OmniClass™ Work Results: a critique (source: NBS.com)
It has been suggested by some that, rather than developing or implementing Uniclass2, we in the UK should switch to OmniClass, used in North America. John Gelder, Head of content development and sustainability, takes a critical look at the OmniClass Work Results Table, comparing it throughout with the Uniclass2 Work Results Table.
OmniClass is the North American equivalent of Uniclass2 and is promulgated by CSI (Construction Specifications Institute) and CSC (Construction Specifications Canada).
Broadly speaking OmniClass is in a similar position to Uniclass 1997, with much the same general limitations, though it is rather more unified. Uniclass articles corresponding to this one include Reclassification and The new Uniclass Work sections table. For a review of OmniClass in general, refer to the separate article OmniClass: a critique.
Scope
Like Uniclass Table J (aka CAWS), the OmniClass Work Results Table (aka MasterFormat) is geared mostly to the specification of systems and products, and so is focused on the construction phase. It doesn’t serve the whole project timeline, as it doesn’t have homes for high-level (early-stage) objects such as Complexes, Activities and Elements. This means that the Table can’t properly serve design-build and design-build-operate procurement (which, in the latter case, typically requires the contractor to be involved from the very beginning of the project, as part of a consortium). Other Tables within OmniClass must be used to structure specifications for Entities, Spaces and Elements. Tables outside OmniClass must be used for other object classes. These would then need to map to each other and to the Work Results Table, in order to properly integrate the specification component of the building information model (BIM) along the project timeline. Given the lack of congruence, this won’t be easy.
The Uniclass2 Work Results Table has homes for objects of all classes from Regions down to Products, so can fully serve the project timeline, and all procurement routes. See Table 5.*
Even mapping between systems and products is problematic because, read with the non-OmniClass SectionFormat, there are no homes for System outline (or compositional) specifications. Indeed, Systems and Products are conflated. This means that the Work Results Table, plus SectionFormat, can’t properly serve BIM, which requires mapping between objects of different classes in the object hierarchy (e.g. this product is part of that system, this system comprises those products). Making this explicit in the specification requires outline specifications. We can’t rely on this mapping being delivered through the geometrical part of BIM (CAD) since many systems and products are not modelled geometrically at all.
The Uniclass2 Work Results Structure Table provides for outline (compositional) specifications all down the object hierarchy, including Systems-to-Products, so fully supports BIM. Table 5 illustrates this (left-hand column).
Table 5: OmniClass and Unclass2 Work Results Tables – scope
Item | OmniClass Table 22 Work Results 2011 & SectionFormat 2008 | Uniclass2 Work Results Table & Work Results Structure Table |
Project management | Division 00 Procurement and contracting requirements + Division 01 General requirements | Group 00 Project management + Management Table |
Region outline | Not included | Group 02 Regions + Regions Table |
Region performance | ||
District outline | Group 04 Districts + Districts Table | |
District performance | ||
Complex outline | Group 06 Complexes + Complexes Table | |
Complex performance | ||
Entity outline | Group 08 Entities + Entities Table | |
Entity performance | ||
Activity outline | Group 10 Activities + Activities Table | |
Activity performance | ||
Space outline | Group 12 Spaces + Spaces Table | |
Space performance | ||
Element outline | Group 14 Elements + Elements Table | |
Element performance | ||
System outline | System sections: System outline subsection + Systems Table | |
System performance | Work sections: SF Products subsection | System sections: System performance subsection |
Products | System sections: Products subsection + Products Table | |
Custom-made products | System sections: Custom-made products subsection | |
Execution | Work sections: SF Execution subsection | System sections: Execution subsection |
System completion | Sub-group XX 08 00 Commissioning | System sections: System completion subsection |
System FM | Sub-group XX 01 00 Maintenance | System sections: System FM subsection |
SectionFormat has a home for the specification of performance and design criteria of products, which in turn are defined as including systems, assemblies, manufactured units, equipment, components, product types and materials. That is, SectionFormat doesn’t really distinguish between products, systems and materials, though OmniClass at large does (in the Products, Work Results and Materials Tables). ‘Performance’ at a higher level was in sub-group 01 80 00 Performance requirements in the 2004 edition of this Table, but this has been dropped in the 2011 edition. As it was actually mostly about elements rather than systems (e.g. 01 83 16 Exterior enclosure performance requirements), the idea is probably that this is specified using a specification aligned to the Elements Table.
The Uniclass2 Work Results Structure Table provides for performance specification of objects all down the object hierarchy, so fully supports contractor (and other) design. It also makes a clear distinction between Elements, Systems and Products (and so on) – this is essential for a rational approach to hierarchical object modelling. Table 5 illustrates this (left-hand column).
In the OmniClass Work Results Table, the commissioning and maintenance of systems (elements, actually) are not described in the system sections, but in separate sections in sub-groups 08 and 01 of each group, respectively, e.g. sub-group 09-08-00 Commissioning of finishes and section 09-01-70 Maintenance of wall finishes (see Table 6). This is rather inconvenient for those wanting to have everything about a given system collected together (though of course this could be managed through reporting in a digital specification tool such as NBS Create).
All aspects of each system, from design to operation, are collected in each of the System sections in the Uniclass2 Work Results Structure Table. Table 5 illustrates this (right-hand column).
Sequence
The general sequence of sections within each Group doesn’t fully reflect construction sequence. For example, operation and maintenance should be last, and commissioning should be second-last, but this isn’t the structure at all. All of this is held in sections that precede those describing the thing yet to be designed and built. See Table 6.
The System section structure in the Uniclass2 Work Results Structure Table fully reflects construction sequence. See Table 5 (right-hand column).
Table 6: OmniClass Work Results Table – section sequence
Fabric example | Services example |
08-00-00 Openings | 23-00-00 Heating, ventilating and air conditioning (HVAC) |
• 08-01-00 Operation and maintenance of openings | • 23-01-00 Operation and maintenance of HVAC systems |
• 08-05-00 Common work results for openings | • 23-05-00 Common work results for HVAC |
• 08-06-00 Schedules for openings | • 23-06-00 Schedules for HVAC |
• Not used | • 23-07-00 HVAC insulation |
• 08-08-00 Commissioning of openings | • 23-08-00 Commissioning of HVAC |
• Not used | • 23-09-00 Instrumentation and control for HVAC |
08-10-00 Doors and frames | 23-10-00 Facility fuel systems |
Not used | 23-20-00 HVAC piping and pumps |
08-30-00 Specialty doors and frames | 23-30-00 HVAC air distribution |
08-40-00 Entrances, storefronts and curtain walls | 23-40-00 HVAC air cleaning devices |
08-50-00 Windows | 23-50-00 Central heating equipment |
08-60-00 Roof windows and skylights | 23-60-00 Central cooling equipment |
08-70-00 Hardware | 23-70-00 Central HVAC equipment |
08-80-00 Glazing | 23-80-00 Decentralized HVAC equipment |
08-90-00 Louvers and vents | Not used |
Conclusion
The OmniClass Work Results Table has deficiencies, specifically with respect to serving the entire project timeline and all procurement routes, and supporting BIM. It has a construction phase focus, and so has no homes for the specification of high-level objects such as Complexes, so it can’t deal with early project stages. System operation and maintenance specifications are isolated from descriptions of the systems themselves, so it doesn’t serve the occupancy phase as well as it might. Together this means that the Table is not well-suited to non-traditional modes of procurement, such as design-build and design-build-operate.
The Work Results Table conflates systems and products, and has no homes for outline or compositional specifications. Together these mean that the Table doesn’t support hierarchical object mapping, a key requirement for a BIM specification. This is exacerbated by the Table – and OmniClass as a whole – not supporting classification of high-level object classes and systems. Without these object classes we cannot produce a complete ‘building’ information model.
Finally, the basic design-build-operate sequence is not implemented fully in the Work Results Table, nor in SectionFormat (e.g. a proposed FM subsection has not eventuated; system-wide performance requirements are not distinguished from those for ‘mere’ products). This makes the default structure rather messy.
BIM requires a unified approach to classification if it is to work well, e.g. with simple mapping between classification Tables. OmniClass cannot deliver this, as it stands. Uniclass2 can.
* Note: Tables 1 to 4 are available in OmniClass™: a critique
Great read, was wondering what are your thoughts regarding Uniclass2015, do the same conclusions still apply?
Why not comparing with CCS Cuneco, http://cuneco.dk/english
The last thing we need is yet another classification system. Using existing and proven data architectures is the way to go…no?
Interesting read, the BIM Institute is busy developing Africlass Classification for BIM projects in Africa.he ASAQS Elemental Class – Version 4 is a classification system derived from the ASAQS Guide to Elemental Cost Estimating 2016.
This classification system gives us the opportunity to classify ‘things’ in different ways in the construction environment, not only as a system but can also help us define BIM objects in a building. By standardizing such information using the Estimators Elemental Class, communication among architects, specifiers, contractors and suppliers can be made far easier for project members to collaborate and for building owners’ in understanding their requirements, timelines and budgets far better for 5D costing.
The ASAQS Guide to Elemental Cost Estimating 2016 is good in some ways and bad in others. There no need for yet another classification system, if people would use learn and improve/adapt what already exists. For example, Uniformat II covers most of what is represented in the ASAQS Guide to Elemental Cost Estimating 2016. Then, of course the level of estimating covers by the ASAQS Guide to Elemental Cost Estimating 2016 is only somewhat useful. For actionable estimating detailed line item estimating is needed, for example CSI Masterformat-50 Division. Then lastly you need and overall common glossary, example OMNICLASS.
Using Uniformat, Masterformat, and Omniclass would have been the place to start, no?
Would like to know what advantages the Author feel Regional/District actually adds to a project? and is the inclusion really beneficial to all services providers
Please clarify….