Model Interoperability in Building Information Modelling

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 building project across all disciplines and all stages of the project lifecycle (initiation, design, bid, construct, maintain, refurbish/recycle) Verb Activity of sharing the complex information across the owners of all systems involved in project 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

Plumbing

Plumbing FIRE 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

The IFC Metamodel (schema)

The IFC Metamodel (schema) 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

Interoperability: Drivers

Interoperability: Drivers 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

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 wellsupported 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

IFC Interoperability: Semantics 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 IFC is too small kerb, or a low wall or small slab 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

IFC Interoperability: Semantics 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?

Content Page