Cloud-enabled Automation Systems using OPC UA

HAUPTBEITRAG | AUTOMATION 2014

Cloud-enabled Automation Systems using OPC UA Extension and Evaluation of Communication in OPC UA

Emerging applications like smart grids and the Internet of Things pose new challenges to industrial systems. A drawback of OPC UA in the context of cloud-based applications are its client-server based communication concept and challenges due to firewalls, proxies, dynamic IP addresses, NATs and client-lookup strategies. Our aim is to interleave OPC UA with web and cloud technologies. We extended the communication concept of OPC UA and provide an evaluation of various protocols that serve as an additional transport layer underneath OPC UA. KEYWORDS OPC UA / Automation / Cloud / Web technologies / XMPP / WebSockets Automationssysteme in der Cloud auf der Basis von OPC UA – Erweiterung und Analyse der Kommunikation in OPC UA Neuartige Anwendungen wie Smart Grids und Internet-of-Things stellen industrielle Steuerungssysteme vor neue Herausforderungen wie das Zusammenspiel aus dem Client-Server basierten Konzept von OPC UA und Firewalls, NATs, dynamischen IP-Adressen, Client-Lookup Strategien und Proxies. In dieser Arbeit wurde das Kommunikationskonzept von OPC UA erweitert und mit Webtechnologien wie XMPP und WebSockets verknüpft, um eine Anbindung von OPC UA basierten Systemen an die Cloud zu ermöglichen. Die Anwendbarkeit und Leistungsfähigkeit wurde anhand einer prototypischen Implementierung betrachtet. SCHLAGWÖRTER OPC UA / Automation / Cloud / Webtechnologien / XMPP / WebSockets

34

atp edition 7-8 / 2014

JOHANNES SCHMITT, THOMAS GOLDSCHMIDT, PHILIPP VORST, ABB Forschungszentrum

T

he targeted scenario focuses on automation systems where an application (or service) in the cloud has to communicate and interact with field devices on a site (for example a building or plant). With “the cloud” we denote a data centre with infrastructure for cloud computing [6], connected to the Internet or a private network. One or more of the following exemplary applications can be assumed: Remote control: As long as requirements like delay constraints and reliability are met, a remote logic in the cloud can be used to control elements on site. The advantages of a cloud-based approach are the global view of aggregating the information of multiple sites and virtually unlimited CPU power based on scalable infrastructure. Another benefit is the easy integration of mobile devices like smartphones. Cloud historian: A data historian in the cloud is of special interest when a virtually infinite amount of data should be stored and/or data should be stored securely in a remote location because of (legal) data backup requirements. Service platform: The cloud type “Platform as a Service” (PaaS) provides a modular software concept and common interfaces as a basis for additional services, to obtain an extensible system architecture. The advantage of a cloud is the flexibility to provide virtually unlimited resources for the services which process the data obtained from the devices.

OPC UA defines a meta-data model and interfaces to the data model. Using an OPC UA based communication between the cloud and a site provides full access to the information of the OPC UA server(s) at the site. Without any media breach like mapping or protocol conversion, a cloud application can make use of the functionality of the OPC UA server on the site. As OPC UA is powerful in terms of extensibility of its data model and semantic self-description of the information, this approach is flexible and future proof.

A cloud application needs an OPC UA client in order to access the data provided by an OPC UA server deployed locally at a site or building. As a major extension to its predecessor OPC, OPC UA provides binary or XMLencoded messages over TCP or HTTP(S) [1]. This makes OPC UA routable, platform-independent and much more flexible – especially for Internet-based or cloud-based applications [2]. Since OPC UA uses a client-server based communication concept, the client starts the connection to the server (“A” in Figure 1). Following this communication principle, OPC UA has to cope with fi rewalls, dynamic IP-addresses, NATs and client-lookup strategies. The common approach of the protocols XMPP and WebSockets is to establish the connection from the local-side and re-use this existing connection from the cloud-side in order to access services [4] behind fi rewalls (as depicted in Figure 1 with “B”). While XMPP follows an asynchronous message-queue based principle using an intermediate message broker, WebSockets are employed for synchronous direct calls. 1. CONCEPT / PROTOTYPE DESIGN We have extended the client-server principle of the OPC UA stack by mechanisms which allow for bidirectional communication. This extension enables a cloud to local-side communication over a previously established local to cloud-side connection (as depicted in Figure 1 with “B”). As another extension we developed a prototype for an “OPC UA proxy server” which provides transparent access (for example for other cloud applications) to multiple client-side OPC UA servers through the cloud-side OPC UA client (comparable to the concept of an aggregating server [3], but without replication). This proxy server concept aims to provide a central point for communication in the cloud for both the OPC UA servers connecting to the cloud and the cloud applications requiring access to the information on the OPC UA servers. The prototyped OPC UA proxy server shown in Figure 2 provides multiple mechanisms to manage the atp edition 7-8 / 2014

35

HAUPTBEITRAG | AUTOMATION 2014

access to remote OPC UA servers as they are commonly available for other cloud services. These mechanisms comprise connection management, remote node management, subscription and alarm/event management as well as access management. However for this work we will further focus on the aspects of communication towards the local infrastructure. 1.1 Integration of WebSockets For our implementation of the WebSocket protocol we have used the Jetty-WebSocket (Version 8) libraries – as they provide both an API for a WebSocket server as well as for a WebSocket client (which is not always included, as the client part is typically JavaScript based). Our WebSocket implementation is designed to allow bidirectional communication. Therefore, a common element in our implementation manages and holds all established WebSocket connections for later use. A flag in the WebSocket settings decides how to handle the WebSocket connection: Server-Flag: Opens a WebSocket server at the given URL Client-Flag: If no connection to the given URL exists, the WebSocket tries periodically to connect to the WebSocket server at the given URL. This approach makes it possible to decide whether the OPC UA client should be the WebSocket server and the OPC UA server the WebSocket client or vice versa. In addition, an OPC UA client can re-use an existing connection. Using this concept it is possible to use the same connection for an OPC UA server and for an OPC UA client on the same machine. This is usefulin cloud technologies, where a cloud-application can be bound to only one port or on a smartphone providing its sensors as nodes within a built-in OPC UA server and at the same time using the connection to the OPC UA client for a connection to the proxy server. 1.2 Integration of XMPP For the integration of the XMPP protocol, one of the most popular implementations of XMPP was used: Smack from Ignite Realtime (http://www.igniterealtime.org). The XMPP server which was used later as broker to setup the connection between multiple clients – called Openfire - is also from Ignite Realtime. Some embedded and lightweight implementations of XMPP exist – which makes it especially interesting for applications in the area of Internet of Things (IoT) [5] and for OPC UA as the consortium announced on the roadmap for 2015. Both the OPC UA server and the OPC UA client act as XMPP client – they initially create an XMPP con-

36

atp edition 7-8 / 2014

nection to the XMPP server. The transport protocol in Smack is based on a modular concept. Here two modules were integrated and used: org.jivesoftware.smack.XMPPConnection: this is the default long-lived XMPP specific TCP protocol. This connection type has the ability to enable the SecurityMode (using SSL “XMPP-SSL” or another, XMPP-specific security mechanism “XMPP-SEC”). org.jivesoftware.smack.BOSHConnection: this module provides a bidirectional data transport based on (long living) HTTP requests. While using the “XMPP-BOSH” based transport, an HTTP proxy can be configured and enables bidirectional communication through an enterprise HTTP proxy. 2. PERFORMANCE EVALUATION As a proof-of-concept and for a performance analysis, we integrated and tested our system on local machines, private clouds, embedded devices, mobile devices and public clouds. The analysis comprises a comparison of traditional OPC UA over TCP and HTTPS with the new approaches of OPC UA over XMPP and WebSockets. In addition, we also analysed the impact of parallel requests, different security configurations and also the usage of XMPP over BOSH which allows traversing HTTP proxies. All the following results show the delay for a requestresponse scenario reading a node value at the OPC UA server– this means it represents the sum of the delays for message encoding, message processing and transport on the client and the server. Unless mentioned otherwise, the results show the average delays per requestresponse observed over 10 000 test-runs with one thread. 2.1 Protocol overhead comparison Both new approaches, XMPP and WebSockets wrap the OPC UA encoded data as payload in their protocol. However they use and provide various mechanisms for communication and transport management. Figure 3 shows as comparison of the different transport means on a local machine, focusing on the plain protocol overhead. OPC.TCP (SEC) with a delay of about 0.45  ms can be seen as a reference value which will typically be applied in OPC UA based systems. The OPC. TCP (SEC) uses its own mechanisms for signing and encrypting the data (similar to but not based on SSL). HTTPS denotes the other OPC UA transport protocol included in the official OPC UA stack. It uses regular HTTP over SSL. Like typical HTTP based approaches, this protocol also uses a new connection per request and base64 for encoding, which makes it slower than OPC.TCP. Pure HTTP was not tested, because OPC UA

FIGURE 1: Old (A) and new (B) communication concept in OPC UA FIGURE 3: Delay for an OPC UA request-response

FIGURE 2: OPC UA proxy server FIGURE 4: Average delay on Raspberry and Android

uses pure HTTP only in combination with the XML encoding, which is currently not supported by the OPC UA Java stack. Typically XMPP uses also a binary TCP transport mechanism – but with the necessity to use a base64 encoding in order to wrap the binary data into an XML container. This and the additional hop over the XMPP server (on the same PC) make XMPP slower than OPC.TCP. In comparison to HTTPS this approach is faster – which may be because it re-uses previously established connections. XMPP can be used in two secure modes: XMPP-SSL uses a (deprecated) approach by applying a SSL connection to the XMPP server, while XMPP-SEC uses an XMPP internal mechanism to provide a secured transport (with endto-end encrypted body). Both approaches have a similar delay in this scenario. XMPP-BOSH uses a BOSH based transport. BOSH itself uses an HTTP-long polling approach. The communication over base64+XMPP+BOSH has the highest latency – but also the ability to work over HTTP proxies, NATs and fi rewalls. The approach using WebSockets (WS) transports the data like native OPC.TCP – but with the bidirectional

communication strategy. This results in a similar delay during the communication: The unsecure approaches need 0.25 ms WS compared to 0.21 ms OPC. TCP; the secure approach WS (SSL) is also comparable to OPC.TCP (SEC) with enabled signing and encryption mechanisms. 2.2 Platform comparison In this scenario an Android device (Samsung Galaxy Tab S2) or a Raspberry Pi was used as an example for a field device gateway on an embedded device. While the Raspberry was connected using a 1Gbit LAN, the Android device was connected over a Wi-Fi access point in the same LAN. In the case of XMPP the XMPP server was installed on the PC. The results in Figure 4 give an approximation of the expected delay: Usually the embedded device was used as the local instance (which receives requests from the PC in the role of a remote/cloud instance). In some cases also the “backward-direction” was tested (marked with “BW”) atp edition 7-8 / 2014

37

HAUPTBEITRAG | AUTOMATION 2014

FIGURE 5: OPC UA communication with the cloud

FIGURE 7: Response time for a prototype of a Soft-PLC in a private cloud

– this means in these cases the embedded device sends requests to the PC. OPC.TCP (SEC) on Raspberry was used in Basic128Rsa15 mode – instead of the default Basic256 mode, which did not work. The test labelled with “OPC.TCP Raspberry (local)” shows the performance if the requests are sent only within the Raspberry (local-only requests with no network communication involved / similar to the local PC scenario). HTTPS

FIGURE 6: Soft-PLC in the cloud controlling a simulated device on the site

on Raspberry did not seem to work properly as it showed latencies of up to 4.7 seconds. In the reverse direction it worked, but also with relatively high latencies around 33 ms. On Android, HTTPS was excluded due to problems with overlapping namespaces with the Android SDK. The tests on Android showed similar behaviour – with a somewhat higher latency, which might be caused by the Wi-Fi connectivity.

AUTHORS

38

Dr. JOHANNES SCHMITT (born 1979) is Scientist in the group Intelligent Devices at ABB Corporate Research. His research focusses communication and especially middleware technologies for automation systems. He also investigates the use of OPC UA on embedded or mobile devices up to cloud based systems.

Dr. THOMAS GOLDSCHMIDT (born 1982) is a Principal Scientist at the ABB Corporate Research in Germany. He focuses on domain-specific language engineering and software architectures in the automation domain. Thomas holds a PhD in computer science from the Karlsruhe Institute of Technology, Germany.

ABB AG Forschungszentrum, Wallstadter Str. 59, D-68526 Ladenburg, Tel. +49 (0) 6203 71 60 08, E-Mail: [email protected]

ABB AG Forschungszentrum, Wallstadter Str. 59, D-68526 Ladenburg, Tel. +49 (0) 6203 71 61 34, E-Mail: [email protected]

atp edition 7-8 / 2014

www.atp-edition.de Jetzt bestellen!

Die Referenzklasse für die Automatisierungstechnik

2.3 Influence of Network Connection

Dr. PHILIPP VORST (born 1979) is a Senior Scientist with ABB Corporate Research in Germany. His research interests include software architecture methods with applications in automation. Philipp holds a PhD degree in computer science (mobile robotics) from the University of Tübingen, Germany. ABB AG Forschungszentrum, Wallstadter Str. 59, D-68526 Ladenburg, Tel. +49 (0) 6203 71 62 80, E-Mail: [email protected]

atp edition ist das Fachmagazin für die Automatisierungstechnik. Die Qualität der wissenschaftlichen Hauptbeiträge sichert ein strenges Peer-Review-Verfahren. Bezug zur automatisierungstechnischen Praxis nehmen außerdem die kurzen Journalbeiträge aus der Fertigungs- und Prozessautomatisierung. Sichern Sie sich jetzt diese erstklassige Lektüre! Als exklusiv ausgestattetes Heft oder als praktisches ePaper – ideal für unterwegs, auf mobilen Endgeräten oder zum Archivieren. Wählen Sie einfach das Bezugsangebot, das Ihnen zusagt: als Heft, ePaper oder Heft + ePaper!

atp edition erscheint in der DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München

In this scenario, the new extensions are used in order to communicate with an OPC UA instance in the cloud. The results in Figure 5 were obtained for 100 test runs. The fi rst test called “WebSocket LocalCloud” was conducted using a virtual machine running the cloud framework on the local PC. It shows the impact of the cloud framework itself – the delay in this case is about 1.74 ms. The second test was done using a traditional client-server connection by applying a OPC.TCP (SEC) connecting to the cloud – in this case the local instance sends requests to the OPC UA server in the cloud “backwards” (BW). Within the ABB LAN it is only possible to communicate through an HTTP proxy towards a real cloud on the Internet. This restricts the communication on XMPP based on BOSH and a Telecom WiFi Hotspot Hotspot (marked with “Wlan”). For this reason the third test which applies the WebSocket technique is also only possible over Wi-Fi. The delay is similar to the basic OPC.TCP (SEC) approach – but in this case it was communicated from the cloud towards the local instance. The fourth test uses XMPP (without BOSH) which was also only possible over Wi-Fi. Both XMPP tests used the XMPP server in the cloud and the OPC UA instances locally on the PC – this means one requestresponse travels to the cloud and back again ( marked with “2 way”). The delay can be assumed to be halved if the requesting entity wwere placed in the cloud. The last test shows the only approach which worked within the ABB network together with its HTTP proxy and which enables a cloud-to-local instance

HAUPTBEITRAG | AUTOMATION 2014

communication backwards over the local instance–tocloud connection. With this approach it is possible to connect an OPC UA proxy server in a cloud with an OPC UA server in the ABB LAN. 2.4 Soft-PLC in a Private Cloud As a proof-of-concept and to round up the scenario of an “automation system in the cloud”, a Soft-PLC service was instantiated in the cloud controlling a (simulated) device on the site. In this setup, the communication between the Soft-PLC and the proxy server was using a Message Queue [7] (as shown in Figure 6 with “MQ”) in order to use an asynchronous and loosely coupled communication to scale up the instances of running Soft-PLCs in the cloud if needed. The Soft-PLC subscribes using OPC UA over the proxy server at the simulated device in order to get notification about status changes of the device via MQ. As a reaction, the Soft-PLC sends back a control command via MQ and OPC UA over WebSockets to the simulated device. This setup uses a private cloud approach with a cloud instance hosted on an ABB server in Sweden and connected via VPN over the Internet to the ABB research labs in Germany. The delay between a status change of the device and a reaction in the form of a control command was measured. Figure 7 shows the results for 10 000 test runs as a histogram. In most cases the response time was around 75-80 ms with a few outliers around 300-400 ms.

XMPP-BOSH where packet losses at about 3 parallel requests can be observed. Additional results also show that by re-using established connections the latency can be reduced – for example while HTTPs takes around 2 ms per request, WebSockets over SSL take only about 0.6 ms. Also, the delay of synchronous calls over XMPP and the indirection through the message broker can be relatively low, so that XMPP can be considered as an alternative to WebSockets. XMPP also provides additional features such as asynchronous calls and multicast which could be interesting for future extensions. CONCLUSIONS The proof of concept shows that it is possible to engineer automation systems for the cloud by using an OPC UA based architecture in combination with extended transport mechanisms. With this approach it is also possible to instantiate “classic” OPC UA connections from the proxy server in the cloud to OPC UA servers on distributed sites – using a stack without WebSocket support but at the expense of having to manually address all connection issues like fi rewalls, NAT, etc. Because the network connection to the cloud typically introduces the largest portion of communication delay, a fundamental question should be considered before enabling an automation system for the cloud: Can the constraints for communication delays be met by the network link to the cloud infrastructure? MANUSKRIPTEINGANG 26.06.2014

2.5 Evaluation results The goal of the presented performance evaluation and some additional tests in combination with embedded systems and clouds was to give a proof of concept and to establish an order of magnitude for the average delay. This makes it possible to explore the limits of current technical solutions for industrial applications and serves practitioners as a reference so that other applications can be compared to our performance measurement results. The additional overhead for WebSockets/XMPP compared to OPC.TCP is in most cases up to 5ms; the average delay for one request on an embedded device in the local network is between 5 and 15 ms. But the basic delay for the communication over the Internet to a cloud instance has to be taken into account in any case – for example the same request towards a system in the (Amazon) cloud takes about 200 ms. The delay might depend on various factors like the cloud provider, the physical distance, the DSL provider, the load of the cloud instance, and the time of day – usually this value is between 50 and 350 ms. In all cases no message losses were observed, which can be seen as an indicator for a robust communication. Other tests taking also the number of parallel requests into account showed that most approaches are also able to handle multitude parallel requests (tested up to 100) with almost linear increase in the delays – except for

40

atp edition 7-8 / 2014

Im Peer-Review-Verfahren begutachtet

REFERENCES [1] National Instruments: Why OPC UA Matters. http://www.ni.com/white-paper/13843/en/ [2] OPC Training Institute: OPC UA: An End-User’s Perspective. http://www.controlglobal.com/assets/Media/Marketing Manager/ 081121_OPC_EndUsersPerspective.pdf [3] Leitner, S., Mahnke, W.: OPC UA – Service Oriented Architecture for Industrial Applications, 2006 [4] Lubbers, Greco: HTML5 Web Sockets: A Quantum Leap in Scalability for the Web. https://www.websocket.org/quantum.html [5] Kirsche, M., Klauck, R.: Unify to Bridge Gaps: Bridging XMPP into the Internet of Things, PerCoM 2012 [6] NIST Special Publication 500-292: NIST Cloud Computing Reference Architecture, September 2011 [7] Mahesh-Kumar, M., Approach for Deploying, Executing and Scaling an IEC6113-3-based Soft-PLC Component on a Multi-tenant Industrial Cloud System for the Automation Domain, Master Thesis TU-Dortmund, 2014

Process Control Systems Engineering DIV Deutscher Industrieverlag GmbH, Arnulfstr. 124, 80636 München

Process Control Systems (PCS) are distributed control systems (DCS) that are specialized to meet specific requirements of the process industries. The text book focuses on PCS engineering basics that are common to different domains of the process industries. It relates to an experimental research plant which serves for the exploration of the interaction between process modularization and process automation methods. This permits to capture features of highly specialized and integrated mono-product plants as well as application areas which are dominated by locally standardized general-purpose apparatus and multi-product schemes. While the text book’s theory is applicable for all PCS of different suppliers, the examples refer to Siemens’ control system PCS 7. Focusing on a single PCS enables readers to use the book in basic lectures on PCS engineering as well as in computer lab courses, allowing students to gain hands-on experience. Editor: Leon Urbas 1st edition 2012 204 pages, content in English, 165 x 230 mm, hardcover ISBN: 978-3-8356-3198-4 Price € 49,80

www.di-verlag.de Order now!

KNOWLEDGE FORTHE FUTURE

Order now by fax: +49 201 / 820 02-34 or send in |aArnulfstr. letter 124 | 80636 München Deutscher Industrieverlag GmbH Yes, I place a firm order for the technical book. Please send

Company/Institution

— copies of the Process Control Systems Engineering 1st edition 2012 (ISBN: 978-3-8356-3198-4) at the price of € 49,80 (plus postage and packing)

First name, surname of recipient (department or person)

Street/P.O. Box, No.

Country, Postalcode, Town

reply / Antwort Vulkan-Verlag GmbH Versandbuchhandlung Postfach 10 39 62 45039 Essen GERMANY

Phone

Fax

E-Mail

Line of business Please note: According to German law this request may be withdrawn within 14 days after order date in writing to Vulkan Verlag GmbH, Versandbuchhandlung, Postfach 10 39 62, 45039 essen, Germany. In order to accomplish your request and for communication purposes your personal data are being recorded and stored. It is approved that this data may also be used in commercial ways by mail, by phone, by fax, by email, none. this approval may be withdrawn at any time.

Date, signature

PAPCSE2014