The Information Delivery Specification (developed by buildingSMART International) is a massive leap forward for information management, according to Vitalij Tetervov.
Information management in the construction industry was accelerated with the introduction of BIM mandates around the globe. The long promise was that users could check their deliverables automatically and it would be easy. Yet, a decade or so later, we are stuck with information requirements written in Excel or, in some cases, stored in databases that are not necessarily machine-readable, or at least interpretable by BIM authoring tools. This led the industry to create proprietary checking software, some built on openBIM standards, including IFC.
So what’s changed? Well, in 2021, I stumbled across the buildingSMART 2020 technical roadmap, which mentioned the Information Delivery Specification standard: a file format that promises to challenge pdf and Excel requirements. I became curious about this subject as I thought it could change the way we write, distribute and check the quality of our data.
This is not a paywall. Registration allows us to enhance your experience across Construction Management and ensure we deliver you quality editorial content.
Registering also means you can manage your own CPDs, comments, newsletter sign-ups and privacy settings.
What is the Information Delivery Specification?
The best way to describe it is to follow the definition from buildingSMART International: “An Information Delivery Specification is a computer interpretable document that defines the Exchange Requirements of model-based exchange. It defines how objects, classifications, properties and even values and units need to be delivered and exchanged. This can be a combination of Industry Foundation Classes (IFC), Domain Extensions, and additional classifications and properties (national agreements or company-specific ones; either stored in buildingSmart Data Dictionary or somewhere else).
“This is the standard to use to define your Level of Information Needs. It brings validation of IFC to the client, the modeller and the software tools that perform (automated) analyses. IDS is a core component that can be used as a contract to deliver the correct information. It holds the ability to create localised and use-case specific requirements for your projects and asset portfolio. The IDS is the solution for predictable and reliable data exchange workflows.”
buildingSMART International even provides a workflow to show how the information can be created, shared and checked independent of your software choice as long as it has IDS implementation. It also shows the connection to buildingSMART Data Dictionary, which can be used when writing IDS and enriching the models to provide consistency in data definitions.
IDS has been coined as clash detection for your data. An IDS is a file format ending in .ids that contains a list of information specifications. According to information on GitHub, these specifications have three key ingredients:
- Description: a description of why the specification is important to your project and instructions on how to achieve it. This part is designed for humans to read and understand why information is being requested.
- Applicability: the type of objects the specification applies to. There are many different types of objects in IFC models, such as walls, doors, and windows, but each specification will only apply to certain objects.
- Requirements: what information is required for the objects specified in part 2, such as required properties or classifications.
For example, the specification of “all walls must have a fire rating property” is structured like so:
- Description: wall fire ratings are critical for building code compliance.
- Applicability: this specification applies to all wall objects.
- Requirements: the aforementioned wall objects must have a fire rating property.
Interestingly, these specifications do not have to come directly from a client. Imagine that your cost consultant on a project needs all modelled elements to have an NRM 3 classification to use this information to connect to their cost databases. This requirement could be expressed through the specification and checked automatically, supporting the essence of the ISO 19650 series, which promotes structured and detailed information requirements and exchanges.
I bet you can already see the potential use cases on your projects, whether they are specific client requirements, or you want to check asset data for the operational stage or something entirely different.
Well, you have to be in tune with the IFC schema. Fortunately, the supported IFC schemas are IFC4X3, IFC4 and IFC2X3. You will also need some understanding of entities, properties, classifications, etc. In fact, there are six facets that can be used for applicability and requirements of specification:
- Entity – i.e. IfcDoor, IfcWall etc;
- Attribute – i.e. Name, Description etc;
- Classification – i.e. Classification System, Classification Reference (Uniclass 2015, Pr_60_60_08);
- Property – i.e. FireRating, AcousticRating etc;
- Material – i.e. concrete, wood etc;
- PartOf – i.e. duct must be part of a distribution system, boiler must be located in a space etc.
These assets can be tailored in multiple ways to describe their applicability and requirements. Additionally, IDS allows for complex restrictions, which may be specified in:
- Enumeration – For example, you may specify that a concrete strength grade may be either “25”, “30”, “35”, or “40”.
- Pattern – For example, if you want to specify that door types must be named using the convention DT01, DT02, DT03, etc, you can create a pattern defining that the letters ‘DT’ should be first, followed by two numbers.
- Bounds – For example, you might specify that a value needs to be “more than 3” and “less than or equal to 10”.
- Length – For example, if you specify a length of 3, then values that are three characters long, like “ABC” or “123”, will meet your requirement. Other values, like “AB” or “ABC123” will not meet your requirement.
In short, you can make your specifications as straightforward or complex, depending on the actual need. This brings us yet again closer to the promised information management and the Level of Information Need framework (at least the alphanumerical requirements) that can actually be machine-interpreted and human-readable.
Most of the above information can be freely accessed on GitHub in greater detail and with many examples. Why did I repeat this information? Well, I don’t think many people go on GitHub for a casual read.
Can I start using it today?
Yes. While still young, IDS is implemented in numerous applications, including Plannerly, Solibri, and CoBuilder Link. Several free applications exist, including ACCA.us, BlenderBIM, IFC Werkzeug. The implementation is at various stages, so some experimentation and testing are required.
While it does not solve every problem, IDS is a massive step in the right direction. The current version tackles basic information requirements, but this is already a leap forward, given the state of information management in the construction industry. For example, you won’t be able to check if all door types are unique or if the site boundary is 3m from a wall.
However, let’s not forget that this is the first iteration of the new format. I think we can expect a lot more complexity in the future. I hope that IDS gets deserved traction from major software providers and that AEC professionals adopt this format to write and check specifications.
Thank you to the buildingSMART community and the people who made it possible. This is the most exciting development in recent years, which will finally propel the use and trust in data.
Vitalij Tetervov is co-founder of yBIM.
