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 enter-
prises yields vertical integration and promises increased
interoperability and flexibility. Unfortunately, two main
obstacles complicate the use of web services in the man-
ufacturing 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 pro-
grammable 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 enter-
prises in the manufacturing domain, e.g. vehicle manu-
facturing 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, ad-
ministration, or human resources. Large-scale enterprises
by the majority and small and medium-sized businesses
increasingly use enterprise resource planning (ERP) so-
lutions 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 man-
ufacturing 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, stan-
dardized 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 en-
terprises in the manufacturing domain is highly heteroge-
neous, 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 manufactur-
ing 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 well-
known 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—tool-
support 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 sub-
divided 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 pro-
duction process using IPCs and PLCs.
power or main memory. A PLC has several input/output
modules that are connected to sensors and actuators, re-
spectively. A sensor collects (often analogous) information
from the shop floor, e.g. temperature, pressure, or humidity,
whereas an actuator allows to manipulate the manufactur-
ing process. Examples for actuators are electric motors,
solenoids, or conveyor belts.
PLCs operate in a loop according to the input-
processing-output (IPO) model where each step is pro-
cessed 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 pro-
cess has three main disadvantages: (1) Within a PLC
control application, control logic for different manufactur-
ing 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
Business
Engineer
Proprietary
Interface
Automation
Engineer
PLC
Function
Input Processing Output
Sensor Actuator
(a)
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 famil-
iar 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
Enterprise Resource
Planning
Business
Engineer Automation
Engineer
Web Service
Interface
PLC
Function
Input Processing Output
Sensor Actuator
(b)
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 of-
fers 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 busi-
ness 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 imple-
mented 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 de-
ploy/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 compo-
nents of the SOAP4PLC engine: WS-Infobase, WSDL-
Generator, SOAP-Handler and SOAP2PLC-Bridge:
• WS-Infobase: This component is the information
source for all other components that need some infor-
mation 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 re-
sponse 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 WS-
Infobase to retrieve required metadata on a specific web
service. Each deployed web service is listed in the WS-
Infobase 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
 :SOAP2PLC-
:SOAP-Handler :WS-Infobase :PLC Function
Bridge
SOAP request
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 WS-
Infobase. 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 SOAP-
Handler. 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 WS-
Infobase. 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 argu-
ments, 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 link-
time 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 ap-
plication. 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 condi-
tions. 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 SOAP2PLC-
Bridge. The used hardware and operating system determine
the structure and the implementation of the SOAP2PLC-
Bridge. Furthermore, the applied PLC programming sys-
tem 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 imple-
mentation of the WS-Infobase, WSDL-Generator, SOAP-
Handler, and SOAP2PLC-Bridge components are dis-
cussed.
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. @CHIP-
RTOS 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 compu-
tational 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 func-
tion 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 S4PexportPlc-
Function 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 shut-
down 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 S4PexportPlc-
Function, 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 im-
plementation 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 @CHIP-
RTOS’ HTTP server is realized using the CGI interface
of @CHIP-RTOS. This interface permits to register ex-
ternal 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 SOAP-
Handler uses the @CHIP-RTOS’ HTTP server as its un-
derlying 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 op-
erating 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 dy-
namic 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 Lin-
ux/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 appli-
cation 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 corre-
sponding 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) dry-
ing. 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 al-
ready implemented by the automation engineer including
the PLC functions identify, selectColor, start-
Painting 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 func-
tion 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 devel-
opment environment with example PLC code of the ex-
ported PLC function selectColor and also the start-
up 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 service-
oriented 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 spec-
ifies 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 im-
plemented 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 real-
time 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 deploy-
ment 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 im-
proved. (2) The design approach for service-oriented PLC
applications is going to be extended to allow comfort-
able 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 Time-
Constrained 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 De-
vices – 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 In-
frastructure for Real-time Embedded Networked Devices: A service
oriented framework for different domains,” in Proceedings of the In-
ternational 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 In-
dustrial Machinery Processes,” in Proceedings of the IEEE Inter-
national 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. Berna-
Martinez, “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, “Inte-
gration of SOA-Ready Networked Embedded Devices in Enterprise
Systems via a Cross-Layered Web Service Infrastructure,” in Pro-
ceedings 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, “To-
wards Service-oriented Smart Items in Industrial Environments,”
Microsystems Technology (MST), vol. 2, pp. 11–12, 2007.