09-01-2024 - BuildingSMART's open standard IDS (Information Delivery Specification) has now been implemented within Pillr. IDS revolutionizes the way you create and share information requirements for your BIM project. In addition, IDS will promote communication, verification and accuracy throughout the building lifecycle. How does that work and what can you expect from it?
What is IDS?
As just indicated, IDS is a new open standard from BuildingSMART. IDS stands for Information Delivery Specification. This is a computer-interpretable document that defines exchange requirements of model-based exchange. It defines how objects, classifications, properties and even values and units are to be delivered and exchanged. This can be a combination of Industry Foundation Classes (IFC, also an open standard of BuildingSMART), domain extensions and additional classifications and properties. Properties can be national and/or company-specific agreements. It is important to understand that this standard can be used to define the level of information needs. And can therefore also serve as a contract to provide the correct information. The advantage of IDS is that it can be used both as a human-readable document and also as a machine-readable document. In other words, 1 document for you and your computer. IDS thus becomes a standard that ensures a predictable and reliable workflow for data exchange.
Information requirements
The current way of sharing information requirements in a BIM project has many variants. Information requirements are recorded in various file formats. Think of PDF, Excel, Word, Powerpoint, etc. In fact, the requirements are often recorded in multiple formats and these are all distributed to the project. And each company has added its own sauce to this. And so two important problems immediately arise. Firstly we have the problem of version control. Since the information requirements appear in 2 sources and can still be changed, we quickly lose track of what the latest and correct version is. And perhaps the biggest problem, all formats in which these information requirements are recorded must be read, interpreted and implemented by humans. And that is exactly the point where things go wrong. This is exactly what IDS will help us with.
Clash control for data
With IDS we will soon be able to automatically check rule-based data. Something that has been possible on Pillr from the start. With this we can actually talk about a Clashcontrol for data. Because IDS is an .xml schema, it can be read by both humans and computers. Let's dig a little deeper into the IDS. Each specification consists of three parts:
- Description: A description of why the specification is important to your project and instructions on how to achieve it. This section is intended to help people read and understand why information is being requested.
- Applicability: to which types of objects the specification applies. There are many different types of objects in IFC models, such as walls, doors, and windows, but each specification applies only to certain objects.
- Requirements: what information is required for the objects mentioned in part 2, such as required properties or classifications.
For example, the specification of "all walls must have a fire classification property" is structured as follows:
- Description: Fire ratings of walls are critical to building code compliance
- Applicability: This specification applies to all wall objects
- Requirements: the above-mentioned wall objects must have a fire-resistant property
How specifications can describe information
Applicability and requirements are described using Facets. A facet describes information that a single entity (e.g. wall, door, etc.) may have in the IFC model. A Facet accurately describes its information using fixed Facet parameters, so computers can understand exactly what information is being sought.
When a Facet is used in “applicability,” the Facet describes information that an entity must have for the specification to apply to the entity.
When a Facet is used in “requirements,” the Facet describes information that an entity must have to meet the Specification.
There are 6 Facets:
You can combine multiple facets of “applicability” or “requirements” to describe a wide variety of specifications. Some facets may have optional facet parameters. For example, if you want to specify that a property must exist, but not the exact value, you can leave the value parameter of the property facet empty.
You can also specify a list of valid values, or a range of numbers, or a text pattern for some facet parameters. We call these regular expressions. For example, you can specify that the fire classification property may only choose from the value "0_min_wbdbo", "30_min_wbdbo" or "60_min_wbddo" or that the NL/SfB coding must consist of 4 digits with a dot in between [0-9][ 0-9].[0-9][0-9]
Finally
The first version of IDS focuses on basic information and relationships in IFC that are common to all disciplines. More advanced information requirements are currently outside the scope of IDS. For example, geometry checks, checks that depend on calculated or dynamic values, checks that refer to data outside the IFC model, or the use of domain-specific IFC relationships are not possible. We keep a close eye on these developments. Want to know more about the IDS and facets? Read more.