6 Mapping of OSGi DAL

6.1 Introduction

The OSGi DAL (Device Abstraction Layer) [i.2] is an OSGi defined service to unify interfaces for accessing devices. By using the OSGi DAL, application developers do not need to deal with protocol details to interact with different types of devices such as sensors, actuators, etc.

Figure 6.1‑1: OSGi DAL [i.2]

OSGi DAL is comprised of several services:

• Device: represents the registered device in the OSGi framework. The device service contains properties describing the device's metadata and context information. The device service has one or more function services.
• Function: represents the function provided by the device. The function could be data reporting or actuating. The function provides a set of FunctionData, properties and operations. A property is the data information that can be accessed by the application. An operation is the interface that can be invoked by an application to trigger a certain procedure. The function also posts FunctionEvent.
• FunctionEvent: represents the asynchronous event of the function. Once the event is triggered, the event is handled by the registered event handler.
• FunctionData: represents the data structure that contains the property and metadata of the function.
• PropertyMetadata: represents the metadata of the function property.
• OperationMetadata: represents the metadata of the function operation.

6.2 Device service

The device service defined by OSGi DAL maps to a oneM2M NoDN and is represented as a specialized resource and a resource.

The OSGi device service itself shall be mapped to a specialized resource of a specific device model that the OSGi device service instance represents. The properties of an OSGi device service shall be mapped to the attributes of the resource, the resource, and its child [deviceInfo] resource.

Once an OSGi device service is registered at the OSGi framework, the IPE shall be responsible for acquiring all OSGi device service properties and other related services (such as OSGi function services) and creating the corresponding resources on the oneM2M CSE.

Upon the registration of an OSGi device service, the IPE should create a resource and a [deviceInfo] specialization as the child resource of the resource. The IPE should also create one__ resource with specialized mandatory [customAttribute] as a 'nodeLink' attribute, which links to a resource that is hosted on the same hosting CSE of the . The mapping between OSGi device and oneM2M resources shall be as follows.

Table 6.2‑1: Mapping of OSGi device service to oneM2M resources

6.3 Function service

6.3.1 Introduction

An OSGi function service maps to a specialized resource that correspond to a moduleClass specified in oneM2M TS-0023 [1]. An OSGi function service may be mapped to different s that correspond to different moduleClasses depending on the OSGi device service that the OSGi function service belongs to.

Table 6.3.1‑1: Mapping of OSGi function to oneM2M resources

6.3.2 BooleanControl Function

BooleanControl function is used for switch-type of device functions like a light, door, window or power socket. It maps to the binarySwitch that is a moduleClass.

Table 6.3.2‑1: Mapping of BooleanControl function to binarySwitch moduleClass

6.3.3 BooleanSensor Function

BooleanSensor function is used to report the data of a device function such as a light, door, window or power socket. It maps to several different resources that are moduleClass. It is based on the device type which determines the specialization of to be mapped to.

Table 6.3.3‑1: Mapping of BooleanSensor function to binarySwitch moduleClass

Table 6.3.3‑2: Mapping of BooleanSensor function to doorLock moduleClass

Table 6.3.3‑3: Mapping of BooleanSensor function to boiler moduleClass

Table 6.3.3‑4: Mapping of BooleanSensor function to waterSensor moduleClass

6.3.4 MultiLevelControl Function

The MultiLevelControl Function maps to different moduleClass depending on the device type.

Table 6.3.4‑1: Mapping of MultiLevelControl function to brightness moduleClass

Table 6.3.4‑2: Mapping of MultiLevelControl function to foaming moduleClass

6.3.5 MultiLevelSensor Function

The MultiLevelSensor Function maps to different moduleClass depending on the device type.

Table 6.3.5‑1: Mapping of MultiLevelControl function to height moduleClass

Table 6.3.5‑2: Mapping of MultiLevelControl function to weight moduleClass

Table 6.3.5‑3: Mapping of MultiLevelControl function to liquidRemaining moduleClass

Table 6.3.5‑4: Mapping of MultiLevelControl function to brightness moduleClass

Table 6.3.5‑5: Mapping of MultiLevelControl function to foaming moduleClass

6.3.6 Meter Function

The Meter Function maps to different moduleClass depending on the device type.

Table 6.3.6‑1: Mapping of Meter function to energyConsuption moduleClass

6.3.7 Alarm Function

The Alarm Function maps to different moduleClass depending on the device type.

Table 6.3.7‑1: Mapping of Alarm function to motionSensor moduleClass

Table 6.3.7‑2: Mapping of Alarm function to smokeSensor moduleClass

Table 6.3.7‑3: Mapping of Alarm function to temperatureAlarm moduleClass

Table 6.3.7‑4: Mapping of Alarm function to waterSensor moduleClass

6.3.8 Keypad Function

The Keypad Function maps to keypad moduleClass of oneM2M.

Table 6.3.8‑1: Mapping of Keypad function to keypad moduleClass

6.3.9 WakeUp Function

This Function currently has no corresponding moduleClass in oneM2M.

6.4 Device service procedure

The IPE is responsible for monitoring the OSGi Device service and synchronizing the properties of the Device service to attributes of the oneM2M resources.

Figure 6.4‑1: Procedure of registering Device service

The mapping of resources shall follow the definition in oneM2M TS-0033 [2] proximal IoT interworking. Depending on the available properties of the Device service, resource, resource, resource or resource may be used to represent the Device service.

6.5 Function service procedure

The IPE is responsible for monitoring the Function property and synchronizing the change of the property to oneM2M resources. The IPE is also responsible for monitoring the update of the oneM2M resource that corresponds to the Function operation. Upon receiving the request targeting the resource, the IPE shall invoke the corresponding Function operation.

Figure 6.5‑1: Procedure of registering function service

Monitors the registration: The IPE monitors the registration of the Function service to the OSGi framework.

Create resource: The IPE creates the corresponding resource to the oneM2M CSE.

Figure 6.5‑2: Procedure of changing function property

Change of Function property: The Function property may be changed due to various reasons such as hardware triggered break, sensor change, local application change etc.

Monitors the change: The IPE monitors the change by subscribing to the eventable properties, acquiring the property periodically or by some other internal call back functions.

Update the resource: The IPE updates the corresponding resource of the Function.

Figure 6.5‑3: Procedure of invoking function operation

Update resource: The oneM2M CSE receives update requests from applications to update the resource that corresponds with the Function service.

Monitors the change: The IPE monitors the change by subscribing to the resource and receiving notifications or polling etc.

Invoke the function operation: The IPE invokes the function operation provided by the Function service.