IEEE Africon 2002
WEB SERVICES FOR REMOTE MAINTENANCE
OF FIELDBUS BASED AUTOMATION SYSTEMS
M Wollschlaeger, P Neurnann and Th Bangernann
lfak Institute for Automation and Communication e.V, Barleben, Germany
ABSTRACT
The use of Web-based concepts in Industrial
automation Is increasingly spreading. The paper shows
motivation, concepts, prerequisites and implementation
details for Web integration. The role of XMGbased
descriptions for mapping of fieldhns data and of
functions to Web technologies is described. Special
attention Is paid to XMGbased Web Services. These
services are mainly used for maintenance and remote
control tasks in automation systems with fieldbnsses.
Finally, security aspects are discussed.
1. INTRODUCTION
The increasing use of fieldbus systems enables the ex-
change of data using modem communication systems.
Local Area Networks, in most cases based on Ethernet
and TCP/IP, are used to interconnect different fieldbus
systems. Furthermore, the mapping of fieldbus compo-
nents' data to LANs has been widely discussed.
Considering the last years' technical developments, the
influence of emerging IT technologies to the automation
and control systems can be treated as the main driving
force in this business. Especially the introduction of web-
based concepts to automation and control is one of the
key technologies. Nowadays, Web-based solutions are
available for a broad range of applications, for example in
human machine interfaces or in engineering tools. Web
technology is also important for the so-called vertical in-
tegration, bridging the gap between the systems at the
factory floor and the systems in the enterprise business
layer.
The main reasons for the developments described above
are dealing with flexibility and usability of browser-based
systems. Topics can be found like platform-independence,
unique access paths, no hard- and software prerequisites,
no installation costs, worldwide access, no limitation for
the number of users, and - last but not least - outstanding
acceptance by the users.
But, besides this mostly euphoric adoption of the technol-
ogy, there are still some drawbacks, that have to be con-
sidered in order to implement high quality solutions. Se-
curity is often counted as the main drawback. Because of
the relevance, this topic is addressed below. Furthermore
the effort for supporting different user interfaces leads to
huge implementation amount at the server. However,
there are some concepts helping to overcome this
implementation efforts by using generation of user
interfaces on the fly.
0-7803-7570-X/02/$17.00 Q 2002 IEEE
247
2. INTEGRATION CONCEPT
A general architectural model is shown in Fig. 1 [I]. It con-
sists of tbree layers. The lowest layer contains the factory
communication system (fieldbus) and the automation and
control devices (fieldbus components). The middle layer
contains the web server@), hosting the information for the
clients in the upper layer. The middle layer is often
described as a portal, mapping the public Hl"l?' protocol to
private protocols (fieldbus). Thus, the web portal contains
the business logic, used to assign the users' requests to
specific data acquisition and management tasks using
fieldbus communication. Technologies like OPC [2] can be
used to assign information from the automation and control
system to an object model. This model can be accessed via
DCOM. OPC servers exist for nearly every fieldbus.
communication
system)
Figure 1: General architecture of Web integration
Although data access is a prerequisite for Web-enabled
solutions, some more facts have to be considered. Using the
Web for automation and control means implementing a
multitude of different technologies, as shown in Fig. 2. Of
course, these technologies have become de facto standards
over the years, and a large number of implementations
already exist. The more important part is the clear mapping
between the single data used in Web applications. The data
are of different types and have different semantic
meanings.
The data within the object model have to be interpreted by
different applications. It is quite important, that this
interpretation has to he consistent. Furthermore, a data
object has relations to context-specific additional
descriptions. For example, a data object containing a
measurement value has to he assigned additional
information describing technical unit, limits, timing
IEEE Africon 2002
requirement, historical data and so on. Depending on the
application, some of this information has to be considered
before presenting the data, some other information is only
useful in other contexts and can be ignored.
I C1lS"i I
Figure 2: The role of XML for data description
The most promising solution for a context-depending
assignment of such additional information is done with
using XMLdescriptions [3]. The descriptions consist of
specialised XML files, describing context-specific
mappings. Since the single XML files rely on
interconnected (linked) XML schemas with syntactical and
semantic definitions, they can be validated by applications.
All the single files and schemas are part of a content model
with welldefmed interfaces [4]. So the complexity of the
descriptions is hidden for the user. Creation and
maintenance of the schemas and the descriptions is tool-
based. A starting point for developing the schemas is a
device model for a single device, or even better a device
profile for a class of similar devices. Fig. 3 shows a
fragment of a schema for PROFInet devices in a generic
XML tool (design view) as an example.
0-7803-7570-X/02/$17.00 0 2002 IEEE
3. SERVER-SIDEFUNCTIONALITY
Using the descriptions, server-side operations can be
performed in order to present the data in a way the client
suits best. This preparation covers different aspects.
Besides the context-specific, application-depending
assignment of additional data, the HMI capabilities of the
clients have to be considered. There are differences
concerning the display size and resolution between a fully-
featured PC, a handheld device (like a palm-size PC) or
even a WAP-capable mobile phone. In order to achieve
best usability, different presentation logic has to be
implemented.
Finally, the underlying heterogeneous protocols for
accessing the information in the fieldbus devices or in data
base systems etc. have to be implemented in the server's
business logic.
In general, the tasks described above lead to functional
complexity at the server. A server implementation usually
relies on standard technologies like ASP, PHF' etc., as
shown in the left part of Fig. 4.
Browser Browser mobile
interfacelCOM) interface (JAVA)
Figure 4 Server architecture (Web-Portal)
In combination with the ongoing success of XML, server-
side handling of XML files gains more importance. It has
some functional benefits. Although transfemng data in an
XML file should - of course - reduce effectiveness of a
transport system, the overall benefits of handling XML
help to overcome this drawback. First of all, the server-side
transformation of XML files using XSLT style sheets
allows to generate any desirable output format. Typical
examples are HTML for browsing in any Web-Browser or
WML for browsing in a GSM mobile phone. Both
 ~

IEEE Africon 2002 249

the service, SOAP is preferred for applications requesting

the service. The principle architecture of a Web-Service
implementationat a server is shown in Fig. 5 .

Some of the benefits using Web-Services are platform-

independence, a generic definition framework for the
messages, the use of "IT as a transport protocol (a
firewall-friendly protocol), and the possibility of
performing validation and security checks before invoking
the service. Of course, the drawback is the coding overhead
of an XMLcoded message, and the required computational
resources. Since there is an increasing performance of
modem hardware components, this should have a minor
influence in the future.

The most promising feature of using Web-Services is the

existence of an XML-based service description. This
description is defined in WSDL (Web Service Description
Language) [7].Fig. 6 shows a fragment of such a service
description.

Web SeMce

Sm*.rq"ni

sa,+za mapon.
.' Listener It. Business Data
Da'a
Logic

B.
++ A W S ~

SanSmntrcl
malm

5. WEB-SERVICE IMPLEMENTATION

Using the server-based architecture shown in Fig. 4, an

exemplary solution has been implemented (Fig. 7).

The Web-Service listener is invoked, when a request has

been passed to the Web Server. The listener itself NIISin a
servlet engine such as Tomcat or JSERV.Depending on the
service, a local function of the object model interface is
invoked. It interacts with the objects and returns the result
of the function as an XML file. Cocoon then transforms

0-7803-7570-X/02/$17.00 0 2002 IEEE


IEEE Africon 2002
this temporary file using an XSLT style sheet. This way,
the result is created and is sent back to the client.
Taking a first look at this scenario, one might not notice the
differences with respect to an explicit function call.
However, the main difference is the existence of a generic
seMce description. It allows a platform-independent access
to the service, since there are no dependencies between the
interface described in WSDL and the implementation of the
listener. It might be implemented in JAVA, as shown in
Fig. 7, it might be implemented using COM or even .NET,
there's no difference in invoking the service.
Web Service Client
Y
HTTF I SOAP
Figure 7: Exemplary WebService implementation
On the other hand, the client can retrieve the WSDL tile
h m the server and can use it to create an appropriate user
interface. Since the WSDL file contains information on
number, names, data types, and ranges of the parameters in
the service request, a user interface can be generated on the
fly. In addition, a validation of the parameters supplied can
be performed before sending the request. This is an
outstanding feature, since it can guarantee, that only valid
requests will be sent.
Of course, the results sent back to the client can be
interpreted the same way. In most cases, human-readable
representations like HTML pages are created. Much more
effective solutions can be implemented, if an application
uses the WSDL description to perform validation and
transformation into internal data formats. Using this
method, Web-Services can be used to exchange data
between applications on demand.
6. WEB-SERVICES AND XML DESCRIPTIONS
As mentioned above, WSDL files are XML files by nature.
This enables to assign the standard XML applications for
transformation and validation. So, for example, the WSDL
file can be created by transforming a device-specific file
with data descriptions and a WSDL template. This method
is an outstanding benefit of the Web-Service scenario,
0-7803-7570-X/02/$17.00 0 2002 IEEE
~
~
250
allowing to generate the required WSDL files by software
instead of writing by hand from scratch.
For example, if a device profile or a device description
contain parameters relevant for a remote maintenance
function, both can be used as an input for the definition of
parameters required in a Web-Service. All additional
information, like data types, ranges. comments, etc. can be
inserted into the WSDL file automatically.
Coming back to the idea of a content model for XML
descriptions of fieldbus systems, Web-Service descriptions
should be an integral part of that model. This would allow
to easily create interface definitions with a well-defined
functionality, which fit optimally to the other parameters of
a device. For the manufacturer of a device, the efforts for
implementing access mechanisms and functions are
reduced dramatically.
mol.. P".."1.Uo"
(~nW8n appllutta.. dl.dlpti0" D."."Drn.
w.b "MUSon SOW or m. datab.u m m ....I
Interfaces InterfaCB
FrameWOrk I
Figure 8: An XML content model
7. SECURITY ASPECTS
When applying the concepts discussed above, more and
more the security aspects are coming into the focus. In
general, this is a positive development, since it leads
towards a discussion of use cases of Web technology. The
following considerations are a first attempt to deal with the
security in systems described above.
First of all, security is an important point and has to be
considered carefully when designing an application. This
can only be done in an adequate way, if an estimation of
the potential security risks has been performed. This
estimation has to take in account, which common relevance
an application can be assigned to. In other words, it has to
be evaluated, how attractive an application may be for
potential attacks - an important, but unfortunately often
difficult task. Furthermore, the general use cases and
implementation concepts for Web-enabled applications
have to be analysed. Of course, there are differences
between an Intranet based scenario and a scenario using the
global Internet.

IEEE Africon 2002
In order to achieve required security criteria, the concepts
and solutions developed for general IT systems have to be
applied. Besides common practice like restrictions on file
and system level (granting read or write access to files,
directories and application, this includes infrastructure
components like firewalls, packet filters, application
proxies, user access control with smart cards, and a
complex security management. Furthermore, appropriate
technologies like encryption, Secure Socket Layer
technology (SSL), Secure HlTF’ ( H T P - S ) , transaction-
based concepts, certificates and digital signatures etc.
should be used. Since there are general requirements for
security in networked applications, applications in the
automation and control area can - and have to rely on-
those standards. There are several open discussions and
forums on this subject like [9].
Derived fmm general IT security considerations, security in
Web-based applications in automation and control has to be
seamlessly integrated into the overall system design. This
has to be done during all the phases of the design process.
It cannot be applied as an “add-on” to an existing system
without influencing the other components’ design and co-
operation.
For a system designer, this means to specify exact use cases
and define required security policies applicable to these use
cases. An o k n used concept is to define so-called %er
roles”. A user role specifies the tasks someone representing
the role has to perform during the lifecycle. This role
defines which data is allowed to be accessed, and which
actions are allowed to be performed. Of course, the user
roles depend on the application. The security policies are
bound to these roles. It has to be pointed out, that the
adequate definition of user roles is a task of general
relevance for every automation and control system.
Besides the roles, the context a role is fulfilled in is
important. The context contains information on the stage in
the life cycle, the type of user-interface, its position in the
architecture of the system, temporal aspects etc. This
information is heterogeneous by nature. In order to make it
accessible in a generic way, it has to be described by a
common methodology. XML can be used here, in
combination with unique semantic definitions defined in a
schema. This task becomes more an more important for
future systems, especially since the information defined
here is useful for other tasks, for example for presentation
and for the generation of user interfaces.
The assignment of user accounts to user roles is the next
step to perform. Of course, the users have to be defined
within a system-wide user accounting system. This ensures
seamless integration of automation and control system and
the underlying general IT system. There are a number of
concepts for user accounting. The most promising is a
directory service [8]. This concept allows the extension of
existing propelry definitions by own, application-specific
properties.
0 2002 IEEE
0-7803-7570-x102/$17.00
-
251
The middle layer of the Web integration concept shown in
Fig. 1 can be treated as a specific type of application proxy.
It maps the functionality of the underlying automation and
control system to web pages or web services. This mapping
has to consider the roles described above. Since this
business layer controls the mapping, it can make sure, that
e.g. there’s no direct write access of binary data which
could contain aggressive information like viruses etc.
Additional protection can be achieved by using dedicated
operating platforms and specific operating systems. Since
the business layer also knows context informatioq the
assignment of security policies can be controlled. In
addition, the knowledge of service sequences and of exact
timing information enables this layer to act as a complex
application proxy.
The concept of Web Services described above offers
starting points for implementing additional security
features. Features like authentication and enclyption can be
integrated according to recent definitions like [lo], [ll].
This ensures a correct mapping of services to predefined
users and user roles. Furthermore, the WSDL descriptions
can be used to check and verify data passed to the service
requests. This reduces errors caused by inconclusive
parameters. However, this feature does not generally
prevent a user from sending faulty parameters, but since the
context is known, additional checks can be implemented
8. CONCLUSIONS
Using the concepts described above, it is possible to
automatically generate Web-enabled services for accessing
fieldbus systems. A scalable solution of applications can be
implemented, combining context-specific infomation with
detailed device data. The implementation can be
characterised to he exeemely flexible, reusable, and
optimally adopted to the required functionality. Especially
for tasks in remote maintenance, the potential of the World
Wide Web can be enabled, combined with easy integration
into existing solutions, and with additional security features
based on validation of XML-coded messages. Web-
Services are an outstanding example of adopting IT-
technology for automation and control systems.
Concerning security, the combination of IT-related security
features with application-specific knowledge and
appropriate definitions offers a good starting point to
implement effective security solutions. However, this can
result in complex systems, so an estimation of the potential
risk is required. Finally it has to be stated, that keeping the
required security level is a never ending task.
REFERENCES
[I] Wollschlaeger, M.: “Framework for Web Integration
of Factory Communication Systems” Proceedings of
81h IEEE International Conference on Emerging
Technologies and Factory Automation (ETFA 2001)
Vol.l,pp. 261-266.
[2] n.n.: OPC Data Access Automation Specification,
Venion 2.0. OPC Foundation
IEEE Africon 2002 252

[3] Bray, T.; Paoli, J.; Sperberg-McQueen, C. M.:

“Extensible Markup Language (XML) 1.0” 1998,
h n p : / k .w3.org/TR/REC-xml
[4] Wollschlaeger, M.; Diedrich, Ch.; Thron, M.; Riedl,
M.: ,,Device Profile Descriptions using General
Purpose Mark-up Languages” Proceedings offhe 4fh
FeT IFAC Confirence Fieldbus Technologv
(FeT2001) pp. 75-82
[SI n.n.: ‘XML Protocol Usage Scenarios” W3C Working
Dr& 2001, http:/ww/wwwww.w3.or~xmlp-scenarios
[6] n.n.: “SOAP Version 1.2 Part 1: Messaging
Framework” W3C Working Drap, 2002,
http://www.w3.orflRn002/WD-soap12-partl~
20020626SOAP
[7] n.n.: ‘W3C Note: Web Services Description
Language (WSDL) 1.1” 2001, hnp://www.w3.org/
TRL2001/?i0TE-wsdl-20010315
[SI nn.: Java Naming and Directory InterfaceTM (JNDI).
http:lljava.sun.co~product~jndi/index.html
[9] Stein, L.D.; Stewart, J.N.: “The World Wide Web
Security F A Q , http://ww~.w3.org/Securi~~aq/
www-security-faq.htmI
[IO] n.n.: “XML-Signature Requirements” W3C Working
Drop, 1999, http:l/wwwww.iedorg/~~~c2807.~t
[I I] n.n.: “XML Encryption Syntax and Processing” W3C
Candidoie Recommendaiion. 2002,
http://www.w3 .orgKRf2002/CR-xmlenc-core-
20020304/

AUTHORS
Peter Neumann
Princisal Author: Martin Wollschlaeger holds a PhD in
Electrical Engineering from Magdeburg University. He is
working on Web integration into automation systems at the
Automation Systems department at if& in Barleben, .,
Germany.

Co-author: Prof Peter Neumann has been working on

various subjects of industrial communication systems and
distributed control systems for several years. He is the head
of ifak Institute for Automation and Communication,
Barleben.

Co-author: Thomas Bangemann holds a PhD in

Electrical Engineering from Magdeburg University. He is
working group leader for Applications at the Automation
Systems department at ifak. Thomas Bangemann

Presenter:
The paper is presented by Prof. P. Neumann

0-7803-7570-W02/$17.00 0 2002 IEEE