OSGi is gaining popularity as enabling technology for building embedded system in residential, automotive and M2M markets. In all these contexts it is often necessary to communicate with IP and non-IP devices by using various protocols such as Zigbee, ZWave, KNX, UPnP etc. In order to provide a convenient programming model suitable for the realization of end-to-end services it is very useful to define and apply an abstraction layer which unifies the work with the different devices. This presentation summarizes the existing approaches for the realization of a device abstraction layer and comments their advantages and disadvantages. A reference architecture based on the experience gained from numerous real-life projects is presented and explained.

1. 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

2. 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

3. 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

4. Reference residential architecture
based on OSGi
Page 4 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

5. 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
Page 5 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

6. 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
Page 6 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

7. 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
Page 7 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

8. 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
Page 8 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

9. 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
Page 9 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

10. 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
Page 10 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

11. 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
Page 11 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved

12. 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

13. HDM device clasess

14. 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
Page 14 OSGi Alliance Marketing © 2008-2011 . All Rights Reserved