Source graphic for image montage: © Who is Danny – stock.adobe.com
How to handle information requirements directly in the authoring software
Error prevention over error correction
Anyone working in the construction sector knows this scenario only too well: Data that is indispensable for project implementation is outdated, inconsistent, incorrect or may not have been communicated at all. Imagine the following: The painting contractor paints the entire ground floor pink, and someone realizes that they actually wanted light blue. It may sound absurd, but as you are reading this article, this is actually happening in thousands of construction projects around the world at data level. And we always act as if data was cost-free and as if the only thing better than tons of data was even more data. But someone has to enter and should ideally also check that data. Every additional iteration means more costs and more stress. This applies to both the virtual and real world: Fixing errors is time-consuming, avoiding errors is difficult. But why actually? We simply need everyone to be clear about what is required, when, from whom and in what quality. It can’t be that hard to communicate this!
For this reason, it is recommended to precisely specify the information requirements before the start of the project, ideally starting with the client and down to the attribute level. The DIN EN ISO 19650 series shows the processes and roles involved in requesting and providing information. In addition, the method for defining the required depth of information is defined using the Level of Information Need (see e.g. DIN EN 17412-1). The result of preparatory planning are supporting documents such as client information requirements (AIA: Auftraggeber-Informationsanforderungen) and BIM execution plans (BAP: BIM-Abwicklungspläne), traditionally in the form of PDF or Excel documents. Some might point out that it’s at least a digital solution, while those who are supposed to work with it scroll through the tables looking for answers. Quality assurance is implemented by setting up inspection rules that are created in specialized software based on the higher-level structure, allowing for an automatically created quality barrier. If provided data does not pass this barrier, a revision request is sent back to the modeling level and we try again.
Testing software now makes it possible to achieve a high-quality result. However, this does not make it particularly easy, because it is important to pay meticulous attention to the requirements in the authoring environment. At least if you want to avoid time-consuming and expensive iterations when testing. A glance into reality once again leads to a hasty conclusion: BIM is complicated and is nothing but a distraction from work!
What’s missing is a way to deal with these requirements naturally. What’s missing is the overarching structure that understands my authoring software and can offer me a view from it. What's missing is an environment in which I can't break the rules of the game in the first place.
Information Delivery Specification
The Information Delivery Specification (IDS) is a new approach to the technical specification of such information requirements. IDS is a manufacturer-independent standard created by buildingSMART for the digitally interpretable definition of information exchange requirements. In contrast to Model View Definition (MVD), IDS focuses exclusively on alphanumeric requirements. It specifies which properties with which content (values and units) should ultimately be assigned to which objects in a project. IDS is therefore perfect for defining the alphanumeric information content (Level of Information - LOI).
As an alternative to simple definition tables, IDS now offers a standardized, digitally interpretable way of integrating this information into the automated BIM process (see Fig. 1). This can be done in two ways:
- As a configuration file for an authoring software to automatically create the required information structure.
- As a configuration file for testing software to automatically fill in test rules.
That way, the information flow between the definition and testing of model content is bridged with the help of a standardized format. In addition, IDS enables a more precise definition of model requirements. Up to now, alphanumeric information has mostly been specified at class level (e.g. properties required for IfcSpaceHeater). With IDS, requirements can also be set up depending on attributes, properties, external classes, relation ships and materials. For example, it makes sense to supply hot water to bidets, but not to urinals. Or the fire resistance class of a fire damper must begin with “K”. The structural overview of such details enables the corresponding elements to be filtered and allows requirements to be mapped much more precisely.
IDS and LINEAR Solutions for Revit
So much for the theory. In practice, the first implementations already exist that allow the automated transfer of IDS specifications to coordination software test rules. This is a good first step, but actually only half a step. What is still missing is an automated transfer of technical specifications into the information structure of the authoring environment. And even if that represents a huge step forward, one should not stop there, because good preparation on the modeling side opens the door to much more than that. It also offers in-process assistance when entering the results. If I know that, according to my IDS, fire resistance classes from the list F 30, F 60, F 90 must be specified, why should I be able to enter anything else at all? If my room numbers are to be assigned according to the format “two-digit floor number + hyphen + three-digit index” (e.g. 01-234), why doesn't my authoring environment point this out to me straight away?
The answer to the above questions is as simple as it is humbling. Revit doesn't know IDS and IDS doesn't know Revit. We therefore need to bridge the gap between these two worlds. And with its dynamically configurable properties window. It all began in version 24, with the option of specifying element classes beyond the Revit categories and combining them with property sets, rules and maturity models. We are now taking it to the next level in version 25 to include the ability to create the required data structures semi-automatically based on our own IDS-based standardization.
Why only semi-automated? The answer remains the same. The two models cannot fully communicate with each other; there is no unambiguous mapping of the IDS to the Revit data model. We must therefore gradually enrich the information in the IDS so that it can be transferred to Revit models with as little loss of structural knowledge as possible (see Fig. 2).
In addition to some detailed technical issues, the following points need to be addressed carefully:
Selection of the specifications to be imported
An IDS can contain a large number of specifications, not all of which may be relevant to the current planning task or the technical model. Therefore, the first step is to determine which specifications are to be adopted. The LOI can also be assigned to individual specifications here.
Assign IFC Classes to Categories
IDS is usually based on the IFC classification, Revit is organized in its own categories. The IFC classification in Revit is therefore defined structurally by the component type in a predefined parameter, regardless of the Revit category. For example, “HLS components” refer thematically to dozens of IFC classes, from containers to central devices.
The assignment of categories to IFC types is thus not clearly defined and must therefore be added during an import. To simplify this task, LINEAR Solutions offer the option of deriving established assignments from a specific model, if they have already been stored therein.
Assign parameters to definitions
IDS identifies IFC parameters by naming and assigning them to property sets (Psets). The Revit environment does not recognize such Psets and also has to deal with content from various sources. To resolve the feared contradictions, in Revit, a text file is maintained that contains the definitions for the so-called “Shared parameters”. There, the blueprint of a parameter (name, data type, etc.) is saved and receives a unique identifier. This process makes it possible to standardize parameters in component models and the labels based on them across projects. To ensure a smooth transition from IDS via a Revit file to IFC, the platform generating the IDS must therefore provide additional metadata in the form of parameter files for the Revit authoring environment and Pset configurations for the IFC exporter. If a suitable definition file is available, the LINEAR environments take over the assignment automatically. Alternatively, suitable definitions are created for further processing in Revit.
Conclusion
The IDS standard of buildingSMART opens up the possibility of truly consistent data use, regardless of the software platform used. The definition of project standards down to the attribute level offers an attractive alternative to textual or tabular requirement descriptions. Making this easy to handle in practice will contribute significantly to the success of this approach.
The automated import of IDS specifications into a target platform such as Revit is a logical step so that the required structure can be taken into account without tedious and error-prone manual input. We have designed an import wizard that guides you through the process and takes as much information as possible from an existing model. This massively shortens the setup of a project standard, and the input check of data types and value ranges that is possible as a result can ultimately ensure the required data quality.
Now it's up to you:
Do you already have IDS specifications that you would like to test for practical suitability with our development team? Or perhaps you have ideas that could help us to further improve the described workflow? In that case we look forward to your feedback!
Sources and recommended literature
DIN EN ISO 19650-1 : 2019-08. Organisation und Digitalisierung von Informationen zu Bauwerken und Ingenieurleistungen, einschließlich Bauwerksinformationsmodellierung (BIM)
DIN EN 17412-1 : 2021-06. Bauwerksinformationsmodellierung - Informationsbedarfstiefe
Eichler et. al. – BIMcert Handbuch - Grundlagenwissen openBIM, buildingSMART, 2024
Would you like to read more articles like this? Vote for them (anonymously) here.