IFC Validator, un outil simple pour le contrôle qualité d’IFC
L’histoire
Depuis longtemps, je cherche quelque chose pour faire le contrôle qualité des fichiers IFC et la validation pour vérifier les fichiers IFC par un moyen d’algorithme autre qu’un contrôle humain. Cette idée commence avec mon post d’octobre 2020, À standardiser : Effort supplémentaire d’entrer dans les processus BIM. J’ai fait beaucoup de recherches sur la façon d’automatiser le processus de vérification par l’inspection visuelle, et j’ai trouvé le bSDD – buildingSMART Data Dictionary. Je pense que cela pourrait peut-être résoudre les questions. Ensuite, j’ai participé au hackathon bSDD 2021, avec leur nouveau buildingSMART Data Dictionary – bSDD OpenAPI, j’ai enfin trouvé le bon outil pour démarrer ce projet. Puis une semaine après, je soumets mon projet IFC Validator et j’ai open-resourcé l’ensemble du projet. Maintenant, la version v1.0 est disponible et gratuite pour tous les utilisateurs de Win 10.
Télécharger : IFC Validator – Microsoft Store
Open-resource : IFC Validator – Github
Le contrôle de la qualité dans IFC est difficile
Comme nous le savons, IFC a été créé pour un système d’échange de données standard. Il résout une grande partie du problème d’échange d’informations dans l’industrie et nous permet de transférer des données et d’échanger des données dans différents environnements de travail. Mais en fait, la qualité de l’information ne peut pas être connue depuis le porteur de l’information. IFC est comme un camion, nous définissons quel type d’articles se trouve dans quelle couleur de boîte et quel type de boîte doit être placé à quel endroit. Nos données sont comme les articles dans la boîte. Les articles sont intégrés selon les règles des boîtes et livrées par camions.
Cependant, dans les projets réels, en raison du caractère unique du projet, les données requises par différents projets à différentes étapes ne sont pas les mêmes. Ainsi, IFC est conçue pour être très inclusive et adaptable, pour nous aider à faire face à diverses situations de projet et à différents besoins. Tout comme vous ne savez pas quels articles exacts figureront dans la boîte, vous ne pouvez concevoir qu’une boîte qui convienne à plus de types d’articles. Mais IFC elle-même n’a pas la capacité de vérifier les informations, comme un camion ne peut pas savoir si les articles peuvent répondre aux besoins des clients. Il n’y a aucun moyen d’évaluer la valeur de l’information et son authenticité dans le porteur de l’information.
Parce qu’il s’agit essentiellement d’un problème sémantique. Plus précisément, un traducteur est nécessaire entre les phrases lisibles par l’homme et les données lisibles par machine. Cela nécessite de définir le sens du vocabulaire et de dire à la machine ce que représentent les données. Par exemple, si cela est spécifié dans le cahier des charges du projet : “Tous les murs doivent avoir des informations sur le classement au feu et le classement d’isolation acoustique pour les simulations futures”. Traduit dans un langage lisible par machine doit être : “Tous les IFCWall doivent avoir la propriété FireRating et AcousticRating”.
Mais si cette propriété est ajoutée de différentes manières, ce problème sémantique sera élargi. Par exemple, le classement de résistance au feu est appelée “Résistance au feu” en français, et il est divisé en cinq niveaux de M0 à M4. Dans l’environnement anglais, il s’appelle “Fire-resistance rating” et est divisé en classe 125, classe 150 et classe 350. Dans l’environnement chinois, il est appelé “耐火等级” divisé en 1 à 4 niveaux. La machine n’a aucun moyen de comprendre le sens du langage, donc pour “Résistance au feu”, “Fire-resistance rating” et “耐火等级”, la machine ne peut pas savoir que ces trois attributs décrivent en fait les mêmes données. De plus, même si nous utilisons le même langage, la machine ne peut pas savoir que “Fire-Rating”, “FireRating” et “Fire-resistance” décrivent les mêmes données. Par conséquent, compte tenu des différentes règles dans différents pays ou projets, cela rend l’échange de données plus difficile.
bSDD – Faire tous les chemins mènent à Rome
![BIMMARS[7]](https://bimmars.com/wp-content/uploads/2021/03/BIMMARS7-scaled.jpg)
Pour résoudre le problème de l’échange de données sous plusieurs standards, bSDD – buildingSMART Data Dictionary a été créé. Qu’est-ce que le bSDD? À mon avis, il s’agit d’un pont reliant différentes normes dans différents environnements de travail. Parce que dans différents environnements de travail, nous avons différents vocabulaires et manières de décrire les mêmes informations, qui peuvent être considérées comme des expressions différentes de ces informations. Lier ces différentes expressions de manière organisée et structurée est le but de bSDD.
Par exemple, “IfcWall” a le “FireRating” attribut selon la norme IFC. Sous une autre standard CCI Construction, il existe une classification appelée “Wall construction” qui peut avoir le même “FireRating“, et cette classification contient les informations de relation montre qu’elle est liée à l’entité IFC “IfcWall”. Ces différentes expressions dans différentes normes sont liées entre elles par des connexions internes. Ce lien normalisé et ce langage commun pour la classification avec leurs propriétés peuvent encore résoudre les problèmes sémantiques et améliorer la qualité des données et la cohérence des informations.
Un pont bidirectionnel améliore les informations
Si nous considérons le bSDD comme un pont entre les acteurs, alors avec une condition d’entrée, nous pouvons nous assurer que la bonne information est bonne. Comme l’exemple officiel dans SketchUp et le travail de BIMData.io dans l’hackathon, avec les classifications et propriétés fournies par service bSDD, l’utilisateur peut facilement créer des données dans un modèle BIM de manière standard. Surtout comme BIMData.io, l’utilisateur est déjà dans un CDE, la méthode standard de création contribuera beaucoup à la cohérence des informations pour tous les membres dans le projet.
Mais il ne suffit pas de que créer des données avec le processus standard pour garantir la qualité des informations. Nous avons également besoin du contrôle de sortie du pont pour nous assurer que les informations sont fournies correctement. C’est mon idée sur IFC Validator. Sur la base de la connaissance commune de bSDD, toutes les informations délivrées peuvent être vérifiées pour répondre à l’exigence du client. S’il existe des données non qualifiées, elles peuvent fournir des commentaires précis au fournisseur de données pour optimiser le projet. Un pont bidirectionnel complète simplement le flux de travail et pourrait améliorer les informations.
Ne se termine pas encore
Le IFC Validator est toujours une version beta achevée en une semaine, et je vais continuer à travailler sur ce projet. Comme je l’ai mentionné que j’ai open-resourcé l’ensemble du projet sur Github, tout type de contribution est le bienvenu.
Et certaines améliorations est déjà sur le RoadMap:
- Utilisez MVD pour décrire les exigences et peut-être remplacé par IDS lors de sa sortie
- Exporter le rapport et exporter avec le détail de l’entité
- Prise en charge multi-domaines
- Prise en charge des sous-entités
- Prise en charge multi-thread
- Prise en charge multilingue
Un merci spécial à M. Frédéric GRAND et à l’équipe support de bSDD pour tout votre support technique.
IFC Validator, 一个简单的IFC质量控制工具
背景故事
很长一段时间以来，我一直在寻找方式来对IFC文件进行质量控制，并通过算法方式而非人工检查的方式去检验IFC文件。 这个想法始于我在2020年10月发表的文章 标准化进程：嵌入BIM工作流的额外努力。 我进行了很多对于如何自动化目前人工浏览检查IFC文件这个过程的相关研究，然后我看到了bSDD-buildingSMART Data Dictionary。 我认为这也许可以解决问题。 并且，在今年三月我参加了bSDD 2021 Hackathon，并使用了他们新发布的buildingSMART Data Dictionary – bSDD OpenAPI，我认为我找到了这个项目的正确打开方式。 在一个星期后，我提交了我的项目IFC Validator，并将整个项目资源。 现在，v1.0发行版可供所有win 10用户免费使用。
软件下载 : IFC Validator – Microsoft Store
IFC 的质量控制是艰难的
如我们所知道的一样，IFC创建了一套标准的体系和数据交换的标准, 解决了很大一部分信息交换的问题。使得我们可以在不同的环境里传递数据交换数据。但是信息的质量是我们无法从信息的载体上得知的。IFC就像一辆货车，我们定义了什么样颜色的箱子装什么样的货物，以及什么样的货物要放在哪里。我们的数据就像箱子里面的货物。货物都会以箱子的规则整合起来并通过货车传递。
但是，在实际项目中，由于项目的独特性，不同项目在不同阶段所需的数据并不相同。 因此，IFC旨在具有广泛的包容性和适应性，以帮助我们应对各种项目情况和不同需求。 就像您不知道盒子里到底有什么物品一样，您只能设计一个可以容纳更多类型物品的盒子。 但是，IFC本身不具备检查信息的能力，就像卡车无法知道货物是否能够满足客户的需求一样。 在信息的载体中，无法评估信息的价值及其真实性。
因为从本质上讲，这是一个语义问题。 更准确地说，在人类可读的语句和机器可读的数据之间，还需要一个翻译器。 这需要定义词汇的含义，并且告诉机器这个数据代表了什么。 举个例子，如果在项目规范中指定：“所有墙壁都必须具有有关防火等级和隔音等级的信息，以便以后进行数字模拟”。 翻译成机器可读的语言应该是：“所有IFCWall必须具有属性FireRating和AcousticRating”。
但是，如果以各种不同的方式添加此属性，这个语义学的问题就会被更加扩大。我们拿耐火等级举例，法语环境下，耐火等级称为 “Résistance au feu“，分为五个级别M0-M4。在英语环境中，它被称为 “Fire-resistance rating“，分为125，150和350三级。在中文环境中，它被称为 “耐火等级“，分为1-4个等级。机器无法理解语言的含义，因此对于 “Résistance au feu”、”Fire-resistance rating” 和 “耐火等级” 机器无法知道这三个属性实际上描述了相同的数据。而且，即使我们使用相同的语言，机器也无法知道”Fire-Rating”, “FireRating” 和 “Fire-resistance rating”描述的是相同的数据。因此，考虑到不同国家或项目中的不同规则，这使得数据交换更加困难。
bSDD – 让条条大路都通罗马
正是为了解决多种规则下的数据流通问题，bSDD – buildingSMART Data Dictionary 被创造了出来。bSDD是什么，在我的观点里，它是连通不同工作环境中不同标准的桥梁。 因为在不同的工作环境中，我们会用不同的词汇和方式来描述同一个信息，这些都可以被称作为该信息的不同表达方式。 将这些不同的表达有组织并结构化的联系在一起，就是bSDD的意义。
例如在IFC的标准下 “IfcWall” 拥有 “FireRating” 属性，在另外一个标准 CCI Construction 下，存在一个类叫做 “Wall construction” 拥有一样的 “FireRating” 属性，并且这个类包含与IFC实体 “IfcWall” 相关的关系信息。 这些在不同的标准中的不同的表达通过内在的联系被链接到了一起。这种标准化的链接和用于类及其属性的通用语言可以进一步解决语义学的问题，并提高数据质量和信息的一致性。
一个为了更高信息质量的双向桥
如果我们将bSDD视为数据传输的桥梁，那么上桥检查点上，我们可以确保提供正确的信息。 就像官方提供的SketchUp的示例 和BIMData.io在黑客马拉松中的成果一样，通过bSDD提供的类和属性，用户可以轻松地以标准方式在BIM模型中创建数据。 特别像BIMData.io这一类应用，用户已经在CDE中，标准的创建方式将为项目中所有成员的信息一致性做出很大贡献。
但是仅使用标准流程创建数据并不足以确保信息质量。 我们还需要对桥的出口处进行检查，以确保我们正确的传递了信息。 这也就是我对IFC Validator的想法来源。 根据bSDD的服务，可以检查交付的所有信息是否满足客户的要求。 如果存在一些不合格的数据，它可以为数据提供者提供准确的反馈，以优化项目数据。 双向桥不仅完整了这个工作流程，而且可以使信息质量更高。
还未完结
IFC Validator仍是一个星期内完成的测试版，我会继续进行开发。 正如我提到的，我已经在Github中开源了整个项目的代码，欢迎任何形式的贡献。
目前已有的一些关于该项目之后的开发设想：
- 使用MVD描述需求, 可能在IDS发布之后替换为IDS
- 导出报告以及导出带有实体明细的信息列表
- 支持多域
- 支持子类
- 支持多线程
- 支持多国语言
特别感谢Frédéric GRAND先生和bSDD技术支持团队所提供的所有技术支持。
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. – BIM Mars. 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.