Web Services for Programmable Logic Controllers - CiteSeerX

SOAP4PLC: Web Services for Programmable Logic Controllers Markus Mathes, Christoph Stoidner, Steffen Heinzl, Bernd Freisleben Department of Mathematics and Computer Science, University of Marburg Hans-Meerwein-Str. 3, D-35032 Marburg, Germany {mathes,stoidner,heinzl,freisleb}@informatik.uni-marburg.de

Abstract The use of service-oriented architectures based on web services in the manufacturing layer of industrial enterprises yields vertical integration and promises increased interoperability and flexibility. Unfortunately, two main obstacles complicate the use of web services in the manufacturing layer. First, the hardware/software used in this layer differs from the hardware/software used in other layers. Second, the manufacturing layer is maintained by automation engineers who typically are not familiar with web services. This paper presents the first SOAP engine for programmable logic controllers to advance the use of web services in the manufacturing layer. The engine offers a low memory footprint to respect the low computational power of programmable logic controllers and allows to export web services automatically without intervention of an automation engineer.

I. Introduction The software infrastructure of today’s industrial enterprises in the manufacturing domain, e.g. vehicle manufacturing and aircraft construction, is often organized in three vertical layers: business layer, intermediate layer, and manufacturing layer. The business layer of an enterprise contains software functionality for planning purposes, e.g. accounting, administration, or human resources. Large-scale enterprises by the majority and small and medium-sized businesses increasingly use enterprise resource planning (ERP) solutions at this layer. For interoperability reasons, current ERP solutions are based on web services that enable a horizontal integration of the enterprise with its suppliers and customers and a flexible adaptation to new market conditions. Another benefit of adopting web services at the business layer is the possibility to publish business

logic in a coarse-grained manner, which leads to simplified engineering and reengineering of business processes. The intermediate layer acts as a mediator between the business layer and the manufacturing layer. It performs two major tasks: (1) Production orders in the business layer are translated into concrete control commands for the manufacturing systems, e.g. throughput increase/decrease, or shutdown for the purpose of service or retooling. (2) Manufacturing data from the shop floor, e.g. the system status of an assembly line, already produced units, or error messages, are collected, filtered, merged, and delivered to the business layer. The interconnection between business and manufacturing layer is realized via a so-called manufacturing execution system (MES). The particular MES used, depends on the automation solution used at the manufacturing layer. In practice, the automation solution also prescribes the MES. At the manufacturing layer, the core business of an industrial enterprise is located: the manufacturing process. Modern assembly lines are composed of numerous, standardized units, e.g. industrial robots, grinding machines, conveyor belts, or paint shops. These units are controlled by programmable logic controllers (PLCs) and industrial PCs (IPCs) and are interconnected via field buses. The software in this layer is often proprietary and bundled with the hardware used. To summarize, the IT infrastructure of industrial enterprises in the manufacturing domain is highly heterogeneous, ranging from the business layer with standardized, web service based ERP solutions to the manufacturing layer utilizing vendor-specific automation solutions. The vertical adoption of service-orientation in all three layers is desirable, since it leads to a homogeneous communication infrastructure based on a single communication paradigm in the entire enterprise [1]. This paper bridges the gap between the service-oriented business layer and the non service-oriented manufacturing layer by means of the first SOAP engine for PLCs called SOAP4PLC. SOAP4PLC supports the convergence of the business and manufacturing layer. The automation

engineer develops the PLC control software in a wellknown development environment. The corresponding web services are generated and deployed automatically in the background. SOAP4PLC is one of the core components of the Time-Constrained Services (TiCS) framework [2]. TiCS is a development environment for time-constrained web services and consists of three functional layers—toolsupport layer, real-time service layer, and hardware layer— that contain several components to meet the demands of a web service based automation infrastructure. The paper is organized as follows. Section II illustrates the concepts of current industrial automation solutions. In Section III, a design approach for service-oriented PLC applications is presented. Section IV discusses major design considerations concerning a SOAP engine for PLCs and explains how the interaction between a web service and a PLC application is managed. Section V presents a prototypical implementation of the SOAP4PLC engine. Section VI discusses a use case that exemplifies the use of SOAP4PLC. Related work is discussed in Section VII. Section VIII concludes the paper and outlines areas for future work.

II. Industrial Automation Using PLCs This section outlines the traditional implementation of control applications using a PLC. More precisely, the functionality of a PLC is presented and the interconnection of the business and the manufacturing layer is discussed. Unfortunately, there are no standards for the design and realization of industrial production processes. Automation engineers rely on best practice solutions developed over the years, as discussed below. At present, the entire manufacturing process is subdivided into several disjunctive manufacturing steps that are called production cells. Each production cell contains several manufacturing devices, e.g. industrial robots or hoisting platforms, that are controlled by a PLC. Several cells are monitored by an IPC. The IPC offers an—often proprietary—interface to query information from higher layers. This approach leads to a hierarchical arrangement of the entire production process, as shown in Figure 1. An IPC is comparable to a regular desktop PC in terms of computing power and main memory, but the case design is much more robust to resist the hostile physical conditions in the manufacturing layer, such as temperature, vibration, or dust and dirt. Often, standardized operating systems like Microsoft Windows or Linux are used to run IPCs. A PLC is specialized automation hardware that differs significantly from common desktop PCs. Even though modern PLCs become more and more powerful, they are not comparable to desktop PCs with regard to computing

Higher Layers

Pro

Pro

Fig. 1. Hierarchical arrangement of the production process using IPCs and PLCs.

power or main memory. A PLC has several input/output modules that are connected to sensors and actuators, respectively. A sensor collects (often analogous) information from the shop floor, e.g. temperature, pressure, or humidity, whereas an actuator allows to manipulate the manufacturing process. Examples for actuators are electric motors, solenoids, or conveyor belts. PLCs operate in a loop according to the inputprocessing-output (IPO) model where each step is processed in a predetermined time. The PLC reads input data from its sensors, computes the necessary reaction based on a given rule base, and uses its actuators to react. Such an IPO loop is called a task. Since each step in an IPO loop can only take a predetermined time, a PLC inherently supports real-time processing. The rule base is set up by a domain expert, namely the automation engineer who maintains the manufacturing process, using different (low-level) programming languages, e.g. Function Block Diagram (FBD), Ladder Diagram (LD), Structured Text (ST), or Sequential Function Chart (SFC), as defined by IEC 61131-3 [3]. A PLC control application is organized in several modules called program organization units (POUs). A POU may consist of multiple expressions in one of the low-level programming languages and other POUs. Each task is realized by one POU. The presented hierarchically organized production process has three main disadvantages: (1) Within a PLC control application, control logic for different manufacturing devices is mixed. (2) The interface between the IPC and higher layers is often proprietary. (3) Interconnection of manufacturing layer and higher layers requires expert

Enterprise Resource Planning

Enterprise Resource Planning Business Engineer

Business Engineer

Proprietary Interface Automation Engineer

Automation Engineer Web Service Interface

PLC

PLC Function Input

Processing

Sensor

Function Output

Input

Actuator

Sensor

(a)

Processing

Output

Actuator (b)

Fig. 2. Separation of concerns in industrial automation.

knowledge both of the automation engineer and software developers from higher layers.

III. Service-Oriented PLC Applications This section presents a design approach for developing service-oriented PLC applications based on web services. Since this concept is new in the industrial automation domain, there are no well-established design patterns. Furthermore, automation engineers are normally not familiar with service-oriented concepts. Therefore, the primary objective of the SOAP4PLC engine is to hide the web service details from automation engineers. This requires a specific organization of the PLC application to permit automatic identification of functional entities (e.g. PLC functions) by the SOAP4PLC engine. The use of web services and conventional tools for the implementation of PLC functions do not affect each other. The automation engineer designs and implements the PLC applications as usual to support high acceptability by the engineering domain. Each functionality of a module that should be exported by the SOAP4PLC engine as a web service has to be encapsulated in a PLC function. To export these functions, the PLC development environment supports a configuration interface. The SOAP4PLC engine manages all exported PLC functions and invokes a specific function when the corresponding web service invocation arrives. This concept allows to use the standard automation tools

and languages for the definition and deployment of web services. Thus, the automation engineer operates in his/her well-known development environment. Since the PLC offers a standardized service-oriented interface based on web services if our SOAP4PLC engine is used, the business engineers can also use their well-known tools to access the manufacturing process. Consequently, our concept fills the gap between business layer and manufacturing layer without introducing unfamiliar technologies, neither for the business nor for the automation engineer. This approach results in a separation of concerns. Up to now, the business and the manufacturing engineer have to collaborate to realize the proprietary interface between the business layer and the manufacturing layer, as shown in Figure 2(a). Using our approach, the concerns of the business and the manufacturing engineer are cleanly separated, as shown in Figure 2(b).

IV. Design of a SOAP Engine for PLCs The primary design objective of the engine is usability for automation engineers, i.e. the control logic implemented by the automation engineer should be exported automatically as web service. Therefore, the automation engineer does not have to deal with unfamiliar technologies such as SOAP. To realize this objective, the following functionality is required: • The automation engineer must be empowered to deploy/undeploy PLC functions as web services.

WSDL descriptions of already deployed web services have to be generated automatically. • The PLC has to listen for incoming SOAP request messages and has to interpret them. • An invocation message must result in a call to the corresponding PLC function. • After the call of a PLC function, a SOAP response message has to be generated and sent. These functions are encapsulated in four core components of the SOAP4PLC engine: WS-Infobase, WSDLGenerator, SOAP-Handler and SOAP2PLC-Bridge: • WS-Infobase: This component is the information source for all other components that need some information about the deployed web services. It provides an interface to permit the export of a PLC function as a web service by the automation engineer. • WSDL-Generator: This component dynamically generates WSDL descriptions for already deployed web services. • SOAP-Handler: This component implements the SOAP protocol, i.e. it processes incoming SOAP request messages and generates outgoing SOAP response messages. • SOAP2PLC-Bridge: This component locates and calls the corresponding PLC function for an incoming web service invocation. •

Web Service Interface

SOAP4PLC Engine

PLC Application

Fig. 3. Design of the SOAP4PLC engine. Figure 3 illustrates the internal structure of a web service enabled PLC. The SOAP4PLC engine acts as a mediator between the conventional PLC application and the web service interface. Figure 4 shows a sequence diagram for the execution of a PLC function using a web service.

A. WS-Infobase The WS-Infobase component implements the service descriptor table, a database that holds the metadata of all deployed web services and the related PLC functions. All other components of the SOAP4PLC engine use the WSInfobase to retrieve required metadata on a specific web service. Each deployed web service is listed in the WSInfobase with its unique name and a table of provided operations. The unique name will be used to retrieve the web service from the WS-Infobase. The table of operations contains a row for each deployed operation of the web service. A row includes the following information to describe the interface of an operation: • name of operation: The name is used to determine the operation of the web service. • reference to the corresponding PLC function: The reference is used to address the PLC function and is realized as a function pointer, a handle, or a unique identifier depending on the used PLC programming system. • list of input parameters: The input parameter list specifies the number of parameters and the datatype of each parameter. The order of the parameters in the list specifies their order for an operation call. • datatype of the operation: The datatype of the operation represents the datatype of its return value. Since the interface definition specifies the interface of the web service and the interface of the corresponding PLC function, both interfaces have to be identical. To the automation engineer, the WS-Infobase provides a user interface to deploy and undeploy web services. More precisely, from the automation engineers point of view, it provides a user interface to export PLC functions. Using this interface, the automation engineer is empowered to select some PLC functions for being exported as web services. For each exported PLC function, a group name is defined. The group name specifies the web service these PLC functions are assigned to. The user interface is the only point of contact between the automation engineer and the SOAP4PLC engine. The WS-Infobase is able to generate all metadata required by the service descriptor table from the input of the automation engineer since the PLC development environment knows all PLC functions, their names and their interfaces. The name of the web service used to deploy the PLC function is derived from the PLC function’s group name. Thus, the deployment process is performed automatically without any interaction of the automation engineer and is completely transparent. This is done at the startup of the PLC application in three steps per web service: (1) All generated metadata will be stored in the service descriptor table. (2) The SOAP-Handler is extended to accept the URI of the newly deployed web

:SOAP-Handler SOAP request

:SOAP2PLCBridge

:WS-Infobase

:PLC Function

match webservice by name result match operation by name result match interface by datatypes result forward request get function pointer result get interface descritpion result invoke

result

Fig. 4. Sequence diagram of a PLC function call using a web service.

service. (3) A new instance of the WSDL-Generator is started to offer a WSDL description for the new web service.

B. SOAP-Handler The SOAP-Handler component realizes the handling of the SOAP protocol. When the WS-Infobase deploys a web service, the SOAP-Handler is informed. At application start, it initiates the underlying HTTP protocol handler to listen for the corresponding URI of the web service. After that, the SOAP-Handler is able to handle requests for that web service. When a request arrives, the SOAP-Handler identifies the target web service via the requested URI and tries to find the corresponding operation interface definition using the WS-Infobase. If no matching entry is found, a SOAP fault message is generated. Otherwise, the interface definition is

validated, i.e. the operation name, the argument datatypes and the return datatype is determined and matched with the metadata from the service descriptor table in the WSInfobase. Additionally, the argument values are parsed and stored for later usage. Then, the SOAP2PLC-Bridge is used to invoke the PLC function and to pass the argument values. As soon as the PLC function terminates, the SOAP2PLC-Bridge returns the result to the SOAPHandler. The result is embedded in a SOAP response message that is delivered to the underlying HTTP protocol handler to complete the web service request.

C. WSDL-Generator The WSDL-Generator component provides a WSDL description for each deployed web service. The WSDL description is generated automatically based on the meta-

data contained in the service descriptor table of the WSInfobase. When the WS-Infobase deploys a web service, a new instance of the WSDL-Generator is created. The new instance initiates the underlying HTTP protocol handler to listen for the according URI of the web service. Since all required information for describing the entire interface of each web service are contained in the WS-Infobase, the generation process can be done completely in background without requiring any attention of the automation engineer. The URI that provides the WSDL description equals the corresponding web service name extended by the postfix “.wsdl”. For example, the WSDL description of the web service “Paintshop” is provided by “Paintshop.wsdl”. On an incoming client request, the handler generates the WSDL description dynamically and delivers it to the underlying HTTP protocol handler.

D. SOAP2PLC-Bridge The SOAP4PLC engine requires to call a PLC function from outside of the PLC application. It passes the arguments, executes the PLC function and on return it reads the return value. Since the PLC function is implemented using a PLC development environment, there are several issues to consider: 1) The PLC function is unknown at compile- and linktime of the SOAP4PLC engine, i.e. the PLC function has to be linked dynamically. 2) The PLC function is not located within the context of the SOAP4PLC engine, but within the PLC application. Consequently, a context switch is required before and after the call of the PLC function. 3) The calling conventions of PLC functions differ from the calling conventions of ANSI C functions. Thus, a PLC compliant stack frame has to be created first for passing arguments, calling the PLC function, and accepting the return value. 4) The PLC application runs in a different task than the SOAP4PLC engine. Hence, the call of a PLC function has to be synchronized to avoid race conditions. Furthermore, the real-time requirements of the PLC application are assured. This is important since the workload caused by the web service consumer is unknown. All these functions are handled by the SOAP2PLCBridge. The used hardware and operating system determine the structure and the implementation of the SOAP2PLCBridge. Furthermore, the applied PLC programming system affects the implementation, since the IEC 61131-3 standard does not define the low-level details (for example memory layout and structure) of a PLC application.

V. Implementation This section presents a prototypical implementation of the SOAP4PLC engine. More precisely, the implementation of the WS-Infobase, WSDL-Generator, SOAPHandler, and SOAP2PLC-Bridge components are discussed.

A. Experimental Soft- and Hardware The IPC@CHIP PLC from Beck IPC GmbH [4] is used as our experimental hardware. All products based on the IPC@CHIP technology contain a full-featured embedded real-time operating system called @CHIP-RTOS. @CHIPRTOS supports all common features of modern operating systems, such as multitasking, support for several network interfaces, TCP/IP protocol stack including IPsec and SSL, and standard transfer protocols like HTTP, FTP, and SSH. CoDeSys, an IEC 61131-3 compliant programming system developed by 3S-Smart Software Solutions [5], is used as our PLC development environment to access the PLC. The CoDeSys programming system consists of two software components. The first one is CoDeSys itself. This is a Microsoft Windows application that realizes the PLC development environment, consisting of editor, compiler, debugger, etc. The second software component is the runtime system called CoDeSys SP. CoDeSys SP runs on the target system (the IPC@CHIP based PLC) and manages download, linking, execution, and debugging of the PLC application. To permit SOAP-based interaction with the PLC, we extended CoDeSys SP by the four components discussed in Section IV. Figure 5 illustrates the integration of the SOAP4PLC engine into the IPC@CHIP based PLC. The WS-Infobase and SOAP2PLC-Bridge plug-ins extend the CoDeSys runtime system, whereas the SOAP-Handler and the WSDL-Generator extend the @CHIP-RTOS by SOAP protocol capabilities. The implementation of the SOAP4PLC engine offers a low memory footprint to respect the restricted computational power of current PLCs. The entire main memory required for engine code and static data is approximately 7 kBytes. The memory requirement for every exported PLC function depends on the size of its interface description (number of arguments). Typically, a PLC function requires approximately 40–100 Bytes of main memory.

B. WS-Infobase Our prototypical SOAP4PLC engine is implemented inside the runtime system only. Thus, there is no graphical user interface, but a simple API. It provides the functions S4PaddArgument, S4PexportPlcFunction, and

PLC Application

HTTP Daemon

Fig. 5. Prototypical implementation of the SOAP4PLC engine at an IPC@CHIP based PLC.

S4PshutDown to handle the export of PLC functions. These functions are implemented as external functions, i.e. these functions are accessible from the PLC application but are not implemented in a PLC programming language. Instead, the functions are part of the runtime system and are implemented using the programming language C. The function S4PexportPlcFunction is called at the start of the PLC application, once for each PLC function to be exported. The function expects the group name, the PLC function name, a reference to the corresponding PLC function, the interface description (argument list) and the return type as its arguments. They are stored in the service descriptor table. The group name will be used as web service name. If the web service name is unknown (i.e. there was no registration call on that name before), two more steps are necessary: (1) The SOAP-Handler is extended to accept the URI of the newly registered web service. (2) A new instance of the WSDL-Generator is started, offering a WSDL description for the new web service. The function S4PaddArgument creates an argument list that is required by the function S4PexportPlcFunction as described above. To create an argument list, it is called once for each argument. It expects the argument type of the new argument and the current argument list. It returns the current argument list extended with the new argument as its result. To create a complete argument list, the function is called for the first argument with S4P_EMPTY (an empty argument list). The next calls are

done with the result of the previous call. Thus, the last call returns the complete list and can be used as an input value for S4PexportPlcFunction. The function S4PshutDown is called once at the shutdown of the PLC application. The function clears the service descriptor table and undeploys all web services, i.e. all web services are deregistered from the SOAP-Handler and all instances of the WSDL-Generator are terminated and removed. As mentioned before, the S4PexportPlcFunction, S4PaddArgument, and S4PshutDown functions are called at application start-up and shut-down, respectively. The CoDeSys programming system provides an event concept that offers several system events. One of these system events—the start event—occurs when the PLC is powered on or when the PLC application is stopped and restarted again. The automation engineer is able to register a PLC function for this event that implements PLC function export using S4PexportPlcFunction and S4PaddArgument. Similarly, the unregister process is also realized using the CoDeSys system events. For this purpose, the system stop event is used to call the S4PshutDown function. This terminates the engine and thus unregisters all functions. The engine is restarted again on the first S4PexportPlcFunction call automatically.

C. WSDL-Generator The @CHIP-RTOS offers an HTTP server. The implementation of the WSDL-Generator component uses this HTTP server to listen for HTTP requests and sends an HTTP response back to the client. The interaction between the WSDL-Generator component and @CHIPRTOS’ HTTP server is realized using the CGI interface of @CHIP-RTOS. This interface permits to register external handlers for incoming requests on specific URIs. The WSDL-Generator component takes advantage of this feature. Every instance of the component announces its own handler for the WSDL URI of the specific web service. On an incoming client request, the specific handler is called. Then, the handler creates the WSDL description dynamically and delivers it to the HTTP server. The HTTP server sends it back to the requesting client.

D. SOAP-Handler Just like the WSDL-Generator component, the SOAPHandler uses the @CHIP-RTOS’ HTTP server as its underlying HTTP protocol handler. Therefore, it registers an external handler for every deployed web service URI using the @CHIP-RTOS CGI interface. As soon as a request for a specific web service arrives, the @CHIP-RTOS’ HTTP

server triggers the external handler. The external handler implements the SOAP parser and interacts with the other required components, as described in Section IV.

E. SOAP2PLC-Bridge The SOAP2PLC-Bridge handles low-level functionality that depends on the used processor architecture and operating system. Since the IEC 61131-3 standard does not define the low-level layer of a PLC application (memory layout and structure), the used PLC programming system also affects the implementation of this component. The IPC@CHIP technology with the @CHIP-RTOS and the CoDeSys PLC programming system require to take dynamic linking, context switches, calling conventions, and synchronization into consideration, as discussed below. 1) Dynamic Linking: On a request to invoke a PLC function, the SOAP2PLC-Bridge expects the name of the PLC function. Matching this name with the WS-Infobase results in a reference (called POU index) to the requested PLC function. Since every POU within a CoDeSys PLC application owns a unique POU index, it can be used to determine the pointer to the PLC function. The mapping from POU index to function pointer is done using a C function provided by the CoDeSys runtime system. Later, this function pointer is used to invoke the PLC function. 2) Context Switch: The process concept known from general-purpose operating systems like Windows or Linux/Unix is also applied in the @CHIP-RTOS. Every process (or application) owns its dedicated context, e.g. stack, instruction counter, heap memory. The SOAP4PLC engine and the PLC application are running in separated processes, i.e. before the PLC function is called, the process context has to be switched to the PLC application. This is important to permit the PLC function to access the PLC application’s environment such as global data. As soon as the PLC function has been completed, the process context of the SOAP4PLC engine has to be restored. In an IPC@CHIP environment, a process context is specified by a 16-bit segment value. The current process context is declared using the data segment (DS) processor register. Before switching the context, the old value is saved to the stack. Then, the PLC application’s process context is written into the DS register. The context is determined using a C function provided by the CoDeSys runtime system. When the PLC function is processed, the SOAP4PLC engine’s context has to be restored. This is done by reading it from the stack and writing it back to the DS register. 3) Calling Conventions: A calling convention is an agreement between a function and a potential caller of this function. It defines the structure of the stack frame of the function call and the responsibility for the memory

allocation for arguments, local data, return value, and return address. The allocation could be realized by the caller, the function itself or by both in an hybrid approach. Furthermore, a calling convention defines the order of the arguments on the stack. Unfortunately, the calling conventions of PLC functions differ from those of ANSI C functions. Therefore, calling a PLC function requires to create the stack frame according to the interface definition of the PLC function and the argument values that were passed on the web service’s invocation message. Then, the function pointer is used to determine the memory address where the PLC function is located and a call to that address is executed. When the PLC function returns, the return value can be read from the stack. Finally, the stack has to be restored, i.e. allocated data has to be deleted. 4) Synchronization: Synchronization includes two challenges: First, the SOAP4PLC engine, more precisely the SOAP2PLC-Bridge, runs in a different task than the PLC application. All exported PLC functions are executed within the SOAP4PLC engine’s context. Consequently, the PLC functions have to be synchronized with the rest of the PLC application. Each access to global data has to be checked and protected against race conditions. Since potential race conditions depend heavily on the PLC application structure, the automation engineer is responsible to realize the synchronization manually. For this purpose, the CoDeSys programming system on the IPC@CHIP based PLC provides a comfortable semaphore API. Second, it must be ensured that the additional workload caused by web service invocations, which normally is unknown, does not delay the execution of the PLC control application. For this purpose, the time-slicing feature of the IPC@CHIP based PLC is used. A time slice defines the maximum processor time that is assigned to the corresponding tasks. The time-slicing feature allows to define a time slice for the system and application tasks (e.g. ethernet, TCP/IP stack, HTTP protocol handling, execution of SOAP4PLC engine) and a second one for the PLC application tasks (all tasks created with the CoDeSys programming system) to ensure timely execution of the PLC control application.

VI. Use Case This section illustrates the use of the SOAP4PLC engine by means of a use case from the automobile manufacturing domain, more precisely the painting of a car. Painting a car takes the following steps: (1) car identification using a bar code or RFID, (2) selection of the corresponding paint color, (3) painting, (4) drying. Using our SOAP4PLC engine results in a web service named PaintShop that offers the operations

identify, selectColor, startPainting, and startDrying. We assume that the overall PLC application was already implemented by the automation engineer including the PLC functions identify, selectColor, startPainting and startDrying. To enable the call of the PLC functions via a web service, the PLC functions have to be grouped and exported using the WS-Infobase function S4PexportPlcFunction. As soon as the PLC application is started, the start-up function exports the PLC functions as a web service. Therefore, a web service named PaintShop is deployed to the SOAP4PLC engine that is accessible under the URI /PaintShop. The web service offers an operation for each exported PLC function. Also, a corresponding WSDL /PaintShop.wsdl description is available that is created dynamically by the SOAP4PLC engine according to the web service name and the method interface description. Figure 6 shows a screenshot of the CoDeSys development environment with example PLC code of the exported PLC function selectColor and also the startup code that exports the PLC function. The example is implemented via a function block diagram according to IEC 61131-3.

VII. Related Work The SIRENA project [1], [6], [7]—part of the ITEA research program—is aimed at the development of a service infrastructure for real-time embedded networked applications. SIRENA envisions a seamless use of serviceoriented architectures within holonic industrial automation and identifies resulting business advantages. Unfortunately, SIRENA only offers an innovative architectural blueprint of service-oriented industrial automation, but no practical implementation or tool support are presented. Gilart-Iglesias et al. [8], [9] present an approach called Industrial Machine as a Service (IMaaS) that enables a seamless service-oriented integration of machines in the IT infrastructure. Even though IMaaS is similar to our approach, no connection to well-established automation tools and programming languages (e.g. according to IEC 61131-3) are presented. Mircosoft has proposed the Devices Profile for Web Services (DPWS) [10], [11], [12]. This technology specifies a minimal SOAP implementation to realize web service communication on small and resource-constrained devices. Although DPWS is suitable to run on a PLC (regarding computational power and memory footprint), there is no support for well-established automation tools and programming languages (such as IEC 61131-3). The Web Services for Devices (WS4D) toolkit [13] carries Microsoft’s DPWS technology into the industrial

automation domain. It supports several DPWS stacks implemented in different programming languages. At present, there is no stack available that allows the usage of DPWS in a typical development environment for industrial control applications. Kalogeras et al. [14] present a web service based system architecture for vertical integration in industrial enterprises. The authors do not discuss the specific realtime requirements in the manufacturing layer and tool support for automation engineers. Thus, our proposal can be used as a technical foundation for this architecture. Karnouskos et al. [15], [16] present the integration of SOA-ready embedded devices into the web service infrastructure of an enterprise. The presented architecture discusses the layers of an industrial enterprise in detail, but no implementation or evaluation is given.

VIII. Conclusions The use of service-oriented architectures based on web services on programmable logic controllers has many advantages. In the industrial automation domain—where software is often proprietary—web service technologies permit the interaction between the manufacturing layer and the business layer without requiring detailed knowledge of the counterpart. Unfortunately, the use of web services on PLCs has several difficulties: (1) hard- and software of a PLC is less powerful than hard- and software on workstations and servers; (2) automation engineers who maintain the PLCs often have less experience in the development and deployment of web services; (3) web services for the manufacturing layer are completely new in the industrial automation domain, so there are no well-established design patterns. The SOAP4PLC engine presented in this paper solves these problems. It extends an IEC 61131-3 compliant programming system with an interface for exporting PLC functions. This interface does not presume any knowledge about web services of the automation engineer. For each exported PLC function, a corresponding web service is deployed automatically. All necessary steps from deployment over WSDL generation to verification and execution of requests are performed automatically and are completely transparent to the automation engineer. Besides the SOAP4PLC engine, we presented a design approach for developing service-oriented PLC applications based on web services. The presented approach allows the organization of PLC applications to permit automatic identification of functional entities (e.g. PLC functions) by the SOAP4PLC engine. There are several areas for future work: (1) The synchronization between the SOAP4PLC engine and the

Fig. 6. Example of a web service accessible PLC application.

cyclic execution of the PLC application has to be improved. (2) The design approach for service-oriented PLC applications is going to be extended to allow comfortable modularization and distribution of service-oriented PLC applications. (3) Our prototypical implementation of the SOAP4PLC engine only offers a simple API for the automation engineer. Future versions will extend the CoDeSys development environment with a graphical user interface that supports to mark an arbitrary PLC function for export as a web service.

References [1] F. Jammes and H. Smit, “Service-Oriented Paradigms in Industrial Automation,” IEEE Transactions on Industrial Informatics, vol. 1, pp. 62–69, 2005. [2] M. Mathes, S. Heinzl, and B. Freisleben, “Towards a TimeConstrained Web Service Infrastructure for Industrial Automation,” in Proceedings of the 13th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA). IEEE Computer Society Press, 2008, pp. 846–853. [3] “International Electrotechnical Commission (IEC), Programmable Controllers – Part 3: Programming Languages (IEC 61131-3),” January 2003, http://www.iec.ch/. [4] “Beck IPC GmbH,” http://www.beck-ipc.com/. [5] “3S–Smart Software Solutions,” http://www.3s-software.com/. [6] F. Jammes and H. Smit, “Service-Oriented Architectures for Devices – the SIRENA View,” in Proceedings of the 3rd International Conference on Industrial Automation (INDIN), 2005, pp. 140–147. [7] H. Bohn, A. Bobek, and F. Golatowski, “SIRENA - Service Infrastructure for Real-time Embedded Networked Devices: A service oriented framework for different domains,” in Proceedings of the International Conference on Networking, International Conference on Systems, and International Conference on Mobile Communications and Learning Technologies (ICN/ICONS/MCL), 2006, pp. 43–47.

[8] V. Gilart-Iglesias, F. Macia-Perez, D. Marcos-Jorquera, and F. J. Mora-Gimeno, “Industrial Machines as a Service: Modelling Industrial Machinery Processes,” in Proceedings of the IEEE International Conference on Industrial Informatics (INDIN). IEEE Computer Society Press, 2007, pp. 737–742. [9] V. Gilart-Iglesias, F. Macia-Perez, F. Mora-Gimeno, and J. BernaMartinez, “Normalization of Industrial Machinery with Embedded Devices and SOA,” in Proceedings of the 11th IEEE Conference on Emerging Technologies and Factory Automation (ETFA). IEEE Computer Society Press, 2006, pp. 173–180. [10] “Devices Profile for Web Service (DPWS) Specification,” February 2006, http://specs.xmlsoap.org/ws/2006/02/devprof/. [11] F. Jammes, A. Mensch, and H. Smit, “Service-Oriented Device Communications Using the Devices Profile for Web services,” in Proceedings of the 21st International Conference on Advanced Information Networking and Applications (AINA). IEEE Computer Society Press, 2007, pp. 947–955. [12] E. Zeeb, A. Bobek, H. Bohn, and F. Golatowski, “Service-Oriented Architectures for Embedded Systems Using Devices Profile for Web Services,” in Proceedings of the 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW), 2007, pp. 956–963. [13] “Web Services for Devices (WS4D), Project Homepage,” http: //ws4d.org/. [14] A. Kalogeras, J. Gialelis, C. Alexakos, M. Georgoudakis, and S. Koubias, “Vertical Integration of Enterprise Industrial Systems Utilizing Web Services,” in Proceedings of the IEEE International Workshop on Factory Communication Systems (WFCS). IEEE Computer Society Press, 2004, pp. 187–192. [15] S. Karnouskos, O. Baecker, L. M. S. de Souza, and P. Spiess, “Integration of SOA-Ready Networked Embedded Devices in Enterprise Systems via a Cross-Layered Web Service Infrastructure,” in Proceedings of the 11th IEEE Conference on Emerging Technologies and Factory Automation (ETFA). IEEE Computer Society Press, 2007, pp. 293–300. [16] S. Karnouskos, A. Colombo, F. Jammes, and M. Strand, “Towards Service-oriented Smart Items in Industrial Environments,” Microsystems Technology (MST), vol. 2, pp. 11–12, 2007.