Service-Oriented Architecture for the Autoconfiguration of Real-Time Ethernet Systems Lars D¨urkop, Jahanzaib Imtiaz, Henning Trsek inIT - Institute Industrial IT OWL University of Applied Sciences D-32657 Lemgo {lars.duerkop, jahanzaib.imtiaz, henning.trsek}@hs-owl.de J¨urgen Jasperneite Fraunhofer IOSB-INA Application Center Industrial Automation D-32657 Lemgo, Germany
[email protected] Abstract: In the context of flexible and agile manufacturing systems, the autoconfiguration capability of devices is very important. Besides other advantages, a Service-Oriented Architecture (SOA) could support the autoconfiguration by offering several interesting features. The Devices Profile for Web Services and OPC Unified Architecture are promising candidates for a future deployment in industrial automation, due to their specific characteristics. However, resource contstraint embedded devices, such as low cost field devices, face particular challenges for an SOA implementation in terms of required memory resources. In this work both technologies are introduced and implemented on embedded devices. The focus is put on autoconfiguration of real-time Ethernets. A comparison and analysis of both solutions, using the discovery process as an example, show their main differences. Finally, the advantages and drawbacks of both approaches are discussed based on the previous findings.
1
Introduction
Due to shorter product life-cycles and changing market conditions current production systems must become more flexible. Today the reconfiguration of a production process requires many manual configuration steps which lead to cost intensive downtimes and sometimes even to failures. This work is aiming at enabling flexible and adaptable production processes by means of devices which can be attached to an industrial network and start functioning without manual interventions. This will enable a Plug and Produce (PnP) capability and requires adaptations to industrial devices at multiple layers. Real-time Ethernet (RTE) systems are increasingly used in industrial automation. On the one hand to meet the performance requirements of industrial applications and on the other hand to provide a common infrastructure from the factory floor up to the enterprise resource planning (ERP) level [Fel05]. All RTEs have in common that manual configuration efforts are needed before the system can start its operation. For example, the network configuration must always be supplied manually to an engineering tool which configures all devices of the RTE. In contrast to this, a PnP enabled device must discover available functionalities of other devices automatically and the data exchange with other devices must be autonomously negotiated. For interoperability reasons, i. e. devices of multiple vendors in one system, it is necessary to offer standardized methods for a consistent discovery and the exchange of configuration information. The mentioned requirements can be met by a ServiceOriented Architecture (SOA) which is a major focus of interest within factory automation industry from the device level to the high level IT [CJdOC10]. Devices in an SOA offer their functionalities/information as services usable by other devices. Currently, the main focus is put on two standardized technologies to support the application of SOA at device level, the Device Profile for Web Services (DPWS) and the OPC Unified Architecture (OPC UA) [CJdOC10]. The authors of [CJdOC10] provide an overview of both approaches. Their strengths and weaknesses are identified with respect to the industrial requirements at device level, e. g. differences in the discovery process. An overall assessment states that no technology is covering all requirements and a convergence approach between both technologies is proposed. Furthermore, the memory footprint required by current OPC UA implementations is identified as being too high for small low cost devices. In [CCBJ11] an SOA ecosystem is presented along with a prototypical implementation based on DPWS. The interoperability of DPWS and OPC UA is
addressed in [ILL11]. The combined solution approach shows an interoperable architecture for a monitoring application. The authors of [BHJ11] developed a convergence architecture for OPC UA and DPWS, which mainly deals with a cross domain data model. However, none of the existing works considered the requirement of having very resource constraint devices. A comparison and evaluation of implementations for embedded systems and examples for concrete services are currently missing. Hence, the presented work focuses on both technologies implementing the autoconfiguration of RTEs as a specific service and further investigates their pros and cons with respect to autoconfiguration as a service. In addition to this, a special focus was put on memory footprint for the OPC UA implementation in order to allow a deployment in resource constraint devices on the factory floor. The paper is organized as follows: section 2 details two of the most promising middleware SOA technologies, DPWS and OPC UA. In section 3 the proposed autoconfiguration steps are described, whereas chapter 4 details the implementation of the discovery procedure using DPWS and OPC UA for resource limited devices. It also provides results and their discussion as part of this comparative study. The paper is concluded in section 5.
2
SOA based Middleware Technologies
DPWS and OPC UA are two promising candidates for an SOA based middleware for industrial automation. They are briefly introduced in this section and their most relevant features are highlighted. Particularly, the services for device discovery and for acquiring the device description are considered, because of their central role during the autoconfiguration of a device.
2.1
Devices Profile for Web Services
DPWS [OAS] is an adapted specification of Web Services for embedded devices. The device model of DPWS is based on a client/server architecture. A server is a device which hosts several services representing functionalities of the device. The services can be invoked by the clients. A device can contain a server and a client at the same time. Additionally DPWS defines some mandatory services for all devices. An example is the service WS-Discovery. It defines mechanisms for the automatic discovery of DPWS-enabled devices. The interface to the services of a device is described with the Web Services Description Language (WSDL). To invoke a device-specific service the server’s WSDL file must be known to the client. The communication in DPWS is based on existing standards. The protocol stack is part of Figure 1. A DPWS message is composed as an XML-based SOAP message [W3C12] which is again encapsulated in HTTP and transported by UDP or TCP.
2.2
OPC Unified Architecture
OPC UA [EM11] is a newly emerged industrial middleware technology, which is fundamentally about data modelling and transport. It uses object-oriented techniques, including type hierarchies and inheritance, to model information. The OPC UA address space allows information to be connected in various ways. OPC UA servers can be varied and scaled in their scope of functions, size, performance and the platforms they support. For embedded systems with limited memory capacities (such as low end devices like sensors and actuators), slim OPC UA servers with a small set of UA services can be implemented, e. g. only data access and minimal security. At the company level, in contrast, where memory resources are not that important, very powerful OPC UA servers can be used with the full functionality. To promote interoperability, OPC UA defines subsets of offered functionalities, referred to as profiles, to which servers may claim conformance. Clients can then discover the profiles of a server, and tailor their interactions with that server based on the profiles. Furthermore, OPC UA is a platform-independent industrial standard through which various kinds of systems and devices can communicate by sending messages between clients and servers over various types of networks. OPC UA defines sets of services that servers may provide, and individual servers specify to clients what service sets they support. Information is conveyed using OPC UA-defined and vendor-defined data types and servers define object models that clients can dynamically discover. Through the address space, clients can query the
server for the metadata that describes the format of the data. In many cases, clients with no pre-programmed knowledge of the data formats will be able to determine the formats at runtime and properly utilize the data. OPC UA can be mapped onto a variety of communication protocols, as shown in Figure 1, and data can be encoded in various ways to trade off portability and efficiency. This paper considered the TCP binary as a transport protocol for UA communication. OPC UA is a very promising approach being able to abstract the physical communication technology and software applications to offer a generic communication interface. Furthermore, the standard has been widely adapted by industrial automation device vendors and system manufacturers. Application
User-Defined Services
Real-time Data
DPWS SOAP WS-Discovery / WS-Transfer HTTP
OPC UA
RT Protocol Stack
TCP / UDP IP Hardware Layer
Figure 1: Communication stack of controller & devices.
3
Autoconfiguration
Approaches for autoconfiguration of RTEs are presented in [RKH+ 08] and [DTJW12]. While [RKH+ 08] is using methods of a specific RTE to achieve autoconfiguration, [DTJW12] is using DPWS to discover devices and gather information about them. The latter is extended in this work to compare DPWS with OPC UA in the context of autoconfiguration of RTEs. The general scenario consists of field devices (referred to as devices in the following) which offer functionalities as services and exchange their process data in real-time over an RTE. For example a temperature sensor can offer the service GetTemperature. When another device is invoking that service the actual exchange of the temperature values takes place over the RTE. An RTE network needs at least one controller which configures all connected devices. In the conventional way the controller gets its knowledge about the other devices manually during the engineering phase before start up. A network topology is created in an engineering tool and the specific parameters of the devices are configured. Afterwards the engineering tool compiles the collected information and downloads it to the controller. These steps have to be repeated every time when a new device is added or removed. In an autoconfiguration scenario the controller must gather all necessary information by itself without manual interventions. The proposed architecture of such a controller is shown in Figure 1. The controller contains a DPWS client, an OPC UA client and an embedded RTE stack. The clients are used in the discovery process which is described in chapter 4. As application, an RTE configuration service is implemented. This service collects the information from the DPWS/OPC UA client and configures the embedded RTE controller as described in [DTJW12]. The steps involved in this process are shown in Figure 2. In phase 1 a device is newly connected to the network. To ensure IP connectivity it must get an IP address. This could be done by a DHCP server or an RTE specific service. In phase 2 the discovery process takes place. In this phase the controller is informed that a new device is connected. The controller also needs RTE specific information from the device for the autoconfiguration phase. This information is described in a device description file (DDF) which belongs to each device. During the discovery the contents of the DDF must be made available to the RTE configuration service. Therefore the device offers an URL, which could refer to the device vendors database, hosted on some web-server, from where the controller can download the DDF which is done in phase 3. In phase 4 the RTE configuration service parses the received file. Afterwards it configures the connected devices and the embedded RTE controller accordingly. Thus, the RTE configuration service takes over the engineering tool responsibilities of traditional solutions.
Controller
IP allocation service
Device
DDF Server
IO-Device connected Requests IP-Address
1
Assigns IP-Address
Discovery
Controller retrieves Device Description File
2
3
Controller parses Device Description File 4 Controller sets device parameters and configures RTE
Figure 2: The autoconfiguration procedure.
4
Discovery of Devices
In this section the discovery process is described for two different solutions, DPWS and OPC UA, and the utilized resources of both technologies are analyzed. As mentioned in chapter 1 an essential function of a SOA based middleware is to enable the discovery of devices and to exchange information about them in a vendor neutral way to enable the autoconfiguration of industrial automation systems. The following subsections analyze and compare DPWS and OPC UA with respect to the complexity of the discovery process and the actual costs of implementation. The clients of both techniques are implemented on a PC based controller. Because resource usage is uncritical on the PC, the following considerations are limited to the devices of the autoconfiguration environment. The communication stack described in Figure 1, shows that the OPC UA protocol stack is leaner than the DPWS stack. For both technologies implementation cost, protocol overhead and network traffic are analyzed using Profinet IO (PN) [PNO10a], [PNO10b] as an example RTE network.
4.1
Discovery using DPWS
Searching and locating devices is done by the multicast protocol WS-Discovery. A device announces its presence by Hello messages to a specified WS-Discovery multicast address. The metadata of that device can be retrieved by the WS-Transfer protocol. The metadata is defined in the DPWS standard and includes manufacturer name, model name, manufacturer URL and other information. On top of the DPWS protocol stack user-specific services can be defined. The messages exchanged between controller and device during the discovery are illustrated in Figure 3. The steps are basically an implementation of phase 2 in Figure 2. Step 1: After a device got an IP-Address, it sends a Hello message via UDP to the WS-Discovery multicast IP-Address 239.255.255.250. This messages contains mainly DPWS addressing information and its size is 1088 bytes. After receiving this message the controller is aware of the presence of a new device. The controller opens a TCP channel with the TCP 3-way handshake (180 bytes) and sends a unicast Get message to the new device (1088 bytes). This message is used to request metadata. The device answers with a Get-Response (2358 bytes) which contains the metadata. Afterwards the TCP connection is closed (114 bytes) by the controller. Step 2: Since the devices offer their capabilities in form of services, the GetDDFUrl service is defined as one of
Controller
Device Multicast WS-Discovery Hello TCP 3-Way Handshake
STEP 1 Discovery
Unicast WS-Transfer Get Unicast WS-Transfer Get-Response Closing TCP channel TCP 3-Way Handshake GetDDFUrl request
STEP 2 Retrieve DDF
GetDDFUrl response Closing TCP channel
Figure 3: Device discovery using DPWS
these services. The controller can retrieve the URL of the needed DDF by invoking this service. After opening the TCP channel (180 bytes) the service request is sent (1130 bytes). The device’s GetDDFUrl service replies with the appropriate URL (1716 bytes). Afterwards the TCP channel is closed (114 bytes). Implementation Open source implementations of DPWS are available in the projects WS4D [WS412] and SOA4D [SOA12]. In our solution approach SOA4D is used, because its portability to new operating systems (OS). The architecture of the DPWS evaluation platform is part of Figure 6. It is based on the Tiger Profinet solution (TPS-1) [KS12]. The TPS-1 provides two Ethernet interfaces and all Profinet related protocol handling is implemented in hardware. The corresponding driver is based on the real-time OS ’embOS’. The SOA4D package consists of the proper DPWS core and a hardware abstraction layer (HAL). The HAL encapsulates all functions which access the OS or the TCP/IP stack which makes it relatively easy to port SOA4D to embOS. Due to the complexity of SOA4D a full functional TCP/IP stack is needed. The same applies to all other DPWS implementations. In this approach the embOS-IP stack is used. DPWS Device Software Layer Application DPWS-Stack: SOA4D embOS
SOA4D HAL embOS-IP Tiger Driver Tiger Hardware Layer Profinet
Standard Ethernet
Figure 4: Implementation architecture of DPWS at TPS-1 evaluation platform
4.2
Discovery using OPC UA
The OPC UA discovery of a newly plugged-in device can be divided into three main steps, all OPC UA messages are request/response pairs. The steps are illustrated in Figure 5.
Controller
UA Discovery Server
Device
TCP 3-Way Handshake Hello/Ack Open Secure Channel
STEP 1 Server-Registration
RegisterServer Close Secure Channel
TCP 3-Way Handshake Hello/Ack Open Secure Channel
STEP 2 Server-Discovery
FindServers Close Secure Channel
TCP 3-Way Handshake Hello/Ack Open Secure Channel GetEndPoints STEP 3 Reference to Device Description
CreateSession ActivateSession Read (DeviceID, Type, ConfigURL) CloseSession Close Secure Channel
Figure 5: Device discovery using OPC UA
Step 1: The built-in OPC UA server in the device will first register itself to a centralized OPC UA Discovery Server at a well-known location in the network. The registration involves protocol service calls with certain network data, such as: • TCP 3-Way handshake (180 bytes) • OPC UA handshake (hello/Ack) (200 bytes) • Establishing a secure channel (380 bytes) • Calling the RegisterServer service of the Discovery Server providing the server name and service endpoint information (400 bytes) • Closing the secure channel and terminating the TCP connection (111 bytes, 238 bytes) A total number of 15 messages are involved in this step. They collectively consist of 1500 bytes. This step is periodically repeated for status updates. Step 2: An OPC UA client at the controller will keep looking for new servers and the status of existing servers from that centralized OPC UA Discovery Server. The only change in addition to step 1 is calling FindServers instead of RegisterServer, rest of the network messages are comparable. Step 3: Once the OPC UA client at the controller is aware of the presence of a new device, it directly connects to the relevant OPC UA server at this device using the discovered server credentials. Since the controller needs the device description file to configure the RTE related communication relationship, the OPC UA server at the device provides a reference (URL) to this device description. The URL could be referring to the device vendor database, hosted on a web server. After opening up the secure channel, the client has to first verify the latest service definitions through GetEndpoints (1227 bytes). A session has to be created via CreateSession (2200 bytes) that exchanges some security credentials. Once the session is activated using ActivateSession (300 bytes), the Read service (300 bytes) can be invoked to actually learn the DeviceID, its Type and ConfigURL. After reading the device information the session must be closed (225 bytes), as well as the secure channel. The total number of messages involved in this step are 23. Altogether the messages consist of 5352 bytes.
Implementation OPC UA offers scalable feature sets that could be tailored according to an application demand. As a matter of fact it is now possible to realize OPC-compatible communication to the chip level. To realize the OPC UA server, the Tiger Profinet solution (TPS-1) was chosen as well. We have extended the firmware by introducing a tailored OPC UA stack, using the binary encoding on top of a tailored TCP/IP stack. Figure 6 shows the extended Tiger firmware with an OPC UA function block. We implemented a server based on the Nano Embedded Device Server profiles of the OPC Foundation. It uses the binary transport profile and may support authentication using certificates. For the server function only 5 kBytes of data memory and 10 kBytes of program memory are needed to implement a basic GetDeviceDescription service. This service provides the basic device description that includes VendorName, DeviceType, DeviceID and ConfigURL. It is also described in Table 1. OPC UA Software Layer Application OPC UA stack embOS
Tailored TCP/IP stack Tiger Driver Tiger Hardware Layer Profinet
Standard Ethernet
Figure 6: Implementation architecture of OPC-UA at TPS-1 evaluation platform
4.3
Comparison results
Device discovery steps in OPC UA are fundamentally different than those in DPWS. The DPWS server broadcasts its presence to the environment, in contrary an OPC UA server has to register to a well know OPC UA discovery server that is monitored by client in order to learn the change in network components. Since the OPC UA stack is leaner than the DPWS stack, there are also differences in terms of the protocol overhead, resulting in an increased network load and processing efforts. Once the Controller gets the device’s ConfigURL, it can download the device description file via HTTP and interpret it accordingly to the DeviceID and Type parameters. The number and size of messages fairly depends on the size of the configuration file and the complexity of the PN IO device. To sum it up, 26 packets and 7968 bytes are transferred using DPWS to discover a new device and transfer its DDF URL. While in OPC UA a total of 53 packets and 8352 bytes are transferred for the same purpose. The discovery process in DPWS is much less complex than in OPC UA. However, the amount of network traffic is comparable. This is due to the mentionable protocol overhead of the DPWS protocols SOAP and HTTP. Moreoverk, OPC UA provides a stronger information meta-modelling, once the device is discovered, to access structured services. In the next step implementation efforts of both SOA approaches are compared. Typically low end IO devices are embedded systems which are very resource constraint in terms of available memory.Therefore the memory requirements of the introduced SOA solutions are analysed. The necessary memory can be divided into the program and the data memory. The program memory contains the instructions of a program. The variables are saved in the data memory. The needed sizes for each software package of the DPWS/OPC UA are shown and compared in Table 1. The off the self DPWS packages also needed user written program code for initialization and adoption to the hardware. To show a dimension of this effort, the lines of code (LOC) written for each package are also given. The LOCs do not include the unmodified source code of the packages. The comparison shows a considerable difference in the memory requirements of both approaches. As mentioned a full functional TCP/IP stack is used for SOA4D. For OPC UA we implemented a TCP/IP stack with limited functions. As a result the program memory needed for the TCP/IP stack of SOA4D is 134 kByte larger than the one of OPC UA. Therefore the development time applied to the own stack was higher than the time
for the adoption of an existing one. Nevertheless this work has to be done only once. The same is true for the implementation of the actual SOA4D and OPC UA stacks. The SOA4D core (including HAL) needs 863 kByte more program memory. When the LOCs are compared also the implementation effort is higher for SOA4D. This is due to the adaption of SOA4D for the OS embOS. There are existing ports for Linux and Windows. If a supported OS is used with SOA4D the implementation effort is much smaller (400 LOCs instead of 4930). Table 1: Resource usage DPWS vs. OPC UA
5
Program memory [kBytes]
Data memory [kBytes]
LOC
embOS
69
69
10
embOS-IP DPWS (SOA4D-HAL) DPWS (SOA4D)
137 113 757
20 83 225
300 4930 400
Total (DPWS)
1007
328
5630
OPC TCP/IP OPC UA
3 7
2 3
700 1400
Total (OPC UA)
10
5
2100
Conclusion
In order to be cost effective industrial devices have various resource constraints. In this work the suitability of two promising SOA based technologies (DPWS and OPC UA) for resource constrained embedded devices was investigated. These devices are typically used in automation networks as field devices where they are acting for example as sensor nodes. Furthermore, this work implements DPWS/OPC UA for autoconfiguration of a Profinet based RTE as one step towards PnP. As a part of it, device discovery and configuration services were implemented. It also presented some initial results of the SOA and autoconfiguration implementation. The results of this paper can be used when a designer has to choose an SOA technology for a certain hardware or a hardware platform for a DPWS/OPC UA solution. It has been shown that the used OPC UA implementation requires much less hardware resources in terms of memory. To achieve this small memory footprint an OPC UA server was developed from the scratch. If a developer must implement an SOA approach as fast as possible the already existing DPWS packages are convenient. Another outcome of this work is the small scale OPC UA stack, developed in ANSI C. It demonstrates that by adding a very small amount of code into a lower end industrial device, it can be enabled to talk to its environment in a standardized and vendor neutral way. This allows offering a basic set of structured services. Being a very small OPC UA server, it enables the integration of the simplest devices into the Internet of Things.
Acknowledgments This work was partly funded by the EU FP7 STREP project IoT@Work under grand number ICT-257367 as well as the German Federal Ministry of Education and Research (BMBF) within the Leading-Edge Cluster ”Intelligent Technical Systems OstWestfalenLippe” (it’s OWL).
References [BHJ11]
B. Bony, M. Harnischfeger, and F. Jammes. Convergence of OPC UA and DPWS with a cross-domain data model. In 9th IEEE International Conference on Industrial Informatics (INDIN), pages 187–192, 2011.
[CCBJ11] G. Candido, A. Colombo, J. Barata, and F. Jammes. Service-Oriented Infrastructure to Support the Deployment of Evolvable Production Systems. IEEE Transactions on Industrial Informatics, 7(4):759–767, 2011.
[CJdOC10] G. Cˆandido, F. Jammes, J. de Oliveira, and A. Colombo. SOA at Device level in the Industrial domain: Assessment of OPC UA and DPWS specifications. In 8th IEEE International Conference on Industrial Informatics (INDIN), pages 598–603, 2010. [DTJW12] L. Duerkop, H. Trsek, J. Jasperneite, and L. Wisniewski. Towards Autoconfiguration of Industrial Automation Systems: A Case Study Using Profinet IO. In 17th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), 2012. [EM11]
U. Enste and W. Mahnke. OPC Unified Architecture. at-Automatisierungstechnik, 59(7):397–404, 2011.
[Fel05]
M. Felser. Real-Time Ethernet - Industry Prospective. Proceedings of the IEEE, 93(6):1118–1129, 2005.
[ILL11]
M.J.A.G Izaguirre, A. Lobov, and J.L.M Lastra. OPC-UA and DPWS interoperability for factory floor monitoring using complex event processing. In Industrial Informatics (INDIN), 2011 9th IEEE International Conference on, pages 205–211, 2011.
[KS12]
KW-Software. Profinet IO Device Chip TPS-1. http://www.kw-software.com/com/industrial-ethernet/3021.jsp, Sep. 2012.
[OAS]
OASIS. Devices Profile for Web Services - Version 1.1. http://docs.oasis-open.org/ws-dd/dpws/1.1/os/wsdddpws-1.1-spec-os.pdf.
[PNO10a] PNO. PROFINET Specification IEC 61158-5-10 (V2.3), 2010. [PNO10b] PNO. PROFINET Specification IEC 61158-6-10 (V2.3), 2010. [RKH+ 08] G. Reinhart, S. Krug, S. Huttner, Z. Mari, F. Riedelbauch, and M. Schlogel. Automatic configuration (plug & produce) of industrial ethernet networks. In 9th IEEE/IAS International Conference on Industry Applications (INDUSCON), pages 1–6, 2008. [SOA12]
SOA4D. Service-Oriented Architecture for Devices (Project website). https://forge.soa4d.org/, Sep. 2012.
[W3C12] W3C. SOAP Specification - Version 1.2. http://www.w3.org/TR/soap/, Sep. 2012. [WS412]
WS4D. Web Services for Devices (Project website). http://ws4d.e-technik.uni-rostock.de/, Sep. 2012.
