This paper proposes using an IPv6 multi-protocol gateway to provide standardized internet access to heterogeneous building automation devices. The gateway maps each device to an IoT-oBIX contract to provide a common representation. It offers web service interfaces for each device, bound to a unique IPv6 address. Evaluation shows CoAP/EXI is most efficient, and remote control delays are under one second. The approach integrates different automation technologies through web services while hiding their differences.
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Heterogeneous device interaction using an IPv6 enabled service-oriented architecture for buiding automation systems
1. Heterogeneous device interaction using an
IPv6 enabled service-oriented architecture
for buiding automation systems
Markus Jung, Jürgen Weidinger and Wolfgang Kastner Alex Carmine Olivieri
Vienna University of Technology Institute Informatique de Gestion
Institute of Computer Aided Automation Haute Ecole Spécialisée de Suisse occidentale
Automation Systems Group alex.olivieri@hevs.ch
{mjung,jweidinger,k}@auto.tuwien.ac.at http://iig.hevs.ch/
www.auto.tuwien.ac.at
In the domain of home and building automation systems the non-IP technologies are dominants, and
1 Introduction with the advent of Internet of Things it is an interesting idea to provide the devices which use these
technologies with internet connectivity.
This paper shows how to satisfy this objective using a IPv6 multi-protocol gateway, where every device is
mapped to an oBIX contract and the gateway is reachable through web service interfaces.
2 Problem 3 Protocol Stack The IPv6 multi-protocol gateway offers for each
legacy device a per-device Web service interface
bound to an unique global unicast IPv6 address.
IPv6 multi-protocol gateway stack
Many technologies for business automation system IoT contracts
exist, but the most commonly used (KNX, BACnet, oBIX
Layers:
ZigBee, ...) are non-IP compliant. JSON, EXI XML oBIX binary JSON, EXI
Existing Binding
a) oBIX: provides a RESTful interaction protocol
and an object model to represent the devices;
To exploit their functionalities in some scenarios, like New Binding
SOAP b) information representation: JSON/EXI as inno-
smart grids or smart cities, they need to be integrated CoAP HTTP Existing
vation;
into the Internet of Things. UDP TCP
New/ c) application and transport protocols:
IPv6
The problem that arises is how to provide a standardized 6LoWPAN
Modified
- HTTP/TCP;
IEEE 802.3
infrastructure that can allow this integration. IEEE 802.15.4 Ethernet
Other links
- CoAP/UDP (needs ulterior mechanisms).
d) network: IPv6.
IPv6 multi-protocol gateway stack
4 IPv6 Enabled SOA IPv6 multi-protocol gateway offers protocol
adapters for various non-IP technologies and it is
iot : iot :
the core component of the IPv6 enabled service-
oriented architecture.
PushButton LigthSwitchActuator
Human KNX Push Button BACnet light switch actuator Control Logic
1: CoAP GET (OBSERVE) [IPv6 address - push button]/value
2: Switch button
4: KNX write on
3: 2.05 Content <bool val="false"/>
group address
5: notify observers
6: 2.05 Content <bool val="true"/> The BAS technologies need to be mapped into
7: CoAP PUT [IPv6 address - light switch actuator]/value - <bool val="true"/>
8: 2.05 Content <bool val="true"/>
IoT-oBIX contracts in order to provide a common
9: BACnet write property on analog output
- present value object oriented representation.
10:
Heteregeneous device interaction An oBIX server takes care about the requests and
dispatch them to the mapped underlying tech-
iot : iot :
TemperatureSensor LightSwitchActuator
Control Logic
nology.
1: CoAP GET (OBSERVE) [IPv6 address of temperature sensor]/value
loop
2: 2.05 Content <real val="[current temp.]" unit="obix:units/celsius"/>
Testbed Sierre, Switzerland Testbed Vienna, Austria alt
[ temperature < 23°]
3: CoAP PUT [IPv6 address - light switch actuator]/value :
<bool val="true"/>
In that way it is possible to integrate different
4:
Technology: Technologies:
technologies, hiding everything behind web ser-
[temperture > 26°] 5: CoAP PUT [IPv6 address - light switch actuator]/value :
ZigBee KNX, BACnet, W-MBus
<bool val="false"/>
6:
vices, providing local or remote control logics.
Two point temperature control logic
5 Evaluation The evaluation shows the performance of the information exchange in different conditions, analyzing
the traffic and measuring the message sizes. Various samples with different information representa-
tions and different CoAP and HTTP methods are analyzed.
Results and observations:
-> CoAP/EXI: is the most efficent protocol binding;
-> EXI encoding: is more efficent than the custom oBIX binary encoding;
-> JSON encoding without loss of information is less efficent than plain XML encoding;
Regarding the remote control an evaluation about the delay
in the commands is showed.
The test is based on the heterogeneous device interaction
showed in section 4, where from Sierre (CH) we control some
devices in Vienne (A).
The delay in the commands execution is less than one
Protocol binding evaluation Delay evaluation
second.
This paper presents how a service-oriented architecture based on an IPv6 multi-protocol gateway can
6 Conclusion be used for control logic that spans heterogeneous devices and geographically distributed sites.
From the tests two conclusions can be extrapolated:
Authors express their acknowledgement to the consortium of the project IoT6
a) the protocol binding based on CoAP and EXI encoding is as efficent as a binary encoded protocols,
(www.iot6.eu). The IoT6 project is supported by funding under the Seventh Research but based on standardized Web technology rather than proprietary encoding definition.
Framework Program of the European Union, with the grant agreement
FP7-ICT-2011-7-288445. b) the delay using a remote control is lower than the latency bound that negatively affects usability.
Contact: alex.olivieri@hevs.ch