• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Using Device Abstraction Layers in OSGi based Embedded Systems - Dimitar Valtchev
 

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

on

  • 3,895 views

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

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.

Statistics

Views

Total Views
3,895
Views on SlideShare
3,894
Embed Views
1

Actions

Likes
2
Downloads
182
Comments
0

1 Embed 1

http://pinterest.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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
    • Reference residential architecturebased 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 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