The Story
For a long time, I have been searching something to do the quality control for IFC files and the validation to verify IFC files by a way of algorithm other than a human visual check. This idea starts with my post in October 2020, To be standardized: extra efforts for entering the BIM processes.. I have done a lot of research about how to automate the human visualization verification process, and I found the bSDD - buildingSMART Data Dictionary. I think it might be able to solve the questions. Then I have participated in the bSDD 2021 Hackathon, with their new released buildingSMART Data Dictionary - bSDD OpenAPI, I finally found the right tool to start this project. Then one week after, I submit my project IFC Validator and open-resourced the entire project. Now the release v1.0 is available and free for all win 10 user.
Download : IFC Validator - Microsoft Store
Open-resource : IFC Validator - Github
Quality control in IFC is hard
As we know, IFC was created for a standard data exchange system. It solves a large part of the information exchange problem in the engineering industry, and allows us to transfer data and exchange data in different work environments. But in fact, the quality of information cannot be known from the carrier of the information. IFC is like a truck, we define what kind of items are in which color box, and what kind of items should be placed where. Our data is like the items in the box. The items are integrated according to the rules of boxes and delivered by trucks.
However, in actual projects, due to the uniqueness of the project, the data required by different projects at different stages are not the same. So, IFC is designed to be very inclusive and adaptable, to help us deal with various project situations and different needs. Just like you don’t know what exact items will be in the box, you can only design a box that fits more types of items. But IFC itself does not have the ability to check information, just as a truck cannot know whether the items can meet the needs of customers. There is no way to evaluate the value of information and its authenticity in the carrier of the information.
Because in essence, this is a semantic problem. More precisely, a translator is needed between human-readable sentences and machine-readable data. This requires defining the meaning of the vocabulary and telling the machine what the data represents. For example, if it is specified in the project specification: "All walls need to have information on the fire rating and sound insulation rating for future simulations". Translated into a machine-readable language should be: "All IFCWall must have property FireRating and AcousticRating".
But if this property is added in a variety of different ways, this semantic problem will be enlarged. For example, the fire-resistance rating is called "Résistance au feu" in French, and it is divided into five level M0-M4. In the English environment, it is called "Fire-resistance rating" and is divided into Class 125, Class 150 and Class 350. In the Chinese environment, it is called "耐火等级" divided into 1-4 grades. The machine has no way to understand the meaning of language, so for "Résistance au feu", "Fire-resistance rating" and "耐火等级", the machine cannot know that these three attributes actually describe the same data. What's more, even if we use the same language, the machine cannot know that "Fire-Rating", "FireRating" and "Fire-resistance rating" describe the same data. Therefore, considering the different rules in different countries or projects, this makes the data exchange more difficult.
bSDD - Make all roads lead to Rome
It is to solve the problem of data exchange under multiple standards, bSDD - buildingSMART Data Dictionary was created. What is bSDD? In my opinion, it is a bridge connecting different standards in different work environments. Because in different working environments, we have different vocabularies and ways to describe the same information, which can be regarded as different expressions of this information. Linking these different expressions in an organized and structured way is the meaning of bSDD.
For example, "IfcWall" has the "FireRating" attribute under the IFC standard. Under another standard CCI Construction, there is a classification called "Wall construction" that can have the same "FireRating" attribute, and this classification contains the information of relation shows it's related to IFC entity "IfcWall". These different expressions in different standards are linked together through internal connections. This standardized link and common language for classification with their properties can further solve semantic problems and enhance data quality and information consistency.
A two-way bridge makes information better
If we regard the bSDD as a bridge between actors, then with an entrance requirement, we can make sure the right information is onboard. Like the official example in SketchUp and the work of BIMData.io in the hackathon, with the provided classifications and properties by bSDD, user can easily create data in a BIM model in a standard way. Especially like BIMData.io, the user is already in a CDE workspace, the standard way of creation will contribute a lot for the information consistency for all member involved in the project.
But only create data with the standard process is not enough to ensure the quality of information. We need also the exit check for the bridge to make sure the information is delivered correctly. That's my idea of IFC Validator comes from. Based on the common knowledge of bSDD, all the information delivered can be verified to meet the requirement of the client. If there are some unqualified data, it can give accurate feedback for the data provider to optimize the project. A two-way bridge just completes the workflow and could make the information better.
Is Not Ending
The IFC Validator is still a beta version completed in one week, and I will continue work on this repo. As I mentioned that I have open-resourced the entire project in Github, any kind of contribution is welcome.
And some improvements are already on the RoadMap:
- Use MVD to describe requirements and maybe replaced by IDS when it released
- Export sum report and export with entity detail
- Multi-domain support
- Sub-entity support
- Multi-thread support
- Multi-language support
Special thanks to Mr Frédéric GRAND and the bSDD support team for all your technique support.