Lecture 04 - Interoperability

Agenda
Building Information Modeling • Interoperability and its significance

• Early efforts in data exchange
• ISO-STEP
• IFC
• Model View Definition (MVD) to streamline
workflows
• Other efforts towards interoperability
Interoperability and IFC

Jinyue Zhang @ University of Toronto 20/07/2012 Interoperability and IFC 1
Multiple models Interoperability

• A team • The ability to pass data between applications,
activity to and for multiple applications to jointly contribute
design and
to the work at hand
construct
buildings • At the minimum, eliminate the need to manually
• Individual copy data already generated in another
applications application
to support – Facilitate iteration during design for finding best
different solutions to complex issues
specialities
– Avoid errors
– Structural,
energy,
scheduling,
• Enable the automation of business practices
estimating, (streamline workflows)
detailing…
20/07/2012 Interoperability and IFC 2 20/07/2012 Interoperability and IFC 3
Data exchange Types of exchange
• Data exchange between traditional CAD systems • Tool-to-tool exchange
– Translators (data exchange formats) such as DXF,
IGES, or SAT.
• Platform-to-tool exchange
– Robust for CAD files because they only concern • Platform-to-platform exchange
shapes and geometry
• Not enough for BIM applications

– Moved from the modeling of shapes and geometry to
the modeling of objects
– Not only multiple kinds of geometry but also relations,
attributes, and properties of different behaviours
Tool-to-tool exchange Platform-to-tool exchange

• Straightforward because of the limited data • The most common and important form of data
exchanges
• Example:
• One platform and a set of tools
quantity takeoff tool Æ cost estimating application
• Model View: model data needed by a specific
• Lightweight geometric viewer (DWF or 3D PDF)
application
as a tool
• Model View data translated into the format
• Example:
needed by the specific tool
Lighting simulation tool Æ DWF viewer
• Usually one-way translation
Clash detection tool Æ 3D PDF viewer
• Maybe direct application to application exchange
or through shared neutral exchange format
Platform-to-platform exchange Platform-to-platform exchange (cont’d)
• Two categories of BIM platform • Limited rule similarity
– Design platforms: ArchiCAD, Revit, Digital Project,
Bentley systems, etc.
• May loose some information:
– Fabrication model platforms: Tekla, SDS/2 A wall assembly in one BIM platform has it own rules
structureworks, StruCAD, CADPipe, CAMduct, etc. about embedded objects such as framing transferred to
another platform having no framing rules defined.
• Exchange within or cross types of platforms
• Even not possible to transfer when rules are
• The major challenge of interoperability
contradictory
• Key issue: exchanging rules that manage the
• A standard vocabulary of rules to solve the issue
objects’ integrity
of platform-to-platform exchange of parametric
• Not easy to pass an editable model along with objects
rules to the receiving platform
Factors influencing the use of BIM Cost associated with non-interoperability

• Interoperability is
much desired by the
industry.
• Other key factors:
– Automatic drafting
– Owner’s demand
– Improved
communication
– Opportunity to reduce
construction cost
Source: McGraw-Hill Construction Research and Analysis, 2007

Benefits of interoperability – data sharing Agenda
• Interoperability and its significance
• ISO-STEP
• IFC
workflows
Early efforts of data exchange Data schema and schema language

• Model schema: to define the meaning of
• 1970s-1980s the information exchanged
– What is a wall/window?
– Translate Intergraph project files to other systems
• Schema language: to define the way
– For example, from a piping design application to information is formatted
– The syntax
applications for piping flow analysis
• No separated schema language until 1980s.
– IGES and DXF
• Initial Graphics Exchange Specification (IGES)
• Schema language defines
– A public domain exchange format demanded by NASA – elements that can appear in a document
– attributes that can appear in a document
– Initiated by Boeing and General Electric – which elements are child elements
– the order of child elements
– Only two translators: for exporting and importing – the number of child elements
– whether an element is empty or can include
– Still in use text
– data types for elements and attributes
– default and fixed values for elements and
attributes

Data schema and schema language Data schema and schema language
• An XML document • SQL and many types of
data schema
• EXPRESS developed by
ISO-STEP to support IFC,
• An XML schema language CIS/2 and many STEP
enabled schemas.
• XML schema language to support:
– Building Automation and Control networks (BACnet)
– Automating Equipment Information Exchange (AEX)
– AECxml, the XML version of the IFC schema
– City Geography Markup Language (cityGML)
Three ways of exchange Direct links

• Direct links • Designed to exchange data between two specific
applications
• Proprietary exchange format
• Use the API of one system to extract data
• Public product data model exchange format
• Write the data using the API of the receiving
application
• Implemented at programming level
– Typically replying on C++ or C#

Direct links (continued) Proprietary exchange format
• Preferred by software companies: they can • A file or streaming interface developed by a
support them better. commercial organization for interfacing with that
company’s application.
• Enable some capabilities that are not easily
supported through public exchanges • Published or confidential schema
– Can tightly couple some tools with a BIM application
• A well-known example in the AEC area: DXF
• Typically robust for the versions of the two (Data eXchange Format) defined by Autodesk
software applications for which they were
• Other examples:
designed
– 3DS for 3D-Studio
• Well-maintained as long as the business – STL for stereo-lithography
relationship holds – SAT (Save As Text)
Public exchange format Common exchange formats in AEC

• Use an open and publicly managed schema and
schema language
• Examples of public interfaces: IFC, CIS/2, etc
– More details to discuss

Common exchange formats in AEC Data composition
• The amount of data and the number of data
types have all grown tremendously.
• The additions of properties, object types, and
relations grew much faster.
Agenda ISO-STEP
• Interoperability and its significance • History of ISO-STEP
• Early efforts in data exchange • The structure of ISO-STEP
• ISO-STEP • Application Protocols for the AEC
• IFC • Other STEP-based building models
workflows

The origin of ISO-STEP Information modeling methods
• Fixed schema file formats until the mid-1980s • Tools to formally specify the conceptual
– DXF, Drawing eXchange Format by Autodesk requirements
– IGES, Initial Graphics Exchange Standards
– IDEF1x, a member of IDEF (Integrated Definition for
• Need a new exchange format to handle ever growing Information Modeling) family for the definition of
complexity of object and associated data (geometry, defense planning in the U.S.
attributes, and relations) – NIAM, a modeling tool developed for business
• Early efforts database schema design in Europe.
– In USA, PDES (Product Data Exchange Standard) – EXPRESS, a standard data modeling language
– In European countries, STEP (STandard for the Exchange of specially developed by ISO-STEP for the exchange of
Product Model Data) product models
• Merged in 1991 (PDES and STEP) – EXPRESS-G, a standard graphical notation for
– ISO10303: Industrial Automation Systems –Product Data information models
Representation and Exchange
ISO-STEP system architecture STEP-on-a-Page

STEP-on-a-Page Other STEP-based building models
• CIS/2: CimSteel Integration Standard, version 2
– Industry developed standard
– For structural steel design, analysis and fabrication
– Supported by American Institute of Steel Construction
and the Construction Steel Institute in the UK
– Widely used and deployed in the North American
structural steel engineering and fabrication industry
• ISO 15926
• AP225: Building Elements Using Explicit Shape Representation – A STEP-based standard for industrial automation
– The only completed building-oriented product data model developed and
approved, for the exchange of building geometry. systems and integration
– Use in Europe, mostly in Germany, as an alternative to DXF – Integration of life-cycle data for process plants such
• AP241: Generic Model for Life Cycle Support of AEC Facilities as oil and gas production facilities
– Proposed by the German National Committee
– Address industrial facilities, partially overlap with IFC functionality – Lifecycle management empowered by 4D technology
– Proposed in 2006 and still under review as a new AP
Other STEP-based building models Agenda

• IFC: Industry Foundation Classes • Interoperability and its significance
– Industry-developed product data model for the design
and full lifecycle of buildings
– Supported by buildingSMART, an international • ISO-STEP
organization dedicated to maintain and promote IFC
– Broadly supported by most software companies • IFC
workflows

Industry Foundation Classes (IFC) IFC’s history
• IFC’s history • Industry Alliance for Interoperability (IAI)
– Due to the slow development of the ISO-STEP
• An example of IFC’s definition: IfcWall
– Started in 1994
• IFC’s structure – Industry-led consortium initiated by Autodesk
– System architecture – 12 companies at the beginning
– Scope
• International Alliance for Interoperability (IAI)
– References
– Started in 1997
– Terms and definitions
– Opened membership to all interested parties
– Structure and concepts
– The goal of publishing the IFC as a neutral AEC
product data model for the building lifecycle
– Based on ISO-STEP technology but independent
IFC’s history (continued) What is the IFC?

• buildingSMART • A schema (expressed by EXPRESS language)
– Started in 2005 • To define an extensible set of consistent data
– To avoid long and complex representation of building information
name of IAI
• For exchange between AEC software applications
– 15 chapters in more than 20
countries worldwide • Rely on ISO-STEP EXPRESS language and concepts
– Major domains • A “framework model” to provide broad, general
definitions of objects and data
– Other STEP-based efforts normally focused on detailed software
exchanges within specific engineering domain
– IFC is extensible to the level of detailed and task-specific models

IFC Version 2x4 IfcWall
• IFC2x4 (Version 2, Edition 4) • Common general building spatial structure in all IFC
models
• Release Candidate 3 (RC3) in October 2011 • Project Æ Site Æ Building Æ BuildingStorey Æ Space
• Higher-level is the aggregation of lower-level
• About 800 entities (data objects)
• 358 property sets
• 121 data types
• IFC2x3 is widely supported by software
companies in AEC
– The current reliable version
IfcWall IfcWall

IfcWallTypeEnum Pset_WallCommon
Pset_WallCommon Qto_WallBaseQuantities
• Reference
Reference ID for this specified type in this project (e.g. type 'A-1'), provided, if there is no classification reference
to a recognized classification system used.
• AcousticRating
Acoustic rating for this object. It is provided according to the national building code. It indicates the sound
transmission resistance of this object by an index ratio (instead of providing full sound absorption values).
• FireRating
Fire rating given according to the national fire safety classification.
• Combustible
Indication whether the object is made from combustible material (TRUE) or not (FALSE).
• SurfaceSpreadOfFlame
Indication on how the flames spread around the surface, It is given according to the national building code that
governs the fire behaviour for materials.
• ThermalTransmittance
Thermal transmittance coefficient (U-Value) of a material. Here the total thermal transmittance coefficient
through the wall (including all materials).
• IsExternal
Indication whether the element is designed for use in the exterior (TRUE) or not (FALSE). If (TRUE) it is an
external element and faces the outside of the building.
• ExtendToStructure
Indicates whether the object extend to the structure above (TRUE) or not (FALSE).
• LoadBearing
Indicates whether the object is intended to carry loads (TRUE) or not (FALSE).
• Compartmentation
Indication whether the object is designed to serve as a fire compartmentation (TRUE) or not (FALSE).

Qto_WallBaseQuantities System architecture
• Length Domain Layer
Total nominal length of the wall along the wall center line (even if different to the wall path).
• Width
Total nominal width (or thickness) of the wall measured perpendicular to the wall path. It should
only be provided, if it is constant along the wall path.
• Height
Total nominal height of the wall. It should only be provided, if it is constant along the wall path.
• GrossFootprintArea
Area of the wall as viewed by a ground floor view, not taking any wall modifications (like recesses) Interoperability Layer
into account. It is also referred to as the foot print of the wall.
• NetFootprintArea
Area of the wall as viewed by a ground floor view, taking all wall modifications (like recesses) into Core Layer
account. It is also referred to as the foot print of the wall.
• GrossSideArea
Area of the wall as viewed by an elevation view of the middle plane of the wall. It does not take
into account any wall modifications (such as openings).
• NetSideArea
Area of the wall as viewed by an elevation view of the middle plane. It does take into account all
wall modifications (such as openings).
• GrossVolume Resource Layer
Volume of the wall, without taking into account the openings and the connection geometry.
• NetVolume
Volume of the wall, after subtracting the openings and after considering the connection geometry.
System architecture Scope of IFC

Domain Layer • Life cycle phases in the scope
-Domain specific entities for a particular use – Demonstrating the need
-Can not be referenced by other entities – Conception of need
– Outline feasibility
Specific – Substantive feasibility study and outline financial authority
– Outline conceptual design
– Full conceptual design
Interoperability Layer – Coordinated design
-Provides more specialized objects and relationships
– Procurement and full financial authority
Core Layer – Production information
-The most general layer within the IFC schema architecture – Construction
-Entities to be referenced and specialized by entities in the – Operation and maintenance
shared element layer and the domain specific layer
-Provide the basic structure, the fundamental relationships • Disciplines in the scope
and the common concepts for all future specializations – architecture (brief, space programming, architectural design, coordinated design
and detailing)
– building services (HVAC, electrical, building control)
Resource Layer
– structural (structural engineering, structural analysis, structural detailing)
-26 sets of base EXPRESS definitions
-To define the base reusable constructs – procurement (quantity surveying, cost estimation)
-Generic for all types of products – construction (construction planning, construction scheduling, construction
-Largely consistent with ISO-STEP shared library resources handover)
– operation and management
General
Normative references Terms and definitions
• ISO 8601:2004 • General terms and definitions
– Data elements and interchange formats - Information Exchange
- Representation of dates and times. – Related to standard terms of data definition, object-
oriented analysis and design, and software related
• ISO 10303-11:1994 identification methods
– Industrial automation systems and integration - Product data
representation and exchange - Part 11: description methods:
The EXPRESS Language Reference Manual • Context specific terms and definitions
– Used within the context of information modeling
• ISO 10303-21:1994
within AEC/FM
representation and exchange - Part 21: Implementation methods:
Clear text encoding of the exchange structure • Abbreviated terms
• ISO 10303-28:2007
representation and exchange - Part 28: Implementation methods:
XML representations of EXPRESS schemas and data, using XML
schemas
General terms and definitions General terms and definitions

Context specific terms and definitions Context specific terms and definitions

Context specific terms and definitions Abbreviated terms

Fundamental structure of IFC data sets Fundamental structure of IFC data sets
• An IFC data set: any delivery form of IFC building information • Each object within an aspect model is defined by its own attributes
• Mandatory context section of the IFC data set: and by relationships to objects within the same aspect model and to
– general frame of reference (project name, description, life cycle phase, author, objects of other aspect models.
application, date of creation or last modification)
– default units (fixed for geometric representations, can be overridden for • Relationships between objects within the same aspect model
alphanumeric content) – composition - providing a whole-part relationship
– optional - the geometric representation contexts
– optional - the geospatial reference of the geometric representation context – connection - providing a connectivity relationship between objects, or
between objects and ports, or between objects and features
• Actual building information content – definition - providing the attachment of properties to objects
– spatial structure occurrence model
– building element occurrence model – association - providing the attachment of external references to objects
– building service element occurrence model • Relationships between objects across two or several aspect models
– structural analysis idealization occurrence model
– work plan and schedule occurrence model, including – typing - provide the assignment of an object type to one or many object
• cost schedule occurrence model occurrences
• work resource occurrence model – containment - providing the spatial containment of building elements or
– internal library model, including building service elements within the spatial structure
• building element type model
• building service element type model
– assignment - providing a logical link between objects of different aspect
• work task and resource type model models
Fundamental concepts and assumptions Fundamental concepts and assumptions


Agenda Model View Definition (MVD)
• Interoperability and its significance • IFC in use
– From the automation of data exchange between two BIM
• Early efforts in data exchange applications
– To refine workflows, eliminate steps, and improve processes
• ISO-STEP
• IFC data models: rich but redundant
• IFC • Next step: identify task and workflow information
• Model View Definition (MVD) to streamline requirements
– Buttons for “IFC export” and “IFC import” are no longer
workflows sufficient
• Other efforts towards interoperability • Model View to support new scenarios

– architect’s structural export for preliminary structural analysis
– curtain wall fabricator detail export to construction management
for fabrication-level coordination
Why are MVDs important? How to define a MVD?

• For the exporter • Another level of
– Know what is required and what is not required specification above the
• For the importer IFC schema
– Know what can be expected and acted upon • Recognized by National
• Current practice: trial and error Institute of Building
– Should the architect’s model of preliminary design of Science (NIBS) and the
a precast concrete façade include the embedded U.S. buildingSMART
window details?
chapter
– What kind of geometry is needed for exchanges when
façade connections are defined by the structural or • An approach outlined in
precast engineer?
NBIMS
• Today’s goal: define effective IFC exchanges, to
smooth and expedite workflows
Program How to define a MVD?
• Form an industry-led
group to identify the
needed exchanges
– to be translated
into IFC constructs
• Business Process
Modeling Notation
(BPMN)
– A well-known
process modeling
language used in e-
business planning
and implementation
• Process Map to provide a clear way to describe activities and the

information flows between activities
• Information Delivery Manual (IDM)

– identify a set of exchanges
– Specify their content form the users’ perspective
Design Design
• Concepts:
– Repeated
model
constructs
– Fundamental
part of the
Model View
• IFC Solutions Factory:

– www.blis-project.org/IAI-MVD
– Available for public review and reuse
– Serve as important modularization of small unit structures
– 23 efforts to define MVDs
• Structural analysis exchange, site planning, quantity takeoffs, etc
– Can be reused

Construct and Deploy Agenda
• Construct: • Interoperability and its significance
– The third phase
addresses the
implementation of the • Early efforts in data exchange
Model Views by
software companies.
• ISO-STEP
• Deploy:
– The last phase
involves deployment • IFC
and field use of the
MVD.
– This should be
supported by workflows
Guidelines that
document the model
views and how the • Other efforts towards interoperability
user should correctly
model its components
within a particular
BIM tool.
Other efforts supporting standardization International Framework for Dictionaries (IFD)

• A much wider issue of interoperability • Different languages in the
naming of properties and object
– IFC only for geometry, relations, and attributes classes
– What about other efforts parallel to IFC? – Door in English
– Porte in French
– What about naming standards for objects in AEC/FM? – Tür in German
– What about languages other than English? – 门 in Simplified Chinese
– 門 in Traditional Chinese
• We review • International Framework for
– International Framework for Dictionaries (IFD) Dictionaries
– www.ifd-library.org
– Building-related classification systems – Map terms in different languages
– Efforts in FM • IFC also provides multi-
– Many XML-based schemas languages, at least for
explaining meanings of some
terms

OmniClass OmniClass
• Existing classification systems
– Masterformat and Uniformat
– Building element and assembly classification system
– Used for specifications and cost estimation in U.S.
– Overseen by the Construction Specification Institute
– Do not map well to individual objects within a building
model
• New effort: OmniClass
– Jointly supported by Europeans and Americans
– Started from the early-1990s
– Developed by ISO and the International Construction
Information Society (ICIS)
– Currently has 15 tables
COBie COBie
• Construction Operations Building information
exchange
– Address the handover of information between the
construction team and the owner
– Deals with operations and maintenance (O&M)
– Uses a standard method for collecting the needed
information throughout the design and construction
process
– Updated at the beginning of 2010 and now is called
COBie2
– Readable by human and computers

From HTML to XML XML-based schemas in AEC
• HTML in early Web • OpenGIS
– Define an open set of common, language-independent
– Has a fixed set of tags abstractions for geometric and geographic objects
– Tags only tell the Web how to “present” the content • gbXML (green building XML)
– A schema for transferring information needed for energy
• eXtensible Markup Language (XML) analysis
– An extension to HTML • ifcXML
– A subset of the IFC schema mapped to XML
– Provide user-defined tags to specify an intended
meaning for data transmitted • aecXML
– Initiated by FIATECH to represent a broad range of buildings
– Very popular for exchange of information between and their components
Web applications, for example, to support e-
• agcXML (associated general contractor XML)
commerce or collect data over the Internet – A schema to support construction business processes
• CityGML
– A common information model for the representation of 3D urban
objects.
XML-based schemas in AEC

• Individually defined entities, attributes, relations,
and rules
• Work well in a group of collaborating firms that
implement a schema and develop applications
around it
• Incompatible each other (analogy of early
railroad development in the United States)
• Some undergoing efforts to harmonize schemas,
for example, mapping OpenGIS with IFC, but
still a lot of work to do
20/07/2012 Interoperability and IFC 90

Lecture 04 - Interoperability

Uploaded by

Copyright:

Available Formats

You might also like

Lecture 04 - Interoperability

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 04 - Interoperability

Uploaded by

Copyright:

Available Formats

Agenda

Building Information Modeling • Interoperability and its significance

Interoperability and IFC

Multiple models Interoperability

• Not enough for BIM applications

20/07/2012 Interoperability and IFC 4 20/07/2012 Interoperability and IFC 5

Tool-to-tool exchange Platform-to-tool exchange

Factors influencing the use of BIM Cost associated with non-interoperability

Source: McGraw-Hill Construction Research and Analysis, 2007

20/07/2012 Interoperability and IFC 10 20/07/2012 Interoperability and IFC 11

20/07/2012 Interoperability and IFC 12 20/07/2012 Interoperability and IFC 13

Early efforts of data exchange Data schema and schema language

20/07/2012 Interoperability and IFC 14 20/07/2012 Interoperability and IFC 15

20/07/2012 Interoperability and IFC 16 20/07/2012 Interoperability and IFC 17

Three ways of exchange Direct links

20/07/2012 Interoperability and IFC 18 20/07/2012 Interoperability and IFC 19

20/07/2012 Interoperability and IFC 20 20/07/2012 Interoperability and IFC 21

Public exchange format Common exchange formats in AEC

20/07/2012 Interoperability and IFC 22 20/07/2012 Interoperability and IFC 23

20/07/2012 Interoperability and IFC 24 20/07/2012 Interoperability and IFC 25

20/07/2012 Interoperability and IFC 26 20/07/2012 Interoperability and IFC 27

20/07/2012 Interoperability and IFC 28 20/07/2012 Interoperability and IFC 29

ISO-STEP system architecture STEP-on-a-Page

20/07/2012 Interoperability and IFC 30 20/07/2012 Interoperability and IFC 31

20/07/2012 Interoperability and IFC 32 20/07/2012 Interoperability and IFC 33

Other STEP-based building models Agenda

20/07/2012 Interoperability and IFC 34 20/07/2012 Interoperability and IFC 35

20/07/2012 Interoperability and IFC 36 20/07/2012 Interoperability and IFC 37

IFC’s history (continued) What is the IFC?

20/07/2012 Interoperability and IFC 38 20/07/2012 Interoperability and IFC 39

20/07/2012 Interoperability and IFC 40 20/07/2012 Interoperability and IFC 41

20/07/2012 Interoperability and IFC 42 20/07/2012 Interoperability and IFC 43

20/07/2012 Interoperability and IFC 44 20/07/2012 Interoperability and IFC 45

20/07/2012 Interoperability and IFC 46 20/07/2012 Interoperability and IFC 47

20/07/2012 Interoperability and IFC 48 20/07/2012 Interoperability and IFC 49

System architecture Scope of IFC

General terms and definitions General terms and definitions

20/07/2012 Interoperability and IFC 54 20/07/2012 Interoperability and IFC 55

20/07/2012 Interoperability and IFC 56 20/07/2012 Interoperability and IFC 57

20/07/2012 Interoperability and IFC 58 20/07/2012 Interoperability and IFC 59

20/07/2012 Interoperability and IFC 60 20/07/2012 Interoperability and IFC 61

Context specific terms and definitions Abbreviated terms

20/07/2012 Interoperability and IFC 62 20/07/2012 Interoperability and IFC 63

20/07/2012 Interoperability and IFC 64 20/07/2012 Interoperability and IFC 65

Fundamental concepts and assumptions Fundamental concepts and assumptions

20/07/2012 Interoperability and IFC 66 20/07/2012 Interoperability and IFC 67

20/07/2012 Interoperability and IFC 68 20/07/2012 Interoperability and IFC 69

Fundamental concepts and assumptions Fundamental concepts and assumptions

20/07/2012 Interoperability and IFC 70 20/07/2012 Interoperability and IFC 71

• Other efforts towards interoperability • Model View to support new scenarios

20/07/2012 Interoperability and IFC 72 20/07/2012 Interoperability and IFC 73

Why are MVDs important? How to define a MVD?

• Process Map to provide a clear way to describe activities and the

• Information Delivery Manual (IDM)

• IFC Solutions Factory:

20/07/2012 Interoperability and IFC 78 20/07/2012 Interoperability and IFC 79

20/07/2012 Interoperability and IFC 80 20/07/2012 Interoperability and IFC 81

Other efforts supporting standardization International Framework for Dictionaries (IFD)