Classifications

• • G—PHYSICS
  • G05—CONTROLLING; REGULATING
  • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
  • G05B19/00—Program-control systems
  • G05B19/02—Program-control systems electric
  • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
  • G05B19/4185—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
  • G05B19/4186—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication by protocol, e.g. MAP, TOP
• • 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
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
  • G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
  • G06F16/367—Ontology
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/901—Indexing; Data structures therefor; Storage structures
  • G06F16/9024—Graphs; Linked lists
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]

Definitions

• the present embodiments relate to a method for transforming a data model for automation purposes into an ontology. More spe cifically, the present embodiments relate to a method for trans forming a semantically enriched and graph-based data model dedi cated for automation purposes into a target ontology.
• OPC UA Open Platform Communications Uni fied Architecture
• OPC Foundation Open Platform Communications Uni fied Architecture
• OPC UA A data model of OPC UA features a semantically enriched and graph-based data structure which is dedicated to automation pur poses.
• OPC UA rather defines concepts for expressing semantic descriptions within the specification documents which means that a formal semantic representation is lacking.
• Accord- ingly, the usage of OPC UA suffers from significant drawbacks due to its lack of formal semantic representation:
• OPC UA defines a query language for ac cessing the data model, no framework for implementing query requests exists to date, not least due to the high complexity imposed for querying the semantic descriptions scattered with in the data model of OPC UA.
• Embodiments herein generally involve a transformation of the da ta model into an ontology which is understood as a formal seman tic representation of terminology and concepts, as well as the relationships among those concepts.
• Ontologies readily provide the desired capabilities for validation, querying and analytics the data model using sophisticated standard tools adapted to the formal representation of the ontology.
• a computer-implemented method for transform ing a semantically enriched and graph-based data model into a target ontology wherein at least one layer of the data model is provided by a first memory unit.
• the data model includes a plurality of nodes described by attributes and inter connected by references.
• identifications are retrieved from said nodes of the data model. Each identification is thereby expressed - i.e. replaced or amended - by a URI or Unique Resource Identifier conforming to a REST (Representation al State Transfer) ruleset.
• REST Representation al State Transfer
• seman tic descriptions of one or more references interconnecting one or more nodes are retrieved.
• These semantic descriptions are ex pressed - i.e. replaced or amended - by at least one predicate and/or at least one class in the target ontology to be produced.
• the target ontology is structured by a semantic on tology language and output to a triple store.
• a transformation unit comprising a processor and a data storage device having stored thereon a computer executable program code.
• the data storage device may be implemented within or external to the processor.
• a non-transitory computer- readable storage medium having stored thereon computer executa ble program code is provided.
• FIG shows a layered architectural framework in accordance with the modular structure of OPC UA.
• the OPC UA framework provides a layered structure as follows:
• OBM A most general OPC UA Core Model or OPC UA Base Layer OBM is provided by the OPC Foundation itself.
• the core model OBM in cludes specifications of base variable types, server types, engineering units etc. on a Base Layer 1.
• At least one so called OPC UA companion specification CS1,CS2 is used to define domain spe cific models or schemas extending the OPC UA model.
• a Lower Companion Specification CS1 may include a topology element type definition; an Upper Companion Specification CS2 may in clude stream type definitions or, more specific, an axis type for a CNC machine (Computer Numerical Control) .
• An Extension Layer 3 above is hosting OEM specific (Original Equipment Manufacturer) schema extensions authored by OEMs, including, for example, a Device Vendor Information Model DVI comprising device type descriptions, a Machine Vendor Infor mation Model MVI comprising machine type descriptions and a Machine User Information Model MUI comprising process types or factory element types.
• OEMs including, for example, a Device Vendor Information Model DVI comprising device type descriptions, a Machine Vendor Infor mation Model MVI comprising machine type descriptions and a Machine User Information Model MUI comprising process types or factory element types.
• an Instance Layer 4 on the top of the layered mod el includes a Device/Asset Information Model DIM, i.e. an in stance model for describing configuration and data items of individual devices based on schemas defined in the layers 0 , 1 , 2 , 3 below .
• DIM Device/Asset Information Model
• OIM OPC UA Information Modelling
• OIM perpendicular to the lay ers 0,1, 2, 3, 4 symbolizes the consistency in the OPC UA data model throughout all layers 0,1, 2, 3, 4.
• An expressivity of in formation models generally increases from a lower layer to a higher layer.
• a transformation process TRF for transforming the infor mation models or data models within a respective layer 0,1, 2, 3, 4 into a respective ontology ONT can be advantageously carried out in a likewise modular way, as shown in the drawing.
• the embodiments advantageously support providing one or more layers of a data model in order to be transformed to a respec tive ontology ONT.
• the transformation process TRF transforms OPC UA information models or data models by translating each of the modules on the respective layer into ontologies ONT that import each other in the same way as respective OPC UA modules. Once this transformation process TRF is performed, the resulting on tologies ONT can be used for the purpose of validation, querying and analytics.
• the OPC UA graph as a graph-based data model is transformed to an RDF based target ontology which is then subjected to the validation using standard ontology tools instead of validating the graph-based data model.
• This validation step it is possible to check the consistency of the target ontology using conventional reasoners without additional effort for implementing validation algorithms.
• This approach will also support automatic rule updates through the declarative nature of a semantic ontology language used to build the target ontology.
• this validation can be done on the base layer 1 to ensure the consistency of the core speci fication itself, the companion layer 2 for validating newly de veloped companion specifications against the core specification, the extension layer 3 for validating vendor specific extensions against the underlying schemes, and finally the instance layer 4 for validating the instance model against a given schema.
• OPC UA rules Web Ontology Language
• SHACL Shapes Constraint Language
• the embodiments advantageously support providing an easy access to OPC UA data model using the common query language SPARQL (SPARQL Protocol and RDF Query Language) .
• SPARQL SPARQL Protocol and RDF Query Language
• the embodiments ensure an RDF representation within the target ontology as an outcome, which captures OPC UA seman tics in a formal way.
• Querying is typically occurring on the in stance layer in order to find the requisite data points for oth er applications (e.g., monitoring, human machine interfaces, maintenance ...) .
• queries can be used as well for intro spection purpose on the extension layer 3 and the companion lay er 2 and further on for validations on the base layer 1.
• the embodiments advantageously support gaining access to the semantics of OPC UA companion standards in a formal way.
• the formal access enables use cases like skill matching, onboarding, monitoring, etc. This is particularly use ful for the instance layer 4 in combination with the companion layer 2, where the companion layer 2 provides the standardized semantics for a given domain, and whereby the instance layer 4 provides specific values, which are tagged by these semantics.
• Based on the companion layer 2 semantic interoperability can be achieved by widely accepted standardized vocabularies for a giv en domain.
• the formal OWL representation can also be used to in terconnect different OPC UA Companion Specifications, to express the fact that two concepts from different domains mean the same (e.g., temperature), which is currently not standardized in OPC UA itself.
• the Extension-Layer can also be used for analyt ics and is especially useful to easily import ontologies into OPC UA without the formal standardization process of the OPC Foundation. Such import of ontologies may be processed using ex- isting ontologies like schema.org or the semantic sensor network ontology .
• identifications or NodelDs of UPC UA nodes are retrieved, and each identification is expressed by a URI (Unique Resource Identifier) conforming to a REST (Representational State Transfer) ruleset.
• URI Uniform Resource Identifier
• REST Representational State Transfer
• every entity in the address space is a Node.
• each node has a Nodeld in cluding three elements, namely a Namespacelndex, an Identi- fierType and an Identifier.
• the Namespacelndex is an index, usually a numeric value, used by an OPC UA server in online operation instead of a namespace identifier in order to expedite transfer and processing of data.
• the namespace identifier identifies a naming authority defining the identifiers of Nodelds, e.g. the OPC Foundation, other standard bodies and consortia, the underlying system, or the lo cal server.
• the Namespacelndex is stored in a repository along with its respective namespace identifier or namespace URI (Uni form Resource Identification) . This repository within OPC UA is also referred to as namespace array.
• the IdentifierType defines a data type of the identifier, e.g. a numeric value, a string, etc. The Identifier, eventually, identifies the Node in the ad dress space of an OPC UA server.
• Node has a common identifier (e.g., DisplayName, De scription) .
• the retrieval of identifications may, therefore, op tionally be accompanied by a retrieval of a browse name or
• OPC UA allows multiple nodes sharing a same browse name.
• the BrowseName according to OPC UA cannot be used to unambiguously identify a node in all cases - as different nodes may have the same BrowseName - a namespace of the BrowseName may provide to make the BrowseName unique in some cases in the context of a Node, e.g. some properties of a node.
• An exemplary identification of a node (based on the Nodeld) is structured as follows:
• »NamespaceString is a string expressing the namespace identifier. Said string is gathered from the NamespaceArray based on the Namespacelndex, here with a numerical value of 1 (one) of the Nodeld. The NamespaceString is required to end with slash or »/ «. The Nodeld is composed as described further down below.
• the Namespacelndex i is set to 1 because this is the in dex for the local server which has to be equal with the
• NamespaceString An exception is a Namespacelndex with a value of zero or »0«, indicating, that this Node is part of the OPC UA base model OBM. However, it is only allowed to omit the corre sponding NamespaceArray if the »NamespaceString « is equal to in dex 1 of the NamespaceArray.
• a further exemplary identification of a node including a quali fied name is structured as follows:
• the NamespaceString is based on the corresponding entry of the NamespaceArray, e.g.,
• a further exemplary identification of a node including a query is structured as follows:
• Such OPC UA identifications of a Node as shown above are to be expressed by a URI conforming to a REST or Representational State Transfer ruleset.
• Representational State Transfer or REST, is a software architectural style defining a set of con straints to be used for creating web services.
• One of the con straints of REST is a uniform identification of resources of URIs, e.g. according to the suggestion RFC 3986 (»Requests for Comments «) of the Internet Engineering Task Force (IETF) .
• »/V1.04 designates version of the API (Application Programming Interface) or apiVersion, which is usually set by the OPC Foun dation.
• the optional sequence »/lllll designates a version of the URI or uriVersion being property value of the OPC UA server.
• the first step of the embodiments for retrieving No- delDs - and, optionally, browse names - and expressing these by a URI conforming to a REST ruleset provides simply accessibility by web-clients conforming to a REST architecture style.
• the URIs are provided in a format which is literally read able for humans. This readability is advantageously improving a user experience when applying ontology editor and knowledge man agement system tools like SPARQL and Protege.
• Protege is a free, open source ontology featuring a graphic user interface for defining and amending ontologies.
• Protege includes deductive classifiers for validating a consistency and for in ferring new information based on the analysis of an ontology.
• semantic descrip tions of references between nodes are retrieved for expressing the semantic descriptions by at least one predicate and/or at least one class of the target ontology.
• a predicate is part of a semantic triple, which is an atomic da ta entry of an ontology organized by a data model in a Resource Description Framework (RDF) according to specifications of the World Wide Web Consortium (W3C) .
• RDF Resource Description Framework
• W3C World Wide Web Consortium
• a triple is a set of three en tities that codifies a statement about semantic data in the form of subject-predicate-object expressions. Triples are usually or ganized and stored in a database entitled triple store.
• mapping specifically means applying rules for retrieving or parsing se mantic descriptions scattered within the data model of OPC UA, classifying these semantic descriptions with common concepts and subsuming the classified concepts to a formal data representa tion in a semantic ontology language.
• a preferred semantic ontology language - amongst other semantic ontology language as RDF, RDFS or RDF schema - is provided by a language family referred to as OWL or Web Ontology Language.
• the OWL language family is structured in conformance with the XML standard of W3C for objects according to the Resource Descrip tion Framework or RDF.
• OWL in combination with RDF has a wide dissemination in implementing knowledge representation for au thoring ontologies.
• compound names with one or more medial capi tals - e.g. a compound name »TypeDefinitionNodes « - are used to refer to authoritative names used in the the specification »OPC Unified Architecture « of the OPC Foundation or in the OWL speci fication.
• These authoritative names are assumed to be known and for a person skilled in the art.
• these authorita tive names are, therefore, introduced without explanation.
• OPC UA references include suitable semantic de scriptions to be expressed by - or mapped to - at least one predicate of the target ontology:
• OPC UA semantics are trans formed to an ontology or OWL class concept.
• ontol ogy class concepts of OWL have appropriate counterparts within semantics of OPC UA suitable for mapping: -
• the class concept »Base« is derived from the BaseNodeClass of OPC UA and the super type of each concrete instance NodeClass.
• the class concept »MethodType « is a helper class to cover and tag all method semantics.
• the semantics can be captured based on the ObjectType and the BrowseName of the Method.
• the class concept »InstanceDeclaration» includes the sub classes MethodlnstanceDeclaration, ObjectInstanceDeclaration and Varia- blelnstanceDeclaration .
• the restrictions regarding instances of InstanceDeclarations in the OPC UA specifications, part 3, chap ter 6.3.6 are modelled using the OWL-Classes and the Subclass- Concept in combination with OWL DataProperty restrictions.
• the class concept »DataType « is built using restrictions on DataTypes in combination with OPC UA variables and OPC UA varia ble types or VariableTypes .
• the »DataType « class concept is structured using OWL classes and the OWL subclass Concept in combination with OWL object property restrictions and the OWL union concept in order to structure the DataType field seman tics, further including restrictions on the structure of
• DataType-Field constraints like a data type.
• An exemplary data type is a 32 bit long unsigned integer or UInt32.
• the class concept »MethodType« is the top-level-concept for all InstanceDeclaration-Methods .
• the semantic definition of methods is comparable to properties. Typical methods are defined by the »owning Object « and the assigned BrowseName. The following rules are to be applied for structuring the MethodType concept:
• the class concept »ObjectType « is used to capture the semantics of the OPC UA concept and to assign restrictions of the corre sponding InstanceDeclaration and ModellingRules .
• An ObjectType consists of Annotation Properties including labels, comments etc.
• the class concept in the ontology is modelled using OWL classes and the OWL-Subclass-Concept in combination with OWL DataProperty restrictions and OWL AnnotationProperties .
• the OWL DataProperty restrictions are modeled according to rules formal ized in the OPC UA specification in part 3 of the specification.
• the ArrayDimensions Attribute may be added if it was not provided or when modifying the value of an entry in the ar ray from 0 to a different value. All other values in the ar ray shall remain the same.
• a Varia- bleType consists of Annotation Properties including labels, com ments etc.
• the class concept in the ontology is modelled using OWL classes and the OWL-Subclass-Concept in combination with OWL DataProperty restrictions, OWL ObjectProperty restrictions and OWL AnnotationProperties .
• the OWL DataProperty restrictions are modeled according to the rules formalized in the OPC UA specifi cation in part 3 of the specification.
• Properties are modeled in the ontology by the following mapping rule. Definitions of Properties and their BrowseNames, i.e. a Property BrowseName, are introduced as a subconcept of the Prop- ertyType for each unique Property-BrowseName . This general map ping rule will ensure that Properties with equal BrowseNames will also be mapped to the corresponding Property-BrowseName concept .
• each BrowseName of an InstanceDeclaration is to be mapped to an object property.
• Each StructureFieldName is to be mapped to an object property with the namespace of the Struc- ture-DataType-Namespace and the string-part with the FieldName.
• the description of the Structure-DataType-Field may be mapped to an rdfs: comment annotation.
• ReferenceTypes in OPC UA are to be mapped to object properties in the ontology. All references which are not symmetric must have an »inverse « counterpart.
• inverseHierarchicalReferences Is to be used (e.g., inverseHierarchicalReferences ) .
• the Hier- archicalReferences tree must be completely mirrored. If a Refer- enceType is defined as symmetric and hierarchical, the reference has to be a subtype of the forward and the inverse tree. Symmet ric references - i.e. Symmetric-Attribute is set to true - will also be reflected by setting a SymmetricObjectProperty to true.
• the present invention allows using already existing semantic web reasoning tools for validation of OPC UA information models.
• An other advantage is the fact that through the declarative nature of web ontology languages, specifically OWL, newly added rules can be processed without modifying the code base.
• the present invention enables querying an OPC UA data model.
• querying of the OPC UA data models becomes feasible.
• the invention pro vides a method wherein the triples are generated in such a way that the semantics of OPC UA are captured, offering possibili ties to reduce the effort for formulating queries by a huge mag nitude.
• semantic Web experts as well as OPC UA experts are able to formulate queries.
• the present invention further enables analyzing the OPC UA data model. Based on the formal representation of OPC UA semantics it is now possible to do tasks like skill-matching, onboarding of devices into machinery, data-Mining etc.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• Data Mining & Analysis (AREA)
• Life Sciences & Earth Sciences (AREA)
• Computational Linguistics (AREA)
• Animal Behavior & Ethology (AREA)
• Software Systems (AREA)
• Manufacturing & Machinery (AREA)
• Quality & Reliability (AREA)
• Automation & Control Theory (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Machine Translation (AREA)
• Information Transfer Between Computers (AREA)

Priority Applications (6)

Applications Claiming Priority (1)

Publications (1)

Family

ID=64661274

Family Applications (1)

Country Status (6)

Cited By (5)

Families Citing this family (10)

Citations (2)

Family Cites Families (6)

• 2018
  • 2018-11-20 US US17/295,429 patent/US12346099B2/en active Active
  • 2018-11-20 CN CN201880099661.0A patent/CN112997170B/zh active Active
  • 2018-11-20 EP EP18815524.6A patent/EP3861463A1/en not_active Withdrawn
  • 2018-11-20 KR KR1020217018750A patent/KR102662252B1/ko active Active
  • 2018-11-20 WO PCT/EP2018/081938 patent/WO2020104019A1/en not_active Ceased
  • 2018-11-20 JP JP2021527250A patent/JP7317961B2/ja active Active

Patent Citations (2)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events