![Example for using DAL
• Print all online devices
final ServiceReference[] deviceSRefs = context.getServiceReferences(
Device.class.getName(), '(' + Device.PROPERTY_STATUS + '=' +
Device.STATUS_ONLINE + ')');
if (null == deviceSRefs) {
return; // no such services
}
for (int i = 0; i < deviceSRefs.length; i++) {
printDevice(deviceSRefs[i]);
}
External Link:
https://github.com/osgi/design/blob/master/rfcs/rfc0196/rfc-0196-DeviceAbstractionLayer.pdf
29.10.2013
Page 30](https://image.slidesharecdn.com/deviceabstractioninosgibasedembeddedsystems-dimitarvaltchev-131101084030-phpapp01/85/Device-Abstraction-in-OSGi-Based-Embedded-Systems-Dimitar-Valtchev-30-320.jpg)
Device Abstraction in OSGi Based Embedded Systems - Dimitar Valtchev
- 1. Device Abstraction in OSGi Based Embedded Systems Dr. Dimitar Valtchev CTO ProSyst Software [email protected] OSGi Community Event, Ludwigsburg, 29. October 2013 12/03/09
- 2. Gateway-centric M2M architecture Cloud Services Local applications Example: Provider of home energy management service. Partners with BSP to install application bundle on Home Gateway and deliver supporting hardware UI Devices M2M App1 AppN App2 HOME GATEWAY PLATFORM D1 D2 D3 D4 D5 Smart home buses connecting to smart home devices and sensors DN 2
- 3. Challenges for creating gateway applications • The availability of heterogeneous HAN • Significant constrains in the functionality of the gateway applications if they are created to support only given and predefined HAN • Impossible or very resource-consuming extendibility of the systems • Difficult portability and interoperability 3
- 4. Smart home architecture with SHAL Cloud Services Local applications Example: Provider of home energy management service. Partners with BSP to install application bundle on Home Gateway and deliver supporting hardware UI Devices M2M App1 App2 AppN Device Abstraction Layer (DAL) D1 4 D2 D3 D4 D5 Smart home buses connecting to smart home devices and sensors HOME GATEWAY PLATFORM DN
- 5. Goals of the abstraction layer 1. Provide unified APIs for application developers – command, control and query home appliances 2. Independence of underlying HAN technologies – so that an application developer doesn’t need to know anything about Zigbee, Z-Wave, wireless m-bus etc. and he can concentrate on the modeled devices available to develop services 3. Enable applications to be portable across different compliant devices 4. Enable extendibility of the system with additional HAN 5. Applications should be able to use a pass-through mechanism to use HAN-specific functions 5
- 6. Smart Home architecture based on OSGi OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 6
- 7. ProSyst product offering Modular platforms w/ APIs & add. functionality Tools & SDKs Remote Management Server 12/03/09 7
- 8. ProSyst stack overview open Programming Interfaces Connect. various UI Options ProSyst OSGi Smart Home Stack (Portal) Apps DLNA API (Java, JSON, RPC) broad Interop. UPnP Data Privacy Security (TLS/X.509) Home Automation Manager (HAM) (Scenes, Rules, Conditions) Management & Update Agent TR-069 / OMA-DM etc. Residential Services Remote Mgmt. API (Java, JSON, RPC) Home Device Manager (HDM) (Devices: Actions + Properties, Zones) ZWave EnOcean ZigBee IP/USB other comprehensive set of Home Protocol Standards 8
- 9. Home Device Manager (HDM) Applications Java, JSON, RPC Java, JSON, RPC one phys. device, several abstract objects DCO b1 DCO a1 DCO bn DCO an standard OSGi Eventing (into Java) routed to JSON/RPC Event Admin Home Device A Home Device B Home Device Manager Home Device Access Home Device Admin ZigBee Protocol Adapter Cameras (IP/USB) Protocol Adapter ZigBee Protocol Driver Cameras (IP/USB) Protocol Driver Home Zone Access Other Protocol Adapter Other Protocol Adapter Home Zone Admin e.g. Z-Wave, Bluetooth, EnOcean e.g. switches, healthcare devices , door sensrs, s mart meters 9
- 10. HDM Features (1) HDM provides a general home device abstraction. Each home device has UID, status, display name, protocol adapter, set of device class objects, vendor, version, additional properties, etc. It is possible to get, set properties and receive events for properties. HDM provides representation of complex devices such as, for example, a device with 2 switches and 1 sensor. In this case several home devices are created, parent and child home devices (1x parent, 3x childs) The functionality of a home device is represented by device class objects. Each device class object implements a specific device class. The device class is a Java interface which has set of properties, setter/getter methods for each property, operations and events. Eventing takes place on property value changes. 10
- 11. HDM Features (2) A device class may extend an other devices class. Each device class has associated metadata for its properties and operations. It is possible to define custom device classes when new device functionality is needed to be represented. There are predefined device classes such as BinarySensor, BinarySwitch, MultilevelSensor, MultilevelSwitch - and a lot more There are special devices classes which provides management functionality. These, for example, monitor the devices, configure them, make firmware update, etc. HDM provides a Home Device Access service. This service allows to get particular home device or a set of home devices based on caller permissions. 11
- 12. HDM Features (3) HDM provides a Home Device Admin service. This service allows to execute management operations such as get info about the available protocol adapters, add new home device, remove home device, search for new home devices, etc. HDM uses OSGi Event Admin service go generate events when adding/removing home devices, changing of home device properties, changing of DCO properties, etc. HDM relies on OSGi Conditional Permission Admin service. By using it is possible to configure which caller may do that with which device. It is possible to set permissions which restrict calls to HomeDevice and DCO methods. HDMPermission Class manages their access privileges. 12
- 13. HDM Features (4) HDM defines a Home Protocol Adapter abstraction. It allows to easily add support for new home protocols and devices. A protocol adapter provides the required objects which represent the home devices. Each protocol adapter is implemented as an OSGi bundle. Protocol adapter call protocol drivers. Protocol Drivers provide an implementation of the home protocol. This adapter is an OSGi bundle which does not have any dependency on the HDM API. It is also possible to put protocol driver logic into the protocol adapter (if needed). It is possible to have general protocol adapters such as for ZWave, ZigBee, Homematic, etc. The general protocol adapter represents all devices from the corresponding home protocol. In this case some more protocol driver logic resides outside this adapter (e.g. ZigBee Stack). 13
- 14. HDM Features (5) It is possible to have also adapters for specific home device types such as Cameras, TVs, etc. The adapter abstraction provides the possibility to extend the adapter with support for new device classes without need to repack the adapter. 14
- 15. HDM Features (6) Applications Java, JSON, RPC Java, JSON, RPC Event Admin A2 Kitchen Home Zone B2 A1 B1 ProSyst OSGi Smart Home Stack C1 Home Device Manager Home Device Admin ZigBee Protocol Adapter Z-Wave Protocol Adapter Camera Protocol Adapter Home Zone Admin Kitchen Zone Trusted Zone System Zone Devices can be identified according to their protocol, but for Application access or Zone grouping it does not matter 15
- 16. HDM Example DCOs Controlled Devices / Actuators Monitored Devices / Sensors Battery Level Binary Sensor Binary Switch Blinds StandBy Switch Power Meter Motion Sensor Door Actuator Identifier Swimming Pool MultiLevel Sensor Temperature Sensor Network Controller MultiLevel Switch Temperature Actuator Wake Up Wind Sensor Window Actuator Scene Actuator Your Need Record Actuator Zoom Actuator Move Actuator Image Provider Video Provider USB or IP A/V Devices 16
- 17. Abstraction of zones HDM provides an abstraction of zones. Zones do group a set of devices. It is possible to have zones for rooms, floors, device category (e.g. Lightning, HVAC, security), etc. System Home Zone System Home Zone Trusted Living Room Living Room Bed Room Kitchen Bed Room Kitchen Untrusted 17 A special System Zone is defined. All devices that are available in HDM are assigned to it.
- 18. Zone types System Home Zone C2 B2 Living Room Home Zone B1 Home Device Manager Device & Zone Mapping A1 All Cameras Home Zone C1 Dining Room Home Zone Home Zones may be device-type-orientied, room-based or otherwise sorted, and may overlap (use-case might be e.g. “all lights off” or “kitchen off” or “all cameras on”) 18
- 19. Home Automation Manager (HAM) Applications Java, JSON, RPC Event Admin Java, JSON, RPC Rule Editor Condition Editor Command Editor ProSyst OSGi Smart Home Stack Scene Editor Web Console Home Automation Manager Command 1-n Rule Manager Condition 1-n Home Device Manager OSGi Command Provider Condition Provider Config Loader Device Abstraction and Access compliant APIs and XML-based way to create automation 19 logic using conditions, commands, rules and scenes
- 20. Connecting to Z-Wave, ZigBee & Co Serial and Parallel Package - Java Communications API 3.0 • javax.comm provides access to RS-232 (serial) and EEE-1284 (parallel/SPP) • RXTX is a Java library, using a native implementation (via JNI), providing serial and parallel communication via gnu.io; a RXTX-to-Java COMM Wrapper Bundle implements the javax.comm API over RXTX gnu.io. It is functional when a RXTX bundle is present, e.g. for Linux, WinCE or via Win32rxtx • Platform Support: • various Linux platforms: x86, i386, ixp425, MIPS and ARM (little endian) • Windows: 95, 98, 2000, NT, XP, XPe, Vista, 7, 7e, WinCE USB Package - support for USB data exchange • based on the libusb Java wrapper • the Java wrapper for libusb is based on libusb and libusb-win32 USB native libraries • ProSyst packages the wrapper along with needed native OS libraries as OSGi bundles • Platform Support: • various Linux platforms: armv4l, ixp425, mipsbe, mipsle, ppc, x86 • Windows: win32 20
- 21. Reference architecture (HGI) Remote Access Middleware RPx • • HOME GATEWAY Remote Access Agent App 1 … App N RP1 RP2 – Device Application Interface • RP4 RP1 – Abstraction Application Interface RP4 – Remote Representation (e. g. ETSI M2M) • RPx – Cloud API Reference points relevant to the abstraction layer as defined by HGI Abstraction Layer RP2 D1 D2 D3 Dx 21
- 22. What does a device abstraction layer need? • Common data model (data model template) • Concrete data models (device ontology) • APIs (and/or protocols) for accessing the devices – For accessing the data models – 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, REST, UPnP, XMPP , TR-69, LWM2M, etc.) – … OSGi Alliance Marketing © 2008-2011 . All Rights Reserved Page 22
- 23. Device model template (in preparation) • A common template used to specify device capabilities • When instantiated, forms a common API for all devices of the same class (eg “Doorbell”) • Should be approved by all participating organizations (BBF, HGI, OneM2M, OSGiA, …) • Template has an informal (text) and a formal section (machine-readable, probably XML based) 23
- 24. Device modeling process (HGI approach) INSTANTIATION CLEARING Send GWD042 to domain specific organization Domain specific org instantiates template for a set of devices Domain specific org returns instantiated templates PUBLICATION Identify the device class Only 1 model for this device class? YES NO Merge differing models into a single unified model and circulate for approval Agreement achieved? YES NO Define mapping rules between unified model and domain specific models Publish resulting domain specific and unified device models 24
- 25. Aimed collaboration of SDOs on DAL Joint work on GWD042 Map ontology template to OSGi technology Jointly approaching domain specific organizations (verticals) Edit and align a GWD042 Liaise template to domain specific organizations Instantiates GWD042 with their respective device characteristics Joint work on ontology template document Map ontology template to BBF TRs (if needed) Jointly approaching domain specific organizations (verticals) Instantiates GWD042 with their respective device characteristics Joint work on ontology template document Map ontology template to specific technologies: •ETSI M2M REST APIs •EEBus APIs Jointly approaching domain specific organizations (verticals) This figure is not at all comprehensive; it only shows a possible starting point. 25
- 26. Possible components of an abstract device model DEVICE MODEL Device (aka Home Device) Device Function SERVICE (akaSERVICE DCO, HGI Modules) DEVICE CLASS still under discussion • How to deal with compound devices like i.e. a TV set which consists of a screen, an audio amplifier, most likely a tuner, sometimes also a hard disk recorder? Formal language for the device model not selected yet • XML, OWL, TR-106 based, etc. • ACTION SERVICE name SERVICE parameter value types return value types Property SERVICE name valueSERVICE type EVENT SERVICE name SERVICE event type payload Would formal semantic description have any benefit? 26
- 27. OSGi devices (draft RFC) org.osgi.service.functionaldevice.Device • Represents the device in the OSGi registry • It’s possible to map a few OSGi device services to one physical device. • Provides an access to rich set of device properties: status, name, description, types, model, firmware version and vendor, hardware version and vendor etc. • Provide basic management operations: remove, property update, enable and disable • Gives up a set of supported Device Functions 29.10.2013 Page 27
- 28. OSGi device statuses (draft RFC) Example: status online 29.10.2013 Page 28
- 29. OSGi device functions (draft RFC) 12/03/09
- 30. Example for using DAL • Print all online devices final ServiceReference[] deviceSRefs = context.getServiceReferences( Device.class.getName(), '(' + Device.PROPERTY_STATUS + '=' + Device.STATUS_ONLINE + ')'); if (null == deviceSRefs) { return; // no such services } for (int i = 0; i < deviceSRefs.length; i++) { printDevice(deviceSRefs[i]); } External Link: https://github.com/osgi/design/blob/master/rfcs/rfc0196/rfc-0196-DeviceAbstractionLayer.pdf 29.10.2013 Page 30
- 31. Conclusions • Having a well defined device abstraction layer is a must for any service/M2M gateway product for the mass market and there are already mature commercial products relying on this approach • It would be extremely useful across products from different vendors and that’s why it became an important standardization topic for organizations like OSGiA, HGI, BBF, ETSI M2M, OneM2M • There are still some issues regarding the scope of the specification work (e.g. data model template vs data models vs API) and its distribution across different SDOs which are in process of being clarified Page 31
- 32. Thank You! Dr. Dimitar Valtchev CTO ProSyst Software [email protected] www.prosyst.com 32