Une approche des données produits-bâtiment : le modèle IFC

Le standard IFC (Information For Construction) est issu d’une longue réflexion qui débute en 1994. À cette période, Autodesk initie un consortium réunissant douze industriels américains autour de la question de l’interopérabilité des logiciels. En 1995, le groupe décide de s’ouvrir plus largement aux industriels de la construction et aux éditeurs de logiciels dédiés. Le groupe est alors baptisé IAI pour « International Alliance for Interoperability ». Dès les premiers temps, le groupe se fixe pour objectif d’établir un modèle de données de produit AIC neutre et couvrant les différents domaines liés au bâtiment (ex. architecture, gestion de projet, HVAC,

82

La modélisation de la connaissance du domaine 122 etc.). Progressivement, l’IAI établit le modèle IFC, « destiné à supporter l’interopérabilité entre les applications individuelles et spécifiques à une discipline qui sont utilisées pour concevoir, construire et exploiter des bâtiments en capturant l’information relative à l’ensemble des aspects du bâtiment au cours de son cycle de vie. », (Khemlani 2004). Aujourd’hui, l’IAI compte 450 membres, 11 chapitres représentant 24 pays. Il s’agit réellement d’un véritable effort à l’échelle internationale (Eastman et al. 2008).

Figure 51. Les quatre couches de l'architecture des IFC⁸³

Les IFC reposent sur la norme STEP (STandard for Exchange of Product data). Cette norme, mise en œuvre en 1984, a été établie en vue de décrire un produit tout au long de son cycle de vie indépendamment de tout système informatique. Les acteurs du secteur de la construction, à l’époque impliqués dans ce projet, ont rapidement mis en évidence la nécessité de développer un modèle spécifique pour représenter les données du bâtiment (Khemlani 2004). C’est

83

La modélisation de la connaissance du domaine 123 pourquoi l’IAI a adopté plusieurs des résultats de STEP tels que le langage Express pour la description de modèles de données, le format neutre pour l’échange de fichiers et les modèles génériques (ex. ceux qui traitent de la géométrie) (Source BuildingSmart⁸⁴).

L’architecture des IFC 2x4 est organisée selon quatre couches comme le décrit la Figure 51 (Eastman 1999; Rivard 2004) :

- La couche inférieure, la couche des ressources, fournit les ressources non spécifiques à un domaine particulier. Elles permettent de définir les propriétés des classes utilisées dans les couches supérieures. Il s’agit des concepts généralistes de ISO-STEP.

- La seconde couche est la couche centrale. Elle inclut le noyau et ses extensions control, product et process et fournit les concepts génériques abstraits qui sont exploités par les couches supérieures.

o Le noyau correspond à la partie la plus abstraite des IFC. Elle définit les éléments génériques qui sont propres à la modélisation orientée objet, tels que les concepts d’objet et de relation.

o L’Extension Produit (Product extension) fournit la majorité des classes nécessaires à la description physique du bâtiment. L’Extension Processus (Process extension) fournit les classes qui permettent de représenter le processus mené pour la conception et la construction du bâtiment. L’Extension Control (Control Extension) décrit les classes relatives aux contraintes et aux approbations des objets du modèle IFC.

- La troisième couche est la couche d’interopérabilité. Elle décrit les objets partagés par plus d’une application. Ces objets spécialisent ceux de la couche centrale et les enrichissent afin de les rendre utilisables pour les applications.

- La quatrième couche est la couche des domaines. Elle identifie les objets qui supportent les données du modèle de produit bâtiment et qui sont nécessaires aux applications spécifiques des acteurs du domaine (architectes, ingénieurs,etc.).

Lors des échanges, et vu la structure hiérarchique ci-dessus, les objets sont inscrits dans un arbre profond de sous-entités. Considérons l’exemple issu de (Eastman 2008) à propos de l’entité mur. La spécification Express de l’entité « IfcWall » (voir Figure 52) nous indique que cette entité est un sous-type de « IfcBuildingElement ». Elle hérite par conséquent de toutes ses propriétés. Par ailleurs, elle est le super-type de « IfcWallStandardCase ». Aussi, le modèle exprime par :

- « IfcWallStandardCase », toutes les occurrences qui ont une épaisseur constante le long du parcours du mur, et où les paramètres d’épaisseur peuvent être complètement décrits par un ensemble de couches de matériaux.⁸⁵

- « IfcWall », toutes les autres occurrences du mur, et plus particulièrement les murs avec une épaisseur changeant le long du parcours du mur (ex. murs polygonaux), ou les murs qui possèdent une section transversale non-rectangulaire (ex. mur de soutènement

84

http://212.157.43.158/BuildingSmart/

85

La modélisation de la connaissance du domaine 124 en L) , et les murs ayant un axe d’extrusion qui est inégal à l’axe global Z du projet (ex. mur non-verticaux).⁸⁶

Figure 52. Spécification Express de l’entité « IfcWall »

Pour appréhender l’ensemble des propriétés de cette entité, il faut remonter l’ensemble de l’arbre hiérarchique (voir Figure 53).

L’entité mur s’inscrit dans l’arbre de la manière suivante :

IfcRoot → IfcObject → IfcProduct → IfcElement → IfcBuildingElement → IfcWall.

Chaque niveau de l’arbre attribue des propriétés à l’entité « mur ». IfcRoot affecte à chaque élément les informations d’identification (par ex. un Global ID). IfcObject correspond à la généralisation des éléments sémantiquement traités. Il s’agit de la superclasse de tous les objets abstraits et physiques (Rivard 2004). IfcProduct identifie la localisation du mur et sa représentation géométrique. IfcElement présente les relations de cet élément avec les autres comme par exemple, les relations de liaison avec d’autres murs ou encore les connexions avec les espaces qui sont séparés par ce mur. C’est également à ce niveau qu’apparaissent les informations liées aux ouvertures nécessaires aux portes ou aux fenêtres. IfcBuilding element comprend tous les éléments principaux qui font partie du bâtiment (par ex. son système de séparation structurel et spatial) (Source BuildingSmart). IfcWall représente un élément vertical de construction qui lie ou subdivise un espace (Source BuildingSmart). Tous ses attributs peuvent être identifiés en remontant la structure hiérarchique.

Cet exemple nous a permis de comprendre comment était intégrée l’entité « mur » au sein du modèle IFC. Cette approche est rigoureusement identique pour chacun des objets de construction existant dans le modèle IFC.

Le modèle IFC est par conséquent capable de décrire l’ensemble des objets du bâtiment exploités au cours des différentes phases du cycle de vie du bâtiment. Il présente un véritable intérêt pour l’échange d’information dans le secteur AIC. Il fait d’ailleurs l’objet de nombreuses évolutions, la dernière version du modèle (IFC 2x4 alpha version) datant de juin 2008. Nous considèrerons quelques applications de ce modèle dans la seconde partie de ce chapitre. Nous préciserons également que depuis novembre 2005, l’organisation de normalisation ISO a

86

La modélisation de la connaissance du domaine 125 attribué aux IFC la référence ISO/PAS 16739⁸⁷, l’objectif étant que les IFC deviennent concrètement une norme internationale (Source BuildingSmart).

Figure 53. L'objet « mur » au sein du modèle IFC⁸⁸

3.1.2. Une approche de l’activité de conception et de construction : le modèle