INTRODUCING A NEW METHODOLOGY TO DEVELOP THE INFORMATION DELIVERY MANUAL FOR AEC PROJECTS
Shiva (Vahideh) Aram, PhD Candidate,
Charles Eastman, Professor,
Georgia Institute of Technology, Atlanta, USA
Rafael Sacks, Associate Professor,
Technion – Israel Institute of Technology, ISRAEL
Ivan Panushev, Research Scientist,
Manu Venugopal, PhD Candidate ,
Georgia Institute of Technology, Atlanta, USA
The Industry Foundation Classes (IFC) create a neutral environment for interoperability by providing a comprehensive specification of the information throughout the AEC/FM project lifecycle, globally, across disciplines and software applications. However, the IFC schema does not capture the ways in which information is created and shared by practitioners; and the lack of specific definition of users’ exchange requirements has made it difficult to implement IFC compliant software solutions. The Information Delivery Manual (IDM) responds to these problems by proposing a methodology that captures business processes in AEC/FM projects and developing specifications of detailed user information exchange requirements. A progressive methodology to develop IDMs is presented in this paper. In this method Exchange Models (EMs) are utilized to provide the content of information exchange between users and/or software applications. Exchange Objects (EOs) are introduced as the fundamental elements in an exchange model, which contain the description of information units in non-technical terms that need to be exchanged in an exchange model. EOs are then developed further to provide the detailed technical attributes of the information categories in exchange models. EOs may be used in several exchange requirement definitions. Therefore, they are defined to be reusable within many exchange models. The level of detail and precision, and the representation type of EOs may vary in exchange models in different stages of the project lifecycle and are determined based on the business rules and with participation of industry experts. The details of the information capture to develop the IDM such that the IFC schema can be applied in national, local, or even project contexts are further illustrated. The paper finally presents the application of the introduced approach, using examples of architectural and structural precast concrete as a test base.
Industry Foundation Classes (IFC), Information Delivery Manual (IDM), Model View Definitions (MVDs), Interoperability, Building Information Modeling (BIM)
The main objective of several national BIM efforts and standards is to improve the information technology comprehension and implementation in AEC/FM industry to transform industry supply chains through interoperable information exchange (NIBS 2008). The Industry Foundation Classes (IFC) define a neutral environment for interoperability by providing a comprehensive specification of the information throughout the AEC/FM project lifecycle, globally, across disciplines, and software applications. Interoperability enhancement
requires common understanding of industry processes and the information required for and resulting from executing these processes (Wix, Nisbet, and Liebich 2009).
However, the IFC schema does not capture the ways in which information is created and shared by practitioners. Implementation of IFC compliant software solutions is hampered by the lack of specific exchange requirement definitions by users. This paper is inspired by the PCI NBIMS project that aims at implementing IFC based interoperability solution for architectural and structural precast concrete. The project team’s role was to technically facilitate the precast concrete information exchange standard development. Based on this project a National BIM Standard, for precast concrete design, engineering, fabrication, and erection, was developed (Eastman et al. 2010a).
IFC based information sharing tools need to be capable of securely and reliably exchanging accurate and appropriate data for specific purposes. To achieve this goal the first step is to capture the deployment information of exchange requirements. Then, one must develop an IFC based technical solution to satisfactorily meet those requirements and finally, it is necessary to deploy the technical solution (Hietanen 2006).
Usually each IFC implementation and development project focuses on a small subset of the IFC schema based on the user oriented “use cases”. Usually use case definitions are the first step of model specifications and are developed on the basis of business processes and related Exchange Requirements (ER) based on the value chain of the end user (Weise, Liebech, and Wix 2009). This process is accomplished through a progressive method to develop Information Delivery Manual (IDM), presented in this paper. In this method, Exchange Models (EMs) are utilized to provide the content of information exchanges between users and/or software applications. Then Exchange Objects (EOs) are introduced as the fundamental reusable elements in an exchange model, which contain the descriptions of information units that need to be exchanged in non-technical terms in an exchange model.
In this paper, we focus on the user requirements stage, as defined in the IDM. In the next step and through IFC Model View Definitions (MVDs), subsets of the IFC Model Specification required for IFC implementation of exchange models in software applications are defined. Therefore, MVD development efforts aim to providing an unambiguous guidance for implementation of IFC as a technical solution for interoperability needs in specific use cases.
2. INFORMATION DELIVERY MANUAL (IDM)
To facilitate interoperability in the AEC/FM industry, product data standards like IFC and CIS/2 have been developed. The IFC model specification is the most comprehensive data model with an object oriented data-schema that provides support for collecting data from a project model in a neutral computer language and representing shared information in a wide range of AEC/FM industry processes (Froese et al. 1999). The data sets’ definitions and rules embedded in the IFC data model provide the basis for developing IFC interfaces for software platforms, which enable sharing data between software applications with different internal data structures (NIBS 2008).
IFC implementations enable users to access the highly structured and attributed object model data used in Building Information Modeling using an application programming interface (API) according to their predefined rights. However, the IFC schema does not define the information exchange requirements specific to different project stages and between different project actors and software applications, which makes it difficult to develop useful IFC software interfaces. Accordingly, software developers and users demand IFC implementation guidelines that allow focusing on use cases of interest and guarantee compatibility with other software implementations. Development of the IDMs and MVDs has been a significant initiative to solve this problem by identifying the subset of IFC data model needed to support the user defined business processes (Wix, Nisbet, and Liebich 2009).
The main purpose of developing IDM and MVD is to define the specifications for mapping the information exchange with the IFC model objects for implementation in software interfaces. Then business rules are defined for these business processes. IFC implementation mainly includes deciding about use cases that should be supported in a specific project and thus needs substantial knowledge about the BIM tools that shall be used in the
projects and their current IFC capabilities (Bazjanac 2002). IFC development efforts incorporate requirements defined by industry experts.
The IDM framework that we have incorporated in this project is different in some aspects from some European efforts. The IDM guide developed by buildingSMART, Norway (BuildingSMART 2006) and some other European IFC deployment guides have expanded the scope of IDM to all the IFC deployment activities from defining process maps to developing IFC concept bindings. So the boundary between IDM and MVD development is blurred. On the other hand, some IFC deployment guides (Hietanen 2006) have considered the distinction between these two. The second approach views IDM as a method to identify the user exchange requirements during different processes with specific purposes. And the task of mapping these information exchange requirements with particular IFC releases is passed to MVD development stage. This approach clarifies the interface between IDM and MVD and makes it simpler to apply the whole IDM/MVD methodology. It provides a more effective way to communicate the exchange requirements to industry experts at the IDM level and to software developers at the MVD level.
Considering all these advantages, we have applied the latter methodology in the current project, distinguishing the scope, purpose, and outcome of IDM and MVD development processes. Thereby, IDM is applied exclusively as an information exchange requirement definition process and MVD as an IFC based technical solutions development process. Therefore, the final outcome of an IDM is a set of IFC independent information items defined for different Exchange Models (EM). Each of these information items, which are called Exchange Objects (EOs), can then be reused in several EMs and their functionality in each EM is illustrated by specified business rules and level of detail.
Facilitating the integration and collaboration between different disciplines involved in an AEC/FM project is one of the major focuses of BIM. In fact there is a close interaction between the BIM value proposition in projects and degree of workflow integration and continuity of information flow through project lifecycle. Hence, BIM aims to eliminate the non-value adding or lower value adding activities, to integrate the high value adding but fragmented tasks and to improve the automation of processes and the project performance in terms of project time and cost. To achieve these goals the first step is to determine the information value chain throughout projects and identify the inefficiencies of current practices. This will enable an enterprise systems analysis and devising alternative processes that streamline the information exchanges and enhance the information value gained by different project activities. The processes, actors, and information flow that are aimed to be supported by BIM tools are defined by Process Maps (PM) (Weise, Liebech, and Wix 2009).
The Business Process Modeling Notation (BPMN) is a standard for expressing process maps which are flow-oriented representations of business operations (Ouyang et al. 2009). In BPMN, developed by Object Management Group (OMG), the useful ideas of previous process modeling notations like IDEF0 (ISO10303) and the activity diagrams component of the Unified Modeling Notation (UML) have been incorporated (OMG 2005). BPMN models have been mainly used to facilitate information exchange and communication between project participants and to aid with decision-making based on various analysis techniques. However, detailed BPMN models are increasingly used as maps to identify the information packages exchanged in business processes and so to define required software features in systems development efforts (Ouyang et al. 2009).
The main components of process models developed by using BPMN are (i) flow objects, representing activities, decision-making gateways, or business events which differentiate different triggers or results, and (ii) connecting objects capturing either the message flow between activities that are carried out as a result of activities or the logical sequence of activities (OMG 2005). BPMN uses swimlanes to categorize activities with different functional objectives or capabilities (White 2004). Some swimlanes contain the exchange requirements of a data source that may be carried either by a BIM tool in the form of a model – called Exchange Models (EMs) in our method – or other non-BIM forms of information exchange, for example, informal comments on the architectural design by structural engineer. Exchange Models (EMs) are utilized to provide the content of information exchanges between users and/or software applications. Further, in order to provide appropriate level of detail,
tasks may be broken down into sub-processes that may be executed multiple times concurrently (Weise, Liebech, and Wix 2009).
In the PCI NBIMS project, that we are going to discuss in this paper, mapping processes using BPMN was the first step in developing an Information Delivery Manual (IDM). BPMN models were useful for identifying the Exchange Models (EMs) in precast concrete projects and provide a base to later identify the content of each information exchange package in the IDM.
A Use Case
Figure 1: Example of BPMN and a use case
2.2.Use Case Approach
The main building blocks of process maps are called “use cases”. They define information exchanges between any two actors in a project aimed at achieving a specific goal, within a specified phase of a project’s lifecycle. Hence, use cases provide detailed description of the content of the information exchanges. Defining use cases is the first step of determining model specifications, and thereby needs special attention in IFC based software interface development efforts.
A particular use case can depict a singular information exchange or a set of iterated exchanges that are illustrated by a loop sign as shown in Figure 1. Use cases are usually part of a greater network of information exchanges and collaborations throughout the project stages and between different project actors that provide the comprehensive process maps of a project (Eastman et al, 2010b).
Developing and implementing standardized information exchanges across industry domains can support vigorous data sharing throughout the information value chains of the industry. While interoperability tools like IFC are international mechanisms to share data, the required data to be shared is different in various localities (NIBS 2008). Defining the content of the information exchanges for each use case, known as Exchange Requirements, is a process based on the involvement of industry experts. This way Exchange Requirements reflect the local processes and legal and contractual obligations. Therefore, it is important that internationally applicable solutions strongly support the specific local applications (Hietanen 2006). Moreover, business requirements should be defined in a way that demand improvements in the status quo and aim to optimize current information sharing thereby initiating further IFC developments (Weise, Liebech, and Wix 2009).
Because of the diverse localities and need for customization of business processes, there is no single process map structure that can represent the entire AEC/FM industry spectrum. Usually there are various ways to compose use cases to achieve similar final purposes (Eastman et al, 2010b). However, some use cases may not be implemented in specific sub-domains of the industry or new use cases may be added for specific purposes.
Therefore, in designing the IDM it is important to identify the best practices across the industry and focus efforts on developing interoperability tools that support (and possibly advance) these best practices.
The result of the process modeling stage is the definition of a set of exchanges needed to support some business activity or domain, characterized by one or a set of use cases between two actors or roles and different stages in the project delivery lifecycle. The next step after identifying the use-cases is to define the information exchange content. As with developing the BPMN, the active involvement of industry experts is necessary in defining the sets of information required for each exchange.
Over multiple iterations, working on two different domains, we have tentatively developed a template to capture the information needed to support the user specification of an information exchange. The exchange model content template and an example are provided in Figure 2 and 3.
|Figure 2: Exchange model content template (Eastman et al. 2009)
|What is the Omniclass design stage?
|Who are the parties to this exchange?
By Omniclass discipline number and name?
(can be >2 disciplines, but using the same basic data.)
|Verbal description of:
1. The purpose of the exchange
2. The required contents of the exchange
3. The optional contents of the exchange
4. Example software in the exchange
5. Whether the exchanges are round trip or one-way
|Related Exchange Models
|Other exchanges this one interacts with (proceeding and succeeding exchanges)
via www.4clicks.com – Premier cost estimating and project management software for JOC, IPD, SABER, SATOC, MATOC, MACC, IDIQ, POCA, BOA.