View
3.832
Download
2
Category
Tags:
Preview:
DESCRIPTION
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.
Citation preview
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
Page 1
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 Page 2
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 Page 3
Reference residential architecture
based on OSGi
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 4
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 5
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 6
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 7
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 8
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 9
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 10
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 11
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
OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 14
Recommended