EP3005162A1 - Procédé d'échange de données descriptives d'installations techniques - Google Patents

Procédé d'échange de données descriptives d'installations techniques

Info

Publication number
EP3005162A1
EP3005162A1 EP14728179.4A EP14728179A EP3005162A1 EP 3005162 A1 EP3005162 A1 EP 3005162A1 EP 14728179 A EP14728179 A EP 14728179A EP 3005162 A1 EP3005162 A1 EP 3005162A1
Authority
EP
European Patent Office
Prior art keywords
data
application
rules
standard
language
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP14728179.4A
Other languages
German (de)
English (en)
Inventor
Philippe PERDRIAU
Hondjack DEHAINSALA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Areva NP SAS
Original Assignee
Areva NP SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Areva NP SAS filed Critical Areva NP SAS
Publication of EP3005162A1 publication Critical patent/EP3005162A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G06F8/22—Procedural
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion
    • G06F16/88—Mark-up to mark-up conversion

Definitions

  • the present invention relates to a method for exchanging data describing technical installations between at least two applications, a said application being able to provide and / or consume data according to an associated application data model.
  • the invention lies in the field of interoperability of descriptive technical data of industrial installations.
  • IS015926 In order to facilitate exchanges between industrial partners, the IS015926 standard has recently been developed. A description of this standard is available on the website: http://www.15926.org/. This standard specifies a representation of the information associated with the engineering, construction and operation of industrial installations, particularly in the field of energy production.
  • IS015926 consists of 9 parts, defining a conceptual data model (Part 2), a set of reference data (Part 4), topology and geometry reference data (Part 3), as well as integration (Part 7).
  • Part 2 a conceptual data model
  • Part 4 Part 4
  • Part 3 topology and geometry reference data
  • integration Part 7
  • the data model is based on object classes having kinship and specialization relationships, the object class relationships being categorized.
  • the standard formats for the exchange of descriptive technical data of industrial installations for example the ISO10303 and IS015926 formats, have similar characteristics, in that they specify a description language of a data model, a data model, a dictionary describing reference objects and their characteristics, and means for accessing and exchanging information.
  • various partners involved at various levels of business application may use different representations (carried by exchange standards different), representative, at least in part, of the same facilities and containing common technical data.
  • To achieve data exchange between business applications it is necessary either to generate descriptive data files, for example files in XML format, or to implement a conversion between the format used and an interoperability format such as the format defined by the standard IS015926.
  • the invention proposes, according to a first aspect, a method for exchanging data describing technical installations between at least two applications, a said application being able to supply and / or consume data according to a model of application-related data, the method allowing interoperability between said applications through an exchange of the expressed and formalized data through at least one selected standard having an associated data model and an associated exchange format, implemented by a programmable device.
  • the method according to the invention comprises, for at least one application considered, steps of:
  • the method according to the invention makes it possible to facilitate the interoperability between data models used by various applications and between various technical data exchange formats describing industrial installations.
  • the method according to the invention may have one or more of the following characteristics, taken independently or in combination:
  • the step of obtaining first conversion rules comprises the definition of unified transformation rules between application data and the chosen standard or standards, on the basis of the generic rule patterns. ;
  • the first conversion rules obtained are bijective rules, allowing a transformation of the application data to the chosen standard or standards, and a transformation of data according to the chosen standard or standards to data corresponding to the application model;
  • the first conversion rules are expressed declaratively and stored in one or more files
  • the step of obtaining first conversion rules comprises the creation or updating of an internal reference dictionary, in connection with the chosen standard or standards;
  • the step of obtaining second rules includes the definition of organization rules and exchanges controls to meet contractual requirements, confidentiality of the information to be exchanged and control information to integrate;
  • said second rules define exchange batches, making it possible to filter from the set of data of the application, a subset of data to be exchanged;
  • the integration step of the application data model in a representation language of the semantic web data comprises two sub-steps, a first substep of transformation of the application model in the data representation language.
  • the semantic web and a second substep of actual transformation of the application data by instantiating the transformed application model from the first substep;
  • said common semantic web data representation language is the RDF language;
  • said semantic Web modeling language is the OWL language
  • one of the standards chosen is the IS015926 standard.
  • the invention relates to a programmable device for exchanging data describing technical installations between at least two applications, a said application being able to provide and / or consume data according to an application data model. associated, allowing interoperability between said applications through an exchange of data expressed and formalized through at least one chosen standard having an associated data model and an associated exchange format.
  • the device of the invention comprises, for at least one application considered, modules able to provide means for:
  • the device of the invention comprises means for implementing all the steps of the method according to the invention briefly introduced above.
  • FIG 1 is a schematic example of an infrastructure implementing the invention
  • FIG. 2 schematically illustrates the principle of the invention
  • FIG. 3 represents the main processing operations of the process of the invention; - Figures 4 to 6 detail the main steps of the processing operations shown in Figure 3.
  • FIG. 1 illustrates an example of infrastructure 2 in which the method for processing descriptive data of technical installations according to the invention is implemented.
  • Infrastructure 2 comprises part 4 of an enterprise called enterprise infrastructure that includes 10.1, 10.2, 10n enterprise application database servers containing information from different business disciplines. to be exchanged with third parties or between them. These databases include descriptive data of technical installations.
  • Part 4 of the infrastructure 2 also includes workstations 20.1, 20.2, 20. n containing clients of these servers 10.1, 10.2, 10 .n, and an exchange computer server 30 allowing the execution of the operations of processing of the method according to the invention associated with a database containing the data to be published, as well as the conversion and control rules.
  • conversion rules refer to dictionaries 50 managed at the level of one of the companies, ie 60.x external dictionaries maintained by third parties (standardization bodies, published by other companies or maintained by representatives of a sector activity).
  • the workstations 20.1, 20.2 to 20. n implement application additions related to the exchange computer server 30 for organizing exchanges, verifying the data to be published or controlling the data to be integrated in the databases. profession of servers 10.1 to 10.n.
  • the enterprise infrastructure 4 also includes one or more workstations 40 making it possible to administer the exchange computer server 30 as well as to organize and monitor the exchanges, to establish the conversion rules and also to check or carry out the exchanges independently of each other. the use of workstations 20.1 to 20. n.
  • a mirror server 30 m synchronized with the server 30 is present, in order to isolate the internal network of the company from an externally accessible network 70, making it possible to meet the requirements of cyber security.
  • the servers 30 and 30 m according to the deployed configuration, are able to respond to third-party requests and to publish files and reports according to the various formats traditionally used by the technical data descriptive exchange standards of industrial installations, for example PDF, XLS, XML, OWL.
  • the servers 10.1 to 10.n, 30 and the workstations 20.1 to 20. n are, in known manner, programmable devices each comprising one or more processors able to perform calculations and to execute computer program instructions, and information storage means capable of storing executable code instructions enabling the implementation of programs comprising computer program code instructions.
  • Accesses are through the network 70 supporting conventional WEB technologies whether it is used in a private mode (intranet of a community) or public (internet).
  • FIG. 1 schematically illustrates the principle of the invention.
  • a business application A called simply application A thereafter, able to provide and process data representative of technical installations is described by its data model, which will be called Model A (MA in Figure 2).
  • This application includes information or data noted DA, which one wishes to publish according to different exchange standards according to their nature.
  • two standards are considered, denoted Standard 1 and Standard 2.
  • the standard 1 is the IS015926 standard and the standard 2 is the IS016739 standard.
  • the invention is not limited to the use of two standards, any number of standards can be used by applying the principle of the invention described below.
  • model A and the model B can be grouped in a model A + B.
  • Semantic Web technology in particular the RDF ("Resource Description Framework”) formalism, defined by the W3C ("World Wide Web Consortium"), for this aggregation, incrementally without calling into question the first implementations of the coupling between the data of the application A to an exchange standard described in more detail below.
  • RDF formalism is a graph model intended to formally describe Web resources and their metadata.
  • the MA Model is expressed in the RDF formalism of Semantic Web technology.
  • the standard data models, respectively M1 for the Standard 1 and M2 data model for the Standard 2 data model are provided by the standardization bodies in a description language that is directly available in the Semantic Web formalism, that is to say in the OWL language ("Web Ontology Language”) formalized in RDF, as is the case in the context of of NS015926, or in other language (for example EXPRESS in the context of NSO10303).
  • a first set of conversion rules (R1) is realized to allow the transformation of the data from the application A (also expressed in the RDF formalism and described through the MA data model) in the data model of the M1 standard. or M2; this work results from an analysis of MA and M1 or M2, in relation with RDL stored dictionaries ("Reference Data Library”) related to Standard 1 and Standard 2 standards.
  • a second set of rules of organization and control is realized to organize and control the exchanges, for the definition of batches of exchange, rules of checks of integrity, to pose numbers of versions or to trace the values exchanged or modified.
  • These rules R1 and R2 are implemented on the server 30, the conversion rules R1 are obtained by programming and the rules of organization and control R2 via a human-machine interface implanted on the workstation 40.
  • a first processing operation OP1 is carried out on the server 30, taking into account the data DA (expressed in RDL), the conversion rules R1 making it possible to transform them according to the expectations of the chosen standard, whether it is the Standard 1 or Standard 2, and taking into account R2 organizational and control rules to organize exchanges, control or produce traceability records.
  • the resulting DAS data of the transformation carried out by OP1 are therefore in accordance with the data model of the standard or standards, properly controlled and grouped together in an exchange batch but are still described in the RDF formalism of the Semantic Web.
  • both Standard 1 and Standard 2 standards are considered, two conversions are performed, making it possible to obtain resultant data for each standard.
  • a second OP2 processing operation makes it possible to publish this DAS data in the formalism (s) of the standard (s) retained, whether they be DAPS files in a usual format such as for example EXCEL®, XML, in RDF databases or by means of access via WEB services.
  • the processing operations OP1 and OP2 perform bijective transformations: they always use the same rule sets R1 and R2 to transform DA into DAS and vice versa DAS into DA, as well as DAS into DAPS and vice versa DAPS into DAS.
  • Extracting data from application A to produce DA or introducing DA data into the application is performed by specific connectors developed using programmatic interfaces of application A. These interfaces can be executed through the application.
  • the conversion rules R1 equate the attributes of the data model A (MA) with a dictionary giving a shared vocabulary (RDL of Figure 2).
  • This equivalence can be simple or can result from a combination of attributes.
  • the vocabulary can be defined and maintained by a standardization body, made available by reference actors (either at the level of a project or a community) or created for the needs of the company (private RDL) .
  • these conversion rules R1 systematically generate a private RDL and then an equivalence is made between a term of the private RDL and a term of a public RDL by substitution of the terms of the vocabulary knowing that the grammar of the standard is respected before and after the substitution.
  • FIG. 3 represents the main steps of the method of the invention implemented by one of the processes on the server 30.
  • Three processing blocks are represented, namely a block 100 of preparatory work, a block 200 of parameterization work and a block 300 of operations of effective data processing, respectively corresponding to the processing operations OP1 and OP2 of Figure 2.
  • the preparatory treatments are illustrated in more detail in FIG. 4.
  • the treatments T1 x (T10, T1 1, T12, etc.) are intended to exchange the data of the application A with their formalized equivalent in the data representation language of the Semantic Web, ie the RDF language.
  • RDF provides the means to express data elementary way to be transformable as instances in the data model of the application with which it is intended to exchange data, by means of data conversion rules.
  • this task consists in accessing the data of the application A via one of the interfaces offered by this application to transform them into an RDF triplet (Subject, Predicate, Object).
  • Predicates refer to concepts (Classes, properties).
  • a separation is made between the processing T10 of the data model (MA) and the processing T1 1 of the data (DA). Transformation of the application data model into an MA model is done only once until the data model of application A has changed at the T10 processing level; the changes come from planned developments of this application A which usually follow with a period of several years.
  • step T10 according to the nature of the technology of the application A (relational or semantic database, XML files, Excel® application), connectors are developed (in export or in import according to the needs), by using classical programming languages (C ++, Java or others), associated with the programmatic interfaces provided by the editors of these applications (for example PLM application editors to manage a repository of technical data or CAD applications to achieve computer-aided design).
  • C ++ classical programming languages
  • Java Java
  • the preparatory data extraction work processing consists of extracting (processing T1 1) the data DA of the application A to store them according to the data model in RDF in a memory 150 of the computer server exchange 30, or to import DA data into RDF to application A (T12 processing).
  • the T2x processes are aimed at transforming the data model of a chosen standard, whether Standard 1 or Standard 2, into the model representation formalism of the Semantic Web, that is, the language OWL modeling. If the model of the chosen standard expresses itself in the OWL language, this task is not necessary. This is the case of ISOI 5926 but also for other standards, for example PLCS for "Product Life Cycle Support”, ISO303-239 standard and BIM for Building Information Model, which express themselves in OWL.
  • a transformation of the data model in its representation formalism for example UML, XML-Schema, EXPRESS
  • the OWL language is performed at the level of the data model. T20, T21 treatment.
  • software bricks on the shelf are among others UML20WL, XSD20WL or Express20WL respectively for UML, XML-Schema or EXPRESS representation formalisms.
  • an ontology refers to the result of the formulation or transformation of the data model in the OWL language.
  • Parameterization and exchange organization processing is the second part of the process as shown in block 200 of FIG. 3.
  • the T3x processing defines the conversion rules R1 for converting the data into the expression language of the one or more selected standards and T4x processes define R2 organizational and control rules to organize, control and monitor exchanges.
  • FIG. 5 shows the organization of the T3x treatments and the input data and results produced.
  • the T3x processing is intended to define the conversion rules R1 that will be used to transform the data of the application A formalized in a RDF language resulting from the preparatory processes T10 to T12 in accordance with the OWL format (s) of the standard (s) resulting from the preparatory processes. T2x.
  • the R1 conversion rules produced are not coded in a program, but are expressed in a declarative way.
  • a rule is composed of a couple: (condition, actions).
  • the condition is a Boolean expression that applies to the data. If it is satisfied, it triggers the execution of a set of predefined operations such as add or modify or delete operations or their combinations.
  • the conversion rules are executed by a rules execution engine commonly known as reasoner.
  • Reasoners are rather complex computer programs to implement but in the trade, there are many reasoners (Pellet®, Racer®, SPINEngine®, etc.). Experiments method of the invention have been performed on the SPINEngine® reasoner of the editor TopQuadrant.
  • SPIN (SPARQL Inferencing Notation) is used to express rules patterns (or “templates” in English) to create R1 conversion rules. This language is used to encapsulate SPARQL queries, which is a language used to search, add, modify or delete RDF data. SPIN and SPARQL are two languages of the Semantic Web.
  • a rule pattern is a generic rule that carries semantics by implementing simple or complex operations.
  • a pattern is characterized by the fact that it defines input parameters and implements a certain logic of transformations and / or encodings to be performed on the basis of these parameters.
  • a rule is no more than a pattern instance with values specific to its parameters, as explained in the T31 process.
  • the number of rule patterns and their complexities, to be defined during the T30 processing, are functions of the major differences that may exist between the semantics of the M1, M2 (applications / ontologies) models, defined from the meta models of these standards, for which the matching rules are created.
  • Generic rule patterns allow you to hide the diversity of the data models of the chosen standards (Standard 1 or Standard 2 in the example) as support for exchanges or interoperability functions.
  • a set of rule patterns P is stored.
  • the processing T31 of definition of the correspondences C between the two models of data consists in building semantic links between the concepts (classes and / or properties and / or instances) of the models. For each correspondence, also called “mapping", between concepts, the user associates two rule patterns in order to be able to transform data from Standard 1 to Standard 2 and vice versa. In this case, the correspondence C is reversible.
  • the user can provide only one rule pattern, for example from Standard 1 to Standard 2.
  • the correspondence C is mono-directional, and not reversible.
  • Step T31 is a key step in the process because it requires in-depth knowledge of both models (Standard 1 and Standard 2) to establish matches, which are semantic links, as well as the choice of rule patterns.
  • a data model is defined to express these C correspondences with their associated P rules patterns.
  • the data model instances are the
  • mappings Some examples of mappings:
  • the rule generator of the step T32 takes as input the results of the processing T31:
  • R1 conversion rules are defined, making it possible to establish equivalences between this internal RDL and the available dictionaries, whether they are published at the level of a standardization organization, a community or a project. If we do not find a match in these dictionaries, the internal RDL can then serve as a basis for a private RDL or project, or even community, which can then be integrated into a standard.
  • step T32 builds the following conversion rules (Standard 1 Standard 2)
  • T4x processing has the goal of defining rules of organization and control R2 allowing to organize, control or follow the exchanges.
  • a processing module is developed to add complementary R2 organization and control rules to the R1 conversion rules produced by the T3x processing, and whose objectives are to build metadata in the form of reports on the data of the applications they are in their original form (that is to say conforming to the data model of the application, for example MA for the application A) or that they are expressed in the language of the selected standard (s) (M1 for Standard 1 and M2 for Standard 2).
  • M1 for Standard 1 and M2 for Standard 2 selected standard
  • T4x treatments break down into two stages.
  • T41 Constitution of reports and their organization / hierarchical classifications in packages (directories) for their publications.
  • T42 Publication of the data which will aim to execute the packages and possibly send it to internal or external partners.
  • the reports are complementary links between a data and:
  • a control rule (allowing to know if received data respects certain coherence rules) or if the authorization to modify the data is available.
  • This last type of data source will allow the federation / integration of all data sources.
  • the report request will be sent in parallel to the data source.
  • the report forming step T41 is followed by a publication step T42.
  • the exchange lot can also have additional reports with:
  • the address of information storage areas accessible by the recipient which may be the http address of a facade, an FTP server, a shared disk.
  • FIG. 6 illustrates in more detail the conversion processing operations T5x and T6x of FIG. 3.
  • the processing T50 first produces data 600 presented according to the logic of the standard or standards Standard 1, Standard 2 following the execution. rules from T3x, based on the stored sets of rules R1 and R2.
  • the processed application data, DA data for application A and DB data for application B, are provided as input to processing T50.
  • the T51 processing organizes and controls the data to be exchanged according to the execution of the R2 rules from T4x.
  • standardized and organized data 610 denoted DAS for application A and DBS for application B, are obtained.
  • T60 processing converts formalized RDF 610 data to the data recommended by the standard Standard 1 or Standard 2 chosen.
  • T50 and T51 processes are in fact identical, applied by a Rule Execution Engine or Reasoner.
  • the purpose of the T60 processing is to transform the data 610 which are logically expressed and organized in data 620 respecting a formalism recommended by the standard (s) chosen to support the exchange.
  • This formalism can be EXCEL®, XML or an RDF / OWL format.
  • the T60 treatment is useless, the data 610 DAS, DBS already being formalized in RDF.
  • Data 620, denoted DASP for application A and DBSP for application B are obtained.
  • the T60 processing is similar to a connector as defined in the T12 process. It is specific to the chosen standard. Treatments T12, T50, T51 and T60 can work in both directions (export and import to application A and a partner).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)

Abstract

Procédé d'échange de données descriptives d'installations techniques L'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é, 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 œuvre par un dispositif programmable. Pour au moins une application, le procédé de l'invention comporte l'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, et, pour chaque standard choisi, l'intégration (T2x) du modèle de données du standard dans un langage de modélisation du Web sémantique. En outre, le procédé permet l'obtention (T3x) 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, et l'obtention (T4x) de deuxièmes règles d'organisation et de contrôle des données à échanger, permettant la conversion et l'échange des données de l'application en utilisant ces règles de conversion.

Description

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 œuvre 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 ISO10303 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 ISO10303 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 serveurs 10.1 à 10.n, 30 et les postes de travail 20.1 à 20. n sont, de manière connue, des dispositifs programmables comportant chacun un ou plusieurs processeurs aptes à effectuer des calculs et à exécuter des instructions de programme informatique, et des moyens de stockage d'informations aptes à stocker des instructions de code exécutable permettant la mise en œuvre de programmes comportant des instructions de code de programme informatique.
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 NS015926, soit dans un langage autre (par exemple EXPRESS dans le cadre de NSO10303).
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 (« Référence 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 OP2 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 OP2 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 œuvre 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 OP2 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 (T1 x) 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 T1 x (T10, T1 1 , 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 T10 du modèle de données (MA) et le traitement T1 1 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 T10 ; 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 : 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>
■ Vanne#1 # <Tag> #1 #
■ Vanne#1 # <Diamètre> 50
■ Vanne#1 # <Unit> m
Pour cette étape T10, selon la nature de la technologie de l'application A (base de données relationnelle ou sémantique, fichiers XML, application Excel®), 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 T1 1 ) 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 T12).
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 l'ISOI 5926 mais aussi pour d'autres normes, par exemple PLCS pour « Product Life Cycle Support », standard ISO303-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 T20, T21 . Pour cela, il est possible d'utiliser des briques logicielles sur étagère. Ces briques logicielles sont entre autres UML20WL, XSD20WL ou Express20WL 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 T20, et la transformation du modèle de données du Standard2 vers le langage OWL à l'étape T21 .
Ces étapes T20, T21 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 T4x 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 T3x et les données d'entrée et résultats produits.
Les traitements T3x 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 T10 à T12 en conformité avec le ou les formats OWL du ou des standards issus des traitements préparatoires T2x.
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 œuvre mais dans le commerce, il existe de nombreux raisonneurs (Pellet®, Racer®, SPINEngine®, etc.). Les expérimentations du procédé de l'invention ont été effectuées sur le raisonneur SPINEngine® de l'éditeur TopQuadrant.
Le langage SPIN (« SPARQL Inferencing 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 : Classification RuieTemplate
o Description : Patron de règle qui permet de créer une instance d'une classe du Standard "I dans 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 T30, un ensemble de patrons de règles P est mémorisé.
Le traitement T31 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 T31 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 T32 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 (1 2) : ClassificationRuleTemplate o Patron (2*1) : ClassificationRuleTemplate
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 (1 *2) : PropertyUnitConversionRuleTemplate o Patron (2*1) : PropertyUnitConversionRuleTemplate La dernière étape T32 du processus consiste à produire les règles de conversion
R1 qui seront fournies au raisonneur (comme décrit ci-après en référence au traitement
T51 ) pour produire les données. Le générateur de règles de l'étape T32 prend en entrée les résultats du traitement T31 :
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 T32, 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 T32, 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 T32 construit les règles de conversion suivantes (Standard 1 Standard 2)
Règle R1 1 - 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 T4x 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 T3x, 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.
T41 : Constitution des rapports et leurs organisations/classifications hiérarchiques dans des packages (répertoires) en vue de leurs publications.
T42 : 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 T41 de constitution du rapport est suivie d'une étape T42 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>
■ Valve#1 # <ID> #1 #
■ Valve#1 # <radius> 2500
■ Valve#1 # <Unit> 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).

Claims

REVENDICATIONS
1 . - 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 œuvre par un dispositif programmable,
caractérisé en ce qu'il comporte, pour au moins une application considérée, des étapes de :
- intégration (T1 x) 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.
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.
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 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 (T1 1 , 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.
1 1 . - Procédé selon l'une des revendications précédentes caractérisé en ce qu'un des standards choisis est le standard IS015926.
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.
13. - Produit programme d'ordinateur comportant des instructions pour mettre en œuvre les étapes d'un procédé d'échange de données descriptives d'installations techniques entre au moins deux applications selon les revendications 1 à 1 1 lors de l'exécution du programme par un processeur d'un dispositif programmable.
EP14728179.4A 2013-06-04 2014-06-03 Procédé d'échange de données descriptives d'installations techniques Withdrawn EP3005162A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1355133A FR3006473B1 (fr) 2013-06-04 2013-06-04 Procede d'echange de donnees descriptives d'installations techniques
PCT/EP2014/061505 WO2014195325A1 (fr) 2013-06-04 2014-06-03 Procédé d'échange de données descriptives d'installations techniques

Publications (1)

Publication Number Publication Date
EP3005162A1 true EP3005162A1 (fr) 2016-04-13

Family

ID=49111393

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14728179.4A Withdrawn EP3005162A1 (fr) 2013-06-04 2014-06-03 Procédé d'échange de données descriptives d'installations techniques

Country Status (6)

Country Link
US (1) US20160139886A1 (fr)
EP (1) EP3005162A1 (fr)
JP (1) JP2016526231A (fr)
CN (1) CN105308593A (fr)
FR (1) FR3006473B1 (fr)
WO (1) WO2014195325A1 (fr)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105786584B (zh) * 2016-03-02 2019-03-19 武汉金思路科技发展有限公司 一种适应多样式bim建模软件界面解析方法
CN107818121B (zh) * 2016-09-14 2022-05-10 阿里巴巴集团控股有限公司 一种html文件压缩方法、装置及电子设备
LU93300B1 (de) * 2016-11-10 2018-06-18 Phoenix Contact Gmbh & Co Kg Intellectual Property Licenses & Standards Austausch von Echtzeitdaten zwischen Programmmodulen
US10841337B2 (en) 2016-11-28 2020-11-17 Secureworks Corp. Computer implemented system and method, and computer program product for reversibly remediating a security risk
EP3401801A1 (fr) * 2017-05-12 2018-11-14 BAE SYSTEMS plc Système de stockage et de récupération de données améliorés
EP3622417A1 (fr) 2017-05-12 2020-03-18 BAE Systems PLC Système de stockage et de récupération de données améliorés
WO2018206973A1 (fr) 2017-05-12 2018-11-15 Bae Systems Plc Système de stockage et de récupération de données améliorés
AU2018267280B2 (en) * 2017-05-12 2023-08-03 Bae Systems Plc A system for improved data storage and retrieval
EP3447639A1 (fr) * 2017-08-22 2019-02-27 Siemens Aktiengesellschaft Dispositif et procédé d'accouplement d'une machine dotée d'une pluralité d'applications
US10735470B2 (en) 2017-11-06 2020-08-04 Secureworks Corp. Systems and methods for sharing, distributing, or accessing security data and/or security applications, models, or analytics
US10594713B2 (en) * 2017-11-10 2020-03-17 Secureworks Corp. Systems and methods for secure propagation of statistical models within threat intelligence communities
EP3582125B1 (fr) * 2018-06-11 2022-08-03 ABB Schweiz AG Système et procédés à complexité réduite dans l'intégration de modèles d'information exposés avec des applications
US10785238B2 (en) 2018-06-12 2020-09-22 Secureworks Corp. Systems and methods for threat discovery across distinct organizations
US11003718B2 (en) 2018-06-12 2021-05-11 Secureworks Corp. Systems and methods for enabling a global aggregated search, while allowing configurable client anonymity
US12346099B2 (en) 2018-11-20 2025-07-01 Siemens Aktiengesellschaft Method for transforming a data model for automation purposes into a target ontology
JP7059916B2 (ja) * 2018-12-18 2022-04-26 日本電信電話株式会社 情報処理システム、方法およびプログラム
US11310268B2 (en) 2019-05-06 2022-04-19 Secureworks Corp. Systems and methods using computer vision and machine learning for detection of malicious actions
US11418524B2 (en) 2019-05-07 2022-08-16 SecureworksCorp. Systems and methods of hierarchical behavior activity modeling and detection for systems-level security
CN110737940A (zh) * 2019-09-30 2020-01-31 深圳市华阳国际工程设计股份有限公司 一种bim制图标准的替换方法、装置及计算机存储介质
US11381589B2 (en) 2019-10-11 2022-07-05 Secureworks Corp. Systems and methods for distributed extended common vulnerabilities and exposures data management
US11522877B2 (en) 2019-12-16 2022-12-06 Secureworks Corp. Systems and methods for identifying malicious actors or activities
US11588834B2 (en) 2020-09-03 2023-02-21 Secureworks Corp. Systems and methods for identifying attack patterns or suspicious activity in client networks
US11528294B2 (en) 2021-02-18 2022-12-13 SecureworksCorp. Systems and methods for automated threat detection
US11782682B2 (en) 2021-07-13 2023-10-10 The Math Works, Inc. Providing metric data for patterns usable in a modeling environment
US12135789B2 (en) 2021-08-04 2024-11-05 Secureworks Corp. Systems and methods of attack type and likelihood prediction
US12034751B2 (en) 2021-10-01 2024-07-09 Secureworks Corp. Systems and methods for detecting malicious hands-on-keyboard activity via machine learning
US12556566B2 (en) 2022-05-11 2026-02-17 Secureworks Corp. Systems and methods for dynamic vulnerability scoring
US12015623B2 (en) 2022-06-24 2024-06-18 Secureworks Corp. Systems and methods for consensus driven threat intelligence
US12609969B2 (en) 2022-11-03 2026-04-21 Secureworks Corp. Systems and methods for detecting security threats
CN120893110B (zh) * 2025-10-09 2025-12-26 四川省生态环境科学研究院 一种bim模型属性定义及编码方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8225282B1 (en) * 2003-11-25 2012-07-17 Nextaxiom Technology, Inc. Semantic-based, service-oriented system and method of developing, programming and managing software modules and software solutions
RU2589342C2 (ru) * 2010-06-23 2016-07-10 Кониклейке Филипс Электроникс Н.В. Взаимодействие между множеством систем защиты данных
CN102004767A (zh) * 2010-11-10 2011-04-06 北京航空航天大学 一种基于抽象业务逻辑的交互式语义Web服务动态组合方法
CN102843245B (zh) * 2011-06-20 2017-08-18 中兴通讯股份有限公司 配置数据交互方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2014195325A1 *

Also Published As

Publication number Publication date
CN105308593A (zh) 2016-02-03
FR3006473A1 (fr) 2014-12-05
JP2016526231A (ja) 2016-09-01
FR3006473B1 (fr) 2017-10-13
US20160139886A1 (en) 2016-05-19
WO2014195325A1 (fr) 2014-12-11

Similar Documents

Publication Publication Date Title
EP3005162A1 (fr) Procédé d&#39;échange de données descriptives d&#39;installations techniques
US20190129724A1 (en) Formalized Execution of Model Integrated Descriptive Architecture Languages
Eichelberger et al. Using ivml to model the topology of big data processing pipelines
El-khoury et al. An industrial evaluation of data access techniques for the interoperability of engineering software tools
EP2297681A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
Scherp et al. Semantic web: Past, present, and future
Lipp et al. The semantic web in the internet of production: a strategic approach with use-case examples
Diamantini et al. A virtual mart for knowledge discovery in databases
EP2281271A1 (fr) Procede de gestion de processus dans un atelier oriente service collaboratif
Eiden et al. Supporting semantic PLM by using a lightweight engineering metadata mapping engine
El-khoury et al. A model-driven engineering approach to software tool interoperability based on linked data
Fillotrani et al. Evidence-based lean conceptual data modelling languages
Telenyk et al. Conceptual foundations of the use of formal models and methods for the rapid creation of web applications
Mocan et al. Solving semantic interoperability conflicts in cross-border e-government services
US20250298844A1 (en) Queryable asset model associated with opc ua and graph
Mahmudi et al. Ontology to relational database transformation for web application development and maintenance
Al Manir et al. Valet SADI: provisioning SADI web services for semantic querying of relational databases
Hamdan et al. Semantic Interoperability in Multi-Cloud Platforms: A Reference Architecture Utilizing an Ontology-Based Approach.
El Asikri et al. A brief survey of Creating Semantic Web content with Protégé
Abdelhedi et al. Conceptual modeling of a document-oriented NoSQL database
Cheng et al. Discrete manufacturing ontology development
Pessemier Knowledge-driven development of telescope control systems
Rosser et al. Full Metadata Object profiling for flexible geoprocessing workflows
Al Wardani About Trust and Proof: a situation, a contemplation, and a framework
WO2008043392A1 (fr) Procede pour traiter des informations

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20151123

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DEHAINSALA, HONDJACK

Inventor name: PERDRIAU, PHILIPPE

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20170714

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180125