New Era of BIM Lifecycle Implementation – Part 2

Reviewing the Adoption of Existing Standards from PIM to AIM

Continued from PART 1

By Dr. Xifan (Jeff) Chen, Dr. Eve Lin, and George Broadbent

Over the past decade, the understanding of Building Information Modeling (BIM) has been expanded from a 3D update of traditional CAD drafting to a lifecycle concept that encompasses the process of creating and managing digital models of built assets. The AECO industry has responded with increased expectations for the advantages the BIM workflow will provide. Project owners and BIM users are well-prepared for its utilization during the delivery phase and now anticipate similar results from its performance during the operational phase, which runs through the remaining lifecycle of a project. The requests for collaborative approaches of information to be collected, created, managed, and shared have intensified.

This article is the second part of the series that deciphers the journey of building information from the delivery phase to the operational phase. The first article  provided an overview of the impact of ISO 19650 Series on Asset Management and concluded its adoption could establish it as the new standard of measurement of true BIM lifecycle implementation. This article supports the previous outlook by reviewing existing widely-adopted classifications in current BIM applications and their practices in BIM to FM (Facility Management) transition. It then takes a deep dive into the current practices of applying those classifications along with discussions of their applicability during the handoff process and their drawbacks. This article also unveils the necessity of an FM-oriented Data Dictionary for BIM to FM (BIM2FM)Lifecycle Project Delivery.   

Introduction

Inadequate interoperability in U.S. facilities costs around 15.8 billion dollars annually. Two-thirds of that amount is incurred during the operation and maintenance phases when more than 80 percent of the time is spent locating pertinent information. The utilization of Building Information Modeling (BIM) coupled with a standardized exchange format has been recognized as the key to enabling seamless data exchange from the Project Information Model (PIM) to the Asset Information Model (AIM). While the advancement of BIM technologies enables a data-rich environment that facilitates various activities throughout the design and construction phases, the information exchange persists as a significant issue during the handover at the end of the construction phase.

Several industry standards, classifications, and specifications were developed to facilitate data interoperability from the initial planning to construction phases, and later on, to the operational phase. For example, Industry Foundation Class (IFC), is one of the most commonly used data models in AECO, maintained and developed by buildingSMART. It is registered as an official international standard – ISO 16739 – for data sharing in the construction and facility management industries. It is a schema developed to define an extensible set of consistent data representation of building information for exchange between AECO software platforms. It has been designed to address building information across the entire building lifecycle from feasibility planning to occupancy and operation. IFC is only one piece of a massive puzzle regarding data conventions and standards in the AECO industry. While IFC addresses the data structures dealing with geometry, relations, and attributes; interoperability is a much broader issue and not covered by IFC, especially during the handover process from delivery to the operational phase. Therefore, coupling IFC with other specifications (i.e., COBie), is often used to address the data exchange needs.

This article reviews four taxonomies that are mostly adopted during the project handover stage, including three classification systems, MasterFormat®, UniFormat™, and OmniClass®, as well as Construction Operation Building information exchange (COBie). Based on industry examples experiences, the article depicts the bitter and sweet stories behind the scenes when applying these standards, from strategic planning to CMMS implementation. It also provides sample use cases of these standards to illustrate their pros and cons and concludes with future directions for improvement.

Quick Review of Current Coding Standards

The Origin Point

MasterFormat® is one of the earliest successful attempts for a common data environment (CDE). It was designed by the Construction Specifications Institute (CSI) and Construction Specifications Canada (CSC) to address building construction specifications via a 16-division numbering system developed in the 1960s and later expanded to 50 divisions in 2004. Classified hierarchically by work results, MasterFormat® organizes information related to construction work results, requirements, products, and activities. Its primary uses are for organizing bidding and contract requirements, specifications, and product information. From its debut, MasterFormat® was developed to support cost estimating and quantity taking off, and therefore is not directly applicable for use during the transition from BIM to FM. Later on, it became a nice addition to UniFormat 2010 as the optional 5th level, which provides a more granular classification to distinguish individual asset types. That gives facility data managers decision making assistance for asset types that could be involved in selected UniFormat™ Levels. As Figure 1 shows below, MF (MasterFormat®) numbers can be referred to under UniFormat™ 2010 Level 4: D2010.20 Domestic Water Equipment.

The Divergence

UniFormat™ has two independent versions, which confused many people. Even Graphisoft®  which developed a BIM software, had a combination of the two versions for a long time. The origin of Uniformat™ came from the American Institute of Architecture (AIA) and the U.S. General Services Administration (GSA) merging the two systems in 1973. The former system (Uniformat 2010) is for architectural practices and the later one (Uniformat II) is for governmental investment and procurement.

The advent of UniFormat™ was significant as MasterFormat® cannot serve both above mentioned tasks well. In addition to the original version of UniFormat™, two UniFormat™ standards have been developed: UniFormat II (2015) from ASTM, and UniFormat 2010 from CSI and CSC. Both standards are top-down 4-level structured, mostly identical but with minor differences, particularly naming conventions and hierarchy arrangements. As the developer of MasterFormat®, CSI can incorporate MasterFormat® into UniFormat 2010 and provide an optional Level 5 in this system, called MF code (or their own choice of coding) in order to make the classification include specific items (from an AM/FM perspective: asset or component). Therefore, UniFormat 2010 is adopted nowadays by some facilities to frame their asset data dictionaries. As an example, Table 1 below presents a portion of the asset data dictionary spreadsheet. The  light yellow color-coded rows are directly adopted from the UniFormat 2010 structure (D3030.10 & D3030.70), while the pale green cells indicate the company’s revisions to Level 5.

The Evolution to Faceted System

Evolving from the developments of MasterFormat® and UniFormat™, the OmniClass® Construction Classification System (OCCS) intends to expand the classification scope to cover the full project lifecycle. It includes but is not limited to sorting and retrieving information for use in preparing project information, and cost and specification. Adhering to the framework of ISO 12006-2 and ISO 12006-3, OmniClass® integrates various domain-specific systems as its tables, such as the aforementioned MasterFormat® for work results table, and UniFormat™

for elements table, as well as EPIC (Electronic Product Information Cooperation) for structuring products.

Compared to its predecessor mostly hierarchical systems, OmniClass® is a faceted classification system with  15 tables, each representing a different aspect of construction information. In a future article, we will dissect the issues of this transition from linear hierarchy to facet system, which solves problems but creates another. OmniClass® is still not a popular standard with facility management, which does not benefit much from its PIM to AIM transition, mainly due to its complexity to use, read, and maintain. Meanwhile, its level of detail overfits asset management’s data requirement.

The Chosen One

Despite the prior standardization efforts, a method to smooth the handoff transition was still absent, and that led to the development of the Construction Operations Building Information Exchange (COBie). COBie is a widely-used performance-based information exchange specification developed to mitigate the tedious, time-consuming handover process during facility asset information delivery. It was initiated in late 2006 under the National Institute of Building Sciences (NIBS) Facility Maintenance and Operation Committee and led by the U.S. Army Corps of Engineers. COBie has been further developed and maintained by the buildingSMART alliance and included as part of the United States National Building Information Model Standard (NBIMS-US) since 2012.

COBie intends to digitize documentation from all channels. In other words, COBie provides a standardized format, i.e., IFC, ifcXML, and Excel spreadsheets, for everyone to collect, populate, and exchange data. It enables data handoff among different software and maintains its interoperability and integrity. The conventional spreadsheet format is the most convenient and straightforward. COBie establishes a set of predefined spreadsheet templates that build an imaginary sharable common “database” between all stakeholders. However, COBie is still confusing most of the time even though it aims to be the “chosen one” to solve all the data problems during the BIM lifecycle implementation. And we all know even with the same last name, chosen ones can have dramatically different stories. We will discuss COBie’s story of BIM2FM transition in the next section.

Real World Complications

The AECO industry has high expectations for COBie to be the data savior. Anyone ever involved in COBie-enabled projects remembers the size of the COBie spreadsheet. COBie can easily generate intensively long spreadsheets due to the number of attributes of every object exported. In extreme scenarios such as an airport terminal, large-scale hospital, or higher-ed facility, it will exceed Excel’s workspace limit of around one million rows. With an acceptable error rate of 1 percent to 1.3 percent  published by buildingSMART industry tests, this will lead to 10,000 rows of problematic data and a painful process considering the difficulty of eyeballing and manually correcting an oversized, color-coded spreadsheet, even on a powerful workstation.

The Struggle of Data Errors

COBie is prone to data errors and that is another barrier stopping companies from adopting it on a lifecycle level. BIM embraces an extensive portfolio of applications, processes, systems, involving various stakeholders, vendors, trades, etc. Data from all channels need to be mapped to populate the COBie sheets – which is more like a highly-maintained business process, rather than a pure technical data exchange. Based on  experience with COBie-streamlined lifecycle data management, errors are inevitable with COBie drops. Meanwhile, a portion of COBie data is required to be populated and updated manually. This creates more trouble over the long run because automated population must be maintained along with manual inputs. Most firms do not prepare and identify this as a risk in the project data management phase, which happens to be the most critical part of BIM to FM lifecycle implementation.

Infrastructural Unfriendly

COBie cannot handle infrastructure projects like other coding standards (i.e., UniFormat™). This is a major drawback, and even an immediate turn off, for Transit Agencies, DOTs, Port Authorities, which own most of the infrastructural capital projects like bridges, tunnels, piers, highways, as shown in Figure 2. For most projects, these agencies will start to develop their own asset structure system rather than use COBie, UniFormat™, or OmniClass®.

For example a transit agency owns various types of capital projects in all the above mentioned infrastructural categories. UniFormat 2010 has been adopted in their project delivery phase  and is regulated by all contractual languages, BIM standards, and BIM execution plans. However, the facilities have their own coding system due to the fact UniFormat™ is a very building-centric system and pushes them to develop their own AM/FM centric data structure. The data structure asymmetry creates a gap from PIM to AIM. An extra mapping layer is required to bridge the gap in terms of data validation, migration, and transition.

Make it More Complicated

COBie can be useful, rational, and practical if only every stakeholder has agreed, is committed and  they all have a good understanding of data exchanges among different stages and drops. Some may already find this is almost an impossible task from a strategic perspective and the need to prepare everything at the beginning of the project, with every stakeholder sitting at the same table, defining data requirements, and COBie schema. That does not include the BIM Standard, BIM Execution Plan (BxP), and QA/QC Compliance Checking process which all need to be correspondingly updated to function with the COBie implementation. The complexity in collaboration, implementation, and validation further demotivates most from choosing COBie in the first place.

A similar story applies to OmniClass®, which includes both MasterFormat® and UniFormat™ and provides an extensible and flexible structure for adding new elements. It is deemed to be more suitable than other coding systems for facility management. While it mitigates some of the drawbacks observed in other coding standards, disadvantages have been found. For example, not all the scopes of the tables incorporate Architecture, Civil, and Building Sciences/Engineering. Also, OmniClass® has varying levels of tables, which lead to inconsistency in the level of description of the components. Furthermore, the inconsistent grouping of objects inside the tables causes discrepancies in the specification. Difficulties in the mapping between the tables and some deficiencies have also been observed. The Work Results Table has shortcomings throughout the entire project timeline and in all procurement routes. OmniClass®’ complexity is the biggest drawback preventing adoption for facility management use.

Simple is Not Always Better

UniFormat™ is another classification standard still in use today. As discussed before, UniFormat™ was initially designed for estimating purposes, which implies its target audiences were not involved in BIM2FM transition. It is very interesting to note clients do choose UniFormat II or 2010 significantly more than COBie to build their asset data dictionaries for their CMMS (like IBM Maximo). One of the key reasons is UniFormat™, compared to any other classification standard, is easy to understand. Simplicity is UniFormat™’s strength, but also its drawback which keeps it from emerging as the go-to classification system for Facility Management. UniFormat™ (both UniFormat II and UniFormat 2010) uses a linear top-down structure. Picture the structure like plant/animal taxonomy – an object can only be categorized under one hierarchy chain (as shown in Figure 3). It is illegal in UniFormat™ to have one object, like water distribution, categorized under multiple systems. This is where the problem transpires.

With project development, various stages and data drops exponentially expand the total amount of model data. It is almost impossible to maintain the linear hierarchical structure. A very common example is  a pump can exist under a hot water system, cold water system, chilled water system, and process water system. This is a violation of UniFormat II 2015. In this case, a prefix has to be added to the pump to make it different such as a hot water pump or cold water pump. Considering the size of the facility management program, the final O&M Manual will be thick like a chronicle. UniFormat II (2010) captured the potential risk and integrated CSI’s MasterFormat® as level 5, trying to fulfill everyone’s needs. It works well from the facility management perspective to help each asset or component find a home. However, from the data transition perspective in terms of BIM2FM data handoff, it is another story for the next article about BIM lifecycle data management.

Conclusion

Despite all the standardization efforts to facilitate the data exchange and handoff process, significant complications persist during the implementation stage. While having limitations, all the classification standards can be useful, rational, and practical if the user understands how to apply them in their scope of work. Users’ domain knowledge and their capability to use these coding standards are significant impacting factors that dictate the smoothness of the implementation process and outcome. In the last decade, even in recent years, many firms have asked about the implementation method of COBie, the transition means from MasterFormat® to OmniClass®, the differences between the two UniFormat versions, and so on. The same questions have come up at BIM conferences, implying this is still a confusing area from the implementer to the user.

Everyone embraces the vision of Integrated Project Delivery (IPD) but often times without fully understanding what it means. When obstacles arise during the implementation, an ad hoc “Frankenstein” solution for data exchange is used and leads to more complications.  As a result, OmniClass® is not often used in the United States. COBie, even highly nominated and promoted, is being gradually phased out more and more often. UniFormat™ is being  more frequently used in AM/FM, although still, by a small percentage.

AEC firms tend to follow the industrial trend when adopting standards. As the concept of BIM lifecycle implementation is better comprehended, it becomes more clear that the difficulty of data exchange  is about the data exchange standard as well as the methods to handle data mapping and transition. Therefore, creating and tailoring a strategic plan for the entire project lifecycle is both ethical and professional.

There was a time when the AECO industry could not speak without referring to BIM4D, 5D, or BIM II. But very few understand the true meaning of these terminologies. The goal is to help all stakeholders reach a mutually agreed data exchange means –  show them the right way to streamline the project from the application, data, model and business process levels, without using standards and interactions that can overwhelm them.

Read Part 1: An Overview of How The ISO 19650 Series Affects Asset Management here.

George Broadbent is Microdesk’s Vice President of Asset Management and has worked on a variety of projects including the rollout of Microdesk’s Maximo and Revit integration solution, ModelStream. George works closely with key stakeholders to identify strategies for asset management projects and manages the effort to build out new systems.

Dr. Xifan Jeff Chen is the EAM Assistant Director at Microdesk, and head of EAM Strategic Advisory Service. Jeff specializes in providing strategic consulting services for clients, conducting and implementing BIM, EAM and GIS integrated solutions, and developing digital twin methodologies for lifecycle BIM implementation.

Dr. Eve Lin is a EAM Strategy Consultant and Sustainability Lead at Microdesk, Dr. Eve Lin specializes in providing strategic and technical solutions for clients to facilitate sustainable practices throughout the project lifecycle. Her involvement includes building performance simulation, design automation, BIM and GIS integration and development of digital twin solutions.