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

COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved

Using Device Abstraction Layers in

OSGi based Embedded Systems

Dr. Dimitar Valtchev

ProSyst Software

21 September 2011

OSGi Alliance Marketing © 2008-2010 .

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

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)

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

Reference residential architecture

based on OSGi

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


C:/Users/dimi/Docs/ProSyst_tech/HDM/docs/hdm/api/com/prosyst/mbs/services/hdm/deviceclasses/BinarySwitch.html




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


http://code.google.com/p/openhab/

http://www.eebus.de/

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

Z-wave

EHS

ZigBee

KNX

SML

Wireles

M-Bus

Switches

etc. smart, smarter,

smartest Meters… HomeMatic, EQ3/FS20

ready IP-Camera

support

all relevant

Smart Home standards

one phys. device,

several abstract

objects

standard OSGi

Eventing (into Java)

routed to JSON/RPC

Java, JSON, RPC

HDM device clasess

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

Technology

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