Using Device Abstraction Layers in OSGi based Embedded Systems - Dimitar Valtchev

Using Device Abstraction Layers in
OSGi based Embedded Systems
Dr. Dimitar Valtchev

ProSyst Software

21 September 2011

OSGi Alliance Marketing © 2008-2010 . 1
Page
COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved
All Rights Reserved

Content

• Introduction
• Known approaches for the realization of home device
access applicable for an OSGi environment
• Definition of Device Abstraction Layer
• Reference architecture for the realization of Device
Abstraction Layer
• Conclusions

Page 2 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

Introduction

• OSGi already established as a key technology in residential
area. Why?
• Technical benefits of using Java, modular layer, dynamic
services, etc
• Maturity of the technology, availability of development tools,
reference materials, trainings, etc.
• Several comparatively well coordinated standardization
efforts building on OSGi (OSGiA, HGI, UPnP, BBF)
• OSGi fits perfectly to the new business models in residential
areas (e.g. the concept of service gateway)
Page 3 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved

Reference residential architecture
based on OSGi

Page 4 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

Home device access

• The home device access is an essential part of any
residential software architecture
• It is necessary in order to realize meaningful applications
for Energy Management, Comfort and Security
• There is a significant number of relevant home protocols
which differ depending on the used media (wires, radio,
plc), topology, communication, power consumption, data
rates
• Examples for home protocols: KNX, ZigBee, Z-Wave,
DigitalStrom, EnOcean, Homematic, Crestron, etc

Possible approaches to access home
devices
There is a general OSGi mechanism for working with devices and
drivers for them - OSGi Device access specification (R4.2
Compendium Spec)
• Specifying OSGi services for each home protocol
• There is already a UPnP Device Service Specification in OSGi R4.2
• Possible to be done for other protocols (for ZigBee or Z-Wave there are already
such plans for the next REG release)

• Defining an additional Device Abstraction Layer which
unifies the work with different types of protocols


Advantages of working with a Device
Abstraction Layer 1/2
• Unified Interfaces
• Example - Binary Switch
• int getState()
This method returns the current binary switch state.
• void toggle()
Toggles the current state of the binary switch.
• void turnOff()
This method turns off the binary switch.
• void turnOn()
This method turns on the binary switch.

• The upper methods do not depend on the underlying
protocol e.g. KNX or ZigBee


Advantages of working with a Device
Abstraction Layer 2/2
• Possible to switch easily between different protocols
without changing the upper layers (e.g. the UI)
• Facilitate the realization of home automation layers
• Allows mapping to management systems (e.g. for BBF
PD-174)
• A devices abstraction layer is not only an element of the
runtime but also of an SDK
• The developers do not to learn many different interfaces and protocols
• Much easier to realize simulators


Existing approaches to the device
abstraction layer
• To choose an existing protocol and to map all others to it
• One comparatively suitable protocol is UPnP (e.g. project OSAmI uses UPnP in
combination with OSGi Wire Admin to work with devices related to Ambient
Intelligence)

• To define from scratch a new abstraction layer. Some
examples:
• OpenHAB - http://code.google.com/p/openhab/
• DOG/DogOnt/DogSim - http://elite.polito.it/dog-tools-72
• EEBus - http://www.eebus.de/
• Home Device Manager (HDM) - http://dz.prosyst.com/devzone/SmartHome


What does a device abstraction layer
include?
• Device ontology (device classes)
• APIs (and/or protocols) for accessing the devices
• For accessing the device classes
• For administrative purposes (list all devices, discover/add device, etc)
• For providing additional convenience to the programmer (zones, friendly
names, etc)
------
• Local (e.g. Java API) or remote (e.g. JSON-RCP, UPnP, TR-69, messaging)
------
• Synchronous or asynchronous


ProSyst’s Home Device Manager
(HDM) – design goals
• Providing local OSGi based APIs for unified access to
heterogeneous devices (Java)
• Ensuring compatibility and good interoperability with
existing IP or non-IP home protocols
• Providing convenient access, control and notification
mechanisms suitable for the OSGi environment
• Support for device plug and play (depending on the
corresponding home protocol)‫‏‬
• Support for JSON/Restful interface, other RPC interfaces
(non-Java) and management protocols

HDM architecture

Java, JSON, RPC

one phys. device, standard OSGi
several abstract Eventing (into Java)
objects routed to JSON/RPC

Z-wave SML
EHS
ZigBee Wireles
KNX M-Bus

Switches smart, smarter,
ready IP-Camera all relevant etc. smartest Meters…
HomeMatic, EQ3/FS20
support Smart Home standards

Conclusion

• Having a well defined device abstraction layer is a must
for any service gateway product for the mass market
• It would be extremely useful also across products from
different vendors and is an important standardization topic
for organizations like OSGiA and HGI
• There are some challenges regarding the scope of a
possible specification work (APIs vs device ontology)
• ProSyst has invested significant resources in this area
and is actively pushing the corresponding standardization
activities

Using Device Abstraction Layers in OSGi based Embedded Systems - Dimitar Valtchev

More Related Content

What's hot

Similar to Using Device Abstraction Layers in OSGi based Embedded Systems - Dimitar Valtchev

More from mfrancis

Recently uploaded

Using Device Abstraction Layers in OSGi based Embedded Systems - Dimitar Valtchev