Using Web Service Gateways and Code Generationfor Sustainable IoT System Development

Till Riedel∗, Nicolaie Fantana∗∗, Adrian Genaid∗, Dimitar Yordanov∗, Hedda R. Schmidtke∗, Michael Beigl∗∗TecO, Karlsruhe Institute of Technology ∗∗ABB AG Corporate Research Germany

Abstract—Wireless Sensing and Radio Identification systemshave undergone many innovations during the past years. Thishas led to short product lifetimes for both software and hardwarecompared to classical industries. However, especially industriesdealing with long-term support of products, e.g. of industrialmachinery, and product lifetime of 40+ years may especiallyprofit from an Internet of Things. Motivated by a practicalindustrial servicing use case this paper shows how we hope tomake equally sustainable IoT solutions by employing a modeldriven software development approach based on code generationfor multi-protocol web service gateways.

I. INTRODUCTION

Information sources from an Internet of Things (IoT) areespecially valuable for industrial field service [1] and mainte-nance engineers [2]: new IoT technology can help to completemaintenance tasks, react more precisely to faults and thus ex-tend the lifetime of machines. We already described potentialsand challenges of using IoT systems in industrial field servicein [1]. Service engineers are experts in connecting informationabout the product life cycle and its current state using datasources ranging from knowledge bases and Internet resourcesto machine diagnostic information and in-situ collected mea-surements – not to forget the sensory inputs and knowledgeof the engineer himself. In an engineer’s toolbox wirelesssensing and RFID systems complement traditional measuringequipment and industrial IT. However, those new tools proveonly powerful if they integrate with existing tools and workflows. This imposes a problem in industries where deviceshave a lifetime of often more than 40 years, and old toolsmay especially valuable if paired with years of experience.

Within the Aletheia project (www.aletheia-projekt.de) westarted looking at an integrated approach making informationfrom the IoT available as federated product and process infor-mation sources. Also motivated by the economical risk to beton one IoT technology, we focused on a platform independentsolution. Typical high level IoT standards like Application-Level Events (ALE) were not intended to capture low-levelsemantics that are often important for industrial measurements.Existing low-level wireless networking and sensing standardsdid not match our effort to support diverse applications andsetups (like WirelessHART) or targeted only lower networklevels of communication (like 802.15.4). Practically we arefacing a vast number of application specific protocols, runtimesystems and APIs. This is a natural development for an areawhere the most powerful systems operate at limits in termsof cost and run on very constrained resources and optimizedminiaturized hardware. Some of those specialized technologiesalready face widespread implementation in industry. In a few

years Generation 1 RFID tags, e.g. used in name plates, mayprove to be the Philips screw of the IoT: although better drivetypes (i.e. interfaces) may exist it will be wise to integrate thefitting driver into your tool box.

Our challenge is to provide a tool box that include suchtechnologies while reducing its overall (future) weight in bothfigurative and practical sense. In this paper we report onapplying state of the art theoretical findings as well as bestpractices from other areas into a novel system, which weapply in an industrial servicing use case. The implementedsystem consists of two parts for which we present our designdecisions and whose components we describe in this paper. Aflexible run-time gateway architecture abstracts basic networkservices and translates them to a standardized interface basedon the Device Profile for Web Services. The second part thedesign section directly provides the necessary tools to developplatform optimized services by means of code generation.We practically integrate a model driven software developmentframework to bring web service processing to any device: itis designed so as to enable even the smallest devices suchas resource-constraint wireless sensor nodes or even passiveRFID tags to implement document based Web Services. Basedon the implementation of the industrial service use case we areable to show that clear high level abstractions and low leveloptimizations are desirable goals for a any IoT infrastructurethat do not contradict each other.

II. MULTIPROTOCOL GATEWAY DESIGN

Numerous works have been presented that employ WebServices directly on embedded devices, e.g. recently [3],[4].They are mostly relying on the valid argument that WebServices are needed at some point for coupling embeddedsystems with state of the art distributed architectures. Inparticular, the Device Profile for Web Services (DPWS) istargeted towards bringing Web Services to devices. It providesa basic profile for Services that is practically motivated by theapplication on devices and successful integration of embeddedsystems, such as machine and control elements, into a servicelandscape using DPWS has been shown [5]. The generalproblem of using Web Services is that even light-weightimplementations are too resource heavy for many IoT systems.That is why it makes sense to use optimized gateways to bridgeenterprise and personal computers with the IoT. However,there is currently no satisfactory practical solution on how todevelop a large number of different IoT gateways as a softwareproduct line with minimal adaption while preserving platformspecific optimizations.

978-1-4244-7414-1/10/$26.00 ©2010 IEEE

urn:...cy54

address translation

lifecycle management

DPWS Gateway p1

state

target MAC layer

Web Service Client

ABC

urn:...d54

syntactictransformations

semantic transformations

http://gwp1/2/Chttp://gwp1/2/Avirtual DPWS

node endpointC

ode

Gen

erat

ion

Web

Ser

vice D

efinit

ion La

ngua

ge

Client Application

DPWS interface

http://gwp2/1/X

routing

Wireless Sensor Networks+ RFID Plattforms

Fig. 1: Abstract Web Service Gateway Design

With the gateway depicted in figure 1 we present a pieceof software and hardware that translates between multipleIoT systems with only small adaption. One objective of thegateway design was it can directly run on a number ofembedded hardware systems, such as an RFID Reader, aWireless Sensor Network Bridge, or a any mobile devicethat has the physical interfaces needed to connect to localIoT devices. Many previous implementations of Web Servicegateways either instantiate a proxy service on the gateway orleave it completely to the IoT Node to handle the Web Serviceinformation [6],[3]. However, there is a tradeoff betweengateway scalability and node complexity.

Both solutions are non-optimal extremes of a complicatedpractical optimization problem. The proposed framework di-rectly addresses this issue by allowing a developer to choosehow much of the state needs to be handled in the gateway. Incontrast to other systems, our system operates transformationdriven, i.e. like a style sheet: it converts incoming informationand passes it on. We thus exploit a design aspect of WebServices, namely that all necessary information is containedin the message. In order to reduce the load of the IoTsystem, the gateway may transform the messages in a targetoptimized representation. The gateway can further optionallyhandle a request in proxy by holding state on the gatewayif the result is known, e.g. if multiple clients have the sameevent subscription. The basis for our implementation is thelightweight gsoap runtime library (gsoap2.sf.net) and the coreimplementations by the WS4D project (ws4d.org) to interfacestandardized DPWS functionality.

In [7], we introduced the concepts of semantic and syntactictransformations for including smart items into ERP systems.The semantic translation matches different network semanticsand translates them. To do this a set of network primitivesneed to be implemented for the platform. The syntactic trans-lation of the message of the payload. Because the payload isapplication-specific and the concrete application is probablynot known when building a gateway this part is handled byautomatically generated code which is again interfaced bya few simple primitives. The according components of thegateway are depicted in figure 1. In the following sectionwe describe the overall design and the basic componentfunctionality. A concrete implementation for the technology

mapping is described in the use case presented in section §III.

A. Semantic TransformationsThe idea of the semantic transformation is to map certain

parts of the rather verbose SOAP binding to the semantics ofa concrete networking platform. For RFID technology, e.g.,it translates the semantics of an RPC to a reader query ortransfers a read to an event.

1) Lifecycle Management and Identification: The primaryconcern of the lifecycle management component is to monitorthe underlying IoT network and manage and discover servicesprovided by the nodes. Discovery can be implemented byactive reader queries or network joining procedures depend-ing on the network topologies. The WS-Addressing standardallows specifying addresses at different networking layers.This is exploited by giving each IoT device a unique logicaladdress. This URN can embed other address spaces containingother types of unique ids, i.e. it may include a hash code ofan Electronic Product Code for RFID or an 802.15.4 MACaddress for a wireless sensor node. This way a node staysunique across multiple gateway instances and can physicallymove between gateways.

The life-cycle management component deals with announc-ing nodes and services running on the nodes. We decouple theWeb Service Discovery from the IoT discovery, in order tolower the load on the IoT network, especially in the presenceof multiple client applications, and to mitigate the effectsof fluctuating networks like RFID on the client logic. Thegateway can use static knowledge about devices, e.g. retrievedfrom the unique numbering scheme of a MAC address or EPCcode, and services, which can be provided by the node.

2) Address Transformation and Routing: The definition ofhosting relationship in DPWS metadata maps service instanceto devices. We use endpoint addresses to store all necessarydispatch information needed to route a message from a WSclient to an IoT node. The first part of the URL, the hostand port number, ensures that a request to the node servicereaches the correct gateway that handles the node. The rest ofthe endpoint address specifies the dispatch path of the messagetowards the IoT node. This allows us to transfer this part ofthe routing state towards the client, so that messages can berouted into the IoT completely stateless.

The routing component of the gateway is used to deliverIoT events by push delivery to Web Service clients usingthe WS-Eventing protocol. Eventing call backs and network-specific event addresses are stored in a local address lookuptable that is queried when a message enters the gatewayfrom the IoT. Furthermore specifying custom WS-Eventingfilters exposes a way to translate arbitrary network-specificsubscription patterns to the Web Service world.

B. Syntactic TransformationsWhen a message is transferred into an IoT network we

support a second step of transformation in ordert to optimizethe communication on the upper network layers. The payloadof a message is transformed from an verbose XML to anoptimized binary representation and back. In order to minimizethe overhead on the gateway, the structure of the message

is retained and the transformation works on the syntacticstructure of the message and the encoding of its elements.For recoding and optimizing the message, knowledge aboutthe Web Service Message structure is necessary to reducecomplexity. For each message, we dynamically load a recod-ing function that can map a Web Service message into anoptimized message format.

As the number of recoding functions required would equalthe number of Web Services times the number of devicesexisting in a system, implementation by hand is not feasiblein truly heterogeneous IoT landscapes. We propose a ModelDriven Software Development (MDSD) approach with codegeneration for the Web Service Description Language (WSDL)for development of encoders and decoders.

1) Model Driven Software Development: Supporting dif-ferent source and target encodings as well as execution plat-forms and programming languages easily leads to redundantoverhead of code and consequentially less manageable code.Introducing a common intermediate representation for boththe data format and the encoders and decoders addressesthis problem. Considering the formality, consistency and toolsupport for data meta-models we decided to use the EssentialMeta-Object Facility (EMOF) (ISO/IEC 19502:2005). To mapWSDL or rather XML Schema to EMOF, we rely on existingwork[8]. Although formality and tool support is a big advan-tage, EMOF is a superset of context free grammars[9] andthus traditionally difficult to handle on devices with limitedresources. Therefore we use only a subset of EMOF as ourintermediate representation. This subset is also known as theclass of regular nested word languages [10], which coincideswith the structure of XML described by an XML Schema.This class of languages includes non-regular, context-freelanguages while being as robust as the class of regular wordlanguages [10]: deterministic nested word automata have thesame expressiveness as non-deterministic ones, they can fur-ther represent both linear as well hierarchical relations betweenlanguage elements, and the class of nested word languages isclosed under intersection and union. These properties make itparticularly suitable for representing XML structures and forsupporting modular design.

On this basis of those meta-models we have alreadysketched a model-driven work flow within the Eclipse Mod-eling Framework for developing message translation for IoTsubsystems [11] that largely automates the process of devel-oping new syntactic transformation for our gateway system aswell as message binding for the IoT platform. This model-driven development process starts with a high-level WSDLdescription of all data to be communicated from which itautomatically constructs an abstract model. This model istransformed into a target model, which in turn is used forcode generation. Up to this point the development processis platform independent and needs no further interventionas long as standard WSDL is used (later we will describepossible transparent annotations to XML Schema that can beused to further optimize target encodings.) In contrast to manyother Web Services frameworks like AXIS, gsoap or WCF, thecode generation is open in terms of programming language,underlying network layers, and data representations. Figure 2

XSD

messagemodel

message layout

acceptor automata

WSN Back-end

RFID

ASN.1UML DSL

PIM

CIM

Code

PSM

common meta-model

automatameta-model

MOF

M1

M2

M0

M3

Fig. 2: Model driven message exchange scheme

outlines the proposed model driven software developmentworkflow according to [12] that we proposed to developencoding translators.

For implementing communication of structured messageson an arbitrary channel a linear encoding is needed ratherthan an abstract representation. In our case an encoding canbe accepted by a special class of pushdown automata calledvisibly pushdown automata (VPA). Automata are a goodcompromise between an abstract and formal representation ofdata formats and a low-level, imperative solution to describe acomputer system. They can be easily constructed on the basisof the abstract grammar of the language they should acceptand can be mapped efficiently to soft and hardware. Especiallyembedded designs are traditionally affine to automata becauseof their efficiency on non-parallel, pipeline-less MCU andtheir deterministic behavior. The meta-model and algorithmsto build VPA are based on [10] and were implemented asEMOF meta models for our MDSD process. Visibly pushdownautomata are the basis of our code generation and can be usedto accept, generate, rewrite and query nested word languagessuch used in typed Web Services.

One of the downsides of restricting ourselves to such asimple automata model is that not all semantics of the EMOFmessage meta model can be captured by the VPA. Howeverwe do not lose this information for later code generation steps,as the original model is linked via references in all automatatransitions. Traditionally this information can be used forsyntactical runtime validation of messages in the gateway.More importantly information captured in the data model canbe used to optimally encode message data. We e.g. exploitdata type informatino (integer, timestamp, string, etc.) to selecta value encoder/decoder. We also support arbitrary minimumand maximum values as well as precision information: atemperature value with a range from −20 to 80 ◦C with aresolution of 0.1 ◦C is automatically encoded as 10 bits. Codegeneration makes this scheme extensible for arbitrary XMLdatatypes.

While by design all encodings can be accepted and emittedby the same type of automata to interface those automata dif-ferent API types can be suported. For example we can supportevent, document model and pull API based messaging process-ing. Voelter [13] shows how different software configurationscan be efficiently be generated using an aspect oriented codegeneration. We adopt this approach for our purposes usingthe xPand template language to implement the code generator.All refinements are encoded as advices of the basic automatacontrol flow templates. Different input and output advices can

Fig. 3: Testbed using mobile device and pPart sensor nodes

be added to the transition templates of the pushdown automatavia a configuration file. This allows the on-demand creation ofspecific eclipse code generator plug-ins for any combinationof model source and target platform. While code generationalways requires a onetime effort per target, it eliminates theneed for re-implementation for different message protocols.The advantages of removing such redundancies are in ourexperience manifold beyond saving routine work. Especiallycode maintenance can be done much better: possibilities forbugs are reduced and improvements propagate more quickly.

Compiler and framework support is offered via eclipsebuilders that can be customized directly as part of a plug-inwork flow. Triggering code generation automatically generatesstatic or dynamic link libraries for inclusion into the targetsystem. We have currently created code generators that canproduce stubs for the C, C# and Java programming languageson the Windows, Linux, Symbian, Particle[14] and Contiki[15]operating systems using DOMs both untyped or typed andtyped and untyped SAX style events: the code is alwaysoptimized to fit the needs of the target system.

III. MOBILE SERVICE ENGINEER USE CASE

When servicing equipment, historical and real-time infor-mation is a valuable good. Often the information gap betweenthe information system and the reality or missing details fromsite prevents optimal reactions to equipment malfunction. Anyeffective maintenance strategy where condition or risk is con-sidered relies upon the availability of data and knowledge[1].In a modern industrial environment a lot of data is available inplant automation and maintenance systems, which are usingfixed installed sensors and asset supervision systems. However,flexible on-site, ad hoc data collection by the individual serviceworker proves helpful for diagnostics, increases the infor-mation amount and supports better diagnostic or decisions.Permanently installed RFID tags as well as ad hoc sensornetworks can add valuable information in this process. Theultimate value of all technology comes from the integrationand intercommunication of all systems including the serviceengineer himself. Today, field service engineers often havelimited information available on-site to perform service tasks.For instance information is needed to find the right equipmenton-site, to analyze the application environment, to diagnosethe root-cause of the problem, and to repair the faulty equip-ment. The envisioned Internet of Things system improvesinformation availability dramatically: it provides the mobile

client = new SensorValuesClient();client.Endpoint.Address = discoveryClient.Find(

new FindCriteria(typeof(ISensorValues))).Endpoints[0].Address;

temp=client.GetSensorValues().Sample[0].temperature;

Listing 1: c# sensor reading client code

service engineer with context-specific information via real-time transactions with the back-end information sources ora dedicated knowledge base has been send up front to themobile device of the service engineer, e.g., together with theservice ticket.

The design decisions in the previous section are all madeon a very abstract level without any technology binding.The gateway and the development tool chain were designedin a way that they can implement a number of differentconcrete systems and support a number of use cases. As aprototypical representative of ad-hoc IoT use cases we presentan Internet of Things application from an ongoing project. Inthe following we show that a derived instance of the designedarchitecture functionally fully maps the requirements of thisuse case. This shows the practical relevance as well as theexpressiveness of the model in terms of this application class.By implementing gateways for multiple IoT subsystems, wefurther demonstrate some practical implication of choosingthis development approach. Besides reporting our experiencewith practically implementing and using the system as wellas giving a qualitative evaluation of our work, we furtherexperimentally show some important quantitative aspects ofour system design based on the implementation of this usecase.

A. IntegrationA mobile service platform serves as an information hub

for the service engineer. The target platform is a portablepersonal device with display and input capabilities (runninga Windows Operating System). Currently the gateways run onthe same mobile device with hardware interfaces to interactwith both sensors and identification tags directly attached.However, settings with the gateways either running on externalreaders, base stations or dedicated gateway devices are possi-ble using the same components. We initially started off witha measurement application where we continuously integratednew RFID and sensor network interfaces. After some timethe interface code easily could outweigh the functional codeof the application, which supports standard diagnosis work-flows. Using web services now allows discarding most of theplatform specific parts. The software already works the .NETenvironment and nicely integrates any sensor node via theWindows Communication Foundation. Listing 1 demonstrateshow comfortable the integration of IoT systems can be donein only 3 lines of code for anyone used to traditional sen-sor network communication. Besides automatically generatedcode this is the only interfacing necessary.

Practically we learned the hard way that this is only part ofthe story when integrating heterogeneous systems via Web Ser-vices. While adding a DPWS client to the C# application tookus about 10 minutes, it took us a few months to understand the

problems that sometimes occurred in the interaction betweenthe gateway and the mobile device each using different Web-Service stacks – WS4D-gsoap and WCF. (This additionallysupports our decision not to fully implement SOAP WebServices on each IoT device) Although widely used and quitematured both implementations did not support the standardcompletely, WS4D-gsoap did not understand client generatedheader parameters and the Microsoft WCF did not correctlytranslate a valid WSDL issued by the DPWS gateway; bothwithout giving any explicit error. Debugging the runningsystem also practically proved that the verbosity of XML didnot help with messages quietly disappearing in transparentdispatching code. It seems especially problematic to us thatdifferent client behavior increased the gateway complexityand requires unnecessary resources on the server, which isan issue for practical scalability. Nonetheless full support ofWeb Service standards pays off when considering all possi-ble network interactions within the use case: By supportingroutable Web Services as well as multicast announcementswe have successfully tested can support complex topologieswhere service engineers can interact with the system locallyand remote support is done over the Internet.

B. Functional Expressiveness

While the expressiveness in terms of communication pat-terns and different modes of operations are guaranteed bythe working DPWS interface it was crucial to validate thatall functional aspects and work flows of our use case canbe expressed by the system. This includes identification,placement, configuration, measurements, storage and analysis[1]. In order to do this we took an existing measurementapplication (figure 3) that implements the servicing processand ported it to the new interface. In various experimentalsettings we confirmed the completeness of the interface.

1) Identification: One of the primary concerns of industrialmeasurement is the unambiguous association of data to datasources may that be pre-deployed measurement units or RFIDname plates. He needs to scan the landscape for existing IoTdevices and to add to devices like sensor nodes, if he needsto gather certain physical parameter. WS-Discovery is a verysimple standard that allows ad-hoc scanning for devices andservices. It can further be extended to search for devices withcustom criteria. Most importantly it works infrastructurelessusing multicast queries and announcements on peer to peerbasis, which can be easily translated to RFID batch readingsor discovery protocols in wireless sensor networks.

2) Placement: The DPWS device based metadata exchangeclearly identifies model and device on the basis of commonattributes. Because the WS-MetadataExchange is extensible,the lifecycle management component can augment furtherinformation that is important to the use case. An example islocation information, which is an important part of the identi-fication data. The discovery protocol further allows extendingthe discovery process by using custom query expressions toselect nodes.

3) Configuration: Once the service engineer has anoverview of the number and types of the systems in place,he informs himself about the current state and the capabilities

ssimp_GetResponse r={};s t r u c t WRITER *writer=alloca_WRITER(msg,ssimp_Sample);TemperatureSensorGet( ssimp_Sample_add_temperature(

ssimp_GetResponse_add_Sample(&r)));ssimp_GetResponse_write(&r, writer);send(msg,finalize(writer));

<GetResponse xmlns="http://particle.teco.edu/SSimp/201/SensorsValues"><Sample><Temperature>21.5</Temperature></Sample></GetResponse>

|1 |0 |1 |00101011 |0 |0 |0 |0 ||sample|time|temp|(x+20)/.5|accl|light|force|sample|

Listing 2: C-Code, SOAP body and binary representation

of all systems. In our case the functional capabilities and theinterface of a node are encoded in WSDL as a service. Theservice interface contains all the static functional capabilitiesof a node, i.e. what information it can provide. Furthermoredynamic capabilities can be configured via RPC. Also morecomplicated configuration tasks that involve changing themeasurement service interface by e.g. adding processing tasksthat change the representation of data from the time to thefrequency domain, can be realized using DPWS by announcingthe new interface via the discovery service.

4) Measurement: The most important part of any sensingsystem is the acquisition of measurement data. Documentbased (in contrast to RPC style) Web Services provide avery fit tool for those needs. WS-Eventing is sufficient tohandle most aspects of starting or selecting event sources (weadditionally implement inter-measurement synchronization asan additional service). We use the WSDL/XMLSchema in-terface to describe various aspects of a measurement valuelike min and max values. Using annotation like precision wecan further add information to measurement data. We alsostarted to annotate the WSDL with ontologies like UnitML,which allow us to even better describe measurement data, otherinformation is added as documentation into WSDL file.

5) Storage: Documenting the measurement and the processof measurement is as important as the measurement itself es-pecially when talking about digital signal processing systems.Comtrade is a classical format for transient recording[16]. Itspecifies three files to be stored with each measurement thedata set itself, a description and the configuration parameters.We emulate those separate data sets by serializing the commu-nication data, the metadata and all configuration calls to a nodeinto XML documents. Because all exchanged data is well-typed and refers to an interface or grammar description, thisdata can be reinterpreted at any point. No additional storageformats are needed. The same is true for the binary storageof sensing data on the nodes. Using document based WS andaccordingly crafted interfaces, we can use the same data typingand encoding for local storage as for communication. For theRFID, we also use the same data model for on chip storage asfor communication. The model driven transformation allows adifferent representation of the data based on the local needs.

C. Efficient Development

One of our design assumptions was that a model drivensoftware development process helps us to make the develop-ment of a whole software product line [13] of gateways moreefficiently. By implementing this design process for ourselveswe are able to show that those software technical innovationscan effectively be applied to the IoT domain. We implemented(and are continuing to implement) a number of gateways forboth productive and experimental purposes:

• Particle (binary encoding, AwareCon MAC, DOM-basedcode, new interface for existing pPart node)

• 6LoWPAN (binary encoding, 6lowpan/802.15.4MAC,event-based code, new Contiki Node)

• “Dummynode” (various encodings, IPv4, dom-based, PC-based test environment)

As well as three prototypes we are currently working on:• RFID (application specific encoding, reader protocol, no

code, RFID storage prototype)• Microstrain (vendor specific encoding, serial AT, closed

source system, prototype for lifting non-service nodes)• Java Node (binary encoding, SAXReader implementa-

tion, IPv4, java sensor nodes or mobile devices)For the Particle platform, which is a ultra-low power wire-

less sending system with a 8-bit PIC18f6720 MCU and ultralow power unbuffered 869MHz TR1001 OOK transceiver,we compared the generated platform stubs on a quantitativelevel with the existing hand optimized minimalistic ConComAPI [14]. We could confirm our claim that using high leveldesign abstraction we do not sacrifice performance. This isespecially interesting because obeying models adds designconstraints so that theoretically some optimal manually writtencode exists. In practice the fact that knowledge is betterrepresented to the developer seems to outweigh this even ona mature system. We could confirm that the generated codeadded no overhead to the code size, both programs uses 40kByte of the available 128 kByte of code memory. Concerningmemory usage we could see a slight shift towards staticallyallocated memory in the program using the generated code,which 604 instead of 560 byte of RAM. At the same timethe maximum amount memory allocated dynamically on thestack during runtime was reduced from 118 to 80 byte incomparison to the manually optimized code. However, wediscovered that a unexpectedly high overhead was introducedwhen using bit-packed encodings because the PIC MCU onlysupports a 1 bit rotate operation for shifts. We ultimatelydecided that the added computational effort, was compensatedfor by the savings in the over the air encoding and memorysavings by the inlined structure bits. However, this is typicalpoint where it might be necessary where optimizing thesystem requires a change in the message encoding which issupported by the development process without any expliciteffect on the application. In figure 4, we compared the sizeand transmission power needed to transfer need to a singlepacket. In a addition to the original semistructured and untypedConCom format, we compared the generated the documentproduced by the generated encoder to a “naive” encoding asXML as well as packed XML documents using GZIP and

20

30

40

50

60

300

400

500

600

700

800

900

mJbyte

0

10

20

30

40

50

60

0

100

200

300

400

500

600

700

800

900

Encoder

mJbyte

Fig. 4: Encoding size and related energy consumption

the XML-aware XMill compressor. Furthermore we addeda comparison to VTD-XML that provides support effectiveprocessing of received data for embedded systems.

Another proof of flexibility is our implementation for a16 MIPS Jennic JN5139 SOC based sensor node that runsthe Contiki Operating system using 6lowpan communication.The system varies from the Particle Sensor Nodes in vari-ous aspect besides using a 2.4 GHz 802.15.4 MAC layer.It has low-power 32bit OpenRISC MCU at its core thatusing big-endian byteorder and aligned memory access. Incontrast to e.g. using packed structures the generated binaryen-/decoder could automatically handle network to host byte-order conversions and alignment corrections. Secondly theContiki is build around protothreads, which provide coroutinelike behavior within the operating system. By adding yieldingin the automata we execute the automata concurrently withthe applications that consume the data. This allows us to evenreceive large structured messages with theoretically infinitesize (i.e. streams) requiring only memory in the size of thelargest simple data type contained in the message and a symbolstack that can be bounded for most message models. Writingthe code generators we largely reused the generator java SAX-Events. Although the concrete programs look quite differentdue to different programming languages and data structures,similarities in the control flow are very significant. The codegenerator requires only about 150 lines of platform specificgenerator code.

D. Gateway performanceAn important practical aspect of our work was that the

system was able to scale with a growing number of deployednodes and services in the IoT. Although we are happy with thegeneral resource consumption in normal operation, rather thanpresenting very application specific results, we like to reportsome of the more critical finding. To illustrate this we presentsome experimental measurements taken from simulated IoTnodes with the gateway and the DPWS client on the samemachine. One of the positive scaling features of a gatewaybased approach is that each gateway only needs to handlethe network traffic of one IoT platform. The traffic behinda single network is bounded, the overall throughput actuallydecreases due to coordination overhead in the network. Forour test we generated events with a constant rate 100ms froma varying number of node. Figure 5 shows a near constantthroughput from 20 nodes onwards because the sensor networkbandwidth was reached. We can see a slight increase onthe WS-Eventing side as additional subscription data wasexchanged. The system performed well up to 50 nodes after

200

300

kbyte/s

0

100

200

300

0 20 40 60 80

kbyte/s

#nodes

Fig. 5: Single client throughput on Wireless Sensor Network(WSN) and Web Service Eventing (WS-E) Protocol

16

64

256

kbytes/s

1

4

16

64

256

0 20 40 60 80 100

kbytes/s

#clients

Fig. 6: Throughput with multiple clients

this point the WS client was not able to handle the push HTTPpush delivery dispatching fast enough (The traffic increaseafterwards is caused by the connection cleanup). This showsa bottleneck in Web Service callback communication to theclient. Performance increases can actually only be expectedby optimizing the Web Service clients which was out of scopein our case. Yazar argues in [4] that RESTful Web Servicesmay solve performance issues, however, in our experimentsperfomance losses occured due to slow TCP connection setup,that afects SOAP (using http) and RESTful Web Servicesequally.

The problem becomes even more apparent in Figure 6. Herewe scaled up the number of clients. Because WS-Eventing usesunicast to each client the connection could not be pooled.We used only a single sensor node that transmitted eventswith 4kbyte/s, this output was transformed and multiplexedto the clients. The figure shows nicely that the ressourceusage on the sensor nodes does not scale with the numberof clients. However, we can also see that only after 5 clientsthe event delivery rate on the WS-Eventing site stagnatesat approximately 250kbyte/s. All performance measurementswere dominated by TCP setup times and connection handlingon the Web Service side. The actual transformation stepswere below the measurement resolution at the rates that wereachievable through both the sensor network and the eventdelivery. Nonetheless especially in the target scenario eitheronly two or three clients consume fast events or the nodes arein low-duty cycle operation anyway for long term monitoring.We further hope to improve our results by optimizing theconnection handling towards the WS client and by movingthe gateway to separate hardware.

IV. DISCUSSION AND RELATED WORK

We have shown that using Web Service based interfacedescriptions paired with a model driven approach we can

achieve a high flexibility at a low runtime overhead whendesigning message based communication within an Internet ofThings. We could show that the system perfectly fits our usecase and we think the approach is applicable to many otherareas with similar requirements. However, there are variouslimitation to a general applicability of the approach. Oneprincipal concern we cannot address with our work is thatby limiting our design space via meta-models, we can neverget better performance than the best hand-optimized code ormessage encodings. This might be critical in rare cases, whereresources are extremely critical. In those cases a differentdescription (in the worst case executable code) is needed todescribe the mapping to an abstract message format. The sameis true if a standard compliant encoding is required, that cannotbe represented as a visibly pushdown language. However, alook at practically used systems quickly shows that by far mostcommonly used encoding fall into the class of tree languageswe are dealing with in our work.

Another expected long-term result from working strictlytop down is that we are transferring large parts of thecomplexity formally captured in run-time middleware andprotocol frameworks into code generation. This leads to ahigher level of abstraction and simpler sources at design time,but can lead to a similar complexity at compile and run time.The system even encourages the use of diverse proprietarymessage encodings. However, we believe that much like withtodays programming language compilers can generate code fordifferent processors, coprocessor extensions and optimizationgoals, only few experts need to be aware of this low levelarchitecture. Additionally all communication can be tracedback to the abstract representation, that can be debugged with acommon set of tools. We believe that the risk of designing IoTsystems is rather that they cannot be understood on a globallevel. One of the consequences of such a top-down approachis that our current communication architecture only guaranteesthat a message can be understood if the abstract type is known.This is a closed world assumption and in parts contradictsthe principle of self-descriptive messages as proclaimed bymodern REST [17] architectures. XML and for XML binaryencodings like EXI [18] allow a structural decoding at anypoint in the system. We purposefully require much of theintelligence of the system only at compile time while notruling out classical self-descriptive message or just-in-timecompilation of acceptors. With EXI we already mentioned adifferent approach on handling XML efficiently.

[19] recently has compared different binary encodings foruse with Web Service on sensor nodes. This paper is not aboutthe implementation of a single combination of encodings andplatform interfaces. We rather designed a flexible frameworkthat uses open technology and standards to support a noveldevelopment approach. Our explicit goal was to integrate asmuch as possible from the previous work and allow developersto adjust systems to their requirements. This work thereforebuilds upon earlier works that bridge sensor networks likeuMiddle [20] or the CoBIs UPnP gateway architecture [7] thataddress network convergence by providing manual messagemappings between wireless networked systems. Although bothsystem also a differen standard, UPnP, the main difference isthat this work uses automatically generated translation that

only require the original web service description. Translationis not specified per message but per platform using model-to-text transformations in a model driven workflow.

A similar system was sketched in [21] based on Ada forheterogeneous military applications. In recent years, however,much progress has been made in terms of standardizationand advances of model driven software development tools andtechniques. This paper exploits those techniques with advancesin the formal modeling and parsing of structured data formatsand applies it to the IoT domain. It provides well-definedmodels and meta-models for describing both data-structureof messages and the execution structure for de-/encoders andbuilds a code generator toolchain on top that is usable in anindustrial context.

V. CONCLUSION AND FUTURE WORK

Automatically generated DPWS gateways for sensor nodespresents a novel practical approach to handling the task ofintegrating multiple concurrent IoT systems. Model drivencode generation techniques and highly efficient communica-tion bindings to arbitrary wireless sensor network services viaa Web Service interface can help us to design sustainable IoTsystems. Based on our experiments with an industrial servicinguse case we could show both optimization and better platformintegration. Although our study only has exemplary nature,we think by showing a vertical integration we could underlinethe potential of applying state of the art in model drivendevelopment and formal language techniques to the domainof information exchange in an Internet of Things on a verypractical basis.

We were surprised that even using a minimal web servicesand standard HTTP communication we ran into performanceissue on the client side early on. This confirms earlier resultswhere also that classical ERP systems have difficulties scalingwith sensor network events under dynamic load conditions [7].From a different perspective it just underlines how efficientcommunication can be handled inside IoT networks. We stillbelieve that Web Service add to a real IoT because they enableflexible architecture and new interaction schemes. Especiallyif using conceptionally powerful SOAP-based standards it isimportant that the associated overhead is not off-loaded to theIoT devices. This is what we have achieved with our gatewayapproach. Our Web Service gateways scale well with local IoTnetworks. An open problem that our experiments expose howa gateway may handle a large number of arbitrary clients.Luckily the industrial service use case does not have thisproblem and thus we are confident that our approach will helpus to integrate further IoT technology at a higher pace withoutloosing manageability.

We are currently working on integrating new RFID readerand sensor network platforms using our gateway design. Inthe long run we hope to remove an often artificial technolog-ical classification of networked sensing systems and enabletruly diverse Internet of Things landscapes. By adding IoTtechnology to the tool box of the industrial service engineer,we already see many innovative practical applications on thehorizon. Abstracting from technology is an important steptowards focus on functionality.

VI. ACKNOWLEDGMENT

This work was partially funded by the German FederalMinistry of Education and Research (BMBF) as part of theAletheia project.

REFERENCES

[1] N. Fantana and T. Riedel, “Servicing industrial machinery - challengesand potential using wireless identification and networked sensing sys-tems,” Jun. 2009, pp. 70–73.

[2] M. Lampe, M. Strassner, and E. Fleisch, “A ubiquitous computingenvironment for aircraft maintenance,” in Proceedings of the 2004 ACMsymposium on Applied computing. Nicosia, Cyprus: ACM, 2004, pp.1586–1592.

[3] O. D. et al., “Towards the web of things: Using DPWS to bridge isolatedOSGi platforms,” in Web of Things 2010, Mar. 2010.

[4] D. Yazar and A. Dunkels, “Efficient application integration in IP-based sensor networks,” in Proceedings of the First ACM Workshopon Embedded Sensing Systems for Energy-Efficiency in Buildings, 2009,p. 4348.

[5] P. Spiess, S. Karnouskos, D. Guinard, D. Savio, O. Baecker, L. M. D.Souza, and V. Trifa, “SOA-based integration of the internet of thingsin enterprise services,” in Proceedings of the 2009 IEEE InternationalConference on Web Services-Volume 00, 2009, p. 968975.

[6] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D. Savio, “Interactingwith the SOA-Based internet of things: Discovery, query, selection,and On-Demand provisioning of web services,” IEEE Transactions onServices Computing, vol. 3, no. 3, pp. 223–235, 2010.

[7] T. Riedel, C. Decker, P. Scholl, A. Krohn, and M. Beigl, “Architecturefor collaborative business items,” Lecture Notes in Computer Science,vol. 4415, p. 142, 2007.

[8] R. Hudson, “Authoring XML schemas for use with EMF,” Eclipsepedia,2009.

[9] M. Alanen and I. Porres, “A relation between Context-Free grammarsand meta object facility metamodels,” Mar. 2003.

[10] R. Alur and P. Madhusudan, “Adding nesting structure to words,” 2009.[11] T. Riedel, N. Fantana, M. Scholz, and C. Decker, “A model driven

internet of things,” in Seventh International Conference on NetworkedSensing Systems (INSS’10), Kassel, Germany, 2010.

[12] T. Stahl, M. Voelter, and K. Czarnecki, Model-Driven Software Devel-opment: Technology, Engineering, Management. John Wiley \& Sons,2006.

[13] M. Voelter and I. Groher, “Product line implementation using Aspect-Oriented and Model-Driven software development,” in Software ProductLine Conference, 2007. SPLC 2007. 11th International, 2007, pp. 233–242.

[14] C. Decker, A. Krohn, M. Beigl, and T. Zimmer, “The particle computersystem,” Proceedings of the 4th international symposium on Informationprocessing in sensor networks, 2005.

[15] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki-a lightweight andflexible operating system for tiny networked sensors,” in Proceedings ofthe First IEEE Workshop on Embedded Networked Sensors, vol. 2004,2004.

[16] A. G. Phadke, J. A. Jodice, M. G. Adamiak, J. D. Brandt, J. A. Bright,R. O. J. Burnett, C. H. Castro, T. W. Cease, D. M. Clark, and G. Clough,COMTRADE: A new standard for common format for transient dataexchange, 1992.

[17] R. T. Fielding and R. N. Taylor, “Principled design of the modern webarchitecture,” ACM Trans. Internet Technol., vol. 2, no. 2, pp. 115–150,2002.

[18] J. Schneider and T. Kamiya, “Efficient XML interchange (EXI) format1.0,” W3C Working Draft, vol. 19, 2008.

[19] G. Moritz, D. Timmermann, R. Stoll, and F. Golatowski, “Encodingand compression for the devices profile for web services,” in 2010 IEEE24th International Conference on Advanced Information Networking andApplications Workshops, 2010, pp. 514–519.

[20] J. Nakazawa, H. Tokuda, W. K. Edwards, and U. Ramachandran, “Abridging framework for universal interoperability in pervasive systems,”in Proceedings of the 26th IEEE International Conference on DistributedComputing Systems, 2006, p. 3.

[21] C. Plinta, R. D’Ippolito, and R. V. Scoy, “A specification and codegeneration tool for message translation and validation,” in Proceedingsof the 1998 annual ACM SIGAda international conference on Ada.Washington, D.C., United States: ACM, 1998, pp. 276–286.