Model Interoperability in Building Information Modelling

Transcription

1 Model Interoperability in Building Information Modelling Jim Steel, Robin Drogemuller Queensland University of Technology/ CRC for Construction Innovation

2 Alternate First Page Only

3 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

4 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

5 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

6 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

7 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

8 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)

9 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

10 Why is BIM a problem? One Island East

11 WATER

12 Plumbing

13 Plumbing FIRE SPRINKLERS

14 ELECTRICAL

15 HVAC

16 STRUCTURE

17 COLUMNS

18 CORE

19 FLOORS

20 CLADDING

21 Complexity?

22 x 71 floors

23 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

24 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

25 The IFC Metamodel (schema)

26 The IFC Metamodel (schema) Alternative modellings vs Extension mechanism IfcProxyObject For things that cannot be modelled using another IFC type

27 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

28 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

29 Interoperability: Drivers

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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.

39 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

40 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

41 Conclusion Questions?

42 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

43 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

44 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

45 Content Page