Model Interoperability in Building Information Modellingindustrialized-software.wdfiles.com/local--files/kiss-aswec-2009/Stee… · ¥ Identity (people, companies, etc) ... properties

Model Interoperability in Building

Information Modelling

Jim Steel, Robin Drogemuller

Queensland University of Technology/

CRC for Construction Innovation

Alternate First Page Only

Summary

• Problem Domain: Architecture/Engineering/Construction industries

• Building Information Modelling

• Industry Foundation Classes as a Domain-Specific Modelling Language

• Using IFC as an interoperability mechanism

• File/syntax

• Visualisation

• Semantic

• Conclusions

The Domain: Stakeholders

• A lot of different parties can be involved in a building project

• Client/owner

• Financier

• Architect/s

• Engineers (structural, mechanical, electrical, acoustic, thermal perf.)

• Government/s (code checking, building approval)

• Builders & Sub-contractors

• Cost Engineers

• All of these need to interact in some way with the building model/plan

The Domain: Concepts

• A lot of different things to model, including

• Structure

• Architecture

• Heating/Ventilation/Air-conditioning (HVAC)

• Electrical

• Interiors

• Landscaping

• Processes, scheduling, costing, ownership/responsibility

• Most of these have complex inter-dependencies

The Domain: What happens

• Traditionally, information exchanged as paper

• Building plans (drawings), cost plan, bill of quantities, building

specification

• Increasing use of 3D tools in the design process

• Often still rendered as 2D for exchange with other parties involved in

the process

• 2D is well-understood, esp. for legal liability implications

The Domain: Building Information Modelling

• Building Information Modelling

• Exchange of rich models

• Full 3D, but also with metadata about materials, processes, purposes,

etc

• Allows for more detailed examination and processing of models by

people and increased use of automation techniques for model analysis

and preparation

• “Tipping point”

• In 2008, 45% of architects, engineers & contractors use BIM on a

significant proportion of their projects

Building Information Modelling

• Noun

– An information model representing a buildingproject across all disciplines and all stages ofthe project lifecycle (initiation, design, bid,construct, maintain, refurbish/recycle)

• Verb

– Activity of sharing the complex informationacross the “owners” of all systems involved inproject procurement

• Better term

– Virtual Design & Construction (VDC)

Why BIM?

• Build virtually before building actually

– Explore more alternatives at each stage

– Directly link analysis tools to BIM

(interoperability)

• Better intergration

– Reduce information entry

– Reduce errors

Why is BIM a problem?

• One Island East

WATER

PlumbingPlumbing

PlumbingFIRE

SPRINKLERS

ELECTRICAL

HVAC

STRUCTURE

COLUMNS

CORE

FLOORS

CLADDING

Complexity?

x 71 floors

Industry Foundation Classes

• Industry standard for BIM exchange

• Since 1996, now version 2x3 (2x4 in draft)

• Defined as a STEP/Express schema

• Mapping to file format (Part 21)

• Mappings to programmatic APIs

• Mapping to XML (ifcXML)

• Very similar architecture to OMG-style MDA

• Wide uptake

• Does vary from between disciplines

The IFC Metamodel (schema)

• BIG!

• 653 entity types, 327 data types, 317 property sets

• BROAD!

• Modelling constructs for:

• Basic building elements, e.g. walls, slabs, beams, columns, doors

• 3-dimensional geometries

• Electrical/Ventilation elements, e.g. wires, ducts, fans, vents

• Facilities management (tasks, etc)

• Identity (people, companies, etc)

• much, much more…



• Alternative modellings

vs

• Extension mechanism

• IfcProxyObject

• For things that cannot be modelled using another IFC type

IFC Models: example

• Mechanical services (and some

structure as a guide) for a 19-

storey office tower

• Plant rooms, verticals, 2 example

floors (not a complete model)

• 360MB file

• 7.3 million objects

Interoperability: Drivers

Why is interoperability an important issue for the domain?

• Large number of participants on any given project

• Complex, highly interdependent models

• Tool-independent Model versioning & management facilities

• Many analyses are manual and labour intensive, that could be at least

partially automated

• Constructibility (process simulation)

• Quantity takeoff and cost estimation

• Environmental analysis, including emissions, carbon, air quality

• Thermal/Acoustic/Lighting performance




• Structure

• Architecture


• Electrical

• Interiors

• Landscaping



IFC Interoperability: File/Syntax

• Interoperability almost universally by Part-21 file interchange

• Occasional problems due to file size

• 7.3 million objects is a large number to parse and store

• 7.3 million objects is a large number to render in 3D

IFC Interoperability: Visualisation

• The main goal of IFC

• Generally good

• Occasional misunderstandings to do with relative locations of copied/reused

objects

• Columns or openings “floating in space”

• Increasingly rare

IFC Interoperability: Alternative visualisations

• Different stakeholders need different visualisations

• An architect wants photo-realism

• A quantity surveyor prefers elements to be visually distinct based on

element type or material in order to classify and quantify them

• A structural engineer sees elements differently again, tied to structural

properties and not visual properties

• IFC supports multiple visualisations

• Managing, grouping and ordering visualisations is not especially well-

supported in and between tools

IFC Interoperability: Semantics

• The most challenging type of interoperability

• Increasingly in demand

• Major stumbling block for uptake of automated analysis tools

• Garbage in, garbage out

• “My crappy model doesn’t produce beautiful analysis results, the

software must be terrible!”

• Some small issues

• Some (significant) tools have a lax approach to preserving globally

unique object identifiers

• Some bigger issues

IFC Interoperability

• Modelling style

• Heterogeneity of attribute values

• If a beam is made of steel, has a compression strength of 450, and a

cross-section of UB470.4, which information goes in the “material”

property, and which goes in the description as text?

• Too many possibilities -> nightmare for anyone writing a tool that

classifies and quantifies the tonnage of steel beams in a design

• Conventions even for naming are different in different jurisdictions

• Solution (technical): ontology-type approaches for standardised modelling

objects

• Solution (non-technical): agreement by stakeholders on standard modelling

styles


• Coverage is an issue

• IFC is too big

• Tools cannot visualize everything: rare – geometry is common

• Tools do not (and should not have to) provide palette objects for every

IFC type

• kerb, or a low wall or small slab

• IFC is too small

• There is no construct for modelling a water tank

• Build it out of slabs and curved walls, OR use a proxy object

• Solution: Conventions & guidelines for good modelling practice


• Alternative representations

• Beyond just alternative visualisations, some stakeholders think about the

model using very different paradigms

• In road modelling, models often begin as string-based models with

vectors for edges instead of surfaces. Need to infer surfaces later in the

process to change paradigms

• When converting a model for thermal/acoustic analysis, walls, windows,

doors, etc from the original are split or merged to simplify the analysis

process. This mapping needs to be preserved

• Solution: Investigating the use of bidirectional/roundtripped domain-specific

model transformations to maintain correspondences

Conclusions: IFC as a modelling language

• Language is very big, very broad

• Models are very big: scalability challenges

• Idea: interesting case study for both metamodel modularity and model

modularity

• 3D visualisation makes visualisation-level interoperability more challenging

than diagrammatic languages, but it seems to work

• Progression from drawing language to true modelling language, used to

drive analysis and automation.

• Reminds me of another language

• Unlike UML, semantic interop issues are not about semantic interpretation,

but clear expression.

Conclusions: The IFC Process

• Compared to languages I know: UML/MOF

• Standardisation by committee/compromise

• Something for everyone: “unionised” modelling language

• Initial set of implementing tools:

• standardisation before implementation?

• shared user understanding, vs shared machine understanding

• threat of the elephant in the room (Autodesk, Rational)

• Transition to partial tool coverage: “family of languages”

• jury still out!

• Compliance testing issues

Conclusions: Human Processes

• Importance of human processes

• In many cases, technical solutions exist provided that they are

combined with agreement and effort amongst stakeholders

• Agreement on modelling “style” and standardised building blocks

• Compliance testing and interoperability testing

Conclusion

• Questions?



• Structure

• Architecture


• Electrical

• Interiors

• Landscaping





• Structure

• Architecture


• Electrical

• Interiors

• Landscaping





• Structure

• Architecture


• Electrical

• Interiors

• Landscaping



Content Page

Documents

Model Interoperability in Building Information Modellingindustrialized-software.wdfiles.com/local--files/kiss-aswec-2009/Stee… · ¥ Identity (people, companies, etc) ... properties