Toward Industrial IoT: Integrated Architecture of an OPC UA synergy platform

Recently, the manufacturing industry has revolutionized with ’smart manufacturing’ and ’Industry 4.0’, and with the development of the Industrial Internet of Things (IIoT), increasing number of physical objects can access network services. However, critical issues such as real-time communication, interoperability, and interlinking of internet and industrial devices are yet to be addressed. These issues arise from the problem of interconnectivity between smart manufacturing systems and non-semantic industrial equipment. Therefore, we referred to ISO/IEC 30141, a standard IoT reference architect document, to solve the interconnection problem and bridge the gap between the Internet and industry. Furthermore, we proposed a four-domain integrated architecture that divides the manufacturing system into user, cloud service, sensing controlling, and device domains. The proposed architecture is validated by constructing the applicable industrial pick-and-place testbed for the manufacturing system. Thus, this testbed can serve as guideline to examine the state of the art of the OPC UA PubSub based protocol in addition to several other types of protocol approaches.


I. INTRODUCTION
W ITH the development of modern information technologies, internet traffic has rapidly increased; more than 50 billion IP connections were projected for the year 2025 [1]. Hence, an Internet of Things (IoT) architecture based on modern computing models, such as Fog or Edge computing, has been recently proposed to reduce process delays and address the limitations of IP resources on the internet [2]- [4]. However, cirical issues such as real-time communication, interoperability, and interlinking of internet and industrial devices are yet to be addressed [5]- [7].
Recently, the manufacturing industry has revolutionized with 'smart manufacturing' and 'Industry 4.0', and with the development of the Industrial Internet of Things (IIoT), increasing number of physical objects can access network services. However, a major challenge that complicates the active adoption of IIoT in smart manufacturing is the problem of Operation Technology (OT) -Information Technology (IT) integration between the shop floor and smart manufacturing systems. This is caused by the problem of interconnectivity between smart manufacturing systems and non-semantic industrial equipment. Therefore, attempts to solve the interconnectivity problem through semantically expressible devices (e.g. OPC UA gateways/ connectors) in smart manu-facturing are being actively made to solve these problems. [8], [10].

A. BACKGROUND
Research and development efforts in terms of interconnection are underway to solve the problems encountered in internet and industrial networks, and the integration of these two networks has been proposed [6], [7]. This proposed integration requires considering two vital aspects: reliability for the internet and immediate response for the industrial network. For example, to block malicious intentions on the internet, traditional firewalls employ a Deep Packet Inspection (DPI)-based algorithm [12] that examines the packets up to the transport layer; however, this algorithm requires a long processing time. Although this long processing time is not critical for the internet, it can cause problems in systems that require an immediate response at critical times, such as safety detection VOLUME 4, 2016 systems. Thus, security and message transmission reliability are more important than immediate response for the internet. The traditional Supervisory Control And Data Acquisition (SCADA) firewalls in SCADA systems of industrial networks only provide limited security for fieldbus protocols on IEC 61158 [13], because industrial networks require rapid processing for time-critical missions. Thus, in stark contrast to the internet, industrial networks require instant response at critical times and face important challenges, such as limited service. To ensure the effective utilization of these two types of networks with different characteristics, the interlinking concept has been developed.

B. RELATED WORK
Endeley et al. [8] suggested a solution featuring a set of communication primitives, a platform-independent type system, and an intermediate language. They implemented Open Platform Communications Unified Architecture (OPC UA) connector through OPC UA information model for the Virtual Automation Bus (VAB) Gateway and for communicating with Industry 4.0 applications. They also evaluated the overhead created by consolidation in terms of round-trip time and message size imposed by metadata for abstraction. However, while these authors have sufficiently introduced the interface between the existing OPC UA Server/Client model and HTTP technology, they have not considered the OPC UA PubSub model for asynchronous data processing.
Kannoth et al. [10] studied the middleware solution that implements OPC gateway to ensure interconnectivity and interoperability and enable effective communication between OPC UA Server/Client model and DDS model. They also tested the performance of the middleware in different scenarios using Raspberry Pi and software middleware connected to a private LAN and evaluated its operation by measuring response times and reliability.
In their study as well, OPC UA's PubSub Model was not used, and processing delay time occurred while OPC UA server exchanged data through OPC gateway and TCP-based Binary Protocol (BP) and converted it into UDP communication DDS data. However, in our approach, the OPC UA PubSub model is applied to minimize the processing delay time, and when the broker sends and receives messages from the gateway, the UDP-based UADP protocol is used instead of the TCP-based binary protocol.
Koziolek et al. [16] suggested a plug-and-produce architecture for Industrial Internet of Things (IIoT) and implemented it on open-source code-based system. However, the authors considered only the industrial side for interoperability and ignored the IoT protocol and internet security or reliability.
Gruner et al. [17] proposed a web platform that integrates the Representational State Transfer (REST) architecture to utilize the internet for solving the interoperability problem between resource-constrained devices in industrial networks using the OPC UA [18].Although these authors sufficiently introduced the interface between OPC UA and the REST technology for processing synchronous data, they neither considered it for industrial networks nor demonstrated the implementation of the OPC UA PubSub interface with middleware for processing asynchronous data.
Luo et al. [9] suggested using the OPC UA technology and applied the Industrial Internet Reference Architecture (IIRA) with a three-tier structure proposed by the Industrial Internet Consortium (IIC) to a smart manufacturing system.
IIRA [11] proposed by IIC is a three-tier structure. The first enterprise tier implements domain-specific applications with interfaces to end-users, and the second platform tier receives, processes, and forwards data. The final edge tier collects data from edge nodes using a proximity network. However, the architecture proposed in this study refers to ISO/IEC 30141, a standard IoT reference architect document, and proposes a four-domain integrated architecture that divides the manufacturing system into user, cloud service, sensing controlling, and device domains.
Both architectures have similar structures for applying Industrial IoT applications to smart manufacturing systems and utilize industrial protocols and OPC UA technology that value real-time; however, the OPC UA PubSub model for asynchronous data processing was not considered in their study.
Regarding analysis of the application-level latency with OPC UA technologies, some studies have compared IoT protocols [19]- [23] other than the Unified Architecture Datagram Protocol (UADP)/Advanced Message Queuing Protocol (AMQP) [24] PubSub. These studies have provided not only an overview of the different features of OPC UA technology but also Constrained Application Protocol (CoAP) [15] and Message Queuing Telemetry Transport (MQTT) [25] and compared their performance against benchmarks.

C. MOTIVATION
Open Platform Communication (OPC) Foundation recently defined a new specification (part 14) for extending the Pub-Sub method to ensure interoperability when applying IoT technologies to industrial networks. However, a concrete concept about how to link the two different technologies of the brokerless model (e.g., UADP PubSub) for industrial protocols and the broker model (e.g., AMQP PubSub) for IoT protocols is still missing. This missing concept can be crucial for addressing the different integrating data in the field of Industry 4.0, which is a cutting-edge technology that is currently being studied. In addition, there has been no case in which the latest OPC UA technologies incorporating the OPC UA PubSub between the internet and industrial networks has been used because the OPC UA specification has recently defined IoT communication. Therefore, this study aims to propose an integrated architecture, divided into user, cloud service, sensing controlling, and device domains, and develop an OPC UA synergy platform concept to interlink server, broker, and brokerless models. To the best of our knowledge, compared with the existing studies, our contributions can be summarized as follows:  • First, unlike existing works, this paper takes a step forward to fill the gap between the proposed architecture and practical implementations by providing guidelines on how to demonstrate an OPC UA synergy platform concept through an experimental setup. • Second, in this pioneering work, the integrated architecture for Industrial IoT is proposed to bridge the gap between the internet and industrial side for the interlinking concept. • Third, the applicable industrial pick-and-place testbed for the manufacturing system is constructed by specifying the details of various protocols, over which the real-time delay was measured, and the OPC UA synergy platform is validated. • Fourth, the established testbed can serve as a guideline to examine the state of the art of the OPC UA PubSub based protocol, and several other types of protocol approaches.
To summarize, the objective of this work is to explore the applicability of the synergy platform, the proposed integrated architecture, and the testbed, to verify our analysis of this advanced interlinking concept. Fig. 1 illustrates the concept of the OPC UA synergy platform, which is divided into broker, brokerless, and server models based on IEC 62541 (OPC UA) [18], [26]- [30]. The broker and server models aim at transmitting reliable messages based on Transmission Control Protocol (TCP) communication on the internet, whereas the brokerless model guarantees a rapid response based on User Datagram Protocol (UDP) communication in an industrial network. The OPC UA synergy platform comprises the OPC UA client/server and OPC UA PubSub pattern for transmitting messages between the two networks. This platform also plays an important role in interlinking the domains (for the internet and industrial network) of the manufacturing system architecture. The synergy platform refers to a synergy model that uses the Server/Client and the PubSub model at the same time, and it is a term officially used in the OPC UA spec document [18], [30]. Fig. 2 shows the detailed structure of the OPC UA synergy platform, which is divided into external internet PubSub cloud clients, gateway (broker), Internet Group Management Protocol (IGMP) switch, and internal industrial PubSub clients.

II. INTEGRATED ARCHITECTURE OF THE OPC UA SYNERGY PLATFORM
The external internet PubSub cloud (the cloud client) can asynchronously communicate with the OPC UA PubSub server through the AMQP broker from the out-of-TCP-based firewall. The AMQP broker sends messages following the exchange type & routing key to the internet PubSub cloud, as depicted in Fig. 2.
The OPC UA PubSub server converts the message to the VOLUME 4, 2016 AMQP dataset and transmits it to the AMQP broker. The PubSub stack defines a function called Network_Message _Reader/Writer, which verifies the data type (whether it is a UADP or AMQP message) and can read/write in the dataset format. The number of internal industrial PubSub clients can be easily increased by connecting to the multicasting band, which rapidly multicasts messages to the gateway through the IGMP switch.
For instance, Fig. 2 shows that the message from the industrial PubSub client is converted into the OPC UA dataset through the UADP PubSub stack, and the dataset is then stored in the OPC UA address space. Thus, TCPbased internet and UDP-based-industrial networks can be interlinked through this platform. The OPC UA Synergy Platform comprises an OPC UA PubSub server with the UADP & AMQP PubSub stack based on open62541, developed by the authors, and the AMQP Broker version 0.9.2. The OPC UA Synergy Platform comprises an OPC UA PubSub server with the UADP & AMQP PubSub stack based on open62541, developed by the authors, and the AMQP Broker version 0.9.2.
However, the OPC UA PubSub server needs to set the initial configuration from the user through the BP, as shown in Fig. 2. This initial configuration must mainly set the UDP multicasting destination address, the AMQP broker's destination address, and the interval cycle. In other words, the BP is used to communicate between the OPC UA server and the client pattern. The OPC UA PubSub server in the gateway contains an information model, including configuration, and the OPC UA client from outside the firewall can connect to this server to set the initial configuration.

III. PROPOSED INTEGRATED ARCHITECTURE AND IMPLEMENTATION TESTBED
In this section, we describe the proposed integrated architecture of the OPC UA synergy platform. The proposed architecture was developed by us and referenced from the IoT reference architecture in ISO/IEC 30141 for applying the internet to the industrial network [31]. The proposed integrated architecture is depicted in Fig. 3 as the IIoT network of the OPC UA synergy platform and the manufacturing system architecture.
The manufacturing system architecture is divided into four domains, user, cloud service, sensing & controlling, and device, which 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 can be mapped to an end-user and device domain in the manufacturing system which provides services or has been served from the cloud. Furthermore, in the IIoT edge network, the cloud can be mapped to the Cloud Service Do-main in the manufacturing system. Near Edge is responsible for distributing services to be properly provisioned between users and the Cloud, which is where the OPC UA Synergy Platform plays a role. This is where the sensing & controlling domains in manufacturing systems play this role.
The sensing & controlling domain is mapped to the OPC UA synergy platform to process large amounts of data between cloud servers and industrial devices. Here, the sensing and control domain connects the cloud services and device domains, and the OPC UA synergy platform acts as the OPC Gate or Connector between the AMQP side of the internet and industrial networks, solving the problems of the different interconnection of the two networks.
The roles and descriptions of each domain in the manufacturing system are as follows.

1) User domain
This domain defines the user as a customer receiving services from the factory. The user can easily access the monitoring and configuration information from anywhere with an internet connection, but not directly access the internal factory. The user indirectly requests service from the cloud service domain and delivers their configuration parameters to flexibly manage the factory.

2) Cloud service domain
The cloud service domain directly connects to the internal factory and provides a monitoring service to users based on an internet protocol (e.g., HTTP/HTTPS) and internet security (e.g., TCP-firewall) to block malevolent users from accessing clouds. The domain consists of front-end servers for providing the user interface service and a back-end client for monitoring the factory information. The back-end clients require the IoT protocol (e.g., AMQP/MQTT) to stably obtain large amounts of data and multiple access for connecting directly to the many assets; thus, this domain should provide interconnection and fast processing to satisfy real-time requirement.

3) Sensing & Controlling domain
The factory needs a network processing machine for the sensing & controlling domain to adjust the traffic between the OT and internet technology. For example, the IGMP switch is necessary for using multicasting for OT (e.g., UADP) and the Broker to using multicasting for IT (e.g., AMQP). This domain also plays the role of rapidly processing real-time data from multiple connections of the industrial devices and simultaneously replying to requests from the servers in the cloud domain. Thus, the OPC UA synergy platform can be included in this domain to bridge the cloud service and device domain as shown in Fig. 3.

4) Device domain
The device domain includes industrial equipment used for implementing factory scenarios. For example, the pick-andplace scenario comprises entities such as robot arms, conveyor belts, and a controller device. When the activating signal for the end-devices from the sensing & controlling domain arrives in the device domain, all the industrial equipment operate automatically in accordance with the preordered scenario.

1) HTTP/HTTPS of user and cloud service domains
The user and cloud service domains require TCP-based communication for reliability purposes, when using the internet. In TCP-based communication, a relatively long delay has no critical impact on the user; hence, TCP-based communication is more reliable and consequently the preferred type of data communication. HTTP is widely used as an internet protocol to ensure data reliability. HTTP default ports are also usually open in firewalls, which is an advantage over other internet protocols. HTTPS is added for secure socket function because HTTP has no security; thus, we recommend using the HTTP added secure socket (HTTPS) for communication between the user and cloud service domains.

2) AMQP/Binary protocol of the cloud service and sensing & controlling domains
For communication between the cloud service and sensing & controlling domains, not only the interconnection problem of accessing clouds but also using the firewall with an internet connection should be considered. The AMQP and OPC UA PubSub protocol enables the transmission of considerable and secure data through middleware; thus, we recommend the OPC UA synergy platform to provide an information model for the AMQP/UADP connection. This platform connects from the cloud domain to the sensing & controlling domain via a BP client/server as depicted in Fig. 3, configures the AMQP PubSub connection at the cloud domain side, and then establishes the AMQP connection between these two domains. The AMQP broker at the sensing & controlling domain side can ensure secure and reliable interconnection for cloud servers. As shown in Fig. 3, when the upper side communicates with the sensing & controlling domain, the TCP based communication is utilized; however, for the lower side communication, sensing data should be quickly aggregated from the industrial device, and messages should be concurrently sent to the equipment. The UADP based on the brokerless model ensures a rapid response and asynchronous communication as a multicast protocol for OT. The UADP also requires specific switches and shifts the work of distributing the messages to VOLUME 4, 2016 all subscribers into the network through the IGMP switches; thus, this protocol is recommended to ensure the processing of fast UDP communication on the lower side. Meanwhile, the device domain comprises various industrial protocols that can be supported by manufacturers. These protocols are realtime based industrial protocols that respond immediately at critical times, and the industrial devices can communicate with each other via OPC UA. If industrial devices do not provide OPC UA function, the OPC UA stack for UADP functionalities can be used to easily connect to the OPC UA synergy platform.
An important feature of the proposed architecture is that it guarantees interoperability and interconnectivity among heterogeneous devices by using OPC UA from the OPC foundation in conjunction with multiple vendors. Moreover, OPC UA provides a useful function for information models and communication services for strong interoperability solutions. Another key feature of this integrated architecture is its distributed structure and asynchronous operation from the user to the end-device, are divided into four domains. This advantage simplifies the complex life cycle and extends the flexibility of the system; thus, it enhances system management efficiency. Additionally, asynchronous operation of the four industrial domains solves the explosive traffic processing problem and provides more large-scale services, such as big data processing.

C. CASESTUDY: THE PICK AND PLACE SYSTME
In this section, the pick-and-place system is demonstrated as a case study of the proposed architecture to validate the various performances. The system mapped the proposed architecture and implemented it to illustrate the pick-andplace scenario. Fig. 4 presents a diagram of the robot and conveyor belt system used as a case study. Fig. 5 shows the real implemented testbed, which can be divided into four domains and three networks.

1) User Domain with HTTP
As shown in Fig. 4, in the user domain, the user can be any entity that seeks monitoring services, such as coordination of a robot position, operation status of a device, or configuration service of adjusting the message period or speed through HTTP. There are typically several HTTP clients, and the user can choose a web browser that supports HTTP.

2) Cloud Service Domain with AMQP and BP
In the cloud service domain, to ensure that distributed clouds can communicate with each other, we designed two cloud servers supporting HTTP and three routers for internet connection. The first cloud server was used for the factory monitoring/controlling service; the second server was for the factory configuration service. The server for factory monitoring/controlling requests factory information from the OPC UA synergy platform through the AMQP of the OPC UA PubSub interface. When the configuration message from the user (e.g., period, speed, IP address information) is delivered to the server for the factory configuration, the server sends the information to the OPC UA synergy platform through the BP of the OPC UA client/server interface.

3) Sensing & Controlling Domain with OPC UA
As shown in Fig. 4, the sensing & controlling domain comprised the OPC UA synergy platform and IGMP switch for multicasting. The OPC UA synergy platform included the UADP, AMQP stack, and BP client/server stack, which is assumed to bridge the sensing & controlling domain with the cloud and device domains. Meanwhile, the OPC UA synergy platform subscribed to the UADP messages from four Raspberry Pi 3 computers through the industrial network, as shown in Fig. 4. This platform also converts the UADP messages into AMQP datasets to transmit them to the external internet simultaneously.

4) Device Domain with UADP and Powerlink
The device domain comprised two conveyor belts, two robot arms, four PLC I/O controllers supporting Powerlink [33], and four Raspberry Pi 3 Model B computers for the robot/conveyor operating software, including control logic. Note that there are no available OPC products that support Powerlink and UADP communication at the same time, considering this, we have developed a simple UADP & Powerlink stack in Raspberry Pi 3 computers, such that these computers can be used for connecting to the OPC UA synergy platform and Powerlink network. As shown in Fig. 4, the Raspberry Pi 3 computers publish monitoring data to the OPC UA synergy platform through UADP. Additionally, these were designed to send control signals for the robots/conveyor belts to each PLC I/O controller via the Powerlink network. After receiving the control signal from the PLC I/O controller, the two conveyor belts or robots operates according to the pick-and-place scenario.
The robot receives the completion signal after the conveyor belt finishes its job; when the conveyor belt does not stop completely, the robot arm will not operate to pick up the object, and vice versa. When the setup is ready, the robot picks up and place the object on the opposite side, and the conveyor belt starts the delivery, as shown in Fig. 4.   Fig. 5(a)-(c) illustrates the implemented pick-and-place system and a User Interface (UI) display for two cloud servers. As shown in Fig. 5(a), the system used four Raspberry Pi 3 Model B computers as the UADP publisher, together with two PLC X20CP1584 and two X20BC0083 sets as the Powerlink I/O module. The system also included an ipTIME SW2400-mini 24 for the IGMP switch and Intel NUC Kits NUC8I3BEH as the OPC UA platform gateway. Two sixaxis robot arms and two conveyor belts made by Ufactory were used as the end-devices. The real-time state values of the robot and conveyor belt operation and the coordinates of the target point obtained from the industrial network are shown in Fig. 5(b). Fig. 5(c) depicts the configuration servers and the setting of the address, speed, and Time To Live (TTL) of AMQP and UDP multicasting for the OPC UA synergy. Two Lenovo Think Centre M720 Tiny PCs were used as the servers, which are used to present the web content for users through the web application server. In the Fig. 5, the robot and conveyor belt are connected to industrial PLC equipment. The PLC unit also communicates with each of the four Raspberry Pi modules including the robot software via Powerlink, an industrial protocol for real-time applications. Here, the powerlink is ethernet-based communication and has three characteristics:

5) Implementation of the Testbed
• Configurable response times ensure time-critical data transmission with very short isochronous cycles. • Synchronize time of all nodes in the industrial network with very high sub-microsecond precision. • Less important data transfer on scheduled asynchronous channels.
Therefore, the real-time and synchronization can be maintained between PLC and Raspberry Pi through powerlink protocol. In addition, the UADP-based protocol using OPC UA is used between Raspberry Pi and OPC UA Synergy Platform gateway. Here, the chrony tool, a system synchronization tool based on Network Time Protocol (NTP), was used between the Raspberry Pi and the Synergy Platform gateway. The chrony tool supports clock synchronization of each system through hardware timestamps, which enables system clock synchronization of all Raspberry Pis and Synergy Platform gateway.

IV. RESULTS
In this section, a sequence diagram is used to describe the operation of the proposed architecture. We also present the performance evaluation results for the four domains of the proposed architecture. The application-level latency is then compared with respect to each communication protocol by varying the payload sizes.

A. SEQUENCE OF OPERATING TASKS
The sequence of the operating tasks for the proposed architecture is shown in Fig. 6. The customer in the user domain can request the monitoring or response data to set the initial configuration of the OPC UA synergy platform. The cloud service domain includes two cloud servers: one for the initial configuration and the other for controlling/monitoring the industrial data. As shown in Fig. 6, the process (A-D) ranged from the user domain to the sensing & controlling domain, especially for the initial configuration of the first cloud, namely "Factory Configuration Cloud1." This server can manage the configuration (e.g., message speed, period, and IP address of each industrial device) of the OPC UA synergy platform. "The factory configuration cloud1" is asynchronously processed through the HTTP between the user and cloud service domains, whereas the OPC UA PubSub  Fig. 6 (C and D). The configure latency time depicted in Fig. 6 was obtained by summing the difference between (A) and (B), and that between (C) and (D). Fig. 6 illustrates (E-J) that the monitoring latency ranged from the user domain to the device domain, and that the monitoring/controlling data of the second cloud (Factory Monitoring/Controlling Cloud2) were processed. In this process, the customer receives the monitoring data between the cloud service and the sensing & controlling domains via the HTTP and OPC UA PubSub pattern. As shown in Fig. 6 (G)-(J), the OPC UA PubSub server receives the industrial dataset from the device domain and converts it into the AMQP dataset, which is sent to the AMQP broker. When this dataset reaches the AMQP queue, the AMQP broker transmits the dataset to the subscriber (Cloud2 server). When the device domain contains additional industrial equipment, UADP PubSub is added, as shown in Fig. 6 (J), and data are automatically published to the multicasting band. In this process, Cloud1 provides configuration service for the PubSub model, whereas Cloud2 monitors the transmission of a large number of messages and guarantees the interconnection of the end-devices. The total monitoring latency time, shown in Fig. 6, was obtained by summing the difference between (E) and (F), that between (G) and (H), and the multicasting publishing delays (I) and (J).

B. DATA LATENCY IN THE PROPOSED ARCHITECTURE
For the operation sequence diagram (Fig. 6), the target latency protocols and measuring range of each domain are shown in Table 1.
The table presents four measuring targets, including each main protocol of the domain: the HTTP protocol between the user and cloud service domains, BP based on the OPC UA client/server model, AMQP based on the OPC UA PubSub model between the cloud service and sensing & controlling domains, and the OPC UA PubSub model of UADP between the sensing & controlling and device domains.
In the case of traffic generation, we implemented a user application program that periodically transmits a packet with a transmission/reception cycle of 10ms and a payload size of 256 to 16384 bytes. The user application program was implemented using open62541, which is an open-source resource for implementing OPC UA, and AMQP Stack of Rabbitmq project and HTTP Stack.
The Wireshark measurement tool was used to compare the latency at the receiver side. For every conducted experiment, each message transmission/reception period of the four-domain was 10 ms, and the payload size ranged from 256 to 16384 bytes. This latency measurement experiment was conducted ten times and gathered from a minimum of 5872 packets to a maximum of 11168 packets during a halfminute. Fig. 7 illustrates the measurement results of applicationlevel protocol latency, which is the key result obtained from Table 2. The HTTP browser from the user domain to the Factory Monitoring/Controlling Cloud2 send the message request through the internet and vice versa; Fig. 7(a) depicts the round-trip time with HTTP latency between User domain and the configuration cloud1 server; this maximum latency time had a delay of 37.97 ms with a mean time of 11.90 ms at 16384 bytes, and the retransmission of HTTP was measured a maximum of 48 times at 16384 kb by Wireshark. HTTP exhibits high reliability communication using retransmission when data are lost during transmission, or a problem occurs with the ACK value [34]. However, this retransmission has a significant impact on latency and occurs frequently as the payload value increases, which also results in a large average delay (Fig. 7a); thus, the latency result also demonstrates that among all TCP protocols, HTTP is most likely to be affected by payload and has the slowest response time. Fig. 7(b) illustrates the latency time for the AMQP of the OPC UA PubSub model, indicating a minor effect on payload size compared with HTTP. Similarly, AMQP exhibited less fluctuating delay as the payload size increased; this protocol had a maximum latency of 3.85 ms and an average time of 3.37 ms at 16384 bytes. Fig. 7(c) depicts the RTT of BP based on the OPC UA client/server model, which exhibited the most monotonic and fastest response time compared with the other TCP protocols. This protocol had a maximum latency of 2.15 ms and an average time of 1.91 ms. In TCP networks, the maximum value of the TCP bandwidth is guaranteed when the Receive Windows Size (RWND) and Transmission Windows Size (TWND) are the same [35]; when these sizes differ, the delay time affects the maximum bandwidth and creates latency. Meanwhile, the TWND size in this experiment was fixed because it does not change the sender buffer size, whereas the RWND size depends on the windows scale option adjusted by the receiver. Likewise, the VOLUME 4, 2016   Fig. 7 three protocols (HTTP, AMQP, and BP) of TCP applications shown in Fig. 7 exhibited application-level delays in all TCP measurements because of the different RWND and TWND sizes. The UDP application had a negligible effect except for the initial fluctuation times required for the address resolution in the IGMP switch, as shown in Fig. 7(d). Fig. 7(d) illustrates the One-Way Delay (OWD) [36] from UADP of the OPC UA PubSub model. Unlike a TCP network, UADP had minimal influence on latency regardless of the payload size and was only affected by the transmission cycle of PubSub. This protocol had a maximum latency of 0.85 ms and an average time of 0.80 ms at 16384 bytes. Overall, UADP achieved the fastest response among all protocols; precisely, it was 45 times faster at 16384 bytes compared with the slowest HTTP, as depicted in Fig. 8. BP was 1.6 times faster at 16384 bytes compared with AMQP; On the other hand, BP was 2.5 times slower than UADP 16384 bytes. According to the experiment, UADP, based on OPC UA PubSub, was suitable for the device domain because it requires minimal delay, rapid response, and processes large amounts of data. Finally, HTTP had a relatively longer delay compared with other protocols; however, it is appropriate to be applied for user domain owing to its high reliability.

V. CONCLUSION
In this study, we proposed an integrated architecture divided into four domains that can simultaneously provide reliable internet and serve an industrial network requiring a rapid response. The OPC UA synergy platform plays an important role in integrating two different networks and was designed to ensure interoperability between the two networks and the transmission of substantial amounts of data. The proposed integrated architecture of the OPC UA synergy platform is expected to facilitate the adoption of Industry 4.0 technology, which aims to provide future autonomy for the adaptation of existing factories into smart manufactories [37].
In this study, we also studied the pick-and-place scenario, and analyzed and verified the proposed system through use cases. The application-level latency analyses demonstrate that the OPC UA protocol can ensure high performance compared with other protocols and provide a competitive service for the information model. Based on the proposed approach and the results of our experiments, the most important contribution of this study is defining the role of the industrial system as four distributed domains (from user to end-device) using the PubSub-model-based OPC UA synergy platform.
These contributions can improve system management efficiency by simplifying the complex life cycle of industrial systems, as well as general systems, and by enhancing their flexibility. Moreover, the proposed comprehensive architecture that integrates the internet and industrial networks in previously unexplored ways can achieve interoperability and transmission of large numbers of messages.
We also provide an outlook related to OPC UA PubSub. First, recent studies [38]- [40] have paid attention to UADP based Time Sensitive Networking (TSN) oriented for achieving real-time industrial communication. Second, the OPC UA PubSub based on 5G will be a key research topic in the future [41]. In particular, AMQP PubSub can provide strong security and ultra-reliable features when combining IIoT with 5G with the cloud domain side [42]. Therefore, we envision that future technologies could be effectively connected or integrated via the proposed integrated architecture of the OPC UA synergy platform.