Entrant details
Role or Job Title on the Project
Digital Engineering Manager
Employer
Employer Role
Design-Builder Company
Are you or your employer a member of buildingSMART?
No
Submission details
Submitting Party Company Name
Lendlease
Submitting Party Company Location
Sydney, Australia
Submitting Party Role on Project
Emerging Digital Engineering Manager
Submitting Party Company Website
Full Project Name
A modular tookit for developing OpenBIM data pipelines
Project Location (Country)
Australia
Project Objectives
A suite of Unix-influenced modular, decoupled, and cross-platform OpenBIM tools were developed under free and open source software licenses. Functionality provided includes native IFC authoring, BCF management, IFC collision detection, 2D IFC construction drawings, IFC data validation for exchange requirements, COBie analysis, IFC comparison, and IFC building physics simulation. This suite can be combined to form a custom pipeline to process OpenBIM data, supported by a community of AEC professionals working with OpenBIM standards. The suite has been applied in a variety of commercial projects, from small construction prototypes to major commercial / infrastructure projects in delivery.
openBIM Achievements
Combining free software and OpenBIM increases OpenBIM’s exposure for smaller market players, cross-platform users, those who cannot afford proprietary tools, those ideologically preferring free software (e.g. non-profits, governments, academics, FOSS advocates), and the general community, who are having increasingly less access to their own built environment data. This combination also allows larger players to build their own digital pipelines more rapidly compared to relying on external software vendors. This pipeline automation improves workflow efficiency and transparency. Overall, the greater industry capability increases the demand for high quality OpenBIM output, as demonstrated on our projects.
openBIM used
IFC 2x3, IFC4, BCF, MVD, mvdXML, COBie
openBIM or open standards used other than those listed above
Uniclass, SVG, JSON, XML, HTML, Git, J/XUnit XML, Gherkin Syntax
Software used
IfcOpenShell, Blender, BlenderBIM Add-on, FreeCAD, IFCDiff, IFCCOBie, BIMTester, IFCClash, IFCCSV, IFCPatch, Git, Git-LFS, Bitbucket, Pipelines, Revit.
Strategic Alignment
Development of a technology pipeline for the industry with free software would not be possible without OpenBIM. Free software naturally leans towards interoperable schemas to integrate, looking for synergies in software tools, rather than to compete. In this project, OpenBIM is treated as a core native format and database, as opposed to a transfer methodology between program imports and exports. The robustness of IFC/BCF and its ability to hold and integrate data relationships across disciplines allows free software to continue to provide a diverse set of offerings, whilst all operating on the same persistent IFC dataset.
Highlights
- A suite of seven cross-platform, Unix-style tools were developed under free software licenses, tackling a variety of OpenBIM usecases across multiple project phases.
- A small project was delivered from design to construction using only IFC and SVG (for documentation) as native formats (no other CAD/BIM formats were used) with no proprietary tools, demonstrating the feasibility of OpenBIM as a native format.
- An automated OpenBIM auditing procedure was implemented on a large NSW government mixed-use infrastructure project, regularly processing gigabytes of OpenBIM data with a custom-built alternative to MVDs and mvdXML.
- A new open source architecture community was started, garnering 330 members within the first six months, pursuing the exchange of OpenBIM data across a variety of underrepresented tools and platforms, helping to develop and test new workflows, and writing guides and best practices along the way.
Project Website
Project Address
N/A - this submission is for technical excellence, representing a suite of modular tools. The addresses of projects this has been implemented on are sensitive in nature.
Project Type
Mixed-Use
Size of Project
The suite of modular utilities formed a pipeline that processed 3.4GB of IFC-SPF data every 2 weeks. IFC data described 5 buildings of significant size, with individual models for each discipline and building. Disciplines included architectural, structural, mechanical, electrical, hydraulics, fire, landscape, and civil.
Detailed description of the project
Projects that this were implemented represents a variety of usecases of OpenBIM. From smaller projects where OpenBIM was used from project inception to fabrication and construction, to larger projects with a variety of disciplines and stakeholders. All projects were commercial in nature and responded to commercial requirements, both internal and client-imposed.
In under a year, a suite of seven cross-platform and Unix-style modular tools were developed under free software licenses, using IfcOpenShell as a library. Each target a different usecase, at different project phases to be used by different stakeholders. Each cross-platform tool can be run headlessly, used as a library, or integrated within a GUI. Each tool uses IFC data as an input format and reads directly from the IFC as a native database, with little to no translation to other schemas. A short summary is provided:
- IFCDiff: compares two IFC files for changes, akin to a “git diff” operation, with options to check for property and inverse attribute changes, and geometry changes. Usecases include model coordination, quality auditing, and model storage management. Each IFC element subclass is hashed to detect changes, with provisions made for numerical tolerance, STEP IDs, and properties known to have limited vendor support.
- IFCCOBie: for COBie data extraction from the relevant COBie MVD IFC format into a spreadsheet format, including a log of COBie mapping non-compliances. Usecase is primarily in COBie data delivery.
- IFCClash: Provide geometry tolerance checking, and collision detection, between sets of IFC models, with various element filters. Usecase is primarily in model coordination.
- IFCCSV: for bulk IFC data management to/from CSV, typically as a general tool in usecases where it is not necessary to use a graphical BIM authoring package, and allows authors to manipulate BIM data in bulk with spreadsheet software without a detailed understanding of the IFC schema.
- IFCPatch: to modify IFC data in-place, without an import/export process. Typically used to restructure IFC data when the authoring tool is unable to export IFC in the desired structure. This allows us to canonicalize data coming from different OpenBIM vendors, who may have differing implementations.
- BIMTester: runs automated model validation and quality auditing, using a plain English alternative to MVD and mvdXML for describing exchange requirements.
- BlenderBIM Add-on: allows native IFC2x3, IFC4, BCF-XML authoring, viewing and editing using the Blender platform. Usecases include model authoring, visualisation, construction sequence animation, real-time OpenBIM querying with Python, and production of construction documentation. It is also used as a graphical interface to the remaining tools in the suite, which are otherwise shipped as command line interfaces.
This pipeline was used by Lendlease, in collaboration with Cox Architecture.
On a small prototype project, the pipeline was used to deliver a building (~250sqm) from concept design through to construction. The entire model was designed with IFC as the native file format. No other native format, proprietary or otherwise, was required to capture the data. This OpenBIM requirement also includes all construction documentation. 2D drawing data and annotation was stored in IFC, and further translated into the SVG open standard, with zero proprietary software. This guaranteed that all documentation was derived from OpenBIM data. The resulting 2D SVG contains links back to the IFC in the form of IFC GlobalIds.
On a larger commercial / infrastructure project, the client mandated the delivery of OpenBIM data, with the COBie MVD. Approximately 3.3GB of IFC data was delivered each fortnight by a diverse set of disciplines: architectural, structural, MEP, fire, and landscape. A custom model delivery procedure and data auditing pipeline was developed to process this OpenBIM data.
Detailed description of openBIM on the project
In under a year, a suite of seven cross-platform and Unix-style modular tools were developed under free software licenses, using IfcOpenShell as a library. Each target a different usecase, at different project phases to be used by different stakeholders. Each cross-platform tool can be run headlessly, used as a library, or integrated within a GUI. Each tool uses IFC data as an input format and reads directly from the IFC as a native database, with little to no translation to other schemas. A short summary is provided:
- IFCDiff: compares two IFC files for changes, akin to a “git diff” operation, with options to check for property and inverse attribute changes, and geometry changes. Usecases include model coordination, quality auditing, and model storage management. Each IFC element subclass is hashed to detect changes, with provisions made for numerical tolerance, STEP IDs, and properties known to have limited vendor support.
- IFCCOBie: for COBie data extraction from the relevant COBie MVD IFC format into a spreadsheet format, including a log of COBie mapping non-compliances. Usecase is primarily in COBie data delivery.
- IFCClash: Provide geometry tolerance checking, and collision detection, between sets of IFC models, with various element filters. Usecase is primarily in model coordination.
- IFCCSV: for bulk IFC data management to/from CSV, typically as a general tool in usecases where it is not necessary to use a graphical BIM authoring package, and allows authors to manipulate BIM data in bulk with spreadsheet software without a detailed understanding of the IFC schema.
- IFCPatch: to modify IFC data in-place, without an import/export process. Typically used to restructure IFC data when the authoring tool is unable to export IFC in the desired structure. This allows us to canonicalize data coming from different OpenBIM vendors, who may have differing implementations.
- BIMTester: runs automated model validation and quality auditing, using a plain English alternative to MVD and mvdXML for describing exchange requirements.
- BlenderBIM Add-on: allows native IFC2x3, IFC4, BCF-XML authoring, viewing and editing using the Blender platform. Usecases include model authoring, visualisation, construction sequence animation, real-time OpenBIM querying with Python, and production of construction documentation. It is also used as a graphical interface to the remaining tools in the suite, which are otherwise shipped as command line interfaces.
This pipeline was used by Lendlease, in collaboration with Cox Architecture.
On a small prototype project, the pipeline was used to deliver a building (~250sqm) from concept design through to construction. The entire model was designed with IFC as the native file format. No other native format, proprietary or otherwise, was required to capture the data. This OpenBIM requirement also includes all construction documentation. 2D drawing data and annotation was stored in IFC, and further translated into the SVG open standard, with zero proprietary software. This guaranteed that all documentation was derived from OpenBIM data. The resulting 2D SVG contains links back to the IFC in the form of IFC GlobalIds.
On a larger commercial / infrastructure project, the client mandated the delivery of OpenBIM data, with the COBie MVD. Approximately 3.3GB of IFC data was delivered each fortnight by a diverse set of disciplines: architectural, structural, MEP, fire, and landscape. A custom model delivery procedure and data auditing pipeline was developed to process this OpenBIM data.
The pipeline involved checking for changes in OpenBIM data to prevent unnecessary coordination by consultants, patching OpenBIM data to mitigate discrepancies in vendor support for OpenBIM, and submission to a Git-based, decentralised, version control system to track versioning. This forms the basis of an OpenBIM-centric CDE, where IFC, not native files, are considered as the source of truth.
Further tasks to audit and process this data followed a Continuous Integration (CI) workflow, similar to well established software industry practices. The IFC dataset is processed through a series of utilities. For instance, conversion into a spreadsheet format for COBie MVD IFCs for convenience, clash detection, data auditing, or CSV exports for scheduling.
Where OpenBIM standards were insufficient to fully describe the data for processing, such as in IFC data auditing, it is accompanied by a small dataset, in a simple but custom schema, formatted in a plaintext modular format, like JSON or Gherkin.
One example is where the procedure discovered shortcomings in MVDs and mvdXML for data validation. Gherkin plaintext was used instead to describe exchange requirements in natural languages, which can be equally understood and specified by BIM managers and project managers alike. This increases the accessibility of otherwise technical OpenBIM concepts to non-technical stakeholders. The full details of this process, as well as an analysis describing its relationship to existing technologies, are documented in a paper co-authored by Thomas Krijnen and Dion Moult, called “Compliance checking on building models with the Gherkin language and Continuous Integration”, recently presented at the European Group for Intelligent Computing in Engineering.
For both projects, existing open data standards and well-established software industry practices were applied along with this OpenBIM pipeline. These include managing models revisions and delivery using the Git version control system, as well as the JUnit XML reporting standard, typically used in Continuous Integration systems.
During the application of these pipelines, the rigorous testing has informed the publication of the buildingSMART User Guide for Geo-referencing in IFC, as well as a series of issues reported to the BCF-XML schema, currently scheduled to be fixed in BCF v2.2.
The suite of tools was developed in an open and transparent manner. A new online AEC community was started, with a focus on integrating free software and open data, where the community heavily participated in the testing, suggestions, and collaborative development of the pipeline. This community has brought together volunteer software developers to help form an integrated pipeline revolving around OpenBIM standards accessible to everyone. A community-contributed Wiki has emerged, with guidelines on best practices on OpenBIM data management in a variety of tools, both proprietary and free. New tools have also emerged in the process, including IFC2CA for structural simulation, Blender Archipack IFC integration, and improved OpenBIM IFC/BCF support in FreeCAD.
Benefits from using openBIM
Client requirements were not able to be satisfied using existing proprietary software. Using OpenBIM specifications coupled with our custom digital pipeline, we are now able to deliver client requirements.
Collaborating transparently on OpenBIM has helped foster a client / consultant relationship between Cox and Lendlease where both parties were empowered to manipulating the BIM data as equals and to the extent required by the project.
"We were able to innovate using openBIM."
Three aspects were innovative in particular:
- The use of OpenBIM and SVG to round-trip construction documentation.
Whereas OpenBIM data schemas for BIM models are relatively developed, OpenBIM data schemas for construction documentation are not. However, construction documentation forms the legal documents that define our projects. IFC was used to store all construction documentation annotation, as well as to generate all views. The SVG standard was then used to place these on sheets, manage paper-space template reuse, and apply CSS styles to determine line weights and hatching styles at run-time (in lieu of IFC style classes). The generated SVG relates back to the IFC dataset. It is possible to programmatically query any 2D vector polygon in the construction documentation, and determine its originating IFC Element GlobalId, its IfcMaterial Name property, as well as any other custom IFC property.
The ability to query semantically rich SVG construction documentation in a way that links back to IFC data is considered innovative. However, it is also a legal guarantee that the construction documentation derives completely from the OpenBIM data, which is increasingly becoming a contractual obligation, and is usually extremely difficult, if not impossible, to guarantee.
- The replacement of MVD and mvdXML with exchange requirements written in Gherkin syntax
This is not such a technically innovative approach, but instead one that resonates with non-technical OpenBIM users. The technical barriers to entry to implementing detailed, project-specific exchange requirements with MVD and mvdXML on projects are high, requiring users to have an in-depth understanding of OpenBIM data schemas and fluent in a bespoke set of XML instructions.
In contrast, providing the equivalent functionality of mvdXML in plain language allows business-oriented stakeholders to recognise the value of OpenBIM deliverables, and encourage further investment in their successful execution on a project.
- Treating IFC as a native data format, instead of an exchange format
To provide users with the greatest flexibility of tools, it was necessary to treat IFC as the common language between authoring programs. However, developing import and export processes are subject to a high risk of data loss. Instead, processes that incrementally modify data in an integrated pipeline do not have this shortcoming.
As a result, the suite of tools all operate on IFC directly, with minimal to no translation to a native data model. This allows operations to be done with no data loss or corruption. It also allows the utilities to be shared between multiple authoring tools. For example, the ability to compare IFC with IFCDiff can be implemented in both the Blender authoring platform as well as the FreeCAD authoring platform with no changes.
This also led to the development of “partial” model editing. For example, the BlenderBIM Add-on authoring tool has the ability to only modify specific geometric representations of an IFC file, leaving the remaining IFC data untouched. With this partial editing approach, tools can each incrementally modify a growing OpenBIM dataset, with each tool specialising in modifying a small portion of the IFC schema.
"We were able to identify where we need openBIM to develop further."
- The usage of OpenBIM data in a CG centric application has exposed weaknesses in the specification related to CG and rendering usecases. For example, material, colour, and texture specifications for CG visualisation and lighting simulation. Relevant criticism and proposals are underway in the buildingSMART forums.
- The usage of OpenBIM data in drawing production has exposed discrepancies in the buildingSMART expectation vs. the community expectation of the role of OpenBIM in drawings / documentation.
- The usage of Gherkin syntax as a substitute for mvdXML highlights a potentially more accessible and user-friendly alternative to intentions of mvdXML.
BIM Uses were defined on the project
I agree to be contacted about the project BIM uses outside of this awards program.
Stakeholders
Lendlease, Sydney, Australia,
https://lendlease.com/, Managing contractor & software developer, Dion Moult
Cox, Sydney, Australia,
https://www.coxarchitecture.com.au/, Architect & super user, Chandrasekar Rajamani
