Liaison entre l'eCCC-GC/eCCC-Bât et le standard IFC
En collaboration avec des experts, CRB a élaboré un jeu de règles permettant de relier le Code des coûts de construction Génie civil eCCC-GC ainsi que le Code des coûts de construction Bâtiment eCCC-Bât au schéma de données IFC. Il est ainsi possible de déterminer les quantités et les coûts directement à partir du modèle CAO. Cette connexion au standard IFC assure aussi l'échange de données entre diverses applications logicielles.
Depuis que nous proposons cette solution, divers fournisseurs CAO ainsi que de nombreux utilisateurs et utilisatrices ont saisi l'opportunité qui leur était offerte de tester la première version du jeu de règles dans le cadre de projets pilotes BIM. Leurs retours, tirés de leurs expériences pratiques, sont pris en compte dans notre processus d'amélioration continue.
La révision et la mise à jour du Code des coûts de construction Génie civil par éléments eCCC-GC (SN 506 512) remonte à 2017.
Avec la publication du standard IFC 4.3, il était nécessaire de procéder également à une actualisation du jeu de règles présidant à la liaison de l'eCCC-GC avec le schéma de données IFC. C'est chose faite depuis mars 2024. Le jeu de règles est désormais disponible dans le Complément du Code des coûts de construction Génie civil eCCC-GC au format E-Book, sous forme d'un tableau Excel téléchargeable.
Le Code des coûts de construction par éléments Bâtiment eCCC-Bât (SN 506 511) a été largement révisé en 2020 et adapté aux exigences actuelles.C'est pourquoi il s'est avéré nécessaire de procéder également à une actualisation du jeu de règles présidant à la liaison de l'eCCC-Bât avec le schéma de données IFC. Le jeu de règles est désormais disponible dans le Complément du Code des coûts de construction Bâtiment eCCC-Bât au format E-Book, sous forme d'un tableau Excel téléchargeable.
E-Book Complément du Code des coûts de construction Bâtiment eCCC-Bât y.c. jeu de règles eCCC-Bât – IFC 4 sous forme de tableau Excel.
E-Book Complément du Code des coûts de construction Bâtiment eCCC-GC y.c. jeu de règles eCCC-GC – IFC 4.3 sous forme de tableau Excel.
Le jeu de règles pour la classification des éléments d'un modèle IFC selon l'eCCC-Bât a été fondamentalement révisé et actualisé:
D'une part, la partie Bâtiment des jeux de règles IFC a été adaptée à l'eCCC-Bât 2020 révisé et, d'autre part, différentes réflexions quant à un mappage durable du modèle de données IFC ont été prises en compte lors de la révision. Celles-ci constituent la base pour des catalogues plus détaillés de CRB ainsi que pour d'autres cas d'application.
Comme auparavant, le nouveau jeu de règles se rapporte aux niveaux 1 à 3 de l'eCCC-Bât, mais les attributions des différentes entités sont désormais répertoriées individuellement en tant qu'«élément de règle». Cela permet de tenir compte du fait que, selon la définition, un élément de l'eCCC-Bât se compose souvent de plusieurs variantes de parties d'ouvrage qui sont aussi, en partie, modélisées de manière différente.
Les éléments de règle désignent les principales entités habituellement attribuées à un élément. Leur dénomination est à présent univoque et garantit une meilleure clarté.
Différentes phases de modèle au sein d'un élément peuvent aussi parfois être couvertes par différents éléments de règle:
Par exemple, dans l'élément C05.01 (Percements et saignées dans le gros oeuvre), les «Eléments à commander (évidements): installations du bâtiment» (IfcBuildingElementProxy/PROVISIONFORVOID) sont appliqués au modèle Installations du bâtiment, avant d'être coordonnés puis documentés concrètement dans le modèle Architecture et/ou Structure porteuse en tant qu'ouvertures, saignées, évidements, etc. (IfcVoidingFeature.xxxx) (voir norme SIA 400).
Les deux possibilités sont répertoriées en tant qu'éléments de règle relatifs à l'élément, afin que le jeu de règles fonctionne indépendamment de la phase de projet ou des accords au sein de l'équipe de projet concernant la coordination des évidements.
Depuis la version IFC 2x1 (2000) déjà, il est possible d'affecter des parties d'ouvrage à un système et ainsi de regrouper celles-ci selon leur rôle dans l'ouvrage. On recourt fréquemment à cette possibilité, par exemple, pour différencier les installations dans les modèles d'installations techniques. L'utilité de l'affectation à des systèmes dépasse largement le cadre des analyses de modèles axées sur les coûts et celle-ci doit donc être mieux exploitée.
L'avantage de l'utilisation de systèmes réside notamment dans le fait qu'un objet peut établir plusieurs relations avec des systèmes. C'est le cas, par exemple, pour une porte qui doit être raccordée à un contrôle d'accès. Celle-ci est attribuée aux systèmes «INTERIOR» ainsi que «SECURITY».
Dans le modèle de données IFC, les parties d'ouvrage sont affectées à un système d'ouvrage (IfcBuildingSystem, à partir de l'IFC 4x3 IfcBuiltSystem) et les éléments d'équipement technique du bâtiment à un système de distribution ou à une installation technique (IfcDistributionSystem). Pour les deux systèmes, le modèle de données IFC contient des énumérations déjà définies (IfcBuiltSystemTypeEnum, IfcDistributionSystemEnum) que CRB a complété par des définitions consolidées internes pour la Suisse, dans le cadre de la révision de l'eCCC-Bât
Il convient encore ici de mentionner qu'une possibilité analogue est prévue pour les locaux dans le modèle de données IFC. Ces derniers peuvent être attribués à des zones ou à des zones spatiales (IfcZone, IfcSpatialZone). Cela permet, par exemple, de créer des groupes de locaux qui représentent un appartement. Cette stratégie est particulièrement adaptée au groupe principal H, car elle permet de définir simplement (et sans caractéristiques supplémentaires personnalisées) les locaux qui, par exemple, doivent être attribués à une surface utile «H02 Installations de laboratoire», et d'évaluer la grandeur référentielle correspondante.
Dans le modèle de données IFC, les caractéristiques des éléments sont encore subdivisés techniquement en attributs (Attributes) et propriétés (Properties). Les propriétés sont regroupées en sets (Pset) et peuvent en principe être rattachées à plusieurs parties d'ouvrage. Les attributs se distinguent uniquement par le fait que leur forme (p. ex. la plage de valeurs) a une signification spécifique avec la partie d'ouvrage correspondante. Les attributs les plus typiques sont:
(* contient le type défini par l'utilisateur si l'énumération de l'attribut PredefinedType est réglée sur USERDEFINED.)
Autant que faire se peut, les valeurs figurant dans les énumérations du modèle de données IFC ont été prises en compte pour le jeu de règles. Lorsqu'elles ne sont pas suffisantes, le PredefinedType est défini à «USERDEFINED» et l'ObjectType est utilisé pour plus de précision. Là aussi, afin de garantir l'interopérabilité lors de l'attribution, CRB a complété l'ObjectType par des définitions internes consolidées pour la Suisse dans le cadre de la révision de l'eCCC-Bât.
Selon le système d'auteurs (logiciel CAO), la définition d'un PredefinedType est mise en oeuvre différemment. Par exemple, celui-ci peut dépendre directement du style / du type / de la famille de partie d'ouvrage ou peut aussi être réglée uniquement sur l'instance de partie d'ouvrage utilisée. Tous les systèmes d'auteurs courants offrent toutefois la possibilité de rattacher aux parties d'ouvrage des valeurs propres, lesquelles devront ensuite être mappéees vers la propriété correcte dans le modèle de données IFC. Les revendeurs proposent ici l'assistance correspondante.
Les réflexions sur le jeu de règles de CRB ont été menées sur la base du nouvel IFC4.3 RC2, en veillant toujours à la rétrocompatibilité avec l'IFC 2x3. Dans certains cas (p. ex. IfcDoor), il n'existait pas encore de PredefinedType dans l'IFC 2x3, mais uniquement un ObjectType.
Il en va de même pour l'IfcWallStandardCase qui est généralement exporté par les systèmes d'auteurs dans l'IFC 2x3, et uniquement exporté en tant qu'IfcWall dans l'IFC4. Le concept de «sous-entités» (...StandardCase ou ...ElementedCase) avait déjà été rejeté dans l'IFC4 ADD2 TC1 (ISO 16739-1:2018).
Pour l'affectation au système d'ouvrage, il existe déjà une liste standardisée dans IFC que CRB a complétée et consolidée pour la Suisse. Le jeu de règles mise sur l'exploitation des définitions consolidées dans la liste CRB_IfcGroupExtensio.
Le système «LOADBEARING» doit être différencié de la propriété de partie d'ouvrage «porteur» proprement dite (p. ex. dans Pset_WallCommon.LoadBearing). Une affectation au système «LOADBEARING» s'entend au sens d'un rattachement général à la «structure du bâtiment», sans anticipation du concept statique. Cette indication peut être fournie dans des phases précoces d'application de l'eCCC-Bât, même par l'architecte.
Autrement dit, les parties d'ouvrage attribuées à «LOADBEARING» sous le groupe principal «C – Gros oeuvre», par exemple, peuvent être des parois en maçonnerie non porteuses aussi bien que des éléments ayant uniquement des fonctions d'étayage, à savoir toutes les parties d'ouvrage, porteuses ou non porteuses, appartenant à la structure architecturale de l'ouvrage.
Le système «TERRAINSHELL» a été ajouté au système déjà existant «OUTERSHELL» et résout ainsi le rattachement des parties d'ouvrage à la façade au-dessus ou dans le terrain. Les propriétés de parties d'ouvrage ardues telles que «souterrain», «en contact avec le terrain» ou «enterré» deviennent superflues et peuvent être réalisées plus efficacement avec un système dédié aux parties d'ouvrage réellement concernées.
Dans le groupes principaux G et J, la flexibilité des systèmes joue un rôle important. Ces éléments sont souvent édités en tant que meubles (IfcFurnishingElement), mais doivent être rattachés à différents groupes voire même systèmes.
Pour l'affectation au système de distribution, il existe déjà une liste standardisée dans IFC que CRB a complétée et consolidée pour la Suisse. Le jeu de règles mise sur l'exploitation des définitions consolidées dans la liste CRB_IfcGroupExtension.
Dans les installations du bâtiment, il est fréquent de retrouver les mêmes systèmes dans plusieurs groupes eCCC-Bât. Par exemple, les groupes suivants contiennent des conduites d'eau froide:
B04.05 Conduites d'eau
D08 Installations de distribution d'eau
I05.05 Installations sanitaires, à l'extérieur
Ils appartiennent tous au même système d'installlations du bâtiment, dans ce cas «Eau», et sont ainsi affectés au même IfcDistributionSystem.PredefinedType, dans ce cas «WATERSUPPLY». Cela permet de prendre en compte l'interopérabilité du système dans la planification.
La délimitation nécessaire dans le système d'éléments de l'eCCC-Bât est réalisée à l'aide de l'IfcDistributionSystem.ObjectType correspondant. Dans ce cas, l'ensemble des conduites et systèmes du groupe d'éléments B04 (Raccordement aux réseaux) sont complétés par l'ObjectType «MUNICIPAL». L'ensemble des conduites et systèmes du groupe d'éléments I05 (Installations, à l'extérieur) sont complétés par l'ObjectType «LANDSCAPE». Il est ainsi possible de procéder à des évaluations à la fois pour le système d'eau complet et dans la répartition des frais par éléments. La distinction entre conduites provisoires et fixes (B03.02 / B04) s'effectue à l'aide du statut «TEMPORARY», qui doit être ajouté pour les conduites provisoires.
La délimitation entre Production (Dxx.01) et Distribution (Dxx.04) à l'intérieur du système d'éléments de l'eCCC-Bât est réalisée à l'aide de l'IfcDistributionSystem.ObjectType correspondant.
Toutes les conduites appartenant à la production (Dxx.01), comme par exemple la conduite d'eau froide, à l'intérieur du bâtiment sont également définies avec «MAINCONNECTION».
.png)
Pour certains éléments, les montants sont indiqués en francs suisses en tant que grandeur de référence dans la norme (p. ex. A01.01 Acquisition du terrain ss). L'entité IfcCostItem est désormais également proposée pour la saisie des montants.
Quelques propositions sont faites, mais aucun traitement final ni aucune attribution ne sont encore réalisés.
Dans la mesure du possible, il convient d'éviter l'entité «BuildingElementProxy» pour la représentation d'éléments dans le domaine du bâtiment, car souvent elle ne permet pas d'obtenir des quantités significatives. Toutefois, il arrive que certains logiciels ne prennent pas (encore) en charge certaines attributions IFC, dans ce cas, il est naturellement possible de recourir à cette entité.
