Uniclass2 is nearing the final version of its first iteration, so it is time to look at how it might be used. John Gelder, Head of content development and sustainability, explores the issue.
Current coordination practice
Current CPI (Construction Project Information) recommendations for coordination of specifications and drawings are that the specification section code, clause (or object) code and clause title are used on the drawings too, e.g. a brick wall might be annotated with 'F10/110 Clay facing brickwork' (see '4.1.5 Linking the documents together', in Production information, at www.cpic.org.uk/en/publications/index.cfm). The drawings wouldn't include any other specification-type information, the idea being that the Contractor will then have to look at the project specification (which is, of course, good practice). We have developed annotation software that helps automate this linkage to NBS for Revit and ArchiCAD (see 'Coordinating drawings with specifications' on www.theNBS.com, for example).
This annotation has several sources. The specification section code 'F10' comes from Uniclass table J Work sections for buildings. Strictly, it should be 'JF10' but, because all the codes come from the same table, the table identifier (the 'J') is redundant. This table only covers systems and (some) products for buildings, e.g. cladding and lighting systems, and mortars and busbar trunking. It doesn't cover other object classes, such as elements and spaces, and it doesn't serve other construction sectors, such as civil and process engineering. These are dealt with in other tables in Uniclass, if at all, e.g. table F for Spaces, table G for Elements for buildings, and table K for Work sections for civil engineering works. This means that, as we move along the project timeline and between sectors, we must keep switching tables (in which case we need to use the table codes, to make it clear which table we are using). We also need to switch for particular applications; for example, elements tables are used for cost planning and CAD layering, rather than table J.
The clause code is user-generated. If you are using NBS Building or NBS Landscape, then it will have come from there (NBS is just a 'user' in this sense), but otherwise you'd use your own coding. The NBS clause code could be tweaked to make it project-specific, e.g. you may need to use 110A and 110B, if there are two different types of clay facing brickwork. The clause title likewise is user-generated, and again may be derived from NBS Building or NBS Landscape. The user-generated (and NBS) clause codes and titles are not derived from any of the tables in Uniclass.
Future coordination practice
Coordination under Uniclass2 will follow similar rules to those outlined above. That is, three-part annotation will be used, e.g. 20-55-95/110 Battened wood floating floor system, and 45-20-15/480 Pile carpet tiles. But it will be much more powerful than before.
The section code will come from the Uniclass2 Work results table, which covers systems (groups 10 to 40, and 50 to 85) and products (groups 45 and 90), but also all other object classes (all in group 05):
- Regions (subgroup 05-05), e.g. 05-05-55 Residential regions.
- Districts (subgroup 05-10), e.g. 05-10-55 Residential districts.
- Complexes (subgroup 05-15), e.g. 05-15-55 Residential complexes.
- Entities (subgroups 05-25 to 05-65), e.g. 05-55-50 Short-term residential entities.
- Activities (subgroup 05-75), e.g. 05-75-55 Residential activities.
- Spaces (subgroup 05-80), e.g. 05-80-55 Residential spaces - exterior.
- Elements (subgroup 05-90), e.g. 05-90-25 Wall and barrier elements.
This means that this one table can be used along the entire project time line. For example, the elements subgroup (or any object class groups or subgroups) in the Work results table can be used for cost planning and CAD layering. The Work results table also serves civil and process engineering, so just the one table is needed on multi-sector projects. Use of just one table in this way facilitates integration of the building information model (BIM).
Using just the Work results table throughout the timeline and for all sectors means that table codes, including the Work results table code (WR), do not need to be used.
The object (e.g. clause) codes and titles are not user-generated. Instead, they derive from the corresponding Uniclass2 object class tables. For example, product object codes and titles derive from the Uniclass2 Products table, and element object codes and titles derive from the Uniclass2 Elements table, applying the rules in the Uniclass2 Work results substructure table (e.g. outline or compositional clauses are numbered as 100s in all sections). This is only possible because all the corresponding tables in Uniclass2 are congruent, which they are not in current Uniclass. This also facilitates integration of the building information model (BIM).
The object codes are not derived from specification clauses, and have much broader application than just the specification.
If an object is not included in Uniclass2, the idea is that a user can contact CPI for a name and code, which will then be added to the official online version of Uniclass2 for everyone to use.
Mapping
The object classes are designed to map to each other in a cascade or object hierarchy, an essential component of the project building information model (BIM). This mapping is not done in Uniclass2, though Uniclass2 is designed specifically to support it. Rather, the mapping is done in the model itself. This mapping is built into NBS Create, between systems and products (with other mappings to follow as we develop the tool - see below), but the geometrical part of the model will mirror this mapping, as should COBie. For example, preconfigured elements in the National BIM Library map to systems. Project mappings will be identical in the geometry (CAD) and in the specification, enabling these two major parts of the model to link to each other so that, ultimately, you will be able to author either in either, if you see what I mean.
The mapping that seems to be of most interest is that of Elements-to-Systems, so it is worth spending a little time explaining how this will work. I'll use the NBS Create clause structure to illustrate this, but it is important to remember that the CAD files will hold parallel mappings (as far as the objects are modelled in CAD, e.g. at present objects like individual bricks and cavity ties are not modelled).
An element such as an 'external cavity wall' is broken down into its sub-elements, such as its core fabric, external skin, openings, coverings and finishes (this layer concept is borrowed from Uniclass table G Elements for buildings, and makes good sense in geometrical modelling for this type of element - not all elements are of this type, however). These in turn will comprise individual technical systems, typically executed by a single trade. For example, the core fabric might be a masonry wall system (trade A), the external skin might be a weatherboarding system (trade B), and the inner covering might be a plaster system (trade C). Painting systems would provide the external and internal finishes (trades D and E, perhaps). This is expanded in the table.
We will treat the sub-elements as keywords in the NBS Create element outline clauses, and the systems will be treated as values. The element outline clauses, in other words, map the elements to their component systems.
Each of these systems will have its own outline clause, many of which are already in NBS Create. These system outline clauses in turn map the system to its component products, via component keywords such as 'Masonry units: [...]' and 'Mortar: [...]'.
Users of NBS Create (and NBS Engineering Services) will be familiar with this. The fully developed version of NBS Create will comprise a chain of compositional mappings (what we call 'outline' specifications), from Regions-to-Districts down to Systems-to-Products.
It is still early days in the development of Uniclass2, NBS Create and the National BIM Library. The concepts, codes and names are subject to change, refinement and improvement.
