# OPC-UA Agent for Legacy Programmable Logic Controllers +
## 5 Conclusions  
In this paper, we proposed the design of an OPC-UA agent. By running the OPC-UA server and client functions on a separate machine, the agent allows legacy PLCs to support an OPC-UA-based information service in a seamless and secure manner and to remotely access external OPC-UA servers. The agent is connected to the PLC using a dedicated link and maintains shared memory for specific variables in the PLC. Based on the periodically  
Figure 12: Average response times and latencies of UA_ReadList, UA_WriteList, and UA_MonitoredItemAddList according to the number of data items in a single request.  
synchronized variables, the agent serves the IEC 61131-3 information model and executes client function blocks on behalf of the PLC.  
Our agent design consists of three components running concurrently that share memory with each other: the legacy gateway, UA server, and UA client. The legacy gateway communicates with the PLC and maintains an image of certain PLC variables in a shared memory area. The UA server manages the IEC 61131-3 information model of legacy controllers and handles service requests from external UA clients. The UA client contains the OPC-UA client stack and is responsible for the RPC of function blocks. The shared memory is periodically synchronized with the PLC memory and is primarily used to read and write node values in the IEC 61131-3 information model. In our design, the shared memory also stores the state of the UA function blocks and their input and output parameters. For the RPC of OPC-UA client functions, each client function is associated with two state variables, and the agent and PLC collaboratively use the variables during RPC handshaking. It is notable that the agent allows standard OPC-UA client functions to be used in PLCs that do not support strings or complex structures. The translator in our design generates a mapping table during the conversion process and stores input values for such non-numeric parameters of OPC-UA client functions in the table. The index of the table entry is stored in the converted program and later used by the UA agent to look up argument values when the client function is called.  
Through experiments, we have validated the OPC-UA agent design and evaluated the performance of the OPC-UA server and client of the agent. We evaluated the read service of the OPC-UA server according to the number of nodes and found that the most appropriate number of nodes is about 3000 to 4000 in a single request. In the OPC-UA client, we measured the response time for 28 client APIs and observed the response times and latency depending on the number of nodes for the UA client functions frequently used for data exchange.  
In our future research, we will study how to further improve the response time and latency in consideration of legacy controllers with different hardware and software. One of the key findings is that the update cycle of shared memory has a large impact on response time when the number of data items in a read or write is small. We will study a scheme to maximize performance by automatically tuning the configurable parameters of the OPC-UA agent, including the update cycle.  
Conceptualization, S.-Y.L. and M.S.; methodology, M.S.; software, S.-Y.L.; validation, S.-Y.L.; writing--original draft preparation, S.-Y.L. and M.S.; writing--review and editing, M.S.; visualization, S.-Y.L.; supervision, M.S.; project administration, S.-Y.L.; funding acquisition, M.S. All authors have read and agreed to the published version of the manuscript.  
This work was supported by the 2021 Research Fund of the University of Seoul.  
Not applicable.  
The authors declare no conflict of interest.