COBie – May 20, 2016
One thing is clear, the construction sector (architecture, engineering, contractors, owners, operators, users, suppliers) has been lagging virtually all other business sectors for decades with respect to productivity improvement.
I believe that the cause is largely cultural, however, any major improvement must be driven by Owners,and/or mandated by governmental regulation.
My reasoning is simple, Owners pay the bills. Thus as long as Owners remain satisfied with the status quo and/or remain “uneducated” with respect to proven business “best practices” and lean management processes, as well as supporting technologies, economic and environmental waste will continue to be rampant.
Currently, my outlook is somewhat pessimistic. If one looks at capability and knowledge specific to life-cycle facility management from an industry perspective, most has originated with the government sector, followed by higher education, state government, healthcare, process-based industries, etc. etc. Basically, Owners whose mission is dependent upon their built environment tend to create and follow life-cycle management practices. These are Owners that can’t adopt a “churn and burn”, or “run to failure” approach to facility management. These sectors can’t easily pack up and move if their facilities and physical infrastructure fail.
That said, even government owners, for the most part, have failed in any sort of department or agency-wide adoption of standardized best practices. This is true even for “simple” areas such as facility repair, maintenance, and renovation. Only the Air Force appears to come close to having any true adoption of robust, proven, best-practices in this regard, as well as associated training, etc., most notably with their SABER construction delivery structure.
In order to effect measurable productivity improvement in the “construction” sector, , I have put together a core requirements “checklist”.
1. Robust Ontology – Cost effective information management and information reuse can only be accomplished with a detailed set of terms, definitions, metrics, etc. This aspect is also critical to improved strategic and tactical decision support mechanisms.
2. An understanding of life-cycle management of the built environment from a collaborative, best-practices, process perspective as well as associated supporting technologies. Forget the traditional strategy-design-construction-demolish approach.
3. Commitment to a total cost of ownership perspective including both economic and environmental costs vs. our classic “first-cost” mentality.
4. “Trust but measure” – Owners MUST conduct their own internal cost estimating and associated capital planning and compare these to contractor estimates, with each party using the same data architecture (examples: RSMeans, masterformat, uniformat, omniclass).
5. Adoption of collaborative construction delivery methods such as Integrated Project Delivery, IPD, and Job Order Contracting, JOC, in lieu of antagonistic and inefficient design-bid-built, or even design-build.
6. STOP reinventing the wheel. Nothing noted here is “rocket science”. Many, if not most, processes, procedures, and technologies are readily available for anyone who does a bit of basic research!!! Also, stop with the focus upon BIM from a 3D visualization perspective! 3D tools are great, and add value, however, INFORMATION and PROCESS drive success.
Here’s a quick overview of a recent meeting discussing the legal aspects of BIM held July 2013.
‘Experts’ we gathered by RIBA Enterprises to discuss the topic. Key items a noted below:
1. CIC Protocol requires employers/onwers to put the protocol in place for all team members and upate the model production delivery table is updated and that an information manager is appointed.Project team members are required to provide specified levels of information, with a reasonable level of care.
2. Key to manage expectations early on in the project.
3. Protocol doesn’t really change liability in itself. That said, the concept of Level of Detail (LOD) become important in determining what information is considered ‘sufficient’ when team members are delivering information to “employers/owners”. Greaeter definition is required for both “data”, i.e. COBie and geometries.
4. Common data is a central requirement and robust management/business rules must be followed to assure development and use.
5. An information manager should not be confused with a design manager. The information manager role spans multiple disciplines / competencies.
6. Copyrights and other intellectual property issues are not any more complicated and appropriate licenses/rights should be established/obtained for owners/team use at the onset of the project.
via http://www.4Clicks.com – Premier cost estimating and efficient project delivery software – JOC, SABER, IDIQ, MATOC, SATOC, MACC, POCA, BOA… featuring integrated contract, project, and document management, visual estimating/QTO, and an exclusively enhanced 400,000+ RSMeans line item cost database with line item modifiers and full descriptions.
Note: The above is not intended as legal advice of any type, but rather a simple report on the session.
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.
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).
|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|
|District outline||Group 04 Districts + Districts Table|
|Complex outline||Group 06 Complexes + Complexes Table|
|Entity outline||Group 08 Entities + Entities Table|
|Activity outline||Group 10 Activities + Activities Table|
|Space outline||Group 12 Spaces + Spaces Table|
|Element outline||Group 14 Elements + Elements Table|
|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).
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).
|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|
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.
1. Robust, collaborative construction delivery methods – IPD, Integrated Project Delivery, JOC – Job Order Contracting, et al . Collaboration in the building industry requires the integration of complex inter-related workflows whereby multitude of stakeholders are incorporated into a common pool of information, decision-support, and activities over an extensive period of time.
2. Standardized “Glossary”.. terms, acronyms, definitions.
3. Benchmarks, metrics.
4. Life-cycle perspective and management techniques/processes… vs. a “first cost mentality”.
5. Technology focused upon enabling robust processes…vs. current focus upon 3D modeling. Embedding vetted processes with technology enables consistent, scalable deployment.
6. Current examples of “open’ and standardized knowledge domains, processes, terms, and technologies.
Capital planning and management systems (CPMS) – physical and functional condition monitoring and associated capital reinvestment planning. traditionally dealing with expenditures in excess of $10,000.
Computerized Maintenance Management systems (CMMS) – inventory, repair, maintenance of ‘movable equipment’. Typically involving expenditures of $10,000 or less.
Computer-Aid Facility Managements Systems (CAFM) – space planning, move management, space utilization.
Building Automation Systems (BAS) – security, life/safety, access control, environment systems management.
Geographic Information Systems (GIS) – computerized location management / positioning.
Create, read, update, delete) operations (CRUD)
Industry Foundation Classes (IFC) – structure enabling native storage of instance models
Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks.
Representational State Transfer (REST) is an architectural style for large-scale software design
Construction Operations Building Information Exchange (COBie) a specification used in the handover of Facility Management information.
OMNICLASS in simple terms, a standard for organizing all construction information. The concept for OmniClass is derived from internationally-accepted standards that have been developed by the International Organization for Standardization (ISO) and the International Construction Information Society (ICIS) subcommittees and workgroups from the early-1990s to the present.
ISO Technical Committee 59, Subcommittee 13, Working Group 2 (TC59/SC13/WG2) drafted a standard for a classification framework (ISO 12006-2, more information below) based on traditional classification but also recognized an alternative “object oriented” approach, which had to be explored further.
UniFormat is a standard for classifying building specifications, cost estimating, and cost analysis in the U.S. and Canada.
MasterFormat is a standard for organizing specifications and other written information for commercial and institutional building projects in the U.S. and Canada.
(Source:A report for the Government Construction Client Group Building Information Modelling (BIM) Working Party Strategy Paper March 2011)
via http://www.4Clicks.com – Premier technology solutions for cost estimating and efficient project delivery method implementation – JOC, SABER, IPD, IDIQ, SATOC, MATOC, MACC, POCA, BOA …
What is COBie?
COBie is a vehicle for sharing predominantly non-graphic data about a facility. The primary motivation for the use of COBie is to ensure that the Client as Owner, Operator and Occupier receives the information about the facility in as complete and as useful form as possible. Wherever possible, data should be recorded within COBie. The COBie dataset can additionally act as a guided index to the supplementary documentation, including 2D and 3D information.
COBie2 was created to provide a means for the faculties industry to communicate information about facilities so that the client can immediately take full and responsible ownership. It arose from the collaboration of the US Department of State, US Army Corps of Engineers, NASA, and the Veterans Association. In 2008 it was revised as COBie to ensure that it was relevant to facilities worldwide and was fully compatible with international standards for data and classification. Adopters of the COBie approach also include public and private owners, University of Indiana, University Southern California, in the UK Vinci Construction Ltd, and in Germany, The State of Bavaria.
COBie is a non-proprietary format based on a multiple page spread sheet. It is designed to be easily managed by organisations of any size and at any level of IT capability, allowing each of them to contribute efficiently to a single representation of the asset. It requires only information that is (or should be) available anyway, so it does not represent a change in the expected content, only in its usefulness and accessibility. The intent is to not create information that is not already available or produced as part of the existing processes. The aim is to structure and rationalise the information for re-purposing and use downstream. COBie also acts as an index to other documents. Overall COBie provides traceability and visibility of design, construction and handover decisions to all supply and client side stakeholders.
COBie is used for communication, as a means of information exchange between parties, particularly to the customer. Where automation is not in use, such as in the lower tiers of the supply chain, COBie information can be captured using direct entry into the spread sheet, often using cut-and-paste from existing schedules and documents. Parties including the client can use the COBie format as a primary document for managing the asset. Design development, construction management and asset management applications have had no difficulty in interfacing with the format.
COBie comprises sheets that document the facility, the levels (or sectors), spaces and zones that make up the function of the facility. These are then filled with the actual manageable systems and assets and details of their product types. During construction and installation these are amplified with information about the spares, warranties, and maintenance requirements. Throughout the process additional attributes, issues and documents can be associated to all these items.
2 COBie (Construction Operations Building information exchange) was developed by a number of US public agencies to improve the handover process to building owner-operators.
COBie data is accumulated throughout the life cycle
COBie transfers the information needed by the owner/operator to manage their asset efficiently. The principal use-case is therefore the handover of a facility after commissioning of the owner/operator. Typical questions answered by COBie include:
1. The handover of a facility to the owner/operator.
2. The capture of commissioning and survey information.
3. The reporting of the designed project ready for tendering.
4. The coordination of maintenance records of existing infrastructure.
5. The documentation of issues discovered throughout the life cycle.
6. The delivery of product data.
7. The reporting of design intent at the early design stage.
8. The comparison of briefing requirements against the designed and as built
COBie documents the asset in 16 consistent and linked sheets
We anticipate that our application of COBie will develop as the various technologies in the market mature, broadly in line with our “maturity levels model” described in appendix 3. For the majority of the five years of the life of this strategy we anticipate that most of the market will be engaged in or around level 2. For all deliveries at this level, COBie will be adequate as a transport mechanism but may well require additional development to cope with additional attached data, which some clients may start to wish for collection. There will also be a need to have a more robust system for processing the information as our understanding and needs grow. For this reason we have identified a stage where we would hold all delivered data in a database to enable these processes. This will need additional guidance as there would be a need to synchronise data, COBie, calculations and proprietary information at the same point in time.
BIM adoption remains a challenge due to the fact that its many supporters don’t focus upon it’s true relevance, the efficient life-cycle management of the built environment.
While any new technology has barriers to adoption, changing the “status quo”, the fundamental nature of how a business sector does business requires a major event. The cultural and process changes associated with BIM, namely the need for all stakeholders to collaborate, share information in a transparent manner, and share in risk/reward, remain chasms to be crossed by many/most. Fortunately, those currently or previously involved with Integrated Project Delivery and Job Order Contracting (the latter a form of IPD specifically targeting renovation, repair, sustainability, and minor new construction) have experience with these “novel” business concepts. Both IPD and JOC have proven track records and have clearly demonstrated the ability to get more work done on-time and on-budget to the benefit of all involved parties.
A key aspect of BIM, collaboration, can only be efficiently accomplished with a commonly understood and shared taxonomy including terms, definitions, and associated metrics.
So called “open BIM”, such as buildingSMART International’s Industry Foundation Classes (IFCs), are important to enabling collaboration as well as interoperability between BIM software applications. COBie, a naming convention for facility spaces/components, etc., and its counterparts OMINCLASS, including MASTERFORMAT and UNIFORMAT, etc. … can be leveraged and generated by IFC appears a goal worth additional focus on a local and global level. That said, support for COBie, OMNICLASS, IFC, etc. varies and, far from mainstream.
As noted in the IFC / COBIE Report 2012, BIM’s success depends upon the ability to:
There are multiple knowledge domains, technologies, and process involve in the life-cycle management of the built environment, all of which need a common data architecture, taxonomy, set of metrics, etc.
The IFC / COBIE Report 2012 correctly points out that pressing needs remain:
The need for standards
The need for guidance
The need for enhanced IFC import export routines from BIM applications
The need for agreed descriptions of who requires what data and when
The need for an improved audit trail to allow greater confidence in collaboration.
Also, and I paraphrase / embellish…