Chapter 2 Discussion Questions
3.3 BACKGROUND OF PRODUCT DATA MODELS
3.3.3 What Are the IFC s?
The Industry Foundation Classes (IFC) was developed to create a large set of consistent data representations of building information for exchange between AEC software applications. It relies on the ISO - STEP EXPRESS language and concepts for its defi nition, with a few minor restrictions on the language. While most of the other ISO - STEP efforts focused on detailed software exchanges within specifi c engineering domains, it was thought that in the building industry this would lead to piecemeal results and a set of incompatible standards. Instead, IFC was designed as an extensible ‘ framework model .’ That is, its initial develop- ers intended it to provide broad general defi nitions of objects and data from which more detailed and task - specifi c models supporting particular workfl ow exchanges could be defi ned. This is characterized in Figure 3 - 1 . In this regard, IFC has been designed to address all building information, over the whole building lifecycle, from feasibility and planning, through design (including analysis and simulation), construction, to occupancy and operation (Khemlani 2004).
•
•
•
❍
❍
•
•
•
•
•
•
•
c03.indd 73
c03.indd 73 12/19/07 1:55:34 PM12/19/07 1:55:34 PM
As of 2007, the current release of the IFC is Version 2x3. It is available for review at: http://www.iai - international.org/Model/IFC(ifcXML)Specs.html .
All objects in EXPRESS are called entities. The conceptual organization of IFC entities is diagrammed in Figure 3 - 2 . At the bottom are twenty - six sets of base entities, defi ning the base reusable constructs, such as Geometry, Topology, Materials, Measurements, Actors, Roles, Presentations and Proper- ties. These are generic for all types of products and are largely consistent with ISO - STEP Resources, but with minor extensions.
The base entities are then composed to defi ne commonly used objects in AEC, termed Shared Objects in IFC model. These include building elements, such as generic walls, fl oors, structural elements, building service elements, proc- ess elements, management elements, and generic features. Because IFC is defi ned as an extensible data model and is object - oriented, the base entities can be elabo- rated and specialized by subtyping * to make any number of sub - entities.
The top - level of the IFC data model are the domain - specifi c extensions.
These deal with different specifi c entities needed for a particular use. Thus
FIGURE 3-1 IFCs consists of a library of object and property defi nitions that can be used to represent a building project and support use of that building information for particular use.
The fi gure shows three examples of specifi c domain uses from a single IFC project:
(A) An architectural view, (B) a mechanical system view, and (C) a structural view. Also shown are (D) a sample IFC object or entity and sample properties and attributes.
*Subtyping provides for defi ning a new class of building object that ‘inherits’ the properties of its ‘parent’ class and adds new properties that make it distinct from its parent and any possible
‘sibling’ classes. IFC superclasses, subclasses and inheritance behavior conform to accepted principles of object-oriented analysis. For more detail, see (Booch 1993).
c03.indd 74
c03.indd 74 12/19/07 1:55:35 PM12/19/07 1:55:35 PM
there are Structural Elements and Structural Analysis extensions, Architec- tural, Electrical, HVAC, Building Control element extensions.
Each of the geometric shapes in the system architecture diagram in Figure 3 - 2 identifi es a set of EXPRESS language entities, enumerations, and types.
The architecture thus provides a type of indexing system into the IFC model, which is also defi ned in EXPRESS. The IFC model is quite large and still grow- ing. As of the current release 2x3, there are 383 Kernel - level entities, 150 shared entities in the middle level, and 114 domain - specifi c entities in the top level.
Given the IFC hierarchical object subtyping structure, the objects used in exchanges are nested within a deep sub - entity tree. For example, a wall entity has a trace down the tree:
IfcRoot → IfcObjectDefi nition → IfcProduct → IfcElement → IfcBuildingElement → IfcWall
FIGURE 3-2 The system architecture of IFC subschemas.
Each Resource and Core subschema has a structure of entities for defi ning models, specifi ed at the Interoperability and Domain Layers.
Adapted from IAI international IFC/ifcXML online specifi cations for IFC2x Edition 3 at http://
www.iai-international.org/
Model/R2x3_fi nal/index.
htm.
Resource Layer (base entitites)
Core Layer Interoperability Layer
Domain Layer (domains)
White entity sets are IFC2x2 platform -IFC2x part equal to
ISO/PAS 16739 Shared Building Services Elements
Building Controls
Plumbing Fire Protection
Structural Elements
Structural Analysis
HVAC Electrical Architecture Construction Management
Facilities Management
gray entity sets are non-platform parts Shared component
elements
Shared Building Elements
Shared Management Elements
Shared Facilities Elements
Control Extension
Product Extension
Process Extension
Kernel
Material
Property Actor DateTime External
Reference Geometric Constraint
Geometric
Model Geometry Material Measure Cost
Presentation Dimension
Presentation Apearance
Presentation Definition
Presentation
Organization Presentation Time
Series Constraint Approval Structural Profile Property Profile Property Quantity Representation Topology Utility
c03.indd 75
c03.indd 75 12/19/07 1:55:36 PM12/19/07 1:55:36 PM
Each level of the tree introduces different attributes and relations to the wall entity. IfcRoot assigns a Global ID and other identifi er information. IfcOb- jectDefi nition optionally places the wall as part of a more aggregate assembly, and also identifi es the components of the wall, if these are defi ned. IfcProduct defi nes the location of the wall and its shape. IfcElement carries the relation- ship of this element with others, such as wall bounding relationships, and also the spaces (including exterior space) that the wall separates. It also carries any openings within the wall and optionally their fi lling by doors or windows. Many of these attributes and relations are optional, allowing implementers to exclude some of the information from their export routines.
Products, including walls, may have multiple shape representations, depending upon their intended uses. Within the IFC, almost all objects are within a composition hierarchy defi ned by IfcObjectDefi nition ; that is, they are both part of a composition and have their own components. IFC also has a general purpose IfcRelation , which has different kinds of relations as subtypes, one of which is IfcRelConnects , which in turn has the subclass IfcRel- ConnectswithRealizing that is used to reference wall connections. This one example indicates the extensiveness of the IFC model. This type of approach is followed for all IFC modeled objects.