OSGi Alliance Residential Expert Group

COPYRIGHT © 2009-2010 OSGi Alliance. All Rights Reserved

OSGi Alliance Residential Expert GroupCurrent ActivitiesJanuary 30, 2014OSGi Users‘-Forum Germany Meeting


OSGi Device Abstraction Layer

RFC 196

Common Device Representation

Page 2


Without Device Abstraction Layer

Complex implementations, multiple dependencies

10.04.23Page 3


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

10.04.23Page 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


Device Abstraction Layer – Real Solution, first steps

10.04.23Page 5


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

10.04.23Page 6


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:

10.04.23Page 7



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

10.04.23Page 8



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

10.04.23Page 9



• 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:

10.04.23Page 10



• 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:

10.04.23Page 11



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

10.04.23Page 12



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

10.04.23Page 13


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

10.04.23Page 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.

10.04.23Page 15


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.

10.04.23Page 16


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.

10.04.23Page 17


Device Abstraction Layer – Summary

10.04.23Page 18


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.

10.04.23Page 19


Device Abstraction Layer – Involved Parties – 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.

10.04.23Page 20


Device Abstraction Layer – Involved Parties – BinarySensor

org.osgi.service.functionaldevice.functions.BinarySensor

• No operations.• Supported properties:

• state – provides information about the current state

•The BinarySensor 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 opened/closed, started/stopped etc.

10.04.23Page 21


Device Abstraction Layer – Involved Parties – MultiLevelControl

org.osgi.service.functionaldevice.functions. MultiLevelControl • No operation.• Supported properties:

• level – provides information about the current state

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

•Next steps – we are working on the concrete types. In this way, we can map the level to something meaningful.

10.04.23Page 22


Device Abstraction Layer – Involved Parties – MultiLevelSensor

org.osgi.service.functionaldevice.functions. MultiLevelSensor

• No operation.• Supported properties:

• level – provides information about the current state

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

•Next steps – we are working on the concrete types. In this way, we can map the level to something meaningful.

10.04.23Page 23


Device Abstraction Layer – Involved Parties – Meter

org.osgi.service.functionaldevice.functions. Meter

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

• Supported properties:• 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:• value – reported value;• unit – the reported value unit;• timestamp – when the value is reported by the device or driver• additional metadata

•Next steps – we are working on the concrete types. In this way, we can map the metering information to something meaningful like water meter, gas meter etc.

10.04.23Page 24


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• additional metadata

•Next steps – we are working on the concrete types. In this way, we can map the metering information to something meaningful like water leak alarm.

10.04.23Page 25


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.

10.04.23Page 26


Device Abstraction Layer – Device Function Summary

10.04.23Page 27


External Links

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

10.04.23Page 28


Device Abstraction Layer – An example

10.04.23Page 29

• 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]);

}


Device Abstraction Layer – Example

10.04.23Page 30

•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();

}

}

Technology

OSGi Alliance Residential Expert Group