KR20210057533A - Method for converting AutomationML data model to OPC UA information model, and Apparatus thereof - Google Patents

Abstract

The present invention relates to a method for converting an AutomationML data model to an OPC UA information model to automatically convert an AutomationML data model into an OPC UA information model without information loss or errors and an apparatus thereof. According to one embodiment of the present invention, a data conversion model comprises the following steps: receiving an AutomationML file created according to an AutomationML model and parsing AutomationML elements and data for the AutomationML elements from the received AutomationML file to generate a data structure; using a mapping rule which maps the AutomationML elements to the OPC UA nodes to convert the AutomationML elements into OPC UA nodes on the basis of the generated data structure; and using the converted OPC UA nodes to generate an OPC UA file according to the OPC UA model.

Description

TECHNICAL FIELD [Method for converting AutomationML data model to OPC UA information model, and Apparatus thereof]

The present invention relates to a data model conversion method, and more specifically, to a data model conversion method and a data model conversion apparatus for converting the AutomationML data model into an OPC UA information model.

The most important feature of the future smart factory is the adaptability of the production system and the corresponding IT system. In other words, a smart factory must have the ability to continuously optimize production processes, change production facilities, and transform production into various products. However, in order to achieve the above goal, continuous reconfiguration of not only production machinery and equipment, but also related software is required. However, in the current production environment, different systems are used for each plant and further for each process line, and different data formats and data transmission protocols are used for each system, which is a big obstacle to the flexible change of the entire system. Therefore, technologies such as AutomationML and OPC UA standards have recently been proposed to increase interoperability and enable connection between various production systems, and furthermore, integration between the two standards is attracting great attention.

AutomationML is a standard (IEC 62714) proposed to increase the efficiency of information transfer and improve interoperability by consistently exchanging data in the production system engineering stage. The engineering stage of a production system is largely composed of factory design, construction, commissioning, and maintenance, and the tools used in each stage (for example, solidworks, excel, AutoCAD, etc.) and data formats are very diverse. However, there has not been a common data model that supports consistent data exchange between different engineering stages. AutomationML is an open data standard format designed to consistently exchange heterogeneous data generated in various engineering stages, and defines the syntax and meaning of data based on XML.

OPC UA enables horizontal information transfer between different industrial networks or equipments of different suppliers, and communicates with various objects and services inside and outside the factory through information transfer in a vertical structure from the field level to the enterprise level. It is a communication technology standard (IEC 62541) that enables compatibility.

In addition, as the number of cases in which the two standards are integrated and utilized rapidly increases, the OPC Foundation and the AutomationML eV group created a joint working group to express the AutomationML data model as an OPC UA information model. AutomationML” was released. This is a criterion for enabling mutual compatibility between the two standard data models based on the similarity of the information models defined by AutomationML and OPC UA.

However, the problem to be solved here is that in order to configure the OPC UA server, the AutomationML data model must be converted to the OPC UA information model. In the past, because the data model of AutomationML was manually analyzed and converted into an information model according to the conversion methodology suggested in the standard document of “OPC Unified Architecture Information Model for AutomationML”, errors in the conversion process are easy to occur and the information The larger the amount, the more time and effort was required for the conversion work. In addition, as the types of data described by AutomationML increase through continuous version upgrades, the manual conversion method has reached its limit.

The technical problem to be solved by the present invention is to provide a data model conversion method and a data model conversion apparatus for converting an AutomationML data model describing various information of a production system into an OPC UA information model.

In order to solve the above technical problem, a data model conversion method according to an embodiment of the present invention receives an AutomationML file created according to an AutomationML model, and parses the AutomationML element and data on the AutomationML element from the received AutomationML file. Creating a data structure; Converting the AutomationML element into an OPC UA node using a mapping rule for mapping an AutomationML element to an OPC UA node based on the generated data structure; And generating an OPC UA file according to the OPC UA model by using the converted OPC UA node.

In addition, the step of generating a data structure by parsing the AutomationML element and the data on the AutomationML element from the received AutomationML file may include reading a schema version of the received AutomationML file; Reading a schema file corresponding to the read schema version from a storage unit or receiving a schema file corresponding to the read schema version from outside; And parsing the AutomationML element and data on the AutomationML element from the received AutomationML file using the schema file read from the storage unit or the received schema file.

In addition, the step of converting the AutomationML element to an OPC UA node may include generating an OPC UA node tree corresponding to the element tree structure of the AutomationML file.

In addition, generating the OPC UA file may include generating a data structure according to an OPC UA model based on a root node among the generated OPC UA node trees; And generating an XML-based OPC UA file by using the data structure according to the generated OPC UA model.

In addition, the step of converting the AutomationML element to an OPC UA node may include mapping the AutomationML element to a UAObject, UAObjectType, UAVariable, or other node; And generating an OPC UA node tree according to the relationship between the mapped AutomationML elements.

In addition, the other node may be a node that refers to an AutomationML element, and may be a node that is mapped when there is no UA node type mapped to the AutomationML element.

In order to solve the above technical problem, a data model conversion apparatus according to an embodiment of the present invention includes at least one memory and at least one processor, and the processor receives an AutomationML file created according to the AutomationML model, and the received A reading unit for generating a data structure by parsing the AutomationML element and data on the AutomationML element from the AutomationML file; A conversion unit for converting the AutomationML element into an OPC UA node using a mapping rule for mapping an AutomationML element to an OPC UA node based on the generated data structure; And a writing unit for generating an OPC UA file according to the OPC UA model by using the converted OPC UA node.

In addition, the reading unit reads the schema version of the received AutomationML file, and reads the schema file corresponding to the read schema version from the storage unit, or a schema file corresponding to the schema version read from the outside through the communication unit. And parsing the AutomationML element and data for the AutomationML element from the received AutomationML file using the schema file read from the storage unit or the schema file received through the communication unit.

In addition, the conversion unit may generate an OPC UA node tree corresponding to the element tree structure of the AutomationML file.

In addition, the conversion unit generates a data structure according to the OPC UA model based on a root node of the generated OPC UA node tree, and generates an XML-based OPC UA file using a data structure according to the generated OPC UA model. Can be generated.

In addition, the conversion unit may map the AutomationML element to a UAObject, UAObjectType, UAVariable, or other node, and generate an OPC UA node tree according to the relationship between the mapped AutomationML elements.

In addition, the other node may be a node that refers to an AutomationML element, and may be a node that is mapped when there is no UA node type mapped to the AutomationML element.

According to embodiments of the present invention, it is possible to automatically convert the AutomationML data model to the OPC UA information model without loss or error of information.

In addition, if you use the converted OPC UA information model, you can easily create an OPC UA server through tools or methods provided by most OPC UA SDKs, and connect with production systems and transmit data through the created OPC UA server. I can.

In addition, by converting the AutomationML schema to create a data model data structure, it is possible to easily respond to revision or version upgrade of the AutomationML standard.

In addition, it is possible to integrate heterogeneous data formats and protocols used by production-related OT and IT systems based on OPC UA standards and improve interoperability.

1 is a block diagram of an apparatus for converting a data model according to an embodiment of the present invention.
2 is a block diagram of an apparatus for converting a data model according to another embodiment of the present invention.
3 to 7 are diagrams for explaining a process of converting a data model in a data model conversion apparatus according to an embodiment of the present invention.
8 is a flowchart of a data model conversion method according to an embodiment of the present invention.
9 to 12 are flowcharts of a data model conversion method according to another embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

However, the technical idea of the present invention is not limited to some embodiments to be described, but may be implemented in various different forms, and within the scope of the technical idea of the present invention, one or more of the constituent elements may be selectively selected between the embodiments. It can be used by combining or replacing with

In addition, terms (including technical and scientific terms) used in the embodiments of the present invention are generally understood by those of ordinary skill in the art, unless explicitly defined and described. It can be interpreted as a meaning, and terms generally used, such as terms defined in a dictionary, may be interpreted in consideration of the meaning in the context of the related technology.

In addition, terms used in the embodiments of the present invention are for describing the embodiments and are not intended to limit the present invention.

In the present specification, the singular form may also include the plural form unless specifically stated in the phrase, and when described as "at least one (or more than one) of A and (and) B and C", it is combined with A, B, and C. It may contain one or more of all possible combinations.

In addition, in describing the constituent elements of the exemplary embodiment of the present invention, terms such as first, second, A, B, (a), (b) may be used. These terms are only for distinguishing the constituent element from other constituent elements, and are not limited to the nature, order, or order of the constituent element by the term.

And, when a component is described as being'connected','coupled', or'connected' to another component, the component is directly'connected','coupled', or'connected' to the other component. In addition to the case, it may include a case in which the component is'connected','coupled', or'connected' due to another component between the component and the other component.

In addition, when described as being formed or disposed in the "top (top)" or "bottom (bottom)" of each component, "top (top)" or "bottom (bottom)" means that the two components are directly It includes not only the case of contact, but also the case where one or more other components are formed or disposed between the two components. In addition, when expressed as "upper (upper)" or "lower (lower)", the meaning of not only an upward direction but also a downward direction based on one component may be included.

1 is a block diagram of an apparatus for converting a data model according to an embodiment of the present invention. The data model conversion apparatus 100 according to an embodiment of the present invention includes at least one memory and at least one processor, and the processor includes a read unit 110, a conversion unit 120, and a write unit 130. do. In addition, as shown in FIG. 2, a storage unit 140 or a communication unit 150 may be further included. The read unit 110, the conversion unit 120, and the write unit 130 may be included in one processor, or one or more may be included in another processor.

The reading unit 110 receives the AutomationML file created according to the AutomationML (AML) model, and generates a data structure by parsing the AutomationML element and data on the AutomationML element from the received AutomationML file.

More specifically, the reader 110 receives the AutomationML file created according to the AutomationML model. After receiving the AutomationML file, the AutomationML element and data about the AutomationML element are parsed from the AutomationML file before conversion to the OPC UA model. The parsed data is saved by creating a data structure.

AutomationML expresses the data model based on the Computer Aided Engineering Exchange (CAEX) class model defined in the IEC 62424 standard.

Here, CAEX is a data format that stores hierarchical object information, such as a hierarchical structure of a factory. At a certain level of abstraction, factories are made up of modules or components connected to each other, and CAEX allows the module or component to be stored through objects. Object-oriented concepts such as encapsulation, classes, class libraries, instances, instance hierarchies, inheritance, relationships, properties, and interfaces are explicitly supported. CAEX is based on XML and is defined as an XML schema (xsd file). The original intent of CAEX development is for the common and established data exchange between process engineering tools and process control engineering tools, but CAEX can be applied to any type of static object information. For example, it can be applied to factory topology, document topology, product topology, petri net, etc.

AutomationML is largely divided into 4 areas as shown in FIG. 3 to define elements suitable for each area.

The Interface Class Library 340 is a part that defines various interface classes for connecting with internal and external components such as a port or an external data connector.

The Role Class Library 330 is a part defining role classes to be used to give a component the same meaning as Group, Resource, Product, and Process.

The System Unit Library 320 may define a System Unit Class (SUC) including characteristics of equipment or objects, and the corresponding class may connect roles and interfaces with reference to the previously defined Role Class and Interface Class.

In InstanceHierarchy (IH, 310), you can define an internal element (IE) instance based on SUC, assign roles and interfaces by referring to Role Class and Interface Class, or define connection relationships between instances using Internal Link. can do. Each class element can refer to external data using an external interface, and can have attribute values through Attribute.

OPC UA to convert AutomationML files is an XML format standard (IEC 62541-5) that describes the set of nodes to be managed by the OPC UA server. In the OPC UA node model, information such as ID, name, and description for each node 410 can be described as an Attribute 411, as shown in FIG. 4, and the type of node or the relationship between nodes with other nodes 420, etc. Has a flexible and extensible structure that can be added as Reference (412).

The reading unit 110 parses the AutomationML file and generates a data structure of the elements to which the transformation is applied and what data the elements have in order to convert into OPC UA.

The reading unit 110 uses a schema file in parsing the AutomationML data model. Here, the schema file is a file for the structure and conditions of the data model, and it is a file that generally defines the objects, properties, relationships, and constraints of data values when manipulating the data. Schema files refer to the structural characteristics of data and can be defined by instances. A schema file is a set of rules that must be followed in order for the file to be considered valid.

Schema may contain element declarations and attribute declarations.

Element declaration and element properties are defined. Contains the element name and target namespace. The type of an element is an important attribute, and it limits what attributes and children an element can have. The type of element can vary depending on the value of its characteristic. Elements can belong to a substitution group. If element E belongs to element H's substitution group, E can appear anywhere the schema allows H. Elements can have integrity constraints. Element declarations can be global or local. Thus, you can use the same name to refer to elements that are not related to each other in different parts of the instance document.

The property declaration defines the property of the property. Again, include the attribute name and target namespace. The type of attribute limits the values that the attribute can have. The default value can be specified in the property declaration or the value can be fixed.

Schema can be divided into external schema, conceptual schema, and internal schema. The external schema can be expressed as a sub-schema or a user view, and the external schema is the definition of the logical structure of the database that the user or application programmer needs from the standpoint of each individual. External schemas can be viewed as a logical part of the entire database, so they are also referred to as sub schemas. Several external schemas can exist in one database system, and multiple applications or users can share one external schema. It allows you to define different views for the same database. General users can easily use the DB by using a query language (SQL), and application programmers can access the DB by using languages such as COBOL and C.

The conceptual schema corresponds to the overall view, and the conceptual schema is the overall logical structure of the database, and there is only one database for the entire organization that aggregates the data required by all applications or users. The conceptual schema represents the relationships or constraints between entities and defines the specification of database access rights, security and integrity rules. It represents the type of data stored in the database file, and simply schema means a conceptual schema. It defines a database from the perspective of an organization or organization. It is configured by the database administrator (DBA).

The internal schema can be expressed as a storage schema. The internal schema is a database structure viewed from the point of view of a physical storage device, and is a layer closely related to the physical storage device. The internal schema defines the physical structure of the records to be actually stored in the database, and indicates how the stored data items are expressed, and the physical order of the internal records. It is a schema from the perspective of a system programmer or system designer.

The reading unit 110 generates a data structure by parsing the AutomationML file using XSD (XML Schema Definition), which is a CAEX schema file.

At this time, the reading unit 110 reads the schema version of the received AutomationML file, and reads the schema file corresponding to the read schema version from the storage unit 140, or reads the schema file from the outside through the communication unit 150 Receiving a schema file corresponding to the schema version, and using the schema file read from the storage unit 140 or the schema file received through the communication unit 150 to the AutomationML element and the AutomationML element from the received AutomationML file You can parse the data for it.

To parse an AutomationML file using a schema file, a schema file corresponding to the schema version of the AutomationML file must be used. If the schema versions are different, the rules may be different, making accurate parsing difficult.

Therefore, the reading unit 110 first reads the schema version of the AutomationML file to be parsed. When a schema file corresponding to the read schema version is stored in the storage unit 140, the schema file may be read from the storage unit 140 and used. However, when the schema file is not stored in the storage unit 140, the schema file corresponding to the read schema version is received from the outside through the communication unit 150 and used. Even in an initial state in which the schema file stored in the storage unit 140 does not exist, the schema file may be received from the outside through the communication unit 150. The schema file may be a schema file provided by the AutomationML site. The received schema file may be stored in the storage unit 140. When the schema file is updated, the communication unit 150 may receive the updated schema file and store it in the storage unit 140. Through this, even when the version of the AutomationML model is updated, only the conversion rule is additionally developed, enabling a quick response.

After receiving the schema file corresponding to the schema version of the AutomationML file to be parsed through the storage unit 140 or the communication unit 150, the AutomationML element and the AutomationML element are retrieved from the received AutomationML file using the corresponding schema file. Parse the data. The parsed elements and data are created and stored in a data structure. In this case, the generated data structure may be stored in the storage unit 140.

The process of generating a data structure by parsing the AutomationML file in the reading unit 110 may be performed as shown in FIG. 5. The reading unit 110 receives the AutomationML file 510, and the AutomationML Library Manager 520 searches the External Reference elements defined in the AutomationML file as shown in the example below to read the external AutomationML data model recorded in another AutomationML file, and You can create a data structure for reference through the same process.

<ExternalReference Path="Libs/RoleClass Libraries/AutomationMLBaseRoleClassLib.AutomationML" Alias="BaseRoleClassLib"/>

<ExternalReference Path="Libs/InterfaceClass Libraries/AutomationMLInterfaceClassLib.AutomationML" Alias="BaseInterfaceClassLib"/>

The conversion unit 120 converts the AutomationML element into an OPC UA node using a mapping rule for mapping an AutomationML element to an OPC UA node based on the generated data structure.

More specifically, the conversion unit 120 sequentially searches the data structure generated by the reading unit 110, and reconstructs the AutomationML element into an OPC UA node. At this time, since the AutomationML element and the OPC UA node are not in a one-to-one mapping relationship, the data of the AutomationML element is used to reconstruct the data into an OPC UA node with the same meaning. Mapping rules that map AutomationML elements to OPC UA nodes can be saved as a mapping table. Mapping rules can be updated if the AutomationML schema file or OPC UA version is updated, or if the rules are different.

The conversion unit 120 sequentially searches the data structure generated by the reading unit 110, and derives a UA node type, a UA reference type, and a UA reference node corresponding to each AutomationML element.

The UA node type is divided according to what kind of node the AutomationML element is among UA nodes, and the UA node type can be divided into UAObject, UAObjectType, UAVariable, and the like, as shown in FIG. 6. At this time, the conversion unit 120 maps the AutomationML element to UAObject, UAObjectType, UAVariable, or other nodes. Here, the other node may be a node that refers to an AutomationML element, and may be a node that is mapped when there is no UA node type mapped to the AutomationML element. Since the types of the AutomationML element and the UA node type do not exactly match, if the UA node type corresponding to the AutomationML element does not exist, the AutomationML element can be mapped to other nodes. As shown in FIG. 6, since a corresponding UA node type does not exist for SupportedRoleClass or RoleRequirement among AutomationML elements, the corresponding UA node type may be left blank or may be mapped to other node types.

The UA reference type is divided according to which node refers to what meaning when there is a node referenced by the corresponding node, and the UA reference type can be divided into HasTypeDefinition, HasSubType, etc. As described above, if a corresponding UA node type does not exist among AutomationML elements, but there is a reference, as shown in FIG. 6, SupportedRoleClass maps 1:HasAutomationMLSupportedPoleClass as UA reference type, and RoleRequirement maps 1:HasAutomationMLRoleRequirement. I can.

The UA reference node maps the reference node if there is a node referenced by the node. As shown in FIG. 6, it may be mapped to 1:CAEXFileType, FolderType, PropertyType, *RefSystemUnitClassPath, *RefRoleClassPath, *RefBaseRoleClassPath, and the like.

The conversion unit 120 may generate an OPC UA node tree corresponding to the element tree structure of the AutomationML file. OPC UA node tree can be created according to the relationship of the mapped AutomationML elements.

Referring to FIG. 6, InterfaceClass, RoleClass, and SystemUnitClass elements defined under InterfaceClassLib, RoleClassLib, and SystemUnitClassLib elements are mapped to UAObjectType nodes to be referenced by other nodes. Nodes such as the InternalElement element under the InstanceHierarchy element are mapped to UAObject nodes, and when SupportedRoleClass and RoleRequirements elements are included, refer to the UAObjectType nodes described above as Reference. The Attribute element is mapped to a UAVariable node, and the parent element that owns the element is added as a child of the mapped node. Finally, the converted OPC UA server has the same node tree as the element tree structure described in InstanceHierarchy as shown in FIG. 7.

The OPC UA node tree can be created by configuring each node into a node tree using each mapped node and reference relationships. Through this, a data structure according to the OPC UA model can be created based on the root node of the OPC UA node tree. As shown in FIG. 7, the OPC UA node tree structure may be generated by arranging UA nodes in a tree structure so as to correspond to the element tree structure described in InstanceHierarchy of the AutomationML file.

Create a node tree with the node mapped with AutomationML's InstanceHierarchy (IH) as the root node. For example, as shown in FIG. 7, the IH may have'Conveyor' and'MyRobot' as IE, the SUC (SystemUnitClass) of'IE:Conveyor' is'Conveyor1', and RC (RoleClass) may be'beltConveyor'. . The attribute of'IE:MyRobot' is'Number0' and may include'Servo Motor' as IE. RC (RoleClass) of'IE: Servo Motor' may be'Actuator'.

OPA UA node tree is created to correspond to this AutomationML tree structure.

For example, as shown in FIG. 7, objects 720 and 730 that are child relationships of the object 710 are connected through HasComponent based on the object 710 which is the root node corresponding to the AutomationML IH. Here, Objects 720 and 730 are UA nodes to which'IE:Conveyor' and'IE:MyRobot' of AutomationML are mapped. ObjectType 740 of Object 720 is a UA node to which SUC and RC of'IE:Conveyor' are mapped, and is connected through HasTypeDefinition.

Variable 750 and Object 760 connected to Object 730 are UA nodes to which Attribue and IE: Servo Motor of'IE:MyRobot' are mapped, respectively, and are connected through HasComponent. ObjectType 770 is a UA node to which RC of'IE:Servo Motor' is mapped and is connected through HasTypeDefinition.

As described above, UA nodes to which AutomationML elements are mapped are created in a node tree structure and stored as a data structure. The generated data structure may be stored in the storage unit 140.

The writing unit 130 generates an OPC UA file according to the OPC UA model by using the converted OPC UA node.

More specifically, the conversion unit 120 generates an OPC UA file according to the OPC UA model by using the node tree structure generated by mapping AutomationML elements to OPC UA nodes. The writing unit 130 may generate an XML-based OPC UA file using a data structure according to the generated OPC UA model.

The writing unit 130 creates a basic XML document structure that the OPC UA information model should have by using the UANodeSet element as a root, and adds a namespace for the OPC UA information model and a namespace for the AutomationML data model as follows.

<NamespaceUris>

<Uri>http://opcfoundation.org/UA/AutomationML/</Uri>

<Uri>http://smic.kr/Topology.xml</Uri>

</NamespaceUris>

Then, based on the BrowseName and NodeId of various DataTypes used during the conversion process, Alias elements are created and added. Finally, add nodes such as UAObject, UAVariable, and UAObjectType converted from the AutomationML data model, and save them as a file with the name specified by the user.

In this way, after the AutimationML file is generated as an OPC UA file, an OPC UA server can be built together with the OPC UA file to be integrated. Through this, integrated management of information according to AutomationML file and information according to OPC UA file becomes possible. In this way, when AutomationML data model is connected through OPC UA communication technology, static data such as production plan, structure and topology, and connection information are imported from AutomationML (*AutomationML), and dynamic data such as operation data and process are obtained from OPC UA. As a result, flexible changes to the entire production system described above are possible and system management is facilitated. For example, if a change occurs in the factory production system, you can use AutomationML to modify the properties and functions of the components that make up the factory, and convert it to the OPC UA information model for the control system. It can be reflected in the UA server, and changed properties or functions can be applied quickly.

8 is a flowchart of a data model conversion method according to an embodiment of the present invention, and FIGS. 9 to 12 are flow charts of a data model conversion method according to another embodiment of the present invention. A detailed description of each step of FIGS. 8 to 12 corresponds to a detailed description of the data model conversion apparatus of FIGS. 1 to 7, and redundant descriptions will be omitted below.

An image processing method according to an embodiment of the present invention relates to a method for converting a data model in a data model conversion apparatus including one or more processors or another apparatus including a processor for converting data models. The processor can process a program that converts an AutomationML file to an OPC UA file, and a program that converts an AutomationML file to an OPC UA file may be stored in memory.

The data model conversion method according to an embodiment of the present invention receives an AutomationML file created according to an AutomationML (hereinafter, AML) model in step S11, and parses the AutomationML element and the data for the AutomationML element from the received AutomationML file. Create a data structure.

In this case, step S11 may be performed through steps S21 to S24. In step S21, the schema version of the received AutomationML file is read, and in step S22, the schema file corresponding to the read schema version is read from the storage unit, or a schema file corresponding to the read schema version is received from the outside. In step S23, the AutomationML element and data for the AutomationML element may be parsed from the received AutomationML file using the schema file read from the storage unit or the received schema file. In this way, a data structure composed of parsed information can be created.

After step S11, based on the data structure created in step S12, the AutomationML element is converted to an OPC UA node using a mapping rule for mapping an AutomationML element to an OPC UA node, and the converted OPC UA node in step S13 Create an OPC UA file according to the OPC UA model by using.

After step S12, the step of generating the OPC UA node tree corresponding to the element tree structure of the AutomationML file in step S31 may be further included.

After step S31, the data structure according to the OPC UA model is created based on the root node among the generated OPC UA node tree in step S41, and the data structure according to the generated OPC UA model is used in step S42. OPC UA files can be created.

Step S12 may be performed through steps S51 and S52. In step S51, the AutomationML element may be mapped to UAObject, UAObjectType, UAVariable, or other nodes, and in step S52, an OPC UA node tree may be generated according to the relationship between the mapped AutomationML elements. Here, the other node may be a node that refers to an AutomationML element, and may be a node that is mapped when there is no UA node type mapped to the AutomationML element.

Meanwhile, the embodiments of the present invention can be implemented as computer-readable codes on a computer-readable recording medium. The computer-readable recording medium includes all types of recording devices that store data that can be read by a computer system.

Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tapes, floppy disks, and optical data storage devices. In addition, computer-readable recording media are distributed across networked computer systems. , Computer-readable code can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers in the technical field to which the present invention belongs.

As described above, in the present invention, specific matters such as specific components, etc., and limited embodiments and drawings have been described, but this is provided only to help a more general understanding of the present invention, and the present invention is not limited to the above embodiments. , If a person of ordinary skill in the field to which the present invention belongs, various modifications and variations are possible from these descriptions.

Accordingly, the spirit of the present invention is limited to the described embodiments and should not be defined, and all things that are equivalent or equivalent to the claims as well as the claims to be described later fall within the scope of the inventive concept. .

100: data model conversion device
110: reading section
120: conversion unit
130: writing unit
140: storage unit
150: communication department

Claims (12)

Receiving an AutomationML file created according to the AutomationML model, and generating a data structure by parsing the AutomationML element and data on the AutomationML element from the received AutomationML file;
Converting the AutomationML element into an OPC UA node using a mapping rule for mapping an AutomationML element to an OPC UA node based on the generated data structure; And
And generating an OPC UA file according to an OPC UA model by using the converted OPC UA node. The method of claim 1,
Parsing the AutomationML element and data on the AutomationML element from the received AutomationML file to create a data structure,
Reading the schema version of the received AutomationML file;
Reading a schema file corresponding to the read schema version from a storage unit or receiving a schema file corresponding to the read schema version from outside; And
And parsing data for the AutomationML element and the AutomationML element from the received AutomationML file using the schema file read from the storage unit or the received schema file. The method of claim 1,
Converting the AutomationML element to an OPC UA node,
And generating an OPC UA node tree corresponding to the element tree structure of the AutomationML file. The method of claim 3,
The step of generating the OPC UA file,
Generating a data structure according to an OPC UA model based on a root node of the generated OPC UA node tree; And
And generating an XML-based OPC UA file using the data structure according to the generated OPC UA model. The method of claim 1,
Converting the AutomationML element to an OPC UA node,
Mapping the AutomationML element to a UAObject, UAObjectType, UAVariable, or other node; And
And generating an OPC UA node tree according to the relationship of the mapped AutomationML elements. The method of claim 5,
The other node,
The corresponding element is a node that refers to the AutomationML element, and is a node that is mapped when a UA node type mapped to the AutomationML element does not exist. One or more memories and one or more processors,
The processor,
A reading unit that receives the AutomationML file created according to the AutomationML model, and generates a data structure by parsing the AutomationML element and data on the AutomationML element from the received AutomationML file;
A conversion unit for converting the AutomationML element into an OPC UA node using a mapping rule for mapping AutomationML elements to OPC UA nodes based on the generated data structure; And
Data model conversion device comprising a writing unit for generating an OPC UA file according to the OPC UA model by using the converted OPC UA node. The method of claim 7,
The reading unit,
Read the schema version of the AutomationML file received above,
The schema file corresponding to the read schema version is read from a storage unit or a schema file corresponding to the read schema version is received from the outside through a communication unit,
And parsing the AutomationML element and data on the AutomationML element from the received AutomationML file using a schema file read from the storage unit or a schema file received through the communication unit. The method of claim 7,
The conversion unit,
A data model conversion apparatus, characterized in that for generating an OPC UA node tree corresponding to the element tree structure of the AutomationML file. The method of claim 9,
The conversion unit,
A data structure according to the OPC UA model is created based on the root node of the generated OPC UA node tree,
The writing unit,
A data model conversion device, characterized in that generating an XML-based OPC UA file by using the data structure according to the generated OPC UA model. The method of claim 7,
The conversion unit,
Map the AutomationML element to UAObject, UAObjectType, UAVariable, or other nodes,
A data model conversion device, characterized in that generating an OPC UA node tree according to the relationship between the mapped AutomationML elements. The method of claim 11,
The other node,
The corresponding element is a node that refers to the AutomationML element, and is a node that is mapped when a UA node type mapped to the AutomationML element does not exist.

Images