Skip to content
Snippets Groups Projects

RDM-2024-0029-Editorial_changes

Merged RDM-2024-0029-Editorial_changes
RDM-2024-0029-Editorial_changes into R5
Merged Andreas Kraft requested to merge RDM-2024-0029-Editorial_changes into R5
Viewing commit 40dcb1ba
Next
Show latest version
1 file
+ 94
− 100
Compare changes
  • Side-by-side
  • Inline
TS-0023-SDT_based_Information_Model_and_Mapping_for_Vertical_Industries.md
+ 94
− 100
@@ -7,7 +7,7 @@
|Document Number |oneM2M- TS-0023-V5.6.0 |
|Document Name: |SDT based Information Model and Mapping for Vertical Industries |
|Date: |2024-06-27 |
|Abstract: |This technical specification includes oneM2M defined 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 <a href="#_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 <a href="#_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 <a href="#_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 <a href="#_ref_1">[1]</a>.
The design principle of the oneM2M Harmonized Information Model is to use SDT4.0 originally introduced in oneM2M TR0017 <a href="#_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 <a href="#_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 <a href="#_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.
![SDT 4.0 Basic Elements](media/SDT_4_0_basic_elements.png)
**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".
@@ -387,7 +383,7 @@ Table 5.2.2-2 provides some examples for short names that have been created by t
- Rule 13: Rule for R/W column:
- The value used in this column defines the interface as it applies to the user of this module. The entity that this module represents (device AE or IPE AE) can read or write to any or all of the datapoints as needed in order to implement the defined interface to the user. &lt;accessControlPolicy> resources shall be defined to enforce access control to the datapoints of the module defined such that R in the R/W column has RETRIEVE accessControlOperations and RW in the R/W column has RETRIEVE and UPDATE accessControlOperations.
- The value used in this column defines the interface as it applies to the user of this module. The entity that this module represents (device AE or IPE AE) can read or write to any or all of the data points as needed in order to implement the defined interface to the user. &lt;accessControlPolicy> resources shall be defined to enforce access control to the data points of the module defined such that R in the R/W column has RETRIEVE accessControlOperations and RW in the R/W column has RETRIEVE and UPDATE accessControlOperations.
- Rule 14: Rule for Optional and Multiplicity:
@@ -599,7 +595,7 @@ This ModuleClass provides capabilities to indicate the detection of low battery
|charging |xs:boolean |R |true | |The status of charging. "True" indicates enabled, and "False" indicates not enabled. |
|discharging |xs:boolean |R |true | |The status of discharging. "True" indicates charging, and "False" indicates not charging. |
|lowBattery |xs:boolean |R |true | |To indicate that the battery is on a low charge level. |
|batteryThreshold |xs:integer |RW |true | |When a battery's "level" is less than "batteryThreshold" then "lowBattery" is set to "True". This datapoint can be used to raise an alarm, depending on the implementation. |
|batteryThreshold |xs:integer |RW |true | |When a battery's "level" is less than "batteryThreshold" then "lowBattery" is set to "True". This data point can be used to raise an alarm, depending on the implementation. |
|chargingVoltage |xs:float |R |true |V |The voltage to charge the battery |
|chargingAmpere |xs:float |R |true |A |The ampere to charge the battery |
|dischargingVoltage |xs:float |R |true |V |The voltage to discharge the battery |
@@ -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
|powerGenerationData |xs:float |R |true |W |Amount of instantaneous generation data. |
|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**
@@ -1407,7 +1403,7 @@ This ModuleClass provides the capability to report the measurement of blood oxyg
|Name |Type |R/W |Optional |Unit |Documentation |
|-|-|-|-|-|-|
|oxygenSaturation |xs:integer |R |false |pct |The measurement of oxygensaturation by Oximeter. |
|oxygenSaturation |xs:integer |R |false |pct |The measurement of oxygen saturation by Oximeter. |
@@ -1610,7 +1606,7 @@ This ModuleClass provides capabilities for a refrigeration function.
|rapidFreeze |xs:boolean |RW |true | |Controls the rapid freeze capability. "True" indicates active, "False" indicates inactive. |
|rapidCool |xs:boolean |RW |true | |Controls the rapid cool capability. "True" indicates active, "False" indicates inactive. |
|defrost |xs:boolean |RW |true | |Controls the defrost cycle. "True" indicates active, "False" indicates inactive. |
|deodorize |xs:boolean |RW |true | |Controls the deodourize cycle. "True" indicates active, "False" indicates inactive. |
|deodorize |xs:boolean |RW |true | |Controls the deodorize cycle. "True" indicates active, "False" indicates inactive. |
|degerm |xs:boolean |RW |true | |Controls the degerm cycle. "True" indicates active, "False" indicates inactive. |
@@ -1756,11 +1752,11 @@ This ModuleClass provides capabilities to set service parameters.
|Name |Type |R/W |Optional |Unit |Documentation |
|-|-|-|-|-|-|
|lightCount |xs:integer |RW |true | |Number of lampholders controlled by the street light controller. |
|lightCount |xs:integer |RW |true | |Number of lamp holders controlled by the street light controller. |
|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 lamp holder 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,12 +1916,12 @@ 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 datapoint 'unit' |The threshold of maximum temperature alarm. |
|highTemperatureAlarmThreshold |xs:float |RW |true |Defined in the data point 'unit' |The threshold of maximum temperature alarm. |
|lowTemperatureAlarm |xs:boolean |R |false | |Low temperature alarm. |
|lowTemperatureAlarmThreshold |xs:float |RW |true |Defined in the datapoint 'unit' |The threshold of minimum temperature alarm. |
|lowTemperatureAlarmThreshold |xs:float |RW |true |Defined in the data point 'unit' |The threshold of minimum temperature alarm. |
|alarmTimestamp |xs:datetime |R |true | |The timestamp since the alarm is active. |
@@ -2075,7 +2071,7 @@ This ModuleClass provides capabilities to provide alarm information of water met
#### 5.3.1.95 waterMeterReportInfo
This ModuleClass provides information of measurements of the watermeter.
This ModuleClass provides information of measurements of the water meter.
<mark>Editor note: the following attributes are missing from the short name tables in 6.3</mark>
@@ -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.
|oil |xs:float |R |true |mg/L |Petroleum pollutants |
|pb |xs:float |R |true |mg/L |Lead (Pb) |
|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). |
@@ -3019,7 +3013,7 @@ A thermostat is used to control the ambient temperature of rooms within, for exa
|Module Instance Name |Module Class Name |Multiplicity |Description |
|-|-|-|-|
|runState |[runState](#53175-runstate) |0..1 |See clause [5.3.1.75](#53175-runstate).<br />The possible values of the "supportedModes" datapoint for the thermostat device are included in clause 5.6.23. |
|runState |[runState](#53175-runstate) |0..1 |See clause [5.3.1.75](#53175-runstate).<br />The possible values of the "supportedModes" data point for the thermostat device are included in clause 5.6.23. |
|timer |[timer](#53190-timer) |0..1 |See clause [5.3.1.90](#53190-timer). |
|temperature |[temperature](#53187-temperature) |1 |See clause [5.3.1.87](#53187-temperature). |
@@ -3302,9 +3296,9 @@ A blood pressure monitor is a device that can be used to monitor the blood press
|battery |[battery](#53110-battery) |1 |See clause [5.3.1.10](#53110-battery). |
|binarySwitch |[binarySwitch](#53112-binaryswitch) |0..1 |See clause [5.3.1.12](#53112-binaryswitch). |
**Table 5.5.3.1-2: Subdevice of deviceBloodPressureMonitor Device model**
**Table 5.5.3.1-2: SubDevice of deviceBloodPressureMonitor Device model**
|Subdevice Instance Name |Subdevice Name |Multiplicity |Description |
|SubDevice Instance Name |SubDevice Name |Multiplicity |Description |
|-|-|-|-|
|cuff |[subDeviceCuff](#5431-subdevicecuff) |1..N |See clause [5.4.3.1](#5431-subdevicecuff). |
@@ -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>.
@@ -4888,7 +4882,7 @@ NOTE: See clause [5.3.1.4 airFlow](#5314-airflow).
### 5.6.37 hd:enumWaterFlowStrength
Used for the "waterLevelStrength" data point of the "[waterFlow](#53193-waterflow)" ModuleClass, indicating the strength of a waterflow.
Used for the "waterLevelStrength" data point of the "[waterFlow](#53193-waterflow)" ModuleClass, indicating the strength of a water flow.
**Table 5.6.371: Interpretation of hd:enumWaterFlowStrength**
@@ -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".
@@ -5411,7 +5405,7 @@ This ModuleClass is used to share static information regarding the device.
|Name |Type |R/W |Optional |Unit |Description |
|-|-|-|-|-|-|
|serialNumber |xs:string |R | true | |Unique device label assigned by the manufacturer. <br />The value of the datapoint typically exposes the device's serial number that is specific to a manufacturer. |
|serialNumber |xs:string |R | true | |Unique device label assigned by the manufacturer. <br />The value of the data point typically exposes the device's serial number that is specific to a manufacturer. |
|manufacturer |xs:string |R |true | |The name/identifier of the device manufacturer. |
|manufacturerDetailsLink |xs:anyURI |RW |true | |URL to manufacturer's website. |
|manufacturingDate |m2m:timestamp |R |true | |Manufacturing date of device. |
@@ -5425,7 +5419,7 @@ This ModuleClass is used to share static information regarding the device.
|friendlyName |xs:string |RW |true | |The device friendly name. |
|description |xs:string |RW |true | |A human readable description of the device (e.g. Alice's cell phone, kitchen's fridge, etc.) |
NOTE: Although all datapoints are optional, depending on the underlying DM technology, some datapoints should be filled, for instance *serialNumber*, *manufacturer* and *model* when this information is available.
NOTE: Although all data points are optional, depending on the underlying DM technology, some data points should be filled, for instance *serialNumber*, *manufacturer* and *model* when this information is available.
@@ -5473,7 +5467,7 @@ writeIO(address="/3/0/15", payload="[Europe/Paris](Europe/Paris)")
-> {"/3/0/15"}
```
NOTE: Some datapoints of the [dmAgent](#582-dmagent) and [dmDeviceInfo](#583-dmdeviceinfo) ModuleClasses correspond to fixed parameters in OMA & BBF data models. The corresponding concepts in OMA DM / LwM2M data models (resp. BBF TR-181 <a href="#_ref_i.12">[i.12]</a>) are specified in oneM2M TS-0005 (resp. TS-0006 <a href="#_ref_i.1">[i.15]</a>). For instance the datapoint *memAvailable* corresponds to `'Device.DeviceInfo.MemoryStatus.Free'` in BBF TR-181 <a href="#_ref_i.12">[i.12]</a> (see oneM2M TS-0006 <a href="#_ref_i.15">[i.15]</a> clause 7.3) and to `'/3/0/10'` in LwM2M (oneM2M TS-0005 clause 6.3.4).
NOTE: Some data points of the [dmAgent](#582-dmagent) and [dmDeviceInfo](#583-dmdeviceinfo) ModuleClasses correspond to fixed parameters in OMA & BBF data models. The corresponding concepts in OMA DM / LwM2M data models (resp. BBF TR-181 <a href="#_ref_i.12">[i.12]</a>) are specified in oneM2M TS-0005 (resp. TS-0006 <a href="#_ref_i.1">[i.15]</a>). For instance the data point *memAvailable* corresponds to `'Device.DeviceInfo.MemoryStatus.Free'` in BBF TR-181 <a href="#_ref_i.12">[i.12]</a> (see oneM2M TS-0006 <a href="#_ref_i.15">[i.15]</a> clause 7.3) and to `'/3/0/10'` in LwM2M (oneM2M TS-0005 clause 6.3.4).
@@ -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. |
@@ -5512,7 +5506,7 @@ Using an abstraction model based on two firmware images it is possible to effect
|secondaryName |xs:string |R |true | |The name of the secondary firmware image. |
|secondaryVersion |xs:string |R |true | |The version of the secondary firmware image. |
|secondaryUrl |xs:url |R |true | |The URL from which the secondary firmware image was downloaded. |
|component |xs:string |R |true | |Allows to identify the sub-component that uses this firmware. <br />This datapoint is mandatory if this is a sub-component firmware. |
|component |xs:string |R |true | |Allows to identify the sub-component that uses this firmware. <br />This data point is mandatory if this is a sub-component firmware. |
@@ -5522,10 +5516,10 @@ NOTE 1: Both primary and secondary firmware image related dataPoints are mandato
![Lifecycle of a dmFirmware](media/lifecycle_of_a_dmfirmware_1.svg)
**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.
@@ -5563,7 +5557,7 @@ An instance of this ModuleClass represents a software module hosted by the devic
A [dmSoftware] module is created on a Hosting CSE by the IPE in charge of the device, either at the initialization if it represents a software module that is pre-installed on the device, or after installation of one or more [[5.8.8 dmPackage]](#588-dmpackage) modules (see clause [5.8.8](#588-dmpackage)) that have been dynamically created (for instance a software image with associated configuration files and libraries).
The association between one or more [dmPackage](#588-dmpackage) modules and a dmSoftware module are under the responsibility of the IPE: dmSoftware modules are created, deleted or updated only by the IPE (for instance updating a [dmPackage](#588-dmpackage) can trigger the modification of the version datapoint of an associated dmSoftware).
The association between one or more [dmPackage](#588-dmpackage) modules and a dmSoftware module are under the responsibility of the IPE: dmSoftware modules are created, deleted or updated only by the IPE (for instance updating a [dmPackage](#588-dmpackage) can trigger the modification of the version data point of an associated dmSoftware).
From external applications, [dmSoftware] modules can only be discovered from the parent [flexNode], not created, and afterwards they can only be activated / deactivated. They can be seen as 'high level' information ("there is such software that is running on the device"), whereas [dmPackage](#588-dmpackage) are 'low level' information ("there is such executable file that is deployed on the device").
@@ -5595,7 +5589,7 @@ This ModuleClass provides DM capabilities to control and monitor event logs of t
|none |retrieveLog |start: xs:datetime<br />end: xs:datetime |true |Upload from the device the logging data between 'start' and 'end'.<br />'start' shall be a date before 'end', and is optional. The default is beginning of time.<br />'end' shall be a date after 'start' and is optional. The default is the timestamp of the last available log entry. |
This action, if provided, requests the IPE to read logging data on the device. This log is then stored in the 'data' datapoint. It is only valid when the 'enabled' datapoint is true. The *start* *and* end arguments are only indications of the timeframe for the log retrieval. If a target device can deliver only partial logs for a given timeframe, for example when the *start* argument is too far in the past and logs are not available for that time anymore, then the device shall deliver logs from the earliest available point in time on.
This action, if provided, requests the IPE to read logging data on the device. This log is then stored in the 'data' data point. It is only valid when the 'enabled' data point is true. The *start* *and* end arguments are only indications of the time frame for the log retrieval. If a target device can deliver only partial logs for a given time frame, for example when the *start* argument is too far in the past and logs are not available for that time anymore, then the device shall deliver logs from the earliest available point in time on.
**Table 5.8.7-2 DataPoints of dmEventLog ModuleClass**
@@ -5611,11 +5605,11 @@ For devices using the dmEventLog ModuleClass, the following rules apply:
- The actual logging process on the device (if any), and the retrieval of device logging data by the IPE, are out of scope of the present document.
- Instances of this module should only be created by the IPE (one per log type supported by the device for instance).
- The IPE can create a [dmEventLog] instance with *status* datapoint 'NotPresent' for a given log type, to indicate that this log type is not supported by the device. Otherwise *status* should have value 'Started' (resp. 'Stopped') if the *enabled* datapoint is set to *true* (resp. *false*). The *status* datapoint can be given 'Error' value if the log processing dysfunctions.
- The IPE should use the &lt;flexContainerInstance> history mechanism (see oneM2M TS-0001 clause 9.6.59) by setting on [dmEventLog] at least one attribute *maxNrOfInstances*, *maxByteSize* or *maxInstanceAge*. Then for each log event read by the IPE from the device, and if the *enabled* datapoint has value *true*, a &lt;flexContainerInstance> resource shall be created, child of this module &lt;flexContainer>. The [dmEventLog] module itself just contains the *last* logged event from the device for this log type.
- The IPE can create a [dmEventLog] instance with *status* data point 'NotPresent' for a given log type, to indicate that this log type is not supported by the device. Otherwise *status* should have value 'Started' (resp. 'Stopped') if the *enabled* data point is set to *true* (resp. *false*). The *status* data point can be given 'Error' value if the log processing dysfunctions.
- The IPE should use the &lt;flexContainerInstance> history mechanism (see oneM2M TS-0001 clause 9.6.59) by setting on [dmEventLog] at least one attribute *maxNrOfInstances*, *maxByteSize* or *maxInstanceAge*. Then for each log event read by the IPE from the device, and if the *enabled* data point has value *true*, a &lt;flexContainerInstance> resource shall be created, child of this module &lt;flexContainer>. The [dmEventLog] module itself just contains the *last* logged event from the device for this log type.
- The [dmEventLog] &lt;flexContainer>, and therefore its &lt;flexContainerInstance> children resources, should have a *dataGenerationTime* custom attribute that indicates the time the event was logged on the device (see Rule 2-5 in clause 6.2.3).
When the *enabled* datapoint is set to *false*, the IPE shall set the *status* datapoint to 'Stopped' and shall not modify the *data* datapoint of the module, and therefore shall not create any *&lt;flexContainerInstance>* child resource.
When the *enabled* data point is set to *false*, the IPE shall set the *status* data point to 'Stopped' and shall not modify the *data* data point of the module, and therefore shall not create any *&lt;flexContainerInstance>* child resource.
@@ -5623,8 +5617,8 @@ When the *enabled* datapoint is set to *false*, the IPE shall set the *status* d
### 5.8.8 dmPackage
This ModuleClass provides DM capabilities to deploy, control and monitor packages of the device.
- These packages can be simple resource files such as software libraries, configuration files, etc. In this case the *softwares* datapoint will be empty.
- They also can correspond to software images, in which case their installation will trigger the creation by the IPE of one or more [[dmSoftware]](#586-dmsoftware) SDT modules classes that can be activated / deactivated (see clause [5.8.6](#586-dmsoftware)). In this case the *softwares* datapoint will contain the list of IDs of this(these) [dmSoftware](#586-dmsoftware) module(s).
- These packages can be simple resource files such as software libraries, configuration files, etc. In this case the *softwares* data point will be empty.
- They also can correspond to software images, in which case their installation will trigger the creation by the IPE of one or more [[dmSoftware]](#586-dmsoftware) SDT modules classes that can be activated / deactivated (see clause [5.8.6](#586-dmsoftware)). In this case the *softwares* data point will contain the list of IDs of this(these) [dmSoftware](#586-dmsoftware) module(s).
- Instances of the dmPackage module class can be dynamically created by the "[deployPackage](#582-dmagent)" action of the [dmAgent](#582-dmagent) module class (see clause [5.8.2](#582-dmagent)).
**Table 5.8.8-1 Actions of dmPackage ModuleClass**
@@ -5658,7 +5652,7 @@ NOTE:
NOTE:
- The [dmPackage] *name* and *version* datapoints are optional because they can be deduced from the downloaded resource. The *url* datapoint is optional because the package can be pre-installed or downloaded from a default repository (for instance a package on a Linux-type system).
- The [dmPackage] *name* and *version* data points are optional because they can be deduced from the downloaded resource. The *url* data point is optional because the package can be pre-installed or downloaded from a default repository (for instance a package on a Linux-type system).
- The possible dependencies between [dmPackage] modules (for instance the [dmPackage] of an executable software image depends on the deployment of other dmPackage that correspond to libraries needed by this software) is out of scope of the present document.
The control of the association between a dmPackage and an associated [dmSoftware](#586-dmsoftware) module, for instance updating a [dmPackage] when the [dmSoftware](#586-dmsoftware) is active, is out of scope of the present document.
@@ -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 &lt;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 &lt;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 &lt;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 &lt;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 &lt;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 &lt;flexContainer> associated to a SubDevice model may have as child resource any &lt;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
|manufacturerDetailsLink |[dmDeviceInfo](#583-dmdeviceinfo) |maDLk |
|manufacturingDate |[dmDeviceInfo](#583-dmdeviceinfo) |manDe |
|material |[battery](#53110-battery) |matel |
|maxHeatingLevel |[heightheatingZone](#53144-heatingzone) |maHLl |
|maxHeatingLevel |[heatingZone](#53144-heatingzone) |maHLl |
|maxLength |[textMessage](#53189-textmessage) |maxLh |
|maxLevel |[openLevel](#53156-openlevel) |maxLl |
|maxSpeed |[airFlow](#5314-airflow) |maxSd |
@@ -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&lt;TS-version>.xsd where the string '&lt;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 <a href="#_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 <a href="#_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 <a href="#_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 <a href="#_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 data point 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.1.0 | 2021-12-02 | RDM-2021-0067-TS-0023_Metadata<br />RDM-2021-0093-SDT-issues-identified_in_TDE_R5 |
| 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 |
| V5.3.0 | 2022-09-28 | RDM-2022-0017R03-Proposed_changes_to_TS-0023_for_WI_0109<br />RDM-2022-0031R01-Adding_a_heater_device_to_TS-0023<br />RDM-2022-0045R01-TS-0023_PropertyNames_rel-5<br />RDM-2022-0051-Adding_the_remoteControlEnable_Module_to_the_deviceRobotCleaner_Device<br />RDM-2022-0052R01-Adding_a_new_Device_model_deviceJuicer_to_TS-0023<br />RDM-2022-0053R01-Adding_a_new_Device_model_deviceShoesWasher_to_TS-0023<br />RDM-2022-0055-Adding_an_electric motorcycle_device_to_TS-0023 |
| V5.4.0 | 2022-11-28 | RDM-2022-0062-TS-0023_v5_1_0_add_Public_Safety_Domain_clause<br />RDM-2022-0070R01-Updating_an_elelctric_motorcycle_device_information_model<br />RDM-2022-0075-TS-0023_v5_2_0_add_SDT_defitions_for_Public_Safety_Domain |
| V5.4.0 | 2022-11-28 | RDM-2022-0062-TS-0023_v5_1_0_add_Public_Safety_Domain_clause<br />RDM-2022-0070R01-Updating_an_electric_motorcycle_device_information_model<br />RDM-2022-0075-TS-0023_v5_2_0_add_SDT_definitions_for_Public_Safety_Domain |
| V5.5.0 | 2023-04-20 | RDM-2023-0020-TS-0023_Moving_SubDeviceCuff_to_health_domain_(R5)<br />RDM-2023-0021-Adding_rule_for_FlexContainerInstance_specialization_naming_(R5)<br />RDM-2023-0022-TS-0023_Clarification_for_naming_elements_(R5)<br />RDM-2023-0023-TS-0023_Correcting_units_of_measure_(R5) |
| V5.6.0 | 2024-06-27 | RDM-2024-0014-Initial_conversion_of_TS-0023_to_markdown |