osgi based device abstraction for enabling m2m services · pdf fileosgi based device...
TRANSCRIPT
OSGi based device abstraction for enabling M2M services
Dr. Dimitar Valtchev
CTO ProSyst Software
12/03/09
ETSI M2M Workshop, 6-7 November, Mandelieu
Smart Home architecture based on OSGi
OSGi Alliance Marketing © 2008-2011 .
All Rights Reserved Page 2
12/03/09
ProSyst product offering
3
Modular platforms w/ APIs & add.
functionality
Tools & SDKs
Remote Management
Server
Gateway-centric M2M architecture
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
4
Smart home architecture with DAL
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
HOME GATEWAY
PLATFORM
UI Devices
5
Requirements to 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 HGI 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
6
Applications
DCO b1
DCO bn
DCO a1
DCO an
Java, JSON, REST
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, REST
7
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/2
8
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
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.
There are special devices classes which provides management functionality. These, for example, monitor the devices, configure them, make firmware update, etc.
HDM Features 2/2
9
HDM 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
Keypad
Your Need
Record Actuator
Zoom Actuator
Move Actuator
Image Provider
Video Provider
10
Abstraction of zones
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
11
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
12
HOME GATEWAY
HGI reference architecture
13
• 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 14 14
Possible components of an abstract device model
15
DEVICE MODEL
Functional 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, or even TR-106 based?
• Would formal semantic description have any benefit?
OSGi device functions (draft RFC)
12/03/09
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 17 17
