BIM – Building Information

Modelling/Management

1
 Outline

 What is the Industry Foundation Classes?

 Background
 Schema
 Domains

 What is the Information Delivery Manual?

2
 What is IFC?

 The Industry Foundation Classes (IFC) are

often talked about in the construction industry
as an important resource for interoperability.

3
 Background: What is IFC?

 1985-1990 -> CAD era

 Drawing Interchange Format (DXF) – Initial
Graphics Exchange Specification (IGES) (geometry
based formats)
 1990-1995 -> STEP-Exchange(-G)
 1995-Today -> IFC
 Releases - IFC 2x4, IFC4
 Data File Formats: STEP, XML
 2017-beyond -> ifcOWL/RDF, ?
4
 Background: What is IFC?

AEC organizations have several industry based product

models on EXPRESS language, which are as follows
 AP 225 – Building Elements Using Explicit Shape
Representation (ISO 10303)
 AP 241 – Generic Model for Life Cycle Support of AEC
Facilities (ISO 10303)
 CIS/2 – CimSteel Integration Standard, Version 2 (for structural
steel)
 IFC – Industry Foundation Classes by buildingSMART
(formerly the International Alliance for Interoperability)

5
 Background: What is IFC?

buildingSMART
 Autodesk and 12 US companies in 1995
 AT&T, HOK Architects, Honeywell, Carrier, Tishman and Butler
Manufacturing, etc.
 buildingSMART is the responsible organization for developing
IFC, the Information Delivery Manual (IDM), Model View
Definitions (MVD), buildingSMART Data Dictionary (bsDD)
 Its goal it the publishing of the IFC as a neutral AEC product
model responding to AEC building lifecycle.

6
 IFC Domains

Domains under buildingSMART, which are as follows:

 AR – Architecture
 BS – Building Services
 CM – Construction
 CS – Codes and Standards
 ES – Cost Estimating
 PM – Project Management
 FM – Facility Management
 SI – Simulation
 ST –Structural Engineering
 XM – Cross Domain
7
 IFC File Format - STEP

STEP has the following properties:

 Use of a machine readable modelling language instead of a
file format;
 The language emphasizes data declarations but includes
procedural capabilities for rules and constraints
 The language has mappings to different implementations,
including a text file format, database schema definitions and
XML schemas;
 Reference sub-models that are shared and re-used subsets of
larger standard models for geometry, measurements,
representation classification and other generic needs

8
 STEP Modelling Language -
EXPRESS

 Most important outcome of STEP is EXPRESS

modelling language
 EXPRESS adopts many object-oriented
concepts, including multiple inheritances.
 Object refers to a computer language concept,
which is broader than just representing physical
objects.
 Objects can be used to represent conceptual or
abstracted objects, materials, geometry, assemblies,
processes and relations, among other things!
9
Example of EXPRESS

SCHEMA Family;

ENTITY Person
ABSTRACT SUPERTYPE OF (ONEOF (Male, Female));
name: STRING;
mother: OPTIONAL Female;
father: OPTIONAL Male;
END_ENTITY; ENTITY

Female
SUBTYPE OF (Person);
END_ENTITY;

ENTITY Male
SUBTYPE of (Person); EXPRESS-G
END_ENTITY;

END_SCHEMA;
 IFC and EXPRESS, XML and OWL?

 The IFCs are defined in EXPRESS

Implementations:
 ISO-10303-21, Part-21 or P-21 file
 SQL and object-based database implementation
 XML implementations (ISO-10303-28 or Part 28
format)
 OWL implementation currently being finalised

11
 What is IFC?

 Designed as an extensible “framework model”

 Its initial developers intended it to provide
broad general definitions of objects and data
from which more detailed and task-specific
models could be defined
 IFC has been directed to address all building
information, over the whole BLC
 planning, through design (including analysis and
simulation), construction, commissioning, operation
12 and maintenance, redesign and demolition
What it IFC?

• Classical argument for the BIM/IFC development.

• (a) multiple interfaces for cross domain communication
• (b) communication through a neutral, common and shared BIM
standard
 IFC Schema

The highest level of the

IFC model contains
entity definitions for
concepts specific to
individual domains
such as architecture,
structural engineering,
facilities' management
http://www.buildingsmart-tech.org/ifc/IFC4/final/html/
14 - Core Schemas
 IFC Schema
This level comprises entity
categories that are commonly
used and shared between
multiple building construction
and facilities management
application.
E.g. Shared Building Elements
schema has entity definitions for
a beam, column, wall, door

15
 IFC Schema
The other two Extension
schemas define process and
control related concepts such as
task, procedure, work schedule,
performance history, work
approval.

Kernel schema defines core

concepts such as actor, group,
process, product, relationship
16
 IFC Schema
The Product Extension schema
defines abstract building
components such as space, site,
building, building element,
annotation

Basic properties such as

geometry, material, quantity,
measurement, date and time,
cost, actors, roles
17
 IFC Hierarchy of Concepts

18
Example
Example

http://www.ifctoolsproject.com/
IFC STEP Example
/* -------------------------------------------------------------------------------- /* if site is irrelevant Building could be connected to project directly ----------------------- */
------------- */ #31 = IFCSITE('21pTbIW1P9phNTO0UY9qiR', #2, 'Default Site', 'Description of Default Site',
/* general entities required for all IFC data sets, defining the $, #32, $, $, .ELEMENT., (24, 28, 0), (54, 25, 0), 10., $, $);
context for the exchange ------ */ #32 = IFCLOCALPLACEMENT($, #33);
#1 = IFCPROJECT('2W41ZrokPFE8L1omDpTIlJ', #2, 'Default /* no rotation - z and x axes set to '$' are therefore identical to "world coordinate system" -- */
Project', 'Description of Default Project', $, $, $, (#20), #7); #33 = IFCAXIS2PLACEMENT3D(#24, $, $);

/* single owner history sufficient if not otherwise required by /* each IFC data set containing elements in a building context has to include a building -------
the view definition ------------ */ */
/* provides the person and application creating the data set, /* at absolute minimum (could have a site and stories as well) --------------------------------- */
and the time it is created ------- */ #34 = IFCBUILDING('2fUtgsqoTFLPRbRPZtVH_M', #2, 'Default Building', 'Description of
#2 = IFCOWNERHISTORY(#3, #6, $, .NOTDEFINED., $, $, $, Default Building', $, #35, $, $, .ELEMENT., $, $, #37);
1489590603); /* if the building is the uppermost spatial structure element it defines the absolut position -- */
#3 = IFCPERSONANDORGANIZATION(#4, #5, $); #35 = IFCLOCALPLACEMENT(#32, #36);
#4 = IFCPERSON($, 'Bonsma', 'Peter', $, $, $, $, $); /* no rotation - z and x axes set to '$' are therefore identical to "world coordinate system" -- */
#5 = IFCORGANIZATION($, 'RDF', 'RDF Ltd.', $, $); #36 = IFCAXIS2PLACEMENT3D(#24, $, $);
#6 = IFCAPPLICATION(#5, '0.10', 'Test Application', 'TA #37 = IFCPOSTALADDRESS($, $, $, $, ('RDF Ltd.', 'Main Office'), '32', 'Bankya', 'Sofia',
1001'); '1320', 'Bulgaria');
#38 = IFCBUILDINGSTOREY('3d6EITXFb2QP01HWpMsAuA', #2, 'Default Building Storey',
'Description of Default Building Storey', $, #39, $, $, .ELEMENT., 0.);
#39 = IFCLOCALPLACEMENT(#35, #40);
/* no rotation - z and x axes set to '$' are therefore identical to "world coordinate system" -- */
#40 = IFCAXIS2PLACEMENT3D(#24, $, $);
#41 = IFCRELAGGREGATES('1rIqXFZaT7cBo6GGby8nj7', #2, 'BuildingContainer',
'BuildingContainer for BuildigStories', #34, (#38));
#42 = IFCRELAGGREGATES('2GMzvdtzX9fBZnvySEN290', #2, 'SiteContainer',
'SiteContainer For Buildings', #31, (#34));
#43 = IFCRELAGGREGATES('25VPwBHGL4HO8T1xupAcKY', #2, 'ProjectContainer',
Source - http://www.buildingsmart- 'ProjectContainer for Sites', #1, (#31));
tech.org/implementation/ifc4-implementation/helpful- #44 = IFCRELCONTAINEDINSPATIALSTRUCTURE('0ZPHip4EX9GhkBaBaDh21n', #2,
examples 'Default Building', 'Contents of Building Storey', (#45, #152), #38);
 IFC Domains: Building Controls
The IfcBuilding-
ControlsDomain schema forms
part of the Domain Layer of the
IFC Model.

It extends the ideas concerning

building services outlined in
the IfcSharedBldg-
ServicesElements schema.

It defines concepts of building

automation, control,
http://www.buildingsmart-tech.org/ifc/IFC4/final/html/ instrumentation and alarm.
Domains: Building Control –
Sensor
Domains: Building Control –
Sensor (enumerated types)
Domains: Building Control –
IfcSensor
• IFC provides enumerations of sensors, which inherit lots of useful
properties, should as placement and representation.
• Otherwise, it provides no support for modelling other relevant
aspects, e.g.
• related to what is being measured/observed
• uncertainty (accuracy and precision) of measurements/observations
• structure of observation, etc.
Domains: Building Control –
Controllers
Domains: Building Control –
IfcController
• IfcController provides a basis for declaring simple controllers, but
is more related to the connections between the controller and the
physical environment and how to install these systems.
• Does not provide more complex descriptions related to:
communication protocols and data message structure,
behavioural characteristics, etc.
Domains: Building Control –
Appliances
Domains: Building Control –
Appliances
• IFC provides enumerations of appliances, again inherit lots of
useful properties, such as placement and representation.
• Otherwise, it provides no support for modelling other aspects,
e.g. related to the behaviour profiles, the energy consumption
profiles, all of which are relevant to smart controls and energy
efficient solutions.
Domains: Placement (Geolocation)
Domains: Placement (Geolocation)
Domains: Placement (Geolocation)

What about individual buildings?

– must define location in relation to IfcSite!
Domains: Placement
• IFC provides good support for placement of objects in 3D space.
This can be important for many use cases related to building
control and automation, e.g. position of sensors in relation to
windows, HVAC, walls, windows, etc.
• IFC also provides some support for geolocation, although it is
perhaps an overly complicated way to locate a building.
Domains: Geometry –
Representation
The schema IfcGeometry-
Resource defines the resources
used for geometric
representations.
The primary application of this
resource is for representation of
the shape or geometric form of an
element.
The geometric representation
items defined here are also used
to describe geometric models
within the schema IfcGeometric-
ModelResource.
Domains: Geometry –
Representation
Domains: Geometry –
Representation
The
Domains: Geometry Represenation
• IFC provides good support for representing building elements.
• In fact, a lot of applications make use of IFC mainly for sharing geometric
information.
• Nonetheless, there may be use cases where only very simple
representations of the building are required, for example 2D
polygons to represent the buildings footprint.
• For such use cases, more light weight solutions may be better suited.
Why use IFC?

• The IFC, as the only public and well-

developed data model for buildings and
architecture, is a de facto standard worldwide.
• It is being picked up and used in a growing
number of applications, in both the public and
private sectors.
• The IFC, as a data model standard, is very
alive.
Why use IFC?

• There are still some missing points due to

standardisation.
• also some problems with the translator software that some of
them can transfer models of IFC properly.
• Some parts of the AEC are still evolving in IFC and
other parts of the IFC needs testing to prove their
standardisation
• Linking to other data models may be a better approach than trying to
represent all BLC data within the IFC schema.
• For web developers, new developers (e.g. those who
wish to use building models during building operation)
the standard may be slightly over engineered 
The Information Delivery Manual
Managing Data Requirements

• The Information Delivery Manual (IDM) was

developed as a direct response to the challenge of
defining data requirements to meet BLC processes.

• It has been developed by buildingSMART

• Together with Model View Definitions (MVDs), they

provide a methodology for different domain experts to
model the specific data requirements that are needed
to meet their own use cases.
Managing Data Requirements
• The IDM/MVD methodology defines how to specify business use
cases and how to coordinate involved stakeholders with their
tools and data requirements.

• A prerequisite for this is to be clear about processes, actors,

shared or exchanged data and used interfaces or data structures.

• It provides a framework for the specification of collaborative

design scenarios, in particular for Building Information Modelling
(BIM)
IDM/MVD
Methodology

• Information
Delivery Manual
(IDM, orange
parts)
• Model View
Definition (MVD,
blue parts)
IDM Methodology

• IDM focuses on knowledge defined by domain

experts.
• It defines processes and exchange requirements,
which will answer:
• what kind of tasks (processes) must be carried out?
• who is responsible?
• when they have to carry out (order, dependencies?)
• what data needs to be exchanged?
IDM Methodology

• Two kinds of specifications are used

1. Process Maps based on the Business Process
Modelling Notation (BPMN)
2. Exchange Requirements typically collected in a
table format
IDM Methodology

• Process Maps define the

various tasks to be carried
out throughout the life-cycle
of a building.
• Each task is placed within a
swim lane, which is assigned to
an actor role
• Arrows between tasks define
data dependencies and are
typically linked with data
exchange requirements.
IDM Methodology
• For making data exchanges more
explicit IDM introduces swim lanes
which carry additional information
about the kind of data exchange
• E.g. BIM, drawings, regulations or other
kinds of data.
• The horizontal axis is tailored
according to the life-cycle phases
so that it is visible what BLC stage
the task is to be carried out
IDM Methodology
• Exchange Requirements specify the data that needs to be
exchanged.
• As mentioned above it typically starts with identifying main data sources in
terms of high-level data structures or domains
MVD Methodology

• Process Maps define the various tasks to be

carried out throughout the life-cycle of a
building.
• Each task is placed within a swim lane, which is
assigned to an actor role whole is responsible for
carrying out those tasks.
• Arrows between tasks define data dependencies
and are typically linked with data exchange
requirements.
IDM Methodology (Process Map)
IDM Methodology (Exchange
Requirement)
IFC in Use – Establish Exchange
Requirements

• Two kinds of specifications are used

1. Process Maps based on the Business Process
Modelling Notation (BPMN)
2. Exchange Requirements typically collected in a
table format
Guidelines for Publishing BIM Data