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

Using Device Abstraction Layers inOSGi based Embedded SystemsDr. Dimitar ValtchevProSyst Software21 September 2011 OSGi Alliance Marketing © 2008-2010 . 1 PageCOPYRIGHT © 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

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

Possible approaches to access homedevices 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

Advantages of working with a DeviceAbstraction 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

Advantages of working with a DeviceAbstraction 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

Existing approaches to the deviceabstraction 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

What does a device abstraction layerinclude? • 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

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

HDM architecture Java, JSON, RPCone phys. device, standard OSGiseveral 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

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

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

by mfrancis

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics