Brevet FR3006473A1 — publié le 20141205

Procédé d'échange de données descriptives d'installations techniques La présente invention concerne un procédé d'échange de données descriptives d'installations techniques entre au moins deux applications, une dite application étant apte à fournir et/ou à consommer des données selon un modèle de données d'application associé. L'invention se situe dans le domaine de l'interopérabilité des données techniques descriptives d'installations industrielles. Dans divers domaines industriels, comme par exemple dans le domaine de la production d'énergie, la mise en place d'un site industriel est réalisée de manière spécifique et fait intervenir de nombreux partenaires industriels. Ces partenaires sont amenés à échanger des données techniques relatives aux installations industrielles mises en place, le terme données techniques recouvrant une description fonctionnelle de système mis en oeuvre par l'installation ou les installations, une description d'équipements, de composants, d'instrumentation, aussi bien concernant leurs caractéristiques fonctionnelles, opérationnelles ou intrinsèques à la solution retenues, leur géométrie, leur assemblage, leur implantation et leur décomposition en pièces élémentaires (nomenclature) ainsi que les exigences associées qu'elles soient de conception, de fabrication, d'exploitation, de maintenance ou d'approvisionnement. Afin de faciliter les échanges entre partenaires industriels, le standard IS015926 a été récemment développé. Une description de ce standard est accessible sur le site Internet : http://www.15926.org/. Ce standard spécifie une représentation des informations associées à l'ingénierie, à la construction et à l'opération des installations industrielles, notamment dans le domaine de la production d'énergie. Le standard IS015926 est composé de 9 parties, définissant un modèle de données conceptuel (Partie 2), un ensemble de données de référence (Partie 4), des données de référence de topologie et de géométrie (Partie 3), ainsi que des modèles d'intégration (Partie 7). Le modèle de données est basé sur des classes d'objets ayant des relations de parenté, de spécialisation, les relations entre les classes d'objets étant catégorisées. Il existe également d'autres formats, standard ou propriétaires, mis en place par divers industriels, de description d'équipements industriels, par exemple le standard IS010303 pour la représentation et l'échange d'informations relatives à la fabrication de produits, le standard IS016739 pour le partage de données dans le secteur de la construction et de la gestion d'installations, le standard BIM (Building Information Model), OPC Unified Architecture (OPC-UA) pour la supervision d'installations industrielles. Les formats standard d'échanges de données techniques descriptives d'installations industrielles, par exemple les formats IS010303 et IS015926, ont des caractéristiques similaires, dans la mesure où ils spécifient un langage de description d'un modèle de données, un modèle de données, un dictionnaire décrivant des objets de référence et leurs caractéristiques et des moyens d'accès et d'échanges d'informations. Ainsi, divers partenaires intervenant à divers niveaux d'application métier (par exemple spécification, équipements, génie civil, validation de sécurité) dans la conception et la construction d'une installation industrielle peuvent utiliser des représentations différentes (portées par des standards d'échange différents), représentatives, au moins en partie, des mêmes installations et contenant des données techniques communes. Pour réaliser un échange de données entre applications métier, il est nécessaire soit de générer des fichiers descriptifs des données, par exemple des fichiers en format XML, soit de mettre en oeuvre une conversion entre le format utilisé et un format d'interopérabilité tel que le format défini par le standard IS015926. Ces deux solutions sont fastidieuses et nécessitent un développement spécifique et sont complexes à gérer si dans le même processus d'échange, des informations relatives à plusieurs disciplines (et plusieurs standards) sont manipulées de façon cohérente. Il existe donc la nécessité de simplifier l'interopérabilité et l'échange de données techniques descriptives d'installations industrielles. A cet effet, l'invention propose, selon un premier aspect, un procédé d'échange de données descriptives d'installations techniques entre au moins deux applications, une dite application étant apte à fournir et/ou à consommer des données selon un modèle de données d'application associé, le procédé permettant l'interopérabilité entre lesdites applications grâce à un échange des données exprimées et formalisées à travers au moins un standard choisi ayant un modèle de données associé et un format d'échange associé, mis en oeuvre par un dispositif programmable. Le procédé selon l'invention comporte, pour au moins une application considérée, des étapes de : - intégration du modèle de données d'application dans un langage de représentation des données du Web sémantique, dit langage commun de représentation, - pour chaque standard choisi, intégration du modèle de données du standard dans un langage de modélisation du Web sémantique, - obtention de premières règles de conversion entre le modèle de données d'application dans le langage commun de représentation et le ou les modèles de données des standards choisis dans le langage de modélisation du Web sémantique, - obtention de deuxièmes règles d'organisation et de contrôle des données à échanger, - conversion des données de l'application en utilisant les premières et deuxièmes règles obtenues en données selon le ou les formats d'échange associés aux standards choisis, - échange de données obtenues à l'étape de conversion selon le ou les formats d'échange associés aux standards choisis. Avantageusement, le procédé selon l'invention permet de faciliter l'interopérabilité entre modèles de données utilisés par diverses applications et entre divers formats d'échange de données techniques descriptives d'installations industrielles. Le procédé selon l'invention peut présenter une ou plusieurs des caractéristiques ci-dessous, prises indépendamment ou en combinaison : - l'étape d'obtention de premières règles de conversion comporte la définition de règles unifiées de transformation entre données d'application et le ou les standards choisis, sur la base des patrons de règles génériques. ; -les premières règles de conversion obtenues sont des règles bijectives, permettant une transformation des données d'application vers le ou les standards choisis, et une transformation de données selon le ou les standards choisis vers des données conformes au modèle d'application ; - les premières règles de conversion sont exprimées de façon déclarative et mémorisées dans un ou des fichiers ; - l'étape d'obtention de premières règles de conversion comporte la création ou la mise à jour d'un dictionnaire de références interne, en lien avec le ou les standards choisis ; - l'étape d'obtention de deuxièmes règles comporte la définition de règles d'organisation et de contrôles des échanges permettant de répondre à des exigences contractuelles, de confidentialité des informations à échanger et de contrôler les informations à intégrer ; -lesdites deuxièmes règles définissent des lots d'échange, permettant de filtrer parmi l'ensemble des données de l'application, un sous-ensemble de données à échanger ; -l'étape d'intégration du modèle de données d'application dans un langage de représentation des données du Web sémantique, comporte deux sous-étapes, une première sous-étape de transformation du modèle d'application dans le langage de représentation des données du Web sémantique et une deuxième sous-étape de transformation effective des données de l'application par instanciation du modèle d'application transformé issu de la première sous-étape ; - ledit langage commun de représentation des données du Web sémantique est le langage RDF ; - ledit langage de modélisation du Web Sémantique est le langage OWL ; -un des standards choisis est le standard IS015926. Selon un deuxième aspect, l'invention concerne un dispositif programmable d'échange de données descriptives d'installations techniques entre au moins deux applications, une dite application étant apte à fournir et/ou à consommer des données selon un modèle de données d'application associé, permettant l'interopérabilité entre lesdites applications grâce à un échange des données exprimées et formalisées à travers au moins un standard choisi ayant un modèle de données associé et un format d'échange associé. Le dispositif de l'invention comporte, pour au moins une application considérée, des modules aptes à fournir des moyens pour : - l'intégration du modèle de données d'application dans un langage de représentation des données du Web sémantique, dit langage commun de représentation, - pour chaque standard choisi, l'intégration du modèle de données du standard dans un langage de modélisation du Web sémantique, - l'obtention de premières règles de conversion entre le modèle de données d'application dans le langage commun de représentation et le ou les modèles de données des standards choisis dans le langage de modélisation du Web sémantique, - l'obtention de deuxièmes règles d'organisation et de contrôle des données à échanger, - la conversion des données de l'application en utilisant les premières et deuxièmes règles obtenues en données selon le ou les formats d'échange associés aux standards choisis, et - l'échange de données obtenues à l'étape de conversion selon le ou les formats d'échange associés aux standards choisis. Le dispositif de l'invention comporte des moyens de mise en oeuvre de toutes les étapes du procédé selon l'invention brièvement introduit ci-dessus. D'autres caractéristiques et avantages de l'invention ressortiront de la description qui en est donnée ci-dessous, à titre indicatif et nullement limitatif, en référence aux figures annexées, parmi lesquelles : -la figure 1 est un exemple schématique d'une infrastructure mettant en oeuvre l'invention ; - la figure 2 illustre schématiquement le principe de l'invention ; - la figure 3 représente les principales opérations de traitement du procédé de l'invention ; - les figures 4 à 6 détaillent les principales étapes des opérations de traitement représentées à la figure 3. La figure 1 illustre un exemple d'infrastructure 2 dans laquelle est mis en oeuvre le procédé de traitement de données descriptives d'installations techniques selon l'invention. L'infrastructure 2 comprend une partie 4 faisant partie d'une entreprise, appelée infrastructure d'entreprise, comportant des dispositifs 10.1, 10.2, 10.n serveurs de bases de données d'applications métiers contenant les informations des différentes disciplines de l'entreprise devant être échangées vers des tiers ou entre elles. Ces bases de données comportent notamment des données descriptives d'installations techniques. La partie 4 de l'infrastructure 2 comprend également des postes de travail 20.1, 20.2, 20.n contenant des clients de ces serveurs 10.1, 10.2, 10 .n, et un serveur informatique d'échange 30 permettant l'exécution des opérations de traitement du procédé selon l'invention associé à une base de données contenant les données à publier, ainsi que les règles de conversion et de contrôle. Ces règles de conversion réfèrent des dictionnaires 50 gérés au niveau d'une de l'entreprise, soit des dictionnaires externes 60.x maintenus par des tiers (organismes de normalisation, publiés par d'autres entreprises ou maintenus par des représentants d'un secteur d'activité). Les postes de travail 20.1, 20.2 à 20.n mettent en oeuvre des ajouts applicatifs liés au serveur informatique d'échange 30 permettant d'organiser des échanges, de vérifier les données à publier ou de contrôler les données à intégrer dans les bases de données métier des serveurs 10.1 à 10.n. L'infrastructure d'entreprise 4 comprend également un ou plusieurs postes de travail 40 permettant d'administrer le serveur informatique d'échange 30 aussi bien pour organiser et suivre les échanges, établir les règles de conversion et aussi vérifier ou effectuer les échanges indépendamment de l'utilisation des postes de travail 20.1 à 20.n. Optionnellement, un serveur miroir 30.m synchronisé avec le serveur 30 est présent, afin d'isoler le réseau interne de l'entreprise d'un réseau 70 accessible par l'extérieur, permettant de répondre aux exigences de la cyber sécurité informatique. Les serveurs 30 et 30.m, selon la configuration déployée, sont en mesure de répondre à des requêtes tierces et de publier des fichiers et rapports selon les différents formats traditionnellement utilisés par les standards d'échange de données techniques descriptives d'installations industrielles, par exemple les formats PDF, XLS, XML, OWL. Les accès se font à travers le réseau 70 supportant les technologies WEB classiques qu'il soit utilisé dans un mode privé (intranet d'une communauté) ou public (internet). La figure 2 illustre schématiquement le principe de l'invention. Une application métier A, appelée simplement application A par la suite, apte à fournir et à traiter des données représentatives d'installations techniques est décrite par son modèle de données, qu'on appellera Modèle A (MA sur la figure 2). Cette application comprend des informations ou données notées DA, que l'on souhaite publier selon différents standards d'échange en fonction de leur nature. Dans l'exemple de la figure 2, deux standards sont considérés, notés Standard 1 et Standard 2. Par exemple le standard 1 est le standard IS015926 et le standard 2 est le standard IS016739. De manière plus générale, l'invention ne se limite pas à l'utilisation de deux standards, un nombre quelconque de standards pouvant être utilisé en appliquant le principe de l'invention décrit ci-dessous. Dans une variante non représentée, on cherche à agréger des informations issues d'une autre application B et les publier en conjonction avec celles de l'application A et toujours en s'appuyant sur un ou plusieurs standards d'échange. Dans ce cas le modèle A et le modèle B peuvent être regroupés dans un modèle A+B. Il est avantageux d'utiliser la technologie du Web sémantique, en particulier le formalisme RDF (« Ressource Description Framework »), défini par le W3C (« World Wide Web Consortium »), pour cette agrégation, de façon incrémentale sans remise en cause des premières implémentations du couplage entre les données de l'application A vers un standard d'échange décrit plus en détail ci-après. De manière connue, le formalisme RDF est un modèle de graphe destiné à décrire de façon formelle les ressources Web et leurs métadonnées. Dans la suite de la description le traitement des données DA d'une application A, ayant un modèle de données MA sera détaillé. Cependant, ce traitement s'applique de manière analogue pour une application B, ayant un modèle de données MB et des données DB associées, et également pour le cas d'un modèle de données A+B. Le Modèle MA s'exprime dans le formalisme RDF de la technologie du Web Sémantique. Les modèles de données des standards, notés respectivement M1 pour le modèle de données du Standard 1 et M2 pour le modèle de données du Standard 2 sont fournis par les organismes de normalisation dans un langage de description soit directement disponible dans le formalisme du Web Sémantique, c'est-à-dire en langage OWL (« Web Ontology Language ») formalisé en RDF, comme c'est le cas dans le cadre de 1I5015926, soit dans un langage autre (par exemple EXPRESS dans le cadre de 1'I5010303). Dans ce deuxième cas, selon l'invention, il est préconisé de traduire l'expression du modèle de données du standard (avec éventuellement des restrictions) dans le langage OWL du Web Sémantique afin d'avoir une homogénéité de représentation et utiliser la puissance de raisonnement du Web Sémantique. Par la suite les modèles de données M1, M2, etc. sont considérés être exprimés dans le langage OWL du Web Sémantique, formalisé en RDF. Un premier jeu de règles de conversion (R1) est réalisé pour permettre la transformation des données issues de l'application A (exprimées elles aussi dans le formalisme RDF et décrites à travers le modèle de données MA) dans le modèle de données du standard M1 ou M2 ; ce travail résulte d'une analyse de MA et de M1 ou M2, en relation avec des dictionnaires mémorisés RDL (« Reference Data Library ») liés aux standards Standard 1 et Standard 2. Un deuxième jeu de règles d'organisation et de contrôle (R2) est réalisé pour organiser et contrôler les échanges, pour la définition de lots d'échange, de règles de contrôles d'intégrité, pour poser des numéros de versions ou pour tracer les valeurs échangées ou modifiées. Ces règles R1 et R2 sont implantées sur le serveur 30, les règles conversion R1 sont obtenues par programmation et les règles d'organisation et de contrôle R2 par l'intermédiaire d'une interface homme-machine implantée sur le poste de travail 40. Une première opération de traitement OP1 est effectuée sur le serveur 30, prenant en compte les données DA (exprimées en RDL), les règles de conversion R1 permettant de les transformer selon les attendus du standard choisi, qu'il s'agisse du Standard 1 ou du Standard 2, et prenant en compte les règles d'organisation et de contrôle R2 pour organiser les échanges, les contrôler ou produire des enregistrements de traçabilité. Les données résultantes DAS de la transformation effectuée par OP1 sont donc conformes au modèle de données du ou des standards, correctement contrôlées et regroupées dans un lot d'échange mais sont toujours décrite dans le formalisme RDF du Web sémantique. Dans le cas où les deux standards Standard 1 et Standard 2 sont considérés, deux conversions sont effectuées, permettant d'obtenir des données résultantes pour chaque standard. Une deuxième opération de traitement 0P2 permet de publier ces données DAS dans le ou les formalismes du ou des standards retenus qu'ils soient des fichiers DAPS en un format usuel comme par exemple EXCEL®, XML, dans des bases de données RDF ou par des accès via des services WEB. Les opérations de traitement OP1 et 0P2 réalisent des transformations bijectives : elles utilisent toujours les mêmes jeux de règles R1 et R2 pour transformer DA en DAS et vice-versa DAS en DA, ainsi que DAS en DAPS et vice-versa DAPS en DAS. Les extractions de données de l'application A pour produire DA ou l'introduction de données DA dans l'application est effectuée par des connecteurs spécifiques développés en utilisant les interfaces programmatiques de l'application A. Ces interfaces peuvent s'exécuter à travers l'interface homme machine de l'application A sur un poste 20.1, 20.2,..., 20.n, de la figure 1, soit sur le poste d'administration 40. Les règles de conversion R1 mettent en équivalence des attributs du modèle de données A (MA) avec un dictionnaire donnant un vocabulaire partagé (RDL de la figure 2). Cette équivalence peut être simple ou peut résulter d'une combinaison d'attributs. Le vocabulaire peut être défini et maintenu par un organisme de normalisation, mis à disposition par des acteurs de référence (soit au niveau d'un projet ou d'une communauté) soit être créé pour les besoins propres à l'entreprise (RDL privé). Afin de rendre les traitements les plus homogènes possibles, ces règles de conversion R1 génèrent systématiquement un RDL privé puis ensuite une équivalence est faite entre un terme du RDL privé et un terme d'un RDL public par substitution des termes du vocabulaire sachant que la grammaire du standard est respectée avant et après la substitution. La figure 3 représente les principales étapes du procédé de l'invention mises en oeuvre par un des traitements sur le serveur 30. Trois blocs de traitement sont représentés, à savoir un bloc 100 de travaux préparatoires, un bloc 200 de travaux de paramétrage et un bloc 300 d'opérations de traitements effectifs des données, correspondant respectivement aux opérations de traitement OP1 et 0P2 de la figure 2. Des travaux préparatoires 100 sont nécessaires, permettant d'obtenir, le cas échéant, le modèle MA de l'application et les données DA associées (T1x) et les modèles M1, M2 des standards sous le format du Web Sémantique (T2x). Les traitements préparatoires sont illustrés plus en détail à la figure 4. Les traitements T1x (T10, T11, T12, etc.) visent à échanger les données de l'application A avec leur équivalent formalisé dans le langage de représentation de données du Web sémantique. i.e. le langage RDF. Le langage RDF offre le moyen d'exprimer les données de façon élémentaire en vue d'être transformables sous forme d'instances dans le modèle de données de l'application avec laquelle il est prévu d'échanger des données, au moyen de règles de conversion de données. De façon pragmatique, cette tâche consiste à accéder aux données de l'application A via l'une des interfaces offertes par cette application pour les transformer en triplet RDF (Sujet, Prédicat, Objet). Les prédicats référencent des concepts (Classes, propriétés). Dans cette transformation, une séparation est faite entre le traitement 110 du modèle de données (MA) et le traitement 111 des données (DA). La transformation du modèle de données de l'application en modèle MA n'est faite qu'une seule fois tant que le modèle de données de l'application A n'a pas changé, au niveau du traitement 110 ; les changements proviennent d'évolutions planifiées de cette application A qui se suivent généralement avec une période de plusieurs années. Afin de mieux expliciter l'invention, un exemple de données (DA) sous forme de triplets est considéré. Soit l'instance d'une vanne : VANNE (Tag : #1#, Diamètre = 50 m), qui porte l'étiquette #1# et qui a un diamètre de 50 mètres (m). Le programme de transformation T10 produirait dans les quatre triplets suivants : - Vanne#1# type - Vanne#1# #1# - Vanne#1# 50 - Vanne#1# m Pour cette étape 110, selon la nature de la technologie de l'application A (base de données relationnelle ou sémantique, fichiers XML, application Excele), des connecteurs sont développées (en export ou en import selon les besoins), en utilisant des langages de programmation classiques (C++, java ou autres), associés aux interfaces programmatiques fournies par les éditeurs de ces applications (comme par exemple les éditeurs d'applications PLM permettant de gérer un référentiel de données techniques ou d'applications de CAO permettant de réaliser de la conception assistée par ordinateur). Les traitements de travail préparatoire d'extraction de données consistent à extraire (traitement 111) les données DA de l'application A pour les mémoriser selon le modèle de données en RDF dans une mémoire 150 du serveur informatique d'échange 30, ou à importer des données DA en RDF vers l'application A (traitement 112). Les traitements T2x visent à transformer le modèle de données d'un standard choisi, qu'il s'agisse du Standard 1 ou du Standard 2, dans le formalisme de représentation de modèle du Web sémantique, c'est-à-dire le langage de modélisation OWL. Si le modèle du standard choisi s'exprime lui-même dans le langage OWL, cette tâche n'est pas nécessaire. C'est le cas de 115015926 mais aussi pour d'autres normes, par exemple PLCS pour « Product Life Cycle Support », standard 150303-239 et BIM pour Building Information Model, qui s'expriment en OWL. Dans le cas où le modèle de données du standard traité n'est pas en langage OWL, une transformation du modèle de données dans son formalisme de représentation (par exemple UML, XML-Schema, EXPRESS) vers le langage OWL est effectuée au niveau du traitement 120, 121. Pour cela, il est possible d'utiliser des briques logicielles sur étagère. Ces briques logicielles sont entre autres UML2OWL, XSD2OWL ou Express2OWL respectivement pour les formalismes de représentation UML, XML- Schema ou EXPRESS. Ainsi, la transformation du modèle de données du Standard 1 vers le langage OWL est effectuée à l'étape 120, et la transformation du modèle de données du Standard2 vers le langage OWL à l'étape 121. Ces étapes 120, 121 ne s'appliquent en principe qu'une seule fois tant que le formalisme du standard choisi n'a pas changé. Dans les étapes suivantes, une ontologie désigne le résultat de la formulation ou transformation du modèle de données dans le langage OWL. Des traitements de paramétrage et d'organisation des échanges constituent la deuxième partie du processus comme le montre le bloc 200 de la figure 3. Les traitements T3x définissent les règles de conversion R1 permettant de convertir les données dans le langage d'expression du ou des standards choisis et les traitements 14x permettent de définir les règles d'organisation et de contrôle R2 pour organiser, contrôler et suivre les échanges. La figure 5 montre l'organisation des traitements 13x et les données d'entrée et résultats produits. Les traitements 13x visent à définir les règles de conversion R1 qui serviront à transformer les données de l'application A formalisée dans un langage RDF issues des traitements préparatoires 110 à 112 en conformité avec le ou les formats OWL du ou des standards issus des traitements préparatoires 12x. Les règles de conversion R1 produites ne sont pas codées dans un programme, mais sont exprimées de façon déclarative. Une règle est composée d'un couple : (condition, actions). La condition est une expression booléenne qui s'applique sur les données. Si elle est satisfaite, elle déclenche l'exécution d'un ensemble d'opérations prédéfinies comme des opérations d'ajout ou de modification ou de suppression ou leurs combinaisons. Les règles de conversion sont exécutées par un moteur d'exécution de règles nommé communément raisonneur. Les raisonneurs sont des programmes informatiques assez complexes à mettre en oeuvre mais dans le commerce, il existe de nombreux raisonneurs (Pellet®, Racer®, SPINEnginee, etc.). Les expérimentations du procédé de l'invention ont été effectuées sur le raisonneur SPINEnginee de l'éditeur TopQuadrant. Le langage SPIN (« SPARQL lnferencing Notation ») est utilisé pour exprimer des patrons de règles (ou « templates » en anglais) permettant de créer les règles de conversion R1. Ce langage permet d'encapsuler des requêtes SPARQL, qui est un langage permettant de rechercher, ajouter, modifier ou supprimer des données RDF. SPIN et SPARQL sont deux langages du Web Sémantique. L'approche, basée sur des règles déclaratives, offre la possibilité de définir un environnement évolutif et flexible pour s'adapter à divers besoins sans l'aide de développeurs informatiques pour réaliser des corrections ou extensions. En outre, elle offre aux utilisateurs la possibilité de définir, étendre et modifier des règles (ou leurs patrons) facilement, suite à de nouveaux besoins et/ou suite à l'impact de la modification d'une des ontologies pour lesquelles on cherche à définir des règles de conversion R1. Cette définition de règles de conversion est le résultat d'un processus en trois étapes, tel qu'illustré à la figure 5, qui sont respectivement : -Traitement T30 : Définition de patrons de règles -Traitement T31 : Définition de règles de correspondances entre les ontologies en se basant sur ces patrons de règles -Traitement T32 : Génération des règles de conversion R1. L'évolution et la flexibilité de l'algorithme se traduit par l'utilisation de patrons. Un patron de règles est une règle générique qui porte une sémantique en implémentant des opérations simples ou complexes. Un patron se caractérise par le fait qu'il définit des paramètres en entrées et implémente une certaine logique de transformations et/ou d'encodages à effectuer sur la base de ces paramètres. Une règle n'est autre qu'une instance de patron avec des valeurs spécifiques aux paramètres de celui-ci, comme expliqué dans le traitement T31. Le nombre de patrons de règles et leurs complexités, à définir lors du traitement T30, sont fonctions des différences majeures qu'il peut y avoir entre la sémantique des modèles M1, M2 (d'applications/d'ontologies), définies à partir des méta-modèles de ces standards, pour lesquels les règles de correspondances sont créées. Les patrons de règles génériques permettent de masquer la diversité des modèles de données des standards choisis (Standard 1 ou Standard 2 dans l'exemple) en support pour les échanges ou les fonctions d'interopérabilité. Voici quelques exemples de définition de patrons de règles : - Nom : ClassificationRuleTemplate o Description : Patron de règle qui permet de créer une instance d'une classe du Standard 1dans le modèle du Standard 2. o Paramètre 1 : Une Classe dans le Standard 1 o Paramètre 2 : Une Classe dans le Standard 2 o Paramètre 3: Une variable pour parcourir toutes les instances du standard A - Nom PropertyUnitConversionRuleTemplate o Description : Patron de règle qui permet la conversion d'une valeur de propriété P du Standard 1 vers le Système d'unités du Standard 2 o Paramètre 1 : La propriété du Standard 1 o Paramètre 2: La propriété du Standard 2 o Paramètre 3: L'unité de valeur de la propriété du Standard 1 o Paramètre 4 :L'unité de valeur de la propriété du Standard 2 o Paramètre 5 : la fonction de transformation de données A l'issue de l'étape 130, un ensemble de patrons de règles P est mémorisé. Le traitement 131 de définition des correspondances C entre les deux modèles de données consiste à construire des liens sémantiques entre les concepts (classes et/ou propriétés et/ou instances) des modèles. Pour chaque correspondance, également appelée « mapping », entre concepts, l'utilisateur associe deux patrons de règles afin d'être capable de transformer des données du Standard 1 vers le Standard 2 et inversement. Dans ce cas, la correspondance C est réversible. Dans une variante, l'utilisateur peut ne fournir qu'un seul patron de règle, par exemple du Standard 1 vers le Standard 2. Dans ce cas, la correspondance C est mono- directionnelle, et non réversible. L'étape 131 est une étape clé du processus car elle exige une connaissance approfondie tant des modèles (Standard 1 et Standard 2) pour établir les correspondances, qui sont des liens sémantiques, que dans le choix des patrons de règles. Un modèle de données est défini pour exprimer ces correspondances C avec leurs patrons de règles P associés. Les instances de modèles de données constituent le « mapping » qui sera en entrée du générateur de règles 132 décrit dans l'étape suivante. Quelques exemples de mises en correspondance : ,./ Mapping 1 : o Le mapping de la classe VANNE du Standard 1 avec la classe VALVE du Standard 2. o Patron (142) : ClassificationRuleTemplate o Patron (241) : Classification RuleTemplate ,./ Mapping 2: o Le mapping de la propriété DIAMETRE du Standard 1 qui est en mètre avec la propriété RADIUS du Standard 2 qui est en centimètre. o Patron (142) : PropertyUnitConversionRuleTemplate o Patron (241) : PropertyUnitConversionRuleTemplate 40 La dernière étape 132 du processus consiste à produire les règles de conversion R-1 qui seront fournies au raisonneur (comme décrit ci-après en référence au traitement 151) pour produire les données. Le générateur de règles de l'étape 132 prend en entrée les résultats du traitement 131 : - La liste de patrons de règles avec leurs paramètres. - Le mapping des deux standards. Les associations avec un dictionnaire RDL Dans le traitement 132, les différentes classes d'objets et attributs sont décrits par un dictionnaire RDL local généré automatiquement, noté D sur la figure 5, lié à la fois au vocabulaire du ou des standards, mais aussi issu des applications en interface. Ce dictionnaire local est appelé RDL Interne. Dans le traitement 132, des règles de conversion R1 sont définies, permettant de poser des équivalences entre ce RDL interne et les dictionnaires disponibles qu'ils soient publiés au niveau d'un organisme de normalisation, d'une communauté, d'un projet. Si on ne trouve pas de correspondance dans ces dictionnaires, le RDL interne peut alors servir de base pour un RDL privé ou projet, voire de communauté, pouvant ensuite être intégré dans un standard. Pour optimiser les traitements dans les raisonneurs, deux jeux de règles sont produits et stockés séparément : un jeu de règles pour chaque sens de transformation de données ([Standard 1 -) Standard 2] et [Standard 2 -) Standard 1]). Chaque jeu de règles est exécuté suivant le besoin exprimé : 1 -) 2 ou de 2 -) 1. Pour l'exemple suivant, le générateur de l'étape 132 construit les règles de conversion suivantes (Standard 1 -) Standard 2) - Règle R11 - pour transformer toutes les instances de VANNE en VALVE o Patron : ClassificationRuleTemplate o Paramètre 1 : VANNE o Paramètre 2 : VALVE o Paramètre 3 :?this - Règle R12 - pour convertir toutes les valeurs de diamètre des instances VANNE en rayon de VALVE o Patron : PropertyUnitConversionRuleTemplate o Paramètre 1 : DIAMETRE o Paramètre 2: RADIUS o Paramètre 3 : mètre o Paramètre 4 : centimètre o Paramètre 5 : diameter2radius Les traitements 14x ont l'objectif de définir des règles d'organisation et de contrôle R2 permettant d'organiser, de contrôler ou de suivre les échanges. Pour cela un module de traitement est développé pour ajouter des règles d'organisation et de contrôle R2 complémentaires aux règles de conversion R1 produites par le traitement 13x, et qui ont pour objectifs de construire des métadonnées sous forme de rapports sur les données des applications qu'elles soient dans leur forme originale (c'est-à-dire conforme au modèle de données de l'application, par exemple MA pour l'application A) ou qu'elles soient exprimées dans le langage du ou des standards retenus (M1 pour Standard 1 et M2 pour Standard 2). Ces règles d'organisation et de contrôle des échanges R2 permettent de répondre aux exigences contractuelles et de confidentialité des informations à échanger et de contrôler les informations à intégrer. Les traitements T4x se décomposent en deux étapes. - 141 : Constitution des rapports et leurs organisations/classifications hiérarchiques dans des packages (répertoires) en vue de leurs publications. - 142 : Publication des données qui visera à exécuter les packages et éventuellement l'envoyer à des partenaires internes ou externes. Les rapports sont des liens complémentaires entre une donnée et : - Un critère de sélection ou une requête (permettant de filtrer les données à échanger) - Une version (permettant de vérifier les mises à jour de ces données). - Un lot d'échange (permettant de regrouper différents types de données à exporter simultanément). - Une règle de contrôle (permettant de savoir si une donnée reçue respecte certaines règles de cohérence) ou si l'autorisation de modifier la donnée est disponible. - Un enregistrement de traçabilité (une version). - Un ensemble de packages où sont classés les rapports. - La source de données dans laquelle le rapport sera exécuté. Notons que la source de données peut être soit : o La base de données de l'application o Une façade de données d'un standard o l'agrégation de plusieurs sources de données Ce dernier type de source de données va permettre la fédération/intégration de toutes sources de données. La requête du rapport sera envoyée en parallèle dans la source de données. L'étape 141 de constitution du rapport est suivie d'une étape 142 de publication. Le lot d'échange peut aussi avoir des rapports supplémentaires avec : - Un format (pas nécessairement unique) - Un destinataire (pas forcément unique) - L'adresse de zones de stockage d'information accessibles par le destinataire (sur le serveur 30 ou le serveur 30m), qui peut être l'adresse http d'une façade, un serveur FTP, un disque partagé. A la fin de la publication T42, une synthèse d'exécution est produite, actant l'échange et pouvant être associée à un bordereau daté et signé, pouvant faire foi dans des échanges contractuels. La figure 6 illustre plus en détail les opérations de traitement de conversion T5x et T6x de la figure 3. Le traitement T50 produit dans un premier temps des données 600 présentées selon la logique du ou des standards Standard 1, Standard 2 suite à l'exécution des règles issues de T3x, en se basant sur les ensembles de règles R1 et R2 mémorisées. Les données d'application traitées, données DA pour l'application A et données DB pour l'application B, sont fournies en entrée du traitement T50. Le traitement T51 organise et contrôle les données à échanger selon l'exécution des règles R2 issues de T4x. En sortie du traitement T51, des données standardisées et organisées 610, notées DAS pour l'application A et DBS pour l'application B, sont obtenues. Le traitement T60 convertit les données 610 formalisées en RDF en données recommandées par le standard Standard 1 ou Standard 2 choisi. Les traitements T50 et T51 sont en réalité identiques, appliqués par un moteur d'exécution de règles ou Raisonneur. Par exemple, le raisonneur produit l'instance de VALVE suivante : - Valve#1# type - Valve#1# #1# - Valve#1# 2500 - Valve#1# cm Le traitement T60 a pour objectif transformer les données 610 qui sont logiquement exprimées et organisées dans des données 620 respectant un formalisme recommandé par le ou les standards choisis pour supporter l'échange. Ce formalisme peut être EXCEL®, XML ou un format RDF/OWL. Dans ce dernier cas, le traitement T60 est inutile, les données 610 DAS, DBS étant déjà formalisées en RDF. Des données 620, notées DASP pour l'application A et DBSP pour l'application B sont obtenues. Pour les autres formats, le traitement T60 s'apparente à un connecteur tel que défini dans le traitement T12. Il est spécifique du standard choisi. Les traitements T12, T50, T51 et T60 peuvent fonctionner dans les deux sens (export et import vis-à-vis de l'application A et un partenaire). REVENDICATIONS1.- Procédé d'échange de données descriptives d'installations techniques entre au moins deux applications, une dite application étant apte à fournir et/ou à consommer des données selon un modèle de données d'application associé, le procédé permettant l'interopérabilité entre lesdites applications grâce à un échange des données exprimées et formalisées à travers au moins un standard choisi ayant un modèle de données associé et un format d'échange associé, mis en oeuvre par un dispositif programmable, caractérisé en ce qu'il comporte, pour au moins une application considérée, des étapes de : - intégration (T1x) du modèle de données d'application dans un langage de représentation des données du Web sémantique, dit langage commun de représentation, - pour chaque standard choisi, intégration (T2x) du modèle de données du standard dans un langage de modélisation du Web sémantique, - obtention (T3x) de premières règles (R1) de conversion entre le modèle de données d'application dans le langage commun de représentation et le ou les modèles de données des standards choisis dans le langage de modélisation du Web sémantique, - obtention (T4x) de deuxièmes règles (R2) d'organisation et de contrôle des données à échanger, - conversion (T5x) des données de l'application en utilisant les premières et deuxièmes règles obtenues en données selon le ou les formats d'échange associés aux standards choisis, - échange (T6x) de données obtenues à l'étape de conversion selon le ou les formats d'échange associés aux standards choisis. 25 2.- Procédé selon la revendication 1, caractérisé en ce que l'étape d'obtention de premières règles (R1) de conversion comporte la définition de règles unifiées de transformation entre données d'application et le ou les standards choisis, sur la base des patrons (P) de règles génériques. 30 3.- Procédé selon la revendication 2, caractérisé en ce que les premières règles (R1) de conversion obtenues sont des règles bijectives, permettant une transformation des données d'application vers le ou les standards choisis, et une transformation de données selon le ou les standards choisis vers des données conformes au modèle 35 d'application. 4.- Procédé selon l'une des revendications 2 ou 3, caractérisé en ce que les premières règles (R1) de conversion sont exprimées de façon déclarative et mémorisées dans un ou des fichiers. 5.- Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape d'obtention de premières règles (R1) de conversion comporte la création ou la mise à jour d'un dictionnaire de références interne, en lien avec le ou les standards choisis. 6.- Procédé selon l'une des revendications 1 à 5, caractérisé en ce que l'étape d'obtention de deuxièmes règles (R2) comporte la définition de règles d'organisation et de contrôles des échanges permettant de répondre à des exigences contractuelles, de confidentialité des informations à échanger et de contrôler les informations à intégrer. 7.- Procédé selon la revendication 6, caractérisé en ce que lesdites deuxièmes règles (R2) définissent des lots d'échange, permettant de filtrer parmi l'ensemble des données de l'application, un sous-ensemble de données à échanger. 8.- Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape d'intégration du modèle de données d'application dans un langage de représentation des données du Web sémantique, comporte deux sous-étapes, une première sous-étape de transformation (T10) du modèle d'application dans le langage de représentation des données du Web sémantique et une deuxième sous-étape de transformation (T11, T12) effective des données de l'application par instanciation du modèle d'application transformé issu de la première sous-étape. 9.- Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit langage commun de représentation des données du Web sémantique est le langage RDF. 10.- Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit langage de modélisation du Web Sémantique est le langage OWL. 11.- Procédé selon l'une des revendications précédentes caractérisé en ce qu'un des standards choisis est le standard I5015926. 12.- Dispositif programmable d'échange de données descriptives d'installations techniques entre au moins deux applications, une dite application étant apte à fournir et/ou à consommer des données selon un modèle de données d'application associé, permettant l'interopérabilité entre lesdites applications grâce à un échange des données exprimées et formalisées à travers au moins un standard choisi ayant un modèle de données associé et un format d'échange associé, caractérisé en ce qu'il comporte, pour au moins une application considérée, des modules aptes à fournir des moyens pour : - l'intégration du modèle de données d'application dans un langage de représentation des données du Web sémantique, dit langage commun de représentation, - pour chaque standard choisi, l'intégration du modèle de données du standard dans un langage de modélisation du Web sémantique, - l'obtention de premières règles (R1) de conversion entre le modèle de données d'application dans le langage commun de représentation et le ou les modèles de données des standards choisis dans le langage de modélisation du Web sémantique, - l'obtention de deuxièmes règles (R2) d'organisation et de contrôle des données à échanger, - la conversion des données de l'application en utilisant les premières et deuxièmes règles obtenues en données selon le ou les formats d'échange associés aux standards choisis, et - l'échange de données obtenues à l'étape de conversion selon le ou les formats d'échange associés aux standards choisis.