Chapter 2 Discussion Questions
3.3 BACKGROUND OF PRODUCT DATA MODELS
3.3.5 IFC in Use
A typical data exchange scenario is shown in Figure 3 - 3 . A Source Application has modeled information to be used by a Receiving Application. The source application has a translator written for it that extracts information instances from the application ’ s native data structure and assigns them to appropriate IFC entity classes. The entity instance data are then mapped from the IFC objects into (in this case) a text fi le format defi ned by the ISO - STEP Part - 21.
This fi le is then received by the other application and interpreted by the Receiving Application ’ s translator in terms of the IFC object instances it
c03.indd 78
c03.indd 78 12/19/07 1:55:37 PM12/19/07 1:55:37 PM
represents. The translator in the Receiving Application writes the relevant IFC objects into its native data structure for use.
Different BIM tools have their own proprietary data structures for repre- senting a building and other design information. Some explicitly store proper- ties and relations, while others compute them on demand. They internally use different geometric representations. Thus, two building modeling tools can both have perfectly good IFC translators to export and import data, but may still be able to exchange very little useful data. The translator ’ s capabilities and object coverage are supposed to be defi ned in the translator ’ s documentation.
For these reasons, IFC model exchange currently needs careful initial testing to determine what information is carried by the exchanging applications.
IFC Viewers
A number of companies have developed geometry and geometry - and - properties viewers for IFC models. Most of these are freely available for downloading.
Available IFC Geometry and Property Viewers:
DDS IfcViewer, at: http://www.dds.no (free) IfcStoreyView, at: http://www.iai.fzk.de/ifc (free) IFC Engine Viewer, at: http://www.ifcviewer.com (free)
ISPRAS IFC/VRML Converter, at: http://www.ispras.ru/~ step (free) Octaga Modeler, at: http://www.octaga.com (commercial)
Solibri Model Viewer ™ , at: http://www.solibri.com/ (free)
FIGURE 3-3
A scenario of the most common type of IFC exchange between two applications.
Source Application
Receiving Application
Export Translator
Import Translator
Data Structure
P-21 Translator
Data Structure P-21
Translator
IFC Product Model
View
Data Exchange
Part 21
c03.indd 79
c03.indd 79 12/19/07 1:55:38 PM12/19/07 1:55:38 PM
Some viewers display the attributes of selected objects and provide means to turn on and off sets of entities. IFC viewers are useful for debugging IFC translators, and to verify what data has been translated.
IFC Views
Because of the variable representation of objects in IFC, two parallel and related efforts are being undertaken to defi ne IFC subsets more precisely. In both cases, data exchanges are prescribed in terms of particular tasks and workfl ows. The American effort is the National BIM Standard (NBIMS), initi- ated by the Facilities Information Council, an organization of US government procurement and facility management groups—within the Department of Defense—and administered through the National Institute of Building Sci- ences (NIBS). The European effort is being led by Norway, developing an Information Delivery Manual (IDM). Both of these efforts are directed toward specifying IFC Views—specifi c subsets of the IFC—to be used for specifi c workfl ow exchanges. Both groups rely on the buildingSMART ™ name, recently adopted by the IAI for promoting the IFC (IAI 2007).
In the USA, the plan for development and implementation of IFC Views is to encourage different business domains within the construction industry to identify data exchanges that, if automated, would provide high value payoffs.
These would be specifi ed at a functional level by the AEC business domain.
The assumption is that building associations, such as the American Institute of Architects, Associated General Contractors, Precast Concrete Institute, Port- land Cement Association, American Institute of Steel Construction and other institutions would represent the business domains. Once specifi ed, the business domain, working with the NIBS - buildingSMART ® organization, would fund information technology specialists to specify the IFC Views to be exchanged, and to develop the functional specifi cations. Last, NIBS - buildingSMART ® and the AEC domain will work with the BIM software tool developers to imple- ment the View translators. There is also discussion of certifi cation.
When these specifi c workfl ow - based translators are implemented, they will be explicitly incorporated into translators, based on either P - 21 fi les or database queries. Some views are being defi ned for one - way passing of a data- set, while others are anticipating multiple iterated exchanges, such as might be desired between a design and an analysis tool to allow interactive performance improvement of the design. These Views, when certifi ed, will add signifi cantly to the robustness of IFC exchanges and eliminate the need for pre - testing and exchanges, as is required today.
A possible example of a fi ne - grain workfl ow exchange is shown in Figure 3 - 4 , showing exchanges between building designers and structural engineers. Six
c03.indd 80
c03.indd 80 12/19/07 1:55:38 PM12/19/07 1:55:38 PM
information exchanges are detailed, denoted in the fi gure as (ST - 1) to ( ST - 6).
These include three iterated exchanges: (1) fi rst to lay out the structural sys- tem conceptually (ST - 1 and ST - 2); (2) the structural engineer undertaking iter- ated analyses to develop a good design based on the engineer ’ s knowledge of the project, (ST - 3 and ST - 4), and (3) exchanges between the designer and the structural engineer, coordinating details with the rest of the building systems and refl ecting design intent (ST - 5 and ST - 6). The structural engineer option- ally has two applications, a structural design application, such as Revit ® Structures, Bentley Structures or Tekla Structures, and a structural analysis application. In many cases (ST - 3) and (ST - 4) will be directly integrated through the applications ’ APIs. Of course, coverage of all relevant AEC domain exchanges will require defi nition of hundreds of workfl ows, each with different intent and data.
IFC Initiatives
At this point in time (2007) there are signifi cant efforts to apply the IFC in various parts of the world:
CORENET is driven by the Singaporean Building and Construction Authority in collaboration with other public and private organiza- tions. It is a major initiative to re - engineer the business processes of the construction industry to integrate the major processes of a build- ing project life cycle: supported by key infrastructures, supporting electronic submission and recording, checking and approval processes, communication methods for dealing with submittal, paperwork, and recording of the review, as well as documentation and training (CORENET 2007).
•
FIGURE 3-4 Example workfl ows between building designer and structural engineer.
Building Design
Building Design Development
Acquire Building Design
Define/Edit Structural Design
Analyze Structure Structural Design
Request for design information(ST-1) Candidate building design(ST-2)
Candidate structural design(ST-6) Revised building design(ST-5)
Send to structural analysis(ST-3) Return analysis results(ST-4) (Task transfer in same software)
c03.indd 81
c03.indd 81 12/19/07 1:55:39 PM12/19/07 1:55:39 PM
Australia is undertaking a similar effort as Singapore, under the trade- mark of DesignCheck ™ (Ding et al. 2006).
The International Code Council in the US has developed a plan that goes down a different path from the CORENET efforts, called SMARTcodes (ICC 2007).
The Norwegian government and construction industry are working together to initiate changes in their construction industry, including build- ing control (automatic code checking), planning (e - submission of building plans), and integration in design, procure, build, and facility management.
Their initiative is also called BuildingSmart ® and there are efforts to coor- dinate the two similarly named but different parallel efforts. The Nor- wegian one is expected to produce a signifi cant impact on the effi ciency, productivity and quality of the construction industry. See “ Industry Initia- tives and Norwegian Solution ” at http://www.iai - international.org/ . The General Services Administration of the US government has undertaken a series of BIM demonstration projects, addressing various applications, many relying on exchanges based on the IFC. These are described on the same IAI website above, under Industry Solutions, GSA Pilots.
Based on these demonstrations, all GSA building projects starting in 2007 are to utilize BIM design tools and use of an exported model in IFC format to support checking of the preliminary concept design against the specifi c project ’ s programmatic spatial requirements. This is the initial functional application of BIM being mandated in the US. Other mandated applications are in development. Further requirements will be introduced in succeeding years. These activities have led to the draft development of GSA BIM guidelines to be followed for all new GSA projects (GSA 2007).
Additional initiatives are being undertaken in Finland, Denmark, Germany, Korea, Japan, China and other countries.