|Document Name: |SDT based Information Model and Mapping for Vertical Industries |
|Date: |2024-06-27 |
|Abstract: |This technical specification includes oneM2Mdefined information model for home appliances and the mapping with other information models from external organization. |
|Abstract: |This technical specification includes oneM2M-defined information models for appliances from various vertical industries and the mapping with other information models from external organizations. |
|Template Version: January 2017 (Do not modify) |Template Version: January 2017 (Do not modify) |
<mark>Editor's note: We need to decide how the Phrase "oneM2M Technical Specification" in the table header above is been formatted. In the original word document this is single line (using col-span)</mark>
...
...
@@ -49,7 +49,7 @@ NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURA
# 1 Scope
The present document describes the oneM2M defined information model for home appliances, including the description of how it is mapped with other information models from external organizations. It also explains the ontology for the home domain information model.
The present document describes the oneM2M defined information model for appliances from various vertical industries, including the description of how it is mapped with other information models from external organizations. It also explains the ontology for the Harmonized Information Model.
# 2 References
...
...
@@ -184,7 +184,7 @@ For the purposes of the present document, the following abbreviations apply:
`DWAPI Device Web Application Programming Interface`
`DWAPI-3DP Device Web Application Programming Interface for 3D printer`
`DWAPI-PCH Device Web Application Programming Interface for Personal Connected Healthcare`
`HIM Harmonized Information Model`
# 4 Conventions
...
...
@@ -194,44 +194,40 @@ The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in
# 5 Harmonised Information Model
## 5.1 Introduction
The present document intends to provide the unified means in the oneM2M system by defining a home appliance information model for the home domain devices such as TV, refrigerator, air conditioner, clothes washer, oven, and robot cleaner. For the reasons of interworking with external technologies and efficiency, the principle of the home appliance information model is designed based on HGI SDT 3.0 <ahref="#_ref_1">[1]</a>.
The principle of defining the home appliance information model is introduced in clause 5.2. ModuleClasses which oneM2M systems support are explained in clause 5.3. In the subsequent clause 5.5, Device models are defined.
The present document intends to provide the unified means in the oneM2M system by defining a Harmonized Information Model (HIM) for the devices such as TV, refrigerator, air conditioner, clothes washer, oven, and robot cleaner. For the reasons of interworking with external technologies and efficiency, the principle of the Harmonized Information Model is designed based on HGI SDT 3.0 <ahref="#_ref_1">[1]</a>.
<mark>Editor's note: this clause has to be updated (remove specific references to Home).</mark>
The principle of defining the Harmonized Information Model is introduced in clause [5.2 Design Principle of the Harmonised Information Model](#52-design-principle-of-the-harmonised-information-model). Module Classes which oneM2M systems support are explained in clauses [5.3 ModuleClasses](#53-moduleclasses). In the subsequent clauses [5.4 SubDevice models](#54-subdevice-models) and [5.5 Device models](#55-device-models), Sub-Device and Device models are defined.
## 5.2 Design Principle of the Harmonised Information Model
### 5.2.1 Basic design principle of information modelling
<mark>Editor's note: this clause has to be updated (removed specific references to Home). Also, text added for this clause</mark>
The design principle of the oneM2M abstract information model of home appliance, is to use SDT4.0 originally introduced in oneM2M TR0017 <ahref="#_ref_i.2">[i.2]</a>. Note that those terms starting with a capital letter in this clause are SDT terms and are explained in <ahref="#_ref_1">[1]</a>.
The design principle of the oneM2M Harmonized Information Model is to use SDT4.0 originally introduced in oneM2M TR0017 <ahref="#_ref_i.2">[i.2]</a>. Note, that those terms starting with a capital letter in this clause are SDT terms and are explained in <ahref="#_ref_1">[1]</a>.
Domain is a unique name which acts like a namespace (e.g., "org.oneM2M.home.modules"). It is set by the organization creating the SDT, allowing reference to a package of definitions for the contained ModuleClasses and DeviceClass models.
**Domain** is a unique name which acts like a namespace (e.g., "org.onem2m.home.modules"). It is set by the organization creating the SDT, allowing reference to a package of definitions for the contained ModuleClasses and DeviceClass models.
ModuleClasses specifies a single service (e.g., [audioVolume](#5318-audiovolume), powerOn/Off) with one or more Actions, Properties, DataPoints and Events. Each service which is described as a ModuleClass can be re-used in many DeviceClasses.
**ModuleClasses** specifies a single service (e.g., [audioVolume](#5318-audiovolume), powerOn/Off) with one or more **Actions**, **Properties**, **DataPoints** and **Events**. Each service which is described as a ModuleClass can be re-used in many DeviceClasses.
DeviceClass model is a physical, addressable, identifiable appliance, sensor and actuator with one or more ModuleClasses, Properties and SubDevices.
**DeviceClass** model is a physical, addressable, identifiable appliance, sensor and actuator with one or more ModuleClasses, Properties and SubDevices.
SubDevice is a device which may be embedded in a DeviceClass and/or is addressed via another DeviceClass.
**SubDevice** is a device which may be embedded in a DeviceClass and/or is addressed via another DeviceClass.
Figure 5.2.1-1 depicts the basic structure of SDT 4.0. Further details about SDT 4.0 and its elements can be found in <ahref="#_ref_1">[1]</a>.
Specifications of new DeviceClass models and ModuleClasses are encouraged to re-use the definitions specified in the present document as much as possible. If re-use is not possible and new DeviceClass and/or ModuleClases definitions are necessary, it is strongly advised to closely follow the guidelines and definition style from the present document.
Specifications of new DeviceClass models and ModuleClasses are encouraged to re-use the definitions specified in the present document as much as possible. If re-use is not possible and new DeviceClass and/or ModuleClasses definitions are necessary, it is strongly advised to closely follow the guidelines and definition style from the present document.
**Figure 5.2.1-1: Design Structure of the Home Appliance Information Model using SDT 4.0**-
**Figure 5.2.1-1: Design Structure of the Harmonized Information Model using SDT 4.0**-
The R/W column of the ModuleClasses' data point tables in clause 5.3 reflects the intentions of how a data point in a ModuleClass shall be used semantically. This is a "behavioural contract" between applications or users of the modelled devices on the semantic level. Further, the devices or IPE's (for NoDN) are expected to implement and control the mappings in clause 5.2.2 to implement this "behavioural contract".
The R/W column of the ModuleClasses' data point tables in clause [5.3](#53-moduleclasses) reflects the intentions of how a data point in a ModuleClass shall be used semantically. This is a "behavioural contract" between applications or users of the modelled devices on the semantic level. Further, the devices or IPE's (for NoDN) are expected to implement and control the mappings in clause [5.2.2](#522-description-rules-for-module-classes-and-deviceclasses) to implement this "behavioural contract".
### 5.2.2 Description rules for Module Classes and DeviceClasses
When the Home Appliances Information Model is described based on SDT, the following rules shall be applied:
When the Harmonized Information Model is described based on SDT, the following rules shall be applied:
- Rule 1: CamelCase rule:
...
...
@@ -345,7 +341,7 @@ When the Home Appliances Information Model is described based on SDT, the follow
- Device operations, which are executed when setting data points to specific values, may take some time to reach the desired result. For example, setting a new temperature to a heater does not immediately change the room temperature, but it may take some time for the heater to increase the temperature. Therefore, it is sometimes necessary to distinguish between current and target data points.
- A ModuleClass shall provide an additional "target" data point when the "current" data point ...
- is writable, and
- is writeable, and
- the functionality that is mapped to the data point is an operation, not a configuration function, and
- the operation may take some time to start and/or to complete, or reach the desired result.
- When a ModuleClass provides current and target data points then the name for the current data point shall have the prefix "current", and the name for the target data point shall have the prefix "target". Both data points shall have the same suffix, for example "currentTemperature" and "targetTemperature".
...
...
@@ -855,7 +851,7 @@ This ModuleClass provides capabilities to monitor network connectivity.
|dailyActivityTime |xs:integer |R |true |s |Daily communication time (Starts at 00:00h). |
|dailyNumberOfConnections |xs:integer |R |true | |Daily number of connections (Starts at 00:00h). |
|commFreqValue |xs:integer |R |true |MHz |Communication frequency value (commFreqValue) is the transmission frequency of the wireless signal. |
|currentCycleBeginn |xs:datetime |R |true | |A timestamp that indicates the beginning of the current cycle for counting the transfer volumina and transmission errors. |
|currentCycleBeginn |xs:datetime |R |true | |A timestamp that indicates the beginning of the current cycle for counting the transfer volume and transmission errors. |
|currentCycleVolume |xs:integer |R |true |bytes |Number of bytes transferred since currentCycleBeginn. |
|currentCycleTransmissionErrors |xs:integer |R |true | |Number of transmission errors since currentCycleBeginn. |
|minimumCommunicationLatency |xs:integer |R |true |s |The minimum time delay between the last communication attempt. |
...
...
@@ -985,7 +981,7 @@ This ModuleClass provides information about generation data on electric generato
|roundingEnergyGeneration |xs:integer |R |true | |This energy consumption data is calculated by multiplying significantDigits with multiplyingFactors, and rounding down the result. |
|significantDigits |xs:integer |R |true | |The number of effective digits for data. |
|multiplyingFactors |xs:floatr |R |true | |The unit for data multiplying factors, for example 1 kWh, 0,1 kWh, 0,01 kWh etc. |
|multiplyingFactors |xs:float |R |true | |The unit for data multiplying factors, for example 1 kWh, 0,1 kWh, 0,01 kWh etc. |
|generationSource |xs:string |RW |false | |The type of generating source. |
...
...
@@ -1235,7 +1231,7 @@ This module allows to control the 'keep warm' feature in devices like coffee mac
#### 5.3.1.49 keypad
This ModuleClass provides the capability to perform a user defined service through the key-in number. For example, a user can define key 1 as "perform a takeout from a restaurant with combo meal 1". The IoT service provider or user can define the services.
This ModuleClass provides the capability to perform a user defined service through the key-in number. For example, a user can define key 1 as "perform a take-out from a restaurant with combo meal 1". The IoT service provider or user can define the services.
**Table 5.3.1.49-1: DataPoints of keypad ModuleClass**
...
...
@@ -1610,7 +1606,7 @@ This ModuleClass provides capabilities for a refrigeration function.
@@ -1760,7 +1756,7 @@ This ModuleClass provides capabilities to set service parameters.
|timePlanStatus |xs:boolean |RW |true | |"False" indicates the time plan is not used. "True" indicates the time plan is being used. |
|timeRangeCount |xs:integer |RW |true | |The number of time ranges for the time plan. |
|timeRange |list of xs:time |RW |true | |An array of sequential time points which define the time plan. Each time point is the start time of the next time range as well as the end of previous time range in the time plan. |
|timeRangeLightDimmingValue |list of xs:string |RW |true | |An array containing the dimming values in different time ranges. In the case that lightCount is larger than 1, it is a 2-dimentional array describing the dimming value of each lampholder in each time range. |
|timeRangeLightDimmingValue |list of xs:string |RW |true | |An array containing the dimming values in different time ranges. In the case that lightCount is larger than 1, it is a 2-dimensional array describing the dimming value of each lampholder in each time range. |
...
...
@@ -1812,7 +1808,7 @@ This ModuleClass provides the capabilities to indicate the detection of smoke an
|-|-|-|-|-|-|
|alarm |xs:boolean |R |false | |The alarm is indicated as follows:<br/>"True" indicates that smoke has been detected, "False" indicates a normal status, that means that smoke is not detected. |
|detectedTime |m2m:timestamp |RW |true | |The date and time the smoke is detected. |
|smokeThreshhold |xs:integer |RW |true |ppm |The threshhold to trigger the alarm. |
|smokeThreshhold |xs:integer |RW |true |ppm |The threshold to trigger the alarm. |
|currentValue |xs:integer |R |true | |The current data value of the smoke sensor. |
|sensorFault |xs:boolean |R |true | |"True" indicates the sensor fault status of smoke sensor. "False" indicates the sensor fault of smoke sensor has been eliminated. |
|lowVoltage |xs:boolean |R |true | |"True" indicates the low voltage status of smoke sensor. "False" indicates the low voltage alarm of smoke sensor has been eliminated. |
...
...
@@ -1920,7 +1916,7 @@ This ModuleClass provides the capabilities to indicate the detection of abnormal
|Name |Type |R/W |Optional |Unit |Documentation |
|-|-|-|-|-|-|
|unit | [hd:enumTemperatureUnit](#5640-hdenumtemperatureunit) |RW |true |C or F or K |Default value is 'C'. |
|temperature |xs:float |R |true |Defined in the datapoint 'unit' |To report the value of the temperature. |
|temperature |xs:float |R |true |Defined in the 'unit' |To report the value of the temperature. |
| | | | | | |
|highTemperatureAlarm |xs:boolean |R |false | |High temperature alarm. |
|highTemperatureAlarmThreshold |xs:float |RW |true |Defined in the data point 'unit' |The threshold of maximum temperature alarm. |
...
...
@@ -2125,7 +2121,6 @@ This ModuleClass provides capabilities to set service parameters for data sampli
#### 5.3.1.97 waterSensor
This ModuleClass provides the capabilities to indicate whether or not water has been sensed, and raising an alarm if the triggering criterion is met.
...
...
@@ -2138,7 +2133,6 @@ This ModuleClass provides the capabilities to indicate whether or not water has
#### 5.3.1.98 waterQualityMonitor
This ModuleClass provides the information of water quality detection.
...
...
@@ -2173,7 +2167,7 @@ This ModuleClass provides the information of water quality detection.
|ph |xs:float |R |true | |Potential Of Hydrogen (pH) |
|sulfide |xs:float |R |true |mg/L |Sulfide |
|sulfide |xs:float |R |true |mg/L |Sulphide |
|temperature |xs:float |R |true |C |Water temperature |
|tn |xs:float |R |true |mg/L |Total nitrogen (TN) which is defined as the total amount of various forms of inorganic and organic nitrogen in water. |
|tp |xs:float |R |true |mg/L |Total phosphorus (TP) which is the result of the conversion of various forms of phosphorus into orthophosphate after digestion of the water sample, measured in milligrams of phosphorus per litre of water sample. |
...
...
@@ -2659,7 +2653,7 @@ This ModuleClass provides information on the origin of the parent device data.
### 5.3.10 Public Safety Domain
#### 5.3.10.1 Disseminator
This ModuleClass provides the capability of creating oneM2M based information from CAP based information received from oneM2M SP Gateway (ASN) and of controlling the change of received public warning messages such as updating oneM2M based information and canceling the dissemination of oneM2M based information.
This ModuleClass provides the capability of creating oneM2M based information from CAP based information received from oneM2M SP Gateway (ASN) and of controlling the change of received public warning messages such as updating oneM2M based information and cancelling the dissemination of oneM2M based information.
<mark>Editor note: the following attributes are missing from the short name tables in 6.3</mark>
...
...
@@ -2977,9 +2971,9 @@ A smart plug is a device that can turn on and off a connected appliance.
**Table 5.5.1.11-2: Subdevice of deviceSmartPlug Device model**
**Table 5.5.1.11-2: SubDevice of deviceSmartPlug Device model**
|Subdevice Instance Name |Subdevice Name |Multiplicity |Description |
|SubDevice Instance Name |SubDevice Name |Multiplicity |Description |
|-|-|-|-|
|powerOutlet0<br/><mark>Discuss: This should be "powerOutlet"</mark> |[subDevicePowerOutlet](#5412-subdevicepoweroutlet) |1..N |See clause [5.4.1.2](#5412-subdevicepoweroutlet). |
...
...
@@ -3302,9 +3296,9 @@ A blood pressure monitor is a device that can be used to monitor the blood press
@@ -3312,7 +3306,7 @@ A blood pressure monitor is a device that can be used to monitor the blood press
#### 5.5.3.2 deviceGlucosemeter
A glucometer is a device that can be used to monitor the blood glucose level.
A glucose meter is a device that can be used to monitor the blood glucose level.
**Table 5.5.3.2-1: Modules of deviceGlucoseMeter Device model**
...
...
@@ -3339,7 +3333,7 @@ A heart rate monitor is a device that can be used to monitor the heart rate.
#### 5.5.3.4 devicePulseOximeter
A pulseoximeter is a device that can be used to monitor the blood characteristics.
A pulse-oximeter is a device that can be used to monitor the blood characteristics.
**Table 5.5.3.4-1: Modules of devicePulseOxiMeter Device model**
...
...
@@ -3540,7 +3534,7 @@ A dehumidifier is a device that is used to monitor or control the state of a deh
#### 5.5.4.10 deviceDigitalGallery
A digital gallery is a device that is used to display picture, e.g., paintings from artists, photos from photographers or personals, etc.
A digital gallery is a device that is used to display picture, e.g., paintings from artists, photos from photographers or personal, etc.
<mark>Editor note: the device is missing from the short name tables in 6.3</mark>
...
...
@@ -4401,7 +4395,7 @@ Used for "currentJobMode" and "jobModes" data points of the "[dehumidifierJobMod
|Value |Interpretation |Note |
|-|-|-|
|1 |smart |This value indicates the smart mode that first gets the target humidity level from user input, next detects the correct relative humidity, then automatically change the dehumidity level to keep the target humidity level. |
|1 |smart |This value indicates the smart mode that first gets the target humidity level from user input, next detects the correct relative humidity, then automatically change the de-humidity level to keep the target humidity level. |
|2 |fast |This value indicates the fast mode that speeds the operating level up to quickly dehumidify when the humidity level is so high. It is a kind of turbo mode. |
|3 |silent |This value indicates the silent mode that can be used when a user sleeps. It reduces the noise. |
|4 |focus |This value indicates the focus mode that dehumidifies focusing on a particular part. |
...
...
@@ -4809,7 +4803,7 @@ Used for the "supportedMediaSources" data point of the "[mediaSelect](#53153-med
|10 |externalStorage | |
|11 |network | |
NOTE: See clause [5.3.1.53 "mediaSelect"](#53153-mediaselect). <mark>Negative values are reserved for vender specific sources</mark>.
NOTE: See clause [5.3.1.53 "mediaSelect"](#53153-mediaselect). <mark>Negative values are reserved for vendor specific sources</mark>.
...
...
@@ -4965,7 +4959,7 @@ Used for the "filterType" data point of the "[waterFilterType](#531105-waterfilt
|Value |Interpretation |Note |
|-|-|-|
|1 |RO |This value indicates the Revers Osmosis type water filter. |
|1 |RO |This value indicates the Reverse Osmosis type water filter. |
|2 |UV |This value indicates the Ultraviolet type water filter. |
|3 |UF |This value indicates the UltraFiltration type water filter. |
|4 |AC |This value indicates the Activate Carbon type water filter. |
...
...
@@ -5119,21 +5113,21 @@ Used for the "batteryMaterial" DataPoint of the "[battery](#53110-battery)" Modu
|Value |Interpretation |Note |
|-|-|-|
|1 |Alkaline_battery |Primary cells or non-rechargeables |
|2 |Lithium_battery |Primary cells or non-rechargeables |
|3 |Magnesium_battery |Primary cells or non-rechargeables |
|4 |Mercury_battery |Primary cells or non-rechargeables |
|5 |Nickel_oxyhydroxide_battery |Primary cells or non-rechargeables |
|6 |Silver_oxide_battery |Primary cells or non-rechargeables |
|7 |Zinc_air |Primary cells or non-rechargeables |
|8 |Lead_acid_battery |Secondary cells or rechargeables |
|9 |Lithium_ion_battery |Li-ion, Secondary cells or rechargeables |
|10 |Lithium_ion_polymer_battery |LiPo, Secondary cells or rechargeables |
|11 |Nickel_cadmium_battery |Ni-Cd , Secondary cells or rechargeables |
|12 |Nickel_iron_battery |Secondary cells or rechargeables |
|13 |Nickel_metal_hydride_battery |NiMH, Secondary cells or rechargeables |
|14 |Nickel_zinc_battery |Secondary cells or rechargeables |
|15 |Rechargeable_alkaline_battery |Secondary cells or rechargeables |
|1 |Alkaline_battery |Primary cells or non-rechargeable |
|2 |Lithium_battery |Primary cells or non-rechargeable |
|3 |Magnesium_battery |Primary cells or non-rechargeable |
|4 |Mercury_battery |Primary cells or non-rechargeable |
|5 |Nickel_oxyhydroxide_battery |Primary cells or non-rechargeable |
|6 |Silver_oxide_battery |Primary cells or non-rechargeable |
|7 |Zinc_air |Primary cells or non-rechargeable |
|8 |Lead_acid_battery |Secondary cells or rechargeable |
|9 |Lithium_ion_battery |Li-ion, Secondary cells or rechargeable |
|10 |Lithium_ion_polymer_battery |LiPo, Secondary cells or rechargeable |
|11 |Nickel_cadmium_battery |Ni-Cd , Secondary cells or rechargeable |
|12 |Nickel_iron_battery |Secondary cells or rechargeable |
|13 |Nickel_metal_hydride_battery |NiMH, Secondary cells or rechargeable |
|14 |Nickel_zinc_battery |Secondary cells or rechargeable |
|15 |Rechargeable_alkaline_battery |Secondary cells or rechargeable |
...
...
@@ -5343,7 +5337,7 @@ The architecture of IPE-based Device Management is presented in oneM2M TS-0001 <
### 5.8.1 flexNode
This flexContainer specialization is the root for SDT-based Device Maagement modules.
This flexContainer specialization is the root for SDT-based Device Management modules.
The containerDefinition attribute of this specialization shall be "org.onem2m.management.device.flexNode".
...
...
@@ -5489,21 +5483,21 @@ Individual firmwares are managed using the [dmFirmware] actions presented in Tab
|Return Type |Name |Argument |Optional |Description |
|-|-|-|-|-|
|xs:string |updateFirmware |url: xs:url<br/>version: xs:string |true |Downloads a new firmware to the device / sub-component. In case of devices that do support toggling between multiple preinstalled firmware versions it also starts the firmware flashing/installation process.<br/>The updateFirmware action as it results returns an AE/IPE message indicating if the action was successful or not. |
|xs:string |updateFirmware |url: xs:url<br/>version: xs:string |true |Downloads a new firmware to the device / sub-component. In case of devices that do support toggling between multiple pre-installed firmware versions it also starts the firmware flashing/installation process.<br/>The updateFirmware action as it results returns an AE/IPE message indicating if the action was successful or not. |
|xs:string |toggle |none |true |Toggles between the firmware versions installed on a device/sub-component. In case of devices that do not support such toggling, it triggers the firmware flashing/installation process.<br/>The toggle action as it results returns an AE/IPE message indicating if the action was successful or not. |
The abstraction model used for [dmFirmware] manages the firmware through two images: a *primary* firmware image and a *secondary* one. Despite the naming both images are equivalent and a secondary image can be actively used by a device just like the primary one.
Using an abstraction model based on two firmware images it is possible to effectively manage firmware on devices with different firmware capabilities. The state machine for firmware management using two images is shown in Figure 5.8.5-1 for devices that do support toggling between multiple preinstalled firmware versions and in Figure 5.8.5-2 for devices that can have only one firmware version installed.
Using an abstraction model based on two firmware images it is possible to effectively manage firmware on devices with different firmware capabilities. The state machine for firmware management using two images is shown in Figure 5.8.5-1 for devices that do support toggling between multiple pre-installed firmware versions and in Figure 5.8.5-2 for devices that can have only one firmware version installed.
**Table 5.8.5-2 DataPoints of dmFirmware ModuleClass**
|Name |Type |R/W |Optional |Unit |Description |
|-|-|-|-|-|-|
|multiFirmware |xs:boolean |R |false | |Indicates if the device/sub-component supports toggling between multiple preinstalled firmware versions. |
|multiFirmware |xs:boolean |R |false | |Indicates if the device/sub-component supports toggling between multiple pre-installed firmware versions. |
|primaryState |[hd:enumFirmwareState](#5644-hdenumfirmwarestate) |R |false | |The current state of the primary firmware image (active, downloading, etc.). |
|primaryName |xs:string |R |false | |The name of the primary firmware image. |
|primaryVersion |xs:string |R |false | |The version of the primary firmware image. |
...
...
@@ -5522,10 +5516,10 @@ NOTE 1: Both primary and secondary firmware image related dataPoints are mandato
**Figure 5.8.5-1: Lifecycle of a dmFirmware for devices that support toggling between preinstalled firmware images**
**Figure 5.8.5-1: Lifecycle of a dmFirmware for devices that support toggling between pre-installed firmware images**
For devices that support toggling between multiple preinstalled firmware images the following rules apply:
For devices that support toggling between multiple pre-installed firmware images the following rules apply:
- There is always one firmware image that is in "Active" state.
...
...
@@ -5760,10 +5754,10 @@ This ModuleClass is used to model the storage on a managed device.
# 6 The Principle of Resource Mapping for Home Appliance Information Model
# 6 The Principle of Resource Mapping for Harmonized Information Model
## 6.1 Introduction
Home appliance information models which are defined in clause 5need to be represented as resources in the oneM2M system. This clause defines the principle of resource mapping based on <flexContainer>. The individual information mapping is provided in annexes [A](#annex-a-(informative)--resource-mapping-examples), [B](#annex-b-(informative)--introduction-of-external-organizations'-data-models), and [C](#annex-c-(informative)--mapping-to-content-attribute).
Harmonized information models which are defined in clause [5](#5-harmonised-information-model)need to be represented as resources in the oneM2M system. This clause defines the principle of resource mapping based on <flexContainer>. The individual information mapping is provided in annexes [A](#annex-a-(informative)--resource-mapping-examples), [B](#annex-b-(informative)--introduction-of-external-organizations'-data-models), and [C](#annex-c-(informative)--mapping-to-content-attribute).
## 6.2 The Resource Mapping Rules
...
...
@@ -5773,7 +5767,7 @@ The present clause specifies the rule to map the "Harmonized Information Model"
### 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](#55-device-models), a specialization of the <flexContainer> resource shall be created as the mapping of the model following conversion rules:
When the AE exposes a controlling interface for a device which is specified as an information model in clause [5.5](#55-device-models), 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](#55-device-models) shall be mapped to a specialization of <flexContainer>. The *containerDefinition* attribute shall be set according to clause [6.4.2](#642-device-models).
...
...
@@ -5874,7 +5868,7 @@ The SubDevice models (in clause [5.4](#54-subdevice-models) or [5.8.9](#589-dmar
- 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](#539-metadata-domain).
- In other words, all subdevices implicitly have the following lines in their modules table:
- In other words, all SubDevices implicitly have the following lines in their modules table:
**Table 6.2.7-1: Modules of subDeviceXXX model**
...
...
@@ -6301,7 +6295,7 @@ In protocol bindings resource attributes names for data points of module classes
@@ -6520,7 +6514,7 @@ Depending on the domain, the *containerDefinition* attribute of specializations
- Rule: "org.onem2m.[domain].action.[action name]", where [domain] is one of the domain names defined in [6.4.1](#641-introduction). The name is chosen according to the domain in which the action is defined.
For example, the *containerDefinition* attribute of the specialization for "[activateClockTimer](#53190-timer)" action in the "[timer](#53190-timer)" module class of the "common" domain shall be "org.onem2m.common.action.activateClocktimer", the *containerDefinition* attribute of the specialization for the "[activate](#586-dmsoftware)" action of the "[dmSoftware](#586-dmsoftware)" ModuleClass of the "management" domain shall be "org.onem2m.management.action.activate".
For example, the *containerDefinition* attribute of the specialization for "[activateClockTimer](#53190-timer)" action in the "[timer](#53190-timer)" module class of the "common" domain shall be "org.onem2m.common.action.activateClockTimer", the *containerDefinition* attribute of the specialization for the "[activate](#586-dmsoftware)" action of the "[dmSoftware](#586-dmsoftware)" ModuleClass of the "management" domain shall be "org.onem2m.management.action.activate".
### 6.4.5 SubDevices
...
...
@@ -6590,7 +6584,7 @@ For example, the XSD definition for "[activateClockTimer](#53190-timer)" specifi
### 6.5.5 XSD definitions for SubDevices
The XSD definitions for SubDeices are specified upon the following rule:
The XSD definitions for SubDevices are specified upon the following rule:
- Rule: [Domain Prefix]-[SubDevice name]-v<TS-version>.xsd where the string '<TS-version>' shall be interpreted as the version of the present document.
...
...
@@ -6610,7 +6604,7 @@ This file contains the definitions of all enumerated types, and nothing else.
## 7.0 Introduction
This clause specifies how the Home Appliance Information Model (HAIM) defined in the clause 5of the present document can be mapped with existing external models from , OCF, ECHONET, OMA GotAPI etc. and introduction of these models is written in annex B. The mapping shall be to enable the interworking between the oneM2M system and external technologies at the information model level. This means a oneM2M native application which understand only oneM2M standardized HAIM shall be able to interact with non-oneM2M home appliances of different technologies in a consistent way without knowing the technology specific details. An IPE shall be responsible for translating the HAIM to/from technology specific information model bidirectionally following the mapping specification in this clause. Using HAIM as a bridge, home appliances and applications of different technologies shall be able to also interact with each other via the oneM2M system (with IPEs).
This clause specifies how the Harmonized Information Model (HIM) defined in the clause [5](#5-harmonised-information-model)of the present document can be mapped with existing external models from , OCF, ECHONET, OMA GotAPI etc. and introduction of these models is written in annex B. The mapping shall be to enable the interworking between the oneM2M system and external technologies at the information model level. This means a oneM2M native application which understand only the oneM2M HIM shall be able to interact with non-oneM2M appliances of different technologies in a consistent way without knowing the technology specific details. An IPE shall be responsible for translating the HIM to/from technology specific information model bidirectionally following the mapping specification in this clause. Using HIM as a bridge, appliances and applications of different technologies shall be able to also interact with each other via the oneM2M system (with IPEs).
## 7.1 OMA GotAPI(DWAPI)
...
...
@@ -6730,7 +6724,7 @@ DevicePulseOximeter of HAIM shall be mapped to Pulse Oximeter of OMA DWAPI-PCH o
#### 7.1.2.5 deviceThermometer
DeviceTermometer of HAIM shall be mapped to Thermometer of OMA DWAPI-PCH on the basis of Table 7.1.2.5-1.
DeviceThermometer of HAIM shall be mapped to Thermometer of OMA DWAPI-PCH on the basis of Table 7.1.2.5-1.
**Table 7.1.2.5-1: Map of deviceThermometer of oneM2M HAIM to OMA DWAPI-PCH**
...
...
@@ -6795,14 +6789,14 @@ Data types of oneM2M HAIM and OMA DWAPI-PCH shall be mapped each other on the ba
# 8 Ontology for the Home Appliance Information Model aligned with oneM2M Base Ontology
The following table shows a mapping of the Home Appliance Information Model to the oneM2M Base Ontology in oneM2M TS-0012 <ahref="#_ref_i.5">[i.5]</a>.
# 8 Ontology for the Harmonized Information Model aligned with oneM2M Base Ontology
The following table shows a mapping of the Harmonized Information Model (HIM) to the oneM2M Base Ontology in oneM2M TS-0012 <ahref="#_ref_i.5">[i.5]</a>.
Table 8-1 only shows mapping of SDT concepts that are used to classify all concepts in the Home Appliance Information Model. Therefore, since any concept in the Home Appliance Information Model can be classified according to a specific SDT concept it also (transitively) maps to the related class of the oneM2M Base Ontology.
Table 8-1 only shows mapping of SDT concepts that are used to classify all concepts in the HIM. Therefore, since any concept in the HIM can be classified according to a specific SDT concept it also (transitively) maps to the related class of the oneM2M Base Ontology.
**Table 8-1: Mapping between SDT concepts in the Home Appliance Information Model <br />and the oneM2M Base Ontology**
**Table 8-1: Mapping between SDT concepts in the Harmonized Information Model <br />and the oneM2M Base Ontology**
|SDT Concept in the Home Appliance Information Model |Mapping relationship | Class in Base Ontology |Property in Base Ontology |Comment |
|SDT Concept in the Harmonized Information Model |Mapping relationship | Class in Base Ontology |Property in Base Ontology |Comment |
|-|-|-|-|-|
|SDT: Device |sub-class of |Device | | |
|SDT: SubDevice |sub-class of |Device | |The base ontology allows a Device to consist of (sub-) Devices |
...
...
@@ -6814,7 +6808,7 @@ Table 8-1 only shows mapping of SDT concepts that are used to classify all conc
|SDT: Module |sub-class of |Service | |The base ontology allows a Service to have subServices. Each SDT:Module implements one SDT:ModuleClass. <br/>Therefore SDT:Module can be considered a subclass of SDT:ModuleClass and therefore subclass of oneM2M:Service.<br/>See note. |
|SDT: ModuleClass |sub-class of |Service | |See note |
|SDT: UnitOfMeasure |sub-class of |MetaData | | |
|SDT: DataPoint |sub-class of |InputDataPoint | |If SDT:DataPoint is writable |
|SDT: DataPoint |sub-class of |InputDataPoint | |If SDT:DataPoint is writeable |
|SDT: DataPoint |sub-class of |OutputDataPoint | |If SDT:DataPoint is readable |
|SDT: Property (of a Device) |sub-class of |ThingProperty | | |
|SDT: Property (of a ModuleClass) |sub-class of |Aspect | |Aspect (of the Functionality) |
...
...
@@ -6996,7 +6990,7 @@ The [[toggle](#53112-binaryswitch)] resource contains the attributes specified i
# Annex B (informative): Introduction of External Organizations' Data Models
## B.1 OMA Got API (DWAPI-PCH)
OMA GotAPI(OMA Generic Open Terminal API Framework) provides the framework to enable applications and multitype devices through GotAPI Servers and Extension Plug-Ins <ahref="#_ref_6">[6]</a>. When APIs are implemented in Extension Plug-Ins under the GotAPI framework, these APIs are called as OMA Device WebAPIs Enabler. In case of healthcare devices, these APIs are called as OMA Device WebAPIs for Personal Connected Healthcare (DWAPI-PCH).
OMA GotAPI(OMA Generic Open Terminal API Framework) provides the framework to enable applications and multi-type devices through GotAPI Servers and Extension Plug-Ins <ahref="#_ref_6">[6]</a>. When APIs are implemented in Extension Plug-Ins under the GotAPI framework, these APIs are called as OMA Device WebAPIs Enabler. In case of healthcare devices, these APIs are called as OMA Device WebAPIs for Personal Connected Healthcare (DWAPI-PCH).
Healthcare devices can be a one of the smart home devices so OMA DWWAPI-PCH can have relationship with oneM2M SDT.
...
...
@@ -7283,7 +7277,7 @@ An example for only DataPoint class mapping is shown below.:
</m2m:rqp>
```
In this case, contentInfo attribute can NOT be omitted because we cannot understand which Datapoint is written in content attribute without contentInfo attribute.
In this case, contentInfo attribute can NOT be omitted because we cannot understand which datapoint is written in content attribute without contentInfo attribute.
If a contentInfo attribute is not used, content attribute may change as follows:
...
...
@@ -7347,6 +7341,6 @@ NOTE: Available at http://www.openmobilealliance.org/release/DWAPI/V1_0-2016041
| V5.2.0 | 2022-07-15 | Reflecting comments from issues tracker. see link https://git.onem2m.org/issues/issues/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=rdm |
