Diplomarbeit - QWERviolin.qwer.tk/dusty/thesis/soap_if_inet-fan.pdf · Diplomarbeit SOAP Interface For An Internet/Fieldbus Gateway ausgef¨uhrt zum Zwecke der Erlangung des akademischen

Diplomarbeit

SOAP Interface For An Internet/Fieldbus Gateway

ausgefuhrt zum Zwecke der Erlangung des akademischenGrades eines Diplom-Ingenieurs

unter der Leitung von

O. Univ. Prof. Dipl.-Ing. Dr.techn. Dietmar Dietrichund

Dipl.-Ing. Dr.techn. Maksim Lobashov

E 384Institut fur Computertechnik

eingereicht an der Technischen Universitat WienFakultat fur Elektrotechnik und Informationstechnik

von

Hermann HimmelbauerMatr.Nr.: 9025909

Martinstraße 18/2, A-3400 Klosterneuburg

Klosterneuburg, am 7. September 2006

Kurzfassung

Ein Schlusselpunkt der vertikalen Integration in der industriellen Automatisierung ist einfunktionierender Informationsaustausch zwischen hoheren Ebenen des Automatisierungssy-stems, wie beispielsweise dem Manufacturing Execution System (MES) und der Feldebene.Eine Verbindung zwischen diesen beiden Ebenen wird meist durch die Installation von Inter-net/Feldbus Gateways bewerkstelligt. Die vorliegende Arbeit untersucht die Anwendbarkeitvon Simple Object Access Protocol (SOAP) Web Services fur eine Internet-Schnittstelle aufeinem Internet/Feldbus Gateway.

Neben der Analyse von verschiedenen Moglichkeiten, das SOAP Protokoll fur den Trans-port von Feldbus-Daten effizient einzusetzen, werden auch existierende Standards in demBereich untersucht. Ein besonderes Augenmerk wird dabei auf die OPC XML Data Access(XML-DA) Spezifikation gelegt. Uberdies wird im Rahmen der Arbeit ein OPC XML-DAServer fur ein existierendes Internet/Feldbus Gateway entwickelt und anschließend auf Inte-roperabilitat und Leistungsfahigkeit getestet.

Die theoretische Analyse, aber auch der praktische Test fuhren zu dem Schluss, dassSOAP Web Services eine brauchbare Losung fur Internet/Feldbus Schnittstellen sind. DieVorzuge der Losung liegen in der Interoperabilitat, der Lesbarkeit des Protokolls und dessenideale Eignung fur den Einsatz im Internet.

Allerdings zieht SOAP auch einige Nachteile mit sich, wie etwa eine hohe Komplexitatder Spezifikation, erhebliche Anforderungen an die Bandbreite des Netzwerks, hohe Anforde-rungen an die CPU und ein betrachtlicher Speicherbedarf. Diese Nachteile scheinen derzeiteine breite Verwendung dieser Technologie in der industriellen Automatisierung zu limitieren.

Abstract

A key to vertical integration in industrial automation is the transparent information exchangebetween the upper level automation system, such as a Manufacturing Execution System(MES) and the field level, which is usually established by Internet/fieldbus gateways. Thisthesis analyzes the suitability of Simple Object Access Protocol (SOAP) Web Services for anInternet interface of Internet/fieldbus gateways.

Apart from theoretically examining how the SOAP protocol can be used to efficientlyrepresent and transport fieldbus data, the thesis considers existing standards in this domain,in particular, the OPC XML Data Access (XML-DA) specification. Furthermore an OPCXML-DA server for an existing Internet/fieldbus gateway is developed and analyzed for in-teroperability and performance.

The thesis shows that SOAP Web Services provide a decent solution to the needs ofInternet/fieldbus interfaces, with the advantages of interoperability, legibility of the protocolto humans and high suitability for deployment on the Internet.

However, certain disadvantages such as complexity of the specification, considerable band-width and CPU requirements and a significant memory footprint seem to limit the broaddeployment of this technology in industrial automation.

Acknowledgements

I would like to thank my supervisor Dr. Maxim Lobashov for his patience and continuousguidance throughout my work. Moreover, I am very grateful to Dr. Ursula Kluwick, whohelped me to correct misspellings and deficiencies in my English.

Finally, I would like to thank my wife Veronika, my children Anna, Maria and Christinaand my parents, who supported me throughout my work and gave me the time I needed tocomplete my work.

Contents

1 Introduction 1

2 Principles of SOAP Web Services 6

2.1 XML - Extended Markup Language . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 SOAP - Simple Object Access Protocol . . . . . . . . . . . . . . . . . . . . . 13

2.3.1 Message Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.3 Encoding and Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 WSDL - Web Services Definition Language . . . . . . . . . . . . . . . . . . . 19

2.5 UDDI - Universal Description, Discovery and Integration . . . . . . . . . . . 21

3 Existing Solutions for SOAP Based Fieldbus Access 23

3.1 OPC - Object Linking and Embedding for Process Control . . . . . . . . . . 23

3.2 oBIX - Open Building Information Exchange . . . . . . . . . . . . . . . . . . 29

3.3 BACNet/WS - Web Services for Building Automation and Control Networks 33

3.4 Echelon i.LON 100 SOAP/XML Interface . . . . . . . . . . . . . . . . . . . . 36

4 Representing Information in Different Fieldbus Systemswith SOAP 40

4.1 Generalized Fieldbus Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.1 Operations for Fieldbus Access . . . . . . . . . . . . . . . . . . . . . . 42

4.1.2 Fieldbus Data and Addressing Scheme . . . . . . . . . . . . . . . . . . 44

4.1.3 Localization and Units . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Application Specific Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Representing Fieldbus Data and Services with SOAP . . . . . . . . . . . . . . 49

4.3.1 XML Attributes and XML Elements . . . . . . . . . . . . . . . . . . . 51

4.3.2 Identifying XML Data by Name Versus Order . . . . . . . . . . . . . . 52

4.3.3 Encoding Fieldbus Data in SOAP Messages . . . . . . . . . . . . . . . 53

4.4 Handling of Latency and Timing Issues . . . . . . . . . . . . . . . . . . . . . 55

4.5 Other Internet/Fieldbus Gateway Issues . . . . . . . . . . . . . . . . . . . . . 57

5 SOAP Front end Design for the IGUANA Gateway 60

5.1 The IGUANA Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Encapsulating the IGUANA Protocol into SOAP Messages . . . . . . . . . . 65

5.3 Representing the IGUANA Interface with an XML compliant OPC standard 68

5.3.1 Representing Datapoint Values with OPC . . . . . . . . . . . . . . . . 69

5.3.2 Mapping OPC Services to the IGUANA Gateway . . . . . . . . . . . . 76

5.4 Web Service Compliant Fieldbus Applications on the IGUANA Gateway . . . 79

6 Implementation of an OPC XML-DA Compliant SOAPWeb Service on the IGUANA Gatew

6.1 Choosing an Appropriate SOAP Framework . . . . . . . . . . . . . . . . . . . 82

6.2 Parsing OPC XML-DA Compliant SOAP Messages . . . . . . . . . . . . . . . 84

6.3 Implementing OPC Server Functionality . . . . . . . . . . . . . . . . . . . . . 87

6.4 Handling of the IGUANA Protocol . . . . . . . . . . . . . . . . . . . . . . . . 93

I

7 Analysis of the SOAP Protocol in Internet/Fieldbus Gateways 967.1 Compatibility and Interoperability of an OPC server on the IGUANA gateway 967.2 Performance and Scalability of the IGUANA OPC Server . . . . . . . . . . . 1007.3 Efficiency of the SOAP Protocol in Fieldbus Access . . . . . . . . . . . . . . . 104

8 Conclusion and Future Work 107

Bibliography 109

II

1 Introduction

Businesses today consist of many different branches, such as shops, production, managementand others which are often situated in various locations. Organizing, coordinating and con-trolling these different branches efficiently is one of the keys to a successful business. Inthis context, one important aspect is communication, so that different enterprise entities areable to exchange information. For instance, a shop may report consumer satisfaction to themanagement, which may then use this information to optimize the production.

Nowadays information is most often transported electronically, therefore computer net-works are an appropriate solution for solving the communication aspect. However, for suc-cessfully establishing such networks, a suitable technological perspective on the enterprisehas to be chosen. From the engineering point of view, enterprises are structured in multiplelevels, as depicted in figure 1.

Company Level

Factory Level

Shop Level

Cell Level

Process Level

Field Level

Figure 1: Different levels in an enterprise

Establishing the seamless integration of these different levels was the main goal of variousefforts in industrial automation. The key to success is the availability of information betweenall levels, as also stated in [WER03]. For instance, the company level should be able toretrieve data from the process level, while the shop floor level may need information from thefactory level.

One well known approach is computer integrated manufacturing (CIM), which introducesthe automation pyramid, which consists of four to six levels in an enterprise. Every level isassociated with a certain functionality and suitable networking technology. These differentnetworks are interconnected to form a complete multilevel networking topology. An in-depthdescription of CIM can be found in [HAR73].

Due to the introduction of new technologies, especially in the networking domain, theengineering viewpoint has changed over time. Therefore the CIM pyramid can today be seenas a three-level hierarchy, as shown in figure 2.

ERP - Enterprise Resource Planning

MES - Manufacturing Execution System

Control Level

Figure 2: Three-level hierarchical information structure in industrial automation

At the top of the hierarchy is the Enterprise Resource Planning (ERP), which deals withstrategic and long-term planning. Below is the Manufacturing Execution System (MES),which is concerned with short-time production planning. At the bottom of the hierarchy isthe control level, which accomplishes all low level tasks of the manufacturing process, suchas controlling sensors and actuators. This topic is further examined by [SAUT05].

For a comprehensive integration of these three hierarchical levels, information has to beexchanged between levels, which is the goal of vertical integration. To achieve this, twoseparate aspects have to be addressed, as denoted in [SAUT05]:

1

1 INTRODUCTION

1. Communication: Different levels in an enterprise often use different networking tech-nologies. Interconnecting these different networks is a major step in vertical integration.

2. Application: In an enterprise, the same information may be represented in differentways. The information in ERP, for example, focuses on the business aspect of an enter-prise, while the control level has to deal with technical details, such as sensor/actuatordata. For this reason, the underlying format in which such information is stored isoptimized for the specific task in the enterprise level and will be syntactically and se-mantically different from the format in the control level. For vertical integration, thesedifferent formats have to be translated or generalized so that applications in differentlevels can communicate which each other.

On the ERP and MES levels, Internet networking technologies, such as the InternetProtocol (IP) are most commonly used today. Therefore the communication aspect does notconstitute a problem. Today the application aspects on this level are already solved to somedegree, although various issues are still in research status. Further information about thistopic can be found in [WER03].

On the other hand, there is still a huge gap between MES and the control level. Asthe functionality and requirements for the underlying technologies vary between these levels,the networks used are different. As shown above, the MES level uses common Internettechnologies for networking, which is, however, unsuitable for the control level due to lack ofreal-time abilities and other reasons.

In the last decades, fieldbuses – often also called “Field Area Networks” (FAN) – wereestablished as the most common communication technology in the control level. Fieldbusesare industrial communication systems and are designed to interconnect a variety of field de-vices, such as sensors and actuators. They are designed to operate in rough environments, asoften found in manufacturing areas. They are capable of handling data in real time, meaningthat the transmission time of data can be predicted and constrained. Moreover, fieldbusequipment is designed to be very cost effective, enabling the technology to be ubiquitous inthe manufacturing environment.

Although many different fieldbus technologies exist, a common way of looking at them isillustrated in figure 3: various devices, called fieldbus nodes are interconnected by a fieldbusnetwork. Data can be represented by so-called “data points”, which are assigned to a fieldbusnode and contain a piece of information, such as sensor or actuator data. These data pointsare associated with underlying devices, such as actuators/sensors and can be read and written,hence establishing control of these devices.

Node Node

Fieldbus

Data

point

Data

point

Data

pointData

point

Data

point

Figure 3: Fieldbus with Nodes and Data Points

There is a variety of different fieldbus systems available, each with its specific strengths andweaknesses. Different fieldbus systems are most often incompatible, therefore interconnectingsystems based on such different technologies is often a tedious task.

2

1 INTRODUCTION

One aspect that is important for the success of vertical integration is the connectivitybetween fieldbuses and IP networks1.

As described by [LOB06], interconnecting these two networks may be done in two ways:

Tunneling: A device that encapsulates one networking protocol into the other is set up be-tween two different networks, so that data can be transported through another network.The receiving side extracts the encapsulated data and may handle it as if it was con-nected to the sending network. This mechanism is called tunneling and is transparent,because the sender and receiver may communicate through this tunnel as if they wereconnected to the same network.

The advantage of this concept lies in its simplicity: the communication aspect can besolved quite easily as encapsulating one protocol into another is not very complicated.However, certain network functionality, such as predefined delays and real-time abilities,may be lost due to the transport over the other network.

The application aspect, on the other hand, is not addressed at all, as the receivingside is able to handle the original data. This way either the fieldbus has to implementInternet specific protocols or the application on the ERP/MES side has to handle thefieldbus specific protocol. This is also the disadvantage of this concept, as the endpoint has to implement the networking protocol of the sender. In vertical integration,implementing lower level protocols in higher levels is a bad solution as the applicationaspect is still unsolved and is merely shifted to another level.

Therefore tunneling solutions are not very widespread and are most often be usedwhere applications need in-depth access to the foreign network. For instance, specificfunctionality such as fieldbus configuration from upper enterprise levels may be solvedby tunneling.

Gateways: Gateways are nowadays the most common technique of interconnecting fieldbusand IP-based networks. Figure 4 shows where such an Internet/fieldbus gateway willbe placed.

Node Node

Internet

Fieldbus

Client

Internet to

fieldbus

protocol

Gateway

Figure 4: Internet/Fieldbus Gateway

As mentioned above, interconnecting networks consist of communication and applica-tion aspects. The communication aspect is relatively easy to manage: the gateway

1It should be mentioned that Ethernet-based solutions, commonly known as Industrial Ethernet, are emerg-ing, which can be seen as an alternative to fieldbus technologies. Although a direct connection between Indus-trial and legacy Ethernet is most often not possible, establishing vertical integration may proof to be easierwith this technology.

3

1 INTRODUCTION

should look like an IP device from the Internet side, while it should be able to integrateinto the fieldbus as any other FAN node. Therefore the gateway will have to implementboth networking protocols. Gateways are often implemented on embedded hardware,on which both networking protocols can be implemented without much effort.

The application aspect is more complex. Fieldbus specific data has to be presented ina way so that upper-level applications can understand and handle it. The situation iscomplicated by the fact that various different fieldbus technologies exist with varyingfunctionality, providing data in different ways. Upper-level applications should mostoften not deal with fieldbus specifics, therefore a way has to be found to representfieldbus data in a general, abstract way.

A common solution is to specify an Internet interface that defines the semantics andsyntax of fieldbus access. Such an interface tries to generalize functionality and datarepresentation of fieldbus systems so that the interface can be used for a variety offieldbus technologies. Moreover, this interface has to specify a protocol which can beused to transport fieldbus data over IP networks. As there are already various Internetprotocols available, it is appealing to use an existing one that suits the needs of such afieldbus/Internet gateway interface.

The traditional approach in distributing information across the Internet is to store dataon servers, which can then be retrieved by clients, which format and present this data tothe user. One well known example is the Hypertext Markup Language (HTML) and itsassociated protocol, the Hypertext Transfer Protocol (HTTP), which is certainly the mostcommon technique of transferring information across the Internet. Although HTML andassociated technologies are well suited to displaying information to users, it is inappropriatefor communication between software applications.

Internet connectivity will soon be available for all sorts of devices such as householdappliances, multimedia systems, cars and also equipment and devices in the industry, makingthe Internet ubiquitous in the near future. Internet applications will be placed on thesedevices that have to exchange information which they have to process and understand. Forinstance, a heating system may periodically retrieve weather information from a centralizedweather station over the Internet to optimize its operation. Another example would be asmart refrigerator that may automatically order food from a store when it gets empty.

To establish successful machine to machine communication, suitable communication for-mats and protocols are needed. The key to success seem to be the following points:

Interoperability: As denoted above, different applications should be able to interoperate.Standardization is an important aspect in establishing interoperability, therefore for-mats and protocols will have to be thoroughly specified, so that different developerscan build interoperable applications.

Discoverability: To establish successful communication between applications, developershave to understand the meaning of the data being sent. Therefore communicationformats should have self-describing abilities so that developers can easily implementapplications on top of these communication formats.

Easy to implement: Ease of use and rapid application development is a key feature ofsuccess. The communication format should be designed in a way so that softwareframeworks can be used to automatically generate functionality, which can then beeasily integrated into the custom application.

4

1 INTRODUCTION

Historically, there have been various technologies and protocols that were designed tofulfill these needs. However, none of them proved as a universal solution.

Today, the common opinion is that a new technology, called “Web Services”, will bethe solution to the requirements above. Web services are designed to provide a high levelof interoperability while covering a variety of communication aspects. They use the so-called “Extended Markup Language” (XML) as their key technology, which is nowadays seenas the most promising communication format, enabling developers to create self-describingdocuments. Moreover, Web services have simplicity in mind and are therefore allowing easyaccess of underlying services.

Figure 5 illustrates the difference between traditional Internet communication, where aclient application retrieves and displays information, and the Web service approach whichconsists of various ubiquitous, interoperating applications.

Server

Internet

Client

Server

Server

Internet

Web Service

Web Service Web Service

Web Service

Figure 5: Classical Internet Communication Versus Web Services

Regarding the Internet interface of an Internet/fieldbus gateway, it can be observed thatthe requirements are very similar to the needs of interoperating Internet applications. In-teroperability, discoverability and simplicity are key aspects of a successful communicationbetween fieldbus and IP networks, too.

Therefore Web services are nowadays seen as a suitable technology for an Internet interfaceon Internet/fieldbus gateways. In fact, there are already various standards and solutionsavailable which are based on this technology.

This thesis examines in which ways Web services may be applied to Internet/fieldbus gate-ways, how well they interoperate and perform and if they are really a solution to limitationsof traditional technologies.

5

2 Principles of SOAP Web Services

Unfortunately there is no unique or exact definition which exactly explains what a WebService really is.

In the UDDI2 section in [WAL02], Web Services are defined thus: “A Web Service is aself-describing, self-contained, modular unit of application logic that provides some businessfunctionality to other applications through an Internet connection. Applications access WebServices via ubiquitous web protocols and data formats, such as HTTP and XML, with noneed to worry about how each Web Service is implemented. Web Services can be mixed andmatched with other Web Services to execute a larger work flow or business transaction.”

[LIV02] uses a far simpler explanation: “A Web Service is the name for a method orfunction that is available for other applications to access over the Internet.”

According to Mark Colan (IBM), Web Services are “Internet-based modular applicationsthat perform a specific business task and conform to a specific technical format.”

Another definition would be that a Web Service is simply a node of a distributed comput-ing environment. To clarify things, here is a typical example where the use of a Web Servicemakes sense:

A software company develops a banking application that has to handle multiple curren-cies. The conventional way would be to implement some kind of currency converter functionand store the required exchange rates somewhere in the application as depicted in figure 6.The problem with this approach is that the exchange rates have to be updated regularly,new currencies have to be added from time to time and program code like the conversionalgorithms have to be maintained.

Banking Application

Currency

Converter

functions

Exchange

rate data

Figure 6: Conventional implementation of a banking application with a built-in currencyconverter.

The Web Service approach offers a different way of dealing with the situation. Theprogrammer does not implement the needed functions himself, but tries to locate an existingand appropriate Web Service that fulfills his needs. Therefore the programmer first looksat a central Web Services registry, called “UDDI Business Registry”. One can picture thisregistry as some kind of yellow pages which not only hold information about the businessthat provides the service but also a technical description and the technical location, suchas a URL. Once the software developer has found a Web Service which implements fullyfunctional currency functions, he contacts the company which operates the Web Service andgains the right to use it for his application.

The next step for the programmer is to access the Web Service from his application.The Web Service approach implements a special language, called “WSDL”3, which is used to

2UDDI stands for “Universal Description, Discovery and Integration” and is a standard which deals withthe discovery of Web Services. UDDI is further described in section 2.5.

3WSLD stands for “Web Services Definition Language” and is a standardized language which can be usedfor describing technical issues of Web Services. WSDL is further described in section 2.4.

6

2 PRINCIPLES OF SOAP WEB SERVICES

define the technical details of a Web Service. Special tools can directly generate source codefrom these definitions. Hence the programmer downloads the WSDL file and generates theneeded code which he can then integrate into his application.

In this manner, the banking application uses the Web Service for all currency issues asshown in figure 7, which greatly reduces the maintenance and therefore also the costs. Theupdating of currency exchange rates and the maintenance of the currency functions are doneby the Web Service provider.

Currency

Converter

functions

Exchange

rate data

InternetBanking

Application

Web Service Company

Figure 7: Banking application accessing a Web Service providing currency functions.

As seen from the above, the developer does not have to cope with SOAP. SOAP is fullytransparent, it is used for the actual transmission of data between the application and theWeb Service. Although this process is invisible to the developer and user, SOAP has animportant role in the Web Service model. Every piece of data that travels between a WebService and a client program is embedded in SOAP packages and there are many requirementsthat SOAP must fulfill. This will be described later in this chapter.

The example shows that Web Services are a unique approach to distributed computing,which is a key feature for many businesses, especially for those offering services on the In-ternet. A short analysis of well known web sites, such as Yahoo or Google, shows that thepages are composed of content that emerges from many sources. To give an example, a newsservice like CNN offers its content via a Web Service, perhaps as a so-called RSS4 news feed,and other web sites can then query this service and embed the news headlines in their pages.

From a technical perspective, distributed computing is not new, hence there are already alot of protocols and programming frameworks that simplify the implementation of distributedcomputing environments. The idea of all these programming environments is to hide the ac-tual transmission between the computing nodes from the programmer and let him call remoteprocedures just as he would call local routines. The implementation of this simplification re-lies on abstract interface definition languages (“IDL”) which enable programmers to describeand define interfaces between the computing nodes. These IDL definitions can then be usedto generate source code, called stubs or skeletons that can then be integrated into applica-tions which deal with the communication between computing nodes. This communicationbetween the nodes is transparent to the user and relies on specific communication protocolswhich enable passing data, function parameters or serialized objects between the distributednodes. Here is a short overview of the most common distributed computing environmentswhich can be regarded as predecessors of SOAP Web Services:

Sun/ONC RPC: This is one of the oldest distributed computing environments and datesback to 1988. It concentrates on remote procedure calls (RPC) and was developedby the Sun Microsystems Open Network Computing (ONC) group. It provides its ownlanguage, called “RCP Language”, which is used to generate stubs by a specific compiler

4RSS stands for “Really Simple Syndication” and is used for distributing news and the content of news-likeWeb Sites.

7


called “rpcgen”. ONC RPC uses a simple request/response communication protocoland is limited to TCP and UDP5. Although it is quite old and has several limitations itis still quite popular as it is distributed with most UNIX operating systems. Moreover,the well known network file system “NFS” utilizes ONC RPC. Further informationabout ONC RPC can be found in [BLO91].

DCE: The “Distributed Computing Environment” (DCE) is a more recent approach thanONC RPC and already implements a feature rich IDL bundled with a compiler thatgenerates stubs. Like ONC RPC, it has a specific protocol which relies on a simplerequest/response architecture. DCE is developed by a vendor-neutral, internationalconsortium called the “Open Group”. DCE not only implements RPC, it also providesdirectory services (CDS/GDS), distributed file service (DFS) and more. An introduc-tion to DCE is given in [BLO91].

CORBA: The Common Object Request Broker Architecture (CORBA) is an attempt tostandardize distributed computing between a wide range of platforms and applicationenvironments. CORBA utilizes a so-called “Object Bus”, called “ORB” which providesthe communication infrastructure to send and receive requests and responses betweendistributed computing nodes. CORBA also utilizes an IDL which is platform and pro-gramming language independent and is used to generate stubs which are then integratedinto applications. CORBA also implements a specific protocol, called IIOP which isused for all transfers between computing nodes. Due to its platform independence,CORBA has been widely adopted by the industry but suffers from its complexity andhigh initial investments regarding the training and deployment of this architecture. Anin-depth analysis of CORBA can be found in [TAR01].

DCOM: The origin of this protocol lies in the development of a communication protocol(COM) between Microsoft Windows applications. The next step was the “DistributedComponent Object Model” or DCOM which provides a distributed computing envi-ronment for the Microsoft Windows platform. DCOM will over time be replaced byMicrosoft’s .Net initiative which relies heavily on SOAP Web Services. Further infor-mation about DCOM can be found in [RED97].

Java RMI: This is a Java specific Framework developed by SUN Microsystems for imple-menting distributing computing in a Java environment. It utilizes a specific protocol,called JRMP. Moreover, it also embraces CORBA through an additional protocol calledRMI-IIOP that provides interoperability with CORBA components. Further informa-tion on Java RMI can be found in [GRO01].

XML-RPC: XML-RPC is not a framework like the ones listed above, but it is a simpleXML-based RPC protocol which is standardized by the W3C consortium and is aviable alternative to SOAP. It is quite popular due to its simplicity and is utilized bymany applications that use this protocol for RPC calls. An in-depth description of thisprotocol is given in [LAUR01]

All of these protocols have their strengths and weaknesses, some do not scale very well,others are difficult to implement and to debug and others are simply not broadly accepted.

5The “Transmission Control Protocol (TCP) and “User Datagram Protocol” (UDP) are commonly usedtransport protocols in combination with the network protocol “Internet Protocol” (IP). A good introductionto these protocols is given in [TAN02]

8


Therefore these techniques are not fully satisfactory for a broadly acceptable distributedcomputing environment.

The industry in cooperation with W3C6 focuses on a holistic solution to this problem byspecifying several standards that build a framework for providing and interconnecting servicesin an open and well defined way. Most of these standards are based on XML7. Services thatuse this framework are called “Web Services”.

A distributed computing environment like a SOAP Web Service has to fulfill many re-quirements. The W3C consortium has reduced these demands to three basic needs:

1. Locating Web Services or Web Service providers.

2. Describing the Web Service in a common, extensible way.

3. Representing the message in a common, extensible format.

For these key requirements the W3C has created three standards in cooperation with theindustry : UDDI, WSDL and SOAP, which will be described in the next sections. Thesestandards are all based on XML and form the basic framework for Web Services. Thesetechnologies and their underlying protocols can be applied to the OSI reference model8 asshown in figure 8.

UDDI

WSDL

XML

SOAP

HTTP, SMTP, ...

TCP, UDP, ...

IP, IPX, ...

HDLC; PPP, 802.x, ...

Modem, ISDN, xDSL, ...

Directory Layer

Interface Layer

Application Layer

Presentation Layer

Transport Layer

Data Link Layer

Application Layer

Figure 8: Web Service Technologies in the OSI Reference Model

2.1 XML - Extended Markup Language

The World Wide Web (WWW) as we know it consists of computing nodes serving documentswhich contain information. These documents are stored in several data formats, most oftenin the “Hyper Text Markup Language” (HTML). Other data formats are proprietary andcan only be read by specific applications. Many of these data formats describe presentationissues but most often do not deal with the meaning of the document. [DAC01] points outthat this leads to information overload and poor content aggregation.

6The World Wide Web Consortium was created in October 1994 to lead the World Wide Web to its fullpotential by developing common protocols that promote its evolution and ensure its interoperability. W3Chas around 450 member organizations from all over the world and has earned international recognition for itscontributions to the growth of the Web.

7XML is a markup language like HTML and is a subset of SGML. XML is further described in section 2.1.8The OSI reference model, developed by the International Standards Organization (ISO), is a standard

reference model for networking protocols used in various layers. For further references see [TAN02].

9


To overcome these problems, documents have to be structured and the meaning of thecontained data has to be added. One mechanism for doing this is markup. [XML1] states“Markup is a method of conveying metadata (information about another dataset).” AllSGML-based9 languages use so-called “tags” for separating pieces of information into so-called “elements”. These tags add the needed metadata for describing the meaning of theelements.

One widely adopted markup language is the “Hyper Text Markup Language” (HTML),which is currently used for most of the documents available on the Internet. HTML containsa fixed set of tags that are used to add formatting and presentation logic to documentsbut lacks the possibility to define new tags which is required to add other than formattingmetadata to documents.

In the end of the 1990s the World Wide Web Consortium designed an extensible markuplanguage called “Extended Markup Language” (XML) that combines the flexibility of SGMLand the widespread acceptance of HTML.

The basic structure of an XML document is best explained by a simple example as givenin Listing 1. The first line is a so-called “processing instruction” (PI) and provides commandsand information to the XML parser. In this case the parser is told that the document compliesto the XML 1.0 standard. The third line is a comment that is used for documentation purposesand is ignored by the parser.

The rest of the document consists of various elements which are arranged in a “1:n”parent/child structure10. The first element – the XML standard calls it the “root element” –opens with the tag currency list and has an attribute which specifies its date. The contentsare multiple currency elements which also have attributes and contain other elements. XMLdocuments can be modeled in a tree-like structure as shown in figure 9.

1 <?xml version=” 1 .0 ”?><c u r r e n c y l i s t date=”04/13/05”>

3 < !−− Currency l i s t and exchange r a t e s −−><cur rency number=”01” va l i d=”1”>

5 USD<name>United Sta te s Do l l a r</name>

7 <change>1 .0</change></ currency>

9 <cur rency number=”02” va l i d=”1”>EUR

11 <name>Euro</name><change>0.779907</change>

13 </ currency><cur rency number=”03” va l i d=”0”>

15 ATS<name>Austr ian S c h i l l i n g</name>

17 <change>10.73175</change></ currency>

19 </ c u r r e n c y l i s t>

Listing 1: Simple XML Code

XML has the following key features:

9The “Standard Generalized Markup Language” (SGML) was developed in the 1970s and is a very matureand flexible but also quite complex markup language. Most of today’s markup languages are based on SGML.

101:n means in this context that each child has exactly one parent but a parent can have zero, one or multiplechildren.

10


currency_list

(document root)

currency

name changeiso

currency

name changeiso

currency

name changeiso

Figure 9: XML tree of the given example.

Extensible: An important issue of XML is that tags can by freely specified. This meansthat metadata of any kind can be added to XML documents.

Legible to humans /easy to create: XML documents are normally created and editedby specific tools, called “XML parsers” but there can be specific cases (e.g. debuggingor testing) where the documents have to be edited by hand. XML has the advantagethat it is legible to humans, moreover, there are editors available that support syn-tax highlighting and structuring of the document, which makes the editing of XMLdocuments very easy.

Verification of syntax and semantics: XML documents can be checked for syntactic andsemantic correctness by the XML parser. If the document is syntactically correct, itis called “well formed”, which means that it fulfills the XML standard. To check thesemantics of a document, the user has to supply information about the document’sstructure and its grammar to the XML parser, which is then used for validation. Forthis task, the XML standard suggests two formal description languages, namely the“Document Type Definition” (DTD)11 and “XML Schema”, which is explained in sec-tion 2.2.

Namespaces: When combining structures with different vocabularies into one document,naming conflicts can occur. XML solves this problem with the use of so-called names-paces. [BIR01] describes namespaces like this: “An XML Namespace is simply a groupof names, usually with a related purpose or context, where the group has a globallyunique name (the “namespace name”). This is often ensured by using a domain name(from Internet DNS) as the first part of the namespace name.” The namespace conceptis best described with a simple example, given in listing 2. Here two namespaces aredefined which refer to two different vocabularies which both contain the word ISO buthave a different meaning. With the namespace prefixes cur: and cnt: these two wordscan be distinguished.

1 . . .<cur : cu r r ency xmlns :cur=” h t tp : //www. qwer . tk /ns/ currency”

3 country xmlns :cnt=” h t tp : //www. qwer . tk /ns/ country”>

11DTD is also derived from SGML and is part of the XML standard. The syntax of DTD is similar to XMLbut is not XML compliant, moreover, it has various limitations, such as lack of extensibility and weak datatyping. DTD is commonly used today but is expected to be replaced by XML Schema in the near future.Further information about DTD can be found in chapter 5 of [BIR01]

11


<c u r : i s o>USD</ c u r : i s o>5 <c n t : i s o>US</ c n t : i s o>

</ cur : cu r r ency>7 . . .

Listing 2: XML Namespace Example

XML has gained broad acceptance and is used in various fields. Many data formats,languages and protocols are XML-based and it is expected that XML will obsolete variousother data formats. The protocols and languages described in the next sections are all XML-based.

2.2 XML Schema

Distributed computing environments have to transport data in various formats. This dataoften has to be validated before it may be processed. For this task the W3C consortium hascreated a standard called “XML-Schema”, which is the successor of DTD and is a powerfuland flexible XML-based language. [VLI02] describes XML Schema as follows:

“An XML schema language is a formalization of the constraints, expressed as rules or

a model of structure, that apply to a class of XML documents. In many ways, schemas

serve as design tools, establishing a framework on which implementations can be built. Since

formalization is a necessary ground for software designers, formalizing the constraints and

structures of XML instance documents can lead to very diverse applications. Although new

applications for schemas are being invented every day, most of them can be classified as

validation, documentation, query, binding, or editing.”

Web Services most often depend on remote procedure calls where parameters have to bepassed to remote methods where they are processed. These parameters emerge from programswritten in computer languages which use variables that are assigned to specific data types,such as strings or integers. When such variables are encoded in an XML document, it isimportant that the information about the data type is not lost. XML Schema offers a varietyof data types that can be used for encoding data so that the receiving Web Service can decodethe transmitted parameters and hand them to the requested method.

XML Schema data types are separated into so-called “simple types” and “complex types”.Simple types describe elements that contain only one value and no attribute, such as <value>

36</value> and therefore represent basic data types like integers or strings12. Complex typesdescribe elements that may contain other elements and/or attributes.

An overview of the most commonly used data types provided by XML Schema is depictedin figure 10.

Listing 3 shows a possible XML Schema for the XML Document in listing 1. Line 3 ofthe listing defines the complex element currency, which contains the three elements iso,name

and change. Line 6, 7 and 8 define the data types for these elements and in line 10 and 11the possible attributes for the element currency are defined.

<?xml version=” 1 .0 ”?>2 <xsd:schema xmlns :xsd=” h t tp : //www.w3 . org /2000/10/XMLSchema”>

<xsd :e l ement name=” currency”>4 <xsd:complexType>

<xsd : sequence>

12It is also possible to define custom simple types, such as strings with a fixed length, or even use regularexpressions for defining patterns which the elements must match.

12


anyType

All complex types anySimpleType

dateTimestring booleanhexBinary float double anyURIdecimal

Integer

long

short

byte

int

nonNegative

unsignedLong

unsignedInt

nonPositive

negativeInteger

normalized

token

language name NMTOKEN

Figure 10: Common data types provided by XML Schema.

6 <xsd :e l ement name=” i s o ” type=” x s d : s t r i n g ”/><xsd :e l ement name=”name” type=” x s d : s t r i n g ”/>

8 <xsd :e l ement name=”change” type=” x s d : f l o a t ”/></ xsd : sequence>

10 <x s d : a t t r i b u t e name=”number” type=” x s d : i n t e g e r ”/><x s d : a t t r i b u t e name=” va l i d ” type=” xsd :boo lean ”/>

12 </xsd:complexType></ xsd :e l ement>

Listing 3: Simple XML Code

In order to check the validity of an XML document it has to be linked to a correspondingXML Schema document. Listing 4 shows how the basic XML example in listing 1 has to bemodified.

1 . . .<cur rency number=”01” va l i d=”1”

3 xmlns :x s i=” h t tp : //www.w3 . org /2000/10/XMLSchema−i n s tance ”xsi:noNamespaceSchemaLocation=” currency . xsd”>

5 USD<name>United Sta te s Do l l a r</name>

7 . . .

Listing 4: Linking to a XML Schema document

XML Schema is a powerful method of constraining the content of XML documents. Itsflexibility and extensibility makes it possible to validate various kinds of XML documents.One problem of XML Schema is that constraining content with a complex structure resultsin even more complex XML Schema documents that can be difficult to read and maintain. Insuch cases a thorough design and accurate documentation of the schema is very important.An in-depth reading about XML Schema can be found in [VLI02].

2.3 SOAP - Simple Object Access Protocol

SOAP stands for “Simple Object Access Protocol” and is a standardized and extensiblemessaging framework for exchanging structured information between distributed computingnodes. SOAP is most often applied to remote procedure calls (RPC) scenarios and therefore

13


ideally suits to the communication between Web services. This new protocol has the followingkey features:

Interoperability: First and foremost, the purpose of a protocol such as SOAP is inter-operation, giving users and developers choice, eliminating lock-in, and keeping themarket open to all size organizations, commercial and open source development, indi-vidual developers and hobbyists. The so-called serializer transforms language specificdata types into SOAP or XML Schema datatypes13. The use of these standardizeddatatypes in combination with SOAP libraries makes it possible to use the same com-plex datatypes with Web Services that are coded in different programming languages.

Strict standards compliance: SOAP is standardized by the W3C consortium, currentlyin versions 1.1 and 1.2. Key industry players like IBM and Microsoft are participantsin this consortium.

Discoverability: The use of XML makes it possible for developers with basic XML andSOAP knowledge to look at the transmitted data of a SOAP procedure call, understandits techniques and it enables them to modify and employ it fairly quickly.

it’s doing, and be able to modify it and have it work on the first or second try.

Firewalls: SOAP is designed to bypass firewalls to improve the reachability of SOAP WebServices. Firewall software can watch for POSTs whose Content-Type is text/xml or(even better) watch for the presence of a SOAPAction header14 and apply whateverpolicies they see fit.

Easy to implement: Web Service developers who want to use SOAP do not have to en-code/decode the protocol by themselves. Quite on the contrary, the SOAP protocolis transparent to them. This is accomplished by special SOAP libraries that exist forseveral programming languages. With their use, accessing or providing Web Servicesis nearly as easy as writing a function header. The SOAP library does all necessarytasks, like communication, serialization of data and error handling.

The underlying transport protocol: SOAP messages can be transported by various pro-tocols like the following:

HTTP: The Hyper Text Transport Protocol (HTTP) is the most commonly used vari-ant for transporting SOAP messages and is defined in [R2616]. HTTP is properlystandardized and widespread. This connection-oriented protocol implements asimple request/response mechanism and is therefore ideally suited to SOAP WebServices issuing RPC calls.

SMTP: The Simple Mail Transport Protocol (SMTP) is also capable of transport-ing SOAP messages. It is defined in [R2821]. SMTP is not designed for fastresponse times, quite on the contrary, its store and forward technology is designed

13Serialization means that language specific data types are transformed into an independent format, e.g.into text format. As this independent format is strictly defined by SOAP it can easily be de-serialized into datatypes of another language. To fulfill this task, the SOAP standard defines various data types, like integers,strings or arrays that can be mapped to their corresponding counterparts in any high level programminglanguage, like C/C++, Java or script languages like Perl or Python.

14The SOAPAction header element can be used for indicating the purpose and/or destination of a SOAPmessage. It can only be applied to SOAP messages that are transported via the HTTP protocol.

14


for transporting messages through various SMTP gateways to their destination.SMTP messages can have long delays but the delivery is very reliable. Thesefeatures make SMTP well suited to asynchronous SOAP messages.

Although most SOAP frameworks are limited to these two transport protocols, mosttasks can be accomplished with them. Nevertheless, SOAP can theoretically be trans-ported with different underlying transport protocol, which will significantly enrich itswidespread use and acceptance.

Any SOAP message consists of three building blocks, which are depicted in figure 11.

SOAP Envelope

SOAP Header

(optional)

SOAP Body

Figure 11: The basic building blocks of a SOAP message.

SOAP Envelope: This part contains the entire SOAP message and contains the SOAPHeader and SOAP Body. This element is mandatory and has to have a namespace thatdefines which SOAP version is applied to the current message.

SOAP Header: This section of the SOAP message is optional but must be the first XMLelement if it is present. Information in this part is interpreted by the SOAP processorwhich can e.g. be used to implement state-fulness that is not provided by the underlyingprotocol15. The SOAP processor needs not necessarily understand the header contents.If this is mandatory, a special flag, called “mustUnderstand” can be set to force theSOAP processor to either process the header contents or to dispose the whole SOAPmessage. Moreover, the SOAP Header contains the so-called SOAP Actor which willbe described in detail later.

SOAP Body: This section is the place where the data for the receiving or sending applica-tion is situated. This section is mandatory in a SOAP message. When using SOAP forremote procedure calls, there are three kinds of SOAP bodies:

1. Request: This message provides the method name of the called Web Service andits input parameters. The first element of the SOAP body specifies the name ofthe called method. The following elements are parameters that are required toprocess the request.

2. Response: A SOAP response message is the counterpart of a request message.It has also to provide the method name with the string “Response” added anddelivers the requested output parameters of the called method to the queryingapplication.

15 For example, HTTP does not by itself support state-fulness, which is often required for transactions orauthentication purposes.

15


3. Fault: If an error in the called method occurs, the method answers with an errormessage, which is called a “SOAP Fault”.

These three building blocks fulfill all the needs to a convenient message format for dis-tributed computing nodes. Listing 5 depicts a simple SOAP message which could be a requestmessage from a banking application to a Web Service that calculates exchange rates. In line1 the envelope is declared which embeds the body which starts in line 2. Line 3 specifiesthe name of the invoked method and declares a proprietary namespace which is used by thisspecific Web Service. Line 5 specifies the encoding style, which is explained in section 2.3.3.Lines 5 to 7 are parameters which are passed to the called method.

1 <s :Enve lope xmlns : s=” h t tp : //www.w3 . org /2001/06/ soap−enve lope”><s:Body>

3 <q:curConvert xmlns:q=” h t tp : //qwer . tk /ns/ currency”s : e n c od i ngS ty l e=” h t tp : //www.w3 . org /2001/06/ soap−encoding ”>

5 <q:from−i s o>USD</q:from−i s o><q : to−i s o>EUR</ q : to−i s o>

7 <q :va lue>7 .23</ q :va lue></ q:curConvert>

9 </ s:Body></ s :Enve lope>

Listing 5: Example of a simple SOAP message

2.3.1 Message Passing

Fulfilling tasks in a distributed computing environment may involve more than only twonodes. A simple client-server model will not suffice for more complex tasks. A simple examplewould be an automated home where a light bulb breaks and the system automatically ordersa replacement. To accomplish the order, a SOAP message is generated by the node that isresponsible for the light. This message contains the type of the needed replacement. TheSOAP message is then forwarded to a main system where appropriate data is added to theoriginal message, like the name and address of the customer and is then forwarded to a WebService at the service center that processes the request and confirms the order.

To accomplish this desired behavior, SOAP messages have to be capable of travelingthrough several nodes that may modify the SOAP body until it reaches its final destination.Therefore a special XML element in the header, called “SOAPActor”, is provided by theSOAP definition. Each node that the SOAP message has to pass is listed in the SOAPheader element that contains a suitable SOAPActor16 element. Whenever a node receivesa SOAP message that contains a header field with a matching SOAPActor, it processes therequest, removes the appropriate header element, modifies the SOAP body and forwards thealtered message to the next actor or node. This procedure continues until the SOAP messagereaches its final destination as depicted in figure 12.

2.3.2 Error Handling

For a successful client-server communication, the underlying protocol has to provide extensiveand extensible error handling. SOAP fulfills this task by defining a so-called “fault message”which includes four specific fault elements:

16A SOAP node can contain any numbers of actors, in other words, a node can play the role of severaldifferent SOAP Actors. [LIV02] describes this in a more specific way: Actor role = SOAP node functionality.

16


SOAP Client Node

Actor

Actor

Node

Actor

Actor SOAP Server

Figure 12: SOAP messages travel along multiple SOAP nodes

1. Faultcode: This element is mandatory and describes four main types of faults17:

VersionMismatch: The processing SOAP application found an invalid namespace forthe SOAP Envelope.

MustUnderstand: The receiving SOAP processor did not understand a header el-ement that was intended for that application and had the “MustUnderstand”attribute set.

Server: This error applies to situations where the server received a valid message butcannot process it due to a server specific error.

Client: In this case, the SOAP message itself contains errors that make it impossiblefor the server to process it.

2. Faultstring: This mandatory element contains a description of the error in human-readable text.

3. Faultactor: As a SOAP message can travel along many nodes with several actors, thiselement contains the actor where the error emerged.

4. Detail: If the error took place while the SOAP application processed the body, it hasto denote this application-specific fault in this element. This element is mandatory forSOAP Body specific errors and is absent when the fault occurred during the SOAPHeader processing.

Listing 6 could be a possible response to a request shown in 5 which produced an errordue to a corrupted database.

<s :Enve lope xmlns : s=” h t tp : //www.w3 . org /2001/06/ soap−enve lope”>2 <s:Body>

<s :Fau l t>4 <f a u l t c od e>Server</ f au l t c od e>

< f a u l t s t r i n g>Server Error</ f a u l t s t r i n g>6 < f a u l t a c t o r>h t tp : //qwer . tk / currency/curConvert</ f a u l t a c t o r>

<d e t a i l>8 <e r r : f a u l t D e t a i l s xmlns : e r r=” h t tp : //qwer . tk /ns/ f a u l t s ”>

<message>Currency Database Corrupted</message>10 <e r r o r code>123</ e r r o r code>

</ e r r : f a u l t D e t a i l s>12 </ d e t a i l>

</ s :Fau l t>14 </ s:Body>

17SOAP Faultcodes are meant to be extensible. That means specific error codes to these main four codes,such as “Client.AuthenticationError” or “Server.PowerFail” can be appended to these four generic Faultcodes.

17


</ s :Enve lope>

Listing 6: Example of a SOAP Fault

2.3.3 Encoding and Data Types

Data transmitted in a SOAP package has to be encoded in some way. SOAP itself permitsany encoding style in its body as far as it is XML compliant. For compatibility reasons, theSOAP specification suggests an encoding style in section 5 of the SOAP standard that iscommonly used.

SOAP encoding is based on XML Schema and inherits its built-in data types. However,some data types which are commonly used in common computer languages, like arrays orstructures are not covered in the XML Schema standard. The encoding of these data typesfor issuing remote procedure calls is mandatory, hence the SOAP standard itself specifiesthese specific data types.

Listing 7 shows a SOAP messages with SOAP encoded data. The data type of the elementis added by adding a specific attribute to the XML tag.

1 <s :Enve lope xmlns : s=” h t tp : //www.w3 . org /2001/06/ soap−enve lope”><s:Body>

3 <q:curConvert xmlns:q=” h t tp : //qwer . tk /ns/ currency”s : e n c od i ngS ty l e=” h t tp : //www.w3 . org /2001/06/ soap−encoding ”>

5 <q:from−i s o x s i : t y p e=” x s d : s t r i n g ”>USD</q:from−i s o><q : to−i s o x s i : t y p e=” x s d : s t r i n g ”>EUR</ q : to−i s o>

7 <q :va lue x s i : t y p e=” x s d : f l o a t ”>7 .23</ q :va lue></ q:curConvert>

9 </ s:Body></ s :Enve lope>

Listing 7: SOAP Encoding Example

Another variant of encoding SOAP messages is the encoding of data in anonymous tags,as shown in Listing 8. Here the name of the tag is not specified, so there is no meaningfulidentification of the element. This implementation works well with array data types wherethere is no need for naming the element.

. . .2 <SOAP−ENC:string>USD</SOAP−ENC:string>

<SOAP−ENC:string>EUR</SOAP−ENC:string>4 <SOAP−ENC:float>7 .23</SOAP−ENC:float>

. . .

Listing 8: Anonymous SOAP Encoding

An alternative to SOAP encoding would be to constrain SOAP message data by anexternal XML Schema document, similar to the examples in section 2.2. This way the SOAPMessage has to contain a reference to a proper XML Schema document or a namespace inwhich the data types of the elements are defined18.

18It should be noticed that these two approaches to the encoding of SOAP messages has caused someconfusion which has led to the development of SOAP frameworks that implement only one encoding standard.This has led to incompatibilities between different SOAP frameworks which greatly reduces interoperabilitybetween SOAP Web Services.

18


With the use of SOAP Encoding, serialization of various data types of common computerlanguages, like C/C++, Java, Perl or Python can be accomplished. Encoding is not machinedependent which greatly improves interoperability between Web Services. SOAP messagesare like any XML document human legible, so developers can easily debug common problemsby looking at the message itself.

2.3.4 Security

The basic SOAP standard itself does not specify any kind of security. Securing Web Serviceshas to be done in conventional ways, for example with SSL19, HTTP authentication or someother mechanism. An often criticized issue is that conventional firewalls cannot secure WebServices, as today’s firewalls can only filter traffic according to a protocol but do not under-stand what is inside the protocol. This way it is possible that a hacker packs his maliciouscode into a correct SOAP message which he then sends to a Web Service via the HTTPprotocol. The “hacker package” travels untouched through the firewall and then unveils hismalicious purposes. To solve this problem, Web Services have to be designed with securityin mind, moreover, smart firewalls are needed that are capable of understanding SOAP andfiltering malicious content in SOAP packages.

In many cases SSL does not suffice as this protocol is dedicated to point-to-point com-munication and SOAP messages may travel over multiple computing nodes. In such casesthe only solution is to secure the SOAP message itself. One way to implement such securitymeasures is to use a submitted standard called “SOAP Security Extensions” that heavilydepends on another standard called “XML-Signature”. This standard makes it possible toadd digital signatures to XML documents which ensures the integrity and authentication ofdocuments. Further information about this standard can be found in [LIV02].

2.4 WSDL - Web Services Definition Language

After finding the appropriate Web Service, the next step is to access it. To accomplish thistask, a technical description of the service is needed. This is where WSDL comes into play.WSDL stands for “Web Services Definition Language” and is a standardized and XML-basedlanguage for describing Web Services.

WSDL documents are typically not written by hand, they are merely generated withtools. The WSDL documents are then publicly offered along with the Web Service itself.When writing a client for a specific Web service which is described by a WSDL definition,the programmer can build a skeleton out of this definition with special tools that are includedin most SOAP frameworks.

Although most programmers will normally not create or read WSDL documents by hand,there can be cases where tools cannot be used which may also apply to certain applicationsin this thesis. This requires some basic knowledge of the WSLD language.

A WSDL document consists of certain sections that must be in a specific order. The basiccomposition of such a document is illustrated in figure 13. The meaning of these sections isas following:

Data types : This section defines what kinds of data types will be part of the Web Service.Data types could be integers, strings or arrays. Moreover, also special data types can

19The Secure Socket Layer (SSL) is commonly used together with HTTP and technically adds a securitylayer between HTTP and TCP. More information about SSL can be found in [THO00].

19


Data types

Messages

Parts

Port Types

Operations

Bindings

Services

Ports

Figure 13: The composition of a WSDL document

be defined. The data types definition has to follow the XML Schema syntax which isthoroughly described in [VLI02].

Messages: With this section it is possible to define the input and output parameters of aSOAP Web Service. Messages contain one or more “parts” that represent either anelement or a type20.

Operations: An operation is a well defined sequence of messages. This construct accom-plishes a correct exchange of messages. There are three possible types of operationmessages:

1. Input messages

2. Output messages

3. Fault messages

Input and output messages may occur not more than one time, hence it is not possibleto specify two input messages in one operation.

With this definition it is possible to establish “request-response”, “one-way”, “solicit-response” and “notification” operations. The most common type will probably bethe “request-response” operation, where the Web Service receives an input message(request) and answers with an output message (response).

Port types: This definition makes it possible to create sequences of operations, e.g. multiplerequest-response sequences. Operations have to be packed into a port type, also if thereis only one operation.

Bindings: After specifying data types and port types there still lacks an association with atransport protocol and a data format. This is accomplished with a so-called binding.The WSDL languag can describe bindings to any transport protocol and any dataformat. Anyway, the most commonly transport protocol will be HTTP and the mostoften used data format will be SOAP. Therefore the WSDL definition contains a HTTPand SOAP extension to simplify the WSDL specification procedure.

20XSD simple or complex types are allowed

20


Services: This element specifies the location of the Web Service. This is accomplished bydefining a so-called “port”21. In the port definition a WSDL binding is associated witha location, which could e.g. be a URL. One or more ports are then packed into a“service” element.

As stated above, the WSDL specification also covers a SOAP and HTTP extension asthese protocols will be most commonly described with WSDL.

SOAP extensions: This extension supports the SOAP data format, especially a way toconnect a binding to the SOAP protocol, the URI for the “SOAPAction” field in theHTTP header and a list of definitions for SOAP headers.

HTTP extensions: This extension makes it possible to bind messages to HTTP withouthaving to tie it to a certain data format.

Further information on WSDL can be found in [LIV02] and [WAL02].

2.5 UDDI - Universal Description, Discovery and Integration

The protocol and the technical description of a Web Service do not suffice for a widespreadembracement of this technology. Programmers know how to access services but a businessitself still needs a way to discover other Web Services and expose its own ones. The discov-erability of an offered Web Service is one of the main keys to its success.

This is where UDDI comes into place. UDDI is an abbreviation for “Universal Description,Discovery and Integration”. It is the first cross-industry attempt to address the currentlimitations afflicting the spread of Web Services. UDDI is not a W3C standard22 but usesmany technologies standardized by W3C like SOAP, XML and XML-Schema and other openstandards, like HTTP. UDDI is not limited to certain systems, instead it embraces diverseplatforms, operating systems and languages that exist on the Internet.

UDDI does not have an important role in this thesis as the discover-ability of fieldbusWeb Services is not very important because programmers who access these services alreadyknow where to find them. Nevertheless some basic knowledge of UDDI is needed to gain abetter understanding of the meaning and the sense of Web Services themselves.

UDDI can hold a lot of information about a business. Details about a specific WebService are just one part although more information is needed to find this specific service.All information in UDDI is stored in the so-called “UDDI Business Registry” as shown infigure 14. As this information is so diverse, it is broken down into three logical parts:

White Pages: The white pages contain basic business information, like the business name,its address, telephone number etc.

Yellow Pages: These pages contain further information about the business.

Green Pages: All technical information goes into this part. This information includes theaccessibility of a Web Service, like URLs, method names, the location of WSDL filesetc.

21A WSDL port must not be confused with a TCP socket type port.22The UDDI community contains over 220 companies. Therefore its support of the industry and its accep-

tance is guaranteed.

21


UDDI Business

Registry

White

Pages

Yellow

Pages

Green

Pages

Publish Inquire

SOAP Messages

Figure 14: The UDDI Business Registry

UDDI Business Registry is stored on so-called operator sites. To improve reliability, eachoperator site replicates their data to the other operator sites.

Access to the UDDI Business Registry is separated in two basic query types:

1. Inquiry: These functions can be used for searching or browsing the registry after specificdata like businesses or Web Services.

2. Publish: These functions allow administrators to create, delete or change registry entries.

UDDI also defines error handling, which is done by SOAP Fault messages.More information about UDDI can be found in [WAL02].

22

3 Existing Solutions for SOAP Based Fieldbus Access

The market today offers many fieldbus gateways that are capable of providing SOAP WebServices. As stated above, SOAP Web Services are based on open standards and thereforeimprove the overall compatibility between computing nodes. However, it has to be con-sidered that SOAP is a framework which may be used for an open protocol but does notguarantee openness and compatibility by itself. As the industry concentrates on vertical in-tegration, which forces high compatibility between devices, open standards describing SOAPWeb Services for fieldbus/Internet gateways have emerged which are meant to be a solutionto compatibility problems.

These standards concentrate on abstracting and representing underlying technologies andprovide the following two key elements:

1. Abstraction of fieldbus specific data: Plant floor devices, such as sensors, servos orswitches provide some kind of data. This data can be abstracted into a compound ofvariables which can be read or written. Variables representing values of fieldbus devicescan then be aggregated23 and can be presented to the Internet by a Web Service whichis deployed on a fieldbus/Internet gateway. Figure 15 depicts an aggregation of valuesfrom two fieldbus nodes into one variable.

Sensor 1 Sensor 2

Internet

Fieldbus

Client

Gateway

Value Value

Value 1

Value 2

Variable

Figure 15: Aggregation of sensor data in a variable on an Internet/fieldbus gateway

2. Managing communication: Plant floor devices can have multiple communication ca-pabilities24 which have to be represented in some way. This means that standards haveto provide message objects that can be used as a proper representation of such commu-nications. Figure 16 shows a client which sends a standardized polling message to thegateway which fetches the requested values from the proper fieldbus node.

3.1 OPC - Object Linking and Embedding for Process Control

The OPC Foundation 25 concentrates on delivering standards for greater interoperability be-tween automation/control applications, field system/devices, and business/office applications

23In fieldbus environments multiple nodes are often needed to fulfill certain tasks. In such cases it makessense to present these nodes in groups where aggregated fieldbus nodes perform specific functions.

24Values from fieldbus nodes most often can be polled, which basically means that one device requests valuesof another device. Another way of transmitting data are notifications where certain events trigger devices tosend data to one or more other devices.

25OPC stands for “OLE for Process Control” where OLE is an abbreviation of “Object Linking and Embed-ding”, a standard created by Microsoft which enables simple data transfer between OLE aware applications.OLE is the predecessor of COM/DCOM.

23

3 EXISTING SOLUTIONS FOR SOAP BASED FIELDBUS ACCESS

Sensor 1 Sensor 2

Fieldbus

Client

Gateway

Value Value

Polling of Sensor 1Translation of

polling message

Figure 16: Polling of data from a Sensor with a standardized polling message

in the process control industry.

Specifications from OPC do not cover implementation issues by intention. This gives ven-dors the important option to implement OPC standards by using their specific key technology.On the other hand OPC standards guarantee interoperability between OPC compliant devicesby providing standardized interfaces and communication methods.

OPC standards cover many common data exchange situations observed in industrial au-tomation environments. Instead of providing one huge standard, OPC designs specificationsfor particular communication situations. Historically, OPC concentrated on vertical dataexchange and introduced a client/server architecture where enterprise level clients could ac-cess data from plant floor devices through so-called “OPC Data Access” (OPC DA) servers.These servers aggregate data from fieldbus nodes and present them to the client in an ab-stract manner. A newer standard also addresses the communication between OPC servers,called “OPC Data Exchange” (OPC DX). figure 17 depicts the client/server server/servercommunication abilities of OPC compliant devices.

OPC DA Server OPC DX Server OPC DX Server

OPC DA/DX ClientEnterprise Level

Plant Floor Level

Devices

Figure 17: Data flow between OPC servers

Historically, OPC used COM/DCOM as key technology, which forced users of these stan-dards to use Microsoft Windows-based environments26. OPC now concentrates on SOAPWeb Services technology and has released two related standards.

OPC defines so-called interfaces which describe accessing data by different protocols orprogramming languages as depicted in figure 18:

Custom Interface: This is the basic interface which is directly based on COM/DCOM andis programmed with Microsoft Visual C++. The OPC Custom Interface describes baseconcepts and capabilities and provides a base for all other interfaces.

26There are products available that provide DCOM also on non-Microsoft platforms. One example wouldbe EntireX DCOM by Software AG that brings the DCOM programming model to UNIX. However, thesealternatives often have limitations and are not very widespread.

24


Automation Interface: This interface enables accessing data with Microsoft Visual Basic5.0. As Visual Basic can be embedded in various Microsoft applications, such as Excelor Access, this is an easy way to read and write data from OPC servers and embeddata into office applications.

SOAP Interface: This is the next step taken by OPC to improve interoperability by pro-viding an interface based on open standards like XML, SOAP and WSDL. Moreover,Microsoft’s .NET framework relies on the SOAP Web Services technology and promotesit as the successor of COM/DCOM.

OPC Server

C++ Application

Custom Interface

Automation Interface

SOAP Interface

SOAP Capable Application

Visual Basic Application

Figure 18: Available interfaces to OPC servers

OPC introduces three objects which establish hierarchical data access (see also figure 19).

1. OPC Items: These Components can be seen as data sources and provide the actualplant floor data in an abstracted way. Every Item consists of the following data:

Value: This object contains the actual data of a plant floor device. It can be providedin various data formats, like strings, integers or more complex formats like enu-merations or arrays. All available data formats and necessary conversion rules arespecified by the OPC standards.

Quality: This data is modeled as a bit mask with predefined options27 that are usedto express common states of the value from plant floor devices.

Timestamp: Data transferred from fieldbus devices to an OPC Client over a gatewayOPC Server takes an unspecified amount of time. Therefore a timestamp field istransported together with the actual data to inform the client when the data wasvalid.

Associated to each item are so-called “Item Properties” that provide various informationand configuration options about the item, such as its data type, the data range or itsprecision. The OPC standards provide several common properties and further allowvendors to add their own custom Item Properties.

2. OPC Groups: OPC Groups aggregate OPC Items and provide clients a way to organizedata.28

27Examples of common quality bits would be “good”, “bad”, “badDeviceFailure” or “uncertain”.28The COM/DCOM-based standards of OPC enable read/write operations to OPC Items only through

OPC Groups. This is different with XML-based standards of OPC, which enable direct read/write operationsto OPC Items. OPC Groups do not play an important role in these standards.

25


3. OPC Servers: This component is the top level object and contains one or multiple OPCGroups. OPC Servers maintain information about themselves, like status informationand provide configuration functions to OPC Clients. One Internet/fieldbus gatewaymay run multiple OPC Servers. The definition and configuration of the server addressspace29 is not specified and is left open. The address space might be fixed, or dynami-cally assigned; it could be configured outside of the OPC environment or configured atstartup of the server.

OPC Server

GroupItem

Item

Item

GroupItem

Item

Item

OPC Server

GroupItem

Item

Item

GroupItem

Item

Item

OPC compliant Internet/fieldbus Gateway

Figure 19: Available interfaces to OPC servers

OPC provides specifications for various common tasks in the industrial automation. Thefollowing list gives an overview of significant OPC standards:

OPC Data Access Custom Interface Specification: This is a basic standard that de-scribes data access (DA) provided by OPC servers via COM/DCOM. The current re-lease of the standard is version 3.0 and provides only limited compatibility to previousreleases, such as version 1.0 or 2.05a. OPC DA is the base for many other standardsthat are designed as companion standards to this specification. Further references canbe found in [OPCDA].

OPC Data Access Automation Interface Specification: This standard is a comple-ment to the OPC DA custom interface and provides data access with Visual Basic5.0 applications.

OPC XML Data Access (XML-DA) Specification: XML-DA is also a companion tothe OPC DA custom interface and enables data access by means of the SOAP WebService technology. In depth specifications can be found in [OPCXMLDA].

OPC Complex Data Specification: The OPC DA standard specifies the data transfer ofsimple data types, like integers, strings or arrays. The OPC Complex Data Specificationdescribes accessing and representing complex data and is meant as a complement to theOPC DA standard. The standard utilizes XML and XML-Schema for defining complexdata types.

OPC Data Exchange (DX) Specification: The OPC DA standards are designed andlimited to vertical data exchange. As also communication between OPC servers isrequired, OPC created the OPC DX standard that describes horizontal data exchangebetween OPC servers. OPC DX servers incorporate an OPC DA server and rely onXML/SOAP technology.

29Address space in this context refers to which OPC Groups and OPC Items are available on the server andhow they are addressed.

26


OPC Alarms and Events Custom Interface: This standard specifies interfaces to alarmand event systems that are often needed in industrial automation environments.

OPC Historical Data Access Specification: This standard is only loosely coupled withother standards and is designed for retrieving historical data from dedicated servers bymeans of COM/DCOM technology.

OPC XML Data Access (OPC XML-DA)

As denoted above, this standard describes accessing plant floor data through an OPC Serverutilizing Soap Web Services technology and is therefore of a special interest for this thesis.OPC XML-DA compliant servers may be bundled with an OPC DA 3.00 server and act as afront end but may be also stand alone.

The specification is accompanied by a WSDL document that must be used when buildingweb applications complying to this standard. The specification on the one hand consistsof WSDL fragments that basically are XML Schema definitions which specify various SOAPmessages. One the other hand it includes specific architecture definitions that describe specialissues like subscription, buffering and error handling:

Supported data types: The OPC XML-DA specification is based on the OPC DA Serverwhich relies on COM/DCOM technology. For compatibility reasons, OPC XML-DAinherits the data types from the COM/DCOM environment.30 These are representedby SOAP/XML Schema data types and cover simple types like strings, integers anddate/time types and also enumerations and arrays.

Available services: The following services are supported and their structure, parametersand behavior are precisely defined in the standard:

Status: Provide status information about the server.

Read/Write: Synchronously read and write data from and to OPC Items. Thesebasic operations are illustrated in listing 9 and 10 as given in [OPCXMLDA].

Subscription: OPC Clients can subscribe to specific items and will be notified when-ever values change.

Browse: Used for searching and listing available OPC Items on a specific OPC Server.

Properties: Get OPC Item properties.

1 <soap:Body><Read xmlns=” h t tp : // opc foundat ion . org / webse rv i c e s/XMLDA/1 .0/ ”>

3 <OptionsReturnErrorText=” f a l s e ”

5 ReturnItemTime=” true ”ReturnItemName=” true ”

7 LocaleID=”en” />

9 <Items ItemName=”Simple Types/UInt” /><Items ItemName=”Simple Types/ Int ” />

11 <Items ItemName=”Simple Types/Float ” />

30COM/DCOM incorporates a special data type called “VARIANT”, which is used to represent severalcommon data types like integers, strings and date/time types.

27


</ ItemLis t>13 </Read>

</ soap:Body>

Listing 9: Example of an OPC XML-DA Read Request

<soap:Body>2 <ReadResponse xmlns=” h t tp : // opc foundat ion . org / webse rv i c e s/XMLDA

/1 .0/ ”><ReadResult

4 RcvTime=”2003−05−27T00:15 :36 .6400000−07 :00 ”ReplyTime=”2003−05−27T00:15 :36 .7500000−07 :00 ”

6 Serve rSta te=” running ” /><RItemList>

8 <ItemsItemName=”Simple Types/UInt”

10 Timestamp=”2003−05−27T00:15 :36 .7343750−07 :00 ”><Value x s i : t y p e=” xsd :uns i gnedInt ”>4294967295</Value>

12 </ Items><Items

14 ItemName=”Simple Types/ Int ”Timestamp=”2003−05−27T00:15 :36 .7343750−07 :00 ”>

16 <Value x s i : t y p e=” x s d : i n t ”>2147483647</Value></ Items>

18 <ItemsItemName=”Simple Types/Float ”

20 Timestamp=”2003−05−27T00:15 :36 .7343750−07 :00 ”><Value x s i : t y p e=” x s d : f l o a t ”>3.402823E+38</Value>

22 </ Items></RItemList>

24 </ReadResponse></ soap:Body>

Listing 10: Example of an OPC XML-DA Read Response

Subscription architecture : Basically there are two ways of obtaining data from OPCServers: Polling and Subscribing. Polling means checking for new data with simpleread operations, which is perfect for acquiring data once in a while. In automationsystems it is often necessary to handle events. Such events are often simply valuechanges of plant floor devices, such as sensors or switches. Although polling of thesedevices is a viable solution, there are many disadvantages of this technique such ashigh server load, high communication overhead and possible outdated values. A betterapproach in such situations are notifications, where devices send messages to the clientwhich indicate that data has changed. This solution requires that clients inform theserver that they want to be notified if values change. This is called subscription.

Subscription naturally raises problems with SOAP Web Services as SOAP messagesutilize the HTTP protocol for data transport. HTTP is a stateless request/responseprotocol and is designed for communication situations where a client fetches data froma server.31 Asynchronous data transfer with HTTP is therefore impossible by design.32

31Polling is perfectly supported by the HTTP protocol as it follows its simple request/response method.32COM/DCOM has different connection and communication abilities that enable asynchronous data trans-

fers.

28


OPC XML-DA suggests a workaround to the limitations of HTTP by introducing atechnique called “polled subscription”. This way the client initiates the subscriptionand issues periodic refresh requests. The associated response messages will then con-tain all data that was updated since the last poll. As subscripted polling poses thesame problems as generic polling, such as high server load and outdated values, OPCintroduces a more sophisticated approach by delaying the server replies of refresh re-quests. This technique is described in figure 20. The left diagram depicts the simplecase where the server does not delay replies. The middle and right diagram intro-duce server delay times.33 During the “wait time” the server waits for occurring datachanges. If data changes occur, the server immediately sends a reply message with theupdated data. This technique provides huge advantages concerning communication la-tency and network traffic. Further information about polled subscription can be foundin [OPCXMLDA].

Client ServerResfresh request

Client ServerServer Response



Hold

Tim

eW

ait T

ime



Hold

Tim

eW

ait T

ime

Simple Refresh Polling Advanced Refresh Polling:

No Data Change

Advanced Refresh Polling:

Changed Data Available

Figure 20: Simple and Advanced Refreshed Polling

Buffering: In case of subscriptions, there can be situations where more than one data changeoccurs within one polled refresh cycle. In order to prevent data loss, OPC Serversprovide buffering, which means that a certain amount of data changes can be stored ina buffer. At a polled refresh, the server sends a reply message with all changed valuesstored in the server’s buffer.

3.2 oBIX - Open Building Information Exchange

The “Organization for the Advancement of Structured Information Standards” (OASIS) isan international consortium that releases standards concerning Web Services. OASIS is thesuccessor of the SGML Open consortium, founded in 1993, which concentrated on developingguidelines for the interoperability of SGML-based applications. Today OASIS concentrates onXML and accompanying technologies such as SOAP, WSDL and UDDI and released severalstandards for Web Services.

The “open Building Information Exchange” (oBIX) is an OASIS initiative which definesXML and Web Services-based mechanisms for building control systems. The oBIX specifica-tion version 0.6 is a mature working draft and is expected to become a standard in the nearfuture. Further information about the oBIX working draft can be obtained in [OBIX].

33The hold time specifies a minimum delay which is based on the maximum update rate of the underlyingdevice. The setting of the wait time has to be balanced so that possible server errors are detected in a reasonabletime. Moreover, it is important keep in mind possible timeout values of underlying network protocols whichmust be greater than the sum of hold/wait time and the network latency.

29


oBIX represents data as objects in a hierarchical, tree-like structure as depicted in figure21. The top level object is called “root object” and is the parent of all other objects.34 Datacan be addressed in a hierarchical way, such as /Floor1/Room3/Lights. oBIX additionallyutilizes this object tree for data browsing by recursively returning subtrees of objects.

Root object

heating

Radiator 2Radiator 1

temperature

room2 room3room1

sensor1 sensor2 sensor3

Figure 21: oBIX Data Structure

The standard defines so-called “oBIX Services” which represent Web Services. Thesecontain one or more “oBIX Operations” which are methods that can be called by a client.Currently oBIX specifies only one service, namely the “SysService” which defines basic op-erations such as read/write. It is expected that oBIX will specify further services in futurereleases of the standard for tasks like retrieving historic data or handling alarms.

The oBIX Specification contains the following key elements:

Localization: Most oBIX operations support the “locale” element which handles languageand country specific issues. This way, data types like date and time can be formatted tospecific needs, in addition strings may be displayed in applications in the local language.

Data Types: For simplicity reasons, oBIX contains only the following simple data types:bool, int, real, string, enum, absTime and relTime. Data structures can be representedby utilizing the hierarchical data tree.

oBIX introduces so-called “facets” which enable defining meta-data to oBIX data types,such as possible minimum/maximum values, resolution and precision35.

Units: Handling different units is no easy task in distributed systems. oBIX chooses aninteresting approach to this problem by mathematically defining units with XML. Thestandard itself provides only basic SI units36. Moreover, oBIX utilizes a simple, linearequation which can be used to express most common units. Listing 11 shows an exampleof the definition of the unit “hour”37.

34This perfectly fits the XML data structure where elements can contain other elements and form aparent/children-like structure.

35Resolution describes the accuracy of a real value in comparison to precision, which defines the number ofdecimal places.

36The International System (SI) provides the seven basic units kilogram(kg), meter(m), second(sec),Kelvin(K), ampere (A), mole (Mol) and candela (cd). Any other unit can be represented by these basicunits.

37The conversion equation is defined as toNormal = scalar ∗ scale + offset where “scalar” are hours inthis example.

30


<unit>2 <id>hour</ id>

<d i s p l a y>Hour</ d i s p l a y>4 <symbol>h</symbol>

<dimension><s e c>1</ s e c></dimension>6 <s c a l e>3600</ s c a l e>

<o f f s e t>0</ o f f s e t>8 </ unit>

Listing 11: Definition of the unit “hour”

Status: Every object has a status element which is returned as a companion to values. Theelement contains important information about the object, such as the quality38 andactual time of the read data and an alarm element which may be utilized for providinga summary of alarm states.

SysService: The SysService defines all operations and forms the base of the oBIX specifi-cation. It contains the following items:

About: This operation is defined for retrieving status information about the oBIXserver and returns elements like server name, vendor, uptime and available locales.

Read/Write: These operations implement reading and writing of one or more dataobjects. The key elements of these operations are best described by a simpleexample, given in listing 12.

<readReq>2 <id> l i g h t S e n s o r s/room1/ senso r2</ id>

<readReq>4

<readRes>6 <ob je c t>

<id>tempSensors/room1/ senso r2</ id>8 <r e a l>21 .2</ r e a l>

<s t a tu s><qua l i t>ok</ qua l i ty </s t a tu s>10 <d i s p l a y>21 ,2 C</ d i s p l a y>

< f a c e t s>12 <min>0</min>

<max>50</max>14 1

<un i t s id=”/ un i t s / degrees−Ce l s i u s ” />16 </ f a c e t s>

</ ob je c t>18 </ readRes>

Listing 12: Simple oBIX read request and response

The read request contains the identification (id) of the object that should be read.The response contains the value, as seen in line 8, the status and the facets ofthe value. oBIX uses an interesting way to assign the data type to the value.Instead of using XML-Schema such as <value xsi:type=”xsd:double”>21.2</value>

oBIX defines tags that directly map to data types, such as <real> or <str>.

38The quality element describes the status of the value, such as “ok”, “disabled” or “fault”. An additionalelement “display” may be used to provide a detailed description for applications.

31


As denoted above, read requests can also be used for browsing, which is shown inListing 13.

<readReq>2 <id> l i g h t S e n s o r s</ id>

<depth>1</depth>4 

<va lue> f a l s e</ va lue>6 <s t a tu s> f a l s e</ s t a tu s>

<d i s p l a y> f a l s e</ d i s p l a y>8 < f a c e t s> f a l s e</ f a c e t s>

</ inc lude>10 <readReq>

12 <readRes><ob je c t>

14 <id>tempSensors</ id><ch i l d r en>

16 <ob je c t><id>tempSensors/room1</ id></ ob je c t><ob je c t><id>tempSensors/room2</ id></ ob je c t>

18 <ob je c t><id>tempSensors/room3</ id></ ob je c t></ ch i l d r en>

20 </ ob je c t></ readRes>

Listing 13: Browsing an oBIX object tree

To enable browsing, the read request contains the element “depth”, which spec-ifies how many hierarchies of the object tree the read operation should descend.Moreover, the request may contain the element “include”, which is used to specifywhat kind of data should be returned.

Write operations are very similar to read operations: a client issues a write requestand the server replies with a write response. Multiple data objects can be writtensimultaneously.

Subscription: As HTTP does not support notifications due to it statelessness, oBIXchooses a similar approach to OPC and implements “polled subscription” wherethe client periodically39 polls the server for changed data. oBIX does not specifyadvanced techniques like OPC for minimizing the delay between data updates40.

By the time of this writing, version 0.7 of the oBIX working draft emerged, which isvery different to the prior standard. The new draft is not SOAP Web Service-based, insteadit is based on the “Representational State Transfer” (REST) architecture41. The oBIX 0.7working draft contains the following key elements:

Addressing: oBIX 0.7 addresses objects with URIs, such as ”http://server1/room1/sensor1”.An URI identifies a unique oBIX object.

39oBIX defines a so-called “lease time” which must not be exceeded.40oBIX is currently a working draft, so future releases of oBIX could implement appropriate techniques.41REST is another approach to implement Web Services and differs by design much from SOAP Web

Services. REST is a very abstract definition. Instead of defining a standard, it is an architectural guideline.REST calls resources “nouns” and access functions “verbs”.The main idea is to provide resources, referencedby URIs and access/modify them by four basic HTTP functions GET, PUT, POST and DELETE. Theseresources are modeled by self-describing XML documents that may reference other resources. Serializationissues are not described by REST. More information can be found in [FIE00].

32


REST Verbs: oBIX objects may be accessed by so-called “Verbs”, which consist of the fourfunctions Get, Put, Create and Delete and map directly to their HTTP counterparts.

Prototypes: The working draft specifies so-called “prototypes”, which are used to modelobjects. oBIX objects always inherit from prototypes and may define new elements oroverride elements of their parent.

Listing 14 depicts a simple “get” response:

<obj h r e f=” h t tp : //myhome/ l i g h t S e n s o r s/room1/ senso r2/”>2 <r e a l name=”temp” un i t s=” o b i x : u n i t s / c e l s i u s ” va l=”21 ,2 ” />

<bool name=” heater ” va l=”1” />4 </ obj>

Listing 14: oBIX working draft version 0.7 example

3.3 BACNet/WS - Web Services for Building Automation and ControlNetworks

In October 2004, the American Society of Heating, Refrigerating and Air Conditioning En-gineers, Inc. (ASHRAE) released an addendum to standard 130-2004, called BACNet/WS42

where “WS” stands for “Web Service”. More information about this standard can be foundin [BACNET/WS].

The BACNet/WS standard is designed to be a general Web Service-based communicationprotocol in the industrial and home automation which can be applied to any fieldbus system.BACNet/WS is currently a public review but is expected to become standardized in the nearfuture.

BACNet/WS does not define the SOAP message format and it does not provide WSDLcode or XML Schemas. Instead, it concentrates on defining an interface that can be used byhigher level programming languages, such as C++ or Visual Basic. This interface specificationcovers topics like data structure, data types or available Web Service methods. BACNet/WSwas designed with the idea that the custom interface is preliminary to the actual SOAP/XMLmessage specifications. However, it is expected that this or another standard will provideWSDL documents in the near future which can be used to access a BACNet/WS compliantserver.

BACNet/WS stores its data in so-called “nodes” which are organized in a hierarchicaltree structure, similar to oBIX. Nodes may have one or multiple children but always haveone parent. The topmost node is called “root node”. Nodes present their state with so-called“attributes”, such as its value or quality. Some attributes are mandatory for a node, othersare optional. One special attribute, the “Value”, is the holder of the actual value of the nodeand is the only attribute that may be written.

Nodes and its attributes are addressed with a “path” similar to a path in a URL, suchas /temperature/room2/sensor1 for a node address or /temperature/room2/sensor1:Value for anattribute of this node.

The BACNet/WS standard introduces so-called “Reference Nodes” which are pointers toreal nodes. Reference nodes can be handled equally to their referred counterparts and are

42BACNet stands for “Building Automation and Control Networks” and is an American national standard,a European pre-standard and an ISO global standard.

33


distinguished only by the special node attributes “Reference” and “Aliases”43. With the useof reference nodes, multiple logical trees can be built, as depicted in figure 22. The right treein the figure illustrates a logical/geographical data organization where reference nodes suchas “sensor1” are referring to nodes in the left tree.

Root node

heating

sensorsradiators

temperature

room2 room3room1

sensor1 sensor2 sensor3sensor1 sensor2 sensor3

Figure 22: Data Organization in BACNet

BACNet provides the following key elements:

Localization: BACNet/WS compliant servers may support multiple locales and returnstrings or specific data types in a localized format. In addition, BACNet servers haveto provide data in its “canonical” format, which is a locale-independent standardizedform44. The localized format is intended for presentation to humans while the canoni-calized format is meant for machine processing.

Data Types: The standard specifies the following data types for node attributes: None,

String, Real, Integer, Multistate, Boolean, Date, Time, DateTime, Duration. Moreover,BACNet/WS defines so-called “polymorphic” parameters, where a specific data typecannot be assigned45. Therefore these parameters are always of the type “string” andhave to be converted to an appropriate data type by the application.

Units: BACNet/WS defines a special node attribute which can optionally be used to definethe unit of the node value. The standard provides a huge list of units that may be used.The complete list can be found in [BACNET/WS].

Attributes: Every BACNet compliant node contains attributes which provide informationabout the node and its data. The most significant attribute is the “Value” whichcontains the actual node data. The value is accompanied by the attributes “ValueType”,“Units”, “Resolution” and “Minimum/Maximum” which provide information about thedata type and format of the value. Other interesting attributes are “ValueAge” forspecifying the actual time the value was valid, “HasHistory” for informing the clientthat the node provides historic data and “InAlarm” which can be used to inform clientsthat the node is in a special alarm state.

43The attribute “Aliases” contains all reference nodes while the attribute “Reference” contains the path tothe referred node

44The canonical data format applies to the encoding rules used in the XML Schema standard.45An example of a polymorphic parameter would be a function that returns values of multiple data types.

34


Services: The specification introduces so-called “Services” which represent methods for ac-cessing and manipulating data in the server. Figure 23 gives an overview about availableservices.

READ:

getValue

getValues

getArray

getArrayRange

getArraySize

WRITE:

setValue

setValues

HISTORY:

getHistoryPeriodic

OTHER:

getDefaultLocale

getSupportedLocales

BACNet Services

Figure 23: Available BACNet services

getValue: This service reads data from node attributes. The returned value is poly-morphically encoded and is therefore of the type “string”. In case of an error, theserver replies with an error message as defined in [BACNET/WS]. The getValueService can also be used to retrieve arrays, in which case the returned value con-tains a string, consisting of array elements delimited by semicolons. The service“getValues” provides retrieval of multiple attributes in one Web Service call.

getArray: The getArray service may be used to retrieve array attributes as an array ofstrings instead of a single string. This service is accompanied by the two services“getArrayRange”46 and “getArraySize”47 .

getHistoryPeriodic: [BACNET/WS] specifies historical data retrieval by the service“getHistoryPeriodic”. The service returns an array of strings, which may be lim-ited by the service parameters “start”, “count” and “interval”48.

setValue: This service writes data to node attributes, which is only allowed for theattribute “Value”. For verification purposes, the service implements a specialparameter “readback”, which – if specified – forces the server to read back thewritten data. In case of success, the service returns an empty string or the value,if the parameter “readback” is specified. The standard furthermore provides theservice “setValues” which can be utilized to write multiple attributes at once.

BACNet/WS does not provide methods for system notifications, such as subscription.Moreover, it does not specify how to obtain information about the BACNet Server. Methodsfor browsing are also not defined49. However, it is possible that these missing points will beaddressed in future releases of the standard.

46This service can be used to retrieve parts of arrays.47The getArraySize service returns the number of items in an array attribute.48This parameter specifies the time interval between values. If the requested interval is shorter than the

actual sample rate, the server returns interpolated values.49It has to be noted that every node contains the attribute “children”, which could be used for browsing

the data structure. However, this attribute is optional and it is not described in the standard how to utilizeit for browsing.

35


3.4 Echelon i.LON 100 SOAP/XML Interface

The Echelon i.LON 100 is a Internet gateway for the LON50 fieldbus and provides a SOAPWeb Service-based interface for data access and configuration. The SOAP protocol of thedevice is not based on any standards, it uses a proprietary protocol developed by Echelon.The i.LON 100 was one of the first fieldbus gateways that implemented a Web Service-basedinterface.

Echelon already provides various tools that can be used to configure and access the i.LON100, such as a configuration tool, distributed with the device or a LON specific tool called“LonMaker”. However, it is also possible to access the gateway with custom Web Service-based applications. Echelon provides WSDL files that can be used by developer tools andoffer a complete programming reference. Further information can be found in [ILON04].

The i.LON 100 provides access to fieldbus devices with so-called “data points”51 whichcontain the actual value and some data point specific properties, such as its data type andformat. Data points have names which follow a naming convention that is used throughoutvarious LON specific tools, such as LonMaker.

The gateway implements the following functions that can be used to directly access datapoints:

DataPointRead: This function implements reading the current value of a specific datapoint. Listing 15 depicts parts of an example request/response SOAP for querying thestatus of a light switch.

<UCPTpointName>NVL nvo03Switch</UCPTpointName>2 <UCPTfieldName>s t a t e</UCPTfieldName>

4 <Resul t><UCPTpointName>NVL nvo03Switch</UCPTpointName>

6 <UCPTfieldName>s t a t e</UCPTfieldName><UCPTlocation>MainBuilding\F i r s tF l o o r \Light</UCPTlocation>

8 <UCPTpointUpdateTime>2001−07−24T01:47 :22 .000</UCPTpointUpdateTime><UCPTvalue>1</UCPTvalue>

10 <UCPTvalueDef></UCPTvalueDef><UCPTunit></UCPTunit>

12 <UCPTpointStatus>AL NO CONDITION</UCPTpointStatus><UCPTpriority>250</UCPTpriority>

14 <UCPTformatDescription>SNVT switch</UCPTformatDescription><UCPTbaseType>BT STRUCT</UCPTbaseType>

16 </Resu l t>

Listing 15: Data point read request as shown in [ILON04]

Line 1,2 illustrate the request message, which consists of the name of the data pointand an optional field name in case the value is a data structure. The result messagecontains the value of the data point and its properties, such as the time when the valuewas read, the unit or the alarm status.

DataPointWrite: The write function enables writing the value of a data point. The SOAPrequest message has to contain the data point name and may contain the followingspecial parameters:

50The “Local Operating Network” (LON) was developed by the company Echelon around 1990 and is basedon a decentralized architecture, containing of multiple nodes that contain logic.

51In LON fieldbuses, data points basically map directly to network variables.

36


Priority: The i.LON 100 implements a simple priority system for writing values todatapoints by defining priority levels52 which are stored in a property of a datapoint. A write operation is only performed, if the priority is the same or higherthan the priority level stored in the data point. In case the priority level of the writeaccess is higher than the stored priority, the data point property is overwrittenwith the higher priority level. This way important or time critical write operationsmay gain precedence over others. The device also implements a special functionto reset the priority level of a data point to recover write access of functions withlower priority.

Propagate: In case of writing to structures, there may be situations where the struc-ture must not be successively written to the fieldbus node. Therefore a writeoperation may specify the parameter “Propagate” which inhibits a propagation ofthe written value to the fieldbus network. This way, the values of the structuremay be written one after another and may be propagated to the fieldbus node inan atomic operation.

Apart from these specific functions that can be used to directly access Data Points, thei.LON 100 implements so-called “applications” that provide a set of functions for specificpurposes. Figure 24 provides an overview.

DataServer:

List

Get

Set

Delete

Read

Write

ResetPriority

Datalogger:

List

Get

Set

Read

Clear

Delete

AlarmGenerator:

List

Get

Set

Delete

AlarmNotifier:

List

Get

Set

Delete

Read

Write

Clear

i.LON 100 Applications

AnalogFB:

List

Get

Set

Delete

EventScheduler:

List

Get

Set

Delete

EventCalendar:

List

Get

Set

Delete

TypeTranslator:

List

Get

Set

Delete

RuleList

RuleGet

RuleSet

RuleDelete

Figure 24: i.LON 100 applications and functions

These applications are configured with XML files that are uploaded to the gateway em-bedded in SOAP messages53. Applications consist of items, such as data points, events,alarms or data logs and can be referenced by a specific identification number, called “index”or by its unique name. Every application has the following four basic functions which reador modify the XML configuration files:

1. List: This function can be used for listing or browsing items, such as alarms, data pointsor events which are already defined in the i.LON 100 configuration files. The returned

52Priority level “0” is the highest priority while “255” is the lowest. The default priority, which is set duringthe boot process is “255”.

53Alternatively, the XML files can be modified by hand and uploaded to the gateway with the File TransferProtocol (FTP). This method has the huge drawback that the i.LON 100 has to be restarted, in order for theconfiguration changes to take effect.

37


SOAP message will contain item properties, such as the index number and name of theitem, its description or its last update time.

2. Get: The configuration of items may be retrieved with this function. The request messagehas to contain the index number or name of the item and may contain also referencesto multiple items.

3. Set: This is the counterpart of the “Get” function and manages writing of configurationdata. Multiple item configurations may be written at once. The “Set” function is usedto create new items and to overwrite the configuration of existing items.

4. Delete: This function deletes items, such as certain data logs, data points or alarms.

These functions differ from the above “DataPointRead/Write” functions as the SOAPmessage is only used for transporting XML code. The SOAP body of request messagesconsists of the special element <Data> which then contains an encoded XML54 file as shownin Listing 16.

<SOAP−ENV:Body>2 <echelon:FunctionName

xmlns :eche lon=” h t tp : / / . . . ”>4 <Data>

&l t ; iLONAppplication&gt ;6 &l t ; UCPTindexValue&gt ;3& l t ; / UCPTindexValue&gt ;

&l t ; UCPTpointName&gt ; NVL nvo03Switch&l t ; /UCPTpointName&gt ;8 &l t ; / iLONApplication&gt ;

</Data>10 </ echelon:FunctionName>

</SOAP−Env:Body>

Listing 16: Transporting XML data in a echelon compliant SOAP message.

The above functions are meant to be “symmetric”, which means that the output of onefunction may be used as an input to another. For example, a data point or alarm item maybe cloned by feeding the output of a “Get” request to a subsequent “Set” command.

As shown in Figure 24, the i.LON 100 implements various applications for the followingpurposes:

Data point management: The most important application of the i.LON 100 is the so-called “Data Server”. It can be used to create, manage, delete and access data points.Apart from the four basic functions, as shown above, the Data Server provides thefunctions “Read”, “Write” and “ResetPriority” that are very similar to the functions“DataPointRead/Write”. However, the Data Server functions provide more function-ality, such as reading and writing multiple data points at once, or reading values fromdata points that fulfill certain criteria.

Data logging: The i.LON 100 implements so-called “Data Loggers” that can be configuredto monitor and store changes of data point values. The data logs itself can be down-loaded with the “Read” function55 and can be erased with the function “Clear”. The

54Encoded XML files are created by escaping the characters “<”, “>” and “&”. Encoded XML is treatedlike a character string by XML parsers and is therefore not verified.

55Alternatively, the log files may be downloaded with FTP.

38


Data Logger enables storage and access of historical data but may also be configuredso that it stores values in a circular buffer, which means that the oldest values aresubsequently overwritten by newer ones.

Alarming: The gateway implements alarming by two applications: the “AlarmGenerator”that generates alarms such as when certain limits of data point values are exceededand the “AlarmNotifier” that logs alarm conditions, sends notifications via SMTP orupdates specific data points.

Event Scheduling: The i.LON 100 implements two applications, called “EventScheduler”and “EventCalendar” that can be used for periodic updates of data points. TheEventScheduler provides means for creating day-based schedules, such as switchingon a light every Monday at 8:00am. The EventCalendar may then be used to create ex-ceptions for these day-based schedules. This way even complex scheduling applicationsmay be implemented.

Type Translating: The Type Translator can be utilized to translate values of data pointswith a specific variable type into another type. This can be useful when comparingdata points of incompatible types. The i.LON 100 also enables the creation of customrule sets that can be stored and utilized by the Type Translator.

The i.LON 100 does not provide strong security measures. The device limits accessby implementing HTTP basic authentication and a common password protection when it isaccessed via FTP. Encryption techniques, such as SSL and authenticity checks like signaturesare not supported. This limits the field of application of the i.LON 100 to already securedintranets – a direct connectivity to the Internet would pose many security threats.

39

4 Representing Information in Different Fieldbus Systemswith SOAP

Vertical integration can only be established if information between different networks andsystems can be exchanged. Therefore when designing SOAP Web Services to access fieldbussystems, compatibility and interoperability between such services have to be kept in mind56.Basically, there are two ways to fulfill these requirements:

Generalized Fieldbus Interfaces

Generalized interfaces enable clients to retrieve fieldbus data from a service without in-depthknowledge of underlying fieldbus technologies. A SOAP Web Service on the Internet/fieldbusgateway provides data structures that represent data in fieldbus nodes. Read and writeoperations on these structures may then be used to access and modify fieldbus data.

Generalized fieldbus interfaces alone are not enough to guarantee interoperability. Thekey is a detailed specification of abstraction layers and broadly accepted standardization.This task is not easy to accomplish as there are many different fieldbus systems with varyingfunctionality and numerous vendors with different interests that have to agree on one interfacespecification.

Standards have to deal with the level of abstraction and the coverage of fieldbus spe-cific details. Figure 25 shows how three different fieldbus systems can be represented by ageneralized interface.

Figure 25: Influence of detail/generalization level on standards

It can be observed that certain features of the different fieldbus systems overlap, whileothers are fieldbus specific. For instance, all three technologies will have similar read/writeoperations, while asynchronous notifications are handled differently. There are two possibili-ties of implementing such a generalized interface:

Limited feature coverage: The right figure shows an interface that only covers overlap-ping functionality of different fieldbus technologies. The huge advantage of such astandard is simplicity: only simple functionality, such as read/write, browsing etc. willbe covered. Therefore such interfaces will be easy to implement and will lead to ahigh level of compatibility. The disadvantage of this concept is that advanced fieldbusspecific operations cannot be used.

56Clients located on upper enterprise levels will use these Web services to access the underlying fieldbus.Such Web services should be designed in a compatible style, so that one client can easily retrieve fieldbus datafrom different services.

40

4 REPRESENTING INFORMATION IN DIFFERENT FIELDBUS SYSTEMSWITH SOAP

Maximum feature coverage: The figure on the left shows an interface which covers func-tionality of all three fieldbus systems. Such an interface would cover overlapping featuresand furthermore specify fieldbus specific extensions to the standard, which deal withdifferent fieldbus specific aspects.

At first glance the ideal solution seems to be the second, covering numerous fieldbus spe-cific features while maintaining a high level of generalization. The problem is that the basicfunctionality has to be modeled in a way so that it can be extended to cover fieldbus specifics,which may lead to complicated specifications. Moreover, fieldbus specific extensions have tobe provided, which make the specification even longer and more complex. Standards that aredifficult to read and to understand often lead to misinterpretations and incompatible appli-cations. Moreover, the extensibility may lead to situations where fieldbus vendors implementfunctionality which is already covered in the standard in their own way, resulting in incompat-ible solutions57. Another issue is that the implementation of a complex standard is expensiveand time consuming and may therefore lead to incomplete or unstable implementations thatonce again raise interoperability problems.

Therefore working groups who design standards for Internet/fieldbus interfaces have tocarefully balance between simplicity and coverage of fieldbus specifics. Many of today’ssuccessful standards focus on a very limited set of fieldbus functionality, such as a limited setof data types and basic fieldbus operations like reading/writing and browsing.

Application-specific Interfaces

An alternative approach to generalized fieldbus interfaces would be to deploy certain field-bus applications on the Internet/fieldbus gateway which provide selected fieldbus data in adescriptive and easy to access way. For instance, there would be an application that can beused to switch on all lights in a building and another one to open a garage door. Such anapplication could provide an operation “switch lights” which can be called with one or moreparameters which specify the location of the lights that should be switched on. In case of ageneralized interface, such functionality would be implemented by utilizing a generic “write”operation to change certain fieldbus data points.

Application-specific interfaces may be seen as a top-down approach, where the client firstspecifies which information or functionality of the underlying fieldbus it is interested in. Theserequirements are then implemented by a number of applications on the Internet/fieldbus gate-way. Such gateway applications may range from simple wrappers, collecting and presentingfieldbus data in a certain way, to real applications, which combine fieldbus data and logic toimplement complex operations. On the other hand, generalized fieldbus interfaces resemble abottom-up approach, where an Internet/fieldbus gateway exposes all available fieldbus dataand lets the client decide which data it is interested in.

From the perspective of the client, application-specific interfaces have the following ad-vantages:

Applications representing functionality: There may be cases where the client needs spe-cific fieldbus functionality, for instance to check, whether all lights in a building are off.Fieldbus applications may therefore collect this data, apply some logic to it and present

57For instance, the standard will specify generic read/write operations which are available in all fieldbussystems. A vendor may now choose to implement his own enhanced read/write operation instead of using thegeneric one. This way, basic operations may become fieldbus specific.

41


it to clients, quite in contrast to generic fieldbus interfaces where clients only have accessto raw fieldbus data.

Meaningful and descriptive applications: Application-specific interfaces provide func-tionality which is tailored to the needs of clients. These applications will have mean-ingful names and will be descriptive, therefore they are easy to access. For instance,a weather station could implement an application called “GetTemperature”, which in-cludes a thorough description that explains how to utilize the application.

Developers who implement client applications will often lack fieldbus knowledge. Incase of application-specific interfaces, the underlying fieldbus technology may be totallyhidden, which allows easy retrieval of fieldbus data.

Access control: Application-specific interfaces can control access on a functional level asusers access the fieldbus through applications which offer certain functionality, quitein contrast to generic interfaces which are offering access to underlying data points.Limiting the accessibility of operations is easier to manage than restricting the accessof fieldbus data points.

Applied to the example above, limiting access to light switches in a building can beeasily done by allowing/denying access to a “switch light” operation.

SOAP Web Services seem to be an ideal approach for application-specific interfaces onInternet/fieldbus gateways, as they are descriptive, easy to access and standardized.

A huge drawback of gateway applications is that they have to be programmed, installedand maintained. Generalized interfaces simply provide access to the underlying fieldbus, andso changes in the underlying fieldbus are immediately reflected by the interface. Moreover,the installation procedure is easy and maintenance minimal. The client side of gatewayapplications also has to be developed, while generalized, standardized fieldbus interfaces maybe accessed by any client that complies to this standard.

Deciding between generalized and application-specific interfaces will most often dependon the information the client has to retrieve from the underlying fieldbus system. If the clientneeds in-depth fieldbus data and access rights are no issue, generalized interfaces will be thebest choice. If the client has to gather statistical information, has to control certain aspectsof the fieldbus, or the access to the fieldbus has to be strictly limited, gateway applicationsmay prove the better solution.

However, a gateway will most often not be limited to one interface, hence it would also bepossible to both provide one or more generalized interfaces and several gateway applicationson the same gateway device.

4.1 Generalized Fieldbus Interfaces

As stated above, generalized interfaces may be used to access fieldbus data without deepknowledge of the underlying system while maintaining a high level of compatibility.

Specifications of such interfaces have to deal with issues such as defining operations thatmay be used to access the fieldbus, the underlying data structure and its addressing scheme.

4.1.1 Operations for Fieldbus Access

An Internet/Fieldbus gateway has to implement certain operations for clients accessing thefieldbus. The fieldbus itself provides various services that may vary from one fieldbus sys-

42


tem to another. These services have to be abstracted by the gateway and aggregated intooperations that are presented to the client.

Basically there are two perspectives from which operations may be defined:

1. Fieldbus-centric: Fieldbus systems define various operations that may be used to accessand control fieldbus devices. An Internet/fieldbus gateway may try to map these oper-ations to SOAP Web Services and map them to the Internet as depicted in figure 26.This way, several specific fieldbus functions, like data retrieval and updates, historicdata retrieval and network configuration could be represented by the gateway quiteeasily. Mapping internal fieldbus operations to Web Services has the huge advantagethat the fieldbus may be accessed in detail – all features of the fieldbus may be utilized.

Data access operations

Alarm operations

System notifications

Historic data retrieval

...


Alarm operations



...

Fieldbus Operations Web Services on the Gateway

Client

Client

Client

Figure 26: Mapping fieldbus specific operations to Web Services

The huge disadvantage of this approach is that the underlying protocols of Web Servicesmay not be appropriate for certain fieldbus operations58. Workarounds and program-ming tricks that partially solve protocol limitations are often used to circumvent theseshortcomings but make the implementation complex59 and difficult to understand.

2. Internet protocol-centric : Web Service protocols such as SOAP or underlying proto-cols like HTTP or TCP/IP were designed with specific applications in mind. SOAP’sbasic goal is to implement remote procedure calls while HTTP was designed to transmithypertext documents. Most fieldbus operations can be abstracted and aggregated intoa handful of very basic Web Services that provide access to the fieldbus and also suitthe underlying Web Service technologies as shown in figure 27.


Alarm operations



...

GET

POST

PUT

DELETE

Fieldbus Operations Web Services on the Gateway

Client

Client

Client

Figure 27: Aggregating fieldbus specific operations to specific Web Services

58An example would be HTTP, which is only a request/response protocol and is therefore unsuitable forasynchronous services such as alarming notifications.

59Moreover, some of these tricks may not work in certain environments or may lead to undetermined states.An example would be the “Advanced Subscription” as described in [OPCXMLDA] where custom TCP/IPtimeouts could possibly lead to unpredictable errors or problems.

43


An interesting approach is the “Representational State Transfer” (REST) Web Servicearchitecture which is introduced in depth by [FIE00]. REST is different from SOAPand is – instead of focusing on RPC – a resource-centric60 approach and defines thefollowing four so-called “Verbs” that modify resources and directly map to the HTTPprotocol:

1. GET: This function requests data from a resource. Requests do not alter any dataand are free from side effects.

2. POST: The POST function adds something to a resource, such as pieces of infor-mation.

3. PUT: PUT creates or overwrites resources.

4. DELETE: Resources may be deleted with this function.

Although REST is a different technology from SOAP Web services, it clearly showsthat numerous Internet operations may be reduced to a handful of very basic ones.Applied to fieldbus systems, this means that various specific fieldbus operations may beaggregated into some elementary functions, which can be easily represented by Internettechnologies, such as:

Read: Read data or properties from fieldbus nodes.

Write: Write values to fieldbus nodes.

Browse: List available fieldbus nodes.

Status: Retrieve status information about the server or the fieldbus nodes.

The amount and the functionality of these basic functions depend very much on theunderlying data structure61. Therefore the aggregation of fieldbus specific functionshas to be accompanied by the modeling of the data structure.

An important aspect of this approach is that certain fieldbus specific functions cannot beabstracted and aggregated to such basic functions due to limitations in the Web Servicearchitecture and their underlying protocols. Time critical operations in particular willbe difficult, if not impossible to map to such basic SOAP Web Services. However,most vertical integration applications can be implemented by means of elementaryfieldbus operations as they are most often not time critical and focus on monitoringand controlling processes on a high level.

4.1.2 Fieldbus Data and Addressing Scheme

Fieldbus data resides on fieldbus nodes which provide one or multiple values and propertiesthat may be read and/or written. This data has to be aggregated and abstracted in some way,so that it can be provided as a consistent data structure on the Internet/fieldbus gateway.

The easiest way would be to create a physical representation of the fieldbus nodes andto provide this structure on the gateway. This approach is impressively simple and easy toimplement but has the following shortcomings:

60Resources are represented by documents, which are commonly written in HTML or XML.61If for example single elements of the underlying data structure are linked together, operations for browsing

may become unnecessary.

44


Fieldbus-specific: Different fieldbus systems implement different data structures62. There-fore data aggregation based on physical structures may not be consistent over differentfieldbus systems which makes data abstraction fieldbus-specific and hence limits inter-operability between systems.

Physical/Logical considerations: In many cases, the physical structure does not complywith the logical structure. For example, a single fieldbus node may implement lightingand heating controls which have no logical connection. Data structures based on thephysical implementation will therefore lead to confusing addressing schemes.

A common fieldbus abstraction is built around the value, which is the very basic elementof fieldbus nodes. Echelon for example introduces a concept of so-called “data points” thatbasically represent pieces of information. These data points reside in a fieldbus node andcontain the value that can be read and written with some accompanying properties, such asa timestamp, the data type or the status of the value as depicted in figure 28.

Fieldbus Node

Data Point

Value

Timestamp

Data Type

Status

...

Data Point

Value

Timestamp

Data Type

Status

...

Fieldbus Node

Data Point

Value

Timestamp

Data Type

Status

...

Fieldbus Node

Data Point

Value

Timestamp

Data Type

Status

...

Data Point

Value

Timestamp

Data Type

Status

...

Fieldbus

Figure 28: Data Points

Common interface specifications for Internet/fieldbus gateways, as described in chapter3, use very similar abstraction techniques.

Internet/fieldbus gateways may also aggregate data points to a structure that is presentedto client applications. This way, data point elements in the gateway, such as the value, areonly place holders63, for their counterparts in the fieldbus node. Such a data structure in anInternet/fieldbus gateway has to be configured, which means that fieldbus data is assigned tocertain data points that are aggregated to some data structure in the gateway. The followingbasic data structures may be used:

Flat: This data structure is depicted on the left in figure 29. The advantage of this arrange-ment of data points is its simplicity – it is easy to set up and to maintain. The drawbackis that the structure gets very complex when the gateway contains a high number ofdata points. Browsing the structure may become very inefficient or complicated64.

The addressing scheme of data points in this structure is simple. However, every datapoint must have a unique address, which demands an address space that is big enoughwhen high numbers of data points are assigned to an Internet/fieldbus gateway.

62For example, Profibus has a very different underlying concept compared to LON which results in differentdata structures.

63This addressing scheme conforms to “pointers” in common programming languages64In case of a high number of data points, an operation which lists available data points will return a huge

data set. To circumvent this problem, browse results may be limited by filtering rules. Data points that donot match certain criteria will not be returned.

45


Hierarchical: Hierarchical data structures, as shown on the right in figure 29, are used toarrange data in a tree-like structure with parent elements that contain zero or multiplechild elements. The top level data point is called “root data point”. Every child mayhave only one parent.

Hierarchical trees may be used to represent physical, geographical or logical structures.The addressing scheme itself describes the location of a data point in the hierarchicalstructure. The address itself consists of the child’s address and all parent addresses,which are separated by delimiters65.

Data Point

Data Point

Data PointData PointData Point

Data PointData PointData Point

Data Point Data Point Data Point Data Point

Figure 29: Flat and Hierarchical Data Structures

Fieldbus systems may have multiple viewpoints66, therefore Internet/fieldbus gatewaysmay assign one data point to multiple data structures. This way, multiple data point treesmay coexist in one gateway and offer clients different perspectives of fieldbus systems.

4.1.3 Localization and Units

Fieldbus data may be used by a variety of applications in different environments and plat-forms, therefore one important goal in an Internet/fieldbus design is interoperability. Twoimportant aspects are localization and units which accompany fieldbus data.

Localization primarily deals with translation into other languages67. For instance, itmay be appropriate to provide textual information which accompanies certain fieldbus data,such as “Air Condition Status”. This textual information may be then be offered in variouslanguages, such as “Status der Klimaanlage” in German. Clients which request fieldbus datafrom Internet/fieldbus gateways with localization support may then specify their “Locale”and retrieve localized fieldbus data this way68.

Fieldbus data may also be provided in different units, such as a mass that may be inkilograms (kg) or in pounds (lb). Client applications have to be informed about units inwhich data is provided, so that the data can be processed correctly. Client applications mayhowever depend on other units than the fieldbus itself offers. Therefore it may be appropriateto offer data in other units than in its defaults, which may be done as follows:

65This addressing scheme is similar to URLs and could look like /item1/item2/item3.66There may be a technical perspective of a system and also a logical or a geographical viewpoint, such as

aggregating similar technical devices compared to arranging data after geographic locations.67Localization not only deals with translating text. Other localization issues are country-specific date/time

formats, currency and others.68If no Locale is specified or no appropriate localized fieldbus data is available, the default locale will be

returned.

46


SI Units: One common way is to only provide and accept fieldbus data with a combinationof the seven SI units. This strict approach is quite simple to implement69 but may beinappropriate for certain clients that do not implement the SI system.

Implement a set of unit conversions: This approach implements a variety of units to-gether with conversion functions in the gateway. Clients may then retrieve fieldbusdata in one of these units.

Conversion functions: Another way would be to implement SI units and accept conversionfunctions in fieldbus requests which can then be used to convert fieldbus data from SIunits to the the specified unit. This conversion function is commonly described as alinear equation, such as unit = (A + Bx)/C + Dx), where A,B,C,D are arbitraryconstants. Although most common units can be expressed this way, units with non-linear conversion functions don’t fit into this model. The approach is further describedby [OBIX] and [BART04].

4.2 Application Specific Interfaces

Fieldbus applications typically reside in the fieldbus itself. For instance, the LON technologyenables programmers to put logic into one or more fieldbus nodes which may together formone application. An example would be an electrical garage door that is controlled by severalfieldbus nodes connected to switches, motor control and sensors. Every node implements acertain part of the application; the node connected to the switch, for instance, starts andstops the motor. This common approach, as depicted in figure 30, has many strengths, suchas that the fieldbus operates autonomously and applications may therefore still work evenwhen nodes are disconnected. Moreover, there exist a number of well-tested tools for creatingsuch fieldbus applications.

Fieldbus

Motor

Switch Sensor 1 Sensor 2

Fieldbus Node

Application

„Garage Door“

Application

„XYZ“

Fieldbus Node

Application

„Garage Door“

Application

„UVW“

Fieldbus Node

Application

„Garage Door“

Figure 30: Application in a LON fieldbus

Nevertheless, there may be situations, where it is more appropriate to install a certainapplication in a “special” fieldbus node which offers capabilities that a normal fieldbus nodecannot provide, such as improved computing power, increased storage, certain technologiesor improved connectivity. An Internet/Fieldbus gateway will often provide this extendedfunctionality and may therefore be appropriate for certain fieldbus applications. Figure 31depicts a scenario where an application resides in the fieldbus gateway.

Such “gateway applications” may range from simple views of fieldbus data to complexapplications. Such views may be accompanied by detailed information about this fieldbus

69Nevertheless certain conversion functions may have to be implemented by the gateway as the fieldbusitself may provide fieldbus data in units other than the SI system defines.

47


Node

Fieldbus

Motor

Switch

Node Node

Sensor 1 Sensor 2

Internet/Fieldbus Gateway

Application

„Garage Door“

Application

„XYZ“

Figure 31: Application on an Internet/Fieldbus Gateway

data and may ease the access of certain information for clients. For instance, retrieving theaverage temperature in a building or the number of active lights may be done with suchviews, which are nothing more than very simple gateway applications. As denoted above,abstract fieldbus interfaces often lack information about fieldbus data. Gateway applicationscould wrap certain fieldbus data into views and provide accompanied information about thisdata.

Applications on an Internet/Fieldbus gateway may also provide an interface to the In-ternet which may be implemented in various common protocols, such as HTTP, SMTP orSNMP. Another approach would be SOAP Web Services, which seem to fit perfectly as theyprovide the following key advantages:

Improved accessibility: Accessing SOAP Web Services is an easy task and is supportedby various frameworks which exist for many platforms. As denoted in chapter 2.4,programmers may easily access Web Services by using the WSDL document of a WebService. WSDL not only eases the access, it also provides a technical documentation ofthe Web Service. Listing 17 shows the client code in the Python programming languagefor accessing a simple Web Service that returns the temperature from a fieldbus sensor70.The example depicts that it takes only some simple code lines for accessing the service,which makes it very easy to integrate fieldbus applications in existing applications.

from SOAPpy import WSDL2 s e r v e r = WSDL. Proxy ( ’ http ://www. qwer . tk / tempserv ice . wsdl ’ )

print s e r v e r . GetTemp( ’ Sensor123 ’ )

Listing 17: Python Client Code for Accessing a Web Service

Self-documentation: By providing WSDL documents together with a Web Service, it ispossible to document not only the technical details of the service but also to outlinewhat exactly the service does. In case of public gateway applications, UDDI may beused to offer the service on the Internet.

Easy deployment: An Internet/fieldbus gateway may provide a special interface that allowsprogrammers to easily deploy applications on the gateway. [ENG02] describes somecommon deployment techniques that may also be implemented on an Internet/fieldbusgateway.

Fine grained access rights: [VEN05] states that “Application-specific interfaces allow amore flexible authorization scheme.” Gateway applications expose only specific fieldbus

70A short introduction to accessing Web Services through WSDL with python can be found in [PIL05].

48


data needed by the client. Other – maybe critical – data is not made accessible. More-over, it is possible to implement advanced access rights, such as client authorization, orlimiting access for specific networks. This way, there may be specific access limitationsfor certain gateway applications, while others could be publicly accessible.

Better error handling: When an error in the fieldbus occurs, such as a defective sensor,an error message has to be returned by the Internet/fieldbus gateway. Gateway appli-cations may map this general sensor error to an application-specific error, which maybe more descriptive and understandable than the native fieldbus error. Moreover, thegateway application may react to certain errors in specific ways, such as by disablingparts of the application or by replacing missing functionality by other means71.

Despite various advantages, gateway applications have certain weaknesses, such as thefollowing:

Configuration: Gateway applications have to be adapted to the underlying fieldbus. Forinstance, a gateway application that calculates the average temperature in a buildingneeds a list of all temperature sensors. Therefore this application has to be configuredaccording to the underlying fieldbus. Moreover, if temperature sensors are added orremoved from the fieldbus, the application has to be reconfigured.

Fieldbus dependent: A gateway application is developed for a specific fieldbus only. If theunderlying fieldbus technology of an Internet/fieldbus gateway is different, the applica-tion has to be adapted as the fieldbus interface may differ.

This problem may be solved by introducing an additional abstraction layer in the field-bus that unifies fieldbus access for gateway applications72.

Hardware dependent: Gateway applications, which are developed in common program-ming languages, such as C, will be in a binary and hardware dependent format. There-fore such gateway applications cannot be installed on gateways with different underlyinghardware.

This problem can be overcome by using programming languages, such as Java orPython, which generate hardware independent byte-code. However, byte code will beinterpreted by a virtual machine, requiring extra processing power and memory whichmay not be available on simple Internet/fieldbus gateways.

4.3 Representing Fieldbus Data and Services with SOAP

SOAP Web Services installed on Internet/fieldbus gateways have to represent fieldbus oper-ations and transport fieldbus data. Therefore fieldbus data has to be encapsulated in SOAPmessages in some way.

A SOAP message consists of the SOAP envelope that contains the SOAP header andthe SOAP body, as depicted in figure 11. The SOAP body, where the fieldbus data willbe placed, contains XML code which has to comply to the SOAP specification. The SOAPstandard constrains this XML code in many ways but leaves the developer many options in

71For instance, if an application returns the average temperature of a building and one temperature sensorfails, the missing temperature may be approximated by the application.

72An example for such a design would be the IGUANA gateway, which is described in detail in chapter 5.1.

49


choosing suitable XML code for his data. Therefore Fieldbus data may be represented bySOAP messages in various ways.

The format of the SOAP message is specified by a WSDL document, which contains XMLSchema code that specifies the format of the SOAP body. In many cases WSDL documentsand therefore the whole structure of SOAP messages can be automatically generated bydeveloper frameworks. However, the format of the SOAP message has to be specified in caseof standardizing SOAP Web Services, moreover, the format has an impact on the followingissues:

Readability: SOAP messages will normally be parsed and processed by machines. However,human legibility of these messages is a huge advantage for debugging or testing purposes.

Listing 18 shows two SOAP bodies which provide the same functionality. It is obviousthat the first body is far less readable than the second.

1 <s:Body><item p0=”Sensor1” p1=” 12 .2 ” p2=”12 ,2 ” p3=”2003−05−27T00:15 :36 ”

3 p4=”1” /></ s:Body>

5

<s:Body>7 <item id=”Sensor1”>

<va lue>12 .2</ va lue>9 <d i s p l a y>12 ,2</ d i s p l a y>

<timestamp>2003−05−27T00:15 :36</timestamp>11 <qua l i t y>OK</ qua l i t y>

</ item>13 </ s:Body>

Listing 18: Readability of SOAP messages

It has to be taken into account that readability comes at a cost – as listing 18 shows,the second SOAP body is a lot larger than the first. Hence there may be cases wherea small message size is preferred to readability.

Representation of data types: Fieldbus data may be transported in many ways. It can,for example, be transported as simple strings, or it may be mapped to SOAP datatypes. Data hierarchies or structures may be expressed by XML in various ways.

Extensibility: Requirements to Web Services on Internet/fieldbus gateways may changeover time. Therefore it is important to specify SOAP messages so that they can beextended in the future. Listing 19 depicts an example SOAP body that describes afieldbus sensor that contains two values (Line 3 and Line 7) with three attributes.The client de-serializes the message according to the order of the XML elements. Thismessage is hard to extend, because if an additional attribute is needed and is appendedto the other attributes in the structure, clients will not be able to understand themessage73.

<s:Body>

73A better approach would be to name the attributes such as <value>12.2</value> and de-serialize themaccording to the element names. This way, additional attributes, which are inserted in the SOAP body dueto extension purposes, could be ignored by clients.

50


2 <item id=”Sensor1”><proper ty>12 .2</ proper ty>

4 <proper ty>12 ,2</ proper ty><proper ty>2003−05−27T00:15 :36</ proper ty>

6 <proper ty>OK</ proper ty><proper ty>11 .3</ proper ty>

8 <proper ty>11 ,3</ proper ty><proper ty>2003−05−27T00:15 :36</ proper ty>

10 <proper ty>OK</ proper ty></ item>

12 </ s:Body>

Listing 19: Extensibility of SOAP messages

Validation: SOAP messages are validated by an XML parser according to constraints de-fined by XML Schemas. The XML structure and the encoding has impact on thevalidation process which has to be taken into account when designing SOAP messages.

Fieldbus data embedded in SOAP messages may be validated by the XML parser. Thisis accomplished by constraining data by XML Schema, such as assigning specific datatypes to elements where fieldbus data is stored, such as <display xsi:type = ”xsd:string

”>Sensor1</display>. The huge advantage of this way is that all validations are doneby the XML parser, so it is not necessary to create one’s own validation algorithms tocheck the correctness of fieldbus data.

4.3.1 XML Attributes and XML Elements

Data may be stored in XML documents in various ways. Often the document designer has todecide if data should be embedded in XML elements or XML attributes. The SOAP messagein listing 20 shows an example where the same data is modeled in XML elements (line 2 to6) or in XML attributes (line 8)74.

<s:Body>2 <item>

<id>Sensor1</ id>4 <va lue>12 .2</ va lue>

<qua l i t y>good</ qua l i t y>6 </ item>

8 <item id=”Sensor1” va lue=” 12 .2 ” qua l i t y=”good”/></ s:Body>

Listing 20: Storing Data in XML Elements or XML Attributes

The decision between these two models is not easy and it is a topic which is often dis-cussed. [BIR01] suggests: “Use an element to represent objects that can exist on their ownindependent of any container element that they may be child of, and attributes to representits properties, which cannot exist without the object.” Generally, the following points shouldbe taken into account:

Hierarchies: Data structures which contain hierarchies can only be stored in XML elementsas XML attributes cannot contain subelements.

74Storing data in elements is called hierarchical model whereas storing data in attributes is called canonicalmodel. However, often data will be stored in a mixture of these two models.

51


Multiple Values: XML Attributes may only occur once, XML code such as <server node=

”1”node=”2”/> is not well-formed and is rejected by XML parsers.

Metadata: Data with related metadata can only be modeled by elements, such as <element

metadata=”123”>data</element>.

Readability and Document Size: The usage of XML Attributes leads to smaller docu-ments, as can be seen in Listing 20. Moreover, the XML parser75 is faster in dealingwith XML attributes. On the other hand, human legibility of XML documents is oftenbetter when data is stored in XML elements.

Order of Data: If the order of data is an issue, it has to be modeled by elements as theorder of XML attributes cannot be specified by XML Schema or DTD.

Extensibility: Generally, elements are easier to extend than attributes. Elements maycontain subelements, which is not possible for attributes.

Applied to fieldbus data, the decision between XML attributes and XML elements is alsonot easy. Standards in chapter 3 show that some fieldbus data may be encapsulated in bothways. However, human legibility and extensibility may be favored over document size andprocessing speed76, so that XML elements may be the preferred way to represent fieldbusdata in most cases. Some data such as the value will also need metadata which makes theusage of XML elements mandatory.

4.3.2 Identifying XML Data by Name Versus Order

XML data is commonly retrieved by addressing an element by its name (tag) and retrieving itsvalue. However, XML also provides addressing by the order of elements, similar to arrays inconventional programming languages. A developer designing XML documents, may thereforechoose between these two addressing schemas. Listing 21 shows an example where fieldbusdata is represented by XML code in three ways.

Line 1 to 5 depicts the commonly used addressing schema, where data is encapsulatedin XML elements that have unique names. Line 7 to 11 is an alternative where the datais modeled similar to an array. Data can be retrieved by the element’s index, similar to anarray. It is obvious that the order of the elements is important this way. Line 13 to 17 showsa mixture of the two examples above, where elements contain unique attributes which maybe used for addressing.

<item id=”Sensor1”>2 <va lue>12 .2</ va lue>

<d i s p l a y>12 ,2</ d i s p l a y>4 <qua l i t y>good</ qua l i t y>

</ item>6

<item id=”Sensor1”>8 <proper ty>12 .2</ proper ty>

75This applies to both XML parser types, namely the “Document Object Model” (DOM) and the “SimpleAPI for XML” (SAX).

76Fieldbus SOAP messages are small in size and simple, moreover, the bandwidth is not a limiting factor asInternet/fieldbus gateways may be connected to clients via fast LAN networks. Therefore the document sizeand the processing speed will not matter for most applications.

52


<proper ty>12 ,2</ proper ty>10 <proper ty>good</ proper ty>

</ item>12

<item id=”Sensor1”>14 <proper ty id=” va lue”>12 .2</ proper ty>

<proper ty id=” 12 ,2 ”>12 ,2</ proper ty>16 <proper ty id=” qua l i t y ”>good</ proper ty>

</ item>

Listing 21: Named Elements Versus Ordered Elements

A quick look at the listing shows the advantages of the named addressing schema:

Human legibility: The use of named addressing outlines the meaning of the data, such as<value>12.2</value>, which greatly improves human legibility.

Extensibility: As already stated above, addressing based on the order of elements may behard to extend, especially if the order of the elements has to be altered. On the otherhand, this addressing schema fits perfectly when embedding arrays in XML documents.

Validation: Constraining data by XML Schema is difficult if not impossible when using thesame element name for multiple data. The second example in Listing 21 shows a casewhere the value (float data type) and quality (string data type) are both embedded inan element called “property”. This way, it is hard to write XML Schema code thatconstrains the value to a “float” data type, while the XML Schema code for the firstexample is very simple: <xsd:element name=”value”type=”xsd:float”/>

The above examples make it obvious that the named addressing scheme is the superiormethod for most fieldbus data. The second example in listing 21 is hard to address andto constrain by XML Schema, and it is meaningless to human readers. The third examplehas no advantages compared to the first but contains redundant information while addingunneeded complexity to the XML code.

One exception are arrays which are embedded in XML documents. Listing 22 shows apossible method for embedding historic fieldbus data in an XML document.

<h i s t o r i c id=”Sensor1”>2 <va lue t s=”2003−05−27 00 : 1 5 : 3 6 ”>12 .2</ va lue>

<va lue t s=”2003−05−27 00 : 1 5 : 4 6 ”>12 .3</ va lue>4 <va lue t s=”2003−05−27 00 : 1 5 : 5 6 ”>12 .4</ va lue>

<va lue t s=”2003−05−27 00 : 1 6 : 1 6 ”>12 .3</ va lue>6 </ h i s t o r i c>

Listing 22: Named Elements Versus Ordered Elements

4.3.3 Encoding Fieldbus Data in SOAP Messages

Fieldbus data has to be encoded in some way when it is transported in XML documents.Most data will remain of the same type, therefore appropriate XML Schemas can be createdthat define the data encoding.

However, there are exceptions where the encoding cannot be defined clearly: Fieldbusnodes may contain values which are of different data types77, as depicted in figure 32. These

77Datapoints may represent various sensors, which provide data of different types, such as a simple counter(integer type), a temperature (float type) or complex data (string type).

53


values with different encoding have to be transported in the same XML document as shownin Listing 23.

Fieldbus Node Fieldbus Node

Fieldbus

Data Point

Value

Type: String

Data Point

Value

Type: Float

Data Point

Value

Type: Integer

Data Point

Value

Type: Date

Figure 32: Different Data Types on Fieldbus Nodes

<item id=”Sensor1”>2 <va lue>12 .2</ va lue>

</ item>4 <item id=”Sensor2”>

<va lue>On</ va lue>6 </ item>

Listing 23: Datapoint Values Embedded in XML Code

In this case, no fixed XML Schema for the “value” element may be used as the data typevaries over different XML code, which represent different datapoints. In order to validateand decode the XML code, the XML parser and de-serializer have to be somehow informedabout the data type of the values. The following solutions to this problem may be used:

1. Specified by Element: This way, certain XML elements are defined in XML Schemathat identify the data types. To give an example, a XML element <real> may thencontain only data of type “real”. An example XML code is shown in listing 24. Thisencoding style is used by [OBIX] and works well but has the major drawback that thehuman legibility is greatly reduced as the XML code does not outline that the encodeddata is a “value”.

<item id=”Sensor1”>2 < f l o a t>12 .2</ f l o a t>


<s t r i n g>On</ s t r i n g>6 </ item>

Listing 24: Data Type Specified by Element

2. Inline XML Schema: Inline XML Schema is another way of directly assigning datatypes to elements. An example listing is depicted in 25. This method is used by[OPCXMLDA] and is a decent solution to the encoding problem.

<item id=”Sensor1”>2 <va lue x s i : t y p e=” x s d : i n t ”>12 .2</ va lue>


54


<va lue x s i : t y p e=” x s d : s t r i n g ”>On</ va lue>6 </ item>

Listing 25: Inline XML Schema

3. Defining outside of XML: Another way is not to inform the XML parser and thede-serializer at all and transmit the data as strings and leave the validation and de-serialization to the application. Nevertheless, the XML code has to give the applicationa hint as to what data type it has to expect. This may be done by XML attributes, asdepicted in listing 26. This encoding style is used by [BACNET/WS]78

<item id=”Sensor1”>2 <va lue type=” f l o a t ”>12 .2</ va lue>


<va lue type=” s t r i n g ”>On</ va lue>6 </ item>

Listing 26: Datapoint Values Embedded in XML Code

All three encoding methods are appropriate solutions. However, the last solution forcesthe software developer to implement code for validation/de-serialization into the applicationwhich is not needed by the first two methods.

4.4 Handling of Latency and Timing Issues

Fieldbus systems consist of interconnected nodes that provide fieldbus data, which originatefrom various devices, such as sensors. From the point in time, at which the sensor data isread to the time when it is evaluated by some upper level application lies some latency, whichdepends on various factors.

This latency may be not important for most clients that retrieve fieldbus data fromInternet/fieldbus gateways. Clients will often collect statistical/historic information, or willretrieve data that is not timing critical. These applications only need to know the exact timewhen the data was valid, which is accomplished by delivering a timestamp79 associated to afieldbus value.

However, there may be applications where the timing is critical, such as for alarms orsystem notifications. In this case, the latency of the whole system has to be analyzed andmechanisms have to be implemented that guarantee a minimum delay.

Figure 33 shows that the overall latency consists of two basic delays, which could be called“fieldbus latency” and “SOAP latency”. Most industrial automation fieldbus systems, suchas Profibus, have real time capabilities. The fieldbus latency is predictable in this case andsimply adds a fixed delay to the overall latency.

The SOAP latency, as depicted in figure 34, is not easy to predict as the underlyingprotocols on a LAN/WAN, such as TCP/IP and HTTP, are not real-time capable. Moreover,the encoding and decoding time of the SOAP messages may vary80.

As figure 34 shows, the delay is caused by three factors:

78[BACNET/WS] calls the data point value “polymorphic” and encodes the data as simple strings.79This timestamp is generated by the fieldbus. Possible fieldbus latency and other timing issues will be

compensated by the underlying fieldbus technology itself.80When multiple SOAP requests have to be processed by the Internet/fieldbus gateway, or the gateway is

busy with other tasks, the encoding/decoding process cannot be predicted and may vary.

55


SensorInternet/fieldbus

Gateway

Client

ApplicationFieldbus Latency SOAP Latency

Figure 33: Latency of Internet/fieldbus Gateways

XML

Decoding

Netw

ork Latency Net

wor

k La

tenc

y

.

XML

Encoding

ProcessingXML

Encoding

XML

DecodingClient

Server

T_Enc T_Net T_Dec T_Proc T_Enc T_Net T_Dec

SOAP Delay

Figure 34: SOAP Latency

1. SOAP Processing: The SOAP message has to be decoded and encoded, and the XMLparser may have to verify the SOAP message. The processing time for these tasksdepends on the speed of the CPU and of the efficiency of the XML Parser and SOAPserializer. On a fast machine, this delay can probably be neglected. However, Inter-net/fieldbus gateways may contain slow CPUs and may have to process multiple SOAPmessages at once.

2. Network Delay: Clients are connected to Internet/fieldbus gateways via networks, whichmay be Local Area Networks (LANs), or Wide Area Networks (WANs)81. The networkdelay depends mainly on the bandwidth and latency of the network link. SOAP mes-sages will be transported by HTTP and TCP/IP, which have no real time capabilities.

A possible solution to circumvent timing problems is to minimize the overall load on thenetwork and the gateway. Moreover, it may be possible to implement an operating systemon the gateway that has real time capabilities.

Minimizing the network load may not be easy: Figure 35 depicts a case where two work-stations – unrelated to the fieldbus – produce a lot of network traffic causing a congestion onthe LAN.

Internet/fieldbus

Gateway

LAN

Client WorkstationWorkstation

Figure 35: LAN Congestion Delaying SOAP Communication

One possible solution to this problem is to set up a network path that is free fromcongestion. As this is not always possible, specific features of TCP/IP, such as “Quality

81The underlying technology may for instance be Ethernet, Frame Relay, ISDN.

56


of Service” (QoS) may be used to give the fieldbus communication precedence over othernetwork traffic82.

4.5 Other Internet/Fieldbus Gateway Issues

Apart from most common Internet/fieldbus gateway issues, which are covered above, thereare other aspects that should also be examined. For instance, smart caching strategies offieldbus data may greatly reduce the fieldbus load. Another interesting issue are system no-tifications, which cannot be easily implemented by the HTTP protocol but may neverthelessbe a reasonable way of improving the performance of an Internet/fieldbus gateway.

Caching of Fieldbus Data in the Gateway

There are situations where many clients request the same datapoint value from the Inter-net/fieldbus gateway. Traditionally, the gateway would acquire this value from the fieldbus,which may lead to high loads on the fieldbus.

To circumvent this problem, the gateway may implement data caching, so that a requestdoes not necessarily trigger fieldbus access. Instead of reading the requested data from thedatapoint, it sends the cached data from the gateway.

Although this technique may greatly reduce the load on the fieldbus, the delivered datamay be outdated – the “real” data in the fieldbus may have changed some time ago. Thisproblem may be circumvented by the following means:

1. Expiration: The cached data is accompanied by a timestamp, called “Expiration Date”.When a client requests this data from the gateway, it checks if the expiration date isolder than a certain amount of time, in which case the cache is refreshed by retrievingthe new value from the datapoint.

2. Subscription: Many fieldbus systems support a technique called “System Notifications”.This way, the gateway observes certain datapoints for value changes. In case of a valuechange, the fieldbus node sends the updated value to the gateway, which refreshes thecache entry.

System Notifications

Fieldbus clients are often interested in value changes. An example would be an alarm systemthat logs the value of a sensor that reports whether a door is open or closed. Many fieldbussystems support this technique by so-called “System Notifications”.

This mechanism cannot be mapped directly to the communication between Internet/field-bus gateways and their clients, as the underlying protocols differ. HTTP is a request/responseprotocol and does not provide means for system notifications. The only way for HTTP-basedcommunication is polling, which means periodically reading data from the gateway. Imple-menting system notifications by periodic polling contains the following problems:

High Network/System Load: Periodic polling causes a high network and system load, asperiodic SOAP messages have to be sent over the network processed by the gateway.

82The problem with this approach is that network devices, which are prone to congestion issues, have toimplement QoS, which is not the case for commonly used network devices.

57


Data Loss: If data changes are faster than the polling period, data loss occurs. If forexample the door sensor in an alarm system is set to “open” for only 5 seconds andthe polling period is set to 10 seconds, the client may never know that the door wasopened, as depicted in figure 36.

Datapoint Value

Poll

Polling Period

Time

OpenClosed Closed

Poll

Figure 36: Polling and Possible Data Loss

This problem may be solved by implementing buffers in the gateway, which store alldatapoint changes until they are fetched by a client. The appropriate size of thesebuffers is related to the time between the polls. More information about buffering canbe found in [OPCXMLDA].

Notifying the client by other means than polling is only possible in the following twoways:

1. Client implements a server: If the client implements a server that listens for notifica-tions, the gateway directly informs the client in case of value changes. Theoretically, itwould be possible to establish a Web Service on the client, which can be used for systemnotifications. The problem with this approach is on the one hand additional complexityand on the other possible security restrictions. Very often, clients are situated behindnetwork firewalls, which disallow incoming connections to clients.

2. Client holds the connection open: Another solution would be to open a connectionto the server which is never closed, so that possible system notifications may be sentdirectly.

[OPCXMLDA] introduces an interesting technique, called “Advanced Subscription”, asdescribed in chapter 3, where HTTP requests are not answered immediately. Instead,the connection is held open until a value changes, or a timeout occurs. This methodgreatly reduces the network and gateway load. However, HTTP was never designed forsuch a case and it is possible that other timeouts83 could lead to unexpected problems.

Theoretically, it would be possible to use other protocols for transporting SOAP mes-sages that keep an open connection between the client and the server. However, suchprotocols are not supported by current SOAP frameworks, moreover, security regula-tions will eventually block these protocols.

SOAP messages may also be transported by other means than HTTP. Therefore it ispossible to choose another protocol that is more suitable for system notifications. One possibleprotocol is SMTP, which is well known for transporting E-Mails over the Internet. SMTP issimple and a lightweight protocol and it is widely adopted. Moreover, some SOAP frameworksalready support SMTP.

83Proxies in between or lower level protocols also have timeouts that could be lower than the HTTP timeout.

58


Clients would request to be informed, whenever certain datapoint values change. In sucha case, the gateway would encapsulate the SOAP message with the fieldbus data in the SMTPprotocol and send it to the client, just like an ordinary E-Mail. This way, the gateway loadwill be greatly reduced, as there is no polling.

The problem with SMTP is that the delay cannot be predicted in any way. SMTPmessages may be routed over various relay stations, which may delay them for an unknowntime. In case of errors, the sender is notified – but this may also take considerable time.Moreover, the client also has to poll some server for the SMTP message84, which adds anadditional delay.

84It would also be possible to implement an SMTP server into the client, so that SMTP messages can bereceived directly by the client. However, setting up appropriate SMTP routing may prove difficult and willpossibly involve other servers due to security restrictions, which may be inappropriate.

59

5 SOAP Front end Design for the IGUANA Gateway

The IGUANA Internet/fieldbus gateway is a development of the Institute of Computer Tech-nology, Vienna University of Technology. Its main goal is to provide Internet access forvarious different fieldbus systems. This task is accomplished by abstracting underlying field-bus systems and providing fieldbus access through various Internet front-ends.

Apart from fieldbus data access, it implements several services, such as events, logging,asynchronous notifications, scheduled parameter uploads and access to a limited subset ofFAN node configuration.

The IGUANA gateway already implements various common Internet protocols, such asthe “Simple Network Management Protocol (SNMP) that can be used to access the underlyingfieldbus systems and several gateway services.

SOAP Web Services may be another way to access the IGUANA gateway and its under-lying fieldbus systems. However, there are various ways to implement SOAP on the gatewayand there may be several difficulties, such as limited processing power of the gateway orsuitable addressing and data representation of fieldbus data with SOAP that have to beovercome.

5.1 The IGUANA Gateway

The architecture of the gateway – depicted in figure 37 – basically consists of three separatelayers, namely an “Internet layer” for providing Internet access to the gateway, a “services anddata processing layer” that handles routing and implements several services, and a “fieldbuslayer” which provides connectivity to underlying fieldbus systems. The IGUANA gateway im-plements four types of modules that fit into one of these layers. These modules communicatewith each other with certain protocols and communication paths85.

Internet Notification

Originator (INO) 1

Extended Service Daemon (ESD)

IGUANA Gateway

FAN Daemon 3

Internet Front-End 2Internet Front-End 1

FAN Daemon 2FAN Daemon 1

Internet

Internet Layer

Services and Data

Processing Layer

Fieldbus Layer

Figure 37: Basic Architecture of the IGUANA Gateway

The modules are currently implemented as daemons on a UNIX86 operating system andcommunicate via stream-oriented TCP/IP protocols. This kind of communication enables

85These modules may be seen as clients and servers, which is denoted with the arrows in the picture. Forinstance, the “Extended Service Daemon” (ESD) is a client of the FAN daemons and the Internet NotificationOriginator, while it is a server for the Internet front-ends. On the other hand, the Internet front-ends areclients of the ESD.

86Currently, the IGUANA gateway is implemented on a LINUX operating system

60

5 SOAP FRONT END DESIGN FOR THE IGUANA GATEWAY

these modules to be placed on different hardware devices. This way an Internet front-endcould be situated on a device outside of the IGUANA gateway. However, the current imple-mentation consists of one hardware device that incorporates all modules.

The IGUANA gateway implements the following four module types:

1. Extended Service Daemon (ESD): This is the main module of the gateway and im-plements routing between fieldbus and Internet modules. Moreover, it implements thegateway services, such as event processing and data logging.

2. Internet Front-Ends: These modules implement various Internet protocols. Currentlythere are implementations for the following protocols:

• Simple Network Management Protocol (SNMP)

• Lightweight Directory Access Protocol (LDAP)

• Structured Query Language (SQL)

• World Wide Web protocols (WWW)

• Extended Service Daemon Protocol (ESD protocol)

More information about the implementation of these protocols can be found in [PRA01]and [SAUT02].

A SOAP Web Service on the IGUANA gateway would be implemented as an additionalInternet front-end.

3. Internet Notification Originator (INO): These modules can be used to send asyn-chronous notifications by means of Internet protocols. Currently available protocols areSMTP and SNMP.

4. FAN Connections: These modules provide connectivity to underlying fieldbus systems.Currently there are only implementations for LonWorks and two proprietary protocols.

Representation of Fieldbus Data in the IGUANA Gateway

The basic idea of the IGUANA gateway is to represent a variety of different fieldbus sys-tems with one unified data model. The basic element of this model is a “datapoint”, whichrepresents a piece of information. Every datapoint is connected to a fieldbus node, whichis connected to a fieldbus. Moreover, every fieldbus is connected to a FAN daemon in theIGUANA gateway. This scheme is depicted in figure 38. A datapoint can also be indexed,which means that it contains a set of values87.

The most important information of a datapoint is its value, such as a temperature of asensor, or the status of a switch. In addition, it contains properties of the datapoint, suchas its FAN-specific data type88, its access mode89, a datapoint name and a self identificationstring. The fieldbus node has also properties, such as the number of data points on this node,a self identification string and custom properties that may be used for the node location.

Properties may be seen as metadata that add vital information to a datapoint, its value ora fieldbus node. This metadata is collected from the underlying fieldbus system, if available.

87Indexed datapoints are currently used for historical data.88This property must not be confused with the encoding type of the value, which may be different to the

fieldbus specific data type.89This property denotes the accessibility of the datapoint, such as read-only or read-write.

61


Extended

Service

Daemon

(ESD)

IGUANA Gateway

FAN

Daemon 1

FAN

Node

DatapointFAN

Node

FAN

Node

FAN

Daemon 2

FAN

Node

FAN

Node

FAN

Node

Indexed

Datapoint

Field Area Network

Field Area Network

Figure 38: Fieldbus Nodes and Datapoints

However, several fieldbus systems do not provide such information, which means that in thiscase these properties either have to be configured in the gateway or are left blank. Thereforeapplications on top of the IGUANA gateway, which are not fieldbus specific, should notdepend on metadata, as it may not be available.

Fieldbus data has to be encoded in some way. The IGUANA gateway introduces sev-eral encoding styles which are associated with appropriate data types. Currently, the mostimportant encodings are as follows:

STRING: A string is a sequence of characters such as letters or numbers. This data typecomplies to a “string” in various programming languages.

TIME: The TIME data type is a long integer that stores the number of seconds elapsedsince 01.01.197090 .

SCALARBIN: The SCALARBIN data type complies to a 32 bit floating point data type.

BINHEX: This data type is used to represent fieldbus specific data. The binary datapointvalue is converted into a string, where each binary octet is translated into two hexadec-imal digits, such as “0A FF 12 17 C3”91. Any fieldbus specific data types, and alsocomplex data structures, may be encoded this way. However, the client has to be awareof the underlying fieldbus technology to decode the BINHEX data type.

The IGUANA gateway maps any fieldbus specific data type into all possible encodings.Numeric data of types such as integer or float can be represented by the SCALARBIN orthe STRING type, while complex data types can only be represented by the BINHEX datatype, as depicted in figure 39.

ESD uses the addressing schema of the underlying fieldbus and extends it by addingIGUANA specific addressing items. Together these elements form a unique address whichmay be used to access fieldbus data. The addressing structure is hierarchical, as depicted infigure 40. It consists of four hierarchies, including the type of the fieldbus, such as “LON”,the fan network, the node address and datapoint address. In the case of indexed datapoints,the index is also part of the address. The format of the address, especially of the node anddatapoint address, depends on the underlying fieldbus system.

90This data type corresponds to the “time t” data type of the POSIX.1 standard, also known as “UNIXtimestamp”.

91The IGUANA BINHEX data type must not be confused with the BinHex data type, which was introducedby Apple and is described by RFC 1741. Although the data types are similar, RFC 1741 introduces a simplemechanism to compress repetitive characters.

62


Numeric Data

Str ing Data

Fieldbus Speci f ic Data

STRING

SCALARBIN

BINHEX

BINHEX

BINHEX

STRING

Figure 39: Data Encoding in the IGUANA Gateway

Fieldbus Type

(FANTYPE)

Fieldbus identifier

(FANid)

Fieldbus Node Address

(FanNodeAddress)

Data point identifier

(DPid)

Figure 40: ESD Addressing Scheme

This addressing hierarchy is automatically set up by the IGUANA gateway and is dynam-ically changed if fieldbus nodes are connected or disconnected. This has the advantage thatno configuration is needed and new fieldbus devices are automatically detected and addedinto the hierarchy.

IGUANA Gateway Services:

As denoted above, the IGUANA gateway implements several services. The key to theseservices is an event processor, which triggers so-called “actions” if certain “criteria” are met.Criteria and actions are defined with a special language, called “Event Language”. If a certainevent is triggered, for instance by the gateway boot, or when a certain time has elapsed, theevent processor checks if user defined conditions are met, such as if a datapoint value haschanged, or is greater or less than another datapoint value. If the condition is met, an actionis executed, such as logging, or sending an asynchronous notifications via SMTP or SNMP.This procedure is depicted in figure 41. Further references can be found in [PRA01] and[LOB02].

Criteria

BOOT

SHUTDOWN

REPEATING

DISPOSABLE

...

Condition

CHANGED

LT

GT

EQ

...

Action

LOG

SMTP

SNMPTRAP

SNMPINFORM

DPWRITE

Trigger

Figure 41: IGUANA Event Processor

The following actions are currently implemented:

Logging: This action logs a datapoint value in a specified encoding with an according times-tamp and a text message. The number of log entries are defined when the event is

63


created. In case the log is full, oldest entries are discarded. Log entries are alwaysassociated to events and may be retrieved from the ESD.

Datapoint Write: The Datapoint Write action may be used to write predefined values tocertain datapoints.

Asynchronous Notifications: In the case of this action, an asynchronous notification, suchas an E-Mail or an SNMP-Trap can be sent to a previously specified destination.

The Extended Service Daemon (ESD) Protocol:

Communication between IGUANA modules is implemented with specific protocols, whichwere designed for the IGUANA gateway. One of these protocols is the “ESD protocol”,which is dedicated to the communication between an Internet front-end and the ESD92.

The protocol is textual-based and stream-oriented, similar to the “Simple Mail TransferProtocol” (SMTP) and consists of single line commands and according response messages,which may be basic (single line) and extended (multiple lines). Such a command/responsesequence is shown in Listing 27 with the request in the first line and the response in thesecond.

DPINFO LON.GATE3!21 @01 : 0 2 : 03 : 04 : 05 : 062 0 LON.GATE3!21 @01 : 0 2 : 03 : 04 : 05 : 06 114 BINHEX ‘ ‘ nvoLedFb ’ ’ ‘ ‘LED1 Feedback ’

’

Listing 27: Example command/response messages in the ESD protocol

The addressing of a datapoint corresponds to the hierarchical addressing schema denotedabove and is formatted as depicted in figure 42. An example address can be seen in listing27.

FANTYPE.FANID!Datapoint ID@FanNodeAddress

FANTYPE.FANID!Datapoint ID. index@FanNodeAddress

Datapoint Address:

Indexed Datapoint Address:

Figure 42: Address Format in the ESD Protocol

The following commands are available in the ESD protocol:

READ: This command retrieves the value of a datapoint in a requested encoding style. Anexample is given in Listing 28.

READ LON.GATE1!21 @01 : 0 2 : 0 3 : 04 : 05 : 06 BINHEX2 0 LON.GATE1!21 @01 : 0 2 : 03 : 04 : 05 : 06 BINHEX ‘ ‘01 0F A0 3F 6A’ ’

Listing 28: Example READ request in the ESD protocol

WRITE: The WRITE command writes a value to a datapoint in a specified encoding style.An example is given in Listing 29.

WRITE LON.GATE1!21 @01 : 0 2 : 03 : 04 : 05 : 06 BINHEX2 0 OK

Listing 29: Example WRITE command in the ESD protocol

92Other protocols would be the FAND protocol, which is basically a subset of the ESD protocol and is usedfor the communication between the ESD and the FAN daemons and the “Internet Notification Originator”(INO) protocol, which is designed for the communication between an INO daemon and the ESD.

64


DPINFO: This command retrieves the properties of a datapoint. An example can be seenin Listing 27.

NODEINFO/ENODEINFO: The Nodeinfo and Extended Nodeinfo commands can beused to retrieve the properties of a given fieldbus node.

Retrieving/Updating the Nodelist: These commands can be used to retrieve a list ofnodes that are connected to a fieldbus. Moreover, they can be used to update the listif nodes are disconnected or new nodes are connected to the fieldbus.

Commands regarding the event processor: These commands can be used to create,delete or list events stored in the ESD.

Commands related to logging: The logging commands are used to retrieve or clear logsassociated to certain events.

Detailed information about the ESD protocol can be found in [LOB02].

5.2 Encapsulating the IGUANA Protocol into SOAP Messages

One way to implement a SOAP Web Service in the IGUANA gateway is to encapsulate theESD protocol into a SOAP message, as depicted in figure 43.

SOAP Envelope

SOAP Header

(optional)

SOAP Body

ESD Code

Figure 43: Encapsulating the ESD Protocol in SOAP Messages

Encapsulating ESD may be done in the following ways:

Encapsulate ESD code “as is”: The easiest way is to put the ESD code directly into theSOAP body. ESD code consists of simple ASCII encoded strings. Therefore, the mostobvious way would be to define an XML element, such as <ESD></ESD>, where theESD code can be embedded.

However, this raises some problems, as ESD code may contain XML specific data,such as characters like “<”. This problem may be circumvented by converting thesecharacters to XML entities93. Such XML code is called “Encoded XML”. Another waywould be to use a specific XML element, called “<[!CDATA[...]]>”94. A sample SOAPmessage that embeds ESD code is shown in listing 30.

<s :Enve lope xmlns : s=” h t tp : //www.w3 . org /2001/06/ soap−enve lope”>2 <s:Body>

93For instance, characters like “<,>,&,” would be converted to “<,>,&”94Between the brackets all characters are allowed except two closing brackets.

65


<esd>READ LON.GATE1!21 @01 : 0 2 : 03 : 04 : 05 : 06/00 : 0 3 : 0 5 BINHEX</ esd>4 </ s:Body>

</ s :Enve lope>

Listing 30: ESD Code Embedded in a SOAP Message

This method is easy to implement and already available tools and functions that arebased on the ESD syntax may be reused completely this way. Moreover, the goodcommunication abilities of SOAP/HTTP may be used95.

However, these advantages come at a high price: The gateway has to implement anXML parser with considerable hardware requirements. Moreover, the XML parsercannot be used to validate fieldbus data due to the structure of the ESD messageformat. Therefore the real advantage of XML documents – conveying metadata forvalidation and processing purposes – is left out.

Moreover, the ESD code depends a lot on whitespace96. Although the XML parser willnot alter the whitespace97 and passes it to the applications “as is”, possible reformattingof the SOAP message by client applications or debug tools could alter whitespace andmake the ESD code erroneous. Structuring data with elements is more natural in XMLdocuments and should be preferred over delimiting with whitespace.

Translate ESD code to XML Code: Handling the ESD code requires in depth knowl-edge of the underlying protocol. One solution would be to translate the ESD code intoanother structure that can be described by WSDL, which simplifies client access. Thistranslation may be done in various ways. A simple example is given in listing 31.

1 0 LON.GATE1!21 @01 : 0 2 : 03 : 04 : 05 : 06 BINHEX ‘ ‘91 9F A0 3F 6A’ ’

3 <response−ba s i c s t a tu s=”0”><addres s>LON.GATE1!21 @01 : 0 2 : 0 3 : 04 : 05 : 06<addres s>

5 <data encoding=”BINHEX”>91 9F A0 3F 6A</data></ response−ba s i c>

7

<response−ba s i c>9 <fantype>LON</ fantype>

<f an id>GATE1</ fan id>11 <node>01 : 0 2 : 0 3 : 0 4 : 0 5 : 0 6</node>

<datapo int>21</ datapo int>13 <s t a tu s>0</ s t a tu s>

<data encoding=”BINHEX”>91 9F A0 3F 6A</data>15 </ response−ba s i c>

Listing 31: Translated ESD Code

Line 1 depicts the untranslated ESD code. Line 3 to 6 shows a possible translation,where the ESD code is split and embedded in several XML elements. The example inLine 8 to 15 also splits the datapoint address into several elements.

95ESD may also be transported via HTTP without the use of SOAP. This way, the good communicationabilities of HTTP may be used without the need of an XML parser or SOAP framework.

96Whitespace are the characters “ASCII space”, “horizontal tab” (HT), “line-feed” (LF) and “carriage-return” (CR).

97The XML specification states that whitespace in element contents must not be altered by the XML parserwith the only exception that a CR or CR/LF has to be converted to a single line feed. This is different toHTML, where whitespace is removed by the parser.

66


One advantage of this translation is easy data access through the XML parser. Nowhitespace parsing has to be done, fieldbus data can easily be accessed by addressingXML elements. Another advantage is human readability, which is improved comparedto the conventional ESD code.

Translating ESD into XML code may be done in different ways. However, there arevarious available standards, as shown in chapter 3. If this “translation process” is donein a standard compliant way, the interoperability between the Internet/fieldbus gatewayand according clients will be vastly improved.

Addressing Scheme

One possible problem of the IGUANA addressing schema is that the hierarchy may not bevery structured in cases of house installations where a small number of fieldbuses containa large number of nodes. This way, the third level of the hierarchy will be very large anddifficult to overlook. Moreover, the addressing schema gives only a technical perspective ofthe fieldbus. In many cases, other views, such as geographical or logical would be moreappropriate.

This problem could be solved by creating custom hierarchies, as shown in figure 44. Asimilar technique, called “reference nodes” is also suggested by [BACNET/WS]. However,ESD and the IGUANA gateway do not support such additional addressing schemes, whichmeans that logical hierarchies would have to be implemented by the Web Service itself.Moreover, such hierarchies would have to be configured at start up and during operation, incase new fieldbus nodes are added or removed.

Root

Sensor1Sensor2Sensor1

Room3Room2Room1

LON.Gate1!21@01:02:03:04:05:06

LON.Gate1!22@01:02:03:04:05:06

LON.Gate2!24@01:02:03:04:05:08

Figure 44: Mapping ESD addressing to a logical tree.

[VEN05] suggests to configure a logical hierarchy by using metadata provided by thefieldbus. The problem with this approach is that it is fieldbus specific and may not bepossible for different fieldbus systems98. The IGUANA gateway is meant to be generic andnot fieldbus specific, therefore the use of metadata for building logical hierarchies contradictsits design.

Data Types and Encoding

XML elements, containing one of the ESD encodings STRING, TIME and SCALARBIN maybe mapped to XML Schema compliant data types and may therefore be validated by an XMLparser. For instance, SCALARBIN encoded data could be embedded in an XML element like<value xsi:type=”xsd:float”>12.2</value>.

98For instance, LON provides appropriate metadata, such as a location string, while other fieldbus systemsdo not.

67


The only exception is the BINHEX encoding, which is fieldbus specific and may not bevalidated in detail. However, the format of the data may be checked by mapping the BINHEXtype to the XML Schema “hexBinary” data type, which is basically the same99.

As shown above, the IGUANA gateway implements only a very limited set of data types.Underlying fieldbus systems may provide various other data types, such as specific date/timetypes, or complex types, like arrays or structures. Theoretically, it would be possible tomap many of these data types to corresponding XML Schema types, hence implement somekind of data type translation. ESD provides the “DPINFO” command, which returns thefieldbus specific data type of a datapoint. This information could be used to represent thefieldbus data with a suitable XML Schema data type. However, the underlying data type isfieldbus specific, moreover, DPINFO will not return the data type for various fieldbus systemsthat simply do not provide data types. Hence, data type translation will be complicated toimplement and may raise interoperability issues, therefore it is preferable to use the limitedset of data types provide by the IGUANA gateway and and encode fieldbus specific data withthe BINHEX data type.

5.3 Representing the IGUANA Interface with an XML compliant OPCstandard

OPC provides various standards that guarantee interoperability between OPC compliantdevices. More recent standards focus on Web Services technology, such as [OPCXMLDA],described in chapter 3.1, that specifies data access in fieldbus systems with SOAP WebServices.

An OPC XML-DA compliant interface is based on an underlying OPC server that com-municates with the IGUANA gateway. This server may be either situated on the gatewayitself or on another hardware device, such as a personal computer100, as shown in figure 45.

OPC XMLDA

Server

SNMPv3 Internet

Front-End

ESD Protocol

Front-End


OPC XMLDA

Server

SNMPv3 Internet

Front-End

ESD Protocol

Front-End


IGUANA Gateway

PC Hardware

IGUANA Gateway

Figure 45: An OPC XML-DA Server on the IGUANA Gateway.

According to the architectural design of the IGUANA gateway, an OPC XML-DA serveris simply another Internet front-end, similar to the SNMP or LDAP Internet front-end. ThisOPC XML-DA server will communicate with the IGUANA main module, the “Extended

99The minor difference is that the IGUANA BINHEX encoding has whitespace between each octet, whilethe XML Schema hexBinary has none.

100Although it seems most appropriate to place the OPC server directly on the IGUANA gateway, hardwarelimitations or the lack of appropriate OPC toolkits may lead to implementations, where the OPC server issituated outside of the gateway. In such cases, it will often be placed on a personal computer, which may alsobe used for client applications.

68


Service Daemon” (ESD) and will basically “translate” the ESD protocol to OPC XML-DAcompliant messages. Moreover, it will have to implement OPC specific functionality, such asbrowsing and subscription. To accomplish this task, the OPC server has to address severalissues, such as data encoding, data type conversion, addressing and data buffering/caching.

5.3.1 Representing Datapoint Values with OPC

The IGUANA gateway represents fieldbus data as datapoints which have a value and someproperties. OPC XML-DA on the other hand represents fieldbus data with so-called “Items”that have “ItemProperties”. These two fieldbus data representations resemble each other,hence a datapoint may be represented with an OPC Item.

Data Encoding, Data Types and Type Conversions

The IGUANA gateway encodes fieldbus data in various ways, such as encoding a sensor valuewith the SCALARBIN or BINHEX encoding. [OPCXMLDA] does not address encodingissues at all but defines 20 simple data types and also provides enumerations and 14 differentarray types that may be associated with OPC Item values as partially shown in figure 46.

Data Type Description

string A sequence of UNICODE characters.

boolean A binary logic value (true or false).

float An IEEE single-precision 32-bit floating point value.

double An IEEE double-precision 64-bit floating point value.

decimal A fixed-point decimal value with arbitrary precision.

long A 64-bit signed integer value.

int A 32-bit signed integer value.

short A 16-bit signed integer value.

byte An 8-bit signed integer value.

unsignedLong A 64-bit unsigned integer value.

unsignedInt A 32-bit unsigned integer value.

unsignedShort A 16-bit unsigned integer value.

unsignedByte An 8-bit unsigned integer value.

base64Binary A sequence of 8-bit values represented in XML with Base-

dateTime A specific instance in time.

time An instant of time that recurs every day.

date A Gregorian calendar date.

duration A duration of time as specified by Gregorian year, month,

day, hour, minute, and second components.

QName An XML qualified name comprising of a name and a

namespace. The name must be a valid XML element

anyType document with the 'type' attribute. This type only has

relevance when used as an element in an array.

Figure 46: Available Simple OPC XML-DA Data Types for Item Values as Specified in[OPCXMLDA].

The best way seems to represent encodings with OPC Items, as depicted in figure 47101.This way, fieldbus data may be provided in multiple encoding styles.

[OPCXMLDA] assigns to every OPC Item a so-called “canonical data type” which is thedefault data type associated with a fieldbus value. The IGUANA gateway does not providesuch information, however encodings may be mapped to certain data types as shown in figure

101Another way would be to map IGUANA encodings to OPC data types, such as mapping SCALARBIN toa float data type or TIME to a time compliant data type in a 1:1 mapping style. However, the encoding of theIGUANA gateway may be extended; For instance a new encoding style may be introduced which would alsomap to a float data type but is different from the SCALARBIN encoding. This would lead to n:1 mappingsin which case retrieving data in certain encoding styles would be impossible.

69


OPC Root Item

OPC Item 1

(Numerical data)

SCALARBIN STRING BINHEX

OPC Item 1

(String data)

STRING BINHEX

Figure 47: Representing IGUANA encodings as OPC Items.

48. An OPC XML-DA compliant server on the IGUANA gateway would therefore implementthree canonical data types, namely “string”, “float” and “dateTime”.

IGUANA Encoding style OPC XMLDA Data Type Comment

STRING string

SCALARBIN float 32-bit floating point number

TIME dateTime

BINHEX string Base64 is also possible

Figure 48: Associating data types to IGUANA encoding styles.

The BINHEX encoding is mapped to a simple string, as the OPC specification does notinclude the XML Schema data type “hexBinary” that would be suitable for this encodingstyle. Another approach would be to re-encode the data into the Base64 encoding102. Thisapproach would reduce the network load due to a reduced size of Base64 encoded datacompared to BINHEX but would also increase the load on the IGUANA gateway due to there-encoding.

Data types implemented by an OPC server have a certain range and precision. Forexample, a dateTime data type could be implemented as a UNIX timestamp which can onlystore dates between 1902 and 2038. [OPCXMLDA] specifies the minimum range and precisionfor OPC data types. In case the precision or the range is lower, the client must be informedabout this fact. The OPC specification defines three specific properties for this task, called“minimumValue”, “maximumValue” and “valuePrecision”. In case the range is exceeded, theOPC server returns a specific “E RANGE” error. If the precision of a value is higher thansupported, the OPC server silently rounds it.

With the exception of the “dateTime” data type, all other canonical data types of an OPCServer on an IGUANA gateway support the default ranges and precisions. For these datatypes, the minimum, maximum and precision properties may be omitted. OPC Items of thedata type “dateTime” have to provide the minimum and maximum properties, as depictedin figure 49.

Canonical OPC XMLDA Data types minimumValue maximumValue

dateTime 1901-12-13T20:45:52Z 2038-01-19T03:14:07Z

Figure 49: Range Item Properties for the “dateTime” data type

Values from OPC XML-DA compliant servers may be retrieved in various data types.For instance, the canonical data type of an OPC Item may be “float” and an applicationwants to retrieve this data as a “string”. [OPCXMLDA] specifies which data conversionsmust be implemented. However, not all conversions have to be implemented for an IGUANAOPC server as it provides only a limited set of data types. Moreover, some data types

102This encoding style was created for transferring binary content over text-based mail systems. Moreinformation can be found in [R2045].

70


such as “duration” cannot easily be implemented on the IGUANA Gateway as they haveno corresponding counterpart. Such data types will be omitted. Figure 50 illustrates allnecessary type conversions.

string float (SCALARBIN) dateTime (TIME) string float (SCALARBIN) dateTime (TIME)

string OK OK OK string OK (6) (6)

boolean OK (1) (3) OK (3) (7) boolean OK OK (3) (7)

float OK (1) (2) (5) OK (7) float OK OK (7)

double OK (1) (2) (5) OK (7) double OK OK (2) (5) (7)

decimal OK (1) (2) (5) OK (7) decimal OK OK (2) (5) (7)

long OK (1) (2) (5) OK (2) (5) (7) long OK OK (5) (7)

int OK (1) (2) (5) OK (2) (7) int OK OK (7)

short OK (1) (2) (5) OK (2) (7) short OK OK (7)

byte OK (1) (2) (5) OK (2) (7) byte OK OK (7)

unsignedLong OK (1) (2) (5) OK (2) (5) (7) unsignedLong OK OK (5) (7)

unsignedInt OK (1) (2) (5) OK (2) (7) unsignedInt OK OK (7)

unsignedShort OK (1) (2) (5) OK (2) (7) unsignedShort OK OK (7)

unsignedByte OK (1) (2) (5) OK (2) (7) unsignedByte OK OK (7)

dateTime OK (1) (2) (5) (7) OK dateTime OK (7) OK (2)

time OK (1) (2) (5) (7) OK (5) time OK (7) OK (2)

date OK (1) (2) (5) (7) OK (5) date OK (7) OK (2)

base64Binary (4) (4) (4) base64Binary (4) (4) (4)

duration (4) (4) (4) duration (4) (4) (4)

QName (4) (4) (4) QName (4) (4) (4)

anyType (4) (4) (4) anyType (4) (4) (4)

(4) These data types and conversions are not implemented by the OPC Server.

Su

bm

itte

d O

PC

XM

LD

A D

ata

Typ

es

Req

ueste

d O

PC

XM

LD

A D

ata

Typ

es

(5) In case of precision loss (e.g. converting from float to integer), values

have to be rounded. No error has to be reported.

(1) If the conversion from a string type to a numeric or date type fails, the error

"DISP_E_TYPE" has to be returned.

(2) Conversions to "smaller" data types are allowed. In case an overflow occurs,

the Error "DISP_E_OVERFLOW" has to be returned.

(3) Numeric types with value "0" and strings with value "true" are converted to

"true", otherwise they converted to "false".

(6) During write operations, conversions from string to numeric or date

types are not allowed by the XMLDA specification.

(7) DateTime to numeric conversions may be supported but are not

neccessary for an XMLDA compliant OPC server.

Read Operations Write Operations

Canonical XMLDA

Data Types on the IGUANA Gateway

Canonical XMLDA

Data Types on the IGUANA Gateway

Figure 50: Data Conversions During a READ Requests from Canonical Data Types to theRequested Type

Addressing Scheme

The syntax of the addressing scheme is not specified in OPC XML-DA, instead OPC leavesthis issue open to the implementation of the server. OPC XML-DA only specifies the twoXML elements “ItemPath” and “ItemName” that together uniquely identify the address ofthe OPC Item. The specification allows to use only “ItemName” for addressing and omit theelement “ItemPath”.

The most natural way to implement the IGUANA addressing scheme in OPC is to placethe address into the “ItemName” element. 103 The hierarchical structure of the IGUANAaddressing scheme allows hierarchical browsing in the object hierarchy. However, the formatof the IGUANA addressing scheme may prove inappropriate as hierarchical addresses arecommonly formatted in a URL like style, which consist of character strings, delimited bythe slash (“/”). Another way is to format the address similar to variables in object-orientedprogramming languages by delimiting the addressing elements with the dot (“.”) character,such as server1/node2/datapoint3 or server1.node2.datapoint3. Therefore IGUANA addressesmay be translated, as shown in figure 51.

An IGUANA address may contain any printable character, with the exception of thethree special characters “!”, “.” and “@”, which are used as delimiters. This means that theslash or dot character may theoretically be part of the IGUANA address. Therefore it has to

103The “ItemPath” element is not necessary and can be omitted.

71


FANTYPE.FANID!DPID@FanNodeAddress /FANTYPE/FANID/FanNodeAddress/DPID

FANTYPE.FANID!DPID@FanNodeAddress FANTYPE.FANID.FanNodeAddress.DPID

Figure 51: Translating the IGUANA Addressing Format to a URL Like or a “Programmingstyle” format

be escaped104, so that possible occurrences of the slash character are not confused with theaddress delimiter.

For retrieving fieldbus data, the encoding style has to be concatenated to the translatedIGUANA address. This way a fieldbus value may be retrieved in a particular IGUANAencoding style. An example address is shown in figure 52.

LON.GATE2!21@01:02:03:04:05:06

/LON/GATE2/01:02:03:04:05:06/21/SCALARBIN

/LON/GATE2/01:02:03:04:05:06/21/STRING

/LON/GATE2/01:02:03:04:05:06/21/BINHEX

Figure 52: Translating the IGUANA addressing format to a URL like format

OPC XML-DA Faults and Result Codes

[OPCXMLDA] also specifies the handling of abnormal conditions and errors, such as serverfaults, invalid requests or errors from the underlying fieldbus. The specification distinguishesbetween the following two errors:

1. Errors concerning whole operations: In cases, where a whole operation (such as aread or write request) cannot be performed, a SOAP fault is returned to the client105.This may happen if the OPC server fails, or a bad request is received that cannot beprocessed.

2. Errors concerning single items: If an operation is partly successful but some itemshave errors, for instance, if a requested value is unavailable or cannot be converted to therequested datatype, an OPC server processes the operation and outlines which parts ofthe operation failed through so-called “result codes”. For this purpose, [OPCXMLDA]specifies the attribute “ResultID” which is placed at the erroneous item and outlinesthe reason for the failure and additionally the element < OPCError >, which may beused as a description for the error106.

104One possible way would be to use the exclamation mark (“!”) for this purpose, as this character must notbe part of the address. This way, a string, such as ab/cd/e would be escaped as ab!/cd!/e.

105Interestingly SOAP faults, as depicted in the XML-DA specification, do not conform to the SOAP stan-dard. The SOAP 1.1 standard specifies in section 4.1.1 that the element < faultcode > must contain one offour specific codes, which differs from the OPC XML-DA specification, where custom error codes are embeddedin the < faultcode > element.

106Moreover, the OPC property “quality” has to be set to “Bad”.

72


[OPCXMLDA] defines in section 3.1.9 23 result codes107 that should cover the mostcommon failures. Moreover, the standard allows to define custom result codes.

The IGUANA gateway reports errors through specific ESD response messages, such asdepicted in listing 32.

DPINFO LON.GATE3!21 @01 : 0 2 : 03 : 04 : 05 : 062 5003 Syntax e r r o r in the Node or Data Point addres s

Listing 32: Example Error Response Message of the ESD Protocol

These ESD error responses may be mapped to OPC errors. ESD errors concerning thewhole operations, such as IGUANA gateway or syntax errors may trigger SOAP faults, whileerrors concerning single items, like addressing or fieldbus specific errors may be representedwith OPC result codes, as depicted in figure 53.

ESD Error Message

Error concerning

whole operation?SOAP Fault Message

SOAP Response with

Result Code Denoting

the ESD Error

yes

no

Figure 53: Mapping ESD Errors to OPC XML-DA compliant Error Handling

The decision of whether ESD errors are mapped to SOAP fault or result codes cannotbe determined from the ESD error codes. Moreover, some ESD errors may be mapped tocompliant OPC XML-DA error codes. These issues may be solved by a simple table in theOPC server that denotes how ESD errors will be mapped. However, this has the disadvantagethat changes in the ESD error handling will not be reflected by the OPC XML-DA server108.

OPC XML-DA properties and IGUANA datapoint properties

IGUANA datapoints and OPC Items have different properties that may not match eachother, or are simply missing.

The OPC XML-DA standard does not specify mandatory properties, which means thatin theory an Item does not need any properties at all109. However, some of these propertiesare needed for certain services, which makes these properties mandatory110. Therefore some

107To be specific, the standard specifies 20 error codes and 3 so-called “Success Codes”, which are more orless warning messages. Error codes always begin with the characters “E ” while success codes start with “S ”.Custom result codes have to follow this convention.

108A possible solution would be to set SOAP faults as the default error handling. This way, unknown ESDerror codes will trigger SOAP faults.

109A meaningful example would be an OPC Item that is the parent of another Item, which is commonly usedin cases of hierarchical addressing. Such a “parent Item” would not need any properties because it serves asa logical container of other OPC Items.

110For instance, the property “dataType” is used to define the Item’s canonical data type. This informationis needed for read operations that do not specify the requested data type. Without the “dataType” propertythe client would not know to which data type the requested fieldbus data should be mapped.

73


important OPC Item properties have to be available, moreover, it makes sense to implementproperties that have a corresponding counterpart in the IGUANA gateway. This may be doneby mapping certain OPC Item properties to IGUANA datapoint properties, as depicted inFigure 54.

OPC XMLDA Item Properties IGUANA Datapoint Properties

OPC-XMLDA

Qualified Name

Description Corresponding

Property

Comment

dataType The canonical data type of the item - Has to be retrieved from a table in

the OPC server, such as

"SCALARBIN" to "float".

value The value of the item value This property is mapped directly.

quality This property denotes the "Quality"

of the value, for instance if it is "Ok"

or "Uncertain"

- The IGUANA gateway does not

implement data quality.

timestamp The time the value was valid. - Timestamp may be set by the OPC

server when it recieves data from

the fieldbus.

accessRights Access rights, such as "readable" or

"writeable".

Access Mapping through simple translation,

such as "RO" to Readable.

scanRate Represents the fastes rates at

which the server could obtain data

from the underlying fieldbus.

- May be set at a fixed number to

reduce possible gateway load.

description Descriptive string sid_str May be set to the self identification

string of the datapoint.

Figure 54: Mapping OPC Item Properties to IGUANA Datapoint Properties

Some mappings of Properties between OPC and IGUANA cannot be done directly. Pos-sible solutions to these mappings are as follows:

dataType: OPC Items have a so-called “canonical data type”, which outlines in which datatype the fieldbus data is encoded by default. The IGUANA gateway does not directlyprovide such metadata111, however IGUANA encoding styles may be associated withappropriate data types, as stated above.

quality: OPC specifies the property “quality” for informing client applications about thestatus of the fieldbus data. Possible values are “Good”, “Bad” and “Uncertain”. TheIGUANA gateway does not provide information about the data quality and does notimplement a corresponding property. However, if the ESD returns an error whichis mapped to an appropriate OPC result code, the quality must be set to “Bad”.[OPCXMLDA] also defines that the property is only mandatory if the quality is otherthan “Good”. The most suitable solution seems to be to entirely omit the qualityproperty except ESD returns an error112.

timestamp: [OPCXMLDA] states: “The servers will provide the most accurate timestampto associate with a value. The timestamp should indicate the time that the value andquality was obtained by the device or the time the server updated or validated the valueand quality in its cache.”

111The IGUANA gateway has a datapoint property called “DataType” which seems like a correspondingproperty. However, this property defines the FAN-specific data type which is in a fieldbus specific formatand is implemented for fieldbus specific clients. Therefore it cannot be used for the OPC “dataType” Itemproperty.

112Setting the quality property to “Good” would be a bad solution, as there may be underlying fieldbussystems that implement data quality. In such a case the fieldbus data may be “Bad” or “Uncertain”, whichis not reported by the IGUANA gateway. This would be misleading which is the reason why the propertyshould be omitted if no error occurs.

74


The IGUANA gateway does not provide timestamps from underlying fieldbus systems.Therefore the only way to implement this OPC property is to set the timestamp bythe OPC server itself. As figure 55 shows, the actual fieldbus read, which is the mostaccurate time where the data is valid113, will be somewhere between the ESD readrequest and its read response.

Request Response

Possible Fieldbus Reads

Time

Figure 55: Possible Fieldbus Data Reads Between the ESD READ-Request and READ-Response

The timestamp may therefore be set somewhere between these two points. One way toapproximate the time would be to calculate an average value, such as by timestamp =(trequest + tresponse)/2. However, a jitter still remains, moreover, there may be caseswhere the timestamp is set to a time before the data was valid, which may be inappro-priate for various applications. Therefore it may be best to simply set the timestampto the time the response message is received.

accessRights: This OPC property specifies the accessibility of the OPC Item. Valid optionsare “unknown”, “readable”, “writeable” and “readWritable”. ESD on the other handimplements the property “Access” that is mandatory and may be mapped to its OPCcounterpart. The string format, as specified in section 5.13 in [LOB02] is slightlydifferent and has to be translated114.

scanRate: [OPCXMLDA] states: “This represents the fastest rate (in milliseconds) at whichthe server could obtain data from the underlying data source.”

Although such information is not available from the IGUANA gateway, this propertymay be used to limit the gateway load by informing the client what response timescan be expected through this parameter. Therefore this property may be set to a veryrough approximation, such as “1000ms”, so that clients do not query the gateway toooften. However there is no guarantee that this property will be regarded by IGUANAgateway clients.

[OPCXMLDA] defines many other Item properties, such as engineering units, maxi-mum/minimum values, its precision and many more. These additional properties are notrequired for an XML-DA compliant OPC server, moreover, they don’t have a counterpart atthe IGUANA gateway. Therefore these properties will not be addressed.

The IGUANA gateway itself provides the following datapoint and node properties whichare not addressed by the OPC specification:

DataType: This is the FAN-specific data type of the data point.

113There may be fieldbus devices which provide cached data. In such cases it is impossible to set an accuratetime.

114The two available ESD Access strings “RO” and “RW” would be translated to “readable” and “read-Writeable”.

75


SetOfEncodings: This property provides information about possible encoding styles of un-derlying fieldbus data. This information is more or less represented by according OPCItems. Nevertheless this property may be provided as an OPC property115.

dp name: The name of the datapoint as defined in the node.

dp num: A property that specifies the number of datapoints that are connected to a node.

nsid str: This property contains an optional self identification string of the node.

opt1 str/opt2 str: These are optional properties which may be used for the node locationand the program ID of a fieldbus node. These properties are only available from anunderlying LonWorks fieldbus and are encoded in the BINHEX format.

The OPC specification allows to define custom properties, therefore these IGUANA spe-cific properties may be simply implemented into the OPC server like all properties specified byOPC. Nevertheless it makes sense to outline that these properties are IGUANA specific. Thiscould be done by prefixing them with the string “IGUANA”, such as “IGUANA nsid str”.

5.3.2 Mapping OPC Services to the IGUANA Gateway

[OPCXMLDA] defines several services that may be used to access underlying fieldbus dataand retrieve status information. These services have to be mapped to appropriate ESDcommands. This mapping will most often not be possible in a 1:1 translation as various OPCservices will need multiple ESD commands. Other OPC concepts, such as subscriptions donot have suitable counterparts in the IGUANA gateway and have to be emulated in someway. However, the following OPC services may be directly mapped directly to ESD:

OPC Read: This OPC service may directly be mapped to the ESD “READ” command.[OPCXMLDA] allows reading of multiple items at once. This can be implementedby subsequently requesting the according datapoint values through the ESD. Dataconversion has to be implemented by the OPC Server as denoted above.

OPC Write: Similar to the Read Service, an OPC “Write” can be mapped to the ESD“WRITE” command. As above, writing of multiple OPC items will be implementedby issuing multiple ESD “WRITE” commands.

OPC GetProperties: This OPC service may be mapped to the ESD command “DPINFO”,which will retrieve all available properties of a datapoint. In case the OPC serverrequests the properties of a fieldbus node, the command “NODEINFO” will be issued.

OPC Status Service

This service is intended for OPC Server status information. This service provides vendorspecific information about the server, the current time on the gateway116 and its currentstatus, such as “running” or “failed”. No ESD commands are necessary for this service.

115The available encodings on the gateway may be extended without implementing these encoding styles inthe OPC server. In this case OPC Items that represent these new encoding styles will not be available. Hencethis information may be conveyed by the “SetOfEncodings” property.

116This information is vital for interpreting timestamps that are returned by the OPC Read service.

76


OPC Browse Service

Browsing elements117 of an OPC XML-DA compliant server is implemented in a hierarchicalfashion. The Browse Service, as defined in [OPCXMLDA], specifies a starting element, fromwhich browsing starts. The OPC Servers then lists items of the same hierarchy level118 andmay implement the following features for limiting browse results and returning extendedinformation about OPC elements:

Return Properties: The client may request item properties including their values whichhave then to be returned by the server.

IsItem/HasChildren: The server has to outline if the listed element is an OPC item oronly a logical branch. Moreover, the server has to denote if there are elements in thenext lower hierarchy level, in other words if the current element is a parent of otherelements.

Filtering: The client may specify filter expressions which can be used to exclude elementsthe client is not interested in.

Limiting Browse Results: A client may also specify the maximum elements the serverreturns in a browsing response119.

Browsing the hierarchical tree of the IGUANA gateway cannot be mapped directly to onesingle ESD command as every level represents a very different dataset and is implemented ina different way. For instance, browsing on the first level will list the “FANTypes” which hasto be implemented by querying the IGUANA gateway configuration, while browsing on thethird level will list the datapoints of a node which has to be implemented entirely different.

The hierarchical tree of the IGUANA gateway has four levels plus an additional levelfor the encoding style. Figure 56 depicts how browsing in different hierarchy levels may beimplemented in the IGUANA Gateway.

Hierarchy level Browsing Implementation on the IGUANA Gateway

FANType This information has to be acquired from the IGUANA gateway

configuration. Information about possible children has also to be

retrieved from the configuration.

FANId This information has to be acquired from the IGUANA gateway

configuration. Checking for possible children (connected FAN Nodes)

can be done with the ESD NODELIST command.

FANNodeAddress Browsing FANNodes may be implemented by ESD NODELIST

commands. The NODEINFO command may be used for retrieving

properties and checking if the node has children.

Dpid This information may be retrieved by issuing the ESD ENODEINFO

command, which also returns all available datapoint encodings.

Encoding Available encodings of a datapoint are retrieved through a DPINFO

command. Properties will also be returned by DPINFO. Values will have

to be retrieved by READ commands.

Figure 56: Possible implementation of an OPC XML-DA compliant browse service on theIGUANA Gateway

Figure 56 shows that a simple OPC browse request may trigger various ESD services whichmay lead to high fieldbus loads and long response times. For instance, browsing one FAN with

117Elements cannot only be OPC items but may also be branches which are logical elements of the hierarchytree and do not contain fieldbus data by themselves.

118The service does not descend in the hierarchy and does therefore not recursively list items in lower levels.119OPC Servers may implement so-called “Continuation Points” that may be used to browse elements that

exceed the maximum elements.

77


100 fieldbus nodes will lead to one ESD NODELIST and 100 ESD NODEINFO commandswhich produce a high load on the fieldbus. The ESD daemon of the IGUANA gatewayimplements caching of certain data, which may greatly reduce the load on the fieldbus120.However, it may be appropriate to implement OPC XML-DA specific caching strategies inthe OPC server itself to further reduce fieldbus load and improve the responsiveness of theOPC Server.

Extended browse features, such as filtering or limiting browse results, are not supportedby ESD and have to be implemented by the OPC server.

OPC Subscription Service

As denoted in chapter 3.1, OPC XML-DA specifies a so-called “Subscription Service” forobtaining changes of fieldbus data, which is basically a mixture of asynchronous notificationsand polling. The IGUANA Gateway does not offer appropriate services that may be mappedan XML-DA compliant subscription service121, therefore it has to be implemented by theOPC server itself.

An OPC Subscription service on the IGUANA gateway may be implemented by period-ically polling certain datapoints with ESD READ commands. Value changes may then besent back to the subscribed client. One viable implementation is shown in figure 57.

OPC Server

Polling Thread 1

Polling Thread 2

Polling Thread 3

Extended Service

Daemon (ESD)

Figure 57: Implementing OPC Subscriptions by creating multiple polling threads

In case of an OPC subscribe request, the OPC server creates a new thread that periodicallyrequests datapoint values from the ESD. If a datapoint value changes, the thread notifies theOPC Server which may forward the changed data to the subscribed client.

An OPC subscription service on the IGUANA gateway raises various problems that haveto be addressed in detail. One major problem may be the so-called “Sampling Rate”, by whichthe client denotes how often a datapoint value should be checked for possible changes. On theone hand the sampling rate needs to be high enough so that changes of datapoint values areregistered, but on the other hand it must not be too high so that the fieldbus is not floodedwith successive datapoint reads. This problem may be solved by introducing a maximumsampling rate that must not be exceeded. Moreover, a maximum number of subscriptionsmay have to be defined, as a high number of polling threads could also flood the fieldbus.Moreover, certain aspects of OPC Subscriptions, such as maintaining subscriptions, bufferingand “Deadband”, have to be implemented in the server, which may raise implementation-specific issues.

120It should be denoted that cache updates are not done automatically but have to be issued by specific ESDcommands, called “REFRESHNODELIST” and “UPDATENODELIST”.

121The IGUANA Gateway offers asynchronous notifications which look like a promising counterpart to theOPC Subscription service. However, the IGUANA notification system has several limitations: Obtainingchanges of fieldbus data is done by polling datapoints instead of asynchronous notifications from the fieldbusitself. Therefore polling may be directly implemented by simple ESD-read commands by the OPC server itself.Moreover, certain aspects of the OPC Subscription Service, such as deadband or buffering, are not supportedby the IGUANA gateway.

78


5.4 Web Service Compliant Fieldbus Applications on the IGUANA Gate-way

As stated in chapter 4.2, so-called “gateway applications” may be prove to be a good solutionto certain tasks. Gateway applications may then reside in the IGUANA gateway, commu-nicate with Internet clients with the SOAP protocol and access the fieldbus through theExtended Service Daemon (ESD), as depicted in figure 58.


IGUANA Gateway

Gateway Application Client

Gateway

Application 1

Gateway

Application 2

Gateway

Application 3

SO

AP

Pro

tocol

Figure 58: Gateway Applications on the IGUANA Gateway

To give an example, a public interface to a weather station should be created which shouldprovide the actual temperature, humidity and wind-speed along with some historic data.Several appropriate sensors are present on different fieldbus networks, which are connectedto the IGUANA gateway.

The software developer would then write an application that collects data from certainfieldbus datapoints with simple ESD READ commands and stores this data in an internalbuffer for a limited time. The application would furthermore implement several functions,such as “GetTemperature” and “GetHumidity” which return appropriate data from the bufferto clients who called these functions. Moreover, the application may implement securityfeatures, such as limiting access to certain networks or authenticate users before permittingaccess to the service.

As the ESD is also accessible via TCP/IP from outside the IGUANA gateway, the de-veloper may create and thoroughly test the application prior to installing the application onthe gateway. Web Service frameworks may be used to support the programmer in creatingthe gateway application, so that complicated issues, such as the SOAP protocol are managedand created by the framework.

When the application is finished and well tested, the developer would automatically createa WSDL document that can then be used by clients to access the new service. Then he woulddeploy the application on the IGUANA gateway along with the WSDL document. Clientsmay then utilize the WSDL code to query the service and thus retrieve data from the weatherstation.

The above example outlines the following main elements of gateway applications on theIGUANA gateway:

Development of gateway applications: The development process primarily focuses onaccessing the fieldbus with the ESD protocol and creating functions which are exposedas SOAP Web Services. Although no specific tools are needed for developing gate-

79


way applications, Web Service frameworks may be used122 which ease the developmentprocess by hiding the SOAP protocol from the programmer.

An important issue is testing and debugging the application. Access to the IGUANAgateway with the ESD protocol is also possible by TCP/IP, therefore testing and de-bugging may be done outside of the gateway. This is a great advantage as the gatewayis not interrupted in its operation by malfunctioning gateway applications, moreover,common tools, such as debuggers may be used by the software developer.

Most Web Service frameworks support an automatic creation of WSDL documents,which further eases the development.

Web Service accessibility and deployment: To accomplish accessibility of a Web Ser-vice, a server has to be set up on the IGUANA gateway. This server has to implementthe HTTP protocol and has to call the requested Web Service. This server may beimplemented in various ways such as with a common HTTP server, which calls servicesin a CGI-style123. Other ways would be a Web Service that implements a HTTP serverby itself or framework specific servers.

Deployment of gateway applications may be either done in a simple way such as withFTP124, or by more sophisticated techniques, such as by implementing a HTTP interfaceor a dedicated gateway application which implements software deployment. Along withthe gateway application itself, the WSDL document may be directly deployed on theIGUANA gateway, although it may also be provided on a different location.

Development of clients for gateway applications: From the perspective of the client,gateway applications on the IGUANA gateway look like any other Web Service on theInternet. Gateway applications may be designed in a way, so that fieldbus technologyis entirely hidden, such as in the above example. In this case, client developers needno fieldbus knowledge at all and may even not be aware that fieldbus technology isinvolved.

Security of IGUANA Gateway Applications: The ESD does not implement any secu-rity features, such as fine-grained access rights125, authentication or encryption. In-stead, the IGUANA gateway relies on the security of the fieldbus itself. Internet/field-bus gateway should however provide more security features, such as limiting access todifferent fieldbus data for certain clients.

Gateway applications on the IGUANA gateway may address a number of security issues,such as fine-grained authorization schemes, limiting access from certain networks andeven encryption. [VEN05] states that: “Application specific interfaces also allow amore flexible authorization scheme.” Moreover, security features may be tailored tothe needs of the applications – for instance, one application may be publicly available,while another has need for strong authentication and encryption.

Type checking: Gateway applications have predefined input and output parameters withassociated data types. Therefore type checking may be done at compile time of the

122The operating system of the IGUANA gateway is Linux, therefore the software developer is limited toWeb Service frameworks that are available for this environment.

123The Common Gateway Interface (CGI) is a popular technique for calling programs from a HTTP server.124The File Transfer Protocol (FTP) is a simple protocol for transferring data between Internet devices125The ESD implements a property called “Access”, which denotes if a datapoint is read-writeable. However,

these access rights are adopted from the fieldbus itself and cannot be configured in the ESD.

80


client.

On the other hand, abstract fieldbus interfaces, such as OPC XML-DA do not providestatic data typing and deliver dynamically typed fieldbus data. Therefore type checkinghas to be done during run time. This fact is also outlined by [VEN05].

Limited Hardware Resources

The IGUANA gateway is implemented on a device with limited hardware resources. There-fore gateway applications have to be designed and programmed in a way so that hardwarelimitations are not exceeded. Hence programming languages such as Java, which need avirtual machine may be unsuitable. Moreover, the HTTP server in front of the Web Servicewill have to be designed in a way so that it has a small footprint. Certain security features,such as encryption may also be impossible due to hardware limitations.

Nevertheless a thorough design and the usage of the right tools should make gatewayapplications on the IGUANA gateway a viable solution for many tasks.

81

6 Implementation of an OPC XML-DA Compliant SOAPWeb Service on the IGUANA Gateway

An OPC XML-DA compliant server is to be developed for the IGUANA gateway. One optionwould be to use an existing framework for OPC XML-DA, however only few frameworks areavailable for the Linux operating system126, moreover, none of them is available withoutcosts. These frameworks already implement the SOAP communication, hence there is littleroom for the examination of SOAP specific issues, which is an important aspect of this thesis.

The necessary steps in designing the server are the following:

Choosing a programming language/framework: SOAP frameworks and server specificlibraries are available in various programming languages.

Server design: The OPC XML-DA server should be able to handle concurrent requests andsupport periodic operations127.

Communication with the ESD: The ESD protocol has to be implemented to accomplishthe communication with the ESD daemon.

6.1 Choosing an Appropriate SOAP Framework

As denoted above, various SOAP frameworks for various programming languages are avail-able. Moreover, a framework/library should be used that eases the development of a serverthat can handle concurrent requests. It is obvious that the SOAP framework and the serverlibrary have to be available for the same programming language, hence the decision is morefocused on programming languages than on SOAP frameworks.

The programming language should provide the following key features:

Easy and rapid development: The programming language and their libraries/frameworksshould enable a rapid development.

SOAP framework: [OPCXMLDA] is heavily based on SOAP, therefore an appropriateSOAP framework should be available.

Server framework: The OPC XML-DA server should be able to handle concurrent re-quests, therefore the programming language should provide libraries that enable andease the implementation of this issue.

TCP/IP and HTTP libraries: The language should also provide libraries that implementthese common Internet protocols to establish communication with the ESD server andto transport SOAP messages via HTTP.

Compatibility: The XML-DA server should be implemented on the Linux operating system,hence the language/framework has to be available for Linux. Moreover, the memoryfootprint and CPU load should be low due to limitations of the IGUANA gatewayhardware.

126Examples would be the “LiXMO Suite” from Technosoftware AG or the “Toolbox C++” from SoftingAG.

127This is needed for OPC subscriptions, where fieldbus data is periodically polled.

82

6 IMPLEMENTATION OF AN OPC XML-DA COMPLIANT SOAPWEB SERVICE ON THE IGUANA GATEWAY

Free availability: The language/framework should be available at no cost. Open sourcesolution should be favored.

Common programming languages would be C/C++, Java, .Net, Python and Perl. Eachof them has several advantages/disadvantages as regards to the requirements above:

C/C++: C/C++ is most often used for implementing OPC compliant servers, as the com-piled code has low memory requirements and is very efficient. A very mature SOAPframework called “gSOAP” is freely available, moreover, there are various libraries formulti-threading, therefore development of a server that handles concurrent requests willbe possible. C/C++ and all libraries are all available for Linux.

The disadvantage of C/C++ is the complicated and error-prone code, which leads tolong development times, hence much effort would have to be put into programmingaspects instead of analyzing the efficiency and suitability of SOAP.

Java: Although Java provides mature SOAP frameworks and has a relatively short develop-ment time, Java-based applications tend to have high hardware requirements, especiallya huge memory footprint which may exceed the capabilities of the IGUANA gatewayhardware.

.Net: This framework is basically available for Microsoft-based systems. As OPC-basedsoftware is most often targeted to the Microsoft Windows platform, many newer OPCframeworks are based on .Net. The IGUANA gateway is Linux-based, therefore Mi-crosoft .Net cannot be used128.

Python: Python is a scripting language, is freely available and has a huge collection oflibraries. A SOAP framework for Python called “Zolera Soap Infrastructure” (ZSI) isalso available. For server development, a library called “Twisted” is available whichsupports the easy and rapid development of servers. Twisted offers various protocols,such as HTTP and raw TCP/IP and solves concurrency issues with an event-drivendesign.

Python code is interpreted and hence has a higher memory footprint than C/C++.Therefore it is uncertain whether a Python-based OPC server would fit on the IGUANAgateway hardware. Another disadvantage is that Python’s SOAP framework is quitenew and does not seem to be very mature.

Java and .Net do not seem to fit the requirements very well, therefore a decision betweenC/C++ and Python has to be made. In case of a commercial development, C/C++ wouldbe the optimal choice due to its efficient and small code. However, for this thesis, whichfavours research and proof of concept over efficiency, Python may be the better option. Itwill also be interesting to examine whether and how Python will fit on embedded hardware,such as the IGUANA gateway.

At first, the specification [OPCXMLDA] was examined once again, and one simple requestwas tested with the Python SOAP framework (ZSI). After some considerations, it was obviousthat a modular design, as depicted in figure 59 would be most appropriate.

128An alternative implementation of .Net is “Mono”, which runs on a variety of platforms, including Linux.However, it is uncertain whether it would provide the necessary functionality, and its hardware requirementsare also relatively high.

83


SOAP message parsing

OPC server functionality

ESD protocol handling

Figure 59: Modular design of ESD OPC Server

6.2 Parsing OPC XML-DA Compliant SOAP Messages

The Zolera SOAP Infrastructure (ZSI) framework handles the parsing and serializing of SOAPmessages. Before a message can be parsed, a data structure, called “Typecode” has to be setup. A Typecode is a Python object and represents a specific type of SOAP message. SOAPmessages can be parsed into suitable typecodes, which can then be read/written by customPython code. On the other hand, typecodes can be serialized, which allows the creation ofappropriate SOAP messages. This concept is depicted in figure 60.

SOAP Message ZSI Typecode Custom Python Code

Figure 60: Parsing/Serializing SOAP Messages via ZSI Typecodes

These typecodes can either be created by hand or - in case a WSDL document is available- with a tool, called “wsdl2py”. This tool generates two python files, which can be importedinto custom code and used to access these typecodes. Moreover, the structure of thesegenerated typecodes can then be examined through python, using the “help()” command.The idea behind this concept is that a user never has to look at the complicated WSDL codeitself, instead he can handle everything through the Python language. Listing 33 depictsa creation of a simple OPC typecode129 and Listing 34 shows the output of the “help()”command, while listing 35 shows the regarding snippet of the WSDL document.

import ZSI2 from OpcXmlDaSrv services import ∗

help ( GetStatusSoapIn ) # L i s t s methods / a t t r i b u t e s o f t h i s typecode4 tc = GetStatusSoapIn ( ) # Create typecode ob je c t

tc . s e t a t t r i bu t e C l i e n t I t emHand l e ( ’ SampleHandle123 ’ )

Listing 33: Creating a Simple OPC Typecode

1 c l a s s GetStatus Holder ( b u i l t i n . ob j e c t )| Methods de f ined here :

3 || i n i t ( s e l f )

5 | ge t a t t r ibute C l i en tReque s tHand l e ( s e l f )| g e t a t t r i bu t e Lo ca l e ID ( s e l f )

7 | s e t a t t r i bu t e C l i e n tReque s tHand l e ( s e l f , va lue )| s e t a t t r i bu t e Lo ca l e ID ( s e l f , va lue )

Listing 34: Available Attributes/Method of the Typecode

129This simple OPC SOAP message is used to retrieve the status of an OPC XML-DA compliant server

84


<s : e l ement name=”GetStatus ”>2 <s:complexType>

<s : a t t r i b u t e name=”LocaleID” type=” s : s t r i n g ” />4 <s : a t t r i b u t e name=”ClientRequestHandle ” type=” s : s t r i n g ” />

</ s:complexType>6 </ s : e l ement>

Listing 35: Associated WSDL Code Snippet

Line 5 in Listing 33 depicts how the generated method set attribute ClientRequestHandlecan be used to fill the associated XML attribute in the SOAP message, as defined in Line 4in listing 35.

Typecodes may embed other typecodes and hence represent complicated WSDL docu-ments. One huge advantage of this concept is that SOAP-compliant data types are au-tomatically converted to Python-specific data types. For instance, a SOAP “integer” willautomatically be converted to a Python integer.

The problem with this approach is that complicated WSDL documents generate com-plicated typecodes, although it may be possible to provide the underlying data in a muchsimpler form, for instance by creating custom objects, or using specific Python data types,such as dictionaries130. [OPCXMLDA] contains various complicated WSDL structures, whichare complex to access. As these structures have to be read/written throughout the wholeimplementation, a simpler structure would be more appropriate.

After a thorough study of the OPC WSDL document, it was discovered that all re-quest/response documents have one or more OPC Items which transport attributes, such asthe Item value, the quality/timestamp and more. OPC Items may contain OPC properties,which contain the name, description and some other attributes of the property. Every re-quest/response is accompanied by general attributes, such as the time when the request wasissued, or a deadline until the response must be finished.

Therefore custom and built-in Python objects could be used as follows:

General request/response attributes: These attributes can be stored in a Python dic-tionary.

OPC Items: A specific object, called “ItemContainer” was modeled which is able to containevery type of OPC Item found in the OPC XML-DA specification.

OPC Properties: Another specific object, called “OPCProperty” was created that can beused to store OPC Item Property data.

Three basic classes were created that are used for storing SOAP message data into thissimpler data structure, as depicted in figure 61131.

These classes have specific “fill” and “read” methods, which may be used to fill/readsuitable ZSI typecodes. These data structures are automatically created by the server, hencethe programmer may easily access OPC data of request/response messages and never has todeal with typecodes.

130A Python dictionary is basically a hash table: Given keys are hashed and stored with associated data ina table.

131For simplicity reasons, not all methods/attributes have been depicted in this figure

85


+fill_ReadRequestItem()

+read_ReadRequestItem()

+getProperty()

+listProperties()

ItemContainer

-ItemName

-ItemPath

-Value

-Timestamp-Name

-Value

OPCProperty

1 *

+fill_Read()

+read_Read()

+fill_ReadResponse()

+read_ReadResponse()

OPCOperation

1

*

Figure 61: Class diagram of the OPC Server’s Data Structure

Problems and Workarounds During the Implementation

After modeling these data structures, code was created. In this process, a WSDL documentwhich was attached to [OPCXMLDA] was used to generate OPC specific typecodes as dis-cussed above. Moreover, the classes, as depicted in figure 61 were coded. However, therewere numerous bugs and missing features in the ZSI, such as:

Attribute handling: XML attributes were handled as strings by ZSI, regardless of the datatype declaration in the WSDL document.

Missing data types: ZSI does not implement all data types, especially the date/time-baseddata types are not fully implemented132 and the fixed-decimal type is entirely missing.

Missing Documentation: The Documentation provided by ZSI is quite outdated, more-over, some newer topics are entirely missing. This made the usage of ZSI quite compli-cated, as some information had to be gathered from the source code itself133.

Various bugs: There were bugs concerning the handling of the “QName” and “anyType”data types, problems in the script that generates the typecodes and some other minorshortcomings.

Fortunately, the ZSI developers were very helpful in solving most of these problems, andit was possible to fix some of these bugs in the source code of the framework or to findworkarounds for some of the shortcomings.

Nevertheless the code tended to be very unstable. For this reason, unit tests for allmethods were set up that verify the serialization and parsing of all available OPC SOAPmessages as follows:

1. Fill Internal Data Structure: The internal Python objects representing the SOAPmessage are completely filled with test data. This way, all available elements/attributesshould be present in the serialized SOAP message.

2. Serialize SOAP Message: The appropriate “fill” method of the data object is thenused for creating the associated typecode, which is used for serializing the data into aSOAP Message.

132There is no support for “duration” and fractions of seconds (milliseconds) and time zones are ignored bythe ZSI as the date is stored in a Python data type without support for this information.

133Unfortunately it is not possible to retrieve this needed information directly from the generated typecodes,as they are based on a concept called “Metaclasses”, a technique were methods and attributes of an objectare not defined in the class but in a Metaclass and are dynamically created at object creation time and arethus not found along with the generated typecodes.

86


3. Check for Attributes/Elements: The XML code in the SOAP message is examinedif the specified data is actually present in XML attributes/elements.

4. Parse SOAP Message into Internal Data Structure: The previously serialized mes-sage is parsed back into a suitable typecode and the “read” method of the associateddata object is then used to fill the Python data structure.

5. Compare Original and Parsed Data: The last step is to compare the original datastructure with the parsed data from the previous step.

These unit tests can then automatically be run to guarantee the proper functionality ofthese code segments. This way, code changes or updates of the ZSI framework that lead tofaulty behavior can easily be tracked and fixed. More information about unit testing can befound in [HUN03]134.

6.3 Implementing OPC Server Functionality

After the successful implementation of the parsing and serializing of the SOAP message, theserver functionality had to be implemented. Requests made to a SOAP server have to bedispatched to the appropriate message handler in one of the following styles:

Top-level SOAP Element: Every SOAP message has a top-level element which may beused for dispatching.

URL-based: The URL that addresses the SOAP Web Service may directly specify themessage handler135.

SOAP-Action: The SOAP specification, as shown in [WAL02], defines a special HTTPheader, called “SOAP-Action”, which can be used for dispatching purposes.

ZSI currently only supports dispatching via the top-level element, while OPC XML-DAuses “SOAP-Action”. Therefore dispatching had to be done by hand.

The basic server layout, as shown in figure 62, depicts that most of the OPC operations,such as “Read” and “Write”, can directly be translated to their ESD counterparts. However,subscriptions are not supported by ESD, therefore this functionality has to be implementedby the server. The server will have to maintain polling reads and store changed values in acache/buffer, which is depicted in figure 62 as “Subscription Polls”.

Handling Concurrent Requests

The server must furthermore be able to maintain concurrent client connections. This way,one long operation does not lead to the starvation of others. Moreover, OPC requests maycontain multiple requests in one message. For instance, one ReadRequest message may re-quest multiple items at once. Furthermore OPC requests may contain a so-called “Deadline”which specifies how long a single item request may last. Therefore handling messages withmultiple requests by issuing sequential ESD commands are inappropriate, as a long-lastingcommand may lead to the starvation of others.

134This book introduces tests with a Java library called “JUnit”. The Python unit testing library is veryclosely related to JUnit.

135If for instance the URL “http://some.url/myws” is the base address for the Web Service, URLs such as“http://some.url/myws/handler1” and “http://some.url/myws/handler2” could be used.

87


Client 1

Client 2

Client 3

OPC Server

Dis

patc

hin

g

OPC Write()

OPC Read()

SO

AP

Message

Pars

ing

SO

AP

Serializ

er

OPC GetStatus()

OPC Browse()

OPC GetProperties()

OPC Subscribe()

OPC Unsubscribe()

OPC SubPollReq()

ES

D P

roto

col T

ran

sla

tor

Subscription Polls

ES

D S

erv

er

Figure 62: Basic Server Layout

Figure 63 shows two possible solutions to this problem. The left diagram solves the prob-lem by issuing one ESD command per requested item, while the right diagram implements aconnection pool which maintains multiple open connections to the ESD server.

Clie

nt

OPC Server

ES

D S

erv

er

OPC Read

ESD Read 1

ESD Read 2

ESD Read 3

...

ESD Read N

Clie

nt

OPC Server

ES

D S

erv

er

OPC Read

ESD

Connection

Pool

Figure 63: Handling Concurrent ESD Requests

In this implementation, the solution in the left diagram will be chosen. The simple reasonfor this is simplicity, as setting up and maintaining a connection pool may lead to a highlevel of complexity. The disadvantage is that many concurrent client connections may thuslead to a high memory requirement in the OPC server and high loads on the ESD server136.

Basically there are three methods to maintain concurrency in a server:

1. Multiple Processes: Each connection is handled in a separate operating system process.The operating system maintains the concurrency of these processes.

2. Multi threading: Every connection is handled by a separate thread, which is controlledby the multi threading framework.

3. Event-driven Design: This technique uses non-blocking function calls, hence it makesthe program asynchronous. These functions signal their readiness to a scheduler, whichdecides if a function is to be executed.

Each of these concepts has its strength and weaknesses. For this design, an event-drivenconcept seems most appropriate for the following reasons:

Ease of use: Compared to threading, an event-driven program does not have to be thread-safe. Therefore data can easily be shared among functions and there is no need formutexes or similar concepts.

136This problem may be solved by limiting the number of concurrent client connections and ESD requests inthe OPC server. This way, excessive connections would be declined with an error message by the OPC server.

88


Good for Network Programming: In an event-driven system, functions are modeled non-blocking, which means that functions are chained and wait for a specific event. In casean event triggers such a chain, they are executed one after another. Applied to Net-working servers, this concepts fits well, as server functions will often wait for messagesfrom a peer, which will trigger such a chain of functions.

High Level of Control: In event-driven programs, the programmer may carefully selectin which order functions should be executed. Compared to multiple processes, theprogrammer has a higher level of control.

The disadvantage of an event-driven design is that it does not make sense where computing-intensive tasks should be parallelized. Moreover, the design has to be asynchronous from thebeginning. Therefore existing blocking functions cannot be parallelized later. However, thesetwo disadvantages are not important for this design, as computing-intensive functions do notexist and the OPC server will be modeled with the event-driven concept in mind from thebeginning.

ZSI does not support concurrent programming very well. It offers dispatching of SOAPmethods in a CGI-like style, however this is inappropriate for this design as a CGI-programneeds a separate web server. It also provides a simple HTTP server, with very limitedfunctionality. However, all dispatching is based on the top-level SOAP element and cantherefore not be used for OPC XML-DA.

The Twisted Framework

The Twisted framework uses such an event-driven system and uses the so-called “deferred”object for building function chains. It is possible to attach “callbacks” and “errbacks” tosuch deferreds, which will be executed when the deferred is “called back” (“fired”).

A sample program is shown in listing 36, which depicts a simple function that is addedto a deferred and fired five seconds after the program started.

from twi s t ed . i n t e r n e t import r ea c to r , d e f e r2

de f p r i n tHe l l o (dummy) :4 # Function that p r i n t s a s t r i n g and s tops the program

pr in t ’ Hel lo , World ’6 r e a c t o r . stop ( )

8 d = de f e r . De fer red ( ) # Create a new de f e r r edd . addCallback ( p r i n tHe l l o ) # Add a ca l l b a ck to the de f e r r ed

10 r e a c t o r . c a l l L a t e r (5 , d . ca l l ba ck , None ) # Cal lback the de f e r r ed a f t e r 5 sr e a c t o r . run ( ) # Sta r t the event loop handler

Listing 36: Simple Twisted Application Using Deferreds

Deferreds have various additional capabilities such as the following:

Error Handling: Apart from adding callback functions to a deferred, so-called “errbacks”can be added. These errbacks will be executed in case a callback raised an error. Theerrback may then either catch this error, in which case the next callback is executed orre-raise an error, which leads to the execution of the following errback.

89


Returning Deferreds: The return values of a callback function will be used as functionarguments of the next function in the callback chain. In case a callback function needsto wait for another event, it is possible to create another deferred, add some callbacksor errbacks and return it instead of the return values. The last function in the callbackchain of this “inner” deferred will then return the arguments for the callback in the“outer” chain.

Waiting for Multiple Deferreds: Twisted provides functions that enable waiting for mul-tiple deferreds. For instance, this feature can be used if a function has to wait formultiple requests, such as depicted in figure 63.

Apart from solving concurrency issues, Twisted implements libraries for various Internetprotocols, such as TCP, HTTP, SMTP, Secure Shell (SSH), XML-RPC and many more. Theselibraries are of much use for the OPC Server design as HTTP will be used for transportingSOAP messages and ESD messages is based on a simple line-based TCP protocol. Moreinformation about the Twisted framework can be found in [FET06].

Unit Tests for the OPC Server

While designing certain server functionality and implementing some simple OPC server func-tions, it was found out that the resulting code had to be thoroughly tested for correctnessand minor changes could lead to erroneous behavior. For this reason, unit testing was es-tablished. However, testing a server supporting concurrent requests is far more complicatedthan a single, synchronous function. For testing concurrent requests, the unit test itself mustimplement concurrency. Fortunately, Twisted provides a unit test library that is tailored tothese needs.

To test an OPC server, a suitable client is needed, which led to the development ofTwisted-based OPC client functions. These functions were then used to test most OPCoperations, such as Read and Write and also complicated issues, such as the subscriptionarchitecture.

Subscription Architecture

As denoted above, ESD does not provide equivalent functionality to OPC subscriptions.Therefore the OPC server has to implement this subscription architecture by itself. One wayto do this is to periodically poll the ESD for a value of a fieldbus datapoint via an ESDREAD command. However, OPC subscriptions are quite complicated issues and provide thefollowing features:

Deadband: The OPC client may notify that it is only interested in value changes exceedinga predefined limit. This is called “deadband” and is specified in the percentage of thecurrent value.

Caching/Buffering: If a value change occurs that should be recorded by the OPC server,it has to cache this value. Moreover, the client may request buffering, so that multiplevalue changes are stored until they are read by the client.

Multiple Subscriptions of the Same Item: Multiple clients may subscribe to one item.This may lead to situations, where multiple polls on one fieldbus value are periodicallyissued while one read would suffice, which would greatly reduce the fieldbus load. On

90


the other hand, it is not possible to easily replace one fieldbus read by another as theclient may specify differing sampling rates137 for each subscribed item.

Maximum Sampling Rate: Sometimes it is not easy to predict how fast a datapoint valuecan be sampled. Some ESD READ commands may reply after a fraction of a second,others take 10 seconds or more. Moreover, the response time of these fieldbus requestsmay change, for instance, if there is a high network load, or a sensor needs more timefor sampling data. Therefore situations may occur where the sampling rate is fasterthan the response time of an ESD READ. In this case, multiple READs would buildup to an extent that exceeds capabilities of the fieldbus.

Manual/Automatic Termination of a Subscription: Subscriptions can either be man-ually canceled or expire if the client does not poll the OPC server within a specified time(the “ping rate”). When the subscription is canceled, every related periodic samplingmust be stopped.

WaitTime/HoldTime: The OPC client has to periodically retrieve changed values via aspecial operation, called “Subscription Polled Request” (SPR). The client may spec-ify a “hold time” and a “wait time” which specify when the server responds. Theseparameters complicate the server implementation to some degree138.

Due to these difficulties a suitable architecture had to be designed and implemented.When a client subscribes to one or more OPC items, a subscription object is created, as

depicted in figure 64.

Subscribe()

Read Items

addCallback

addSubscription()

addSubscription()

Return

Create Subscription Object

For Items in SubItems

with no errors

Cache Item

Create function

SampleItem()

Create function

HandleSampledItem()

Create/Start LoopingCall of

SampleItem()

Store LoopingCall in

Subscription Object

Start a delayed call which cancels

the subscription after „PingRate“

Store the subscription in the

Server object

Figure 64: Creating a Subscription Object

The function “Subscribe” first reads all requested items in a deferred style and adds acallback called “addSubscription” to prevent blocking of the server due to the read command.The callback function creates a subscription object, which is able to store all attributes andmethods associated with this subscription. Then for every item the previously read value iscached and the two functions “SampleItem” and “HandleSampledItem” are created139, where

137The OPC client may request a sampling rate, which defines how fast the server should poll the fieldbusfor value changes. If the server cannot sample at the requested rate, it may revise the rate and notify theclient about this change.

138For instance, the server should return immediately and ignore the hold time in case all requested itemsare erroneous, hence the items have to be checked immediately. On the other hand, value changes that occurwithin the hold time should be returned by the server. Therefore the items have to be checked when the holdtime has expired.

139Python offers an elegant way of creating functions during runtime with so-called “closures”, which arebasically functions within functions. More information about this technique can be found in [MAR03].

91


the second function will handle the output of the first. Next a so-called “LoopingCall” isstarted and stored in the subscription object, which periodically calls the sampling functions.The last step is to set up a delayed call that cancels this subscription and all related samplingfunctions. This way, subscriptions will automatically be canceled in case the OPC client doesnot query the server within the “ping rate”.

Figure 65 depicts how caching and buffering of OPC Items are implemented in the currentdesign.

Subscription

Cache

Item 1

Item 2

...

Buffering?

Item N

SampleItem 1

Old Item

Item Buffer

(FIFO)

01: Item 4

02: Item 3

03: Item 7

04: Item 1

05: Item 1

06: Item 4

...

Old Item

Drop old

Item Value

Subscription Polled Refresh

SampleItem 2

...

SampleItem N

Subscription Specific

Figure 65: Item Caching/Buffering Scheme

The function “SampleItem” first reads the fieldbus value in a deferred style. The resultis handled by the callback function “HandleSampledItem”, which stores the new value in the“subscription cache” in case it has changed140. If buffering is enabled for this subscribed item,the old value will be stored in the “item buffer”. This FIFO-style buffer is not subscriptionspecific and can store a predefined amount of items. If the buffer is full, the oldest entry willbe deleted. In case a buffered item is lost, this event will be recorded by the subscriptionobject so that it may notify OPC clients which retrieve buffered data from the server.

Figure 66 depicts an OPC “Subscription Polled Request” (SPR) which queries the OPCserver for new values. An OPC SPR may query multiple subscriptions in one request.

After checking whether the specified subscriptions are valid, the polling of the subscriptionis blocked to guarantee that no other client may poll data from this subscription141. The nextstep is to cancel all automatic unsubscriptions, so that the subscription object is not deletedwhile a poll is taking place. Then the function creates a deferred and adds the callback“PollWait” in case the client specified a wait time and the callback function “PollItems”.Then the server waits for the specified hold time and calls the next function in the callbackchain.

If a client specifies a wait time, the server waits for the given time and returns immedi-ately in case a value has changed or after the wait time has exceeded. Therefore the PollWaitfunction first creates a deferred that is stored in the subscription object and sets up a Wait-Cancel function. This deferred will either be fired by the function “HandleSampledItem”,

140“Changed” means in this context that the new value exceeds the previously defined deadband.141Subscriptions are associated with one client only. However the OPC XML-DA specification is quite loose

on this topic and does not explicitely prohibit multiple queries to one subscription but does not define how theserver should react in such a situation: For instance, the server could return changed values to all concurrentclients but could also return it to only one. Due to these uncertainties, this server blocks all other requests toa subscription object in case a poll is taking place.

92


SubscriptionPolledRequest()

Check for valid Subscriptions

Fire PollDeferred

after HoldTime

PollWait()

addCallback

PollWait()

Cancel all pending automatic

Unsubscriptions

PollItems()

Recreate automatic

Unsubscriptions

If there are no other pending

polls for this Subscription

WaitTime &

not ReturnAllItems

addCallback

PollItems()

Create WaitDeferred

Create a WaitCancel function that

fires WaitDeferred after WaitTime

(When no Value changes)Read all changed Values from

Subscription Cache and

from Buffer

Denote if a Buffer overflow

has occurred

Create a Cleanup function that

cancels all WaitCancel functions

and removes all WaitDeferreds

Delete all possible Wait deferreds

as the poll has already be called

Denote the server that

a poll is taking place

Create PollDeferred

addCallback

PollItems()

Add the WaitDeferred together

with Cleanup Function to

Subscription so that it may be

fired by a Sampling Read,

meaning a Value has changednoyes

Figure 66: Polling a Subscribed Item

which periodically checks for value changes and fires all deferreds in a subscription object, orby the WaitCancel function that is executed when the wait time has elapsed.

The function “PollItems” reads all changed values from the subscription cache and fromthe item buffer, denotes whether a buffer overflow has occurred and returns this data. More-over, it establishes the automatic unsubscription function, so that the subscription is canceledin case the ping rate is exceeded.

Problems During the Implementation

Getting used to deferred-style programming was not easy at first due to thinking in a multi-threaded style instead of an event-driven concept. On the other hand, many problems whichseemed very complicated at first, could be solved quite easily with twisted.

There were also some misunderstandings in the namespace concept of python, especiallywith closure functions, which led to various bugs in the server. Moreover, unit testing thesubscription architecture was quite complicated: After issuing multiple subscription requests,multiple SPRs had to be sent to the server in a non-blocking style. After that, certain OPCitems were written which should be denoted by the concurrent SPRs.

6.4 Handling of the IGUANA Protocol

The concept of the OPC server on the IGUANA gateway is similar to a proxy: Requestsissued by OPC compliant clients are translated into ESD commands, while ESD responsesare translated into OPC SOAP messages. Functionality which is not directly supported byESD – such as subscriptions – has to be managed by the OPC server itself. This internalfunctionality will also retrieve data via ESD commands142.

Therefore the last step in the implementation was to translate OPC operations into ESDcommands. At first, the line-based protocol itself had to be implemented. The basic archi-

142For instance, the subscription architecture will periodically retrieve fieldbus data with the ESD READcommand.

93


tecture for implementing protocols in the Twisted framework is to separate the protocol fromthe server logic as depicted in figure 67.

ESD Factory

ESD Protocol

ESD Functionality

Figure 67: Implementation of the ESD Protocol in the Twisted Framework

When a client connects to the server, the ESD factory object creates an ESD protocolobject which then handles the client/server communication. This communication object thencalls functions from another object which implements the required functionality. This basicconcept applies to an ESD client but also to an ESD server.

The ESD protocol was quite easy to implement. ESD requests are always sent as a singleline and responses can either be single-line and in some cases also multi-line, therefore a verysimple state machine had to be implemented.

The addressing scheme in OPC XML-DA and ESD has a different format, therefore asimple function was created that interpretes the ESD address syntax and formats it in anOPC XML-DA compliant style, as already shown in chapter 5.1.

For testing purposes, a simple ESD server was programmed which simulates the ESDfunctionality of an IGUANA gateway. Fieldbus nodes and datapoints can be configured in asimple XML configuration file which is read at startup. This server also simulates delays143

and implements all necessary ESD functionality, such as READ, WRITE, (E)NODEINFO,DPINFO and NODELIST.

Implementing ESD Functionality in the ESD Server:

The actual implementation of the ESD functionality in the OPC XML-DA server is merelya translation from OPC operations into ESD commands144. The following operations had tobe implemented:

OPC Read/Write: These operations could directly be mapped to their ESD counterparts.The encoding, which is part of the item name in OPC, had to be removed from theOPC address and was given as a parameter to the ESD command145.

OPC Browse: Browsing the IGUANA gateway is different by design from browsing an OPCXML-DA compliant server. OPC provides one browse operation which can be appliedto all items in the address space. On the other hand, ESD has commands which provideinformation about specific entities, such as “NODELIST” for listing all available nodes,or “ENODEINFO” for listing all datapoints associated to a node.

Therefore the OPC browse data had to be retrieved from the IGUANA gateway by asuitable ESD command, as depicted in figure 68.

Some ESD requests return data which has to be filtered. For instance, an OPC browseoperation of the item “/LON/GATE1” results in an ESD “NODELIST” command,

143Delays for ESD READ/WRITE commands can also be specified in the XML configuration file.144As denoted above, one XML-DA request message may contain multiple items, which then results in

multiple concurrent ESD commands.145For instance, the address “/LON/GATE1/01:02/01/STRING” is translated to the ESD command “READ

LON.GATE1!01@01:02 STRING”.

94


NODELIST/FANTYPE

/FANTYPE/FANID

/FANTYPE/FANID/NODEADDRESS

/FANTYPE/FANID/NODEADDRESS/DPADDRESS

ENODEINFO

Browse Path ESD Command

DPINFO

/

Figure 68: Required ESD Commands in an OPC Browse Request

which lists all available nodes, regardless of whether they are associated with the fantype“LON” or not. Therefore unwanted data is filtered by the server.

OPC browse operations also offer retrieval of properties associated with the retrieveditems. This functionality was implemented by calling the OPC “GetProperty” function.

OPC GetProperties: Similar to browsing, OPC has one operation to retrieve propertiesfrom an item, while the IGUANA gateway provides two commands, namely “NODE-INFO” and “DPINFO” to retrieve properties of a node/datapoint. Therefore the re-quested data had to be retrieved with different ESD commands, depending on theprovided item address.

95

7 Analysis of the SOAP Protocol in Internet/Fieldbus Gate-ways

After the implementation had been finished and all unit tests succeeded, the performance,compatibility and efficiency of the design was tested.

7.1 Compatibility and Interoperability of an OPC server on the IGUANAgateway

Compatibility and interoperability between different OPC XML-DA implementations basi-cally depends on the following two issues:

1. Compatibility of SOAP Frameworks: Information in OPC XML-DA is exchangedvia SOAP messages, which are constructed with a SOAP framework. To maintaininteroperability, these frameworks must be compatible. The OPC specification addi-tionally provides a WSDL document which specifies the format of SOAP messages.The SOAP framework may therefore improve compatibility by validating incoming andoutgoing SOAP messages utilizing the constraints in the WSDL documents.

2. Accuracy of the OPC XML-DA specification: To ensure interoperability, a speci-fication must be very accurate and precise. If it is loose or unclear in some parts, itmay lead to custom interpretations, leading to incompatible implementations of thestandard.

Testing for compatibility and interoperability between different OPC implementationscan basically be done in two ways:

1. Interoperability tests: In this practical approach, different OPC servers and clients areconnected with each other and tested for interoperability. Although such tests providean interesting overview, reasons for lack of compatibility cannot easily observed as theymay either lie in the underlying SOAP framework or in the OPC implementation.

2. Observations during the implementation: During the implementation, the program-mer will have to deal with shortcomings of the SOAP framework, loose definitions inthe OPC specifications or other problems which affect the compatibility. These findingscan be collected and may prove valuable information for estimating interoperability.

This analysis focuses on the observations during the implementation. Moreover, practicaltests will be done, although they are limited due to lack of available OPC implementations.

Compatibility Issues Found During the Implementation

The SOAP standard was initially developed with simplicity in mind. However, over time itbecame very complicated146. Moreover, SOAP Web services also embrace other technologies,such as XML, XML Schema, WSDL and others.

146Therefore SOAP was initially the acronym for “Simple Object Access Protocol”. Later it was called“Service Oriented Architecture Protocol”. The current SOAP 1.2 specification states that the word “SOAP”is no acronym anymore, as none of the names above are correct anymore. This fact alone is a hint to theincreasing complexity of SOAP.

96

7 ANALYSIS OF THE SOAP PROTOCOL IN INTERNET/FIELDBUS GATEWAYS

Due to this high level of complexity, SOAP frameworks tend to have difficulties imple-menting every aspect of the SOAP specification. This was also observed with ZSI: As denotedabove, ZSI does not implement several data types, such as “Decimal” and SOAP arrays. How-ever, it seems that these limitations do not apply to ZSI, other frameworks such as .NET alsoseem to have shortcomings. For instance, the OPC XML-DA specification defines a specificdata type for arrays as the underlying frameworks lack support for this data type. Anotherexample is the statement in [OPCXMLDA]:

Time, date and duration are not supported fully by the .NET tools. Time and date aretransmitted as dateTime while duration is transmitted as a string. A ValueType Qualifierattribute is included when values of this type are transmitted between client and server.

Such missing functionality complicates the implementation and may lead to interoper-ability problems. To give an example, let’s assume that a SOAP framework supports the“duration” data type and automatically serializes it as an XML Schema “duration”. AnOPC peer that is implemented with a framework unaware of this data type would there-fore either reject the SOAP message or maybe decode it incorrectly, which could lead tounexpected behavior. It is expected that SOAP frameworks will evolve and provide a betterSOAP standard compliance and functionality in the future. In fact, older frameworks hadmuch more incompatibility issues than current implementations.

Another advantage which improves compatibility is the automatic validation of SOAPmessages, as depicted in figure 69.

Server

Function

SOAP

Message

Parser

SOAP

Message

Validator

SOAP

Message

Serializer

Cllient

Function

SOAP

Message

Validator

Client Server

Request

Message

Figure 69: Validation of a SOAP Request Message in the Client and Server

It can be seen that the client validates the SOAP message before it serializes and sends itand the server also validates the message before it hands it to the receiving server function.This validation greatly improves the compatibility of SOAP Web services, as the exchangedmessages must follow a previously defined specification. Moreover, validation reduces errorsas faulty messages will be rejected by the validator. However, validation comes at a cost: Onthe one hand, it will increase the CPU load, on the other it will add extra complexity to theSOAP framework.

As a next step, the validation facilities of ZSI were tested. ZSI does not have a dedicatedvalidator but it does nevertheless catch various errors due to type and element checking. Theresults are depicted in figure 70.

Type Checking Wrong Element Enumeration maxOccurs Required attribute

Input Yes Yes No Yes No

Output Yes (2) Yes (1) No Yes No

(1) Wrong elements can be added but will not be serialized

(2) Automatic conversions (e.g. str -> int) are tried. If conversion fails, an error is raised.

Figure 70: Validation Facilities of ZSI

For this test, various erroneous typecodes were built and attempts were made to serializethem. On the other hand, it was tried to parse manually constructed erroneous SOAPmessages. It can be seen that validation of advanced features, such as enumeration is not done.Nevertheless, many errors are detected, such as wrong data types in elements/attributes.

97


The OPC XML-DA standard itself is simple at a first glance but tends to be quite com-plicated during the implementation. It is also interesting that the specification is not strictlySOAP compliant. [OPCXMLDA] states: OPC XML-DA is being developed in a manner thatleverages concepts from Simple Object Access Protocol (SOAP) 1.1.

There are some difficulties and unclear sections in the OPC standard, especially with thesubscription architecture. Some of these are as follows147:

OPC Faults may be not SOAP compliant: The SOAP 1.1 specification states the fol-lowing: The faultcode values defined in this section MUST be used in the faultcodeelement when describing faults defined by this specification. The namespace identifierfor these faultcode values is ... Use of this space is recommended (but not required) in thespecification of methods defined outside of the present specification. The set of faultcodevalues defined in this document is: “VersionMismatch”, “MustUnderstand”, “Client”,“Server”.. [LIV02] interpretes this section thus: Currently there are only four types offaults that can e defined by SOAP. On the other hand, the OPC XML-DA specificationintroduces custom faultcodes by using a custom namespace. It is unclear whether thisviolates the SOAP specification or not. This is once again an example where the SOAPspecification is unclear and may be implemented in a different manner by differentSOAP frameworks.

Complicated subscription: Implementing the subscription is quite complicated, especiallywith the advanced subscription architecture with wait/hold times. Some important in-formation is found in comments, such as The first SPR148 after the Subscribe mustreturn only Items with changed values if the Subscribe returned the values (ReturnVal-uesOnReply = true). The first SPR after the Subscribe must return all items if theSubscribe did not return the values (ReturnValuesOnReply = false). Such commentsmay easily be overlooked, which may lead to incompatible implementations.

Moreover, the specification does not explicitly state whether one or more clients mayquery a subscription. Moreover, it seems to be allowed that one client may issue con-current SPR messages to an OPC server. The specification does not state which ofthese SPR’s should receive changed data. This lack of information may also lead tounexpected behavior of OPC servers.

Omitting return values vs. empty strings: In case of “void” return values, the specifi-cation is sometimes unclear whether an empty attribute/element should be returned orthe element/attribute should be omitted.

Return items in write operations: The specification does not state if in case of a suc-cessful write operation, an empty item should be returned.

Notification of buffer overflows: In case of buffer overflows, an item attribute should beset with a specific code, denoting the overflow. However it is not specified if only oneor more items should contain this flag.

147Fortunately many of these questions were answered in the Internet forum on the OPC web site by a helpfulOPC representative.

148SPR is used as an acronym for the OPC XML-DA operation “Subscription Polled Refresh”

98


Interoperability between Different OPC XML-DA Implementations

As denoted above, a practical test may also produce valuable information about compatibil-ity and interoperability. All tests were done for simplicity reasons on PC hardware insteadon the IGUANA hardware. As a first step, a simple client test was done. The OPC foun-dation provides various sample OPC servers, which may be used for testing purposes. Asdenoted above, client functionality was implemented in the design, which was used to test allavailable OPC operations as shown in listing 37. Most of these tests worked immediately149,interoperability issues were not found.

1 from PyOPC import XDAClientfrom PyOPC. OPCContainers import ∗

3

addres s = ’ http :// path/ to / s e r v e r ’5 xda = XDAClient ( OPCServerAddress = addres s )

p r in t xda . GetStatus ( )7 pr in t xda . Read( ItemContainer ( ItemName=’ S ta t i c . Simple Types . Int ’ ) )

Listing 37: Creating a Simple OPC Typecode

The next step was to test the IGUANA OPC server, which was done with an OPC testclient150 and a simple test setup, as depicted in figure 71.

ESD

Simulation

Server

IGUANA

OPC

Server

Test

Client

Figure 71: Interoperability Test Setup

The test results of all available OPC XML-DA operations were as follows:

GetStatus: This operation worked without any problems.

Read/Write: The read operation also worked right away, but writing to OPC items returnederrors. After thoroughly examining the SOAP messages, it turned out that the testclient expected an empty OPC item as a result, while the IGUANA OPC client returnedan empty XML element. As denoted above, the OPC XML-DA specification definesthe reply message of write operations very loosely, which led to this incompatibilityproblem.

Subscription: The same incompatibility problem was also found in the AddSubscriptionoperation: Subscribing to an object did not return any items, which led to an errorin the test client. The SPR and CancelSubscription operations worked without anyproblems, buffering, deadband and the advanced subscription architecture also workedas expected.

Browse: The browse operation of the test client tried to retrieve certain properties whichwere not available from the server. This led to erroneous client behavior. Apart fromthis problem, browsing worked properly.

149There were minor issues with qualified names (QNames) which were incorrectly implemented.150This test client was available from Advosol Inc., and was part of an evaluation version an OPC XML-DA

software development kit. This SDK is compatible with the Microsoft Windows operating system and can bedownloaded from their web page, namely http://www.advosol.com. The client has a graphical user interface,which supports all needed OPC functionality.

99


GetProperties: This operation also worked without any problems.

This short server test shows that loose definitions in the OPC XML-DA specification leadto multiple interpretations which may result in incompatible implementations. Nevertheless,most of the OPC operations worked as expected.

7.2 Performance and Scalability of the IGUANA OPC Server

Another important issue is the performance and scalability of the IGUANA OPC server. Toexamine these issues, several tests were performed. All of these tests were performed on PChardware151 and not on the IGUANA gateway hardware for simplicity reasons. However, theserver performance on different hardware can easily be estimated from the test results.

Parsing/Serializing Performance

SOAP Web services serialize data as XML documents (the SOAP message). This documenthas to be created from a custom data structure, which is called serializing. The receiver of aSOAP message parses it with an XML parser back into the custom data structure. Duringthe testing of the IGUANA OPC server, it was observed that this parsing and serializingtook relatively long compared to other tasks. Therefore all steps in this serializing/parsingprocedure were timed to examine this issue. Figure 72 depicts the typical steps in serializingand parsing SOAP messages with ZSI.

Fill Typecode

Build Serialized Object

Convert Serialized Object to String

Build Parsed SOAP Object

Parse SOAP into Typecode

Read Data from Typecode

Figure 72: Performance Test Setup of Parser/Serializer

The duration of 1000 repetitions of each step was measured. Three different SOAPmessages were tested to rule out side-effects. Moreover, ZSI supports the usage of threedifferent XML parsers, which were also compared in the test152 The result of this test can befound in figure 73.

GSR-1 RR-1 GPR-1 GSR-2 RR-2 GPR-2 GSR-3 RR-3 GPR-3

Fill Typecode 0,13 0,1 0,09 0,13 0,1 0,09 0,14 0,1 0,09

Build Serialized Object 3,53 3,27 2,37 3,55 3,33 2,39 3,43 3,32 2,43

Convert Serialized Object to String 1,83 1,2 1,06 1,86 1,21 1,1 1,86 1,2 1,07

Build Parsed SOAP Object 55,33 37,06 33,71 2,95 2 1,77 1,06 0,93 0,87

Parse SOAP into Typecode 4,86 2,79 1,98 2,44 1,58 1,14 2,03 1,31 0,93

Read Data from Typecode 0,06 0,05 0,04 0,06 0,05 0,04 0,06 0,04 0,04

65,74 44,47 39,25 10,99 8,27 6,53 8,58 6,90 5,43

RR - result message of OPC Read

GPR - Result message of OPC GetProperties

Duration in seconds for 1000 repetitions

GSR - Result message of OPC GetStatus

Figure 73: Test Results of Parser/Serializer

151The PC hardware consists of a Athlon XP 1600+ with 768MB main memory. All tests were done withPython 2.4.

152The parser is denoted by the numbers 1 to 3 in the test results. For instance GSR-1 refers to the GetStatusresult message with parser 1, while GSR-2 refers to the GetStatus result message with parser 2.

100


It can be observed that the choice of the parser has a massive speed impact. Obviouslythe first parser - which is the default in ZSI - is very inefficient, being approximately 50 timesslower than the fastest parser. Moreover, it can be seen that filling/reading data to/from theZSI typecodes are a lot faster than other steps. It is also interesting that serializing a SOAPmessage takes slightly longer than parsing when an efficient parser is used. As serializingneeds much less effort than parsing a SOAP message, code optimizations that speed up theserializer are probably possible153.

When an efficient parser is used, the performance of ZSI seems to be reasonable: Parsingand serializing a common SOAP message, which is needed for any client/server communica-tion, is in the millisecond range on the PC hardware of the test setup.

Scalability and Performance of the IGUANA OPC Server

The next step was to measure the performance of the IGUANA OPC server in differentscenarios. The test setup consisted of the OPC server which was to be tested, a client thatcreates different loads on the server and the ESD simulation server that provide appropriatefieldbus data for the test server.

In order to optimize the test results, the OPC server which was to be tested was placedon a different machine than the test helper programs, such as the client and the ESD server.This way the measurements of the server performance could not be tampered with otherCPU demanding processes. Moreover, the test was set up with server hardware slower thanthe client hardware to avoid server idle times due to a slow client.

Two OPC operations were chosen for the test, namely “GetStatus”, which does notrequest data from the ESD server and “Browse”, which retrieves fieldbus data via an ESD“NODELIST” command. Every test consisted of 500 requests of one of these operations.These tests were first issued in a pipelined manner, then multiple simultaneous requests weredone, starting with 5 up to 500 concurrent requests.

It was observed that the timing results for up to 50 concurrent requests were quite con-sistent, while 100 and more concurrent requests led to erratic results. The reasons for thistest behavior were unclear at first, but it was noticed that there were short durations wereboth the client and the server were idle and therefore a problem with the network was sus-pected. Therefore a network I/O test was done with a network analyzer tool154. The resultingdiagrams are depicted in figure 74.

pipelined query 10 concurrent connections 100 concurrent connections 100 concurrent connections

Figure 74: Networking I/O Diagram During Server Testing

The first two diagrams show the network load with a pipelined query, where requests areissued one after another, and a scenario with 10 concurrent requests. Multiple tests were done

153Parsing is implemented via a Python library that provides an interface to the extremely efficient “Expat”XML parser, which is written in C. On the other hand, serializing is done in Python, which is due to theinterpreter being much slower than C. Nevertheless speed improvements should be possible by optimizing thePython code or coding certain parts of the serializer in C.

154The tool used for this test was “Ethereal”, an open source network analyzer. This tool is available fromhttp://www.ethereal.com.

101


which always led to very similar I/O diagrams. However looking at the two right diagrams,which both result from server tests with 100 concurrent connections155, it can be seen thatthey differ. It is very likely that this inconsistent network load lead to erratic test results, asdenoted above. The cause of this problem could not be located, but it is likely that it lieseither in the Twisted framework or in the TCP stack of the operating system.

Due to these problems, the test setup was changed, so that all test programs resided onthe same server. This way, the client CPU load will influence the test results, but it wasobserved that they are minimal and can be neglected. Figure 75 depicts the test results.

15,00

17,00

19,00

21,00

23,00

25,00

27,00

29,00

31,00

33,00

1 5 10 25 50 100 250 500

Concurrent Connections

Seco

nd

s

GetStatus

Browse

Figure 75: Server Throughput

It can be seen that the IGUANA OPC server scales well up to 100 concurrent requests.Above this value the throughput seems to decrease. However, an IGUANA gateway willprobably never have such high loads, therefore the maximum amount of simultaneously al-lowed connections may be limited to 100. This way, the server will always provide optimalperformance.

From this graph the average throughput can be deduced, which is at minimum 20 Browserequests per second and 26 GetStatus requests per second156. As the IGUANA gateway hard-ware is approximately ten times slower than the testing hardware, it can be estimated thatit could handle two OPC operations per second, which seems to be a reasonable performancefor a fieldbus gateway.

Memory Usage

As a next step, the memory requirements were tested. The current memory usage for theOPC server could be retrieved from the operating system and was periodically logged. Thenthe three OPC operations “GetStatus”, “Read” and “Browse” were tested with 1, 50 and100 concurrent server requests. The results of this memory usage test is depicted in figure76.

It can be seen that the idle server requires approximately 15MiB. It is interesting toobserve that the “Read” and “Browse” operations consume much more memory than the“GetStatus” operation. The reason for this behavior is that “GetStatus” does not connect tothe ESD server and hence does not create any Twisted ESD client protocol objects. However,the memory requirements are huge in case of concurrent requests: 10 concurrent OPC readrequests almost double the memory requirements of the server. However it is also interesting

155In these diagrams 5 network bursts, which are associated with the concurrent requests. Altogether, 500requests are issued. As the client sends 100 simultaneous requests at once, it takes some time for the serverto process these requests and to respond. During these processing times, the network is idle.

156Due to the specific test setup, the throughput in this test is lower than it would be without the additionalload from the test client and the ESD simulation server.

102


0

5000

10000

15000

20000

25000

30000

35000

40000

45000

Idle

1Get

Sta

tus

50 G

etSta

tus

100

Get

Sta

tus

1Rea

d

10 R

ead

100

Rea

d

1Bro

wse

10 B

rowse

100

Bro

wse

Mem

ory

Usag

e i

n K

iB

Figure 76: Memory Usage of IGUANA OPC XML-DA Server in Different Scenarios

to see that the additional requirements between 10 and 100 concurrent requests are not ashigh as it would be expected. The reason for this server behavior is uncertain, but it isexpected that certain optimization would greatly reduce these high memory requirements157.

It was further interesting to examine how much memory is allocated by various servermodules. Therefore the memory usage of the server was measured during the server starttime after each module load. The results of the OPC IGUANA server memory allocation isdepicted in figure77.

Python

32%

Basic Libs

4%

ZSI

25%

Gen. Typedefs

7%

Twisted

18%

OPC Logic

14%

Figure 77: Memory Usage of the Server Components

It can be seen that the Python interpreter and the ZSI framework each allocate approxi-mately a third of the memory, while the last third is allocated by the Twisted modules andthe OPC server logic. It is interesting to see that the SOAP message handling, which is doneby ZSI and its generated typedefs consumes almost a third of the server’s memory, which isquite much. Moreover, it was also not expected that the Twisted framework consumes somuch memory.

157It was further observed that some of the memory was not freed after a request. Theoretically, the Pythongarbage collection should handle these issues but for an unknown reason, it does not. It was found thatcalling the garbage collector after each operation does reduce the memory usage, but it slows down the serverconsiderably. It is expected that the newer version of Python (2.5) will resolve these problems.

103


It is expected that certain optimization, especially in the ZSI SOAP framework but alsoin Twisted, could lead to a reasonable memory reduction, however further investigations onthis topic were not done.

7.3 Efficiency of the SOAP Protocol in Fieldbus Access

It is also interesting to examine the efficiency of the SOAP protocol in the current design.In this context, a comparison between SOAP and an alternative technology would be mostappropriate. One option would be to compare the IGUANA OPC server with the ESDsimulation server. Although these two technologies offer similar capabilites, it has to bedenoted that the OPC XML-DA SOAP messages transport much more information than theESD protocol such as:

Server Status: Most OPC reply messages contain timestamps of the server receive andreply time, moreover, they contain information about the current server state.

Multiple Item Queries: The OPC SOAP message format allows to request multiple field-bus items in one message.

Item Properties: OPC provides additional properties, such as Quality, the item timestampand others.

Error Descriptions: In case of errors, OPC may be more descriptive, such as deliveringa detailed information about a server failure, while ESD errors contain only an errornumber and a single string.

However, many of these features are not needed in a connection-oriented protocol, suchas ESD: For instance the “ClientRequestHandle” that helps to distinguish between SOAPmessages makes no sense with the ESD protocol. Also the receive/reply timestamps will makesense for SOAP Web services where messages may be sent through various paths and proxiesbut are probably useless in a connection-oriented protocol. Moreover, in many situationsa very simple fieldbus read suffices, hence many of the extra OPC features are not neededfor simple applications. Therefore, from the perspective of a fieldbus client with very basicrequirements, a comparison between ESD and OPC XML-DA seems to be possible.

SOAP certainly has various advantages over proprietary fieldbus protocols, such as inter-operability, human legibility, firewall passing and documentation with WSDL documents, asalready discussed in chapter 2.3. Nevertheless SOAP has some disadvantages, which are asfollows:

SOAP is not Simple: Although the simplicity of SOAP was initially a main goal, thestandard became quite complex. Despite supporting frameworks, the construction ofSOAP messages is quite complicated, as already shown in chapter 6.2. A simple protocolsuch as ESD may be easily implemented by hand, while parsing SOAP messages requiresa framework.

To give an example, the implementation of the ESD protocol has 615 code lines, whilethe implementation that reads OPC SOAP messages into custom data types need 1500lines of code158 and additionally requires a complicated framework.

158Once again it must be noted that ESD has much less functionality and therefore fewer messages, howeverafter subtracting functionality from the SOAP code which is missing in ESD, the code for reading OPC SOAPmessages is still longer than the ESD protocol implementation.

104


SOAP has a huge overhead: The price for the convenience of XML is that the protocolgets bigger and the parsing produces extra server load. Figure 78 depicts the conse-quences of this overhead.

0

100

200

300

400

500

600

ES

D S

erv

er

Thro

ughput

OP

C S

erv

er

Thro

ughput

req/s

0

200

400

600

800

1000

1200

1400

1600

1800

2000

ESD Read

Message

Size

SOAP

Read

Message

Size

byte

s

0

2000

4000

6000

8000

10000

12000

14000

16000

ESD

Server

Memory

Usage

OPC

Server

Memory

Usage

kB

Figure 78: Comparison Between ESD and OPC

It can be seen that the throughput of the ESD server is approximately 25 times higherthan its OPC counterpart. Moreover, the network load will be less due to a far smallermessage size159. It can also be observed that the ESD server memory usage is lower asno XML parser and SOAP framework is needed.

The SOAP message size will probably not be a problem to modern networks. It wasobserved with a network analyzer that 100 OPC Read requests led to a network trafficof 300kB160. A typical OPC XML-DA server that does not handle more than 5 requestsper second, would put a load of 15kB/second on the network, which requires a networkspeed of approximately 128kbit/second.

The biggest problem may be the high memory requirements, as embedded hardwaremay have limited resources and cannot provide as much memory as the server wouldneed. However, it is very likely that server implementations in the C programminglanguage consume much less memory and would therefore fit on such hardware.

Toolkits support only HTTP: Theoretically, SOAP messages could be transported viavarious protocols, however nearly all current SOAP toolkits support HTTP as a trans-port protocol only. Although HTTP has its strength, it also has weaknesses such asthe following:

Speed: Compared to a connection-oriented protocol such as ESD, HTTP is relativelyslow.

Stateless: HTTP is stateless, therefore more complicated tasks like transactions arevery difficult to perform and cause the requests to contain enough informationfor the server to provide an ACID161 behavior which is needed for many applica-

159The size of the SOAP message length may be reduced with an efficient text compressor by approximatelya factor of three, however the compressing/decompressing would increase the server load, which would resultin a decrease of the throughput.

160This number also includes the overhead of HTTP and TCP/IP.161In this context, ACID is an acronym for Atomic, Consistent, Isolation, and Durable. To ensure predictable

behavior, all transactions must possess these basic properties functionality.

105


tions162. Call backs or events from the server to the client are not possible. HTTPis strictly a request/response protocol.

Some toolkits also provide support for SMPT, which has additional routing capabilitiesand enables asynchronous notifications, but SMTP is probably inappropriate for OPCas the routing of the SMTP messages may lead to high latencies.

162For instance, such additional information is transported in OPC SOAP messages via the “ClientRe-questHandle” attribute.

106

8 Conclusion and Future Work

Research and analysis in this thesis show that SOAP as a fieldbus protocol has its strengthsand its weaknesses. These facts help to decide whether SOAP should be used for certainapplications or whether alternative technologies should be favoured. Table 1 tries to sum upthe most important advantages and disadvantages of SOAP.

Advantages Disadvantages

High level of Interoperability "SOAP is not Simple"; Complex to

implement

HTTP/SOAP can travel through firewalls Securing SOAP Web services is

complicated, "smart" firewalls are needed

Human legibility of SOAP messages; Easy

debugging

Higher network load compared to other

protocols due to XML format

XML validators may prevent errors in the Web

service

Buggy SOAP frameworks may lead to

malfunctioning Web services

Comprehensive protocol documentation through

technologies such as WSDL

High hardware requirements

(CPU/Memory).

Table 1: Advantages and Disadvantages of SOAP Web services

OPC XML-DA seems to be a thoroughly designed and mature specification of a SOAP-based fieldbus interface. However, some parts of the standard tend to be complex to imple-ment, such as the subscription architecture, moreover, some elements seem to exist in orderto maintain backwards compatibility with previous OPC standards which may be obstructiveto new implementations that are not related to older OPC specifications. Nevertheless theopenness and high level of interoperability of the OPC XML-DA specification seem to leadto a widespread usage of this fieldbus interface and may prove a long-term replacement ofolder, DCOM-based OPC standards.

Currently a new standard is being developed by the OPC consortium, namely the “OPCUnified Architecture” (OPC-UA). As shown in chapter 3, OPC today has very differentspecifications, covering issues such as data access, alarms and events and historical access.The new OPC-UA standard tries to bring all different OPC specifications into one, all-embracing standard163, which is structured in different sections, covering the following topics:

• Address Space, Services and Information Model

• Security

• Data Access

• Alarms and Conditions

• Programs

• Historical Access

It can be observed that all access types, such as data access and alarms, are based on oneinformation model. This approach may lead to a higher level of compatibility between differ-ent OPC applications and may also reduce implementation efforts. It is also very interestingthat OPC has decided to also cover security, an aspect that current OPC standards lack.

163OPC-UA is designed for vertical integration, therefore horizontal integration issues, such as specified byOPC-DX are not part of this emerging standard.

107

8 CONCLUSION AND FUTURE WORK

OPC-UA compliant clients and servers utilize SOAP Web services for their communi-cation, therefore it seems that SOAP has a bright future for Internet/fieldbus interfaces.Further information about this emerging standard can be found in [OPCXMLUA], the firstpublicly released specification of the OPC-UA standard.

Future Work

There are several other SOAP related issues that should be addressed to further examine thesuitability of SOAP Web Services as an Internet/fieldbus interface, such as the following:

Security: Security is more or less not addressed in this thesis. However, many fieldbusapplications may need common security features, such as encryption, authenticationand access control. The SOAP specification itself does not address security, instead itrelies on the underlying protocol that transports the SOAP messages. Most often thiswill be HTTP, therefore common security measures such as HTTPS for encryption andHTTP basic authentication may be used. It will be interesting to examine whetherthese technologies are appropriate for fieldbus access.

Performance: As denoted above, SOAP Web services tend to have significant hardwarerequirements. As fieldbus gateways will often be implemented on embedded hardwarewhich has limited resources, the deployment of SOAP Web services on fieldbus gatewaysmay lead to performance problems. Therefore careful selection of server modules, suchas an efficient XML parser and a thorough optimization of the SOAP framework andthe server are important. This issue may also be interesting for further research.

Alternative Transport Protocols: Although HTTP is the most common transport pro-tocol for SOAP messages, other protocols, such as SMTP, may have certain advantagesfor fieldbus applications and would also be an interesting topic for further examination.

The IGUANA OPC XML-DA server seems to be a good base for further research. Asthe design is already very modular, the implementation could be used as the base for anOPC XML-DA framework. This framework could then be used to implement other protocolsbeside ESD and could be enhanced to support advanced features such as security and amaintenance interface for the OPC server itself.

At the time of writing, the new SOAP 1.2 specification has been released, which shouldresolve various issues and will be the successor of the previous SOAP 1.1 standard. SOAPcan still be seen as a new technology; SOAP frameworks seem to mature and new SOAP-based protocols and implementations are emerging fast. It will be interesting to see how thistechnology will further evolve.

108

REFERENCES

References

[BACNET/WS] ASHRAE Standard:First Public Review Draft of BSR/ASHRAE Addendum c to ANSI/ASHRAE Stan-dard 135-2004, BACnet - A Data Communication Protocol for Building Automationand Control NetworksAmerican Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.GA 30329-2305, 2004

[BART04] Saulius Bartkus:Integration of Fieldbus Systems into Enterprise Applications based on Meta DataHamburg University of Technology, Germany 2004

[BIR01] Mark Birbeck, Jason Diamond, Jon Ducket et al.:Professional XML 2nd EditionWrox Press Ltd. 2001

[BLO91] John Bloomer:Power Programming with RPCO’Reilly, CA-95472 1991

[DAC01] Michel C. Daconta, Leo J. Obrst, Kevin T.:The Semantic Web: A Guide to the Future of XML, Web Services and KnowledgeManagementJohn Wiley & Sons NJ-07030-5774 2003

[DIE97] Dietrich, Loy, Schweinzer:LON-Technologie: verteilte Systeme in der AnwendungHuthig, Heidelberg 1997

[ENG02] Robert Englander:Java and SOAPO’Reilly, CA-95472 2002

[FET06] Abe Fettig:Twisted Network Programming Essentials O’Reilly, CA-95472 2006

[FIE00] Roy Thomas Fielding:Architectural Styles and the Design of Network-based Software ArchitecturesUniversity of California, Irvine 2000

[GRO01] William Grosso:Java RMIO’Reilly, CA-95472 2001

[HAR73] J. Harrington:Computer-Integrated ManufacturingIndustrial Press, New York 1973

[HUN03] Andy Hunt / Dave Thomas:Pragmatic Unit Testing in Java with JUnit The Pragmatic Programmers, LLC2003

109

REFERENCES

[ILON04] Echelon Corporation:i.LON 100 e2 Internet Server Programmer’s Reference Version 1.1Echelon Corporation, CA 95126, 2004

[LAUR01] Simon St. Laurent, Joe Johnstong, Edd Dumbill:Programming Web Services with XML-RPCO’Reilly, CA-95472 2001

[LIV02] Dan Livingston:Advanced SOAP Web DevelopmentPrentice-Hall Inc., NJ-07458 2002

[LOB01] Maxim Lobachov, Peter Palensky:Bringing Energy-related Services to RealityInstitute of Computer Technology, Vienna University of Technology, Austria 2001

[LOB02] Maxim Lobachov:Communication to the Extended Service Daemon (esd)Institute of Computer Technology, Vienna University of Technology, Austria 2002

[LOB06] Maksim Lobashov el al.:Vertical Integration in Distributed Automation EnvironmentElektrotechnik und Informationstechnik, Heft 5.2006, Springer-Verlag, page 1662006

[MAR03] Alex Martelli:Python in a NutshellO’Reilly, CA-95472 2003

[OBIX] Brian Frank, Tridium:oBIX Specification, Working Draft 0.6OASIS Open, Billerica, MA-01821, 2004

[OPCDA] OPC Foundation:OPC Data Access Custom Interface Standard Version 3.00OPC Foundation, AZ-85260-1830, 2003

[OPCXMLDA] OPC Foundation:OPC XML-DA Specification Version 1.01OPC Foundation, AZ-85260-1830, 2004

[OPCXMLUA] OPC Foundation:OPC Unified Architecture, Release Candidate Specification, Part1: Concepts, Ver-sion 1.20OPC Foundation, AZ-85260-1830, 2006

[PIL05] Mark Pilgrim:Dive Into PythonApress CA-94710 2005

[PRA01] Gerhard Pratl, Maxmim Lobachov, Thilo Sauter:Highly Modular Gateway Architecture for Fieldbus/Internet ConnectionsInstitute of Computer Technology, Vienna University of Technology, Austria 2001

110

REFERENCES

[R1630] T. Berners-Lee:Universal Resource Identifiers in WWWRequest for Comments 1630, 1994http://rfc.net/rfc1630.html

[R1738] T. Berners-Lee, CERN, L. Masinter et al.:Uniform Resource Locators (URL)Request for Comments 1738, 1994http://rfc.net/rfc1738.html

[R1808] R. Fielding, UC Irvine:Relative Uniform Resource LocatorsRequest for Comments 1808, 1995http://rfc.net/rfc1808.html

[R2045] N. Freed, Innosoft, N. Borenstein:Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Mes-sage BodiesRequest for Comments 2045, 1996http://rfc.net/rfc2045.html

[R2141] R. Moats, AT&T:URN SyntaxRequest for Comments 2141, 1997http://rfc.net/rfc2141.html

[R2616] R. Fielding, UC Irvine, J. Gettys et al.:Hypertext Transfer Protocol – HTTP/1.1Request for Comments 2616, 1999http://rfc.net/rfc2616.html

[R2821] J. Klensin, AT&T Laboratories:Simple Mail Transfer ProtocolRequest for Comments 2821, 2001http://rfc.net/rfc2821.html

[RED97] Frank E. Redmond III:DCOM: Microsoft Distributed Component Object ModelIDG Books Worldwide, Inc. 1997

[SAUT02] Thilo Sauter, Maksim Lobashov, Gerhard Pratl:Lessons Learnt From Internet Access to Fieldbus GatewaysInstitute of Computer Technology, Vienna University of Technology, Austria 2002

[SAUT05] Thilo Sauter:Integration Aspects in Automation – a Technology SurveyProc. of the 10th IEEE Int. Conference on Emerging Technologies and FactoryAutomation (ETFA’2005) Vol. 2, pp. 255-263 2005

[SEE02] Scott Seely:SOAP: Cross Platform Web Service Development using XMLPrentice-Hall Inc., NJ-07458 2002

111

REFERENCES

[TAN02] Andrew S. Tanenbaum:Computer Networks, 4th EditionPrentice Hall Inc., NJ-07458 2002

[TAR01] Zahir Tari, Omran Bukhres:Fundamentals of Distributed Object Systems - The CORBA PerspectiveJohn Wiley & Sons NJ-07030-5774 2001

[THO00] Stephen A. Thomas:SSL & TLS Essentials - Securing the WebJohn Wiley & Sons NJ-07030-5774 2000

[VEN05] Marcus Venzke, Christoph Weyer, Volker Turau:Application specific vs. standard Web service interfaces for the vertical integrationof fieldbus systemsDepartment of Telematics, Hamburg University of Technology, Germany 2005

[VLI02] Eric van der Vlist:XML SchemaO’Reilly, CA-95472 2002

[WAL02] Aaron E. Walsh:UDDI, SOAP and WSDL - The Web Services Specification Reference BookPrentice-Hall Inc., NJ-07458 2002

[WER03] Thomas Werner et al.:From Order to Production: A Distinct View on Integration of Plant Floor andBusiness SystemsProc. of the 2003 IEEE Int. Conference on Emerging Technologies and FactoryAutomation (ETFA’2003) Vol. 1, pp. 276-281 2003

112

Documents

Diplomarbeit - QWERviolin.qwer.tk/dusty/thesis/soap_if_inet-fan.pdf · Diplomarbeit SOAP Interface For An Internet/Fieldbus Gateway ausgef¨uhrt zum Zwecke der Erlangung des akademischen