KR20230132143A - OPC UA synergy platform for Industrial IoT - Google Patents

Abstract

Recently, the manufacturing industry is undergoing a revolution with 'smart manufacturing' and 'Industry 4.0', and the number of physical objects that can access network services is increasing due to the development of the Industrial Internet of Things (IIoT). However, important issues such as real-time communication, interoperability, and linking of the Internet and industrial devices have not yet been resolved. These problems arise from the interconnection issues between smart manufacturing systems and non-semantic industrial equipment.
Therefore, in order to solve the interconnection problem and bridge the gap between the Internet and industry, the present invention refers to the standard IoT reference designer document ISO/IEC 30141, which divides the manufacturing system into user, cloud service, sensing control, and device domains. A two-domain integrated architecture was proposed. The architecture according to the present invention was verified by constructing an industrial pick-and-place testbed applicable to manufacturing systems. Therefore, this testbed can serve as a guide for investigating the state-of-the-art in OPC UA PubSub-based protocols in addition to several other types of protocol approaches.

Description

OPC UA synergy platform for Industrial IoT

The present invention relates to integration technology between heterogeneous networks, and more specifically, to an integrated architecture divided into user, cloud service, detection control, and device areas that implements integration between heterogeneous networks through the configuration of the OPC UA synergy platform.

With the development of modern information technology, Internet traffic has increased rapidly. More than 50 billion IP connections are expected by 2025. Therefore, recently, Internet of Things (IoT) architectures based on modern computing models such as Fog or Edge computing have been proposed to reduce process delays and address the limitations of IP resources in the Internet.

However, key issues such as real-time communication, interoperability, and linking of the Internet and industrial devices have not yet been solved.

Recently, the manufacturing industry is undergoing a revolution with 'smart manufacturing' and 'Industry 4.0', and the number of physical objects that can access network services is increasing due to the development of the Industrial Internet of Things (IIoT).

However, a major challenge complicating the active adoption of IIoT in smart manufacturing is the issue of operational technology (OT) and information technology (IT) integration between the shop floor and smart manufacturing systems. This is caused by the problem of interconnection of smart manufacturing systems and non-semantic industrial equipment.

Therefore, to solve these problems, attempts are being made to solve the interconnectivity problem through semantically expressible devices (e.g. OPC UA gateway/connector) in smart manufacturing.

To address the challenges faced by the Internet and industrial networks, research and development efforts are underway on interconnection, and integration of these two networks has been proposed. This proposed integration must take into account two important aspects: reliability over the Internet and immediate response over industrial networks. For example, to block malicious intent on the Internet, traditional firewalls use Deep Packet Inspection (DPI)-based algorithms that inspect packets all the way to the transport layer.

However, this algorithm requires long processing time. Although this long processing time is not critical on the Internet, it can cause problems in systems that require immediate response at critical times, such as safety detection systems. Therefore, security and reliability of message transmission are more important than immediate response to the Internet. Existing Supervisory Control And Data Acquisition (SCADA) firewalls in SCADA systems in industrial networks provide limited security only for the fieldbus protocols of IEC 61158. This is because industrial networks require rapid processing for time-critical missions. Therefore, in stark contrast to the Internet, industrial networks require an immediate response at critical times and face significant challenges such as limited services. To effectively utilize these two types of networks with different characteristics, the concept of interconnection was developed.

Endeley et al. proposed a solution featuring a set of communication primitives, a platform-independent type system, and an intermediate language. An Open Platform Communications Unified Architecture (OPC UA) connector was implemented via the OPC UA information model for communication with Virtual Automation Bus (VAB) gateways and Industry 4.0 applications. They also evaluated the overhead due to integration in terms of round-trip time and message size imposed by metadata for abstraction.

However, although these authors sufficiently introduced the interface between the existing OPC UA server/client model and HTTP technology, they did not consider the OPC UA PubSub model for asynchronous data processing.

Kannoth et al. studied a middleware solution that implements an OPC gateway to ensure interconnection and interoperability and enable effective communication between the OPC UA server/client model and the DDS model. Additionally, using software middleware and Raspberry Pi connected to a private LAN, we tested the performance of the middleware in various scenarios and evaluated its operation by measuring response time and reliability.

Their study also did not use the PubSub model of OPC UA, and processing delay occurred while the OPC UA server exchanged data through the OPC gateway and TCP-based BP (Binary Protocol) and converted it to UDP communication DDS data.

Koziolek et al. proposed a plug-and-produce architecture for the Industrial Internet of Things (IIoT) and implemented it in an open source code-based system. However, the authors only considered industrial aspects for interoperability and ignored IoT protocols and Internet security or reliability.

Gruner et al. proposed a web platform that integrates the Representational State Transfer (REST) architecture to leverage the Internet to solve the problem of interoperability between resource-constrained devices in industrial networks using OPC UA. OPC UA and REST technologies for synchronous data processing have not been considered for industrial networks, nor has the implementation of the OPC UA PubSub interface been demonstrated with middleware for asynchronous data processing.

Luo et al. proposed OPC UA technology and applied the three-layer Industrial Internet Reference Architecture (IIRA) proposed by the Industrial Internet Consortium (IIC) to a smart manufacturing system.

IIRA proposed by IIC has a three-tier structure. The first enterprise layer implements domain-specific applications with interfaces to end users, and the second platform layer receives, processes, and delivers data. The final edge layer uses proximity networks to collect data from edge nodes.

Both architectures have similar structures for applying industrial IoT applications to smart manufacturing systems and utilizing real-time-oriented industrial protocols and OPC UA technology. However, the OPC UA PubSub model for asynchronous data processing was not considered in the study.

Regarding application-level latency analysis using OPC UA technology, some studies have compared IoT protocols other than Unified Architecture Datagram Protocol (UADP)/Advanced Message Queuing Protocol (AMQP) pubserve. These studies provided an overview of the various features of OPC UA technologies, as well as Constrained Application Protocol (CoAP) and Message Queuing Telemetry Transport (MQTT), and compared their performance with benchmarks.

The Open Platform Communication (OPC) Foundation recently defined a new specification (part 14) to extend the Pub-Sub approach to ensure interoperability when applying IoT technology to industrial networks. However, the specific concept of how to connect two different technologies, a brokerless model for industrial protocols (e.g. UADP PubSub) and a broker model for IoT protocols (e.g. AMQP PubSub), is still not established.

This missing concept may be important in solving diverse integrated data in the field of Industry 4.0, a cutting-edge technology currently being studied. Additionally, because the recent OPC UA standard defines IoT communication, there are no cases of using the latest OPC UA technology that combines OPC UA PubSub between the Internet and industrial networks.

Accordingly, the present invention was created in consideration of the above-mentioned situations, and the purpose of the present invention is to propose an integrated architecture divided into user, cloud service, sensing control, and device areas, and to propose an OPC that links server, broker, and brokerless models. It provides the UA synergy platform concept.

Additionally, the purpose of the present invention is to verify the analysis of the interconnection concept by exploring the applicability of the OPC UA synergy platform and the integrated architecture and testbed using it.

To this end, the gateway of the OPC UA synergy platform according to the present invention includes an OPC UA pubserve server that converts the UADP data set received from each device in the device domain into an AMQP data set, and an AMQP data set received from the OPC UA pubserve server. Includes an AMQP broker that transfers data sets to the cloud domain.

Here, the OPC UA pubserve server is characterized by setting the initial configuration through binary protocol (BP).

The integration method between heterogeneous networks according to the present invention includes the steps of, when a user terminal requests settings for initial configuration to a cloud domain, the first cloud server in the cloud domain requests settings for initial configuration to the OPC UA synergy platform, and the OPC The OPC UA server of the UA synergy platform performs settings for initial configuration, the OPC UA server of the OPC UA synergy platform receives a UADP message from each device in the device domain, and the OPC UA synergy platform's An AMQP broker converts the UADP message into an AMQP data set and transmits it to a second cloud server in the cloud domain, and the second cloud server in the cloud domain processes and monitors the AMQP data set and sends the monitoring result to the user terminal. Including the step of transmitting.

Here, the user terminal requests initial configuration settings from the cloud domain through the HTTP protocol, and the first cloud server configures the OPC UA synergy platform through a binary protocol (BP) based on the OPC UA client/server model. It is characterized by requesting settings for initial configuration to the OPC UA server.

In addition, communication between the OPC UA server of the OPC UA synergy platform and the device domain is performed through the OPC UA Pubserve model-based UADP protocol, and communication between the AMQP broker of the OPC UA synergy platform and the second cloud server of the cloud domain This is characterized by being performed through the AMQP protocol based on the OPC UA Pubserve model.

As described above, the present invention can minimize processing delay time by applying the OPC UA PubSub model and using the UDP-based UADP protocol instead of the TCP-based binary protocol when the broker sends and receives messages at the gateway.

The OPC UA Synergy platform according to the present invention plays an important role in integrating two different networks and can ensure interoperability and transfer of significant amounts of data between the two networks. Accordingly, the integrated architecture of the PC UA synergy platform of the present invention can promote the adoption of Industry 4.0 technology.

Additionally, the present invention can guarantee high performance compared to other protocols and provide competitive services for information models through use cases based on pick-and-place scenarios.

Additionally, the present invention can improve system management efficiency by simplifying the complex life cycle of not only general systems but also industrial systems and improving flexibility. Moreover, a comprehensive architecture that integrates the Internet and industrial networks in previously unexplored ways has the effect of achieving interoperability and large number of message transmissions.

Figure 1: OPC UA Synergy Platform Diagram
Figure 2: OPC UA Synergy Platform Diagram
Figure 3: Integrated architecture for Internet and industrial networks of the OPC UA Synergy Platform
Figure 4: Diagram of robot and conveyor belt system used as a use case
Figure 5: Testbed implementation
Figure 5-(a): Pick and place demo system
Figure 5-(b): Cloud service control/monitoring
Figure 5-(c): Configuration Cloud Service
Figure 6: Operational sequence of the proposed architecture.
(A) HTTP Request Fetch Method
(B) HTTP response - status code 200
(C) OPC UA Request - ReadRequest
(D) OPC UA Response - Configuration latency of ReadResponse. Monitoring latency
(E) HTTP Request - Get Method
(F) HTTP response - status code 200
(G) OPC UA (AMQP) Subscription - Enabled
(H) OPC UA(AMQP) ACK - usage confirmation
(I) OPC UA (AMQP) Publishing (Issuance) - Delivery
(J) OPC UA (UADP) Publishing - UADP Message
Figure 7: Measurement results for round-trip delay over time obtained using the proposed approach.
Figure 7-(a): HTTP get/state RTT
Figure 7-(b): OPC UA P/S AMQP RTT
Figure 7-(c): OPC UA C/S BP RTT
Figure 7-(d): OPC UA P/S UADP OWD
Figure 8: Application-level average latency comparison between four different protocols.

Hereinafter, embodiments according to the present invention will be described in detail with reference to the attached drawings. The configuration of the present invention and its operational effects will be clearly understood through the detailed description below.

The present invention has the following features compared to conventional research.

First, unlike prior work, the present invention goes one step further to bridge the gap between the proposed architecture and actual implementation by providing guidance on how to demonstrate the OPC UA synergy platform concept through an experimental setup.

Second, the present invention provides an integrated architecture for industrial IoT to bridge the gap between the Internet and industrial aspects of the interconnection concept.

Third, the present invention specifies the details of various protocols that measure real-time delay, constructs an industrial pick-and-place testbed applicable to manufacturing systems, and verifies the OPC UA synergy platform.

Fourth, the testbed according to the present invention can serve as a guide for investigating the latest OPC UA PubSub-based protocols and many other types of protocol approaches.

Integrated architecture of the OPC UA Synergy Platform

Figure 1 shows the concept of the OPC UA synergy platform, which is divided into broker, brokerless, and server models according to IEC 62541 (OPC UA). While the broker and server model aims for reliable message transmission based on TCP (Transmission Control Protocol) communication on the Internet, the brokerless model guarantees rapid response based on UDP (User Datagram Protocol) communication in industrial networks. The OPC UA Synergy platform consists of the OPC UA Client/Server and OPC UA PubSub patterns for transmitting messages between the two networks. This platform also plays an important role in interconnecting the domains of the manufacturing system architecture (for the Internet and industrial networks). The synergy platform refers to a synergy model that uses the server/client and PubSub models simultaneously, and is a term officially used in the OPC UA specification document.

Figure 2 shows an industrial IoT network system consisting of an external Internet PubSub cloud client (10), an OPC UA synergy platform (100), and an internal industrial PubSub client (40).

Referring to Figure 2, the OPC UA synergy platform 100 is composed of a gateway (broker) 20, an Internet Group Management Protocol (IGMP) switch 30, a firewall 50, etc., and a gateway (broker) 20. ) includes an AMQP broker (22) and an OPC UA PubSub server (24).

The external Internet PubSub cloud (cloud client) 10 can communicate asynchronously with the OPC UA PubSub server 24 through the AMQP broker 22 in the out-of-TCP-based firewall 50. The AMQP broker 22 sends a message to the Internet PubSub cloud 10 according to the exchange type and routing key as shown in FIG. 2.

The OPC UA PubSub server 24 converts the message into an AMQP data set and transmits it to the AMQP broker 22. The PubSub stack defines functions called Network_Message_Reader/Writer that can check the data type (whether it is a UADP or AMQP message) and read and write to the data set format. The number of internal industrial PubSub clients 40 can be easily increased by connecting to a multicasting band that quickly multicasts messages to the gateway 20 through the IGMP switch 30.

For example, Figure 2 shows that a message from an industrial PubSub client 40 is converted to an OPC UA data set through the UADP PubSub stack and then stored in the OPC UA address space. Therefore, the TCP-based Internet and UDP-based industrial network can be connected through this platform 100.

However, the OPC UA PubSub server 24 must set the initial configuration from the user through BP as shown in FIG. 2. This initial configuration requires setting the UDP multicasting destination address, AMQP broker's destination address, and interval period. That is, BP is used for communication between the OPC UA server 24 and the client pattern. The OPC UA PubSub server 24 of the gateway 20 contains the information model, including the configuration, and OPC UA clients 10 outside the firewall 50 can connect to this server 24 to set up an initial configuration.

OPC UA Synergy Platform (100) consists of OPC UA PubSub server (24), open62541-based UADP and AMQP PubSub stack developed by the author, and AMQP Broker version 0.9.2.

Integrated architecture and implementation testbed according to the present invention

The integrated architecture according to the present invention referred to the IoT reference architecture of ISO/IEC 30141 for applying the Internet to industrial networks. The integrated architecture is shown in Figure 3 as the IIoT network and manufacturing system architecture of the OPC UA Synergy Platform.

The manufacturing system architecture is divided into four domains: users, cloud services, sensing and control, and devices, and can be mapped to the IIoT edge network.

In general, the concept of Far/Near Edge can be applied to IIoT edge networks. In the Far/Near Edge concept, the Far Edge (40, 60) can be mapped to the end-user domain (60) and device domain (40) of the manufacturing system that provides services or is provided in the cloud. Additionally, in the IIoT edge network, the cloud 10 can be mapped to the cloud service domain 10 of the manufacturing system. Near Edge (100) plays the role of distributing appropriately provisioned services between the cloud and the user. Near Edge (100) is where the OPC UA Synergy Platform (100) plays its role. This is where the sensing and control area 100 of the manufacturing system comes into play.

The sensing control domain 100 is mapped to the OPC UA Synergy Platform (1000) and processes large amounts of data between the cloud server 10 and the industrial device 40. Here, the sensing control domain 100 is connected to the cloud service 10 and the device. Connecting the domains 40, the OPC UA Synergy Platform 100 acts as an OPC gate or connector between the AMQP side of the Internet and the industrial network, solving the different interconnection problems of the two networks.

The role and description of each area in the manufacturing system are as follows.

A. Role of the integrated architecture area (domain)

1) User domain

The user domain defines the user as a customer (user terminal) who receives service from the factory. Users can easily access monitoring and configuration information from anywhere with an Internet connection, but do not have direct access to the internal plant. Users manage the factory flexibly by indirectly requesting services from the cloud service domain and passing configuration parameters.

2) Cloud service domain

The cloud service domain is directly connected to the internal factory and provides monitoring services to users based on Internet protocols (e.g. HTTP/HTTPS) and Internet security (e.g. TCP-firewall) to prevent malicious users from accessing the cloud. . The cloud service domain consists of a front-end server that provides user interface services and a back-end client that monitors factory information. Backend clients require IoT protocols (e.g. AMQP/MQTT) to reliably secure large amounts of data and multiple accesses to directly connect to many assets. Therefore, the cloud service domain must provide interconnection and fast processing to meet real-time requirements.

3) Sensing control domain

Factories need network processing machines for the sensing control domain to coordinate traffic between OT and Internet technologies. For example, multicasting for OT (e.g. UADP) requires an IGMP switch, and multicasting for IT (e.g. AMQP) requires a broker. The sensing control domain also serves to quickly process real-time data from multiple connections of industrial devices and simultaneously respond to requests from servers in the cloud domain. Therefore, the OPC UA Synergy platform can be included in the sensing control domain to connect the cloud service and device domain as shown in Figure 3.

4) Device domain

The device domain contains industrial equipment (devices) used to implement factory scenarios. For example, a pick and place scenario consists of entities such as a robotic arm, conveyor belt, and controller device. When an activation signal for an end device in the sensing control domain reaches the device domain, all industrial equipment automatically operates according to a pre-ordered scenario.

B. Communication protocols between industrial IoT domains

1) HTTP/HTTPS for user and cloud service domains

Users and cloud service domains require TCP-based communication for stability when using the Internet. Relatively long delays in TCP-based communications do not have a significant impact on users. Therefore, TCP-based communication is more reliable and is consequently the preferred type of data communication. HTTP is widely used as an Internet protocol to ensure data reliability. HTTP default ports are usually open even in firewalls, which is an advantage over other Internet protocols. Since HTTP does not have security, HTTPS was added for secure socket functionality. Therefore, it is recommended to use HTTP Additional Secure Sockets (HTTPS) for communication between users and cloud service domains.

2) AMQP/binary protocol in the discovery control domain and cloud service domain

For communication between the cloud service and the sensing control domain, the use of a firewall connected to the Internet as well as the interconnection issues to access the cloud must be considered. AMQP and OPC UA PubSub protocols allow significant and secure data transfer through middleware. Therefore, the OPC UA Synergy platform is used to provide an information model for AMQP/UADP connectivity. As shown in Figure 3, the OPC UA Synergy platform connects from the cloud domain to the detection control domain through the BP client/server, configures an AMQP PubSub connection on the cloud domain side, and then establishes an AMQP connection between these two domains. The AMQP broker on the sensing control domain side can ensure secure and stable interconnection to cloud servers.

3) Unified architecture datagram protocol of detection control domain and device domain

As shown in Figure 3, TCP-based communication is used when the upper part communicates with the sensing control domain. However, for downstream communications, industrial devices must quickly aggregate sensing data and send messages to the equipment simultaneously. UADP, based on the brokerless model, is a multicast protocol for OT that guarantees fast response and asynchronous communication. UADP also requires a specific switch and offloads the task of distributing messages to all subscribers in the network over the IGMP switch. Therefore, this protocol is recommended to ensure fast processing of UDP communications on the low end.

Meanwhile, the device domain consists of various industrial protocols that manufacturers can support. These protocols are real-time based industrial protocols that respond immediately at critical points and allow industrial devices to communicate with each other via OPC UA. If the industrial device does not provide OPC UA functionality, it can be easily connected to the OPC UA Synergy platform using the OPC UA stack for UADP functionality.

An important feature of the architecture according to the invention is that it uses OPC-based OPC UA with multiple vendors to ensure interoperability and interconnectivity between heterogeneous devices. OPC UA also provides useful features for information models and communication services for robust interoperability solutions.

Another key feature of the integrated architecture is its distributed architecture and asynchronous operations from user to end device, divided into four domains. These benefits simplify complex life cycles and expand the flexibility of the system. Therefore, system management efficiency can be improved. In addition, asynchronous operation of four industrial areas can solve explosive traffic processing problems and provide larger-scale services such as big data processing.

Case Study: Pick and Place System

In this section, we demonstrate the pick and place system as a case study of the architecture according to the invention to verify its various performances. A system was implemented to map the architecture of the invention and illustrate a pick-and-place scenario. Figure 4 shows a diagram of the robot and conveyor belt system used as a case study. Figure 5 shows an actual implemented testbed that can be divided into four domains and three networks.

1) HTTP user domain

As shown in FIG. 4, in the user domain 40, a user may be any entity that desires monitoring services, such as adjusting the position of a robot, operating status of a device, or a configuration service that adjusts the message cycle or speed through HTTP. . There are usually several HTTP clients and users can choose any web browser that supports HTTP.

2) Cloud service domain with AMQP and BP applied

In the cloud service domain (10), two cloud servers (12, 14) supporting HTTP and three routers for Internet connection were designed so that distributed clouds can communicate with each other. The first cloud server (first cloud) 12 was used for factory configuration services. The second cloud server (Second Cloud) (14) was for factory monitoring/control services. The factory monitoring/control server 14 requests factory information from the OPC UA Synergy Platform Gateway 20 through AMQP of the OPC UA PubSub interface. When the user's configuration messages (e.g., period, speed, IP address information) are passed to the server 12 for factory configuration, the server 12 sends that information through the BP of the OPC UA client/server interface to the OPC UA Synergy Platform Gateway. Send to (20).

3) Discovery control domain using OPC UA

As shown in Figure 4, the detection control domain 100 corresponds to the OPC UA synergy platform and is composed of a gateway 20 and an IGMP switch 30 for multicasting. The gateway 20 of the OPC UA Synergy platform includes UADP, AMQP stack and BP client/server stack, which are assumed to connect the sensing control domain with the cloud and device domains. Meanwhile, the OPC UA Synergy Platform 100 subscribed to UADP messages from four Raspberry Pi 3 computers through the industrial network as shown in FIG. 4. The OPC UA Synergy platform 100 also converts the UADP message into an AMQP data set and simultaneously transmits it to the external Internet.

4) Device domain with UADP and PowerLink

The device domain 40 consists of two conveyor belts, two robot arms, four PLC I/O controllers supporting power link, and four Raspberry Pi 3 Model B computers for robot/conveyor operation software including control logic. do. There are no available OPC products that support PowerLink and UADP communications simultaneously. With this in mind, we developed a simple UADP and PowerLink stack on Raspberry Pi 3 computers that can be used to connect these computers to the OPC UA Synergy platform and PowerLink network.

As shown in Figure 4, the Raspberry Pi 3 computer posts monitoring data to the OPC UA Synergy platform through UADP. It is also designed to send control signals for the robot/conveyor belt to each PLC I/O controller through the Power Link network. After receiving control signals from the PLC I/O controller, the two conveyor belts or robots operate according to the pick and place scenario.

The robot receives a completion signal after the conveyor belt has finished its work. If the conveyor belt does not come to a complete stop, the robotic arm will not work to pick up the object and vice versa. Once the setup is complete, the robot picks up the item and places it on the other side, and the conveyor belt starts transporting it as shown in Figure 4.

5) Building a test bed

Figures 5(a)-(c) show the pick and place system and user interface (UI) display implemented for two cloud servers. As shown in Figure 5(a), the system used four Raspberry Pi 3 Model B computers as UADP publishers and two sets of PLCs X20CP1584 and two sets of X20BC0083 as Powerlink I/O modules.

The system also includes ipTIME SW2400-mini 24 for IGMP switch and Intel NUC kit NUC8I3BEH as OPC UA platform gateway. Two 6-axis robot arms and two conveyor belts made by Ufactory were used as the final devices. The real-time status values of the robot and conveyor belt operations and the coordinates of the target point obtained from the industrial network are shown in Fig. Same as 5(b). Figure 5(c) shows the address, rate, and TTL (Time To Live) settings and configuration server for AMQP and UDP multicasting for OPC UA synergy. Two Lenovo Think Center M720 Tiny PCs were used as servers and were used to provide web content to users through a web application server.

In Figure 5, the robot and conveyor belt are connected to industrial PLC equipment. Additionally, the PLC device communicates with each of the four Raspberry Pi modules containing the robot software via PowerLink, an industrial protocol for real-time applications. Here, PowerLink is Ethernet-based communication and has three characteristics.

- Configurable response time ensures time-critical data transmission with very short isochronous periods.

- Synchronizes the times of all nodes in an industrial network with very high precision of sub-microseconds.

- Transfer of less important data on scheduled asynchronous channels.

Therefore, real-time and synchronization can be maintained between the PLC and Raspberry Pi through the PowerLink protocol. Additionally, a UADP-based protocol using OPC UA is used between the Raspberry Pi and the OPC UA Synergy Platform Gateway. Here, the chrony tool, a Network Time Protocol (NTP) based system synchronization tool, was used between the Raspberry Pi and the OPC UA Synergy Platform Gateway. The chrony tool supports clock synchronization of each system through hardware timestamps, enabling system clock synchronization of any Raspberry Pi and OPC UA Synergy Platform Gateway.

A sequence diagram is used to explain the operation of the architecture according to the present invention. We also present performance evaluation results for four areas of the architecture. We then compare the application-level latency for each communication protocol by varying the payload size.

A. Sequence of operations

The sequence of operational tasks for the architecture according to the invention is shown in Figure 6. Customers in user domain 60 may request monitoring or response data to establish an initial configuration of the OPC UA Synergy platform. The cloud service domain 10 includes a cloud server 12 for initial configuration and a cloud server 14 for industrial data control/monitoring.

As shown in Figure 6, processes A-D span from the user domain 60 to the sensing control domain 100. This process is for the initial configuration of the first cloud (12), i.e. “Factory Configuration Cloud1”. This server 12 can manage the configuration of the OPC UA Synergy platform (e.g. message rate, frequency, IP address of each industrial device). “Factory Configuration Cloud1” is processed asynchronously over HTTP between the user and the cloud service domain, while the OPC UA PubSub server (24) in the discovery control domain (100) is an OPC UA client/server using the Cloud1 server (12). It is processed synchronously through patterns. User and cloud service domains were configured through HTTP post/get method and ACK (Acknowledgement) signals (A, B).

The OPC UA PubSub server provided the ReadRequest and ReadResponse of the RPC (Remote Process Call) service to the cloud, as shown in Figure 6 (C and D). The configuration latency shown in Figure 6 is obtained by summing the difference between (A) and (B) and the difference between (C) and (D).

Figure 6 shows that the monitoring delay ranges from the user domain to the device domain, and the monitoring/control data of the second cloud (Factory Monitoring/Controlling Cloud2) (14) has been processed (E-J). In this process, customers receive monitoring data between the cloud service and the sensing control domain through HTTP and OPC UA PubSub patterns. As can be seen in Figures 6(G)-(J), the OPC UA PubSub server 24 receives industrial data sets from the device domain and converts them into AMQP data sets that are sent to the AMQP broker 22. When this data set reaches the AMQP queue, the AMQP broker transmits the data set to the subscriber (Cloud2 server) (14). If the device domain 40 includes additional industrial equipment, UADP PubSub is added as shown in FIG. 6(J) and data is automatically released to the multicasting band. In this process, Cloud1 provides configuration services for the PubSub model, and Cloud2 monitors large-scale message transmission and ensures interconnection of terminal devices. The total monitoring delay time shown in Figure 6 was obtained by summing the time difference between (E) and (F), the time difference between (G) and (H), and the multicast publishing delay (I) and (J).

B. Data delay of architecture according to the present invention

For the operation sequence diagram in Figure 6, the target delay time protocol and measurement range for each area are shown in Table 1.

Table 1 presents four measurement targets, including each major protocol in the domain. The four measurement targets are the HTTP protocol between the user and the cloud service domain, BP based on the OPC UA client/server model, AMQP based on the OPC UA PubSub model between the cloud service and the discovery control domain, and OPC UA PubSub of UADP between the discovery control domain and the device domain. It's a model.

In the case of traffic generation, we implemented a user application that periodically transmits packets with a transmission/reception period of 10ms and a payload size of 256 to 16384 bytes. The user application was implemented using open62541, an open source resource for OPC UA implementation, and the AMQP Stack and HTTP Stack of the Rabbitmq project.

We compared the latency on the receiver side using the Wireshark measurement tool. In all conducted experiments, the message transmission/reception period for each of the four areas was 10 ms and the payload size was 256 to 16384 bytes. This latency measurement experiment was performed and collected 10 times over 30 minutes, from a minimum of 5872 packets to a maximum of 11168 packets.

Figure 7 shows the measurement results of application-level protocol latency, which is the main result obtained in Table 2. Figure 7(a) shows the round-trip time with HTTP latency between the user domain and the configuration cloud1 server. This maximum latency was 11.90ms on average at 16384 bytes, resulting in a delay of 37.97ms, and HTTP retransmissions were measured up to 48 times at 16384kb using the Wireshark measurement tool. HTTP represents highly reliable communication by using retransmission when data is lost during transmission or a problem occurs with the ACK value.

However, this retransmission has a significant impact on latency and occurs more frequently as the payload value increases, resulting in a larger average delay (Figure 7(a)). Therefore, the latency results also show that among all TCP protocols, HTTP has the highest payload impact and the slowest response time.

Figure 7(b) shows the latency for AMQP in the OPC UA PubSub model, showing a negligible impact on payload size compared to HTTP. Similarly, AMQP exhibited less variable delays as payload size increased. The maximum latency for this protocol is 3.85ms and the average time is 3.37ms at 16384 bytes.

Figure 7(c) shows the RTT of BP based on the OPC UA client/server model, showing the most monotonous and fastest response time compared to other TCP protocols. The maximum latency of this protocol is 2.15ms and the average time is 1.91ms. In a TCP network, the maximum TCP bandwidth is guaranteed when RWND (Receive Windows Size) and TWND (Transmission Windows Size) are equal. These different sizes affect the maximum bandwidth and create latency.

Meanwhile, in this experiment, the TWND size is fixed because it does not change the outgoing buffer size, while the RWND size depends on the window size option adjusted by the receiver. Similarly, the three protocols (HTTP, AMQP, and BP) of the TCP application shown in Figure 7 exhibit application-level delays in all TCP measurements due to their different RWND and TWND sizes. Application of UDP had a negligible effect except for the initial change time required for address interpretation in the IGMP switch, as shown in Figure 7(d).

Figure 7(d) shows One-Way Delay (OWD) in UADP of the OPC UA PubSub model. Unlike TCP networks, UADP had minimal impact on latency regardless of payload size and was only affected by PubSub's transmission cycle. The maximum latency of this protocol is 0.85ms and the average time is 0.80ms at 16384 bytes.

Overall, UADP achieved the fastest response among all protocols. To be exact, it was 45 times faster at 16384 bytes than the slowest HTTP, as shown in Figure 8. BP was 1.6 times faster at 16384 bytes than AMQP. On the other hand, BP was 2.5 times slower than UADP 16384 bytes. Experiments showed that UADP based on OPC UA PubSub was suitable for the device domain because it minimizes delay, requires fast response, and handles large amounts of data. Lastly, HTTP has relatively higher latency compared to other protocols. However, due to its high reliability, it is appropriate to apply it to the user domain.

The present invention applies the OPC UA PubSub model to minimize processing delay time and uses the UDP-based UADP protocol instead of the TCP-based binary protocol when the broker sends and receives messages at the gateway.

The architecture according to the present invention refers to ISO/IEC 30141, a standard IoT reference architecture document, and proposes a four-domain integrated architecture that divides the manufacturing system into user, cloud service, sensing control, and device domains.

In other words, the present invention proposes an integrated architecture divided into four areas that can provide services to industrial networks that require rapid response while providing stable Internet. The OPC UA Synergy platform plays an important role in integrating two different networks and is designed to ensure interoperability and transfer of significant amounts of data between the two networks. The integrated architecture of the OPC UA Synergy platform of the present invention is expected to accelerate the adoption of Industry 4.0 technologies.

The present invention also studied pick-and-place scenarios and analyzed and verified the system of the present invention through use cases. Application-level latency analysis shows that the OPC UA protocol can guarantee high performance compared to other protocols and provide competitive services for the information model.

Based on the approach and experimental results according to the embodiment of the present invention, the role of the industrial system was defined into four distributed domains (from user to end device) using the PubSub model-based OPC UA synergy platform.

The present invention can improve system management efficiency by simplifying the complex life cycle of not only general systems but also industrial systems and improving flexibility. Moreover, the proposed comprehensive architecture, which integrates the Internet and industrial networks in a previously unexplored way, can achieve interoperability and large number of message transmissions.

The present invention also provides perspectives related to OPC UA PubSub. First, recent research has focused on UADP-based Time Sensitive Networking (TSN) to achieve real-time industrial communication. Second, 5G-based OPC UA PubSub will become a key research topic in the future. In particular, AMQP PubSub can provide strong security and highly reliable functions when combining IIoT and 5G with the cloud domain side. Therefore, the present invention will be able to effectively connect or integrate future technologies through the integrated architecture of the OPC UA synergy platform.

The above description is merely an illustrative description of the present invention, and various modifications may be made by those skilled in the art without departing from the technical spirit of the present invention.

Accordingly, the embodiments disclosed in the specification of the present invention do not limit the present invention. The scope of the present invention should be interpreted in accordance with the scope of the patent claims below, and all technologies within the equivalent scope thereof should be interpreted as being included in the scope of the present invention.

10: Cloud 12: First Cloud
14: Second Cloud 20: Gateway
22: AMQP Broker 24: OPC UA Pubserve Server
30: IGMP switch 40: Industrial client (equipment)
50: Firewall 100: OPC UA Synergy Platform

Claims (7)

In the gateway of the OPC UA synergy platform,
an OPC UA pubserve server that converts the UADP data set received from each device in the device domain into an AMQP data set;
A gateway including an AMQP broker that transmits the AMQP data set received from the OPC UA pubserve server to a cloud domain. According to paragraph 1,
The OPC UA pubserve server is a gateway characterized in that the initial configuration is set through binary protocol (BP). When the user terminal requests initial configuration settings from the cloud domain, the first cloud server of the cloud domain requests initial configuration settings from the OPC UA synergy platform;
A step where the OPC UA server of the OPC UA synergy platform performs settings for initial configuration,
The OPC UA server of the OPC UA synergy platform receives a UADP message from each device in the device domain;
The AMQP broker of the OPC UA synergy platform converts the UADP message into an AMQP data set and transmits it to a second cloud server in the cloud domain;
An integration method between heterogeneous networks comprising the step of a second cloud server of the cloud domain processing and monitoring the AMQP data set and transmitting the monitoring result to the user terminal. According to paragraph 3,
An integration method between heterogeneous networks, characterized in that the user terminal requests initial configuration settings from the cloud domain through the HTTP protocol. According to paragraph 3,
An integration method between heterogeneous networks, characterized in that the first cloud server requests settings for initial configuration to the OPC UA server of the OPC UA synergy platform through a binary protocol (BP) based on the OPC UA client/server model. According to paragraph 3,
An integration method between heterogeneous networks, characterized in that communication between the OPC UA server of the OPC UA synergy platform and the device domain is performed through a UADP protocol based on the OPC UA pubsub model. According to paragraph 3,
An integration method between heterogeneous networks, characterized in that communication between the AMQP broker of the OPC UA synergy platform and the second cloud server of the cloud domain is performed through an AMQP protocol based on the OPC UA pubsub model.