BIM Busters - IDS will solve our data quality issues
IDS or Information Delivery Specification is currently very en vogue and it's a very powerful standard - but it is not the holy grail solving the data quality problem.
2023 was the year IDS became famous, and Solibri and BIMcollab, as mainstream tools, implemented it. Now, even people who don't know much about BIM or technology see IDS as the solution to the data quality problem. So it's time for another BIM buster...
IDS is a text-based exchange format for IFC quality assurance rule sets. And that is great, but more is needed to solve the main problems.
IDS from a client's perspective
The main problem for clients is to define what (data) quality is. What does the client need for the handover, and what is necessary for project quality assurance? Once this is determined, the client needs the data quality assurance rules to check it. Most clients shy away from defining their data requirements because this is a lot of work. But this is the starting point for any IDS use. Furthermore, the client needs to:
Look at the client's processes and decide which of these processes need data from a model. Which processes are value-adding, which have a business impact, and which can be neglected?
Look at the values that are written inside the attributes. Let's assume an attribute of fire safety. Is it filled with a value "EI90" or "EI-90" or any other variations? Without defining this, a data handover and any automation is impossible.
To communicate these requirements, the IDS can help with the metadata. Geometric modeling rules can not be formulated with the IDS. But especially for quantities these geometric rules are necessary.
Communicate geometric modeling requirements/guidelines to ensure data consistency and usability. For example: Which volume is relevant for a Facility Management (FM) solution? From the top of the floor to the suspended ceiling or the slab? If this is not defined, communicated, and enforced, you won't be able to use the data.
Set up the quality assurance process and define who is responsible for checking the deliverables. Not only in one but in all the projects.
Set up a handover workflow and automation. Very often, this won't be a straightforward 1 to 1 relationship but some kind of aggregation. For example, in the BIM, every space has a classification and sqm, but the FM solution needs the sum of the interior usable spaces. So these rules need to be documented and the pipeline needs building.
It's not enough to define the standard and the IDS once. The systems' values could change, so a process to update the rules is necessary. Firstly, determine how to find changes and when and who is responsible for implementing the changes in the template.
Lastly, who communicates the changes to the running projects? It probably would be better not to share the changes to every project. It's better to decide on a project-to-project base to avoid claims. So, some data governance and guidelines are necessary.
So, the IDS helps in one of these topics: communicating the metadata requirements to the teams on a technological level!
It's great that you can now provide rule sets in a standardized format. And that some rule checkers can import them. But the other seven topics are much more important to solve, and that needs hard work in the organizations and the mindset of people!
IDS from a planner's perspective
There is another myth surrounding the IDS. Some clients believe they define an IDS and hand it over, and this IDS magically configures the planner's modeling tool.
Only Vectorworks from the mainstream tools has an IDS important, and even if your tool supports it, I recommend NOT to use it as a planner to configure your tool.
The reason is simple: Very likely, planners work for different clients with different standards, so it does not make sense to work with the client's standards it’s better to have an own company standard. It's comparable to a layer standard for FM. How many offices do you know that use the client's layer standard during the project phase - exactly - none! It's economically not feasible to change the standard in every project.
Offices lose flexibility and can't easily switch employees between projects.
Employees would need extensive project-specific training.
It's hard to build efficient automated workflows, e.g., quantity takeoff for cost calculations when the standard changes in every project.
So, build your standard and translate it (automatically) for handover to the client! The translation is easy once the data is structured!
Therefore:
Use the IDS to configure Quality Checkers quickly.
Build up your standard and, at the beginning of a project, set up a workflow to translate the office standard to the clients.
Make sure your standard is as simple as possible so that it's fun and easy to model. Avoid klicks!
Avoid any duplication of data entry. Every duplication exponentially increases the number of necessary quality checks. When you have one required attribute, you need one rule to check it. When you have two attributes, you need three rules. Two will check the content, and a third will crosscheck consistency. E.g., the Name of the Space can be an office, meeting room, or balcony, and the attribute IsExternal can be TRUE or FALSE. You must check if the attribute name contains one of the approved names. Secondly, if the attribute IsExternal has one of the two values. And when you need to check if the office has the correct attribute, IsExternal = FALSE. Instead of checking, setting up some automated enrichment based on some easy-to-enter value, e.g., the room name, would make much more sense. Especially when you have more attributes to crosscheck the doubt of necessary rules becomes unmanageable.
Don’t forget the geometric modeling guidelines and standards. They are essential for cross-project comparability and data use!
Conclusion
Having a standardized format - the IDS - to exchange technical data is excellent. It will increase data quality or at least replace the many bad Excel sheets that try to define requirements inconsistently. However, it does not solve the extensive work of defining the requirements as a client, and it is unsuitable to configure the planner's modeling tool.
So, every client should start by doing their homework to define their data requirements and when they can utilize the technical solution of an IDS.
Every planner should start setting up their BIM-based standards and workflow, and when they win a contract from a client with requirements, they can set up a translation process.
IDS is an exchange format for checking rules for the information content of components. A model checker or quality checker goes through component by component and checks whether the applicability (i.e. the filter) applies in order to then check the attributes and properties as well as the values entered againts the requirements. I don't think IDS is suitable for exchanging information about properties. It has RegEx (regular expressions) to solve problems easily like those described in chap. 2 -> "EI90" or "EI-90“. But how can you reverse uncertainty into Psets? Easily it is possible to check all Qto_?????BaseQuantities independent from the IfcEntity.
But there is a standard für defining Property Sets „PSD“ http://standards.buildingsmart.org/IFC/RELEASE/IFC4/FINAL/PSD/PSD_IFC4.html. Why does the AEC software industry is not using this PSD for information input? The only question might be the hope for selling one or two licenses more...