6.2 The Resource Mapping Rules
6.2.1 Introduction
The present clause specifies the rule to map the "Harmonized Information Model" to oneM2M resources.
6.2.2 Resource mapping for Device model
When the AE exposes a controlling interface for a home domain device which is specified as an information model in clause 5.5, a specialization of the <flexContainer> resource shall be created as the mapping of the model following conversion rules:
-
Rule 1-1: Each Device model defined in clause 5.5 shall be mapped to a specialization of <flexContainer>. The containerDefinition attribute shall be set according to clause 6.4.2.
-
Rule 1-2: Each entry in the 'Module' table shall be mapped to a child resource(s) which is mapped as a specialised <flexContainer> following the rule in clause 6.2.3.
-
Rule 1-3: The specialized <flexContainer> resource of the Device model may contain an optional attribute nodeLink (as defined in oneM2M TS-0001[3] and in oneM2M TS-0004[4]). The value of nodeLink shall be set to the resource identifier of a <node> resource described in Rule 1-5 below. See also clause Rule 1-8.
-
Rule 1-4: XSD file for each Device model shall be named according to clause 6.5.2.
-
Rule 1-5: A <node> resource shall be created on the same hosting CSE as the <flexContainer> representing this Device model. If the <node> resource does not contain a [flexNode] child resource (see Rule 1.7), then it contains all the management information as specialized <mgmtObj> resources (e.g. [firmware]) about the Device model instance for device management purposes.
-
Rule 1-6: Void.
-
Rule 1-7:The <node> resource targeted by the nodeLink attribute may have a [flexNode] child resource. This [flexNode] resource contains all the Device Management information as specialized <flexContainer> resources defined in clause 5.8 (e.g. [dmFirmware]) about the device model instance for Device Management purposes.
-
Rule 1-8: Void.
-
Rule 1-9: Each entry in the 'SubDevice' table shall be mapped to a child resource(s) which is mapped as a specialised <flexContainer> following the rule in clause 6.2.7.
-
Rule 1-10: Each <flexContainer> associated to a Device model may have as child resource any <flexContainer> associated to a ModuleClass model of the Metadata domain defined in clause 5.3.9.
In other words, all devices implicitly have the following lines in their modules table:
Table 6.2.2-1: Modules of deviceXXX model
Module Instance Name | Module Class Name | Multiplicity | Description |
---|---|---|---|
<any module in mdd domain> | <any module in mdd domain> | 0..N | See clause 5.3.9. |
6.2.3 Resource mapping for ModuleClass
The ModuleClass models shall be mapped to the specializations of a <flexContainer> resource. The following rules shall be applied:
When the Device or SubDevice models in clauses 5.4, 5.5, 5.8.1 or 5.8.9 are mapped to the <flexContainer> resource, and if the device or sub-device supports the functionality associated with a ModuleClass in the model, a <flexContainer> resource which is mapped from ModuleClass definitions shall be created as a child resource:
- Rule 2-1: The containerDefinition attribute shall be set according to clause 6.4.3.
- Rule 2-2: Each entry of 'Action', 'Property', and 'DataPoint' in ModuleClass definitions shall be mapped following the resource mapping rules described in clauses 6.2.4 to 6.2.7 .
- Rule 2-3: XSD file for each ModuleClass shall be named according to clause 6.5.3.
- Rule 2-4: The resourceName attribute for each module class that appears as a child of a Device or SubDevice model shall be CREATED with the value set to "Module Instance Name". If the module class is contained in a list (multiplicity 0..N or 1..N), its resourceName attribute shall be set to "Module Instance Name" appended with an underscore '_' and an incrementing index so that it is unique in the parent's children (e.g. "firmware_0", "firmware_1", etc.). The index shall not have leading 0's.
- Rule 2-5: The specialized <flexContainer> resource of the Module model may contain an optional [customAttribute] named dataGenerationTime. The value of dataGenerationTime contains the time when the data was generated by the device. The data type of this custom attribute is m2m:timestamp.
6.2.4 Resource mapping for Action
Actions defined as part of a ModuleClass model shall be mapped to the specializations of a <flexContainer> resource. The following rules shall be applied:
- Rule 3-1: The containerDefinition attribute shall be set according to clause 6.4..
- Rule 3-2: When the Action supports any 'Arguments', they are mapped to [customizedAttribute] with their variable names (short names are given in clause 6.3.4). When the Action supports a 'Return Type', it is mapped to a [customizedAttribute] named 'result' (short name 'resut'). The keyword 'result' is reserved and cannot be used as an Argument name.
- Rule 3-3: XSD file for each Action shall be named according to clause 6.5.4.
-
Rule 3-4: The Action shall be triggered:
- by updating at least one of the Arguments custom attributes with any value, if the action has at least one argument; or
- by updating the <flexContainer> resource with empty content if it has no argument.
-
Rule 3-5: The resourceName attribute for each Action model that appears as a child of a ModuleClass model shall be CREATED with the value set to "Action name".
- Rule 3-6: If an action returns a value that is of a complex data type, i.e. not one of the standard scalar types, then this value shall be encoded as a JSON structure and returned serialized in an xs:string.
6.2.5 Resource mapping for Property
When the Device model (in clause 5.5) or the ModuleClass model (in clause 5.3) is mapped to the <flexContainer> resource, and if the device supports a Property, the following rules shall be applied:
- Rule 4-1: Each entry of 'Property' table in ModuleClass model, shall be mapped to the [customAttribute] of <flexContainer> resource which is mapped from associated ModuleClass model, with its Property name with prefix 'prop'.
- Rule 4-2: If the <node> resource targeted by the nodeLink attribute of a Device model does not have a [flexNode] child resource, then each 'Property' of the Device model is mapped to a specialized [objectAttribute] of a [deviceInfo] <mgmtObj> resource child of this <node>, otherwise it is mapped to a [customAttribute] of a [dmDeviceInfo] <flexContainer> resource child of this [flexNode].
- Rule 4-3: Each entry of 'Property' table in SubDevice model, shall be mapped to the [customAttribute] of <flexContainer> resource which is mapped from associated SubDevice model, with its Property name with prefix 'prop'.
6.2.6 Resource mapping for DataPoint
When the ModuleClass model (in clause 5.3) is mapped to the <flexContainer> resource, and if the ModuleClass supports a DataPoint, the following rules shall be applied:
- Rule 5-1: Each entry of DataPoint table in ModuleClass model, shall be mapped to [customAttribute] of <flexContainer> resource which is mapped from associated ModuleClass model, with its DataPoint name.
6.2.7 Resource mapping for SubDevice model
The SubDevice models (in clause 5.4 or 5.8.9) shall be mapped to the specializations of a <flexContainer> resource. The following rules shall be applied:
-
When the SubDevice model in clause 5.4 or 5.8.9 is mapped to the <flexContainer> resource, and if the device supports the functionality associated with a SubDevice in the model, a <flexContainer> resource which is mapped from SubDevices definitions shall be created as a child resource.
-
Rule 7-1: The containerDefinition attribute shall be set according to clause 6.4.5.
-
Rule 7-1a: Each entry in the 'Module' table shall be mapped to a child resource(s) which is mapped as a specialised <flexContainer> following the rule in clause 6.2.3.
-
Rule 7-2: The XSD file for each SubDevice model shall be named according to clause 6.5.5.
-
Rule 7-3: void
-
Rule 7-4: The resourceName attribute for each SubDevice that appears as a child of a Device or FlexNode model shall be created with the value set to "SubDevice Instance Name". If the SubDevice is contained in a list (multiplicity 0..N or 1..N), its resourceName attribute shall be set to "SubDevice Instance Name" appended with an underscore '_' and an incrementing index so that it is unique in the parent's children (e.g. "cuff_0", "cuff_1", etc.). The index shall not have leading 0's.
-
Rule 7-5: Each <flexContainer> associated to a SubDevice model may have as child resource any <flexContainer> associated to a ModuleClass model of the Metadata domain defined in clause 5.3.9.
-
In other words, all subdevices implicitly have the following lines in their modules table:
-
Table 6.2.7-1: Modules of subDeviceXXX model
Module Instance Name | Module Class Name | Multiplicity | Description |
---|---|---|---|
<any module in mdd domain> | <any module in mdd domain> | 0..N | See clause 5.3.9. |