OSGi Alliance Residential Expert Group

OSGi Alliance Residential Expert Group
Current Activities
January 30, 2014
OSGi Users‘-Forum Germany Meeting

COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved

OSGi Device Abstraction Layer
RFC 196
Common Device Representation

Page 2


Without Device Abstraction Layer

Complex implementations, multiple dependencies

Page 3


30.01.14

Device Abstraction Layer – RFP boundaries
•

•

API applicable for all relevant device
protocols
• General device data model
• Access to common device
properties
• Access to the device states
• Access to device meta info
• Device operations
• Management operations
• Data operations
API solving common problems with device
access
• Avoiding protocol specific behavior
• Avoiding application workarounds
• Avoiding custom device abstractions
• Avoiding uncontrolled dependencies
Page 4

•

•
•

•

Access control based on user and
application permissions
• Fine-grained security control
• Full flexibility of OSGi security
model
Security features available in the device
protocols
A notification mechanism is needed for:
• Device state monitoring
• Device data model monitoring
• Device operations monitoring
Extension points for new protocols
• Dynamic extension points
• Protocol independent
• Available at runtime


30.01.14

Device Abstraction Layer – Real Solution, first steps

Page 5


30.01.14

Device Abstraction Layer – Involved Parties – Device

org.osgi.service.functionaldevice.Device
• Represents the device in the OSGi service 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
Page 6


30.01.14

Device Abstraction Layer – Device statuses
• Device online status – indicates that the device is
currently available for operation. Possible transitions from
and to that status are:

Page 7


30.01.14

• Device offline status – indicates that the device is
currently not available for operations. Possible transitions
from and to that status are:

Page 8


30.01.14

• Device processing status – indicates that the device is
currently busy with an operation. Possible transitions to
and from that status are:

Page 9


30.01.14

• Device not initialized status – indicates that the device is
not fully initialized by the OSGi driver. The device can be
initialized later when it’s awakened. Possible transitions to
and from that status are:

Page 10


30.01.14

• Device not configured status - indicates that the device
requires additional configuration to become completely
connected to the network. An example, an additional
button has to be pushed. Possible transitions to and from
that status are:

Page 11


30.01.14

• Device disabled status – indicates that the device is
disabled for operation. Possible transitions from and to
that status are:

Page 12


30.01.14

• Device removed status – indicates that the device is
removed from the network. It’ll be unregistered from the
OSGi service registry.

Page 13


30.01.14

Device Abstraction Layer – Device status detail
• Device status detail - holds the reason for the current
device status. For example, the device can be offline,
because the device is broken. We’ll have:
• status – offline
• status detail – device broken

Page 14


30.01.14

Device Abstraction Layer – Involved Parties –
DeviceFunction
org.osgi.service.functionaldevice.DeviceFunction
• Represent a specific device functionality in OSGi service
registry like MultiLevelSwitch, BinarySensor etc.
• Can provide a set of properties with:
• Access type – eventable, writable and readable
• Additional metadata – description, min and max value, measurement unit etc.

• Can provide a set of operations with:
• Metadata – description, arguments min and max value, arguments measurement
unit etc.

Page 15


30.01.14

Device Abstraction Layer – Device Function property
• Device Function property metadata:
• access type – represents the access to the function property
• eventable – the property value is reported with an event;
• writable – the property value can be changed;
• readable – the property value can be read;
• unit – represents the value unit;
• min and max value – if the property value cannot cross a given minimum or
maximum value;
• description – describes the property with a human readable description;
• values – contains a set of predefined values, which can be assigned to the
property;
• resolution – difference between two values in series.

Page 16


30.01.14

Device Abstraction Layer – Device Function operation
• Device Function operation metadata:
• input arguments – they are using the same metadata as Device Function property
from the previous slide;
• output argument – it’s using the same metadata as Device Function property from
the previous slide;
• description – human-readable operation description.

Page 17


30.01.14

Device Abstraction Layer – Summary

Page 18


30.01.14

Device Abstraction Layer – Involved Parties – functions
org.osgi.service.functionaldevice.functions
• There is a set of predefined device functions:
• BinaryControl – provides binary control support to manage functionalities based
on two state like: turnOn/turnOff, Start/Stop, Up/Down etc.
• BinarySensor – provides binary sensor monitoring like: motion/no motion
• MultiLevelControl – provides multi-level control support. Usual example is
dimmer, but can control any device with a set of acceptable values like temperature
control.
• MultiLevelSensor – provides multi-level sensor monitoring to collect information
about humidity, temperature etc.
• Meter – the meter can track metering information about electricity, water etc.
consumption
• Alarm – triggers an alarm event when the alarm sensor detects an alarm. It can
register an alarm because of smoke, water leak, heat etc.
• Keypad – provides information about a set of buttons.
Page 19


30.01.14

BinaryControl

org.osgi.service.functionaldevice.functions.BinaryControl
• Supported

operations:

• reverse – reverses the BinaryControl state i.e. if the current state is true, it’ll be
reversed to false and the opposite.
• setTrue – sets the BinaryControl state to true.
• setFalse – sets the BinaryControl state to false.

• Supported properties:
• state – provides information about the current state

• The BinaryControl data provides:
• value – reported value;
• timestamp – when the value is reported by the device or by the driver;
• additional metadata.

•Next steps – we are working on the concrete types. In
this way, we can map true and false to meaningful states
like open/close, start/stop etc.
Page 20


30.01.14

BinarySensor
org.osgi.service.functionaldevice.functions.BinarySensor

• No operations.
• state – provides information about the current state

•The BinarySensor data provides:
• timestamp – when the value is reported by the device or by the driver;
• additional metadata.

this way, we can map true and false to meaningful states
like opened/closed, started/stopped etc.

Page 21


30.01.14

MultiLevelControl
org.osgi.service.functionaldevice.functions. MultiLevelControl

• No operation.
• level – provides information about the current state

• MultiLevelControl data provides:
• unit – the reported value unit;
• timestamp – when the value is reported by the device or driver
• additional metadata

this way, we can map the level to something meaningful.

Page 22


30.01.14

MultiLevelSensor
org.osgi.service.functionaldevice.functions. MultiLevelSensor

• No operation.
• level – provides information about the current state

• MultiLevelSensor data provides:

this way, we can map the level to something meaningful.

Page 23


30.01.14

Device Abstraction Layer – Involved Parties – Meter
org.osgi.service.functionaldevice.functions. Meter

• Supported operations:
• resetTotal – resets the total metering information.

• total – contains information about the total metering information
• current – contains information about the current metering information
• flow – if you are producer, there’ll be out flow; if you are consumer, there’ll be in
flow.

• Meter data provides:

this way, we can map the metering information to
something meaningful like water meter, gas meter etc.
Page 24


30.01.14

Device Abstraction Layer – Involved Parties – Alarm
org.osgi.service.functionaldevice.functions. Alarm

• No operations.
•Supported properties:
• alarm – specifies the alarm property. It must be an eventable property.

• Alarm data provides:
• type – the alarm type
• severity – the alarm severity
• timestamp – when the alarm is triggered

this way, we can map the metering information to
something meaningful like water leak alarm.
Page 25


30.01.14

Device Abstraction Layer – Involved Parties – Keypad
org.osgi.service.functionaldevice.functions. Keypad

• No operations.
•Supported properties:
• key – specifies the property for the key from the keypad.

• Keypad data contains information about the key:
• key code;
• key name;
• type: pressed, long pressed, double pressed, double long pressed.

Page 26


30.01.14

Device Abstraction Layer – Device Function Summary

Page 27


30.01.14

External Links
• https://github.com/osgi/design/blob/master/rfcs/rfc0196/
rfc-0196-DeviceAbstractionLayer.pdf

Page 28


30.01.14

Device Abstraction Layer – An example
• 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]);
}

Page 29


30.01.14

Device Abstraction Layer – Example
•The code snippet sets to true all BinaryControl functions.
final ServiceReference[] binaryControlSRefs =
context.getServiceReferences(BinaryControl.class.getName(),
null);
if (null == binaryControlSRefs) {
return; // no such services
}
for (int i = 0; i < binaryControlSRefs.length; i++) {
final BinaryControl binaryControl = (BinaryControl)
context.getService(binaryControlSRefs[i]);
if (null != binaryControl) {
binaryControl.setTrue();
}
}

Page 30


30.01.14

OSGi Alliance Residential Expert Group

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie OSGi Alliance Residential Expert Group

Ähnlich wie OSGi Alliance Residential Expert Group (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

OSGi Alliance Residential Expert Group