@@ -79,13 +79,13 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
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).
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 [ModuleClasses](#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 ModuleClassesClasses of the same or another [Domain](Domain).
*Devices*may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModuleClasses(#ModuleClass) 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.
...
...
@@ -179,7 +179,7 @@ Since the *Properties* are highly varied, depending on industry segment, no atte
**ModuleClass**
*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.
*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 *ModuleClass* with additional functionalities.
Every [Device](#Device) can be described by a collection of *ModuleClasses* (functionality).
