Device Abstraction in OSGi Based Embedded Systems

Dr. Dimitar Valtchev

CTO ProSyst Software

d.valtchev@prosyst.com

OSGi Community Event, Ludwigsburg, 29. October 2013

12/03/09

Gateway-centric M2M architecture

2

M2M App1 App2 AppN

D1 D2 D3 D4 D5 DN

Smart home buses connecting to smart home devices and sensors

Local applications Example: Provider of home energy management service. Partners with BSP to install application bundle on Home Gateway and deliver supporting hardware

Cloud Services

HOME GATEWAY

PLATFORM

UI Devices

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

Smart home architecture with SHAL

Device Abstraction Layer (DAL)

M2M App1 App2 AppN

D1 D2 D3 D4 D5 DN

Smart home buses connecting to smart home devices and sensors

Local applications Example: Provider of home energy management service. Partners with BSP to install application bundle on Home Gateway and deliver supporting hardware

Cloud Services

4

HOME GATEWAY

PLATFORM

UI Devices

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

Smart Home architecture based on OSGi

OSGi Alliance Marketing © 2008-2011 .

All Rights Reserved Page 6

12/03/09

Modular platforms w/ APIs & add.

functionality

Tools & SDKs

Remote Management

Server

ProSyst product offering

7

ProSyst OSGi Smart Home Stack

ZWave EnOcean ZigBee IP/USB other

Home Device Manager (HDM) (Devices: Actions + Properties, Zones)

API (Java, JSON, RPC)

Home Automation Manager (HAM) (Scenes, Rules, Conditions)

API (Java, JSON, RPC)

Security (TLS/X.509)

Management & Update

Agent TR-069 / OMA-DM

etc.

UPnP

DLNA

ProSyst stack overview

(Portal) Apps

comprehensive set of Home Protocol Standards

Residential Services Remote Mgmt.

Connect.

broad Interop.

Data Privacy

open Programming Interfaces various UI Options

8

Applications

DCO b1

DCO bn

DCO a1

DCO an

Java, JSON, RPC

one phys. device, several abstract objects

Home Device B Home Device A

Event Admin

Home Device Manager

Home Device Access

Home Device Admin

Home Zone Access

Home Zone Admin

ZigBee Protocol Adapter

Cameras (IP/USB) Protocol Adapter

Other Protocol Adapter

ZigBee Protocol Driver

Cameras (IP/USB) Protocol Driver Other

Protocol Adapter

e.g. Z-Wave, Bluetooth, EnOcean

e.g. switches, healthcare devices , door sensrs, s mart meters

standard OSGi Eventing (into Java) routed to JSON/RPC

Home Device Manager (HDM)

Java, JSON, RPC

9

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.

HDM Features (1)

10

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.

HDM Features (2)

11

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.

HDM Features (3)

12

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

HDM Features (4)

13

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.

HDM Features (5)

14

HDM Features (6)

Home Device Admin Home Zone Admin

ZigBee Protocol Adapter

A1

Z-Wave Protocol Adapter

Camera Protocol Adapter

A2

B1

B2

C1

Home Device Manager

ProSyst OSGi Smart Home Stack Event

Admin Kitchen Home Zone

Devices can be identified according to their protocol, but for

Application access or Zone grouping it does not matter

Applications

Java, JSON, RPC Java, JSON, RPC

Kitchen Zone

Trusted Zone

System Zone

15

HDM Example DCOs

USB or IP A/V Devices

Monitored Devices / Sensors

Controlled Devices / Actuators

MultiLevel Sensor

Battery Level

Power Meter

Wake Up

Temperature Sensor

Binary Sensor

Motion Sensor

Wind Sensor

Network Controller

Binary Switch

Door Actuator

Window Actuator

MultiLevel Switch

Blinds

Identifier

Scene Actuator

Temperature Actuator

StandBy Switch

Swimming Pool

Your Need

Record Actuator

Zoom Actuator

Move Actuator

Image Provider

Video Provider

16

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.

A special System Zone is defined. All devices that are

available in HDM are assigned to it.

Abstraction of zones

System Home Zone System Home Zone

Living Room

Kitchen

Bed Room

Trusted

Untrusted

Living Room

Bed Room

Kitchen

17

Zone types

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”)

System Home Zone

B1 A1

All Cameras Home Zone

B2 C2

C1

Living Room Home Zone

Dining Room Home Zone

Home Device Manager Device & Zone Mapping

18

Home Automation Manager (HAM)

Rule Manager

Home Automation Manager

ProSyst OSGi Smart Home Stack

Applications

OSGi compliant APIs and XML-based way to create automation

logic using conditions, commands, rules and scenes

Command 1-n

Java, JSON, RPC

Event Admin

Home Device Manager

Command Provider

Condition 1-n Condition Provider

Config Loader

Rule Editor

Condition Editor

Command Editor

Scene Editor

Web Console

Device Abstraction and Access

Java, JSON, RPC

19

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

HOME GATEWAY

Reference architecture (HGI)

21

• RP1 – Abstraction Application Interface

• RP2 – Device Application Interface

• RP4 – Remote Representation (e. g. ETSI M2M)

• RPx – Cloud API

Reference points relevant to the abstraction layer as defined by HGI

D1 D2 D3 Dx

Abstraction Layer

RP2

Remote Access Agent

App 1 App

N …

RP4

Remote Access Middleware RPx

RP1

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

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, OSGi-A, …)

• Template has an informal (text) and a formal section (machine-readable, probably XML based)

23

PUBLICATION

INSTANTIATION

CLEARING

Device modeling process (HGI approach)

24

Domain specific org instantiates template for a set of devices

Send GWD042 to domain specific organization

Domain specific org returns instantiated templates

Merge differing models into a single unified model and circulate for approval

Agreement achieved?

Publish resulting domain specific and unified device models

YES

Define mapping rules between unified model and domain specific models

NO

Only 1 model for this device

class?

NO

YES Identify the device class

Aimed collaboration of SDOs on DAL

25

Joint work on ontology template document Map ontology template to BBF TRs (if needed) Jointly approaching domain specific organizations (verticals)

Joint work on GWD042 Map ontology template to OSGi technology 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)

Edit and align a GWD042 Liaise template to domain specific organizations

Instantiates GWD042 with their respective device characteristics

This figure is not at all comprehensive; it only shows a possible starting point.

Possible components of an abstract device model

26

DEVICE MODEL

Device (aka Home Device) SERVICE

SERVICE Device Function (aka DCO, HGI Modules)

SERVICE SERVICE

ACTION name parameter value types return value types

SERVICE SERVICE

Property name value type

SERVICE SERVICE

EVENT name event type payload

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.

• Would formal semantic description have any benefit?

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

OSGi devices (draft RFC)

29.10.2013 Page 28

OSGi device statuses (draft RFC)

Example: status online

OSGi device functions (draft RFC)

12/03/09

29.10.2013 Page 30

• 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

Example for using DAL

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

www.prosyst.com

Dr. Dimitar Valtchev CTO ProSyst Software d.valtchev@prosyst.com

Thank You!