MAS2014 0331 R 01 On a Device Information

MAS-2014 -0331 R 01 On a Device Information Model for devices in one. M 2 M Joerg Swetina, NEC Laboratories Europe

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

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

Some facts about device types (not only IP capable ones !!) Note, this is about types of devices, not individual instances ! ▐ A device always contains l Either only a receiver (e. g. a remote controlled power plug – only supports Input operations, no ACK possible!) l or only a sender (e. g. a humidity sensor that periodically reports measurements – only supports Output operations) l 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 M 2 M Area Network. l The device has an address within the Area Network. The addressing scheme is determined by the type of the Area Network Page 4 MAS-2014 -0331 R 01

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 l Static (e. g. Allowed operating temperature range) or l Dynamic (e. g. current load level of the battery) ▐ A device (physical or abstract/virtual) has properties related to its operation, e. g. l 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. l Name/Identifier of manufacturer l Model identifier, Universal Product Code, Serial number, and other information that can e. g. support Device Registration need, etc. Page 5 MAS-2014 -0331 R 01

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. l Must at least contain all input- and output- operations of a device type but can contain more information. l Is system- (protocol/hardware/software) independent l Can be de used to create system specific representations (e. g. one. M 2 M 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 l Is manufacturer (and protocol- and hardware/software) independent l Should allow to be extensible but it should contain sufficiently many parameters to be able to describe most device types without extension. Page 6 MAS-2014 -0331 R 01

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

Information Model contains Input- Output operations of a device ▐ Example of a washing machine – I/O operations consist of 3 kinds of data: l Names l I/O data types l Communication pattern Input operation type 1 • Name: Start / Pause • I/O type: binary • communication pattern: Instruction (unacknowledged) 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) Page 8 MAS-2014 -0331 R 01 Input operation type 2 • Name: Spin Selection • I/O type: no-type • communication pattern: Instruction (acknowledged) 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: l 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 l I/O data types correspond to Datatypes in XML Schema of W 3 C ▐ Names l Give names to operation types to make them distinguishable l Give names to parameters. e. g in a “SELECTION” Page 9 MAS-2014 -0331 R 01

Input- Output operations (III) ▐ communication patterns: l Describe the direction of data-flow (Input or Output) l 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 ! Page 10 MAS-2014 -0331 R 01

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. l Examples: • Semantic information provided my manufacturer: – – Manufacturer is “Candy” Model is “GOF 462 S” The address type is “Wi. Fi” (can be accessed through a Wi. Fi 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” Page 11 MAS-2014 -0331 R 01

Proposal for way forward in one. M 2 M ▐ Elaborate and agree on the one. M 2 M view (responsibilities. . . ) on Device Information Model l Manufacturer, Domain stakeholder, Cross-Domain stakeholder ▐ Check what parameters, from one. M 2 M point of view, l must to be contained in the Device Information Model (required for syntactic interoperability) l 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 one. M 2 M resources Send all of that to other SDOs such that these SDOs can create the Device Template. Page 12 MAS-2014 -0331 R 01

Page 13