BIM Beyond Design Guidebook (2020)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

81 Prior sections have discussed how BIM can be a process for sharing facility data and building a collaborative life cycle approach to managing facilities. This section will describe the primary data types, structures, and formats that are generally associated with BIM, and the most common methods of information exchange between BIM and other facility management applications. BIM can provide accurate and complete facility data, but if these data are not accessible to the organization, little benefit will be realized. To facilitate BIM accessibility, it is critical that the facility data within BIM be integrated into the other existing information management systems so that these data provide direct productivity and quality improvements to O&M activities across the airport. While major BIM-authoring software applications allow an ad hoc approach to asset data definitions, there are two primary considerations in ensuring the smooth integration of BIM with external systems. The first consideration is the format of the data. The second consider- ation, particularly important with the integration of BIM and a CMMS and/or EAM system, is the notion of asset classification and mapping in different classification systems. Both considerations will be reviewed in this section, followed by an example of how they are tied together to provide an integrated data management process. 8.1 Data Formats 8.1.1 IFC IFC, defined by ISO 16739, is the core BIM data standard that is used to provide inter- operability with BIM and other external applications. It is a structured, plain text format that can be opened and viewed with any text editor. It also comes in a format (an IFCXML format) that is structured for the IFC text to be easily viewed using web browsers. IFC includes both a definition of asset data types and graphical primitives (commands on how to draw an item in 3D) that can reproduce the size and shape of the assets developed within the BIM. IFC also includes data on how assets are tied together into systems within BIM. IFC is one of the primary methods used to share facility models developed within one vendor’s BIM-authoring system with another. IFC as an integration method works well to some degree, but there may be productivity features within one BIM-authoring tool that do not carry over in the translation to another tool. This is because IFC has no corresponding support for those features. Unsupported features include the parametric design aspect of objects within a BIM that would enable how it is inserted and sized within a BIM. Using IFC as an exchange mechanism between one BIM-authoring platform and another would result in the loss of this parametric object functionality and bring over a static object. S E C T I O N 8 BIM Implementation—Integration of BIM with Existing Systems

82 BIM Beyond Design Guidebook One area IFC does excel in is supporting open-source, inexpensive viewing platforms that can be used to publish BIM data across an organization. To the extent that access to BIM should be maximized, having open-source options for sharing BIM is valuable. Other benefits of IFC are apparent in BIM coordination during construction, when various subcontractors are using BIM-authoring platforms from different vendors, and in analy- sis applications that provide support for performing energy analysis, lighting analysis, LEED compliance analysis, or structural analysis. Although a detailed analysis of the IFC format is beyond the scope of this research, a snippet of IFC code related to a door shows the complexity that would be involved in using this as a primary human interface: #548 IFCRELASSOCIATESCLASSIFICATION('3BZU0$SsX19PepvRtakq3K',#41, 'Uniformat Classification','',(#533),#547); #552 IFCCARTESIANPOINT((1.38777878078145E-17,0.)); #554 IFCAXIS2PLACEMENT2D(#552,#23); #555 IFCRECTANGLEPROFILEDEF(.AREA.,'36" x 48"', #554, 0.0416666666666667, 2.58333333333333); = = = = This sample of code illustrates that while IFC can be read by humans, in practice, it is more relevant as a means of data transfer between software applications. 8.1.2 COBie—MVD The COBie MVD of IFC was designed to make working with IFC data easier. An MVD of IFC defines a subset of the IFC focused on one or more information exchange requirements needed to support end-user applications. While this sounds complex, it is designed to get the IFC mapped into a manageable format. COBie is defined in Chapter 4.2 of the NBIMS-US V3 National BIM Standards. Addi- tional guidance is provided in “The COBie Guide: A Commentary to the NBIMS-US COBie Standard,” (East and Carrasquillo-Mangual, 2013), which provides additional details about implementing COBie. COBie was developed as a standard to manage the handover of critical O&M data to owners after construction to support facility management applications. Because of this, COBie is the most common means of transferring data from BIM into CMMS and EAM systems. COBie is not the only means of integrating data between BIM and a CMMS. The data within a BIM can be formatted and classified using any ad hoc approach the owner wishes. However, if the owner decides to use a non-COBie approach, the owner will be responsible for creating the approach’s unique mapping of BIM data attributes to the asset classifications used in the owner’s CMMS. Using COBie provides a standard consensus approach that is supported by many CMMSs and other management application vendors. A standards-based approach enables the owner to more freely migrate to new systems or replace systems without the added complexity of having to invest in an additional programming effort. Unlike IFC, COBie is primarily focused on facility and asset data and not on representing the detailed size and shape of each asset within the facility. Other MVDs focus on the geometric data and include the reference view and coordination view. These examples demonstrate how valuable the use of MVD structure is in limiting the size and complexity of the IFC data to fit the need of the application.

BIM Implementation—Integration of BIM with Existing Systems 83 COBie data are very easy to read and manage and have value outside of BIM. Data are often developed, shared, and managed within spreadsheets, and can be easily exported directly from BIM with most major BIM-authoring software. COBie can be viewed and managed as spread- sheets, which are defined by the SpreadsheetML standard; this is generally the format that owners will be using. COBie data define a facility as a set of zones, spaces, and floors, with assets having types composed of specific components that may be connected as systems. Within the COBie spreadsheet, there will be separate worksheets for contacts, facility, floor, space, zone, asset type, component, and systems. Spatial assets, such as floors and rooms, are identified by space and floor worksheets. Spaces can also be defined using a zone worksheet, where zones might include data on HVAC circulation zones, security zones, fire protection, or other facility space management structures. It is important to note that while spaces must be unique, spaces can be defined as existing in multiple zones. Equipment is identified in the type and component worksheets, and specific equipment asset information is in the attribute worksheet. Optionally, equipment can be identified as belonging to a system. Figure 8-1 shows COBie’s typical data structure. COBie does not define an asset-naming convention; it only requires that asset names are unique. The COBie commentary from the NIBS suggests a method for ensuring unique asset names by structuring the names based on the COBie space and asset type names. The formula recommended is the following: COBie.Type.Name – COBie.Space.Name – Item Count in Space For example, light fixtures in a lobby might be defined as the following: Lobby.overhead light – 001, Lobby.overhead light – 002, and so forth If the COBie data are going to be combined with several other facilities, then the asset names can be prefixed with the COBie.Facility.Name: TerminalA.Lobby.overhead light – 001 Source: East, 2013 Figure 8-1. COBie data structure.

84 BIM Beyond Design Guidebook Other asset-naming schemas are possible and will work with COBie if the naming conven- tions ensure uniqueness. The NBIMS-US V3 COBie standard does not define specific equipment attributes that each component must provide. The COBie commentary (East and Carrasquillo-Mangual, 2013) does provide some guidance on the attributes that should be collected. An example from the commentary is shown as Figure 8-2. The shaded rows are optional entries while the non- shaded rows are required data. Each owner may include additional attributes; COBie does not restrict the inclusion of additional asset data. Example COBie Space Worksheet Figure 8-3 is an example of a space worksheet. Each unique space should have a line and a unique name in the worksheet. In the example, the room tag is used as the space name, and the “Category” column identifiers are using OmniClass classifications (described later in this section). Example Component Worksheet Each unique component of the facility must first be defined as a type in a COBie type work- sheet. For example, each type of door would have a line in the worksheet shown in Figure 8-4. Likewise, similar doors from different manufacturers would each have a separate line. The COBie component worksheet would look as shown in Figure 8-5. In this worksheet, each line represents a unique asset. Every door has a specific location and name. Note that the type name for the component must match one of those defined in the type worksheet. Also, note that, in the case of a door, the space description includes the two COBie spaces and the door connects. These COBie spaces must be those defined in the COBie space worksheet. Source: East and Carrasquillo-Mangual, 2013 Figure 8-2. COBie recommended asset attributes example.

BIM Implementation—Integration of BIM with Existing Systems 85 Figure 8-3. Example COBie space worksheet. Figure 8-4. Example COBie type worksheet. Figure 8-5. Example COBie component space definitions.

86 BIM Beyond Design Guidebook A detailed tutorial on COBie is beyond the scope of this Guidebook. Additional COBie resources are included in the bibliography. The critical aspects of COBie that airport owners should understand are the following: • COBie can provide a structured system for asset data handover after construction. • COBie defines asset data, not 3D geometry. • Using COBie provides a consensus standard approach that is supported by many CMMSs and other management application vendors. A standards-based approach enables the owner to more freely migrate to new systems or replace systems without the added complexity of having to invest in an additional programming effort. • While COBie is a good option for data integration with a CMMS, full IFC is a better option for integration that requires 3D visualization, floor plans, and other spatial geometry. 8.2 Classification Systems BIM supports a standard for asset classification and, because OmniClass is the most preva- lently used system, it is a good starting point for the discussion of how to classify airport assets. 8.2.1 OmniClass/UniFormat OmniClass and UniFormat are classification systems developed for the construction industry. OmniClass includes 15 tables that classify construction environment information: • Table 11—Construction Entities by Function • Table 12—Construction Entities by Form • Table 13—Spaces by Function • Table 14—Spaces by Form • Table 21—Elements • Table 22—Work Results • Table 23—Products • Table 31—Phases • Table 32—Services • Table 33—Disciplines • Table 34—Organizational Roles • Table 35—Tools • Table 36—Information • Table 41—Materials • Table 49—Properties OmniClass, as its name suggests, encompasses several other classification systems. The Construction Specifications Institute (CSI), Master Format standard, is part of “Table 22— Work Results.” This table classifies a facility regarding the specific components required to build it and to support cost estimating. The CSI UniFormat standard is part of “Table 21— Elements,” which identifies specific facility elements. CSI Master Format “Table 23—Products” specifies standard product types currently used in the construction and operation of facilities. While an owner’s non-standardized asset classification system can be fully integrated with BIM, the use of a standardized system is a step toward creating a sustainable asset life cycle approach that can leverage industry standard tools, processes, and experience to lower overall facility management costs. 8.2.2 Custom Asset Data Schema Migrating to a new asset classification system can be a time-consuming and costly process. Adopting a standards-based data schema will eliminate the cost and the potential introduction

BIM Implementation—Integration of BIM with Existing Systems 87 of errors of the data translation that will be required to utilize industry-developed product- ivity and collaboration tools that require standardized interfaces. The alternative is to invest in creating a custom data mapping standard that will show how the airport’s custom asset classification maps to existing standards. The considerations for integration are the following: • Defining the AIRs before BIM development • Defining an AIR quality control process to validate asset data before integration • Mapping BIM asset unique identifiers with assets in the CMMS • Being able to classify assets by their BIM systems • Being able to classify asset zones and spaces within BIM 8.3 Integration Process Much of the preceding narrative has been focused on BIM data integration with a CMMS system. This narrative covered the general data formats and asset classification systems that airport owners will need to understand. The following sections provide a recommended process for creating a maintainable BIM–CMMS integration. 8.3.1 Create BIM AIRs Airports are composed of many facility types. As BIM is developed for these facilities and delivered either through new construction or from as-built data, it is important that a consistent asset data schema, or AIRs, is used. Included in the AIRs are the requirements for the AIM that define what LOD is required to support the desired external integration with asset management, space management, sustainability analysis, disaster planning, and other operational analysis applications. With the current level of technology, a record model BIM delivered as part of a construction handover process may be overly complex and cause performance issues with the integration. The construction LOD required for clash detection, workflow coordination, and sequencing is greater than that required for asset inventory or maintenance planning. Also, the BIM objects that many manufacturers supply are often overly complex and designed to look photorealistic rather than designed to provide the minimum graphical model requirements (size, shape, critical inputs/outputs, and access points). For space-planning purposes, an LOD of 200 may be enough to support the integration of floor layouts. LOD 300 is likely enough for most asset management applications. The reduced detail model is the AIM. Over time, as the BIM software and hardware continue to improve and reduce issues with handling large complex files, the need to optimize files or reduce complexity will be minimized. 8.3.2 Define Mapping of AIR to CMMS Classification and Component Elements Integration of BIM with end-user applications requires mapping both component-level elements and space elements and addressing how they are organized into systems. Integration requires mapping the AIR elements onto the CMMS data dictionary. In the absence of standards, this mapping can be a time-consuming and costly task. The use of COBie and a CMMS that supports COBie can greatly accelerate this task. 8.3.3 Integrate BIM and the CMMS The term “integration” can represent many things. Exporting data from BIM into a stan- dard format (such as COBie or IFC) and exporting it into another application is a form of

88 BIM Beyond Design Guidebook integration. It is not a tight integration, such as a bi-directional interface between two systems that ensures updates into one system are updated in the other. The range of automated integra- tion capabilities varies across different CMMS or other facility management software platforms, and this should be well understood before beginning this process. If the CMMS is not capable of the desired level of integration, middleware software is available that can provide a bridge between the CMMS and BIM to provide these types of capabilities. Table 8-1 is a high-level mapping of COBie data to an IBM Maximo data system. Some end-user systems will not only support the exchange of component and space data but will also support the exchange of graphical data. For example, selecting a component in the CMMS links the user to the BIM and to a view of the selected component that allows the user to review the location and surrounding environment. 8.3.4 Integrate BIM and BASs Another area of intense interest is integrating BIM with BASs. With the emergence and rapid adoption of IoT real-time sensors, the data available to BASs and other facility management applications will enable optimization and performance levels not previously achievable in buildings. BIM is important to BASs because it provides a coordinate-based spatial context to the real-time sensor data collected. BIM integration enables BASs and other building analytic software to correlate events and provide a level of root cause analysis. The integration tools for BIM and BAS (see Figure 8-6) rely upon IFC. There is currently a Building Automation Modeling Information Exchange (BAMie) in development that is a subset of IFC and is focused on building automation (just as COBie was focused on facility data handover after construction). This standard has not yet been fully released, or adopted widely, so the IFC integration still relies upon customizing the BIM. 8.3.5 Integrate BIM and GIS GIS is typically used for the site-civil asset documentation, while BIM provides a view of the airport’s building facilities. While there is a likelihood that these data types will converge in the future to provide a complete digital model of airport facility infrastructure, today they are still documented in very different types of systems: GIS and BIM. GIS and BIM can be seen as developing out of the 2D CAD environment. GIS added a rich database environment and programmatic interface onto 2D maps. BIM similarly added a COBie Data Type Maximo Object Type Contacts PERSON, COMPANIES, COMPANY CONTACT Facility LOCATION Floor LOCATION Space LOCATION Component LOCATION AND ASSET RECORD Zone LOCSYSTEM System LOCSYSTEM Attributes Values in SPECIFICATION TABLE of ASSET TYPE Table 8-1. High-level mapping of COBie data to an IBM Maximo data system.

BIM Implementation—Integration of BIM with Existing Systems 89 database of facility asset data and a programmatic interface for simulations to 2D CAD. While GIS was primarily 2D, it now supports 3D elements. It would be desirable to be able to leverage the considerable amount of information on horizontal facility infrastructure at airports (such as underground utilities, roadways, and airside pavement) within BIM to provide a more comprehensive view of the entire airport for planning, design, construction, operations, and maintenance activities. Major GIS and BIM software vendors have begun to actively cooperate to simplify the information exchange between GIS and BIM. However, this coordination is still in the early stages, and more manually intensive methods are still required. Depending on the airport stake- holder group, it may be more beneficial either to integrate BIM data into the GIS or to integrate the GIS data into the BIM. Land survey staff may prefer the ability to see faci- lity BIM data as part of their GIS base maps. Facility managers may prefer to see GIS underground utility asset locations and data in the context of their facility BIM. While there is currently no standard method for this exchange, two options are provided in the following. 8.3.6 BIM Data Integrated into GIS One approach is to use the IFC export from BIM and map these data onto a City Geography Markup Language (CityGML) format that can be used with GIS. CityGML is an open infor- mation model standard developed by the Open Geospatial Consortium for the visualization and exchange of 3D city model data. It also has a concept of LOD similar to BIM, in which LOD 4 has not only accurate building shapes but also accurate internal floor plans. Another approach is to use the WebGL (Web Graphics Library) to combine GIS and BIM data (see Figure 8-7) into a single view. This approach does not bring the BIM data into Source: Ecodumus Figure 8-6. BIM–BAS integration interface.

90 BIM Beyond Design Guidebook the GIS database, but it does provide a common interface for viewing and accessing the data within BIM and GIS. One of the greatest challenges with BIM and GIS integration is BIM not being aligned with real-world geospatial coordinate systems. While BIM can utilize real-world spatial coordinate systems, in practice most architectural and construction models are built around internal reference coordinate systems. Converting internal reference coordinate systems to real-world geospatial coordinate systems after construction can be problematic and time consuming, so requiring the use of geospatial coordinates as part of the BIM-authoring stan- dards is recommended. 8.3.7 GIS Data Integrated into BIM Until the specific BIM-authoring tools to provide closer integration with tools available in the GIS world are more fully developed, bringing GIS data into native BIM-authoring tools will require some intermediate integration to convert the data into a format more usable by BIM. The required workflow would bring GIS data into a 3D site-civil design tool where contour surface maps could be created. GIS shapefiles would need to be used as a guide to developing 3D civil infrastructures such as roadways, taxiways, pavements, and underground utilities. The site-civil 3D infrastructure developed from the GIS, along with the GIS attribute data, can then be integrated into a BIM-authoring platform. The integration is somewhat straightforward if tools from the same software vendors are being used, but can also be done using IFC, if necessary. 8.4 Summary Integration of BIM with other facility data management systems can be a complex activity. Although software and technology vendors are working toward more highly integrated solutions, it is still early in the process, and available solutions will still require some level of manual effort or customization. The value of BIM, however, increases dramatically as the information available in BIM is shared across the facility information management infrastructure. The more systems that share common data, the more value BIM delivers. Standards-based BIM asset data schemas will maximize the benefits of interoperability while at the same time minimizing the cost of integration. Custom data translation is possible Source: CityGML Figure 8-7. CityGML LOD example.

BIM Implementation—Integration of BIM with Existing Systems 91 to support existing non-standard data classification systems; however, there will be a cost associated with integration, and it could introduce the possibility of future data translation errors. The facility management industry is rapidly evolving to accommo- date innovation in facility information management. These innovations promise to radically improve the information and real-time controls available to facility managers. These include IoT real-time sensor data, BASs, predictive maintenance systems, AI-based decision-making support, and automated construction and maintenance systems. Developing a BIM with an open standards-based technical architec- ture will position the airport to leverage existing BIM tools, processes, and standards, and to benefit from future innovations. Section 8 Checklist 1. Determine the BIM data standard to be used to provide interoperability with BIM and other external applications. 2. Create BIM AIRs. 3. Define mapping of AIR to CMMS classi- fication and component elements. 4. Integrate BIM and the CMMS. 5. Integrate BIM and BASs. 6. Integrate BIM and GIS.