Commit 59e2cb17 authored by Yongjing Zhang's avatar Yongjing Zhang

adding definition and examples of "Product"

parent cc7bcc24
......@@ -46,6 +46,7 @@ This section provides an overview about the SDT 4.0 definitions and element hier
|Domain | Unique name, or "wrapper" which acts like a namespace, set by the organization creating the SDT, allowing reference to a package of definitions for the contained ModuleClasses and device definitions. Can be referenced when extending ModuleClasses. It has two possible uses: to select the scope of a technology domain, or to set the scope of a use case domain (like Home, SmartGrid, etc) |
| 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. |
| Product| A concrete device model with deterministic Device Properties and ModuleClasses (no optionality). It's deemed as an specialized implementation of a DeviceClass but not yet an device instance. Examples are the shopping items (e.g. a smart watch) in an online digital store that can be ordered (but not necessarily manufactured) by a customer. |
| 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|
......
......@@ -2,6 +2,7 @@
[Domain](#Domain)
[Device](#Device) | [SubDevice](#SubDevice)
[Product](#Product)
[Property](#Property)
[Module and ModuleClass](#ModuleClass)
   [Action](#Action)
......@@ -75,6 +76,7 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
---
<a name="Device"/></a>
### Device
![](images/Device.png)
......@@ -115,6 +117,7 @@ An example for a compound device is a connected power-strip where each of the s
---
<a name="SubDevice"/></a>
### SubDevice
*SubDevices* are optional components of a [Device](#Device). They represent physical sub-devices and services inside another device (the *Device*).
......@@ -143,8 +146,114 @@ An example for a compound device is a connected power-strip where each of the s
</SubDevice>
---
<a name="Product"/></a>
### Product
![](images/Product.png)
In real life of device manufacturing, there is an important concept of *Product* under a certain *DeviceClass*. For example, oneM2M may specify a generic *DeviceClass* called 'deviceSmartBracelt' with many fancy features (*ModuleClasses*). Based on the same *DeviceClass*, company A may design a *Product* called 'X-Fit' with only the *ModuleClass* of 'stepCounter' and the instantiated *Property* value of 'Manufacturer = Company A', while company B may design a *Product* called 'Y-Wristband' with the *ModuleClasses* of 'stepCounter' and 'heartRateMonitor' and the instantiated *Property* value of 'Manufacturer = Company B'. Those two *Products* are different but follow the same *DeviceClass*.
On the other hand, a *Product* is **NOT** yet a real device instance of that ¡®DeviceClass¡¯. It may not have an instantiated *Properties* like device-id, date-of-manufacturing, and the firmware/software-version, etc. It can be ¡®ordered¡¯ by the customers, but not necessarily instantiated or manufactured.
In short, a *Product* is a concrete device model with deterministic Device Properties and ModuleClasses (no optionality). It's deemed as an specialized implementation of a *DeviceClass* but not yet an device instance. Examples are the shopping items in an online digital store that can be ordered (but not necessarily manufactured) by a customer.
A *Product* can be defined by inheriting from an existing *DeviceClass* (e.g. removing unimplemented optional *Properties* and *ModuleClasses*), extending from an existing *DeviceClass* (adding new *Properties* and *ModuleClasses*), or from scratch (without basing on any *DeviceClass*).
#### Attributes
- **id** : The identifier for that *Product*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
#### Elements
All elements of *DeviceClass* can be reused in *Product*, but the *optional* attribute of those elements is not applicable (ignored if present).
- **[Doc](#Documentation)** : Documentation for the *Product*. Optional.
- **[Properties](#Property)** : Further meta-data (or properties) about the *Product*. Optional.
- **[ModuleClasses](#ModuleClass)** : A list of *Module* components that are local to the *Product*. Optional.
- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
- **Extends** : Reference to a *DeviceClass* which is extended with this *Product*. Optional.
The element has the following attributes:
- **domain** : Identifier / Reference of the [Domain](#Domain) of the extended *DeviceClass*. Required for this element.
- **class** : Name of the *DeviceClass* in the [Domain](#Domain) that is extended. Required for this element.
The element has the following child elements:
- **ImplementModuleClasses** : A list of names of the implemented optional [ModuleClasses](#ModuleClass) in the [DeviceClass](#DeviceClass) that is extended. Optional. If not present, only mandatory [ModuleClasses](#ModuleClass) are implemented. If present, both the listed optional [ModuleClasses](#ModuleClass) and the mandatory [ModuleClass](#ModuleClass) are implemented.
- **ImplementProperties** : A list of name-value pairs of the implemented optional device [Properties](#Property) in the [DeviceClass](#DeviceClass) that is extended. Optional. If not present, only mandatory [Properties](#Property) are implemented. If present, both the listed optional [Properties](#Property) and the mandatory [Properties](#Property) are implemented, and the values of those [Properties](#Property) are initiated as provided. In the case that the value of the [Properties](#Property) should not be initiated, the value can be omitted.
**Note**: New extended *Properties* and *ModuleClasses* **should** have different names from those in the inherited *DeviceClass*. In case the names conflict, the newly defined *Properties* and *ModuleClasses* shall override the inherited ones.
*Editor's Note: the description of the optionality of the datapoints, properties, actions, events in the inherited ModuleClass is FFS*
#### XML Example
```
<Product id="myMseebProduct">
<Extends domain="org.exampleDomain" class="MSEEB.root">
<ImplementProperty>
<Property name="name" value="product-abc"/>
<Property name="vendor" value="xyz"/>
<Property name="SerialNumber"/>
</ImplementProperty>
<ImplementModuleClasses>
<MoudleClass name="rootPowerOnOff"/>
<MoudleClass name="power" />
</ImplementModuleClasses>
</Extends>
<Properties name="someNewProperty" value="someValue">
<Doc>...</Doc>
<SimpleType type="string" />
</Properties>
<ModuleClasses name="someNewModuleClass">
<Actions>
<!-- List of Actions goes here-->
</Actions>
<Events>
<!-- List of Events goes here-->
</Events>
<DataPoints>
<!-- List of DataPoints goes here-->
</DataPoints>
</ModuleClasses>
</Product>
```
#### JSON Example
```
{
"Product": {
"id": "myMseebProduct",
"Extends": {
"domain": "org.exampleDomain",
"class": "MSEEB.root",
"ImplementProperties": [{
"name": "name",
"value": "product-abc"
},
{
"name": "Vendor",
"value": "xyz"
},
{
"name": "SerialNumber"
}],
"ImplementModuleClasses": ["rootPowerOnOff","power"]
},
"Properties": [{
"name": "someNewProperty",
"value": "someValue",
"Doc": "...",
"DataType": "..."
}],
"ModuleClasses": [{
"name": "someNewModuleClass",
"Actions": [],
"DataPoints": [],
"Events": []
}]
}
}
```
---
<a name="Property"/></a>
### Property : Element of a *Device* or *ModuleClass*
![](images/Property.png)
......@@ -173,6 +282,7 @@ Since the *Properties* are highly varied, depending on industry segment, no atte
---
<a name="ModuleClass"/></a>
### Module and ModuleClass
![](images/ModuleClass.png)
......@@ -227,6 +337,7 @@ The element has the following attributes:
---
<a name="DataPoint"/></a>
### DataPoint : Element of *ModuleClass* and *Event*
![](images/DataPoint.png)
......@@ -271,6 +382,7 @@ In EBNF:
---
<a name="Action"/></a>
### Action : Element of *ModuleClass*
![](images/Action.png)
......@@ -289,6 +401,7 @@ Note that systems which rely on RESTful operations need to carry out such comple
- **Args** : Zero or more occurances of [argument](#Arg) definitions for an *Action*. Optional.
<a name="ActionExample"/></a>
#### Example
The following are two examples for actions implementing a getter and a setter for boolean values.
......@@ -311,6 +424,7 @@ The following are two examples for actions implementing a getter and a setter fo
---
<a name="Event"/></a>
### Event : Element of *ModuleClass*
![](images/Event.png)
......@@ -341,6 +455,7 @@ The following are two examples for actions implementing a getter and a setter fo
---
<a name="Arg"/></a>
### Arg : Element of *Action*
![](images/Arg.png)
......@@ -362,6 +477,7 @@ See [example above](#ActionExample).
---
<a name="Data_Types"/></a>
### DataType
The data type can be simple integers or string text, or rather complex, as shown below:
......@@ -388,6 +504,7 @@ The *DataType* element is a "container" for the various aspects of a type.
---
<a name="Constraint"/></a>
### Constraint : Element of DataType
![](images/Constraint.png)
......@@ -413,6 +530,7 @@ The *TypeChoice* construct is required for syntactic reasons in the UML diagram
---
<a name="SimpleType"/></a>
### SimpleType : Element of *TypeChoice*
![](images/SimpleType.png)
......@@ -440,6 +558,7 @@ If not stated otherwise datatypes should comply to the equivalent datatypes defi
---
<a name="StructType"/></a>
### StructType : Element of *TypeChoice*
![](images/Struct.png)
......@@ -453,6 +572,7 @@ The *StructType* element can be used to represent an ordered list of diverse Dat
---
<a name="ArrayType"/></a>
### ArrayType : Element of *TypeChoice*
![](images/Array.png)
......@@ -465,6 +585,7 @@ The *ArrayType* element is provided for defining lists of data; the definition i
---
<a name="Documentation"/></a>
### Doc : Element for all Documentation
![](images/Doc.png)
......
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