Commit 23578d05 authored by Yongjing Zhang's avatar Yongjing Zhang

remove Module and replace with ModuleClass as possible. Figures needs

further update though.
parent cc7bcc24
/.Introduction.md.html
/.SDT_Components.md.html
......@@ -47,7 +47,7 @@ This section provides an overview about the SDT 4.0 definitions and element hier
| Device | Physical, addressable, identifiable appliance/sensor/actuator. |
| Sub-Device | A device (usually one of several) which may be embedded in a Device and/or is addressed via another Device. |
| ModuleClass | Specification of a single service with one or more service methods, the involved abstracted data model and related events. The expectation is that each separate service which may be used in many kinds of Devices (like PowerON/OFF, Open/Close, ...) will be described by a ModuleClass which can be re-used in many Device definitions. |
| Module | Instantiation of a ModuleClass for a specific Device or SubDevice|
**Definitions of SDT Elements.**
......
......@@ -3,7 +3,7 @@
[Domain](#Domain)
[Device](#Device) | [SubDevice](#SubDevice)
[Property](#Property)
[Module and ModuleClass](#ModuleClass)
[ModuleClass](#ModuleClass)
   [Action](#Action)
      [Arg](#Arg)
   [DataPoint](#DataPoint)
......@@ -51,7 +51,7 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
#### Elements
- **[Doc](#Documentation)** : Documentation for the *Domain*. Optional.
- **Imports** : XML import/include of other XML files. Optional.
- **[Module](#ModuleClass)** : A list of those *Module* components that are global to the whole domain. Optional.
- **[ModuleClasses](#ModuleClass)** : A list of those *ModuleClass* components that are global to the whole domain. Optional.
- **[Devices](#Device)** : a List of *Devices* components. Optional.
#### Example
......@@ -64,9 +64,9 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
<!-- Import other SDTs via XInclude's include mechanism -->
<xi:include href="./dal-core.xml" parse="xml" />
</Imports>
<Modules>
<!-- List of Domain global Modules goes here -->
</Modules>
<ModuleClasses>
<!-- List of Domain global ModuleClasses goes here -->
</ModuleClasses>
<Devices>
<!-- List of Devices goes here -->
</Devices>
......@@ -79,13 +79,13 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
![](images/Device.png)
The *Device* was initially thought of as the representation of "the basic things we are trying to model" and can still be considered so. However, after discussion with various SDOs, it was decided to add also "[sub-devices](#SubDevice)". That is, there is one level of hierarchy to allow modeling of e.g. a set of independent energy monitoring plugs in a single addressable power-extension-block. (Other SDOs might consider it more appropriate to use a recursive sub-sub-sub ... device definition). Note that all the different devices which one needs to model within a Domain are composed of one or more [Modules](#ModuleClass).
The *Device* was initially thought of as the representation of "the basic things we are trying to model" and can still be considered so. However, after discussion with various SDOs, it was decided to add also "[sub-devices](#SubDevice)". That is, there is one level of hierarchy to allow modeling of e.g. a set of independent energy monitoring plugs in a single addressable power-extension-block. (Other SDOs might consider it more appropriate to use a recursive sub-sub-sub ... device definition). Note that all the different devices which one needs to model within a Domain are composed of one or more [ModuleClassess](#ModuleClass).
For each physical device on the network at least one *Device* **must** be defined. If the physical device is a simple device, i.e. it does not contain embedded devices, e.g. a light switch, it does not include further [SubDevices](#SubDevices). On the other hand, if the physical is a compound device, i.e. it does contain embedded devices that can be addressed separately, the *Device* **should** contain [SubDevices](SubDevices) for each of the identifiable embedded devices.
An example for a compound device is a connected power-strip where each of the sockets can be switched on and off individually. The power-strip itself can provide functions such as "all sockets off" and "overall power consumption".
*Devices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModulesClasses of the same or another [Domain](Domain).
*Devices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModuleClassesClasses of the same or another [Domain](Domain).
#### Attributes
- **id** : The identifier for that *Device*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
......@@ -94,7 +94,7 @@ An example for a compound device is a connected power-strip where each of the s
- **[Doc](#Documentation)** : Documentation for the *Device*. Optional.
- **[Properties](#Property)** : Further meta-data (or properties) about the *Device*. Optional.
- **[Modules](#ModuleClass)** : A list of *Module* components that are local to the *Device*. Optional.
- **[ModuleClasses](#ModuleClass)** : A list of *ModuleClass* components that are local to the *Device*. Optional.
- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
#### Example
......@@ -104,9 +104,9 @@ An example for a compound device is a connected power-strip where each of the s
<Properties>
<!-- The list of Properties for the Device goes here-->
</Properties>
<Modules>
<!-- List of Modules local to the Device goes here-->
</Modules>
<ModuleClasses>
<!-- List of ModuleClasses local to the Device goes here-->
</ModuleClasses>
<SubDevices>
<!-- List of Sub-Devices of the Device goes here-->
</SubDevices>
......@@ -128,7 +128,7 @@ An example for a compound device is a connected power-strip where each of the s
#### Elements
- **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional.
- **[Properties](#Property)** : Further meta-data (or properties) about the *SubDevice*. Optional.
- **[Modules](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
#### Example
......@@ -137,9 +137,9 @@ An example for a compound device is a connected power-strip where each of the s
<Properties>
<!-- The list of Properties for the Device goes here-->
</Properties>
<Modules>
<!-- List of Modules local to the Device goes here-->
</Modules>
<ModuleClasses>
<!-- List of ModuleClasses local to the Device goes here-->
</ModuleClasses>
</SubDevice>
---
......@@ -173,26 +173,23 @@ Since the *Properties* are highly varied, depending on industry segment, no atte
---
<a name="ModuleClass"/></a>
### Module and ModuleClass
### ModuleClass
![](images/ModuleClass.png)
**Module**
*Module* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). There could be an infinite number of possible functionalities, however it is recommended to identify a not-too-large selection of them as generic examples (called *"*ModuleClasses*, see below) and allow for additional proprietary extensions. In a particular [Domain](#Domain) there will be one *Module* for each of the agreed *ModuleClasses* plus additional ones for each extension of a *ModuleClass*.
**ModuleClass**
The advantage of identifying a subset of generic *ModuleClasses*, described below, is that any suitable high-level software would then be able to "parse" the generic functionality for all compliant appliances, even if the proprietary parts could not be interpreted by the software.
*ModuleClass* elements are basically constraints or templates for how to model functionality of real things/appliances/devices within the [Domain](#Domain). A *ModuleClass* can be extended from another pre-defined *ModuleClass* with additional functionalities.
Every [Device](#Device) can then be described by a collection of *Modules* (functionality). In the simplest examples, where there are no extensions needed, each *ModuleClass* has exactly one "child" Module ... in such cases the software developer can consider the two terms to be the same.
Every [Device](#Device) can be described by a collection of *ModuleClasses* (functionality).
The relationship between a *ModuleClass* and a *Module* is very similar to the specification of a class and an instantiated object in an object oriented programming language.
The set of *ModuleClasses* is defined at the [Domain](#Domain) level or in the context of a [Device](#Device).
**ModuleClass**
The set of *ModuleClasses* is defined at the [Domain](#Domain) level. Each one describes some functionality (services). In principle there could be an infinite number of *ModuleClasses* (as noted above), for every kind of functionality found in UPnP, ZigBee and all the other automation protocols ... However that would not simplify the job of software developers at all! Therefore, HGI recommends that a finite and convenient number of prototypical *ModuleClasses* are re-used as much as possible (within a Domain at least).
In principle there could be an infinite number of *ModuleClasses*, for every kind of functionality found in UPnP, ZigBee and all the other automation protocols ... However that would not simplify the job of software developers at all! Therefore, oneM2M recommends that a finite and convenient number of prototypical *ModuleClasses* are re-used as much as possible (within a Domain at least). oneM2M TS-0023 specifies a set of such standardized ModuleClasses (as well as Device models).
Typical *ModuleClasses* might be equivalent to "power ON/OFF", "Open/Close", "PanUP/DOWN", "ReadTemperature", etc. Those examples make it apparent that various read/write usage of parameters, invoking of actions and waiting for events might be needed in the different *ModuleClasses*, and a guideline for those structures is explained below.
#### Attributes
- **name** : Name of the *Module* or *ModuleClass*. The name must be unique in the scope of the [Domain](#Domain). Required.
- **optional**: Boolean that indicates whether a *Module* or *ModuleClass* is optional or mandatory. Optional, the default is *false*.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment