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.
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.
How does it work?
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.
Is it complex?
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.
Disclaimer
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.
Is it the future then?
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.
Don’t miss out on BIM and digital construction news: sign up to receive the BIMplus newsletter.
Comments
Comments are closed.
It’s undoubtedly the future, one that will require significant learning and adaptation. However, it’s unfortunate that it will likely undergo a prolonged period of what can be termed as ‘BIM abuse,’ akin to many other information requirement-based specifications, often presented in extensive written texts exceeding 60 pages based on templates. This misuse will inevitably impede investment in learning and education initiatives as resource is finite & dealing with the waste always removes more of the margins available. It’s crucial to note that this issue isn’t inherently caused by IDS or BuildingSMART but rather a consequence of how they are implemented.
I have no doubt that within the next year or two, we’ll witness IDS specifications appearing in tenders. However, I doubt they will accurately reflect the needs of contractors or the operational end-users who implement them because their true expectation is still the traditional e-paper and simple datasets. Subsequently, these initial IDS may be adopted as templates by numerous clients and contractors, merely as a checkbox requirement or based on advisory recommendations that they should rather than focussing on the why (review my BIM+ post on that!).
Until the principle of ‘Level of Information Need’ truly becomes ingrained in our practices, this may persist as a source of frustration rather than a valuable tool. This phenomenon is often denoted as ‘BIMWaste.’
Am I being overly negative? Perhaps. However, I believe evidence will emerge once these practices are put into action.
Those are excellent points, John.
Given BIM’s history to date, it is somewhat realistic to expect such outcomes even with IDS implementation. I’d be curious to learn how to overcome the same issues repeated throughout the last ten or more years. Education and upskilling spring to mind, but is it enough? I really like what has been done on the UK BIM Framework regarding education and free resources, yet it does not entirely prevent ‘BIMWaste’. Fighting bad requirements one project at a time works, but it might be too slow… Maybe ‘BIM Abuse’ is an inevitable part of any new process?
On the other hand, it seems we talk about information requirements from/to the client (appointing party). I am eager to see how IDS is utilised between appointed parties and lead appointed parties. Rather than having vague descriptions of what needs to be shared, IDS has the utility to be specific. I think one of the ways we can progress in the right direction is to specify our needs in a correct way, show tangible results and then lead by example. I believe contractors and appointed parties have a role to play here.
i used JCT/A37 to specify Employer Information Requirements.
regrettably I believe the Employer did not have systems in place to take the EI and integrate it within its asset management systems.