DEPLOYMENTOF EMBEDDEDWEB SERVICES IN REAL-TIME SYSTEMS
GUIDO MORITZ, STEFFEN PRUETER, DIRK TIMMERMANN
∗
AND FRANK GOLATOWSKI
†
Abstrat. Servie-orientedarhitetures(SOA)beomemoreandmoreimportantinnetworkedembeddedsystems.Themain
advantagesofServie-orientedarhiteturesareahigherabstrationlevelandinteroperabilityofdevies.Inthisarea,Webservies
havebeomeanimportantstandard forommuniationbetweendevies. However,thisupomingtehnology isonlyavailableon
devieswithsuientresoures. Therefore,embeddeddeviesareoftenexludedfromthedeploymentofWebserviesduetoa
lakofomputingpower,insuientmemoryspaeandlimitedbandwidth.Furthermore,embeddeddeviesoftenrequirereal-time
apabilitiesforommuniationandproessontrol. Thispaper presentsanewtabledrivenapproahtohandlereal-timeapable
Webserviesommuniation,onembeddedhardwarethroughtheDeviesProleforWebServies.
Keywords: servie-oriented deviearhiteture,deviesproleforWebservies,Webserviefordevies
1. Introdution. High researh eorts are made to develop ross domain ommuniation middleware
basingonarhitetural oneptslikeREST (Representationalstatetransfer) and Servie-orientedDevie
Ar-hitetures(SODA)[25℄andontehnologieslikeUPnP(UniversalPlug andPlay),JINI,andDPWS (Devies
ProleforWebServies). WhileUPnP,DLNAandrelatedtehnologiesareestablishedinnetworkedhomeand
smalloeenvironments,DPWSiswidelyusedintheautomationindustryatdevielevel[26℄andithasbeen
shownthat theyare alsoappliableforEnterprise integration[24, 27℄. Barisietal. [33℄outlinethepotential
of SOA to beome a keyfator in embedded software development. Embedded development proess anbe
improvedsigniantlyiftheSOAparadigmisusedin eah developmentstage. However,tomakethishappen
itisneessarytoestablishthegroundingfordeeplyembeddedsystemsandreal-timesystem
BesidestheadvantagesofSODA,additionalresouresarerequiredtohostaneessarysoftwarestak. There
are SODA toolkits available for resoure-onstraineddevies like UPnP staks [28℄ or DPWS toolkits [8, 9℄.
However,additionaleortisneessaryfordeploymentondeeplyembeddeddeviesandespeiallyforembedded
real-time systems. Deeply embedded devies are small miroontrollers with only a few kB of memory and
RAM (e.g. MSP430, ARM7). These devies annot be applied with omprehensiveoperating systems. But
theyareessentialbeauseastheyombine prie,lowpowerproperties,size andbuild-inhardwaremodules.
Thiswork presentsanewapproah, whihan beapplied todeeplyembedded deviesandservereal-time
andspeiationompliantDPWS ommuniation.
2. Servies in Devie Controlling Systems. TheWorld Wide WebConsortium(W3C) speies the
Webserviesstandard[13℄. UPnP isapopularspeiationin thehomedomain. Dueto thelakof seurity
mehanismsandthemissing servieproxyit islimitedtosmall networks(see[2℄). Furthermore,UPnPbased
ommuniationsalesnotwiththearisinghighnumberoffutureomingwirelesssmartooperatingobjetsdue
to its usageof Simple Servie DisoveryProtool (SSDP) fordevie disoveryat run-time. Web servies are
alreadywidelyusedinlargenetworksandtheinternetforbusinessproessesandserver-to-serverommuniation
mainly. Thislient-to-serverinterationusesSOAP[12℄forthetransportlayerandExtensibleMarkupLanguage
(XML)forthedatarepresentation[1,15℄. Ontheotherhand,theWebserviesprotoolsneedmuhomputing
power and memory, in order to enable a devie-to-devie ommuniation with more onstraint resoures as
servers. Therefore,aonsortiumleadbyMirosofthasdenedtheDeviesProleforWebservies(DPWS)[4℄.
DPWSusesseveralWebserviesprotools,whilekeepingaspetofresoureonstraintdevies. Inomparisonto
standardWebservies,DPWSisabletodisoverdeviesatruntimedynamiallybasedonWS-Disovery,
WS-MetadataExhangeandWS-Transfer,withoutaglobalservieregistry(UDDI).TheinludedWS-Eventing[6℄
speiation also enableslients to subsribe for events on a devie to get notied by state hanges. Thus,
pullmessaging is avoided in favorof pushmessaging, whih isa signiantadvantageforresoureonstraint
devies and networks. DPWS is integrated in Mirosofts operating systems Windows Vista and Windows 7
andfurthermorein misellaneousframeworkslikee.g. .netMiroFramework. Additionally,opensourestaks
are available [8℄. In August 2008 a tehnial ommittee (TC) at OASIS was formed for the Web Servies
Disoveryand Web Servies Devies Prole (WS-DD) [5℄. WS-DD denes a lightweightsubset of the Web
Serviesprotool suitethat makesit easyto nd, share, andontroldevies on anetwork. Thework ofthis
∗
UniversityofRostok,Rostok18051,Germany({guido.moritz,steen.prueter, dirk.timmermann}uni-rostok.de)
†
TCisbasedontheformerDPWS, WS-DisoveryandSOAP-over-UDPspeiation. InJuly2009version1.1
ofnamed speiationswere publishedbytheOASISWS-DD TC.Formanyompanies,thisisthereasonfor
developingnewinterfaesfortheirprodutsbasedontheseprotools.
Usingserviegatewaysisthepredominatingapproahtobridgebetweendierentommuniationlayersor
betweenembedded systemsand enterprise systems. Ourapproah aimsat loweringthe eortsfor integration
and interation and to set on standardsinsteadof re-developnew protools. Bukl et al. [32℄ assume adata
entriproessingmodelisusedinembeddedsystems.AuthorsdierentiatebetweenembeddedServies(alled
as eServies ) and Web Servies. Both worlds are integrated by a servie gateway. In [34℄ Web Servies
on Universal Networks (WSUN) is desribed. The presented SOA based platform (environment) whih is
omposed of broker,registryand universal adaptorand is ableto bridgebetweendierentSOAtehnologies,
likeJiniand DPWS.This work onentratesoninteroperabilitybetweendierentsubnets andusesDPWS to
integratedevies. SomeworkhasbeendonetointegrateDPWS intoOSGi. WhileUPnPsupporthasalready
beenstandardized within OSGi, todaysome initial work andproposalshave been doneto extendOSGi with
DPWS [35, 36℄. Fiehe et al. [36℄ desribe adistributed arhiteture whih uses DPWS to extend OSGi and
makeOSGi a distributed system. This approah is similar to atual work on distributed OSGiinside OSGi
initiative. However,there stillexiststhelakto integrateDPWSapabledevie intoOSGi.
LessworkhasbeendonetobringDPWSondeeplyembeddedsystemsandsensornetworksandespeially
real-time systems. With the new approah, presented in this paper, Web servies beome also available on
deeplyembeddeddevies. Both,deeply embeddeddevies anddeviesthat aremorepowerfulwillbeenabled
toommuniateandinteratwith eahother. Thissubstitutestheappliationlayerproxies.
Throughlinkingthedeviesto ahigherlevelofommuniation,devies nolongerrelyonspeitransfer
tehnologies like Ethernet. All devies in an infrastruture are onneted via servies. This servies based
arhitetureis alreadyused in upperlayers. Servies basedommuniationbeomes available onlowerlayers
nearestto thephysialtier. Thisallowsahigherabstrationlevelofproessstrutures. Therststeptoallow
thisisthereationofaSODAframeworkthat fulllstherequirementsofdeeplyembeddeddevies.
3. RequirementsforalightweightSODA. High-levelommuniationonresoureonstrained
embed-deddevies anresultin anoverallperformanedegradation. Inapreviouspaper[7℄Prueter et. alpresented
dierenthallengeswhihhavetobemetinordertorealizeDPWSommuniationwithreal-timeharateristis.
Firstly, as a basis an underlying real-time operating system must exist, ensuring the sheduling of the
dierent tasks in the right order and in spei time slots. Seondly, the physial network has to provide
real-timeharateristis. ThemajorhallengeinDPWSwithrespettotheunderlyingnetwork,isthebinding
of DPWS and SOAP. SOAP is bound to the Hypertext TransferProtool (HTTP) for transmission. HTTP
isbound to theTransmissionControlProtool(TCP) [10℄ (seeFigure 3.1). The TCP-standardinludes
non-deterministipartsonerningaresendalgorithminaseofanerror. Furthermore,theMediumAessControl
(MAC) to the physial tier has to grant aess to the data hannel for preditable time slots. Forexample,
Ethernetannotfulll thisrequirement.
AsshowninFigure3.1,itispossibletouseSOAP-over-UDP.ButinaordanetotheDPWSspeiation,
adevie mustsupportatleastoneHTTPinterfae[4℄.
In [7℄ Prueter et al. Xenomai [11℄ is used asoperating systemand RTNet [14℄ to grantnetwork aess
with real-time harateristis. RTNet relies on theUser DatagramProtool (UDP) insteadof TCPand uses
Time Division Multiple Aess (TDMA) for Medium Aess Control (MAC). The usage of UDP demands
SOAP-over-UDPat thesametime. Atleast twointerfaeshavetobeimplemented: A non real-time, DPWS
ompliantHTTP/TCPinterfaeandareal-time UDPinterfae. Thedisadvantageofusing aspeial network
stakinludingaspeialMAC,alsoimplies buildingupaseparatenetwork. Inthisnetwork,allpartiipating
noteshavetoonformtotheMACandusedprotools.
Fordeeplyembeddeddevies,variousreal-timeoperatingsystemsexist. FreeRTOS[21℄isaminireal-time
kernelfor misellaneous hardware platforms like ARM7, ARM9, AVR, x86, MSP430 et. Unfortunately, no
usefulreal-timenetworkstakandoperatingsystemombinationisurrentlyavailableforthesekindsofdeeply
embeddeddevies. Therefore,thispaperonentratesonthepossibilitiestoprovidereal-timeharateristisin
theupperlayersbeingonthetopofTCP/IP.
Thebinding of DPWS and TCP throughHTTP ausesdierenthallengesin grantingreal-time
TCP
UDP
IP
802.11, Ethernet, ZigBee
Physical Transmission
HTTP, HTTPS
DPWS
SOAP
Fig.3.1. DPWSprotoolstak
Application Data
XML
TCP
IP
Physical Transmission
(Ethernet, …)
process in
Network
Stack
Physical Network
Device A
HTTP
embed in
SOAP
Application Data
IP
Physical Transmission
(Ethernet, …)
parse out
Device B
extract out
UDP
XML
HTTP
TCP
UDP
Fig.3.2.Modulestobeimplemented
operatingsystemgrantsaesstoperipheriesforpreditabletimeslotsandexeutionoftasksintherightorder.
Thearisinghighlevelommuniationmaynotinterferewiththereal-timeproessontrolling. Theunderlying
real-time operating systemtakes are of orret thread management and orret sheduling of the real-time
and non real-time tasks. Tasks on the ontroller, ompeting with the ommuniation, are prioritized by the
operatingsystem.
InordertoprovideWebserviesonmiroontrollers,dierenthallengeshavetobemet. Figure3.2shows
thepartiularparts,whih havetoberealized.
3.1. NetworkStak. Thenetworkstak,responsiblefortherightaddressingandthewayofexhanging
data,istherstmodule,whihhavetoberealizedandmeettheresourerequirements. Dunkelshasdeveloped
uIP and lwIP, twostandard ompliantTCP/IP staks for 8 Bitontroller arhitetures ( [15, 16, 17℄). uIP
fullls all minimum requirements for TCP/IP data transmissions. The major fouses are minimal ode size,
memoryandomputingpowerusageontheontroller, withoutlosingstandardonformane. lwIP alsofullls
nonmandatoryfeaturesofTCP/IP.Bothimplementationsaredesignedtorunon8-bitarhitetureswithand
withoutanoperatingsystem. Thedierenesbetweenbothstaksareshownin thefollowingTable3.1.
DPWSbasesonWS-Disoveryforautomatidisoveryofdevies andisbasedonIP Multiast. Multiast
appliationsusetheonnetionlessandunreliableUserDatagramProtool(UDP)inordertoahievemultiast
ommuniations. uIP is able to send UDP Multiast messages, but is notable to join multiast groupsand
Table3.1
uIPvs. lwIP
Feature uIP lwIP
IPandTCPheksums X X
IPfragmentreassembly X
IP options X
Multiple Interfaes X
UDP X
MultipleTCPonnetions X X
VariableTCPMSS X X
RTTestimation X X
TCPowontrol X X
SlidingTCPwindow X
TCPongestionontrol Not needed X
Out-of-sequeneTCPdata X
TCPurgentdata X X
Databueredforrexmit X
theadvantagesof aompatible, lightweightnetwork stakand theusage of anembedded real-time operating
system.
3.2. SOAP. Upon the network stak, HTTP ommuniation protool is used for transport of uniast
messages. Thepayload is embedded in XML strutures and sent viaHTTP. All messagesutilize the POST
methodofHTTPforSOAPenvelopedelivery. MostaddressinginformationintheHTTPheaderisredundant
beause they are inluded in the SOAP message itself with a higher servie abstration. Signiant HTTP
headerinformationistheContent-LengthledtoidentifyendingofmessagesintheTCPdatastream. Beause
DPWSrequiresasmallpartof theHTTPfuntionalityonly,itis notneessaryto implementafull funtional
HTTPstak.
Inontrast,theXMLproessingandparsingdrawsmoreattention. Ondeeplyembeddeddevies,withonly
fewkBofmemory,theodesizeandtheRAMusagehavetoberedued. TheWS-DisoveryandWS-Metadata
messagesexeed the Maximum Transmission Unit (MTU) of mostnetwork tehnologies, inluding Ethernet.
ThissupportsthedeisionforlwIPinfavourofuIP.TheuIPimplementationonlyusesonesingleglobalbuer
forsendingandreeivingmessages. Theappliationrsthastoproessthemessageinthebuer,beforeitan
beoverwritten[17℄. InaseofaompleteXMLmessage,thewholelehastobeavailablebeforeausefulparsing
anbeproessed. Additional, omputingpoweris restritedtoresoureonstraineddevies. With respet to
theoverallperformaneoftheommuniationtask,itisdiulttoworkthroughandparsethewholemessage
asanestedXMLle. Therefore,ourresearhgrouphasdevelopedandimplementedanewapproahtohandle
HTTPandXMLanalysis. Thisnewapproahisdesribedinthenextsetion.
4. New TableDriven Approah. A ompleteimplementation ofSODAfordeeplyembeddedsystems,
likewireless sensor network nodes with limitedproessing powerand memory, is a signiant hallenge. All
modulesthatarementionedinsetionIIIlikenetworkstak,SOAP,HTTPandDPWShavetobeimplemented.
Due to dediated harateristisand funtionalities of sensors and ators in resoureonstraint
environ-ments, most of theexhangedinformation are disoverymessagesfor the lose oupling of thedevies during
run-timeand basiservieinvoationswith non-omplexdata types. Wehaveanalyzed dierentsetups with
DPWS ompliant implementations to identify whih parts of DPWS ould be omitted oradopted to redue
neessaryresoures. In mostsenarios,onlyfewtypesof messageshaveto beproessed. Afterdisoveryand
metadata exhange, the devies and their addresses areknown and the serviesan be invoked. Only a few
partshangewithintheexhangedmessages. Majorpartsofthemessagesstayunhanged. Everytimeaservie
isalled,almostthesamemessagehastobeparsedandalmostthesamemessagehastobebuild.
With allexhangedmessagesfrom theanalysis ofdierent senarios,tables anbe generated. The tables
ontainallappropriatedinomingandoutgoingmessages. Thenewimplementedtable drivenapproahisable
toresponse everyrequestbyreferringtothese tables.
PC
Firewire
Camera
Robot
Imageprocessing
Commandgeneration
Commands
Fig.5.1. MobileRobotSenario
ontainingtheservieinvoationsaresimplestrutured andthereisnoneedforomplexparsingofmessaging
inludinge.g. heavyweightXML namespae support. The messagesareinterpreted assimpletext messages
andnotasSOAPEnvelopesbeingembedded inHTTP.TherelevaneofthereeivedstringsfromHTTPand
SOAP protools are unknown forthe table driven devie. Certainly, thetable driven devie ananalyze the
inomingrequestsandlterrequiredinformation. Thedevieisabletosendspeiresponsewiththeorretly
adapteddynamihangingsetions. Theoverheadforparsingandbuildingalwaysthesamemessageisredued
bythisapproah. Therebymemoryusage andomputation timearedereasedin omparisonto atraditional
implementation.
With respet to a real-timeapable ommuniation,the treatmentof the messagesasstringsand notas
spei protools is signiant. The parsing as a string is independent of the depth of the nesting of XML
struturesanddenedbythelengthoftheSOAP-Envelopeonly. Theneessarytime, toparsethemessageas
astring,ispreditable. XMLShema,whihisrequiredbyDPWS,annotfullltheserequirementsbydefault.
5. Mobile Robot Senario. We veriedour solutionin areal worldsenario. An external PCand an
overhead ameraontrolateamofveautonomousrobots. Therobots areoordinated viaDPWS interfaes.
Therobotsreeiveommandsfromaentralserver. Theommandshavetobeexeutedinpreditedtimeslots
topreventollisionsandenableauratemovementoftherobots. ThewholesetupisshowninFigure5.1.
Theteambehavioroftherobotsisontrolledbyaentralserverwhihusesoneormoreamerasmounted
abovethe ground. Image proessing software on the PC extrats the position of all robots in the eld. On
thePCeventheommandsfortherobotsarealulated. Theseommandsonsistofglobaloordinatesofthe
robotpositionsandthetargetpositions. Theseommandsaresentwithahightransmissionratetotherobots.
The robots use global oordinates to update their own loal and impreise oordinate traking. The robots
needthisglobalupdatesinregularperiods, otherwiseaorretontrollingannotbegranted. Thesereal-time
requirementsforontrollingtherobotswithaparallelrunningommuniationsystemmaketherobotsenario
anidealtestbenh forourimplementations.
5.1. Robot Hardware. Toontrol therobots weuse twoontrollerboardsalternatively: anembedded
LinuxboardandanARM7ontrollerboard. TheembeddedLinuxboardistheCoolMoteMaster(CMM)from
LiPPERT.It isequippedwithanAMDAlhemyAU 1550proessor[19℄. Thisboard isdesignedasagateway
node for sensor networks. The CMM is already equipped with an 802.15.4 omplianttranseiver. We have
extendedtheboardwithadditionalBluetoothandWi-Fi(IEEE 802.11)interfaes[20℄. Thereby,theboardhas
threedierentradiotehnologiesfornetworkingbesideEthernet.
TheARM7boardisaSAM7-EX256evaluationboardfromOlimex[23℄. ThisboardisappliedwithanAtmel
ARM7 ontrollerwith 256kB memory and 64 kB RAM. The board already provides an Ethernet interfae,
whihwasusedfortesting. Theontrollerisrunningwithalokrateof55MHz. Itispossibletoshedulethe
lwIPstakandtheimplementedtabledrivendevieindierentprioritized taskswiththehelp ofFreeRTOS.
TheimplementationsareevaluatedonastandardPCandontheseboards. An overviewofusedhardware
isprovidedin Table5.1. Thenetworkdeviesareongured inaway,thatallofthemanhandle IPtra.
soft-Table5.1
Usedhardwarefortestingthenewtabledrivenapproah
x86PC CMM SAM-7
CPU IntelPentium4 AlhemyAU1550 AtmelARM7
ClokRate 3,4GHz 500MHz 55MHz
ROM 500GB 512MB 256kB
RAM 1024 MB 256MB 64kB
OperatingSystem Linux(2.6.24/Ubuntu) Linux(2.6.17/Debian) FreeRTOS5.0
Networkinterfaes Ethernet Ethernet,802.11g, Ethernet
802.15.4, Bluetooth
DPWS.ThistoolkitusesgSOAP[22℄forSOAPfuntionalitiesandextendsgSOAPwithanimplementationof
theDPWS speiation. Thistraditionalimplementationwill beusedasbenhmarkforthenewtable driven
approah.
Intherststepaservieisreatedwiththeexisting WS4D toolkitthatprovidesallneessaryommands
fortherobotsin ourmobilerobotsenario. TheexternalPCallsahostedservieontherobots. Theservie
isalled everytimewhennewommandshavetobesend totherobots. Thenewommandsareembeddedin
therequest. Theservieanswerswitharesponse,inludingaperformaneparameteroftherobot.
Intheseondstep,theexhangedmessagesareanalyzedaordingtotheDPWSspeiation. Allpossible
outgoingand inomingmessagesfor themobile robot senarioare generated. In thethird step, aompletely
newDPWS devieis implemented. Thestruturesand ontentsofthe possiblemessagesaredepositedin the
newimplementeddevieasstrings. ThisdeviedoesnotsupportanydynamiSOAPorHTTPfuntionalities.
The new table driven approah does not parse the whole inoming message as XML le. Every reeived
messageisanalyzedwithanelementarystringompare. Therebythetypeofthemessageisguredout. Ifthe
messagetypeis known,the devie answerswiththe relatedmessage. Theansweris alreadydeposited in the
implementeddevie asa stringalso. In the answer, only parts required by theDPWS speiation and the
payload arehanged. With respettoavailableresouresofthetargethardwareplatform,theimplementation
anbeoptimizedonerningtheFlashandRAMmemoryusage. Ontheonehand,thegeneratedtablesanbe
loadedinRAMatstarttimeofthebinary. Thisrequiresmoreavailablemainmemory,butanfastenthedata
aessduringruntime. Ontheotherhand,thegeneratedtablesanalsobestoredinnon-volatilememorylike
Flash. Thisreduesfootprintofthebinarybutmayausehigherexeutiontimesduringservieinvoationand
messageproessing. To meetreal-time requirements,the hoie between both optionsorrelatesto real-time
featuresoftheunderlyingmanagementofvolatileandnon-volatilememoryaess.
Duringthe implementation of the table driven devie, wehave takenare that system funtions are not
alledin ritialsetions. Forexample,themainmemorymanagementisprovidedbythetaskitself. Thetask
alloatesapoolofmain memorywhen itisstarted andthenorganizes themain memoryitself. Furthermore,
thedierentthreadsforthenetworkstakandthethreadshandlingthemessagesareanalyzedtobesheduled
intherightorderandwithorretpriorities.
6.1. Message Exhange. Figure 6.1givesanoverviewof exhangedmessagesin the mobile robot
se-nario. When startingthedevie, itannounesitself with aHelloSOAP Envelope. Within this messageonly
theMessageID and thetransport spei address,are dynamiallyand has to be adapted. Furthermore,the
MessageNumberandtheInstaneIDhastobeorret.
Whena lient wasnotstarted, asthedevie announes itself with a Hello, thelientasks witha Probe
for available devies. Theansweris aProbe Math, where the RelatesTohas to t to the MessageIDof the
Probe and the MessageIDhas to bedynami. Here,also the MessageNumberand theInstaneID hasto be
inremented.
Whenthedeviesandtheiraddressesareknown,thelientwillaskforthehostedserviesonthedeviein
thenextstep. Therefore,aGetMetadataDevieissendtothehostingservie,whihisatleastahostedservie
that announesrepresentativetheavailable hostedservies. TheGetMetadatamessageistherstonethat is
sentviaHTTP.WithintheHTTPheader,theContent-Lengthheadereld,thelengthofthemessage,andtheIP
addresshastobeadopted. Theaddressonlyhastobehanged,ifitwasnotknownatompiletime. Thisapplies
toallIPaddressesinthesenario. IntheGetMetadataDeviemessageSOAP-Envelope,theToXMLtaghasto
(6)
S
e
rvi
c
e
U
s
e
r
/
C
lie
n
t
S
e
rvi
c
e
P
ro
vi
d
e
r
/
D
e
v
ic
e
Hello
Probe
HTTP/TCP - GetMetadata Device
HTTP/TCP - GetMetadata Service
HTTP/TCP - GetMetadata Device Response
HTTP/TCP - GetMetadata Service Response
HTTP/TCP - Service Usage Request
HTTP/TCP - Service Usage Response
. . .
UDP Unicast Probe Match
UDP Multicast
239.255.255.250
(1)
Resolve
UDP Unicast Resolve Match
UDP Multicast
(2)
(3)
(4)
(5)
Bye
UDP Multicast
Fig.6.1. MessageExhange
Whenthelientknowsavailablehosted servies,the spei hosted servie,that the lientis looking for,
isaskedfortheusageinterfaewithaGetMetadataServie. TheGetMetadataServieResponse refersto the
GetMetadataServiethroughtheRelatesToXMLtag.
Afterthemetadataexhangeisomplete,thelientknowshowtointeratwiththespeiservieandthe
servieusagestarts. Thelientinvokestheserviewithamessage,whereToandMessageIDhastobeorret.
IntheServieUsageRequest,theoordinatesofthemobilerobotsenarioareintegrated. Theservieanswers
with the Servie Usage Response. Therein, the referene to the request is given through the RelatesTo tag.
Inour speial mobile robot senario,the response also ontains theProessingTime tag. In this setion, the
servieinformstheservieuseraboutthetime, theappliationneeds toproessthe newoordinatesand isa
performaneparameterforthemobile robot.
An overviewaboutthedynami parts of thedierentmessagesis givenin Table6.1. The overall size for
theexhangedmessagesis12.839Bytes. TheoverallnumberofBytesthatanhangeis588. Only4.6%ofthe
overall exhangedbytesaredynamiinthemobilerobot senario.
6.2. Devies Footprint. The memory optimized WS4D toolkit implementation of the DPWS devie
needs360kBofdiskspaewhenompiledforLinuxonax86arhiteture. Thetable drivendevie
implemen-tationhasa16kBfootprintwhenompiledfor astandardx86PCrunningwithLinux. Bothversionsdonot
ontain networking staksin these x86 implementations. Both implementations for anx86 PC running with
LinuxareusingtheBSDSoketAPIandorrespondingnetworkstaksinludedinLinuxtohandlethenetwork
tra. Thesameimplementationofthenewtable drivenapproahportedtotheSAM7-EX256boardrunning
withFreeRTOS5.0 hasa13 kBfootprint withoutnetwork stakand interfae drivers. Asnetwork stak the
independentlwIPstakinVersion1.3isappliedtotheboard. Therefore,thestakwasportedtoFreeRTOS5.0.
The required disk spae for the dierent parts on the SAM7 board is shown in Table 6.2. The overall
memorybeingusedontheboard,inludingFreeRTOS,lwIP andthedevie needs146kB.
The heap and stak usages of both implementations are given in Table 6.3. The maximum stak and
heapusageofthetable drivenapproahismuhlower,beauseexhangedmessagesandtheirsizesareknown
at ompile-time and no non-required memory has to be alloated during run-time. Due to thesoft resoure
requirementsofthe usedhardwareplatforms,theimplementationof thetable drivenapproah isstill notfull
optimizedonerningheapand sakusage. Itdependson thespei senario,ifthemessagetables arekept
intoRAMduringrun-timeorareloadedseparatelyintoRAMfromnon-volatilememorylikeashondemand.
Keepingtheontentsofthetablesinashreduesheapandstakusage,butmayauseagaininrespondstime
duetohigheraesstimetoashomparedtoRAM.Forhighlyenergyonstraineddevieswithashmemory
fordatastorageonexternalhardwaremodules,swappingthetablestoashanhaveaninueneontheoverall
poweronsumption also. Theash hardware omponent anbeswithed of whilekeepingthetables without
Table6.1
OverviewExhangedMessages
MessageType Changing parts Dynami Bytes
Hello MessageID 36
XAddrs (IP) max. 17
AppSequene MessageNumber approx. 2
AppSequeneInstaneId 10
Probe MessageID 36
ProbeMath MessageID 36
RelatesTo 36
AppSequene MessageNumber approx. 2
AppSequeneInstaneId 10
GetMetadaDevie HTTPContent-Length max. 5
HTTPHost 175,max. .f.[10℄
MessageID 36
To 36
GetMetadataDevieResponse HTTPContent-Length max. 5
RelatesTo 36
Address 175,max. .f.[10℄
GetMetadataServie HTTPContent-Length max. 5
HTTPHost 175,max. .f.[10℄
MessageID 36
To 175,max. .f.[10℄
GetMetadataServieResponse HTTPContent-Length max. 5
RelatesTo 36
ServieInvoationRequest HTTPContent-Length max. 5
HTTPHost 175,max. .f.[10℄
MessageID 36
To 36
Payload 16
ServieInvoationResponse HTTPContent-Length max. 5
RelatesTo 36
Payload 3
Table6.2
FootprintofSAM7ImplementationwithFreeRTOSandlwIP
Module Footprint
statiDPWSdevie 13kB
lwIP1.3 77kB
FreeRTOSinludingDebugTasks 56kB
andontentarekeptintoRAMwithlowaesstimesandnoadditionalenergyonsumption, whileinfrequent
usedtablesarekeptintoashtoredueheapandstakusagewhilerun-time.
6.3. Time Responds. Also some timing measurements have been done in order to have an objetive
omparison for the newstati approah. Therefore, the round trip time wasmeasured that is requiredfrom
sendingthemessagetoreeivingtheresponseonthelientside. Throughthismethodtheoverallperformane
andthemaximumnumberofservieinvoationsperseondanbedeterminedwhih anbeserved.
These measurementsaredoneforastandardx86 PCandtheSAM7board. Onbothdevies a100MB/s
Ethernetinterfaeisapplied,whihhasbeenusedforthemeasurements. OntheSAM7boards,anindependent
thread simulated anadditional CPUload. This CPU loadthread wassheduledwith dierentpriorities. As
requestinglientastandardPC(2x3,5GHzwith1GBRAM)wasusedinallases.
RoundTripTimeandMemoryUsage
Devie RoundTripTime Requestsperse MaxHeapUsage MaxStakusage
x86PC 1,05ms 952 112,76Bytes 97,64Bytes
WS4Dtoolkit
x86PC 0,9 ms 1111 8,928Bytes 15,324Bytes
TableDrivenDPWS
SAM7-EX256 18,6ms 53 N.A. N.A.
TableDrivenDPWS
SAM7-EX256 18,6ms 53 N.A. N.A.
TableDrivenDPWS
SAM7-EX256 30,2ms 33 N.A. N.A.
TableDrivenDPWS
OnthePC,thenewimplementedapproahprovidesafasteroverallproessing. Thetimerespondsonthe
real-timeoperatingsystemoftheSAM7board,dependongivenprioritiesforthedierentompetingtasks. As
longasthe CPU loadtaskhas alowerpriority thanthe DPWS and thelwIP tasks, noeet to theaverage
timesouldbemeasured.
7. Message struture optimizations. All messagesin DPWS makeuse of XML for data
representa-tion. Theappliation of XMLin DPWSand WebServies hasmultiple advantagesonsidering independeny
of programminglanguage,operatingsystem, ommuniationhannel, data representation, and harater set.
Certainly, XML implies amessage overhead. Hene, this subsetion desribesseveral onepts for optimized
dataenodingsofSOAPmessages.
FastWebServies[30℄areusingASNtoompresstheXMLlesintoaresoureoptimizedbinary
represen-tationandto overomeperformaneissuesfor omplexstringoperationsin messageproessing. Sandozet al.
developedasolutiontoonvertWebServiesspeiXMLShemaintoASN.Theproposedapproahredues
thesize of the XML databy morethan fatorfour and performaneis nearly 10 timesthat ofXML literal.
Inotherwords,FastWeb Servieswill performbetterasthesize oftheontentinreases." Nevertheless,this
approahleadstoisolatedappliationsandisinompatiblewithDPWSdeviesandlientsthatdonotsupport
theASNdatarepresentation.
The Eient XML Interhange Working Group [29℄ develops anenoding format for XML, that allows
eient interhangeof the XML Information Setand allows eetiveproessorimplementations". Themain
fous ishigh data ompression evenof big anddeep struturesompletely ompliantto XML. Analyseshave
shownthatthebinarydoumentsanbeupto 90%smallerthantheoriginalXMLdoument.
Inomparisonto EientXML andFast WebServies, A-SOAP[31℄ desribesoneptsforXML
enod-ing, whih an be easily implemented in hardware and thereby muh more energy eient then in software.
Additionally, thisapproahprovidesreal-timeparsingharateristis.
A-SOAP (AdaptiveSOAP)uses hash funtions,to enapsulate omplexXML strutures. Constantly
re-urrentXMLstruturesarerepresentedbyhash values(seeexampleinFigure 7.1). Forthetransmissiononly
hangingparts ofthe XMLles aretransmitted asproperXMLtags. All tagsknown bysenderand reeiver
aretransmittedbyusinghash values. EspeiallyA-SOAP anbeintegratedin DPWS andassureompliane
to lients and devies whih not support A-SOAP. An endpoint that annot understand a SOAP message,
respondswith aSOAP Faultmessage. Intheasewhen anendpointis notA-SOAPenabled,the overhead is
oneadditionalrequest and oneadditional SOAP Fault. The senderthen has to retransmit the messageasa
ompliant XMLmessage. Certainly, this generiA-SOAPsupportdetetion mehanismis ompletelyDPWS
ompliant.
A-SOAP is aproperaddition to the table driven approah. The ontents of thegenerated tables anbe
attahedtohashvaluesforidentiation. Nottheontentshavetobetransmittedbutonlythedediatedhash
values. Ontheonehand,thisreduesparsingeortsashashvaluesanbeparsedin hardwareandinsoftware
fastandeasily. Ontheotherhand,theintegrationoftheA-SOAPapproahintoolkitsfortheimplementationof
thetabledrivenapproahreduesfootprintsandmemoryonsumptionsigniantly. Ifpossibleommuniation
Hash Table:
1:<soapenv:Envelope...>
2:<soapenv:Body>
21:<ns1:add…>
22:<ns1:in0>
VALUE A
19:</ns1:in0>
0:<ns1:in1>
VALUE B
20:</ns1:in1>
3:</ns1:add>
4:</soapenv:Body>
5:</soapenv:Envelope>
Hash Table:
1:<soapenv:Envelope...>
2:<soapenv:Body>
21:<ns1:add…>
22:<ns1:in0>
VALUE A
19:</ns1:in0>
0:<ns1:in1>
VALUE B
20:</ns1:in1>
3:</ns1:add>
4:</soapenv:Body>
5:</soapenv:Envelope>
Device A
Device B
Fig.7.1.A-SOAP
theassoiatedhashvalueshavetobeinluded. Thisresultsin real-timeDPWSbasedommuniationevenfor
highlyresoureonstrainedplatforms.
ThedisadvantageofA-SAOPisthat it reentlywasgrantedaspatent. Hene,there is noproposalfora
dataompressiontoapplyDPWS inWSNW.
8. Conlusion. The new table driven approah allows the usage of Web servies on deeply embedded
devies. Furthermore,theimplemented serviesangrantreal-time apabilities. Thus, the deeplyembedded
deviesanbeintegratedinenterpriseserviestrutures. Thereatedservieinterfaesanbereusedindierent
appliation. Theonnetivitybetweensuhlargenumbersofembeddeddeviesnormallyneedsproxyonepts
with stati strutures. Now, these proxies are no longer required. The devies an be diretly aessed by
a high level proess logi. Furthermore, the validation and ertiation beome heaper beause of the slim
implementationandreusabilityoftheinterfaes.
Themeasurementsshowthatthebinarysize ofadevieanbereduedbythefatorofmorethan20. At
thesametime,thetimerespondsanbeimproved. Heapandstakusagesdonotdependonspeidependent
valuesbutonspeimessageexhangepatternsofdediatedsenariosThroughtheimplementationindierent
threads,thetimerespondsofthenewimplementedstatiapproahisindependentfromotherompetingtasks.
However,thisassumesanunderlyingreal-timeoperatingsystem.
Further optimizationof thefootprintanddynami memoryusageare amainfouses forthefuture work.
Future work will also researh on a ompletely speiation ompliant implementation inluding optimized
messagestruturingforreal-timeparsing.
REFERENCES
[1℄ W.Dostal,M.Jekle,I.Melzer,andB.Zengler,ServieorientierteArhitekturenmitWebServies,Elsevier,(2005).
[2℄ ElmarZeeb,AndreasBobek, HendrikBohn,FrankGolatowski,Servie-OrientedArhiteturesforEmbedded
Sys-temsUsingDevies Prole forWebServies,2nd International IEEE Workshop on ServieOriented Arhitetures in
ConvergingNetworkedEnvironments(SOCNE2007),(2007),NiagaraFalls,Ontario,Canada,pages956963.
[3℄ Maro Sgroi, Adam Wolisz, Alberto Sangiovanni-Vinentelliand Jan M. Rabaey, AServie-Based Universal
Appliation InterfaeforAd-hoWirelessSensorNetworks(Draft),Unpublishedartile,(2003).
[4℄ MirosoftCorporation,DPWSSpeiation,TehnialReport,http://spes.xmlsoap.org/ws/2006/02/devprof, (2006).
[5℄ OASIS,WebServiesDisoveryandWebServiesDeviesProle(WS-DD)TC,TehnialReport,http://www.oasisopen.
org/ommittees/ws-dd/,(2009).
[6℄ WorldWideWebConsortium,WebServiesEventing(WS-Eventing)Submission,Tehnialreport,http://www.w3.org/
Submission/WS-Eventing/,(2006).
[7℄ SteffenPrueter,GuidoMoritz,ElmarZeeb,RalfSalomon,FrankGolatowski,DirkTimmermann,Appliability
of WebServieTehnologies toReah Real TimeCapabilities, 11th IEEE Symposiumon ObjetOriented Real-Time
DistributedComputing(ISORC),(2008),Orlando,Florida,USA,pages229-233.
[8℄ UniversityofRostok,DPWS-StakWS4D,Tehnialreport,http://ws4d.org,(2009).
[9℄ ShneiderEletri,SOA4DForge,Tehnialreport,https://forge.soa4d.org/, (2009).
[10℄ InternetEngineeringTaskFore,HypertextTransferProtoolHTTP/1.1[RFC2616℄,Tehnialreport,http://tools.
[12℄ World Wide Web Consortium,SimpleObjet Aess ProtoolSpeiation, Tehnialreport,http://www.w3.org/TR/
soap/,(2008).
[13℄ World Wide Web Consortium, Web Servie Arhiteture Speiation, Tehnial report, http://www.w3.org/TR/
ws-arh/,(2007).
[14℄ Kiszka, J. and Wagner, B. and Zhang, Y. and Broenink, J.F., RTnet - A exible Hard Real-Time Networking
Framework,10th IEEEInternational ConfereneonEmergingTehnologiesand FatoryAutomationVolume1,(2005)
Catania,Italy,page8.
[15℄ Adam Dunkels, Full TCP/IP for 8-Bit Arhitetures, International Conferene On Mobile Systems, Appliations And
Servies,(2003),SanFraniso,California,pages85-98.
[16℄ AdamDunkels,uIP,Tehnialreport,http://www.sis.se/~adam/uip/,(2007).
[17℄ AdamDunkels,lwIPALightweightTCP/IPstak,Tehnialreport,http://savannah.nongnu.org/projet s/lwip/,(2008).
[18℄ AdamDunkels,TheuIPEmbeddedTCP/IPStak,TheuIP1.0RefereneManual,Tehnialreport,(2006).
[19℄ LiPPERT:PCsolutionsforruggedindustrialappliations,CoolMoteMasterBoard,Tehnialreport,http://www.
lippert-at.om/, (2008).
[20℄ ThorstenShulz,EvaluierungvershiedenerProzessorloesungen fuerRoboCupRoboter,Tehnialreport,(2006).
[21℄ FreeRTOSTheStandardSolutionForSmallEmbeddedSystems,http://www.freertos.org,(2008).
[22℄ Robert A. van Engelen, Kyle A. Gallivany, The gSOAP Toolkit for Web Servies and Peer-To-Peer Computing
Networks,2ndIEEE/ACMInternationalSymposiumonClusterComputingandtheGrid(CCGRID),(2002)Washington,
DC,USA,page128.
[23℄ Olimex,SAM7-EX256EvaluationBoard,Tehnialreport,http://www.olimex.om/dev,(2008).
[24℄ S.Karnouskos,O.Baeker,L.Moreira,S.deSouza,P.Spieÿ,IntegrationofSOA-readynetworkedembeddeddevies
in enterprise systems via a ross-layered web servieinfrastruture, Emerging Tehnologiesand Fatory Automation
(ETFA),(2007)Patras,Greee,pages293-300.
[25℄ Sottde Deugd, RandyCarroll, KevinE. Kelly,Bill Millett,andJeffreyRiker,SODA:Servie-Oriented
DevieArhiteture,IEEEPervasiveComputing,(2006),vol.5,no.3,pages94C3.
[26℄ H.Bohn, A.Bobek, andF.Golatowski,SIRENA-ServieInfrastrutureforRealtimeEmbedded Networked Devies:
Aservieorientedframeworkfordierentdomains,InternationalConfereneonSystemsandInternational Conferene
onMobileCommuniationsandLearningTehnologies(ICNICONSMCL'06),(2006),Washington,DC,USA,page43.
[27℄ ElmarZeeb, Steffen Prueter, Frank Golatowski, Frank Berger,Aontext awareservie-oriented maintenane
systemfortheB2Bsetor,3rdInternationalIEEEWorkshoponServieOrientedArhiteturesinConvergingNetworked
Environments(SOCNE2008),(2008)Ginowan,Okinawa,Japan,pages13811386.
[28℄ Intel,UPnP -Tehnology Overview, Tehnial report, http://www.intel.om/d/ids/developer/asmo-na/eng/downloads/
upnp/overview/, (2008).
[29℄ W3C,EientXMLInterhangeWorkingGroup,Tehnialreport,http://www.w3.org/XML/EXI/,(2009).
[30℄ Sandoz,P., Perias-Geertsen, S., Kawaguhi,K., Hadley, M.,Pelegri-Llopart, E.,FastWebServies,Artile,
(2003).
[31℄ Rosu, M.-C., A-SOAP: Adaptive SOAP Message Proessing and Compression, IEEE International Conferene on Web
Servies(ICWS2007),(2007)SaltLakeCity,Utah,USA,pp.200-207.
[32℄ Christian Bukl, Stephan Sommer, Andreas Sholz, Alois Knoll, Alfons Kemper, Joerg Heuer, Anton
Shmitt, Servies to theField: An Approah for Resoure Constrained Sensor/Ator Networks, International
Con-fereneonAdvanedInformationNetworkingandAppliationsWorkshops(AINAW2009),(2009)pp.476481.
[33℄ Daniel Barisi, MartinKrogmann, Guido Stromberg, Peter Shramm, MakingEmbedded Software Development
MoreEientwith SOA,21stInternational Confereneon AdvanedInformationNetworkingandAppliations
Work-shops(AINAW2007),(2007)vol.1,pp.941946.
[34℄ Hyung-JunYim, Il-Jin Oh, Yun-Young Hwang, Kyu-Chul Lee, KanghanLee, and Seungyun Lee, Designof
DPWSAdaptorforInteroperabilitybetweenWebServiesandDPWSinWebServiesonUniversalNetworks,
Interna-tionalConfereneonConvergeneInformationTehnology(ICCIT2007),(2007)pp.10321039.
[35℄ AndréBottaro,Anne Gérodolle,SylvainMarié, StéphaneSeyvoz,Eri Simon,RFP86DPWS DisoveryBase
Driver,OSGiAlliane,(2007).
[36℄ A. Bottaro and A. Gérodolle, Home SOA:faing protool heterogeneity in pervasiveappliations, 5th international
ConfereneonPervasiveServies(ICPS2008),(2008)ACM,NewYork,NY,pp.7380.
[37℄ ChristophFiehe, AnnaLitvina, Ingo Luek, OliverDohndorf, JensKattwinkel,Franz-JosefStewing, Jan
Krueger,HeikoKrumm,Loation-Transparent IntegrationofDistributedOSGiFrameworksandWebServies,
Inter-nationalConfereneonAdvanedInformationNetworkingandAppliationsWorkshops,(2009)pp.464469.
Editedby: JanuszZalewski
Reeived: September30,2009