KR20210066595A - Edge Device for Interworking with Heterogeneous Legacy Protocols in Smart Factory - Google Patents

Abstract

Provided is a smart factory edge device for interworking with a heterogeneous legacy protocol. By the edge device receiving the device information model and data information model from an upper operating system, a device interworking method according to an embodiment of the present invention comprises collecting data from a device based on the received device information model and data information model. Therefore, through a protocol conversion standard information model specification of various industrial IoT sensors, equipment, and production facility devices installed in a smart factory, the present invention is capable of integrating and managing different protocol-based data generated by various devices in the smart factory.

Description

Edge Device for Interworking with Heterogeneous Legacy Protocols in Smart Factory

The present invention relates to a protocol interworking technology, and more particularly, by defining a device and data standard information model of various industrial IoT sensors, equipment and production facility devices installed in a smart factory, mutually generated by various devices of a smart factory in the future It relates to a method for integrated management of data based on different protocols.

A smart factory has several manufacturing facilities and machines, and each machine uses several sensors/actuators, but these equipment/sensors/actuators use various protocols that are not unified, so it is difficult to link higher systems with production equipment. Many problems are being caused.

In addition, in order to build a smart factory, a network between the equipment and the upper system must be configured. However, when configuring the network of production equipment only by wire, space and facility scalability are limited, and some production equipment is outdated and does not support network connection.

On the other hand, in order to solve the problem of dependency (dependence) on the process management system or application manufacturer and to increase process management efficiency, the application and process management system built in the factory is highly dependent on the application supplier when changing or upgrading, so it is necessary to fully accept the factory side There are many restrictions on In particular, when collecting data from equipment/sensors/actuators, client companies such as MES/FDC are highly dependent on each individual data collection company's solution due to the lack of a standardized method for data collection.

The present invention has been devised to solve the above problems, and an object of the present invention is to use a legacy protocol conversion standard information model necessary to integrate and collect industrial IoT sensors, equipment and production facility data installed in a smart factory, It is to provide a smart factory edge device that performs interworking with heterogeneous legacy protocols.

According to an embodiment of the present invention for achieving the above object, a device interworking method includes: a first receiving step of receiving, by an edge device, a device information model from an upper operating system; a second receiving step in which the edge device receives the data information model from the upper operating system; and collecting, by the edge device, data from the device based on the received device information model and data information model.

The device information model may include information required for device connection, device property information, and property information required for device data collection.

The device information model may include a device ID, a protocol type, a connection model, a data model list, a connection state, a status, and an error message.

Detailed information of the connection model can be defined according to the protocol used by the device.

The data information model may include at least one of data ID, data format, number of data arrays, data value, data minimum value, data maximum value, data default value, data unit, sampling time, and data variable type.

Unique attribute information for each data variable type of the data information model may be defined according to a protocol used by a device.

The first receiving step and the second receiving step may be performed when the device is newly connected to the edge device.

On the other hand, according to another embodiment of the present invention, a data collection system, a device installed in a smart factory; and an edge device that receives the device information model and the data information model from the upper operating system, and collects data from the device based on the received device information model and data information model.

As described above, according to embodiments of the present invention, through the protocol conversion standard information model specification of various industrial IoT sensors, equipment, and production facility devices installed in the smart factory, different protocol-based Data can be integrated and managed.

In addition, according to embodiments of the present invention, it is possible to support the establishment of an infrastructure to enable manufacturing and facility data collection for a smart factory without changing existing facilities.

1 is a system to which the present invention is applicable;
2 is a device and data standard information model class diagram;
3 is a device standard information model class diagram;
4 is a connection model class diagram;
5 is a communication protocol classification of Modbus,
6 is a list and description of protocol parameters of SECS-I.
7 shows the protocol parameters of HSMS;
8 is a data standard information model class diagram;
9 is a format of a Modbus data request message;
10 is an example of the Modbus Function field type;
11 shows the format and field information of a SECS-I data request message;
12 is a Stream of SECS-I, a function code type (example),
13 shows the format and field information of an HSMS data request message;
14 is an MQTT operation procedure;
15 is an OPC UA structure;
16 shows the format and field information of a CoAP data request message;

Hereinafter, the present invention will be described in more detail with reference to the drawings.

In an embodiment of the present invention, a device standard information model including connection and basic attribute information of a device to which various legacy protocols are applied is defined, and a data standard information model including information required for data collection generated by the device is defined.

Legacy protocols include PLC protocols (Modbus, OMROM PLC, MELSEC PLC, LSIS PLC, Siemens PLC, etc.) mainly used in manufacturing plants, HSMS, SECS, and existing IoT protocols MQTT and CoAP used in semiconductor processes.

In an embodiment of the present invention, a DeviceModel object specification representing device information is defined to express them. In addition, it defines CommonTag and Tag object standards indicating information of tags that generate data in devices. CommonTag object includes common information of data generated by tag, and Tag object additionally includes not only common data information generated by tag but also unique data information for each device.

In addition, an embodiment of the present invention proposes an edge device that collects and transmits data of industrial IoT sensors, equipment, and production facilities to a higher level system using the suggested standard information model.

Through the information model provided in the embodiment of the present invention, various client applications such as MES/FDC on the host side can acquire/use data in a standardized manner regardless of the protocol of the equipment/sensor/actuator.

Furthermore, through an open API-based information provision method, various client applications such as MES/FDC can acquire sensor and device data in a standardized way, making it easier to use for monitoring and analysis applications.

1 is a block diagram of a system to which the present invention is applicable. The system to which the present invention is applicable is configured to include an industrial IoT sensor 110 , equipment and production facilities 120 , an edge device 130 , and an upper system 140 , as shown.

The industrial IoT sensor 110 refers to various IoT sensors such as vibration, temperature, and humidity, and communicates based on industrial IoT standard protocols (MQTT, CoAP, OPC-UA, etc.).

Equipment and production facilities 120 refer to robots, conveyors, AGVs, PLCs, CNCs, etc., and industrial standard (SECS-I-1, HSMS, MODBUS, etc.) and non-standard protocols (Mitsubishi PLC, Omron PLC, Siemens PLC, LSIS PLC) ) to communicate based on

The edge device 130 acquires data by interworking with the industrial IoT sensor 110 and equipment and production facilities 120 , and transmits the acquired data to the higher-level system 140 in need.

When a new device is connected, the edge device 130 receives the device and data standard information model from the upper operating system and installs/executes a communication module based on this to communicate with the device in a standardized manner without being limited to a specific device and protocol. can do.

The device standard information model includes information necessary for device connection and basic and unique attribute information of the device, and includes basic and unique attribute information required for device data collection. A class diagram representing a relationship between a device and a data standard information model may be defined as shown in FIG. 2 .

1. Device standard information model

The device standard information model includes device connection information and basic and unique property information. When the edge device 130 is first connected to the upper operating system by the upper operating system or when a new device is connected to the edge device 130 is sent to 130.

The edge device 130 may dynamically install a communication module based on the device standard information model and interwork with the device. A class diagram representing a relationship between the device standard information model and related models may be defined as shown in FIG. 3 .

1.2 Common property information of device model

The common attribute information of the device model can be determined as follows.

Here, the device model may be connected to one connection model and multiple data models. That is, the device may be connected to the edge device 130 through one connection and generate various types of data.

1.3 Property information of the Connection model

The connection model includes common attribute information and unique attribute information for each connection type, and a class diagram indicating a relationship between related models may be defined as shown in FIG. 4 .

1.3.1 Common property information of Connection model

The common attribute information of the connection model can be defined as follows.

Here, the connection type supports TCP, UDP, and serial communication used in major industrial communication protocols, and the serial communication includes RS232/485.

1.3.2 Unique property information for each connection type of the Connection model

Unique property information required for connection by connection type of connection model can be defined as follows.

TCP connection property information

UDP connection property information

Serial connection property information

1.4 Unique property information for each protocol type of device model

Unique property information for each protocol type of the device model can be defined as follows. Here, the protocol type includes 6 major industrial protocols (Modbus, SECS-I, HSMS, MQTT, OPC UA, CoAP), and it is a fixed value among the information required for device connection and communication, or it is predefined by the related model Information other than information can be defined as unique attribute information for each protocol type.

1.4.1 Modbus

Modbus communication protocol is divided into RTU and ASCII protocol as shown in FIG. RTU uses 0x00~0xFF characters by separating frames with spaces, so communication time is shortened. ASCII uses special starting characters (colon ':') and ending characters (CR, LF) to separate frames, so communication time is shorter than in RTU mode. This takes more but is human-readable. Based on this information, unique property information of Modbus device can be defined as follows.

1.4.2 SECS-I

The protocol parameters of SECS-I and general values, ranges, and precision of parameters are shown in FIG. 5 . Here, the baud rate indicating the serial communication speed can be referred to in the baudrate attribute of the serial connection model, so it can be omitted. Based on this information, unique attribute information of the SECS-I device can be defined as follows.

Attribute information of SECS-I device

1.4.3 HSMS

HSMS is a protocol created to replace sesc-I and uses TCP/IP protocol instead of serial communication protocol. The protocol parameters of the HSMS and general values, ranges, precisions, and field descriptions of parameters can be defined as shown in FIG. 7 .

Here, parameters other than T3, T5, T6, T7, and T8 can be omitted because they can be referred to in the ip, port, and active properties of the TCP/UDP connection model. Based on this information, unique attribute information of the HSMS device can be defined as follows.

1.4.4 MQTT

MQTT requires authentication when secure interworking between a client and an MQTT broker (server), and authentication is performed based on a user name and password. Based on this information, unique attribute information of MQTT device can be defined as follows.

1.4.5 OPC UA

OPC UA also requires authentication when security interworking between the client and server, and authentication is performed based on a user name and password. Based on this information, unique attribute information of the OPC UA device can be defined as follows.

1.4.6 CoAP

CoAP allows interworking between the CoAP server and the client without authentication and does not require additional information for device connection other than the information included in the UDP connection model, so the unique attribute information of the CoAP device is not defined.

2. Data standard information model

The data standard information model indicates basic attribute information of data generated by the device. When the edge device 130 is first connected to the upper operating system by the upper operating system or when a new device is connected to the edge device 130, the edge device 130 ) is sent to

The edge device 130 may create a data request message of the device based on the data standard information model and collect data from the device. A class diagram representing a relationship between the data standard information model and related models may be defined as shown in FIG. 8 .

2.2 About common properties of data models

Common property information of data model can be defined as follows.

2.3 Unique property information for each data variable type of the data model

Property information for each data variable type of the data variable model can be defined as follows. Here, the data variable type includes 6 major industrial protocols (Modbus, SECS-I, HSMS, MQTT, OPC UA, CoAP), and is a fixed value among the information required for data collection or information that can be omitted as it is predefined by a related model The remaining information except for is defined as unique attribute information for each data variable type.

2.3.1 Modbus

The data request message format of Modbus can be defined as shown in FIG. 9 . Among the data request message fields, the Function field indicates the function of the message, and the type of the Function field can be defined as shown in FIG. 10 .

Here, among the defined fields, Start Address Hi, No. The of Registers Hi field can be fixed to 0, and the Error Check and Trailer fields can be defined in the host (edge device), so it can be omitted. Based on this information, the unique property information of Modbus data can be defined as follows.

2.3.2 SECS-I

The data request message format and field information of SECS-I may be defined as shown in FIG. 11 . Here, among the defined fields, Device ID can be referred to in the deviceid attribute of the SECS-I device model, R and W can be fixed to 0 (host->equipment) and 1 (Reply Message), respectively, and block number , system byte can be set in the host (edge device), so it can be omitted. Based on this information, unique attribute information of SECS-I data can be defined as follows.

Types (examples) of stream and function codes constituting messageid can be defined as shown in FIG. 12 .

2.3.3 HSMS

The data request message format and field information of the HSMS can be defined as shown in FIG. 13 . Here, among the defined fields, Ptype can be fixed to 0 (SECS-II message encoding) and Stype can be fixed to 0 (data message), and system byte can be set in the host (edge device), so it can be omitted. Based on this information, unique attribute information of HSMS data can be defined as follows.

2.3.4 MQTT

MQTT is an operation structure in which when a publishing client publishes a specific topic and data, as shown in FIG. 14, a subscribing client subscribing to the topic receives the data through a broker.

MQTT divides QoS into three stages for data reliability. The basic QoS is 0, and the higher the QoS, the higher the data reliability. Based on this information, unique attribute information of MQTT data can be defined as follows.

2.3.5 OPC UA

When performing data communication, OPC UA supports both the server/client structure and the Pub/Sub structure as shown in FIG. 15 . In the case of the server/client structure, the client can receive data from the server by requesting data from the server. In the case of the Pub/Sub structure, data can be received by subscribing to the topic like MQTT, but QoS is not supported. Based on this information, unique attribute information of OPC UA data can be defined as follows.

2.3.6 CoAP

The CoAP data request message format and field information may be defined as shown in FIG. 16 . Here, v can be fixed as 01 (currently fixed version) and code as 01 (method indicating GET), and TKL, Message ID, and Token can all be defined in the host (edge device), so they can be omitted. Based on this information, unique attribute information of CoAP data can be defined as follows.

On the other hand, it goes without saying that the technical idea of the present invention can also be applied to a computer-readable recording medium containing a computer program for performing the functions of the apparatus and method according to the present embodiment. In addition, the technical ideas according to various embodiments of the present invention may be implemented in the form of computer-readable codes recorded on a computer-readable recording medium. The computer-readable recording medium may be any data storage device readable by the computer and capable of storing data. For example, the computer-readable recording medium may be a ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical disk, hard disk drive, or the like. In addition, the computer-readable code or program stored in the computer-readable recording medium may be transmitted through a network connected between computers.

In addition, although preferred embodiments of the present invention have been illustrated and described above, the present invention is not limited to the specific embodiments described above, and the technical field to which the present invention belongs without departing from the gist of the present invention as claimed in the claims In addition, various modifications may be made by those of ordinary skill in the art, and these modifications should not be individually understood from the technical spirit or perspective of the present invention.

110: industrial IoT sensor
120: equipment and production equipment
130: edge device
140: upper system

Claims (8)

a first receiving step of receiving, by the edge device, a device information model from an upper operating system;
a second receiving step in which the edge device receives the data information model from the upper operating system;
The edge device, based on the received device information model and data information model, collecting data from the device; device interworking method comprising: a.
The method according to claim 1,
The device information model is
Device interworking method, characterized in that it includes information required for device connection, device attribute information, and attribute information required for device data collection.
3. The method according to claim 2,
The device information model is
Device ID, protocol type, connection model, data model list, connection status, device interworking method, characterized in that it includes a status and error message.
4. The method according to claim 3,
The details of the connection model are:
Device interworking method, characterized in that it is defined according to the protocol used by the device.
The method according to claim 1,
The data information model is
A device interworking method comprising at least one of data ID, data format, number of data arrays, data value, data minimum value, data maximum value, data default value, data unit, sampling time, and data variable type.
6. The method of claim 5,
The unique property information for each data variable type of the data information model is,
Device interworking method, characterized in that it is defined according to the protocol used by the device.
The method according to claim 1,
The first receiving step and the second receiving step,
A device interworking method, characterized in that it is performed when a device is newly connected to an edge device.
devices installed in smart factories; and
An edge device that receives the device information model and the data information model from the upper operating system, and collects data from the device based on the received device information model and data information model; Data collection system comprising a.

Images