On a Device Information Model for devices in oneM2M MAS-2014-0331 On a Device Information Model for devices in oneM2M Joerg Swetina, NEC Laboratories Europe

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

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

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

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

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.

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

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” …

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”

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 !

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”

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.