Chapter 2 Discussion Questions
3.3 BACKGROUND OF PRODUCT DATA MODELS
3.3.5 IFC in Use—BIM Standards
As the AEC fi eld has matured, it has become recognized that the issue of inter- operability has moved from data exchange between two BIM applications to supporting the use cases defi ned by workfl ows. The major benefi ts of interop- erability are not only to automate an exchange (although replicating the data in another application is certainly redundant activity), but the larger benefi ts that refi ne workfl ows, eliminate steps, and improve processes. The new phrase is to better “manage lean workfl ows.”
ch003.indd Sec3:119
ch003.indd Sec3:119 3/8/11 6:09:24 PM3/8/11 6:09:24 PM
www.EngineeringBooksPdf.com
IFC, developed to respond to the different needs of designers, contractors, building product suppliers, fabricators, government offi cials, and others, is both rich and redundant. Its multiple types of geometry, many types of prop- erties and relations, are necessary to identify the information needed for par- ticular exchanges or tasks. Thus IFC is highly redundant. Task and workfl ow information requirements have become recognized as critical for successful exchanges. User interface buttons for “IFC export” and “IFC import” are completely insuffi cient. What is needed are task-related exchanges based on subsets of the IFC schema, for example, an “architect’s structural export for preliminary structural analysis” or a “curtain wall fabricator detail export to construction manager for fabrication-level coordination.” Such exchanges are called model views, drawing from the notion of a database view. This level of specifi city involves identifying the exchanges to be supported and then specify- ing the IFC model view of the information that the exchange needs.
Model views are another level of specifi cation, above the IFC schema.
Realizing this added layer of specifi cation in the United States has been taken on by the National Institute of Building Science (NIBS) and the U.S.
buildingSMART organization. Similar organizations have taken up the charge in other buildingSMART chapters (IAI 2010). The U.S. effort led to the devel- opment of a report: U.S. National Building Information Modeling Standard, Version 1, Part 1, released in December 2007 (NIBS 2008). It lays out a process to be followed in developing model views. This is characterized in Figure 3–7.
Why Are Model Views Important?
Whether carried out for public or proprietary exchanges, Model View Defi ni- tions (MVD) identify what should be expected for an exchange to be effective.
This helps the users at both ends; the exporter knows what is required—and also what is not required. The receiver knows what can be expected and acted upon. “Should the architect’s model of preliminary design of a precast concrete façade include the embedded window details?” “What kind of geometry is needed for exchanges when façade connections are defi ned by the structural or precast engineer?” Such questions are today worked out by trial and error.
Most importantly, model views defi ne for implementers what is to be imple- mented, so that both export and import are aligned, eliminating mismatches regarding assumptions. These are the immediate uses of MVDs. Today, the goal is to defi ne effective IFC exchanges, to smooth and expedite workfl ows.
When this happens, model views will take on expanded roles. There is both the need and opportunity to defi ne the handover specifi cations for different phases of project delivery, for example from design to construction, and for construc- tion to operation, such as defi ned by Construction Operations Building
ch003.indd Sec3:120
ch003.indd Sec3:120 3/8/11 6:09:24 PM3/8/11 6:09:24 PM
www.EngineeringBooksPdf.com
information exchange (COBie), see Section 3.4.3. These will evolve into fi ner- grain exchanges and become part of the defi nition of project scope. They are expected to be defi ned within contracts to specify milestone handovers. They will then need to be defi ned for direct exchange between applications as well and public data schema exchanges. The point is, MVDs respond to very impor- tant needs in building procurement, far beyond IFC interoperability.
Generic BIM Guide Product–Specific
BIM Guides BIM Creation BIM Exchange and
Data Validation BIM Data Reuse and Extention Model View Definition and Implementation Specifications
Facilitate SW Product Implementation and Certification Implementation in Software
Use in Industry Exchange Requirement
Models Generic Model View
Definition Standard Design Workgroup Formation
Process Map Exchange Requirements
and Business Rules Standard Requirements
Project Agreement Requirements
Products:
- Interest groups form, locate resources and/or define a new need.
- Process description, and - Required, optional and variable data required at each exchange as agreed by experienced subject–matter experts.
PROGRAMDESIGNCONSTRUCTDEPLOY
Products:
- Common grouping of date.
- Non–software–specific description of how data grouping to be managed by applications.
Products:
- Very specific association of data to specific version of IFC.
- NBIMS works with software vendors who implement technical exchange definition into their software, and - assist in getting software products tested.
Products:
- Individual parties to contracts agree on BIM function to be provided using BIM Guides that are not product–specific.
- Project parties create BIMs using Certufued software &
product-specific BIM Guides, content are checked using validation software.
- BIM construction and data content are checked using validation software.
- BIMs are used for many purposes by certified software.
National BIM Standard Interoperable Exchange Development and Use
FIGURE 3–7
This fi gure shows the four major steps for defi ning and implementing an NBIMS of Program, Design, Con- struct, and Deploy.
ch003.indd Sec3:121
ch003.indd Sec3:121 3/8/11 6:09:24 PM3/8/11 6:09:24 PM
www.EngineeringBooksPdf.com
In North America, it was recognized that industry-led efforts to defi ne workfl ows should be the driving force, as the industry stakeholders are who benefi t from improving IT and getting software companies to support them. The National BIM Standard (NIBS 2008) was developed by build- ingSMART America to identify the need and outline an approach to specify- ing and implementing MVDs. Below we provide an overview of the NBIMS process.
Phase One: Program
The initial step is to identify and form an industry-led group to defi ne the needed exchanges according to model views. These groups are usually formed under umbrella organizations, such as the American Institute of Archi- tects, the Association of General Contractors, American Society of Civil Engi- neers, the American Institute of Steel Construction, the Precast Concrete Institute, as well as others. This working group identifi es a set of exchanges they wish to see implemented, then specify them functionally in suffi cient detail for them to be translated into IFC constructs that can be implemented.
The buildingSMART organization has adopted a well-known process mod- eling language, BPMN, used in electronic e-business planning and implementa- tion, for modeling exchanges. Business Process Modeling Notation (BPMN, www.bpmn.org) provides clear ways to describe activities and the information fl ows between activities in what is called a Process Map. A process map show- ing a typical set of information exchanges is shown in Figure 3–8. It defi nes a set of tasks and exchanges specifi ed for handling an architectural precast concrete project, using IPD types of collaboration (Eastman et al. 2009). The following outlines some guidelines for reading a BPMN process map.
There are many BPMN diagramming tools; the one used in Figure 3–8 was made using Visio, which has a plug-in for BPMN shapes at the BPMN Web site, at www.bpmn.org/documents.htm. Alternatives to Visio are also listed there. The horizontal rows and the vertical columns in a BPMN process map are called “swim lanes.” The rows identify the “Disciplines” involved in the exchanges. In between the Discipline rows are “Exchange” rows. These organize and group exchanges between Disciplines. The vertical columns identify project Phases. Within the cells created by the swim lanes, white rec- tangles with rounded corners signify Activities. The appropriate Discipline’s row and project Phase column identifi es the context of the exchange. Each Activity has an identifi er, linked to a more extensive description. Within an Activity box, there may be several symbols across the bottom; a directed arc designates the Activity may be iterated. A plus box indicates the Activity is a high-level description made up of a set of Activities described separately and
ch003.indd Sec3:122
ch003.indd Sec3:122 3/8/11 6:09:25 PM3/8/11 6:09:25 PM
www.EngineeringBooksPdf.com
123
FIGURE 3–8 A process map of exchanges between architect, structural engineer, and precast fabricator during the design stages.(Eastman et al. 2009a)
Preliminary Project Description 31–20–10–00
Architecture (33–21–11–00)ExchangeExchangeExchangeBuilding Product Manufacturing (33–25 41 11 11)
General Contracting (33–41 11 11)Engineering (33–21 31 00)
[1.1]
Concept Design of Precast Facade
Concept model Review
Comments [EM.1]
[EM.1]
[EM.2] [EM.3] [EM.4]
[EM.5]
[EM.6] [EM.8]
[EM.7]
[B5]
[B4]
[B1] [B3]
[B2]
Review Comments Review
Comments
Review Comments Design
Dev.
Model
Eng.
Contract Model
Precast Contract Model
Review Comments
Precast Coordination
Model Merged
Coordination Model Precast
Coordination Model Design
Dev.
Model
Arch.
Contract Model Design Development
31–20–20–00
Construction Documentation 31–25–00–00
Procurement 31–30–00–00
Product Development 31–40–30–00
Fabrication 31–40–40–14–24
Erection Phase 31–40–40–14–11
[1.4]
Design Development
∼ ∼
∼ [1.2]
Specify structural
system
[1.5]
Specify Requirements
[1.3]
Design review and Concept Modeling
[1.5]
Construction Documentation
[1.8]
Precast Bid Preparation
[1.9]
GC Bid Preparation
[1.13]
Construction Coordination
[1.12]
Precast Detailing
[2]
Fabrication And Erection
Continued on the
“Fabrication and Erection”
process map [1.11]
Structural Design Review [1.6]
Construction Documentation
[1.10]
Design Intent Validation
Concept model
⫹
⫹
3/8/11 6:09:25 PM3/8/11 6:09:25 PM
www.EngineeringBooksPdf.com
hierarchically—BPMN provides hyperlinks between high-level and detail Activities. (The full graphic syntax of BPMN is available from www.bpmn.org/).
The corner folded blocks in the Exchange lanes designate Information Exchanges. The gray information exchanges are building model exchanges, while the white ones are reports represented as text or voice messages. These also have IDs for cross-referencing. It is a gray exchange that we are primarily interested in and they are called Exchange Models (EMs).
The process map shows several different types of exchanges. In the fi rst column, exchanges between architect, engineering, and building product man- ufacturing (here a precast fabricator) are shown. In both cases, the architect releases a BIM model for review by the engineer and the precast fabricator.
The return information involves comments and suggestions, based on the model reviewed. These are clearly one-way exchanges.
During design development, we see another exchange between the archi- tect and engineer. Here the exchange passes a building model in both direc- tions. The structural engineer may propose changes to the received building model to indicate how the architectural precast may be carried by the struc- ture. This is a two-way or iterative exchange.
For each of the EMs, the working group provides detail specifi cations of the content of each exchange. This functional specifi cation must deter- mine the type of entities, their geometry, attributes, level of detail, material or processes that are needed for passing from one application to another (Aram et al. 2010). The fi nal outcome of the Program Phase is a report, called an Information Delivery Manual (IDM) (Eastman et al. 2010a), that identifi es a set of exchanges and specifi es their content from the user’s perspective. The specifi cation is fully reviewed and approved by the domain committee.
Phase Two: Design
The Exchange Requirements identifi ed in the IDM are next structured into a set of information modules that are the units of the exchange, defi ned to be mapped to the implementation schema—IFC most commonly, or CIS/2 or an XML schema. The work is carried out by IT specialists who collaborated with the domain experts in Phase One.
When early groups began developing Model Views, it was found that they included many repeated model constructs, for geometry, links between parts and assemblies, between physical pieces and analytic representation of those pieces, for example. Repeated specifi cation, implementation, and testing of these constructs is a waste of time; they should be defi ned once and imple- mented and tested once, and reused. The constructs identifi ed in this way were called Concepts. Concepts are a fundamental part of the Model View
ch003.indd Sec3:124
ch003.indd Sec3:124 3/8/11 6:09:25 PM3/8/11 6:09:25 PM
www.EngineeringBooksPdf.com
methodology. They are a hierarchical structure of mappings from the user- defi ned Exchange Models, decomposed into modular units of implementation binding. An example is shown in Figure 3–9.
The Concept defi nitions defi ned for a wide variety of MVDs are shared through an open Web site, IFC Solutions Factory, at www.blis-project.org/IAI- MVD/. They are available for public review and, most importantly, for reuse.
These Concepts, if well-structured, are a potentially important modularization of small unit structures that can be reused in many MVDs (Eastman et al. 2010a).
< COVER PAGE
VIEW ID PCI–001
VIEW NAME Precast Concrete
APPLICATION NAME
com – IFC 2x4 Precast Piece
PCI–063 Element Attributes
VOL–170 GUID VOL–171 Name VOL–172 Description
PCI–067 Tag Property of the Piece is
used to store the Piece Mark attribute
Precast Piece Mark PCI–066
Precast General Attributes PCI–067
Precast Fabrication Attributes
PCI–069 Approval Assignment
PCI–066
Generic Brep Shape Geometry PCI–065
Extruded Geometry PCI–069
Arbitrary Precast Profile PCI–070
Arbitrary Precast Profile with Voids
VOL–206 Material Name
Cloud belong either to the building or the storey but not both
Cloud be relative to other element PCI–061
Precast Piece Material Association PCI–065
Actor Assignment
PCI–063 Relative Placement PCI–064 Absolute Placement PCI–062
Placement Relative to Grid PCI–090
Reinforcing Unit Association to Piece PCI–070
IOG–619
Generic Geometric Representation PCI–064
Element Type Assignment PCI–065
Precast Property Set Assignment
PCI–066
System Piece Aggregation VOL–200
Shape Representation
VOL–013
Owner and Status Information VOL–200
Generic Assignments
VOL–250 Generic Associations PCI–092
Precast Piece Containment VOL–201
Generic Object Placement
VOL–404 Generic Aggregation
Generic
APP.VERSION Generic
EXCHANGE TYPE Generic
DIAGRAM STATUS Draft
DIAGRAM VERSION 1
DIAGRAM DATE 9–Sep–09
DIAGRAM AUTHORS Rafael Sacks, Chuck Eastman
IFC Model View Definition Diagram : Precast Piece IFC 2x4
FIGURE 3–9 A high-level Concept that defi nes a Precast Piece, showing its breakdown into more detailed Concepts and eventu- ally to Leaf Concepts, which carry the IFC bindings.
(Eastman et al. 2010b)
ch003.indd Sec3:125
ch003.indd Sec3:125 3/8/11 6:09:26 PM3/8/11 6:09:26 PM
www.EngineeringBooksPdf.com
A well-structured set of templates have been developed for document- ing the Concepts and their aggregation into higher-level Concepts, then into a Model View for a single exchange. When the templates are fi lled out, the resulting online documentation serves as the specifi cation for the Model View Defi nition, which is the second major document (Eastman et al. 2010b). The MVD is the fulfi llment of the requirements defi ned in the IDM, and should be validated by checking its Concepts against the IDM. Currently, this validation is done manually. The Design Phase specifi es the implementation bindings and how all properties are to be handled, providing the software implementation specifi cation of a Model View Defi nition.
Phase Three: Construct
The third phase addresses the implementation of the Model Views by software companies (who should be engaged throughout the previous phases). Imple- mentation is of the MVD specifi cation developed in Phase Two. It is augmented by small IFC test fi les which are available to test translator capabilities. It also needs to be augmented by small, easily implemented designs—in drawing or 3D model form—that can be built within a modeling tool being validated, so that can then be exported. The exported fi le is assessed to determine if the modeling tool can export information according to the MVD specifi cation.
These tests, for both import and export, need to cover all the individual varia- tions that are included in the IDM, and specifi ed in the MVD.
Testing of implementations is undertaken in two phases and is generally called Model View Validation. The initial tests are based on the implementa- tion Concepts defi ned in the MVD and are called Unit Tests. These are tested for both import and export, for all the varied conditions that the MVD is supposed to support. Once the Unit Tests are successfully completed, larger integrated testing is required. Careful methods of both unit testing and full exchange model testing are required to be confi dent in the capability of an Exchange Model between two software applications. Certifi cation is the for- mal designation that an implementation of a Model View Defi nition has been rigorously tested and can be relied upon by users.
Recently, two initiatives for Model View Validation and Certifi cation has been implemented as Web sites by the buildingSMART International Implementation Support Group (ISG). One is the Global Testing Documen- tation Server and is hosted by the Institute for Advanced Building Informatics (IABI) at Technical University, Munich (http://portal.bau.hm.edu/IABI/
leistungsprofi l/testplattform). It supports both import and export testing of Concepts and complete Model Views. It is expected to serve as a validation and certifi cation test site for developers, and also be accessible to users. The
ch003.indd Sec3:126
ch003.indd Sec3:126 3/8/11 6:09:26 PM3/8/11 6:09:26 PM
www.EngineeringBooksPdf.com
other is part of IFC Solutions Factory (www.blis-project.org/IAI-MVD/). It provides testing primarily of export exchanges and has rigorous testing of export translators.
Phase Four: Deploy
The last phase involves deployment and fi eld use of the MVD. This should be supported by Guidelines that document the model views and how the user should correctly model its components within a particular BIM tool. This lets the users of applications know what they need to do to prepare models that carry the information required in the exchange. This phase also includes the development of project test models that can be used for real-life testing. Certi- fi cation of implementations is also called for, although the organizational issue of who oversees certifi cation is unanswered at this time.
When these specifi c workfl ow-based translators are implemented, they will be explicitly incorporated into translators, based on P-21 fi les, XML, or database queries. These Views, when certifi ed, will add signifi cantly to the robustness of IFC exchanges and eliminate the need for pretesting and trial exchanges, as are required today.
The IFC Solutions Factory identifi es 23 efforts to defi ne MVDs, as of April, 2010. These include structural analysis exchange, transfer of as-built data to facility operations site planning, code compliance, quantity takeoffs, and others.
The development and testing of Model View Defi nitions has been a large under- taking and we are only beginning to see the fruits of these endeavors. An impor- tant benefi t of the IFC Solutions Factory is that new MVDs can increasingly reuse the Concepts of previous MVDs for their defi nition. Also, the modulariza- tion of MVD implementations could also eventually result in easy implementa- tion as well. We expect there will be several dozen MVDs from which to choose within the selection window of BIM platform software in the future.
Summary
At this point in time (mid-2010) there are signifi cant efforts to apply the IFC in various parts of the world:
Multiple agencies around the world have initiated efforts to develop automatic building code checking capabilities (Eastman et al. 2009a).
The Norwegian government agency for construction, Statsbygg, and its construction industry are working together to initiate changes in their construction industry, including building control (automatic code checking), planning (e-submission of building plans), and integration throughout all phases: design, procure, build, and facility management.
•
•
ch003.indd Sec3:127
ch003.indd Sec3:127 3/8/11 6:09:26 PM3/8/11 6:09:26 PM