OSGi Community Event 2013 (http://www.osgi.org/CommunityEvent2013/Schedule) ABSTRACT OSGi is gaining popularity as enabling technology for building embedded systems 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, EnOcean, etc. In order to provide a convenient programming model suitable for the realization of end-to-end services it is very important to apply an abstraction layer which unifies the work with devices supporting different protocols. A specification work covering this topic has been already started by OSGi Alliance in cooperation with organizations such as HGI, ETSI M2M, BBF and OneM2M. This presentation comments the existing approaches for the realization of device abstraction in OSGi. Special attention is paid to the requirements making such an abstraction suitable for interactions with cloud based applications and services. A reference architecture based on the experience gained from numerous commercial projects is presented and explained. SPEAKER BIO Dr. Dimitar Valtchev is Chief Technology Officer of ProSyst Software. His main technical interests are in the fields of embedded systems, device management and distributed computing. Recently Dimitar has been involved in numerous residential and automotive projects using the OSGi technology. He believes in the power of open systems/architectures and actively participates in the work of organizations such as HGI and OSGi Alliance. Dimitar is a senior member of IEEE and holds MS in Electronics, MS in Computer Science and PhD in Electrical Engineers degrees from the Technical University of Sofia.

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

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
d.valtchev@prosyst.com
www.prosyst.com
32