BIM et Brexit – Il y a plus en commun que vous ne le pensez !

2 mars 2020 0 Par Master

Le consultant en ingénierie Tony Marshallsay trouve des points communs entre les problèmes du BIM – et ceux du Royaume-Uni.

Le plus gros problème du BIM est le même que l’UE: le manque de normes communes. Au fil des décennies, l’UE a progressivement réussi à harmoniser la plupart des normes industrielles et des documents commerciaux nationaux importants, en effectuant une collecte juste à temps des pièces et des assemblages de toute l’Europe.

La communauté BIM a commencé à suivre l’exemple de l’UE en commençant à harmoniser la documentation du projet, mais elle n’a pas encore franchi l’étape suivante, et sans doute la plus importante: la normalisation des formats de fichiers de données ouverts et communs – pas seulement pour les objets BIM 3D et connexes Dessins de travail 2D, mais aussi pour tous les autres types de documentation nécessaires à un projet de construction entièrement numérique.

Comme je l’ai écrit dans un article pour BIM + précédemment, la normalisation est extrêmement importante. Pourquoi, demanderez vous ? Pour la réponse, nous devons apprendre un peu d’histoire.

Cela n’aurait pas d’importance, si un consultant en architecture et en ingénierie (AEC) dans le monde de la construction pouvait produire une conception entière en interne, en utilisant l’écosystème propriétaire de son partenaire logiciel choisi, mais aujourd’hui, les projets sont devenus si grands et compliqués que les AEC ont dû se spécialiser dans des secteurs particuliers: architecture, structure, services de S&E, finitions, etc.

Étant donné que ces AEC spécialisés ont généralement été séparés des AEC auparavant pleinement capables, ils sont souvent restés fidèles à leur logiciel de CAO hérité, posant maintenant le problème de la façon de créer un modèle BIM fédéré à l’aide d’objets créés dans une multiplicité de formats de fichiers propriétaires incompatibles.

Oui, c’est possible et oui, ça marche, mais à quel prix?

Le spécialiste AEC doit exporter les données dans un format acceptable par l’AEC hébergeant le modèle fédéré, et / ou l’hôte doit pouvoir lire toutes les données entrantes, quel que soit son format.

Cela signifie:

Les progiciels de CAO sont remplis de modules de traduction de format, qui doivent être mis à jour chaque fois qu’un format propriétaire est modifié / mis à jour. Si ces mises à jour ne sont pas effectuées rapidement, il y a de fortes chances que des erreurs se produisent.
Le temps de traitement et l’énergie électrique associée sont tous deux gaspillés dans l’exécution de la traduction du format (sans parler du chiffrement et du déchiffrement parasites car les gens sont paranoïaques à propos de la sécurité des données).
La latence de rafraîchissement de l’affichage est augmentée, car toute modification en temps réel effectuée par des AEC spécialisés distants doit également être traduite, reflétée par l’hôte, puis l’image du modèle mise à jour est retraduite avant d’être retransmise à l’éditeur.

Il est presque impossible de créer un modèle fédéré distribué, chaque AEC spécialisé étant responsable de l’hébergement de son propre contenu, car la quantité de traduction de format requise augmenterait la latence au point d’être intolérable. L’alternative – le segment de modèles du spécialiste étant conservé sous forme de copies dans chacun des différents formats utilisés dans le projet – multiplie l’espace serveur requis.

Maintenant, regardez ce qui pourrait arriver si tous les AEC utilisaient le même format de fichier ou un format spécialisé conçu pour être compatible avec une norme ouverte commune mais incorporant des informations spécialisées supplémentaires:

Étant donné que tous les AEC utiliseraient le même format ou un format compatible avec la norme commune, ils pourraient librement lire et échanger les informations de la norme.
Les mises à jour du format standard peuvent atteindre toutes les parties par téléchargement simultané à partir de l’hôte de normes commun, ce qui signifie que tout le monde est toujours à jour.
Aucun temps de traitement ni aucune énergie gaspillée en traduction, la latence d’affichage serait donc minimisée (mais tout surcoût de chiffrement resterait, ce qui pourrait devenir un goulot d’étranglement).
Il est à espérer que ce ne soit pas trop long terme, il serait possible pour les éditeurs de logiciels de proposer des packages «formats standard uniquement» moins chers, avec des modules de traduction supplémentaires en option.
Plus important encore, un modèle de «cloud» fédéré et distribué, avec un accès 24/7/365 de n’importe où – essentiel dans le monde d’aujourd’hui – deviendrait une réalité pratique.

Mais qu’en est-il de tous ces formats de fichiers propriétaires jalousement gardés qui ont créé, protégé et pris en charge les écosystèmes logiciels des grands fournisseurs pendant des décennies? Les formats de fichiers courants pour les dessins (et les calendriers de projet, les coûts, la main-d’œuvre et la logistique …) ne détruiraient-ils pas ce modèle commercial?

Non, car ce qui fait que les utilisateurs continuent d’acheter dans des écosystèmes propriétaires ne sont pas les formats de fichiers, car ils ne les voient pas (à moins qu’ils ne leur créent leurs propres interfaces à usage spécial, ce que les fournisseurs déconseillent généralement), c’est ce qu’ils voient comme facilité d’utilisation: l’interface utilisateur (UI) et l’expérience utilisateur associée (UX). «La viande d’une personne est le poison d’une autre» est aussi vrai pour les écosystèmes de logiciels de construction et de CAO que pour Apple et Windows.

Donc, à mon avis, les éditeurs de logiciels n’ont rien à craindre d’abandonner leurs formats de fichiers propriétaires et de passer à un format unique et ouvert pour chaque catégorie de données de construction.

source : http://www.bimplus.co.uk/opinion/bim-and-brexit-theres-more-common-you-think-tony-m/