Methods to specify information requirements in digital construction projects
With the ever-growing digitalisation of the built environment, specifying information requirements (IR) is crucial to control the Building Information Modelling (BIM) data. However, encoding these requirements is subject to a wide range of possibilities, making it difficult for the users to choose the most suitable method.
Together with Léon van Berlo, Marzia Bolpagni, Thomas Krijnen, André Borrmann and myself – Artur Tomczak, we attempted to identify and compare both standardised and non-standardised methods to specify information requirements, such as:
- Product Data Templates (PDT),
- Model View Definition (mvdXML),
- Information Delivery Manual (IDM),
- Level of Information Need (abbreviated in this article as LOIN),
- Data Dictionaries (ISO12006),
- IFC Property templates,
- Information Delivery Specification (IDS),
- Linked Data with SHACL,
- non-standardised textual or spreadsheet documents (DOC & XLS)
- proprietary solutions, such as Solibri
- other such as dedicated visual programming scripts.
The list is certainly far from complete and more methods exist, highlighting the discussion’s importance on their differences. You can read more about individual methods, their purpose and their characteristics in the conference paper summarising our work.
To show some of the differences we gathered a few examples of how the same requirement can be defined depending on the method of choice.
Example 1. Textual file explaining the requirement. Source: Statsbygg’s SIMBA (https://sites.google.com/view/simba-bim-krav)
Before we did the comparison, we defined the criteria for it. The choice was built on standards and available use cases that can be found in the buildingSMART’s Use Case Management Service (UCMS). Below is the summary of our comparison criteria:
- Standardised – is the method formally defined in a standard?
- Applicability – can a requirement be assigned to elements it applies to, for example, a wall or a pipe?
- Information type – can a requirement query specifically for a property, material, or else?
- Data type – can a field be required to be a text, number, boolean or else?
- Unit of measure – can value be of a particular unit, such as kilogram?
- Description – plain text descriptions are handy for unambiguous contractual definitions. Does the method allow for adding it?
- References – The global community speak different languages, uses other units and has other names for similar concepts. What IFC calls ‘thermal transmittance’, the ETIM classification calls the ‘U-value’. While experts can interpret such ambiguities, machines and software developers can not, so references to a common standard are desired to help avoid misunderstandings.
- Value constraints
- Equality – asking for exact literal values
- Range – numerical values might be limited to defined range boundaries, as in the case of relative humidity, which is expected to be between 0 and 100 percentage units
- Enumeration – allowing for multiple possibilities
- Patterns – variance of notation validated using Regular Expression patterns. For example, a value should start with the letters XYZ followed by any capital letters
- Existence – When no element matches applicability, whether the model should pass such validation depends on how a method specifies information existence. Propositional logic only deals with the truth value of propositions and logical connectives. Still, to fulfil use-cases needs, the method should also support first-order logic, allowing to make statements concerning a population by introducing universally (∀) and existentially (∃) quantified variables. For example, the universal requirement ‘all walls need a length property’ would be satisfied with the lack of any wall but fail if only one of many walls does not have a length property. In contrast, the existential requirement ‘a wall with a length property must exist’ would correspondingly result in opposite failure and success.
- Documents – The requirement for content existence can also extend to documents such as attached files, drawings and images.
- Structure – a requirement could specify how an element or data should be structured in relation to other objects. For example, is it enclosed in a larger assembly or contained within the spatial construct? Structure applies to spatial composition and how the data is structured in the model hierarchy.
- Geometry – Requirements can also refer to spatial information.
- Representation – In many cases, it is sufficient that geometry is described with boundary representation or mesh, but in some, it is needed that representation describes embedded logic, explaining how the volumes were procedurally extruded. An example of such a requirement is the SIMBA use case from the Norwegian Statsbygg, which demands that the IfcSpace object extends from the upper surface of a floor slab to the underside of a slab above.
- Detailedness – Information requirements can also demand a particular level of detailedness, meaning what needs to be modelled and to what precision. The more schematic model usually takes less memory and time to create, but a more granular one can provide more details necessary for the later design stages.
- Metadata – The context of a requirement is given by providing metadata.
- Purpose – according to EN 17412-1, validation differs from general verification by having a specific intended purpose.
- Actors – Some use cases need to specify an actor to assign the responsibility for fulfilling the requirement to a person or role.
- Process map – use cases might derive requirements from workflows, so a method should support mapping a requirement to a process map with data exchanges.
- Expressiveness – these include the expressiveness of standards, meaning the breadth of ideas they can describe and how ambiguous they are.
- Dependency – on industry classifications and schemas that define the semantics
- Technological agnosticity – the complexity of transcribing a standard from one file format or implementation to another. The European Interoperability Framework discourages over-restrictive obligations to use specific digital technologies.
- Governance – Finally, there are questions about the method's governance: how it is managed, standardised and transparent, whether it is coordinated and how easy it is to influence change.
Our results show that no single solution covers all the aspects of the analysis of use cases. Despite overlaps, each method has a different intended purpose and should be selected consciously. All described methods have reasons for existence and play an important role in the ecosystem. However, because their boundaries are hazy, they tend to be misused, causing disappointment and limiting digitalisation performance. We present a summary of the comparison in the two tables below. The first table shows aspects that are either supported, partially supported or not covered by a particular method. The second table shows a grouping of methods with regard to the criteria.
The differentiators identified by this research are explained in the next section.
Table 1. Information requirement support in the described methods.
Suitability of each method
Data dictionaries and PDTs are the best fit when properties are specified at a global level, shared with industry, not project-specific. They can also indirectly be used as a reference when defining requirements in all other methods to provide a shared understanding. Since PDTs do not restrict how to reference norms and different values, there is a risk that equal content will be defined and referred to differently, interrupting interoperability and automation. The bSDD has mitigated this by restricting the units, references and country codes to a common list. LOIN is better suited for individual projects since it includes how information matures during the design, only asking for what is needed at a certain time for a specific purpose. It also serves well for contractual deliverables, including geometrical requirements and documentation. However, LOIN’s schema – EN 17412-3 – is still under development and not available for evaluation. The EN 17412-1 standard is also now in the process to be adopted at the ISO level as ISO 7817 series. The IDM has the crucial advantage of linking data handovers to exact processes and workflows. Its extension – idmXML – defines requirements in a computer-readable but not necessarily computer-interpretable way. For technical interpretation of human-readable instructions, it refers to MVD definitions.
For data to be trustworthy, it should undergo a validation process. According to EN 17412-1, validation is a ‘confirmation, through the provision of objective evidence, that the requirements (...) have been fulfilled. However, computer interpretability comes at the expense of expressiveness. The IfcPropertyTemplate is the most direct form of preparing placeholders for properties within the IFC schema, embedded in the schema itself. The same fact is why it is rarely used as a separate document, is limited to basic features, and does not allow for validation if elements are present. Despite being suggested by IDM, the MVD is primarily made for software implementation rather than information requirement purposes (although there have been attempts to include those in later versions). Its complexity stems from the ability to both define concepts with IFC instance graphs and constrain them. MVD has the advantage of being self-contained and able to express new ideas. However, being a bespoke, custom-made solution makes the software implementation only specific for supporting mvdXML, and readily available software libraries are likely not available. The complete picture can be drawn after considering their existing implementations. It was found that both mvdXML and IPT are not widely adopted and are hard to author in current tooling. IDS has been identified as the most advantageous method for automated compliance checking by validation of the alphanumerical IR. It supports information requirements authoring by providing users with a set of possibilities on what can be required of the models. On the other hand, unlike IDM and LOIN, IDS is limited to IFC entities and their properties, making it only applicable to openBIM compliant tools. IDS is not made for geometrical requirements or mapping requirements with project processes.
Unstandardised methods, such as text documents, spreadsheets, Linked Data with SHACL and Others, overlap with all of the above, overcoming some of their limitations and adding flexibility both in definition and time of implementation. However, they also come with a trade-off of limited transparency and integration with the entire ecosystem. The plain text allows describing all possible aspects but is loose and depends on the interpretation. Linked Data with SHACL and Others require specialist knowledge to modify. In light of this knowledge, the question arises of how much a standardised approach improves the collaborative workflow, reduces risks of errors and misunderstandings, and allows for optimisation.
There are multiple ways how we can require information on digital construction projects. There are clear advantages and disadvantages of each method. The legal advantage of using text has a trade-off for automated compliance checking. However, automatic checking limits flexibility. This study shows how existing methods differ and what are the advantages and purpose of each of them.
The resultant paper will be published later this year and can be tracked at:
The work was also presented at the CIB World Building Congress in Melbourne on 27th June 2022 (https://www.cibwbc2022.org/), and you can watch the recording here: https://youtu.be/43YCXsYvEKs.
Artur Tomczak, August 2022
Reach out to me via Linkedin: https://www.linkedin.com/in/artur-tomczak-5b66444b/