1. On a Device Information Model for devices in oneM2M
MAS
On a Device Information Model for devices in oneM2M
Joerg Swetina, NEC Laboratories Europe

2. How are devices treated in oneM2M ?
Every type of devices has its own Device Information Model…
oneM2M Devices
CSE
CSE
Device Information Model AE AE
Mca
Mcc
legacy (non-oneM2M) Devices and [non-IP] Area Networks
CSE
Device Information Model
CSE
IPE (Application) AE
Area NW
Mcc
IPE … Inter-working Proxy Application Entity

3. Who contributes to the Device Information Model
Manufacturer defines (at least) Syntactic Device model
Input- Output operations
Enables creation of (oneM2M) representations - resources
syntactic interoperability
Manufacture specific data
Domain specific
Manufacturer
CSE AE
Context specific
Cross-domain stakeholders may define context specific extensions Location information
Relationships to things
Usage for Virtual Devices
Enables linking device types to the context they are used in
Domain stakeholder (e.g. HGI) defines domain specific Semantic Device model
Generic naming of device types operation types …
Abstract devices
semantic interoperability

4. Some facts about device types (not only IP capable ones !!)
Note, this is about types of devices, not individual instances !
A device always contains
Either only a receiver (e.g. a remote controlled power plug – only supports Input operations, no ACK possible!)
or only a sender (e.g. a humidity sensor that periodically reports measurements – only supports Output operations)
or both (e.g. an IP connected device)
Input- and output operations may be correlated - by the used transport protocol - to each other (e.g. a Response is linked to a specific Request)
A physical device has some sensor- and/or actuator hardware that interact with the physical world. Abstract / virtual devices do not necessarily have such hardware.
A physical device contains hardware modules that manage the communication of the device via some M2M Area Network.
The device has an address within the Area Network. The addressing scheme is determined by the type of the Area Network

5. Some facts about device types (II)
A physical device contains hardware that can be described in terms of its physical properties (e.g. Battery capacity, Allowed operating temperature range …). These properties can be
Static (e.g. Allowed operating temperature range) or
Dynamic (e.g. current load level of the battery)
A device (physical or abstract/virtual) has properties related to its operation, e.g.
A set of states that any instance of that device is in.
A device (physical or abstract/virtual) has some none-physical properties - ‘meta-information’, e.g.
Name/Identifier of manufacturer
Model identifier, Universal Product Code, Serial number ...

6. Device Information Model (Also called Device Capability) and “Device Model Template”
“Device Information Model” contains: The information on a device type as indicated above can formally be described (e.g. as XML document) in an information model of that device type.
Must at least contain all input- and output- operations of a device type but can contain more information.
Is system- (protocol/hardware/software) independent
Can be de used to create system specific representations (e.g. oneM2M resources)
A “Device Model Template” would be the schema (e.g. specified as a XSD document) that specifies what parameters constitute the information model of (any) device. “Device Model Template” needs to be a collaborative work of multiple SDOs
Is manufacturer (and protocol- and hardware/software) independent
Should allow to be extensible but it should contain sufficiently many parameters to be able to describe most device types without extension.

7. Putting the picture together
The Device Template is created through collaboration among SDOs
Manufacturers create Device Information Models
Representations in target systems (defined through e.g. a Interworking Proxy Application Entity - IPE)
Instances (individual devices in a specific system)
Device Information Model:
Device Type A
The Device Template
Device Information Model:
Device Type B (Manufacturer YY)
ZigBee representation of Device Type C
Device Information Model:
Device Type C (Manufacturer ZZ)
Extension with semantic information by Domain- and Cross- domain stakeholder
oneM2M representation of Device Type C
Instance 1
Instance 2
Instance 3
Device Information Model can be extended by Domain- and Cross- domain stakeholder

8. Information Model contains Input- Output operations of a device
Example of a washing machine – I/O operations consist of 3 kinds of data:
Names
I/O data types
Communication pattern
Input operation type 1
Name: Start / Pause
I/O type: binary
communication pattern: Instruction (unacknowledged)
Input operation type 2
Name: Spin Selection
I/O type: no-type
communication pattern: Instruction (acknowledged)
Output operation type 1
Name: Spin speed display
I/O type: selection 1 out of “OFF”, “MED”, “MAX”
communication pattern: Notification (response to Input operation type 2)
Input operation type 3
Name: Function Selector
I/O type: complex type:
Selection “OFF”
Selection “COTTONS”
Select integer from: min-value = 30 max-value = 90 min-step = 10
Selection “SPECIALS” …

9. Input- Output operations (II)
I/O data types:
I/O data types are data types (like boolean, integer, ... or more complex structures) together with their restrictions (e.g. maximum/minimum values, stepsize …) and describe:
For input: all acceptable input values for the device
For output: all possible output values
I/O data types correspond to Datatypes in XML Schema of W3C
Names
Give names to operation types to make them distinguishable
Give names to parameters. e.g in a “SELECTION”

10. Input- Output operations (III)
communication patterns:
Describe the direction of data-flow (Input or Output)
Can be:
Notification (device asynchronously transmits data to the device’s peer)
pushing data device => peer e.g. periodic reporting of humidity. Is also possible when device has only “sender” functionality
Instruction (peer entity issues a request, carrying the data, to the device )
pushing data device <= peer e.g. a remote controlled power switch. Is also possible when device has only “receiver” functionality
Can be acknowledged by the device through a correlated - immediate or separate - “Notification” if device has also “sender” function
Input- Output operations allow syntactically correct, yet application independent communication with a device, => syntactic interoperability !

11. Semantics added to the Information model
Semantics provide additional parameters of the device type as well as meta-information.
Semantics are not needed for syntactic interoperability.
Examples:
Semantic information provided my manufacturer:
Manufacturer is “Candy”
Model is “GOF462S”
The address type is “WiFi” (can be accessed through a WiFi Area NW)
Input operation “Start / Pause” does the following: When setting binary state “TRUE” this starts the washing process according to the current state of all other input operation variables.
Semantic information provided by Domain stakeholder
The generic name of this device type is “Washing Machine”
Semantic information provided by Cross-Domain stakeholder (e.g. home management system)
A device of type “Washing Machine” may have a relationship “is_located” with a thing of type “Room”

12. Proposal for way forward in oneM2M
Elaborate and agree on the oneM2M view (responsibilities ...) on Device Information Model
Manufacturer, Domain stakeholder, Cross-Domain stakeholder
Check what parameters, from oneM2M point of view,
must to be contained in the Device Information Model (required for syntactic interoperability)
should additionally be contained in the Device Information Model (semantic information for semantic interoperability and for describing context)
Create an example (toy Device Information Model) and show the mapping into oneM2M resources
Send all of that to other SDOs such that these SDOs can create the Device Template.