Design Software Interoperability in Construction Projects
Lack of software interoperability in the design phase of construction projects takes designers away from design work and is a major cause of delays and increased costs.
1. Background
The push for digitalization in the construction industry has been ongoing for several decades now. While much effort from private players and industry bodies has gone into developing functionality and standards to support digitalization, the available technologies still fall short of the promise of BIM.
A need as basic as design software interoperability is still a cause for major struggles in construction projects. Instead of directly addressing the interoperability problem, the latest technology platforms often require construction designers to become software engineers. Even when such an expansion of skillset is feasible, it comes at a great cost by bringing designers away from their core competencies and by dramatically changing common construction design workflows.
2. Models, Objects, and Metadata
In this section three topics are covered; clearly explaining the concepts of model, object, and metadata, briefly explaining auxiliary data, and briefly explaining reference data.
2.1. Key Terminology
At the heart of design data lies the 3D design model of the construction project with all its geometries. The design model is an aggregate of design discipline models corresponding to the different design disciplines involved in a construction project, most commonly:
- Architecture model
- Structural engineering models
- MEP models
- HVAC models
The aggregate of the design discipline models, the combined design model, is intended to exactly represent that which is constructed, be it a building, bridge, tunnel, or any other thing to be constructed. The objects that make up the combined design model, in addition to their geometries, are described through metadata. The metadata describes various attributes of objects in the design model, including materials and profiles used, surface treatments, energy efficiency, per-unit cost, and a plethora of other attributes. These metadata are related to or derived from reference data. Reference data is described below in more detail.
2.2. Auxiliary data
The combined design model — with all of its objects and metadata — is additionally related to various kinds of auxiliary data. For example, coordinate markers, location data related to the site for the construction project, 2D drawings required for on-site assembly, and many other kinds of possible auxiliary data.
2.3. Reference data
Reference data refers to universal lists of information that aren’t unique to a specific construction project. For instance, material and part costs, properties like thermal and insulation characteristics, etc. These are attributes related to objects and metadata in the combined design model.
3. The Problem of Interoperability
This section is covered through a clear explanation of the topic of interoperability, an overview of the failed promise of IFC, and a commentary on ontologies from the perspective of the kinds of problems they can be used for addressing.
3.1. Understanding Interoperability
The most basic aspect of the construction project for which digital interoperability is required is the design phase. Designers from different disciplines work on their design discipline models independently yet need complete and continuous visibility to work done to other design discipline models. For such interoperability to be practically useful, model changes have to synchronize ubiquitously between all common design software, such as Archicad, Tekla Structures, and Revit.
Interoperability is also required for other aspects of the construction project and its various phases. For example, the flow of data from the combined design model to costing, scheduling, supervisory, fabrication, and manufacturing software systems. While these are outside the scope of this article, it is valuable to acknowledge these requirements.
3.2. The Failed Promise of IFC
The industry standard to solve the problem of digital interoperability for synchronizing multiple design discipline models is the Industry Foundation Classes (IFC) format. IFC has fundamental weaknesses, such as how it leaves compliance (with IFC) to the discretion of each design software vendor. Further, its primary goal is to allow design discipline models of one discipline to be used as reference models for other disciplines. This is in stark contrast with what is needed i.e. allowing building objects to be shared between multiple design discipline models to be automatically and continuously updated across all design discipline models within a given project.
Practically speaking, IFC implementations leave designers complaining about unsupported building objects and delays caused by waiting for IFC files to load in their design software. In some cases, delays persist even if the IFC file was exported from the same design software it is imported into. Further, since the process of sharing and importing IFC files is manual, it depends fully on the designer’s discretion on when they publish changes to be shared with other disciplines or when they load the changes made by other disciplines.
At best, this lack of ubiquitous synchronization of changes between models leads to increased project cost and a lack of confidence in the combined design model. At worst, it manifests as errors in the combined design model, leading to the project going over time and budget.
3.3. What Ontologies Can Solve?
In the past few years, there has been a lot of buzz around the concept of ontologies and how they can be applied for the betterment of construction projects. Ontologies work well to encompass the entire universe of construction data — the design model, metadata, auxiliary data, and reference data. Ontologies can also be useful in the way they bring semantic order and consistency to all the data mapped in the ontology.
Well-structured ontologies accomplish this by establishing a hierarchical semantic structure where all parameters/attributes have singular and unique naming. All participants in a construction project must transform the data they generate to fit into this structure. This laborious process overcomes naming inconsistencies between different data sources as well as ensures that the structure neatly indicates the purpose of each parameter or piece of data.
Ontologies, however, are not useful for generating the combined design model. Being semantic data structures, to be operationally useful, ontologies require to be wrapped into software intended for such a purpose. Each design software and other software used in the project would then have to be integrated with the software in which the ontology resides. In other words, we don’t end up any closer to solving the interoperability problem, but we further complicate solving it.
4. Solving Interoperability
In this section, we will introduce the actual solution, and therefore, we return to the fundamental problem — the lack of interoperability between construction design software — and the source of that problem.
The source of the problem lies in the fact that different design software arranges building objects and their metadata differently. In part, this is caused by the fact that each software focuses on the requirements of a specific design discipline (e.g. ArchiCAD focuses on architecture).
While there are collaborative efforts, for instance, to allow designers from a specific discipline to work on their design discipline model collaboratively, for the most part, these efforts do not readily extend to cross-discipline collaboration. The problem is further exacerbated by the existence of different construction design software walled-gardens (Nemetschek group, Trimble, AutoDesk, etc.), making universal design software interoperability much harder to accomplish.
Today, there is no tool or platform which harmonizes different disciplines as well as the different software walled gardens and allows cross-discipline collaboration between designers, enabling the combined design model to be built seamlessly with minimal friction and reversion of changes. The impact of this on the design and later stages in the construction project lifecycle is tremendous.
At aecmaster, since 2019, we have tirelessly challenged this status quo. In 2023 aecmaster DesignFlow, the world’s first zero-code construction design interoperability solution brings ubiquitous model synchronization to construction projects of all sizes.
