Building automation and smart cities: An integrationapproach based on a service-oriented architecture

Markus Jung, Jurgen Weidinger, Wolfgang KastnerInstitute of Computer Aided Automation

Vienna University of TechnologyVienna, Austria

Email: {mjung,jweidinger,k}@auto.tuwien.ac.at

Alex OlivieriL’Institut Informatique de Gestion

Haute Ecole Specialisee de Suisse OccidentaleSierre, Switzerland

Email: alex.olivieri@hevs.ch

Abstract—Building automation is a vital part of many usecases related to energy efficiency and smart living in the contextof smart cities. State of the art building automation systems likeKNX, BACnet or ZigBee are based on control networks mainlyused for local control scenarios using non-IP communications.This paper presents an integration approach for building automa-tion systems using an IPv6 enabled service-oriented architectureallowing interconnecting heterogeneous technologies into a large-scale distributed control system. Details on the concept, a proof ofconcept implementation and performance evaluation results of amulti-protocol gateway are presented, offering a per-device IPv6interface using a novel CoAP/EXI protocol binding for oBIX.The integration approach aims at providing a homogeneousintegration layer that can be used to build advanced controlscenarios that might arise in the context of smart cities.

Index Terms—Internet of Things; IPv6; Home Automation;Web services

I. INTRODUCTION

The continuous trend towards more urbanization puts anextraordinary stress on the infrastructures of cities. A smartcity aims at increasing the effectiveness and efficiency ofpublic transport, energy and water supply, healthcare, publicsafety to government services by integrating various systemsout of these domains using information and communicationtechnology (ICT) [1]. Without question, buildings and res-idential homes will be a vital part of such a smart city”system of systems” as they are central energy consumersand living and working area of the city residents. State ofthe art building automation systems (BAS), such as BACnet,KNX, ZigBee or Wireless M-Bus, usually come with a customprotocol stack and use non-IP communication. The challengeof integrating a variety of sensing infrastructures and differenttechnologies for smart cities is already stated in [2]. Withinthe domain of home and building automation, integrationapproaches like oBIX, OPC UA or BACnet/WS address thisproblem by providing a centralized Web service interface atthe management tier of a typical BAS. They provide eithera RESTful Web service interface based on HTTP or use theWS-* stack based on SOAP for interfacing the underlyingtechnology. For message encoding, mainly XML is used whichis a convenient representation of information for humans andprovides interoperability for every type of system.

However, these technologies based on TCP, HTTP and

XML come at the cost of huge resource demands in thesense of computational power, memory and message size.Devices that implement such a stack are multiple times moreexpensive than equivalent devices using non-IP technologies.In order to reduce this efficiency gap, the IETF workinggroup on Constrained RESTful Environments (CoRE) workson the standardization of the Constrained Application Pro-tocol (CoAP) [3] which is a UDP based protocol providingequivalent features to HTTP. Due to the usage of UDP,it provides non-confirmed messaging, group communicationand asynchronous communication capabilities which togethermake CoAP more efficient and powerful compared to HTTP.CoAP can thus be used to realize RESTful Web services onconstrained devices. In combination with 6LoWPAN [4], itis also possible to efficiently use IPv6 as network layer forwireless sensor networks. 6LoWPAN and CoAP support anefficient deployment of protocol stacks with a Web serviceinterface directly accessible via IPv6 addresses of constraineddevices. Finally, for the message encoding, efficient XMLinterchange (EXI) [5] provides a standardized binary represen-tation of XML data which completes the optimizations towardsusing Web services on embedded devices [6], [7]. Altogether,this allows to build an Internet of Things (IoT) based on theInternet as communication infrastructure.

Where CoAP, EXI and IPv6 may be the technology stackfor future sensors and actuators, within smart cities millionsof existing sensors and actuators already deployed need to beintegrated. Therefore, this paper presents how an IPv6 multi-protocol gateway [8], [9], [10] can be used to integrate existingBAS technologies into an IPv6 service-oriented architecturebased on oBIX using a novel CoAP protocol binding. Theapproach allows integrating BAS into an IoT that can be usedin the context of smart cities. The gateway provides an IPv6per-device CoAP RESTful Web service for each technologythat resides behind the gateway as illustrated in Figure 1.By means of this uniform interface, it is possible to deploycontrol logic that spans geographically large distributed controlsystems consisting of heterogeneous technologies.

The paper is structured in the following way. Section IIlists the relevant related work. Next, Section III provides anoverview of the used protocol stack. A brief overview over theCoRE technologies is given and described how oBIX can be

Server

Server

Node

Internet (IPv6)

HTTP

Proxy

Server

Constrained Environments

C

REST

HTTP

CoAP

C

C

C

CoAP

CoAP

CoAP

IPv6 multi-protocol gateway IPv6 multi-protocol gateway

KNX network BACnet network

KNX

KNX KNX

KNX

KNX

PLC

C C C C C

BACnet

BACnet

BACnet

C C C

CoAPCoAP

HTTP

ZigBee network

ZigBee

wM-Bus

ZigBee

C C C

Fig. 1. Extending the CoRE architecture [11] transparently with BAS

combined with CoRE at the application layer. Furthermore,a CoAP and EXI protocol binding for oBIX are presentedmaking the centralized state of the art oBIX Web servicesmore efficient. The architecture and design of the gatewayare discussed in Section IV where also details on the usedsoftware packages for the implementation are given. Differentinteraction scenarios between legacy devices are presentedin Section VI. Finally, evaluation results are outlined andcompared to state of the art oBIX interfaces regarding messagesize and necessary costs for additional CPU demands.

II. RELATED WORK

The feasibility using service-oriented architectures ap-proaches in ubiquitous computing, especially in the domain ofhome automation, is explored in [12]. There, SOAP based Webservices and a communication stack using HTTP, SOAP, WS-Agreement, WS-QoS, WS-Security, WSDL, WS-Policy, UDDIand WS-Notification are discussed. The authors propose toequip all devices with sufficient computational power in orderto host an implementation of such a complex communicationstack. Although hardware resources are getting cheaper it isstill a question to use such devices in automation systems.Constrained RESTful environments provide a simpler commu-nication stack that comes with fewer features but is feasible tobe deployed on the most constrained devices. Therefore, thispaper targets the seamless integration of existing devices intoCoRE instead of heavy-weight WS-* based communicationstacks.

In [13], the heterogeneity of devices is addressed througha generic communication interface for DPWS-based Web ser-vices. We identify this approach as too heavy-weight and theproposed communication interface as too generic compared tothe semantic abstraction of common oBIX objects proposedin our paper.

A thin server architecture based on RESTful Web service in-terfaces and a reference implementation of CoAP are presentedin [14]. There, the authors describe how application logic canbe moved to the cloud through the usage of RESTful Webservices on constrained devices using 6LoWPAN as efficientadaption layer between the network and data link layer ofwireless networks in order to provide IPv6 connectivity for enddevices. Based on this concept, the authors present in [15] acontainer for scriptable control and monitoring logic using anenvironment for JavaScript. In this paper, we use Java applica-tions for deploying control and monitoring logic. Furthermore,the standard IoT oBIX contracts presented in our work allowclient applications to take advantage of the enriched semanticsand offer the possibility for specific monitoring and controllogic interfaces for the device types.

The challenge of heterogeneous sensor infrastructures andthe requirement for a homogeneous interface are presentedin [2]. The authors depict an architecture based on an ab-straction layer using a distributed database scheme, a RESTAPI and XML models aligned to the Sensor Web Enablement(SWE) standard defined by the Open Geospatial Consortium.Although a distributed database scheme is used, the RESTAPI provides a central interface for applications. In our work,we follow a more decentralized approach with an interface forsensors and actuators based on a per-device IPv6 address anda CoAP based Web service interface in mind.

III. PROTOCOL STACK

The multi-protocol gateway provides a uniform interfacefor all technologies behind the gateway based on the protocolstack illustrated in Figure 2. This stack may also be directlydeployed on embedded devices.

oBIX

Existing Binding

IoT contracts

New Binding

New/Modified

IEEE 802.15.4IEEE 802.3 Ethernet

Other links6LoWPAN

IPv6

UDP TCP

HTTP ExistingCoAP

IPv6 multi-protocol gateway stack

JSON, EXI

SOAP

JSON, EXI

New Binding

XML oBIX binary

Fig. 2. IPv6 multi-protocol gateway stack

On top of the protocol stack, oBIX is used as applicationlayer protocol since CoAP does not provide the requiredfeatures to map all the application layer functionalities ofexisting BAS.

With oBIX, an information model is delivered representingdevices and entities out of the domain of building automation

as oBIX objects. Further a simple protocol aligned to RESTfulinteraction is offered. The functionality includes interaction toquery and modify objects and to invoke oBIX operations. Tothis end, three protocol services are offered (read, writeand invoke) that are mapped to the HTTP and CoAPverbs get, put and post. The oBIX object model (seeFigure 3) follows the typical approach of representing alldevices as objects holding collections and references to otherobjects and collections of data points with a specified datatype. oBIX uses the concept of contracts to define certainobject types. Currently, 17 standard object types are defined,ranging from basic data items like bool, int, real andstr over to more complex object types. oBIX contracts alsoprovide semantics for standard device types. Special contractsfor observing resources, alarms and histories based on theobject contracts for watches, alarms and histories aresupported.

The semantic description of oBIX contracts is only intendedfor human beings but not usable for machine based semanticprocessing. In this regard, it can be compared to functionblocks of BAS that describe standardized behaviors of sensors,actuators and control devices and define the semantics of inputand output data points of devices that implement the functionblocks.

obj

name: str href: uri is: contract null: bool icon: url displayName: str display: str writable: bool status: status

val

val: <type>

list

of: contract min: int max: int

op

in: contract out: contract

feed

in: contract out: contract

ref err

bool

range: uri

int

min: int max: int uint: int

real

min: real max: real uint: uri precision: int

str

min: int max: int

enum

range: uri

uri

abstime

min: abstime max: abstime uint: str

reltime

min: reltime max: reltime

date

min: date max: date tz: str

time

min: time max: time tz: str

Fig. 3. oBIX object model [16]

oBIX defines a protocol binding to HTTP for messageencoding (XML or custom binary representation). For messageexchange, the gateway offers either HTTP or CoAP. Both arein general quite similar, but HTTP uses TCP as underlyingtransport layer protocol. This provides reliability but limitsthe communication to a connection oriented point-to-point

communication and can be considered as heavy-weight com-munication protocol for sensor networks regarding bandwidthand computational resources of nodes.

Furthermore, HTTP only allows a request/response interac-tion using a client/server communication model. In contrastto that, CoAP uses UDP as transport layer. This providesunreliable packet-oriented communication with group commu-nication and asynchronous interaction within the client/servercommunication model. Due to these differences, CoAP addsfacilities for non-confirmed and confirmed message exchangeand furthermore extends the regular HTTP protocol with anobserve verb [17]. The enhancement supports observing aresource and avoids frequent polling of resources such as eventstreams or alarms.

To improve the message encoding of XML based commu-nication interfaces, EXI provides a standardized method tomap XML data to a binary representation. The encoding ismost efficient if an XML schema is offered. In this case,all communication partners need to be aware of the schema.However, even if no schema is used reasonable results regard-ing message size can be achieved and the problem of a tightcoupling between service consumer and service provider isavoided.

The data link layer used to interact with the gateway is moreor less out of scope since IPv6 is the common network layerprotocol. For native wireless IoT devices, basically any linkis possible, but IEEE 802.15.4 and the 6LoWPAN adaptionlayer to IPv6 are desirable.

The presented protocol stack provides several new messageencodings and new protocol bindings to CoAP for oBIX.Asynchronous communication features of CoAP provide amore efficient subscription to oBIX objects than using thewatch mechanism that is based on polling using HTTP.

A. IoT Contracts

For the integration of the various BAS technologies, weuse a generic set of oBIX contracts (Figure 4). The design ofthe contracts aims at representing functional blocks found innowadays BAS (cf. KNX functional blocks [18]).

Fig. 4. Excerpt of IoT contracts

The IoT contracts define the data points offered by thedevices. Two examples of such contracts are shown in List-ings 1 and 2. The contracts are quite similar since both offer asingle boolean data point, but in case of the actuator, the datapoint is also writable. For more sophisticated devices, moredata points can be defined, e.g. a dimming push button or adimming actuator would additionally have an integer propertyrepresenting the current setting.

Listing 1. Light switching actuator contract<obj href="iot:LightSwitchActuator" is="iot:Actuator">

<bool name="value" href="value" val="false" writable="true"/>

</obj>

Listing 2. Push button contract<obj href="iot:PushButton" is="iot:Sensor">

<bool name="value" href="value" val="false"/></obj>

IV. GATEWAY ARCHITECTURE AND IMPLEMENTATION

The architecture of the gateway is outlined in Figure 5.Each device is represented by an oBIX object either boundto a unique IPv6 address or to a context path within thecentralized interface. It makes no difference which protocolbinding is used by the client application that may reside onsite or remote. Regardless whether the HTTP or CoAP handlerreceives the incoming request, it is then processed by themessage encoder. In case of SOAP, the processing of the SOAPenvelope resides in between. Currently, only XML is supportedas message encoding for the SOAP interface. For the messageencoding, (schema informed) EXI, JSON or oBIX binary canbe freely chosen, also separately defined for the request andthe response.

For the EXI encoding an XML schema for oBIX is definedcovering the basic oBIX data model. This schema is also usedfor specifying the types within the WSDL document for theSOAP Web service allowing a client to automatically generatethe SOAP client API. By using the generic oBIX data model,the XML schema does not need to be aligned with the customdefined contracts.

Finally, all requests are processed by the oBIX server thatkeeps track of the current state of the oBIX object. Therefore,it is possible to use different protocol bindings at the same timeoperating on the same oBIX object. The oBIX server executesthe read, write and invoke requests. For the supportof the oBIX watch mechanism and the CoAP observemechanism, it also implements the observer pattern. The oBIXobject represents a device of a BAS that resides behind thegateway. The protocol adapters take care of the BAS specificcommunication protocols, e.g. group communication in KNX,and map the oBIX updates accordingly. At the same time theprotocol adapters observe changes inside the BAS and updatethe oBIX objects consequently. The oBIX objects based onthe presented IoT oBIX contracts provide a generic object-oriented representation for same device types out of differentBAS.

Fig. 5. Multi-protocol gateway architecture

A. Implementation

For the implementation, the Java 6 platform and several ex-isting open source libraries are used in order to realize the pro-tocol adapters [19], [20], the message encoder/decoder [21],the oBIX server [22], [23] and the protocol bindings [24]. Stilla lot of custom implementations were necessary to provide theIPv6 mapping to oBIX objects and the novel protocol bindings.For some technologies (e.g. wireless M-bus) custom protocolstacks had to be prepared since no proper open source libraryexisted. By using Java as platform, it is possible to deploy thegateway either on strong server infrastructures or embeddedplatforms like the Raspberry Pi.

V. EVALUATION

For the evaluation of the presented concept, a distributedtest bed based KNX, BACnet, wireless M-Bus and ZigBeeis used. Several devices are interconnected using the IPv6multi-protocol gateway including light switching actuators,dimming actuators, push buttons, temperature sensors, fans,valves, pump actuators, air conditioning devices and boilers.Figure 6 shows a picture of the devices used for the proof ofconcept implementation and the concept evaluation.

A. Control logic use cases

By means of the unified interface based on RESTful Webservices, it is possible to create control logic that operateson remote servers. This way, heterogeneous non-IP basedbuilding automation systems are seamlessly integrated withconstrained RESTful environments. Control applications usea unique interface, regardless if it is a native IoT devicethat operates an IPv6 based Web service stack or a non-IP

Fig. 6. Test bed

based legacy device. As validation for heterogeneous deviceinteraction, a KNX push button is linked to a BACnet lightswitch actuator. A simple two-point temperature controllerwith a small hysteresis is implemented as Java application thatdirectly operates on the per-device CoAP Web services. For thetemperature control scenario a temperature sensor is directlymounted next to a light bulb that acts as heat source. TheUML sequence diagrams in Figure 7 and Figure 8 illustratethe implemented control logic use cases.

Fig. 7. Two point temperature control logic

For the temperature control scenario the delay addedthrough this integration layer is not crucial, since the controlledsystem comes with a high response time. However, if aninteractive scenario is chosen, the added delay can significantlyinfluence the user experience and usability. Therefore, the nextsubsection presents a performance evaluation of the presentedconcept.

VI. PERFORMANCE EVALUATION

Measurements have been carried out aiming at quantitativemetrics regarding message size, CPU utilization and the addeddelay if control logic is based on the RESTful Web serviceinterfaces. For the message size and the CPU utilization, abenchmark based on the defined IoT contracts was chosen.For the message size evaluation, each object and data pointwas accessed by a read and write request. Using an automatedclient based on a network packet capturing library, the traffic

Fig. 8. Heterogeneous device interaction

was analyzed and different message sizes of the used protocolsabove IP were subsequently recorded. The results of themeasured message sizes are given in Figure 9. As illustrated,the CoAP protocol binding with schema-informed EXI is themost efficient protocol binding. The schema-informed EXImessage encoding is slightly more efficient than the customoBIX binary encoding but comes with the big advantages ofa generic and standardized encoding mechanism that solelyrequires the XML schema at the client and at the server side.The JSON encoding is unexpected higher than the plain XMLencoding. This can be explained by the necessary encodingthat keeps all relevant information to encode XML to JSONwithout any loss of information. A dedicated JSON bindingwould be slightly more efficient than the XML encoding.

150

250

500

1000

2000

2500

GET full object GET data point PUT full object PUT data point

Con

vers

atio

n S

ize

in B

ytes

oBIX Protocol Binding

Protocol Evaluation

HTTP/XMLHTTP/JSON

HTTP/EXIHTTP/EXI SCHEMA INF.

HTTP/OBIX BINARY

CoAP/XMLCoAP/JSON

CoAP/EXICoAP/EXI SCHEMA INF.

CoAP/OBIX BINARY

Fig. 9. Protocol binding evaluation

For the performance evaluation, the IPv6 multi-protocolgateway is deployed on a Raspberry Pi board (700 MhzARM CPU, 512 MB memory). By means of this hardwareplatform, it is possible to conduct an operational performanceanalysis based on the service demands with their differentprotocol bindings. To calculate upper asymptotic bounds on

the maximum throughput, the service demands Di, where irepresents the protocol binding, have been calculated usingthe methodology presented in [25]. According to the servicedemand rule (Equation 1), it is possible to calculate theutilization U for a given throughput X . Figure 10 illustratesa comparison of the maximum throughput depending on theprotocol binding. The results show that the best throughputis provided by using an HTTP protocol binding with XMLfor message encoding. The lowest throughput results by usingCoAP for message exchange and schema-informed EXI formessage encoding. The difference between HTTP and CoAPcan be explained by a more mature HTTP server implemen-tation in use. The EXI encoding is clearly an overhead sincethe used oBIX server operates on XML requiring an XMLrepresentation before the message is encoded using EXI. Thisoverhead could be avoided if the oBIX server will operate onEXI encoded data directly.

Di =Ui ∗ τC

=Ui

Xi(1)

0

0.2

0.4

0.6

0.8

1

0 1 2 3 4 5 6 7 8 9 10 11

Util

izat

ion

CP

U (

%)

Throughput (req./s)

HTTP XMLHTTP EXI

HTTP EXI (SCH. INF.)HTTP oBIX Binary

HTTP JSONCoAP XML

CoAP EXICoAP EXI (SCH. INF.)

CoAP oBIX BinaryCoAP JSON

SOAP over HTTPSOAP over CoAP

Fig. 10. Maximum throughput

For evaluating the introduced delay by using control logicbased on the IPv6 RESTful Web services, a Java controlapplication was deployed in the first case locally on the sameplatform (Raspberry Pi) at which the multi-protocol gatewayresides. In the second case, the application was deployedremotely on a server representing a possible cloud basedsolution. As BAS components, a simple push button andswitching actuator of a KNX test bed were used. Instead oflinking both devices using KNX group communication, eachdevice uses a separate group communication address that wascoupled by the control logic based on the IPv6 oBIX interfacewith the CoAP protocol binding using XML encoding in orderto support asynchronous subscriptions to the events of the

KNX push button. The KNX test bed and the Raspberry Piboard equipped with the IPv6 multi-protocol gateway werehosted in Vienna, Austria. For the remote control scenario, thecontrol logic was deployed at a server in Sierre, Switzerlandconnected through public IPv6 connectivity with the test bedin Vienna.

Server

Internet (IPv6)

IPv6 multi-protocol gateway

KNX network

KNX

KNX KNX

KNX

KNX

PLC

C C

CoAP

Remotecontrol and monitoring

Local control and monitoring

CoAP

Fig. 11. Delay evaluation

The delay was measured on the KNX bus using the dif-ference between two consecutive write requests on the twoseparate used group communication addresses assigned to theKNX devices. As shown in Figure 12, the introduced latencystays below one second, which is a crucial limit for theinteraction flow of a human user according to [26] and [27].

200

300

400

500

Local Control Remote Control

Del

ay in

ms

Control Strategy

Delay

Fig. 12. Delay evaluation

VII. CONCLUSION

This paper presented a concept of an IPv6 multi-protocolgateway used for seamless integration of building automationsystems in the Internet of Things. Details on the concept ofan IPv6 multi-protocol gateway are discussed. The approach

taken combines IPv6 and oBIX with current research activitiesin constrained RESTful environments and provides severalnovel protocol bindings which are evaluated regarding mes-sage size and performance. Furthermore, control use cases arebriefly discussed that handle interconnecting heterogeneousBAS locally or remotely based on IPv6 connectivity. Suchan integration of heterogeneous technologies taking care ofinterconnecting large-scale distributed control networks mightprovide several benefits in the context of smart cities. Asfurther work we consider to focus on more specific use casesdedicated to smart cities and to address security and scalabilityissues.

ACKNOWLEDGMENT

Authors express their acknowledgement to the consortiumof the project IoT6 (www.iot6.eu). The IoT6 project is sup-ported by funding under the Seventh Research FrameworkProgram of the European Union, with the grant agreementFP7-ICT-2011-7-288445.

REFERENCES

[1] M. Naphade, G. Banavar, C. Harrison, J. Paraszczak, and R. Morris,“Smarter cities and their innovation challenges,” Computer, vol. 44,no. 6, pp. 32–39, 2011.

[2] M. Fazio, M. Paone, A. Puliafito, and M. Villari, “Heterogeneous sensorsbecome homogeneous things in smart cities,” in Innovative Mobileand Internet Services in Ubiquitous Computing (IMIS), 2012 SixthInternational Conference on. IEEE, 2012, pp. 775–780.

[3] “Constrained Application Protocol (CoAP) draft-ietf-core-coap-11,”IETF Internet Draft, Mar. 2012.

[4] “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):Overview, Assumptions, Problem Statement, and Goals,” RFC4919, Jul.2007.

[5] “Efficient XML Interchange (EXI) Format 1.0,” W3C Recommendation,Mar. 2011.

[6] Z. Shelby and C. Bormann, 6LoWPAN: The Wireless Embedded Internet.Wiley, 2011.

[7] A. Castellani, M. Gheda, N. Bui, M. Rossi, and M. Zorzi, “Web Servicesfor the Internet of Things through CoAP and EXI,” in Proceedings of theIEEE International Conference on Communications (ICC 2011), 2011.

[8] M. Jung, J. Weidinger, C. Reinisch, W. Kastner, C. Crettaz, Y. Bocchi,and O. Crettol, “A transparent IPv6 multi-protocol gateway to integrateBuilding Automation Systems in the Internet of Things,” in Proceedingsof the IEEE International Conference on Internet of Things (iThings2012), Besancon, France, Nov. 2012.

[9] M. Jung, J. Weidinger, D. Bunyai, C. Reinisch, W. Kastner, andA. Olivieri, “Demonstration of an IPv6 multi-protocol gateway forseamless integration of Building Automation Systems into ConstrainedRESTful Environments,” in Proceedings of the IEEE InternationalConference on Internet of Things (IoT 2012), Wuxi, China, Oct. 2012.

[10] M. Jung, J. Weidinger, W. Kastner, and A. Olivieri, “Heterogeneousdevice interaction using an IPv6 enabled service-oriented architecturefor building automation systems,” in Proceedings of the 28th ACMSymposium on Applied Computing, Coimbra, Portugal, Mar. 2013.

[11] Z. Shelby, “Embedded Web Services,” Wireless Communications, IEEE,vol. 17, no. 6, pp. 52–57, 2010.

[12] M. Aiello and S. Dustdar, “Are our homes ready for services? A domoticinfrastructure based on the Web service stack,” Pervasive and MobileComputing, vol. 4, no. 4, pp. 506–525, 2008.

[13] L. Ribeiro, J. Barata, A. Colombo, and F. Jammes, “A generic com-munication interface for DPWS-based web services,” in Proceedings ofthe 6th IEEE International Conference on Industrial Informatics (INDIN2008). IEEE, 2008, pp. 762–767.

[14] M. Kovatsch, S. Mayer, and B. Ostermaier, “Moving Application Logicfrom the Firmware to the Cloud: Towards the Thin Server Architecturefor the Internet of Things,” in Proceedings of the 6th InternationalConference on Innovative Mobile and Internet Services in UbiquitousComputing (IMIS 2012), Palermo, Italy, Jul. 2012.

[15] M. Kovatsch, M. Lanter, and S. Duquennoy, “Actinium: A RESTfulRuntime Container for Scriptable Internet of Things Applications,” inProceedings of the 3rd International Conference on the Internet ofThings (IoT 2012), Wuxi, China, Oct. 2012.

[16] “oBIX 1.1 draft committe specification,” OASIS, 2011.[17] “Observing Resources in CoAP draft-ietf-core-observe-05,” IETF Inter-

net Draft, Mar. 2012.[18] “KNX System Specifications,” KNX Association, 2009.[19] “Calimero - KNXnet/IP (and more) for Java,” http://calimero.

sourceforge.net/, 2012, [Online; accessed 22.09.2012].[20] “BACnet I/P for Java,” http://sourceforge.net/projects/bacnet4j/, 2012,

[Online; accessed 22.09.2012].[21] “OpenEXI,” http://openexi.sourceforge.net/, 2012, [Online; accessed

22.09.2012].[22] M. Neugschwandtner, G. Neugschwandtner, and W. Kastner, “Web Ser-

vices in Building Automation: Mapping KNX to oBIX,” in Proceedingsof the 5th IEEE International Conference on Industrial Informatics(INDIN 2007), 2007.

[23] “oBIX Java Toolkit,” http://sourceforge.net/projects/obix/, 2010, [On-line; accessed 22.09.2012].

[24] J. Elonen and K. Togias, “NanoHTTPD,” http://elonen.iki.fi/code/nanohttpd/, 2012, [Online; accessed 22.09.2012].

[25] P. J. Denning and J. P. Buzen, “The Operational analysis of queuingnetwork models,” ACM Computing Surveys, vol. 10, no. 3, 1978.

[26] R. Miller, “Response time in man-computer conversational transactions,”in Proceedings AFIPS Fall Joint Computer Conference. ACM, Dec.1968, pp. 267–277.

[27] J. Nielsen, Usability engineering. San Francisco, California: MorganKaufmann, 1994.