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.
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
||OmniClass Table 22 Work Results 2011 & SectionFormat 2008
||Uniclass2 Work Results Table & Work Results Structure Table
||Division 00 Procurement and contracting requirements + Division 01 General requirements
||Group 00 Project management + Management Table
||Group 02 Regions + Regions Table
||Group 04 Districts + Districts Table
||Group 06 Complexes + Complexes Table
||Group 08 Entities + Entities Table
||Group 10 Activities + Activities Table
||Group 12 Spaces + Spaces Table
||Group 14 Elements + Elements Table
||System sections: System outline subsection + Systems Table
||Work sections: SF Products subsection
||System sections: System performance subsection
||System sections: Products subsection + Products Table
||System sections: Custom-made products subsection
||Work sections: SF Execution subsection
||System sections: Execution subsection
||Sub-group XX 08 00 Commissioning
||System sections: System completion subsection
||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).
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
||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
||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
||23-50-00 Central heating equipment
|08-60-00 Roof windows and skylights
||23-60-00 Central cooling equipment
||23-70-00 Central HVAC equipment
||23-80-00 Decentralized HVAC equipment
|08-90-00 Louvers and vents
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
via http://www.4Clicks.com – Leading cost estimating and efficient project delivery software software solutions for JOC, SABER, IDIQ, MATOC, SATOC, MACC, POCA, BOA, BOS … featuring and exclusively enhanced 400,000 line item RSMeans Cost Database, visual estimating / automatic quantity take off ( QTO), contract, project, and document mangement, all in one application.