Retrouvez la première partie de cet article en en suivant ce lien
Navigation dans le contexte d'un actif GMAO à l'aide de données géométriques et sémantiques
Notre objectif est de fournir à l'utilisateur des vues contextuelles d'un actif, lui permettant ainsi de visualiser l'actif à différentes échelles ou d'utiliser les nombreuses représentations de l'actif pour répondre à un besoin spécifique. A cette fin, nous proposons une solution pour visualiser et naviguer dans des données géospatiales hétérogènes sur le web en lisant et en extrayant des informations de ces données, en se concentrant dans ce projet sur la géométrie 2D ou 3D (figure 3). En outre, cette solution garantit que les informations extraites sont toujours liées à leurs sources.
Définition
Une vue contextuelle est la visualisation d'une ou plusieurs représentations différentes d'un actif et de son contexte. Offrir des vues contextuelles d'un bien aiderait les gestionnaires de biens ou les agents de maintenance en enrichissant les informations disponibles sur un bien. On peut distinguer deux types de représentations. La première, une représentation géospatiale, représente l'emplacement, l'information topologique ou géométrique. Cette représentation peut être soit réaliste, soit symbolique, en 2D ou en 3D. Par exemple, lorsqu'un utilisateur n'a pas besoin d'une représentation visuelle réaliste et détaillée d'un bien et qu'il doit seulement trouver son emplacement, sa topologie ou les objets environnants, une représentation symbolique est suffisante.
La deuxième, sémantique, représente des informations textuelles, en utilisant des formulaires, des documents officiels et techniques.
Pour offrir des vues contextuelles et y naviguer, nous proposons une méthodologie et une architecture logique pour rassembler, visualiser et naviguer dans la représentation géospatiale et sémantique d'un actif.
Méthodologie
L'architecture logique présentée dans la figure 4 montre que les objets de données peuvent être stockés dans des bases de données ou dans des fichiers contenant des données géospatiales ou de GMAO.
Ils sont divisés en deux catégories : ceux qui comportent des informations géométriques en 2D ou 3D et ceux qui n'en comportent pas. L'idée principale derrière cette division est que si un objet non spatial, tel qu'un événement (par exemple un ordre de travail, un désordre, etc.) ou un document (par exemple une documentation technique, une photographie) n'a pas de représentation géospatiale, ou si la représentation d'un actif est seulement sémantique, cela signifie qu'il ne peut pas être visible dans un environnement 2D ou 3D. Par exemple, les bons de travail doivent être visibles sur la carte pour permettre aux administrateurs de comprendre l'état actuel de leur parc de biens. Comme ils ne sont pas des objets physiques, ils ne sont pas décrits par une géométrie, mais une représentation géospatiale est nécessaire pour pouvoir les localiser. En liant un objet non spatial à son bien ou en liant une représentation sémantique d'un bien à une représentation géospatiale, nous nous assurons qu'ils ont une représentation. Pour les biens qui n'ont pas de représentation géospatiale, nous créons une représentation simple, comme un symbole, pour faciliter leur visualisation dans un environnement 2D ou 3D.
Puisque nous voulons rassembler autant d'informations que possible, nous allons essayer de comprendre chacune des sources de données afin de préserver les informations originales. Les données sémantiques doivent être accessibles directement à partir des sources de données, en utilisant des API spécifiques pour chaque source. L'utilisation des API nous permettant d'obtenir une solution où chaque composant est autonome et faiblement lié aux autres, il est donc plus facile d'essayer et d'utiliser plusieurs solutions pour chaque composant.
Comme nous voulons proposer à l'utilisateur une vue contextuelle d'un actif avec les données sémantiques et géométriques, il est nécessaire qu'un visualiseur Web soit capable de naviguer dans toutes ces données hétérogènes en une seule scène. Pour ce faire, il faut trouver des solutions pour interroger et visualiser les données géométriques, ainsi que les données sémantiques liées. Il faut également permettre à l'utilisateur d'interagir avec ces données, de la même manière qu'il le fait dans un logiciel de GMAO classique.
Pour permettre une telle fonctionnalité, nous proposons d'abord de créer un outil de transformation qui aidera à visualiser les données géométriques. Il doit s'adapter aux différents modèles utilisés et produire une géométrie basée sur le modèle que l'observateur peut lire indépendamment du modèle original. Cet outil doit être capable d'extraire les informations géométriques de leurs sources de données et de les transformer, tout en maintenant un lien avec les sources (représentées en vert dans l'encadré de la figure 4).
Qu'il s'agisse de créer un symbole ou d'extraire une géométrie pour visualiser un bien, le but est de les stocker dans une géométrie géoréférencée standardisée, en 2D ou 3D. Ce faisant, nous nous assurons que toute la géométrie est stockée et organisée de la même manière, comprise et affichée par un visualisateur. En outre, l'utilisation d'un modèle géométrique normalisé résout divers problèmes liés à la visualisation de la géométrie sur le Web, tels que l'organisation spatiale, la définition de la géométrie et le nombre d'objets à afficher, problèmes que les modèles géospatiaux ne traitent pas. Un autre avantage de l'utilisation de normes est qu'elles peuvent déjà être utilisées sur plusieurs visualiseurs existants, qui n'auront pas besoin de s'adapter aux différentes représentations existantes de la géométrie. Enfin, il faut s'assurer que la norme choisie traite correctement les données géospatiales, afin de faciliter la navigation dans celles-ci et de résoudre des problèmes tels que la manipulation du système de projection.
En utilisant un couplage faible entre les composants, notre solution globale peut répondre à différents besoins et être utilisée dans sa totalité ou partiellement. De plus, cette approche nous permet d'explorer une variété de solutions pour un problème local sans modifier l'ensemble du pipeline.
Enfin, au cours du processus d'extraction de la géométrie, un lien vers les sources de données originales doit être créé. Dans certains cas, la visualisation de la géométrie seule peut ne pas être suffisante pour comprendre pleinement un bien, ce qui implique que l'on peut avoir besoin d'accéder à plus d'informations sur les objets visualisés. En fournissant un lien entre une représentation visuelle et ses sources de données originales, le visualisateur qui demande et affiche les données saura où trouver les données sémantiques liées à la représentation visuelle.
Fournir un lien entre un actif et ses différentes représentations dans de multiples sources de données permet de naviguer dans son contexte : soit en ayant plusieurs représentations visuelles, en obtenant des données sémantiques supplémentaires ou en explorant les relations avec d'autres objets dans son environnement. Cela permettra non seulement de visualiser une représentation mais aussi de mieux comprendre un bien en utilisant des informations complémentaires qui existent dans différents domaines.
Comme mentionné précédemment, une fois que les informations géométriques d'un bien sont extraites et transformées en géométrie géoréférencée standardisée, ainsi qu'un lien avec ses sources, le visualisateur doit être en mesure de naviguer dans son contexte. Par exemple, une fois que la représentation BIM d'un bâtiment est visualisée, l'utilisateur peut vouloir recueillir des informations supplémentaires que celles de la géométrie, comme le débit d'un tuyau, qui se trouve dans la source. Cela signifie qu'il doit être en mesure d'interroger et de visualiser les informations de ses différentes représentations en données géospatiales mais aussi d'explorer les données des actifs liés qui peuvent aider à mieux les comprendre. L'utilisateur doit être informé des représentations disponibles d'un bien et doit pouvoir visualiser chacune d'entre elles, qu'elle soit sémantique ou géométrique, qu'elle soit à l'échelle d'une ville ou d'un bâtiment, indépendamment ou simultanément.
Pour résumer
Au final, notre solution permet de visualiser la représentation des équipements (figure 5) de différentes sources (Ifs, CityGML, .Obj) et de différents domaines (BIM, SIG, CAO).
Leur format standardisé permet une utilisation plus aisée. Il offre la possibilité d'inclure des données géométriques et sémantiques associées tout en les laissant évoluer dans leurs propres sources, ce qui permet de naviguer dans le contexte de l'actif. L'utilisation d'un couplage faible entre les composants permet de créer des vues personnalisées et de choisir les données à utiliser. L'effort de reproductibilité par la création de conteneurs Docker pour chaque composant nous permet d'intégrer la solution dans des systèmes d'information de type CARL Source, notre solution de GMAO.
Ce travail contribue à prouver que l'utilisation de données géospatiales pour la GMAO permet de mieux comprendre les actifs, et donc de faciliter les opérations de maintenance.
Nos travaux futurs se concentreront sur les domaines suivants : la mise en relation d'un bien et de ses représentations, la création de représentation symbolique et l'amélioration de la navigation 2D et 3D. Pour pouvoir proposer différentes représentations visuelles d'un bien à un utilisateur, il est nécessaire d'identifier et de lier chaque représentation d'un bien. De plus, une fois que plusieurs représentations sont liées à un actif, l'utilisateur doit pouvoir choisir celle qu'il souhaite visualiser. Nous allons travailler sur la création de symboles pour proposer une représentation moins détaillée d'un bien, pour se concentrer uniquement sur les informations topologiques apportées par les données géospatiales ou pour une problématique d'optimisation : lorsqu'on se concentre sur un objet particulier, il n'est pas forcément nécessaire d'avoir une représentation précise et complexe de l'objet environnant.
Enfin, l'amélioration de la navigation 2D et 3D impliquerait la création de différents modes de navigation, en fonction d'un besoin particulier. Par exemple, la navigation en intérieur peut nécessiter un autre mode de navigation que le mode volant actuel, qui est généralement utilisé à l'échelle d'une ville. L'utilisation de fonctionnalités de jeu peut être utile à cette fin.
Pour lire l'article complet, cliquez ici!
