Exchange Model and Exchange Object Concepts for Implementation of National BIM Standards

Transcription

1 Exchange Model and Exchange Object Concepts for Implementation of National BIM Standards C. M. Eastman 1 ; Y.-S. Jeong 2 ; R. Sacks 3 ; and I. Kaner 4 Abstract: The industry foundation class IFC standard building model schema is a necessary but not sufficient condition for achieving full interoperability between building information modeling BIM tools. Unless each information exchange within construction project workflows has its specific contents and level of detail defined, the breadth and flexibility of the IFC schema leaves room for errors. The national BIM standard approach for resolving the ambiguities of information exchange is based on use cases, which precisely define the data required in each information exchange between disciplines in engineering workflows. In this paper, we define specific procedures for developing information delivery manuals IDM, which capture the use cases and the precise information to be exchanged. We also identify some of the data semantics we found problematic that require workflow specification. We further propose details of the information capture that allow the IDM to serve as a specification for later implementation and testing. The procedures are illustrated using examples from an IDM specification developed for the domain of architectural precast concrete. DOI: / ASCE :1 25 CE Database subject headings: Data communication; Information technology IT ; Precast concrete; Standardization; Threedimensional models; Implementation. Author keywords: Data communication; Information technology IT ; Precast concrete; Standardization; Three-dimensional models. Introduction 1 Professor, College of Architecture and College of Computing, Georgia Institute of Technology, Atlanta, GA corresponding author. chuck.eastman@coa.gatech.edu 2 Postdoctoral Researcher, College of Architecture, Georgia Institute of Technology, Atlanta, GA yeon-suk.jeong@ gatech.edu 3 Associate Professor, Faculty of Civil and Environmental Engineering, Technion Israel Institute of Technology, Haifa 32000, Israel. cvsacks@techunix.technion.ac.il 4 Graduate Student, Faculty of Civil and Environmental Engineering, Technion Israel Institute of Technology, Haifa 32000, Israel. israelkaner@gmail.com Note. This manuscript was submitted on March 14, 2008; approved on February 9, 2009; published online on December 15, Discussion period open until June 1, 2010; separate discussions must be submitted for individual papers. This paper is part of the Journal of Computing in Civil Engineering, Vol. 24, No. 1, January 1, ASCE, ISSN /2010/ /$ The problems of interoperability between engineering software systems have existed since the introduction of computer-aided design CAD in the 1970s Pratt File-based data exchange methods such as DXF, IGES, and SAT were developed to exchange geometric entities between one CAD system and another. Most CAD systems have similar geometric entities: points, lines, arcs, planar surfaces, curved surfaces, primitive solids, and so on. The task in writing a geometry translator was to find the corresponding geometric entity in the exchange file format and export the CAD system entities to it. If importing, the corresponding task involved reading the entities from the file format and loading them into the CAD application s native file format. These file formats worked adequately when the objectives were limited to geometry. However, as CAD systems became more sophisticated and evolved into parametric and object-based modeling, the limitations of existing file-based methods became apparent. Parametric modeling involves rules and constraints that define how shapes are to be generated or modified in various conditions; CAD systems became object-based and included attributes and relations between objects as well as geometry Light and Gossard There was no standard way of representing these aspects with existing geometry exchange standards. These more complex interoperability issues first arose in manufacturing in the late 1980s and led to the development of product model exchange technologies in ISO-STEP Standard for the Exchange of Product model data, which is formally called the ISO Standard. ISO-STEP provided the EXPRESS language ISO 1994 for data modeling, common libraries of reusable structures, and methods for developing a variety of exchange capabilities based on specialized data schemas Schenck and Wilson 1994; Eastman This technology has enabled the development of object-based data schemas Fowler 1996; ISO 1998 in more than 20 different areas of manufacturing and electronics Eastman The same issues have become critical in the architecture, engineering, and construction AEC industries with the widespread adoption of Building Information Modeling BIM in the early 2000s Eastman et al The cost of inadequate interoperability for the AEC industries in the United States has been estimated at over $15 billion Gallaher et al While parametric modeling of buildings has existed for as long as it existed in manufacturing, efforts to develop a building product model exchange schema based on ISO-STEP technology only began in the mid-1990s and is ongoing. This effort is the industry foundation classes IFCs IAI 2007, promoted by BuildingSMART previously called the International Alliance for Interoperability Young The manufacturing industries made significant investments in customizing and tailoring parametric modeling tools for their JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010 / 25

2 products Duvall and Bartholomew They rely on long-term working relationships between organizations, developing semicustom exchange protocols using ISO-STEP as a foundation. Such practices are not practical in building construction, which relies on open partnering of small businesses in sharp contrast to the automobile and aerospace industries on projects that commonly extend for periods of three years or less. An exchange capability using open standards is generally recognized to be an industry need Tolman The IFC model provides a range of means to define building objects, processes and other information in a publicly available data schema. It was conceived as a framework model, addressing the broad scope of building design, engineering, construction, and operation Björk It provides an extensive set of generic building object types beam, column, wall, slab, etc. with associated attributes and other properties. It offers numerous shape definition methods and means to depict relations between objects. The intended role of IFC is to depict all information associated with a building, from feasibility and design, through construction and then operation and to support exchanges of this range of information IAI While the intentions of the IFC were laudable, it has been available for a decade but has not yet had a significant impact on the broad problems of interoperability in AEC. In contrast, another building model data schema, the CIMsteel Integration Standard CIS/2, provides capabilities specifically tailored to the domain associated with fabrication of steel structures in buildings Crowley and Watson CIS/2 has enjoyed the strong support of the AISC and has become widely deployed in steel fabrication Eastman et al and supporting interfaces with 15 applications. In retrospect, the purpose and application of CIS/2 was very different from IFC. CIS/2 has limited scope of engineering knowledge, restricted geometry, material properties, and processes Crowley and Watson In practice, the set of applications that deal with steel analysis and fabrication allowed intuitive identification of a few primary workflows and developed specific exchanges for the workflows between the relevant applications. The primary exchanges were: 1 design to fabrication; 2 design to analysis; 3 fabrication to analysis; and 4 fabrication to production. These workflows are broadly supported, implemented in steel fabrication and related applications, and used today in daily production. The results of the IFC, on the other hand, have been difficult to implement and utilize because the use cases in which exchanges are to be made have not yet been clearly defined. For a building model framework schema such as IFC, lack of definition of specific task-oriented exchange content leads to implementation of translators that may be technically correct, but generate incomplete and incompatible data exchanges for specific tasks, because of lack of coordination regarding what specific information is to be included in the IFC view. A proposed solution to these problems is to define the workflows used in practice, the specific information exchanges they require, and define appropriate model views for the exchanges. This is the focus of the national BIM standard NBIMS, administered by BuildingSMART within the National Institute of Building Sciences NIBS In the NBIMS approach, groups of people that are expert in some domain of AEC specify use cases in what are called information delivery manuals IDMs Hietanen 2006a for their domain, after which information experts prepare implementation-oriented model view definitions MVDs Hietanen 2006b to provide the information specifications needed to enable software developers to write appropriate export and import translators. Use cases are detailed descriptions of the context and content of information exchanges between users and/or software tools. The recommended process for generating a NBIMS specification and implementation is described in NBIMS, Vol. 1, Section 5 NIBS A general outline of the process is shown in Fig. 1. The first phase program focuses on domain expert input and the second phase design deals with IFC MVD. This paper presents an early attempt to apply this generic approach, using the domain of architectural precast facades as a test bed. At the time of writing, no completed content volumes of the NBIMS had been published and the applicability of the generic process was thus untested. The research described here required learning and testing through design, application, implementation, and most important, developing further detail for the various steps involved in development of an IDM. The paper offers detailed guidelines for the development of BIM standards following the generic NBIMS approach. The work builds upon earlier efforts to assess the issues involved in interoperability dealing with architectural precast Sacks et al., 2008; Y.-S Jeong, et al Need for Detailed Workflow Analysis When data are exchanged between BIM tools, it is insufficient to rely on the visual aspects of objects only. A range of aspects, not visually apparent on a three-dimensional 3D computer model, must be dealt with. As a shorthand, we call these more detailed aspects of implementation the model s semantics. Also, it is not possible for an application data exchange translator to include the full breadth of entities in the IFC schema; IFC entity classes represent more information than is supported by any one domain application. For issues regarding different types of geometry or attributes, specific use-based targets must be defined. Object models defined by BIM tools are depicted with five classes of description of their contents Pratt Almost all of these classes can be supported for IFC object representations, but until now they have not been adequately specified for robust IFC model exchanges. The classes are: Functional type: wall, slab, column, stairway, footing, etc. ; that is, an object s functional identity must be maintained in any exchange. This identity determines important properties and relations of the object, i.e., riser and tread of stairs. In existing translators, a proxy entity of IFC is sometimes used when the appropriate function-specific type is not identified in the source BIM tool, violating this condition. Other typical errors are exchange of steel reinforcing as pipes, spandrels as walls instead of structural elements, a composition of slabs for a stairway, etc. Geometry: the type of geometry exchanged must be suited to the intended purpose. Different types of geometry provide different capabilities to meet different functional needs. As shown in Fig. 2, the different levels of needs are: 1 visualization; 2 use of a shape s surface geometry for reference or conflict clash checking Garcia-Alonso et al ; 3 direct editing of simple object geometry; and 4 full parametric editing of building objects. A good survey of shape and parametric modeling can be found in Pratt Full exchange of parametric editable models is not supported in current ISO- STEP technology today Pratt 2004 and thus not supported by IFC. In addition, abstract geometries are needed for structural, thermal and other types of analyses Rezayat Attributes: different object properties are needed for different 26 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010

3 needed, additional property sets can be defined for IFC entities for specific tasks. Relations between objects: the relevant set of topological relations is needed to define operations on configurations of shapes. For example, structural connections are needed for structural analyses, and nesting relations between concrete and reinforcing are needed for spatial conflict testing otherwise all reinforcing will be interpreted as conflicting with the concrete objects in which they are embedded. Behavioral rules: the set of rules that determine how the shape and related properties adjust within an assembly when edited, based on context; this information is currently not exchangeable Pratt Although the latest version of the EXPRESS language ISO 2004 supports constraints to define behaviors for dynamic entities, this new language version has not been widely tested or yet used in practice. Thus a successful exchange can only be achieved when the exchange incorporates the semantically required subset of each of the aforementioned classes of description for each object in that exchange. This subset of constituent IFC entities required for any given exchange and their needed definitions must be explicitly defined. The subset is then the basis for translator programming and a yardstick for measuring the success or failure of any export or import function. Such IFC subsets are called model views. An additional issue is that while most object classes for representing building components have been defined in IFC, the great breadth of the construction industry means that some specialized ones have not. As examples: some aspects of architectural precast, such as the surface mix that defines the material used on exposed faces, have no explicit representation. Also, weld objects and specifications needed for structural steel fabrication modeling are not yet defined. Omissions are being addressed as the needs for new object classes are identified. Fortunately, IFC was defined to be extensible and such extensions are usually not difficult. Interesting errors sometimes occur when objects are not explicitly defined and the translator writer has made arbitrary mappings using a proxy element; such as the example shown in Fig. 3. Use Case Approach Fig. 1. Overview of the NBIMS development process; NBIMS, Vol. 1, Section 5 NIBS 2008 tasks and must be defined with agreed-to interpretable names. These range from properties related to performance, to cost codes, to the schedule identifier defining what task will fabricate or place certain building parts during construction. If It has taken several years for AEC researchers and the industry to reach the above recognition that without careful definition of all aspects of each task-specific exchange, they will inevitably continue to be unreliable and faulty. From this recognition, the development of a use case approach to specifying exchanges has emerged Hietanen 2006a. The use case approach identifies the purpose and intent of each exchange, and specifies the necessary content for the exchange to be successful. The implication is that there will be many use cases, possibly hundreds, but each one tuned from the user s perspective to send and receive the specific information of interest. The use case approach has been adopted both in Europe BuildingSMART 2008 and in the United States, albeit with slightly different forms. It is the core of what has been defined in the United States as the NBIMS see Fig. 1. In North America, use case definition is expected to be undertaken by industry organizations or ad hoc groups with shared business interests in specific areas of interoperability. Interest groups are expected to form around building systems types, such as structural steel, RC, curtainwalls, precast concrete, mechanical systems, external cladding systems, site work, building control systems, cabinets, and woodwork, etc. Other use cases will define JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010 / 27

4 Fig. 2. Four different geometric representations and their varying functional capabilities exchanges between architects and structural engineers, between architects and energy consultants, acousticians, lighting consultants, and other parties addressing specific design issues. The domain groups, with guidance from NIBS and industry advisors, will develop the IDM and MVD addressing their priority use cases. The IDMs involve direct involvement of industry specialists who know the workflows and their information flows required for information technology IT -level exchange. Industry or university research groups can advise and document the specification developed. It is the responsibility of NIBS and BuildingSMART to harmonize the different groups and their specifications, so that they are consistent and not duplicative. The next stage, development of MVDs, principally involves the funding of IT experts to carry out the specification process for the relevant use cases. These steps will typically be funded by the domain groups having a business interest in the use cases. It is also the responsibility of BuildingSMART and NIBS to coordinate the release of MVDs to software vendors and to coordinate their implementation by the vendors. Testing and certification of implementations are also anticipated, although these processes have not yet been detailed. The development of a more strictly specified set of data for exchange starts with the identification of the purpose of the exchange. This is formalized through a process model or diagram. NBIMS prescribes use of the business process modeling notation BPMN developed by the object management group OMG, an international, open membership, not-for-profit computer industry consortium BPMN OMG task forces develop enterprise Fig. 3. Connection details were not defined in a BIM tool translator and were arbitrarily mapped to a plant object Lipman 2006 integration standards for a wide range of technologies. BPMN was a development of such a task force to provide a standard diagramming language that is widely used to model business processes for Web business-to-business implementation BPMN BPMN has an associated automated XML implementation of use case diagrams, facilitating business-to-business interoperability. A use case defines an exchange scenario between two welldefined roles for a specific purpose, within a specified phase of a building s life cycle. It is both composed of more detailed process parts and is embedded in a more aggregate process context. A use case has a set of information that is exchanged within it. The exchange may be a singular exchange instance, a set of iterated exchanges, or an initial exchange instance followed by updates. At the same time, most use cases are parts of larger collaborations, where multiple use cases provide a network of collaboration links with other disciplines. We call this higher level composition of use cases a process map. Process maps are not meant to have a fixed structure; use cases may be composed in multiple ways to achieve the same overall purpose and may be defined dynamically. Rather, a process map is illustrative and meant to show where each use case is typically used. A high-level process map for architectural precast is shown in Fig. 4. By using BPMN it identifies the relevant life cycle steps in vertical phases and the roles of the actors in horizontal swim lanes. The three primary elements defined in the process map are: Activities, specified within a role-lifecycle context. These define the specific tasks that the use cases address. Activities are linked by information flows shown as dashed lines and arrows, indicating the direction of information flow solid lines show the precedence relation between activities within a role. Information exchanges, represented by exchange model (EM) definitions on the information flows, identify the information packet that is used in each exchange. Activities may be iterated and indicated with an arc and arrow symbol at the bottom of the activity. They may be high level, indicating it is an aggregation of more detailed activities and EMs, which is indicated with a plus sign in a small box in the activity. A more detailed process map for Activity 1.7 is shown in Fig. 5. The activities interacting with the decomposed activity are repeated, to show their interaction with the decomposed activities. 28 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010

5 Fig. 4. Process map for architectural precast, showing eight use cases In order to define clearly the intentions of each activity in the process map, short paragraphs are linked to the activities using an index. Three examples are shown in Fig. 6. These process maps were developed with input from representative precast contractors, consulting engineers and architects. Significant input came from experimental work on the Rosewood project, which involved careful monitoring and comparison of data exchanges using both two-dimensional 2D and 3D representations, carried out prior to the IDM development Sacks et al For example, the purpose of the use case between Activity 1.1 and 1.2 is to support collaborative design information exchanges between an architect and a precast contractor in design-build or other forms of collaborative development, including construction manager-at-risk. It supports concept design information exchange, to address such issues as panelization, structural connections, casting alternatives, and other issues that can lead to more efficient fabrication level design, without complete redesign of architectural models. Each activity and each EM is given a unique identifier. As IT supports more management functions within the AEC industries, it is important that various efforts be coordinated. In order to standardize the terms used in NBIMS use cases and to provide consistent classification schemes for other information associated with building models, the Omniclass tables and codes recently defined by the Construction Specifications Institute CSI have been adopted. CSI has worked closely with parallel European efforts to develop standard classifications for many of the terms used in construction; these are called the Omniclass Tables Omniclass There are 15 tables covering various definitional aspects of building elements, processes and actors. For use cases, the three important Omniclass definitions are for: Phases (Table 31) which carries the temporal aspects of activities, in creating and sustaining the built environment. Phases include the temporal stages of a building project. Disciplines (Table 33) which are the practice areas and specialties of the actors participants that carry out the processes and procedures that occur during the design-engineeringconstruction-operation life cycle. Organizational roles (Table 34) which are the functional positions occupied by the participants, both individuals and groups, that carry out the processes and procedures which occur during the life cycle of a construction entity Omniclass These classifications are used in naming project phases and in identifying the disciplines associating with the activities being supported. Their purpose is to allow cross referencing between IDMs, allowing matching and, where appropriate possible merging. JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010 / 29

6 Fig. 5. Detailed process map for Activity 1.7, precast detailing, from Fig. 4 Information Delivery Manuals IDMs as Specifications The purpose of an IDM is to capture the knowledge and best practices regarding workflows and their information contents from experts in the user domain. Its focus is to identify the information needed to guarantee that the targeted electronic workflow exchanges will be effective. Clearly, a specification of needed information of the sort all architectural precast pieces must be exchanged along with their geometry is inadequate. Without knowing the exchange purpose, we cannot determine what type of geometry is required or what properties or relations of the architectural precast pieces are needed. The purpose determines the functionality of the desired information. Initial efforts in defining IDMs have not addressed the types of variability that are reviewed in Need for Detailed Workflow Analysis. As a result, workflow implementation decisions made at the MVD stage will likely have some amount of arbitrariness and lead to potentially faulty implementations. A somewhat better scenario is that continued review by domain experts of the technical details of MVD specification will be required. We view this as undesirable because the domain experts are not software experts and will not generally be interested in software details. Mapping the issues to their functional implications, as we propose and have attempted, makes the issues comprehensible. However, there are also strong advantages to be gained from obtaining fully detailed functional specification of exchanges within the IDM itself, defined at the time the workflows are identified. Creating a full functional specification at this stage has the following consequences: 1. Representatives of the end user community that use the use case exchanges the domain users can see the functionality of their specification and gain a good understanding of 30 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010

7 [1.1] Concept Design of Precast Facade Type Name Omniclass Code Documentation Activity Concept Design of Architectural Precast Preliminary design stage Architects or designers use an approved or certified BIM authoring application to develop a Building Model that will include non-structural precast façade panels. They define the panel layout, fenestration, and surface patterning. They place structural elements needed to support the precast pieces. They identify elements that are embedded within the precast or are attached to it. The proposed layout may be made available for review in sketch and drawings or as a model [1.2] Design Review and Concept Modeling Type Name Omniclass Code Documentation [1.3] Design Development Type Name Omniclass Code Documentation Activity Design Review and Concurrent Modeling Preliminary design stage A precast vendor may be consulted in reviewing candidate layouts of architectural precast facades. The fabricator may comment on manufacturing, shipping, fragility, lifting and erection and other issues that may affect the design. These may be passed as verbal or written comments to the architect. Activity Design Development Fabrication Document Preparation Phase The architect refines the architectural precast design and integrates its layout with other building systems. Surface finishes, molding, reveals and other decorative features are defined. The information is prepared as a construction drawing set, or optionally, a construction-level model. Fig. 6. Few activity definitions for the process map shown in Fig. 4 Type Name Identifier Change Log 27-Oct-07 Project Stage Omniclass Table 31 Disciplines Omniclass Table 31 Exchange Model Definition Architectural Precast Concept Stage Exchange Model EM.1 Version 0.5 created, based on Pankow project documents developed by Yeon-Suk Jeong and Chuck Eastman of Georgia Tech and Rafael Sacks and Israel Kaner at Technion. chuck.eastman@coa.gatech.edu cvsacks@techunix.technion.ac.il 1 Concept design of Precast Façade Preliminary Project Description Stage 2 Design review and Concept Modeling Design Development Stage 3 Tender Stage Design Development 4 Design Development Construction documents Stage GC Bid Preparation Procurement Stage 6 Precast Bid Preparation 7 Structural Requirements 8 Precast Detailing Product Development Phase 9 Construction Coordination Coordination Phase 10 Design Intent Validation 11 Structural Design Review 12 Precast Fabrication Fabrication Phase 13 Plant Material Tracking Erection Phase Architecture Subcontractor Precast Fabricator Contractor Engineer (precast consultant) Engineer (Structural) Steel Fabricator -- Iron working Fig. 7. Header page of the EM.1 EM definition what it is and is not expected to do. This eliminates surprises after implementation. 2. The domain experts contribute in a single phase, without cycles of review at long intervals. 3. The IDM becomes a specification that determines up front what the MVD should accomplish, providing clear criteria for later implementation and evaluation. Because of these benefits, the writers have proposed and implemented an IDM definition procedure which uses exchange objects EOs as building blocks for defining EMs. EOs are encapsulated definitions of the information objects that are to be exchanged, defined in language that is in common use by domain experts. They are, however, rigorously defined in terms of the predefined set of functional issues that affect the semantic correctness of an exchange, including the issues described in Need for Detailed Workflow Analysis. All of the functional issues have been incorporated in an EM template in an easy-to-read form, which allows domain experts to provide definitive specifications for EOs, achieving the benefit of functional specification at the early stage of IDM definition. An example of the use of the EM template is shown in Fig. 7 header page and Fig. 8 detailed body of the specification. The header page identifies the project stage and actors, defined in both words and with Omniclass table indices. The stages and actors laid out in the template may vary, depending upon the targeted scope of the process map. These should be adjusted as the process map definition is being defined. Fig. 8 is a page from the body of the EM definition. The page is taken from the EM definition between design development and precast detailing in Fig. 5, labeled EM.4. The template lists object types relevant for the exchanges defined in the process map, grouped on the left by their different information class groupings. The information classes are informal groupings of the information objects to be exchanged. EO type is the class of EO that may be used in the process map, and which may be any of physical, complex property or process. These are grouped into shared sets, defined for the particular use cases being considered. The columns in the EM template body determine the functional properties of the EOs as they are to be used for the EM being defined. First, only one EO template is defined for each EM, and not all EOs will be needed in any particular EM definition; the template allows registration of EOs as not needed, optional or required. Next, the function of the geometry representation, the type of surface geometry that needs to be supported, the accuracy of the geometry, the relations and the metadata required are all specified for each EO class. Three types of relationships are noted: nesting for objects inside of other objects but not subtracted from them, assemblies, where multiple parts are composed into a higher-level part such as steel parts or a wall with doors and windows, and connections that are a three piece relation between two parts and their connection objects, which carries special properties not noted elsewhere. Almost all objects will have the standard metaproperties of writer, version, and timestamp, except possibly for complex property objects. Status data will be associated with certain objects to track progress. Finally, the EO property sets identify the different types of properties that are anticipated for the functions of the associated EO types. There may be several of these for each object, required or not in different contexts Fig. 9. The purpose of the use cases and information exchange documentation is to provide a functional specification that is adequate to specify the semantic characteristics of the product data model entities needed at the view implementation level. Once these semantics have been specified in the IDM, all later aspects of the implementation specification and the implementation itself can be validated against the criteria defined within the IDM. In this way, much of the success or failure of the MVD stage can be determined by reference back to the IDM. JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010 / 31

8 Information Exchange Object Type Obj Required/ Optional (R/O) As Cast /Deformed (C/D) Geometric Meta Surface Type Accuracy Relations Functionality data Viewable Referenceable Volume & clash Check Editable Faceted Meshed 3 rd Order Surfaces Splines High (< 1mm) Regular (~ 5mm) Low (> 7 mm) Nested Assemblies Connections Author, version, Status/approvals Properties and Property-Sets Project/ Project EO_Project Building Building EO_Building Building Stories EO_Story Building(s) Grid Layout EO_Grid Main structural members:, EO-Building_System Columns + Beams + Foundations + Slabs + Bracing + Architectural Precast Elements Secondary structural members for supporting architectural precast panels Other façade systems that join with architectural precast Other systems that connect to or are supported by architectural precast Architectural : Façade Assemblies Walls Column Covers Spandrels Copings, EO-Building_System EO-Building_System EO-Building_System EO-Façadel EO-Precast_Piece EO-Precast_Piece EO-Precast_Spandrel EO-Concrete_Coping Fig. 8. Detail page of the EM.1 EM definition body EM.1 Concept Model EO Class attributes Properties and.. Property-Sets EO_Project EO_Building EO_Story EO_Grid EO_Building_System Functional type, geometry, attribute, relation and behavior class values, as defined in Section 2 and shown in Fig. 8. EO_Project Functional Semantics EO_Building Relations Functional Semantics Properties Relations and P-sets EO_Story Properties Functional andsemantics P-sets EO_Grid Relations Functional Semantics Properties and P-sets Relations Properties and P-sets EO schema mappings must meet the requirements set by the EO class attributes Fig. 9. Characterization of an EM, defining the set of EOs involved in a particular class of exchange Exchange Objects, Exchange Models, and Mappings to Product Model Schema The initial task is to define the EMs for all the use case exchanges in an IDM using templates such as that shown in Fig. 8 in terms of their constituent EOs. Note that each EO can have multiple configurations, because of the different levels of detail needed for different process stages, which is expressed through the different EMs. For example, it may be sufficient to exchange an extruded solid shape for a precast concrete beam at the early stages, while the detailed geometric features along its length must also be exchanged in later project stages. This means that each EO may have more than one mapping, as shown in Fig. 10. However, considerable economy can be achieved if the EOs including their detailed software mappings into MVD components can be reused. This is possible wherever EO definitions are similar, or where they can made to conform to one another. EM.2 Contract Model EO Class attributes Properties and.. Property-Sets EM.1 Concept Model EO Class attributes Properties and.. Property-Sets EM.6 Fabrication Model EO Class attributes Properties and.. Property-Sets Functional Semantics Relations Functional Semantics Properties and P-sets Relations Functional Properties Semantics and P-sets Relations Properties and P-sets Multiple mappings for an EO according to theemuse cases it serves. Some of these can be rationalized to reduce their number. Fig. 10. Different EM views for a particular EO 32 / JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010

9 In Fig. 10, the different functional needs for a single EO are shown together, defining what semantic conditions, properties and relations are needed in the different object model exchanges. This view is helpful for MVD specification and implementation, because many of the same EOs are defined in different EMs. Some exchanges can use a mapping already defined for an EO, while others have different requirements with regard to geometry, attributes, and relations. The grouping of mappings for an EO can be compared and harmonized when the data from them is organized as it is in Fig. 10. The final determination of how many different mapping variations must be implemented for an EO will depend on the use cases considered and the judgment of the MVD specifier. The next step is to define a mapping for each EO to a set of building product model schema objects, such as a set of IFC entities, including their relevant properties and the relationships between them. EOs are also called concepts. These coded mappings for the EOs are the basis for the MVDs; an MVD can be compiled for any EM largely by aggregating the software mappings for all of the EOs included in the EM. Note that each EO can have multiple configurations, because of the different levels of detail needed for different process stages, which is expressed through the different EMs. For example, it may be sufficient to exchange an extruded solid shape for a precast concrete beam at the early stages, while the detailed geometric features along its length must also be exchanged in later project stages. This means that each EO may have more than one mapping, as shown in Fig. 10. However, considerable economy can be achieved if the EOs including their detailed software mappings into MVD components can be reused. This is possible wherever EO definitions are similar, or where they can made to conform to one another. In Fig. 10, the different functional needs for a single EO are shown together, defining what semantic conditions, properties and relations are needed in the different object model exchanges. This view is helpful for MVD specification and implementation, because many of the same EOs are defined in different EMs. Some exchanges can use a mapping already defined for an EO, while others have different requirements with regard to geometry, attributes, and relations. The grouping of mappings for an EO can be compared and harmonized when the data from them is organized as it is in Fig. 10. The final determination of how many different mapping variations must be implemented for an EO will depend on the use cases considered and the judgment of the MVD specifier. Later, when a specific MVD for a use case is completed, the organization coordinating the NBIMS development NIBS is tasked with presenting and releasing the MVD to the relevant software community for implementation. These steps are summarized in Fig. 1. The figure identifies additional activities after implementation. These include validation testing and the development of a user BIM guide for the domain covered, that will define how to properly create a building model capable of being correctly exported using the use cases specified GSA Conclusions The IFC standard building model schema provides a basis for achieving full interoperability between BIM tools. But unless the specific contents and details are defined for each use case for construction project workflows, the breadth and flexibility of the IFC schema leaves room for software vendors to program translators that do not result in effective exchanges. The NBIMS attempts to resolve the ambiguities of information exchange by defining use cases with precise workflow specifications. The basic approach calls for the development of functional specifications or exchange requirements defined by end users in an IDM. These are then mapped to MVDs by IT experts. As a result of our early experience in carrying out the IDM development, and anticipating the later MVD specification, we have added additional levels of specificity to the IDM object-level exchange definitions. This has been driven by the need to validate later steps, at the MVD and translator implementation stages. The basis for such validation comes from the original user need and intended use. If these are not captured initially, they will either be dealt with in ad hoc fashion later, or require iterated reviews by end-users throughout the MVD definition. Instead, we have developed methods to capture detailed level information requirements from end users at the IDM phase of specification, so that all later stages may refer to the specifications for guidance. We have presented examples of the documentation, addressing the domain of architectural precast concrete. Tables define each use case within the processes; other tables define the information exchanges required for the use cases. The writers have developed more detailed objectives for defining the IDM documentation for workflow use cases. We believe this detailed level of specification will allow precise implementations for complex objects that are reliable and foolproof that would not be reliably achieved otherwise. The expected eventual outcome of the architectural precast use case study and implementation will be a MVD that fully addresses the information exchange needs between four primary actors: architect, precast contractor, general contractor, and structural engineer, who deal with architectural precast issues. Other actors, such as rebar and mesh fabricators, concrete mix plants, and precast erection firms, may be addressed in later use case efforts. These use cases, specified in the IDMs, will allow specification of a set of MVDs that are expected to define complete and robust data exchange requirements that can be implemented by software vendors whose BIM tools support the representation of architectural precast products. Our goal is to anticipate issues of MVD specification early in the IDM so that iterated referral back to users is minimized. With validation and certification testing, the exchange implementation of software vendors should be reliable out of the box without the need for testing and debugging, allowing reduced exchange cycles and leaner practices to emerge. The expectation that there will be many different use cases possibly several hundred has raised concerns. On the user side, it means that the intention of each use case is easily understood, within the context of the whole set. The expectation is that IFC export and import would involve a submenu allowing user selection from among the supported use cases for that BIM tool. The NIBS, overseeing the NBIMS effort, has plans to publicly document all use cases. For companies that develop BIM software tools, the existence of many functionally distinct use cases leads to the potential need for possibly hundreds of distinct translators. This seems unnecessary. At the least, it is expected that the EOs used in the process described here will overlap with one another at the implementation level and can be supported by a single set of IFC entities. Possibly, EOs, as defined here, will provide libraries facilitating translator implementation. In the longer term, it is expected that IFC translator implementations will become tunable, allowing export and import of targeted entities only. At least one imple- JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010 / 33

10 mentation of IFC export has this capability already. This targeting may have table driven setups, which would tie in directly to use case specifications. In the end, robust and correct use case definitions do not guarantee success for building information exchanges, unless the model instances are defined by users in the manner expected by the object-based translation scheme. The quality of translation will depend greatly on the naturalness of the methods required to construct a translatable building model and whether the requirements for one use case are consistent, at the building model level, with others used in the same project. These issues become apparent when the BIM application s user guides are examined for compatibility. These are second order issues that domain interest groups will have to address. Acknowledgments The research reported in this paper was funded by the Charles Pankow Foundation. Advisory support was also provided by FI- ATECH and the National Institute of Building Sciences. References Björk, B.-C Requirements and information structures for building product models. Technical Rep. 245, VTT Technical Research Centre of Finland, Espoo, Finland. BPMN Business process modeling notation BPMN Version Oct. 30, BuildingSMART BuildingSMART, projects.htm Oct. 30, Crowley, A. J., and Watson, A. S Representing engineering information for constructional steelwork. Comput. Aided Civ. Infrastruct. Eng., 12 1, Crowley, A. J., and Watson, A. S CIMsteel integration standards release 2: Overview, Steel Construction Institute, London. Duvall, M., and Bartholomew, D PLM: Boeing s dream, Airbus nightmare. Baseline: The project management center, Airbus-Nightmare/ Oct. 30, Eastman, C Building product models: Computer environments supporting design and construction, CRC, Boca Raton, Fla. Eastman, C., Teicholz, P., Sacks, R., and Liston, K BIM handbook: A guide to building information modeling for owners, managers, designers, engineers and contractors, Wiley, New York. Eastman, C., Wang, F., You, S.-J., and Yang, D Deployment of an AEC industry sector product model. Comput.-Aided Des., 37 11, Fowler, J STEP architecture and methodology, PDT Solutions, Bentham, U.K. Gallaher, M. P., O Connor, A. C., John, L., Dettbarn, J., and Gilday, L. T Cost analysis of inadequate interoperability in the U.S. capital facilities industry. Rep. No. NIST GCR , National Institute of Standards and Technology, U.S. Dept. of Commerce Technology Administration, Gaithersburg, Md. Garcia-Alonso, A. M., Serrano, N., and Flaqueer, J Solving the collision detection problem. IEEE Comput. Graphics Appl., 14 3, GSA GSA building information modeling guide series: 02-GSA BIM guide for spatial program validation. Oct. 30, Hietanen, J. 2006a. Information delivery manual guide to components and development methods, BuildingSMART, Oslo, Norway. Hietanen, J. 2006b. IFC model view definition format, International Alliance for Interoperability, MVD_060424/IAI_IFCModelViewDefinitionFormat.pdf Mar. 15, IAI IFC/ifcXML specifications, Oct. 30, ISO Industrial automation systems and integration Product data representation and exchange Part 11: Description methods: The EXPRESS language reference manual, ISO TC184/SC4, Oct. 30, ISO Guidelines for the development and approval of STEP application protocols. ISO TC184/SC4, Oct. 30, ISO Industrial automation systems and integration Product data representation and exchange Part 11: Description methods: The EXPRESS language reference manual. ISO TC184/SC4 webstore.ansi.org/ Oct. 30, Jeong, Y.-S., Eastman, C., Sacks, R., and Kaner, I Benchmark tests for BUM data exchanges of precast concrete. Autom. Constr. 18, Light, R., and Gossard, D Modification of geometric models through variational geometry. Comput.-Aided Des., 14 4, Lipman, R CIS/2 and IFC for structural steel. Building SMART day, presentation, Dec. 7, NIBS Oct. 30, NIBS United States national building information modeling standard version 1 Part 1: Overview, principles, and methodologies, Oct. 30, Omniclass Omniclass: A strategy for classifying the built environment, introduction, and user guide, 1.0 edition, Construction Specification Institute, Arlington, Va., Pratt, M Geometric methods for computer-aided design. Fundamental developments of computer-aided geometric modeling, L. Piegl, ed., Academic Press, London, Pratt, M Extension of ISO 10303, the STEP standard for the exchange of procedural shape models Int. Conf. on Shape Modeling and Applications (SMI 2004), IEEE Computer Society 2004, Genova, Italy. Rezayat, M Midsurface abstraction from 3D solid models: General theory and applications. Comput.-Aided Des., 28 11, Sacks, R., Kaner, I., Eastman, C., and Jeong, Y.-S The Rosewood experiment Building information modeling and interoperability for architectural precast facades. Autom. Constr., in press. Schenck, D. A., and Wilson, P. R Information modeling the EXPRESS way, Oxford University Press, New York. Tolman, F Product modeling standards for the building and construction industry: Past, present, and future. Autom. Constr., 8 3, Young, N Interoperability: A growing understanding and momentum. Proc., Interoperability Int. BuildingSmart Conf st/05 Norbert Youbd Oslo-Interoperability 1 Jun05.pdf Oct. 30, / JOURNAL OF COMPUTING IN CIVIL ENGINEERING ASCE / JANUARY/FEBRUARY 2010