Paul Grimston
An updated UK National Annexe for BS EN ISO 19650-2 was published earlier this year. This detailed a change in the recommendations around “Information Container Identification,” which means file naming to to most of us.
The previous recommendation followed the format of:
Project – Originator – Volume/System – Level/Location – Type – Role – Number
And gave us file names along the lines of:
2021-SYM-Z2-03-DR-S-0001
Which would signify a structural drawing of Zone 2, Level 3 for project 2021 by Symetri. Often, the number would be adapted to try and group drawings into types or packages, such as 1,000’s for plans, 2,000’s for sections, 3,000’s for elevations and so on.
As the guidance recommended the use of “ZZ” or “XX” for either multiple zones or levels or no applicable zones and levels, many of the files produced in a project would end up with ZZ or XX in the Volume and Location fields. This leaves the Number field as the only way of distinguishing between files. Section and Elevation drawings are a good example as they will often span multiple levels.
The updated guidance in the UK national annexe has become more flexible to help combat this and gives file names that make it easier to understand the content contained within them.
The updated recommendation gives the following format:
Project – Originator – Functional Breakdown – Spatial Breakdown – Form – Discipline – Number
Key to making it more flexible, the recommendation of field lengths has also been removed, meaning that each field can be assigned codes that suit the purpose of the project. This will lead to a much more appropriate naming format to suit different types of projects, including infrastructure projects where volumes and levels didn’t always make sense.
Let us look at how this new naming system might be used in a bit more detail.
No change here, the project needs to have a fixed reference, assigned by the appointing party, for all information produced on the project. Each consultant is likely to have their own internal project references/job numbers, but this one must be consistent across all information produced by all the consultants, contractors, and sub-contractors on the project. I have heard it referred to as the “Client Reference” for the project.
Again, there are not any significant changes here except for the removal of fixed length fields. Therefore, if your company is better identified by two initials rather than three or four, then that is acceptable so long as it is agreed and noted within the project documentation.
This is the first major change. In changing the Volume/System label to Function, this field can now be used to denote different design function intended for the information contained in the file.
Currently, the volume/system field is usually used to divide bigger projects into zones, for example, separate buildings on a site or each use in a multi-use development. However, this kind of Zoning could be incorporated into the Spatial Breakdown field, leaving this Function field to define the design purpose of the information, making it easier to group similar information together, for example, fire protection information that would have the same function code regardless of which part of the project it related to or whether it is a schedule, drawing or report.
For many years consultants have had a system of drawing numbers that help them to package relevant drawings together and organise them when viewed as a folder of individual files. CI/SfB and subsequently Uniclass have been used as part of many CAD standards since CAD became popular and are ingrained in some working practices.
Therefore, the option to use a functional breakdown allows us to use work packages to define the function. For example:
The proposed breakdown needs to be specified in the project documentation and agreed to by all parties for each project.
This field has been renamed from Location/Level to allow for a wider range of spatial locations to be accommodated. For example, infrastructure projects could be split by geographical regions or site locations. For a building project, both Zone and Level could be combined to specify the spatial breakdown. With the field character limit being removed, more complex, project specific codes can be accommodated.
For a project which has three buildings on a site, the spatial breakdown could be made up of a building reference combined with a floor level.
Building A, floor level 01 could be specified as “A01”
Building B, mezzanine of level 3 could read as “B03M”
The recommended level codes have also been removed, allowing for codes that are more suitable to specific projects, so long as they are agreed and documented in the BEP.
This field is renamed from Type and has a more succinct list of standard codes. However, the standard codes could be extended on a project-by-project basis to allow for more precise codes.
The standard codes are as follows:
An example of extending the codes could be as follows:
The discipline field is renamed from Role, with the list of standard codes revised to take account of technical activities rather than job titles or contractual titles. The revised list is as follows:
These codes can be expanded to 2 characters if required by the project.
The final field is the number. If all the preceding fields do not generate unique numbers, then this field should be allocated a sequential number to make the whole name unique.
If required, the number can be used to create groupings or series of information, although it should not duplicate any information defined in the preceding fields. For example, if a plan needed to be tiled across multiple sheets, this would lead to the fields being identical and the number would need to identify the tiles to make the file name unique.
The length of the number must be consistent and defined within the project documentation. Although there is no minimum or maximum length specified, it should be as short as possible, with leading zero’s being used to maintain the length.
The revised format detailed above should lead to meaningful names that could be deciphered to make finding the relevant files easier without the need for reading metadata via a document management system. Below are some examples of such file names conforming to the revised recommendations.
The revised recommendations on information container naming are a welcome change and will give more scope to assign meaningful names to project files, as well as making it more relevant to infrastructure projects. It will also make it easier for organisations to adopt compliant naming standards as they will be able to use familiar codes to identify their outputs.
For more information on ISO 19650 please book an appointment with us HERE.
