Chapter 2 Discussion Questions
3.3 BACKGROUND OF PRODUCT DATA MODELS
3.3.3 What Is the IFC?
The Industry Foundation Class (IFC) is a schema developed to defi ne an exten- sible 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 EXPRESS 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 developers intended it to provide broad, gen- eral defi nitions of objects and data from which more detailed and task-specifi c models supporting particular exchanges could be defi ned. In this regard, the 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 building operation (Khemlani 2004). Several of the case studies show different uses of IFC, par- ticularly the Helsinki Music Hall and the Crusell Bridge (see Chapter 9). Because of its growing role in AEC interoperability, we describe it here in some detail.
A small example of this breadth is shown in Figure 3–4.
As of 2010, a new version of the IFC has been released, Version 2x4. This release of IFC has about 800 entities (data objects), 358 property sets, and 121 data types. While these numbers indicate the complexity of IFC, they also refl ect the semantic richness of building information, addressing multiple different systems, refl ecting the needs of different applications, ranging from energy analysis and cost estimation to material tracking and scheduling. Interfaces based on it are currently being implemented by the major BIM design tool and platform software companies, replacing the older 2x3 version. It is available for review at: www.iai-tech.org/products/ifc_specifi cation/ifc-releases/summary.
The conceptual organization of IFC can be considered in several ways. A system architecture perspective is diagrammed in Figure 3–5. At the bottom are 26 sets of base EXPRESS defi nitions, defi ning the base reusable constructs, such as Geometry, Topology, Materials, Measurements, Actors, Roles, Presentations,
ch003.indd Sec3:114
ch003.indd Sec3:114 3/8/11 6:09:15 PM3/8/11 6:09:15 PM
www.EngineeringBooksPdf.com
FIGURE 3–4
IFCs consist of a library of object and property defi ni- tions that can be used to represent a building project and support use of that building information for a particular purpose.
The fi gure shows three examples of specifi c domain uses from a single IFC project: (A) An architec- tural view, (B) a mechani- cal system view, and (C) a structural view. Also shown are (D) a sample IFC object or entity and sample prop- erties and attributes.
Domain Layer (domains)
Interoperability Layer
Core Layer
Resource Layer (base entities)
Building Controls
HVAC
Shared Building
Services Elements Shared component Elements
Control Extension
Product Extension
Process Extension
Kernel
Material
Property Actor DateTime
Profile
Presentation Dimension
Presentation Appearance
Presentation Definition
Presentation
organization Presentation Time Series Constraints Approval Structural Profiles Property Property Quantity Representa-
tion Topology Utility
External Reference
Geometric Constraint
Geometric
Model Geometry Material Measure Cost
gray entity sets are non–platform parts Shared Building
Elements
Shared Management
Elements
Shared Facilities Elements Electrical Architecture Construction
Management
Facilities Management Plumbing
Fire Protection
Structural Elements
Structural Analysis
FIGURE 3–5
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 Interna- tional IFC/ifcXML online specifi cations for IFC2x Edition 4 at www.iai-tech .org/products/ifc_specifi cation/
ifc-releases/ifc2x4- release.
ch003.indd Sec3:115
ch003.indd Sec3:115 3/8/11 6:09:16 PM3/8/11 6:09:16 PM
www.EngineeringBooksPdf.com
and Properties. These are generic for all types of products and are largely con- sistent with ISO-STEP shared library Resources, with minor extensions.
The base entities are then composed to defi ne commonly used objects in AEC, termed Shared Objects in IFC. These include building elements, such as generic walls, fl oors, structural elements, building service elements, process 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 elaborated and specialized by subtyping1 to make any number of subentities.
At 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 there are Structural Elements and Structural Analysis Extensions, Architectural, Electrical, HVAC, and Building Control Element Extensions.
Because of the IFC hierarchical object subtyping structure, the objects used in exchanges are nested within a deep subentity defi nition tree. All physi- cal objects, process objects, actors, and other basic constructs are abstractly represented similarly, for example, a wall entity has a trace down the tree shown in Figure 3–6.
Each level of the tree in Figure 3–6, introduces different attributes and relations to the wall entity. IfcRoot assigns a Global ID and other information
Label Name Globalld
metadata
Composition structure:
wall layers, material properties OwnerHistory
(INV) IsDecomposed By S[0:?]
(INV) IsDefinedBy S[0:?]
(INV) ConnectedTo S[0:?]
(INV)HasCoverings S[0:?]
(INV)HasStructuralMember S[0:?]
(INV) Decomposes S[0:1]
(INV) hasAssociations S[0:?]
RelatingObject
RelatingElement S[0:?]
RelatingElement
PredefinedType RelatingBuildingElement S[0:?]
RelatedObjects RelatedObjects
RelatedObjects Description
ObjectType
Representation
ObjectPlacement Tag
(INV) FillsVoids S(0:1) RelatedObject [1:?]
IfcText (ABS)IfcRelAssigns
(ABS) IfcRoot IfcGloballyUniqueld
(ABS)IfcRelDecomposes (ABS)IfcRelAssociates IfcRelDefinesByProperties
IfcRelConnectsElements IfcRelHasCoverings IfcRelConnectsStructural
Element dfcWallTypeEnum
IfcOwnerHistory (ABS)IfcObjectDefinition
(ABS)IfcObject
(ABS)IfcBuildingElement IfcWall (ABS)IfcProduct (ABS)IfcElement IfcProductRepresentation
IfcRelVoidsElement IfcObjectPlacement
IfcIdentifier Label ⫽ “precast”
Properties Connections:
to other walls, ceilling, floor
Structural Properties RelatedBuildingElement
(INV)hasAssignments S[0:?]
FIGURE 3–6 The IFC structure for defi ning a wall.
1Subtyping 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 prin- ciples of object-oriented modeling. For more detail, see Booch 1993.
ch003.indd Sec3:116
ch003.indd Sec3:116 3/8/11 6:09:22 PM3/8/11 6:09:22 PM
www.EngineeringBooksPdf.com
for managing the object, such as who created it and when. IfcObjectDefi nition places the wall into the aggregate building story assembly. This level also iden- tifi es the components of the wall, including windows, doors, and any other openings. The IfcObject level provides links to properties of the wall, based on its type (defi ned lower down in the tree). IfcProduct defi nes the location of the wall and its shape. IfcElement carries the relationship of this element with others, such as wall bounding relationships, and also the spaces that the wall separates. It also carries any openings within the wall and optionally their fi ll- ing by doors or windows. If the wall is structural, a structural element repre- senting the wall can be associated with it.
Walls are typed as one of the following: Standard: extruded vertically with a fi xed width along its control line; Polygonal: extruded vertically but with varying cross section; Shear: walls not extruded vertically; ElementWall: walls composed of elements such as studs and sheathing; PlumbingWall: wall with embedded routing space; Userdefi ned: all other types; Undefi ned. Many of these attributes and relations are optional, allowing implementers to exclude some of the infor- mation from their export routines. It is possible that not all BIM design tools can create or represent all of the different wall types.
Properties are carried in optional P-sets. The PSetWallCommon pro- vides fi elds to defi ne: Identifi er, AcousticRating, FireRating, Combustibility, SurfaceSpreadOfFlame, ThermalTransmittance, IsExterior, ExtendToStructure (to slab above), LoadBearing, Compartmentation (fi rewall). Other more detailed P-sets are also supported if needed. Openings, notches and reveals, and protruding elements, such as pilasters, are supported, along with walls clipped by irregular ceilings.
All IFC models provide a common general building spatial structure for the layout and accessing of building elements. It organizes all object infor- mation into the hierarchy of Project -> Site -> Building -> BuildingStorey ->
Space. Each higher-level spatial structure is an aggregation of lower-level ones, plus any elements that span the lower-level classes. For example, stairs usually span all building storys and thus are part of the Building Aggregation. Walls typically bound two or more spaces on one or multiple stories. They are typi- cally part of the BuildingStorey, if structured within a single story and part of the Building Aggregation if they span multiple stories.
From this wall example, one gets a sense for how all building elements in IFC are defi ned. There are many types of assemblies, P-sets, and features that can support structural, mechanical, and other system elements. Analysis mod- els, load data, and product performance parameters can also be represented in some areas.
ch003.indd Sec3:117
ch003.indd Sec3:117 3/8/11 6:09:23 PM3/8/11 6:09:23 PM