MAS / SDT · Commits

Commit 892fd0ebc9f05129686b1b42b380cd1a07a9d84d

Authored by Andreas Kraft
2 parents 7c890b69 39a583eb

Merge pull request #14 from ankraft/sdt3 

SDT3 improved documentation
Inline Side-by-side
Showing 4 changed files with 159 additions and 146 deletions
1 1 # Introduction to the SDT
2 2  
3   -The Smart Device Template (SDT) is a template which is used to model the capabilities, actions and events of connected devices. The intent of the SDT is to be able to model any type of connected device using a well accepted and standardised format. The main application of SDT is to enable a uniformly structured Application Programmer’s Interface (API) to applications that need to interact with connected devices. Usually, these applications would communicate to devices using an Abstraction Layer as an intermediary logic. The Abstraction Layer „hides“ the technology-specific, native language format of devices of different technology type from the applications.
  3 +The SDT (Smart Device Template) is an initiative from HGI to find consensus amongst various SDOs and industry alliances to derive a common approach for device modelling. HGI and partners have the approach to agree on a set of automation commands, following a common syntax, which are sufficient to model most home appliance functions.
4 4  
5   -## The goal
  5 +At the time of writing, every software developed for home gateways or internet-of-things gateways needs to be capable of using various different protocols (ZigBee, UPnP, EchonetLite, DECT ULE, etc) to interact with a range of devices designed for the home environment. This adds extreme overheads in integrating, checking and updating code. The purpose of SDT is to describe devices and device services in a way which is independent of the LAN technology, in a format which is convenient and reliable for integration in modern code (Java, C/C++, ...).
6 6  
7   -Interoperability for smart-home and other IoT-related applications and Internet-of-Things devices and services is a key objective that is not currently easy to meet, because of the many types of technology specific device interfaces in wide deployment. There is no accepted standard.
  7 +The key goals of the SDT are: (1) keep it simple, especially for manufacturers to contribute device information; (2) modularity for functions and device types; (3) make it easy for developers to create unified APIs; (4) be independent of underlying home-area network technologies; (4) enable extendibility of the system in place without service interruption; (5) allow a pass-through mechanism to enable use of proprietary or technology-specific functions.
8 8  
9   -A major goal for service providers is that software developers should be able to write application software which would handle most of the commonly used functions for any device, irrespective of the device technology. Furthermore, software developers should not have to make major changes to the software in case a new device of similar function but of a different interface technology is used.
10   -If these goals were fully or even partly met, major advantages can be obtained:
  9 +In general a description of device (or complex appliance) behaviour can be made in many ways, with various kinds of constraints:
11 10  
12   -- Service Providers would be more able to deploy and support select new technology types of devices, because existing software application code could be more easily adapted to the new device technology.
13   -- Devices of multiple technology types could be deployed and supported by the same platform (e.g. a Home Gateway), and applications could more easily communicate with them simultaneously.
14   -- Devices of multiple technology types could be deployed by a service provider in different regions or homes, but common application code could be used to support applications. For example, a home automation application could support ECHONET devices in one set of homes, and ZigBee devices in another
15   -- Makers of software application code can more easily support multiple device technology types
16   -- Vendors using newer device technologies could more easily bring their products to new markets.
  11 +1. no constraints (e.g. using OWL 2.0 or even more "flexibly" RDF)
  12 +2. moderate constraints (e.g. using XML and a related extensible XSD template)
  13 +3. strict constraints (typical for a device certified to interoperate with a specific LAN protocol)
17 14  
18   -The interoperability benefits can potentially partially obtain even without a fully complete interoperability of the SDT. For example, the most common functions can be modeled with SDT, and more particular functions can be modeled with technology-specific, proprietary, or seldom-used aspects.
  15 +HGI chose to use the approach "moderate constraints" (XSD based) because for software development it offers ease of use and a good compromise. In particular, if there are few or no constraints on control parameters then few automatic checks can be made to detect if the software parameters are appropriate for each device integrated. XML and XSD languages were chosen because they are familiar to many developers, can be parsed with common software tools, and can still be created and interpreted by humans if necessary.
19 16  
20   -## How should SDT work?
  17 +HGI believes that Device information models based on XML and extensible XSD need some guidelines. If every possible feature of every existing LAN technology and appliance were allowed to be described in any formally correct way, then the results would be a modern Babel, no better than today's system of widely different and wildly competing automation protocols.
21 18  
22   -The basic concept is that a manufacturer, organisation or global SDO would define its preferred Smart Device Template, in XML, specified by and based on an XSD. Using that XSD, manufacturers or indeed hobbyists could "describe" existing or new devices by means of XML files, specifying the capabilities and the parameters needed to control the devices.
  19 +Therefore HGI proposes to recommend a certain structure (template) for the information model(s), but to allow extensions. Naturally, the more industry consensus is achieved for a single recommended template, the greater the utility for software developers (and users).
23 20  
24   -Assuming that the XML files conform to the specified XSD and to some guidelines described in this document, software developers could readily create APIs able to "parse" the XML-descriptions of devices and (assuming the underlying LAN technology of the device is supported by the software/hardware environment in the gateway) operate the equipment.
  21 +The SDT approach is to define re-usable basic functions (or services), labelled "ModuleClass" in the figure below, which can represent the typical functions found in many home automation systems, such as "on/off", "dim a lamp", "receive events from binary sensor", "read data from sensor", etc. Each ModuleClass is composed of a (small) number of actions, datapoint read/write operations, or asynchronous events. For example, an "on/off" ModuleClass would consist perhaps of just one Action, but a "ReadKeypad" Action might have a number of possible events, each with some data value and (usually) a sequence-ID or timestamp start/stop to indicate when and how long each key was pressed.
  22 +
25 23  
26   -The key to making software reliably interoperate with various technologies is to define in the SDT a finite and convenient to use number of functions (which is the decision of the SDO which are commonly used and can therefore be reliably re-used in software for one type of device or another.
  24 +![SmartHome Device Template (XSD) for a generic device (simplification)](images/SDT_simplified.png)
  25 +**SmartHome Device Template (XSD) for a generic device (simplification)**
27 26  
28   -For the convenience of users and developers, it would also be possible to collect the device descriptions of common "modules" (types of) appliances so that the operations of "a generic air-conditioner" could be agreed and re-used often, adapting descriptions of special models with just some special features added as local extensions. Agreeing on the definition of "a generic XYZ appliance" is rather time-consuming, so such "repository" may not become standardised, however the basic approach has huge benefits even if such an archive (also known as a "hierarchical ontology") is never formally agreed.
  27 +The SDT represents the device models introduced in the above figure by using an XSD schema to allow formal checking of compliance for XML device descriptions of specific appliances. The modularity goal in the XSD schema is achieved with re-usable XSD fragments ("ModuleClass" in the figure).
29 28  
30   -The sections below explain this in more detail.
  29 +Complex devices or appliances can then be described by an appropriate set or collection of the agreed XSD fragments (ModuleClasses), as indicated in the figure, which also shows an optional DeviceInfo XSD fragment to allow noting of static information such as device manufacturer name, device firmware version, etc etc.
31 30  
32   -## How does the SDT approach simplify software development?
  31 +HGI has discussed with many SDOs to validate these concepts. SDT is designed to take into account the list of "services" compiled by the SAREF project (https://sites.google.com/site/smartappliancesproject/home).
33 32  
34   -Simplification is achieved in software development by first developing methods to handle common or general functions, then treating necessary "uncommon" functions as extensions; treating each functionality as an individual special case does not scale. Identifying the general functions is often called "abstracting".
  33 +The SDT supports the use of a set of templates for generic devices or appliances (e.g. for a dimmable lamp, a basic washing machine, etc, which would be specific instances of the "Device" object , which form the basis of APIs used by application developers. These templates can also be referenced by manufacturers creating XML documents to describe their specific products. For example, the SDT enables specification of a generic washing machine template, with on/off, set-wash-temperature, pause and a few other commands, which could be referenced by a manufacturer as the schema for a XML description of a basic model washing machine. The SDT allows for vendor-specific additional commands (ModuleClasses) to suit specific product types.
35 34  
36   -There are four major levels of progressively greater abstraction in the signaling and software along the path between a sensor (or actuator) and a software application installed in the cloud:
  35 +The interoperability benefits can potentially partially be obtained even without a fully complete interoperability of the SDT. For example, the most common functions can be modeled with SDT, and more particular functions can be modeled with technology-specific, proprietary, or seldom-used aspects.
37 36  
38   -1. a LAN protocol can provide a common set of signaling methods for all compatible sensors/actuators/devices (abstraction at the LAN-controller)
39   -2. a local gateway software can provide common functions to operate diverse kinds of LAN-controllers (abstraction in the local gateway)
40   -3. an IoT platform in the WAN can interoperate with a number of WAN protocols supported by different kinds of gateways (abstraction at the IoT platform)
41   -4. software in the Cloud can interact with diverse IoT platforms and other software applications (abstraction in the Cloud)
  37 +Various details about the recommended structure for SDTs are described in the next sections. The key point to keep in mind is that HGI sought a compromise between, at the one extreme, complete flexibility (which could describe any device, of any complexity) and, at the other extreme, a rigid structure which could be 100% validated and lead to validated software APIs.
42 38  
43   -The concept of the SDT was created in order to make life easier for the software developer working particularly at the second level, creating software for local gateways to interact with devices connected by various kinds of (wireless) LAN technologies/protocols. The same information written into XML instantiations of the SDT do describe sensors or appliances can also be very valuable, however, to applications in the Cloud, helping to interpret the data.
44 39  
45   -Currently every software developed for home gateways or internet-of-things gateways needs to be capable of using various different protocols (ZigBee, UPnP, EchonetLite, DECT ULE, etc) to interact with a range of devices designed for the home environment. This adds extreme overheads in integrating, checking and updating code. The purpose of SDT is to describe devices and device services in a way which is independent of the LAN technology, in a format which is convenient and reliable for integration in modern code (Java, C/C++, ...).
  40 +## Definitions
46 41  
47   -In general a description of device (or complex appliance) behaviour can be made in many ways, with various kinds of constraints:
  42 +This section provides an overview about the SDT 3.0 definitions and element hierarchy. Terms to be described in detail in this section are:
48 43  
49   -1. no constraints (e.g. using OWL 2.0 or even more "flexibly" RDF)
50   -2. moderate constraints (e.g. using XML and a related extensible XSD template)
51   -3. strict constraints (typical for a device certified to interoperate with a specific LAN protocol)
  44 +| Term | Definition |
  45 +|------|------------|
  46 +|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) |
  47 +| Device | Physical, addressable, identifiable appliance/sensor/actuator. |
  48 +| Sub-Device | A device (usually one of several) which may be embedded in a Device and/or is addressed via another Device. |
  49 +| 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. |
  50 +| Module | Instantiation of a ModuleClass for a specific Device or SubDevice|
52 51  
53   -HGI chose to use the approach "moderate constraints" (XSD based) because for software development it offers ease of use and a good compromise. In particular, if there are few or no constraints on control parameters then few automatic checks can be made to detect if the software parameters are appropriate for each device integrated. XML and XSD languages were chosen because they are familiar to many developers, can be parsed with common software tools, and can still be created and interpreted by humans if necessary.
  52 +**Definitions of SDT Elements.**
54 53  
55   -HGI believes that Device information models based on XML and extensible XSD need some guidelines. If every possible feature of every existing LAN technology and appliance were allowed to be described in any formally correct way, then the results would be a modern Babel, no better than today's system of widely different and wildly competing automation protocols.
  54 +A major decision, facilitating validation of code and signalling, was to describe services (functionality) of devices in terms of ModuleClasses made up of combinations of three kinds of elements:
  55 +
  56 +1. DataPoints which are aspects of the Device that can be read/written,
  57 +2. Actions which consist of more complex sequences of operations;
  58 +3. Events which can be signalled ("published") by devices asynchronously.
56 59  
57   -Therefore HGI proposes to recommend a certain structure (template) for the information model(s), but to allow extensions. Naturally, the more industry consensus is achieved for a single recommended template, the greater the utility for software developers (and users).
  60 +This ModuleClass structure is shown in the figure below and is a major part of the SDT which is illustrated in detail in the following figure:
  61 +
  62 +![UML description of device functionality in terms of Actions, DataPoints and Events](images/MC.Action.DataPoint.Event.png)
  63 +**UML description of device functionality in terms of Actions, DataPoints and Events**
58 64  
59   -## Related aspects which are out of scope of the SDT
  65 +## How should SDT work?
60 66  
61   -Not directly part of this work is a related but separate aspect of every gateway software development: a "device abstraction layer" which can translate between (1) software APIs written based on a particular SDT and (2) the "commands" expected by several different LAN protocols and their hardware controllers.
  67 +The basic concept is that a manufacturer, organisation or global SDO would define its preferred Smart Device Template, in XML, specified by and based on an XSD. Using that XSD, manufacturers or indeed hobbyists could "describe" existing or new devices by means of XML files, specifying the capabilities and the parameters needed to control the devices.
62 68  
63   -Programmers developing a "device abstraction layer" for software in a gateway need to create run-time representations of all the recognized devices, their operations and their actual states. This internal "information model" needs to be updated in real time as the devices and the users interact. Programmers may be tempted to use the SDT structure to organize their real-time information model, adding additional information elements for the current state of each device, for some kind of "history" of commands sent/acknowledged, the user etc. This is an efficient approach BUT it must be clear that the real-time state information and history of events, etc, can NOT be represented in a pre-defined SDT not in an XML giving specific details for a device.
  69 +Assuming that the XML files conform to the specified XSD and to some guidelines described in this document, software developers could readily create APIs able to "parse" the XML-descriptions of devices and (assuming the underlying LAN technology of the device is supported by the software/hardware environment in the gateway) operate the equipment.
  70 +
  71 +The key to making software reliably interoperate with various technologies is to define in the SDT a finite and convenient to use number of functions (which is the decision of the SDO which are commonly used and can therefore be reliably re-used in software for one type of device or another.
  72 +
  73 +For the convenience of users and developers, it would also be possible to collect the device descriptions of common "modules" (types of) appliances so that the operations of "a generic air-conditioner" could be agreed and re-used often, adapting descriptions of special models with just some special features added as local extensions. Agreeing on the definition of "a generic XYZ appliance" is rather time-consuming, so such "repository" may not become standardised, however the basic approach has huge benefits even if such an archive (also known as a "hierarchical ontology") is never formally agreed.
  74 +
  75 +## Related aspects which are out of scope of the SDT
64 76  
65 77 The SDT defines the structure of all compliant XML descriptions. Each XML description of a specific device is definable at the time of manufacture of the device and can therefore only contain "static" information: (a) manufacturer data in the form of documentation elements and properties, (b) device capability information detailing the firmware operations and types/meanings of input/output variables.
  78 +
  79 +NOT directly part of this work is a related but separate aspect of every gateway software development: a "device abstraction layer" which can translate between (1) software APIs written based on a particular SDT and (2) the "commands" expected by several different LAN protocols and their hardware controllers.
  80 +
  81 +Programmers developing a "device abstraction layer" for software in a gateway need to create run-time representations of all the recognized devices, their operations and their actual states. This internal "information model" needs to be updated in real time as the devices and the users interact. Programmers may be tempted to use the SDT structure to organize their real-time information model, adding additional information elements for the current state of each device, for some kind of "history" of commands sent/acknowledged, the user etc.
  82 +
  83 +The above is an efficient approach BUT it must be clear that the real-time state information and history of events, etc, can NOT be represented in a pre-defined SDT and in the XML giving specific details for a device.
  84 +
  85 +---
  86 +
  87 +Click [here](SDT_Components.md) for detailed documentation about SDT.
  88 +
  89 +
... ...
... ... @@ -3,8 +3,9 @@
3 3 [Domain](#Domain)
4 4 [Device](#Device) | [SubDevice](#SubDevice)
5 5 [Property](#Property)
6   -[ModuleClass](#ModuleClass)
  6 +[Module and ModuleClass](#ModuleClass)
7 7    [Action](#Action)
  8 +      [Arg](#Arg)
8 9    [DataPoint](#DataPoint)
9 10    [Event](#Event)
10 11 [Data Types](#Data_Types)
... ... @@ -17,28 +18,10 @@
17 18  
18 19 ---
19 20  
20   -In this document an overview about the SDT 3.0 definitions and component hierarchy is given.
21   -
22   -Various details about recommended structure for SDTs are described in the next sections. The key point to keep in mind is that HGI sought a compromise between, at the one extreme, complete flexibility (which could describe any device, of any complexity) and, at the other extreme, a rigid structure which could be 100% validated and lead to validated software APIs.
23   -
24   -A major decision, facilitating validation of code and signalling, was to describe services (functionality) of devices in terms of ModuleClasses made up of combinations of three kinds of elements:
25   -
26   -1. DataPoints which can be read/written,
27   -2. Actions which consist of more complex sequences of operations;
28   -3. Events which can be signalled ("published") by devices asynchronously.
29   -
30   -This structure shown in the following figure.
31   -
32   -![](images/MC.Action.DataPoint.png)
33   -
34 21  
35 22 ## SDT Overview
36 23  
37   -The following UML diagram presents an overview of the structure (elements) of every SDT which is conformant with these guidelines. As implied in the above descriptions, there can be many different choices of the details of a SDT, each one optimized for a particular market segment and the types of devices used in that market segment. Obviously an unnecessary proliferation is counter-productive, but as long as each SDT conforms to the structure shown below then it will be possible with little or modest effort for software applications to be adapted accordingly.
38   -
39   -The reader must keep in mind that the UML diagram below is in a sense the meta-format for different possible Smart Device Templates (XSDs) for device descriptions (XMLs) of real devices - sorry about that.
40   -
41   -The followng UML diagram presents an overview about the SDT components.
  24 +The following UML diagram presents an overview of the structure (elements) of every SDT which is conformant with these guidelines. As implied in the above descriptions, there can be many different choices of the details of a SDT, each one optimized for a particular market segment and the types of devices used in that market segment. Obviously an unnecessary proliferation is counter-productive, but as long as each SDT conforms to the structure shown below then it will be possible with little or modest effort for software to be adapted accordingly.
42 25  
43 26 ![](images/SDT_UML_Basic_Elements.png)
44 27  
... ... @@ -46,15 +29,13 @@ The key to the diagram elements of the UML diagrams above and the snippets in th
46 29  
47 30 ![](images/SDT_UML_Key.png)
48 31  
  32 +<a name="Domain"></a>
  33 +
49 34 The syntax used in the diagram to model an XML Schema Definition (XSD) as an UML diagram follows the following approaches:
50 35  
51 36 - [Design XML schemas using UML](http://www.ibm.com/developerworks/library/x-umlschem/)
52 37 - [UML For W3C XML Schema Design](http://www.xml.com/pub/a/2002/08/07/wxs_uml.html)
53 38  
54   -
55   -## Components
56   -
57   -<a name="Domain"></a>
58 39 ### Domain
59 40  
60 41 ![](images/Domain.png)
... ... @@ -70,7 +51,7 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
70 51 #### Elements
71 52 - **[Doc](#Documentation)** : Documentation for the *Domain*. Optional.
72 53 - **Imports** : XML import/include of other XML files. Optional.
73   -- **[Module](#ModuleClass)** : A list of *Module* components that are global to the whole domain. Optional.
  54 +- **[Module](#ModuleClass)** : A list of those *Module* components that are global to the whole domain. Optional.
74 55 - **[Devices](#Device)** : a List of *Devices* components. Optional.
75 56  
76 57 #### Example
... ... @@ -79,12 +60,10 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
79 60 xmlns="http://homegatewayinitiative.org/xml/dal/3.0"
80 61 id="org.homegatewayinitiative">
81 62 <Doc>Some documentation</Doc>
82   -
83 63 <Imports>
84 64 <!-- Import other SDTs via XInclude's include mechanism -->
85 65 <xi:include href="./dal-core.xml" parse="xml" />
86 66 </Imports>
87   -
88 67 <Modules>
89 68 <!-- List of Domain global Modules goes here -->
90 69 </Modules>
... ... @@ -102,7 +81,7 @@ It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
102 81  
103 82 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).
104 83  
105   -For each physical device on the network at least one *Device* **must** be defined. If the physical device is a simple device, ie. 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, ie. it does contain embedded devices that can be addressed separately, the *Device* **should** contain [SubDevices](SubDevices) for each of the identifiable embedded devices.
  84 +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.
106 85  
107 86 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".
108 87  
... ... @@ -139,7 +118,7 @@ An example for a compound device is a connected power-strip where each of the s
139 118 ### SubDevice
140 119 *SubDevices* are optional components of a [Device](#Device). They represent physical sub-devices and services inside another device (the *Device*).
141 120  
142   -*SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend ModulesClasses of its or another [Domain](#Domain).
  121 +*SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend *ModuleClasses* of it's or another [Domain](#Domain).
143 122  
144 123 ![](images/SubDevice.png)
145 124  
... ... @@ -166,13 +145,13 @@ An example for a compound device is a connected power-strip where each of the s
166 145 ---
167 146  
168 147 <a name="Property"/></a>
169   -### Property
  148 +### Property : Element of a *Device* or *ModuleClass*
170 149  
171 150 ![](images/Property.png)
172 151  
173 152 *Property* elements are used to append to [Devices](#Device) and their [ModuleClass](ModuleClass) elements with arbitrary additional information. For [Devices](#Device) it would be very common for a manufacturer to want to add into the XML file which is describing the device such information as "Manufacturing Site", "Date of Manufacture", "Certification Code", "Energy Label Code", "compatible LAN technology", "URL for the device handbook", "physical limits of operation environments", etc.
174 153  
175   -Some of that information might in some devices be available by reading a specific device [DataPoint](#DataPoint), however even if it cannot be read from the device then at least it can be noted in the device's XML description. Examples for organizations that specifiy these kind of added "Property" information are [eCl@ss](http://www.eclass.eu) and [UNSPSC](http://www.unspsc.org) (United Nations Standard Products and Services Code).
  154 +Some of that information might in some devices be available by reading a specific device [DataPoint](#DataPoint), however even if it cannot be read from the device then at least it can be noted in the device's XML description. Examples for organizations that specify these kind of added "Property" information are [eCl@ss](http://www.eclass.eu) and [UNSPSC](http://www.unspsc.org) (United Nations Standard Products and Services Code).
176 155  
177 156 Since the *Properties* are highly varied, depending on industry segment, no attempt is made in the SDT to constrain the options: however it is highly recommended to provide software-developer-friendly information in the [Doc](#Documentation) field of each Property.
178 157  
... ... @@ -194,7 +173,7 @@ Since the *Properties* are highly varied, depending on industry segment, no atte
194 173 ---
195 174  
196 175 <a name="ModuleClass"/></a>
197   -### Module, ModuleClass
  176 +### Module and ModuleClass
198 177  
199 178 ![](images/ModuleClass.png)
200 179  
... ... @@ -202,7 +181,7 @@ Since the *Properties* are highly varied, depending on industry segment, no atte
202 181  
203 182 *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*.
204 183  
205   -The advantage of identifying a subset of generic *ModuleClasses* 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.
  184 +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.
206 185  
207 186 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.
208 187  
... ... @@ -225,7 +204,7 @@ Typical *ModuleClasses* might be equivalent to &quot;power ON/OFF&quot;, &quot;Open/Close&quot;, &quot;Pa
225 204 The element has the following attributes:
226 205 - **domain** : Identifier / Reference of the [Domain](#Domain) of the extended *ModuleClass*. Required for this element.
227 206 - **class** : Name of the *ModuleClass* in the [Domain](#Domain) that is extended. Required for this element.
228   -- **[Properties](#Property)** : Further meta-data (or properties) about the *SubDevice*. Optional.
  207 +- **[Properties](#Property)** : Further meta-data (or properties) about the *Module* or *ModuleClass*. Optional.
229 208 - **[Actions](#Action)** : A list of *Action* components, each defining a single action. Optional.
230 209 - **[Data](#DataPoint)** : A list of *DataPoint* components. Optional.
231 210 - **[Events](#Event)** : A list of *Event* components. Optional.
... ... @@ -247,70 +226,14 @@ The element has the following attributes:
247 226  
248 227 ---
249 228  
250   -<a name="Action"/></a>
251   -### Action
252   -
253   -![](images/Action.png)
254   -
255   -*Action* elements are an efficient way of describing arbitrary sequences of operations/methods; these are very common in automation. Typical example include "FactoryReset", and "AutoCalibrate". *Actions* preserve transaction integrity by putting together all the parameters ("args", see next section) with the method which checks and executes them, in one step.
256   -
257   -Note that systems which rely on RESTful operations need to carry out such complex setup-parameters-then-do-action by first using (several) [DataPoint](#DataPoint) operations to "load" the parameters to the device and then do a [DataPoint](#DataPoint) operation to manipulate the "start operation NOW" action.
258   -
259   -#### Attributes
260   -- **name** : The name of the *Action*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
261   -- **optional**: Boolean that indicates whether an *Action* is optional or mandatory. Optional, the default is *false*.
262   -
263   -#### Elements
264   -- **[Doc](#Documentation)** : Documentation for the *Action*. Optional.
265   -- **[DataType](#DataType)** : The return type of the *Action*. It must comply to the *DataType* definition. Optional. If no *DataType* is specified the *Action* does not return a value.
266   -- **Args** : Zero or more occurances of [argument](#Arg) definitions for an *Action*. Optional.
267   -
268   -#### Example
269   -The following are two examples for actions implementing a getter and a setter for boolean values.
270   -
271   - <Action name="get" type="boolean">
272   - <Doc>Obtain the current associated state. Example of a getter.</Doc>
273   - </Action>
274   -
275   - <Action name="setTarget">
276   - <Doc>Set the associated state to the specified value. Example of a setter.</Doc>
277   - <Args>
278   - <Arg name="value">
279   - <Doc>The desired value of the associated state.</Doc>
280   - <DataType>
281   - <SimpleType type="boolean" />
282   - </DataType>
283   - </Arg>
284   - </Args>
285   - </Action>
286   -
287   ----
288   -<a name="Arg"/></a>
289   -### Arg
290   -
291   -![](images/Arg.png)
292   -
293   -The *Arg* element represents the parameter information which a device needs to carry out a required *Action*.
294   -
295   -The *Arg* has the following attributes and elements:
296   -
297   -#### Attributes
298   -- **name** : The name of the *Arg* attribute. Required.
299   -
300   -#### Elements
301   -- **[Doc](#Documentation)** : Documentation for the *argument*. Optional.
302   -- **[DataType](#DataType)** : The return type of the *argument*. It must comply to the *DataType* definition. Required.
303   -
304   ----
305   -
306   -<a name="Data"/></a>
307   -### DataPoint
  229 +<a name="DataPoint"/></a>
  230 +### DataPoint : Element of *ModuleClass* and *Event*
308 231  
309 232 ![](images/DataPoint.png)
310 233  
311   -A *DataPoint* element represents an aspect of a device which can be read/written to, and forms part of a device’s data model. Manipulating *DataPoints* is the most common way of controlling devices. Each *DataPoint* has an associated *type* (e.g. simple integer/real numbers, string of text, struct, or arrays thereof) which facillitates data integrity. Note that all RESTful systems (e.g. CoAP) only use *DataPoint* operations, so the mapping of a data models using an SDT into RESTful applications is easy.
  234 +A *DataPoint* element represents an aspect of a device which can be read/written to, and forms part of a device’s data model. Manipulating *DataPoints* is the most common way of controlling devices. Each *DataPoint* has an associated *type* (e.g. simple integer/real numbers, string of text, struct, or arrays thereof) which facillitates data integrity. Note that all RESTful systems (e.g. CoAP) use only *DataPoint* operations, so the mapping of a data models using an SDT into RESTful applications is easy.
312 235  
313   -However, *DataPoints* are not the only way of controlling devices, so further "Actions" and "Events are described below.
  236 +However, *DataPoints* are not the only way of controlling devices, so further [Actions](#Action) and [Events](#Event) are described below.
314 237  
315 238 Though *DataPoints* only refer to single data points of a physical device it is possible to describe hierarchies by model the path to the data point in the hierarchy by a path-like structure like to the pathname of a UNIX file system. Here, the root node of the hierarchy is a slash (/ 0x2F) and the segments or nodes along the path are also separated by slashes. The actual datapoint is the last leaf at the path.
316 239  
... ... @@ -347,8 +270,48 @@ In EBNF:
347 270  
348 271 ---
349 272  
  273 +<a name="Action"/></a>
  274 +### Action : Element of *ModuleClass*
  275 +
  276 +![](images/Action.png)
  277 +
  278 +*Action* elements are an efficient way of describing arbitrary sequences of operations/methods; these are very common in automation. Typical example include "FactoryReset", and "AutoCalibrate". *Actions* preserve transaction integrity by putting together all the parameters ("args", see next section) with the method which checks and executes them, in one step.
  279 +
  280 +Note that systems which rely on RESTful operations need to carry out such complex setup-parameters-then-do-action by first using (several) [DataPoint](#DataPoint) operations to "load" the parameters to the device and then do a [DataPoint](#DataPoint) operation to manipulate the "start operation NOW" action.
  281 +
  282 +#### Attributes
  283 +- **name** : The name of the *Action*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
  284 +- **optional**: Boolean that indicates whether an *Action* is optional or mandatory. Optional, the default is *false*.
  285 +
  286 +#### Elements
  287 +- **[Doc](#Documentation)** : Documentation for the *Action*. Optional.
  288 +- **[DataType](#DataType)** : The return type of the *Action*. It must comply to the *DataType* definition. Optional. If no *DataType* is specified the *Action* does not return a value.
  289 +- **Args** : Zero or more occurances of [argument](#Arg) definitions for an *Action*. Optional.
  290 +
  291 +<a name="ActionExample"/></a>
  292 +#### Example
  293 +The following are two examples for actions implementing a getter and a setter for boolean values.
  294 +
  295 + <Action name="get" type="boolean">
  296 + <Doc>Obtain the current associated state. Example of a getter.</Doc>
  297 + </Action>
  298 +
  299 + <Action name="setTarget">
  300 + <Doc>Set the associated state to the specified value. Example of a setter.</Doc>
  301 + <Args>
  302 + <Arg name="value">
  303 + <Doc>The desired value of the associated state.</Doc>
  304 + <DataType>
  305 + <SimpleType type="boolean" />
  306 + </DataType>
  307 + </Arg>
  308 + </Args>
  309 + </Action>
  310 +
  311 +---
  312 +
350 313 <a name="Event"/></a>
351   -### Event
  314 +### Event : Element of *ModuleClass*
352 315  
353 316 ![](images/Event.png)
354 317  
... ... @@ -377,27 +340,42 @@ In EBNF:
377 340  
378 341 ---
379 342  
380   -<a name="Data_Types"/></a>
381   -### Data Types
382   -The data type can be simple integers or string text, or rather complex, as shown below:
  343 +<a name="Arg"/></a>
  344 +### Arg : Element of *Action*
383 345  
384   -![](images/SDT_UML_DataType.png)
  346 +![](images/Arg.png)
  347 +
  348 +The *Arg* element represents the parameter information which a device needs to carry out a required *Action*.
385 349  
386   -The various elements are described in the sections below.
  350 +The *Arg* has the following attributes and elements:
  351 +
  352 +#### Attributes
  353 +- **name** : The name of the *Arg* attribute. Required.
  354 +
  355 +#### Elements
  356 +- **[Doc](#Documentation)** : Documentation for the *argument*. Optional.
  357 +- **[DataType](#DataType)** : The return type of the *argument*. It must comply to the *DataType* definition. Required.
  358 +
  359 +#### Example
  360 +See [example above](#ActionExample).
387 361  
388 362 ---
389 363  
390   -<a name="DataType"/></a>
  364 +<a name="Data_Types"/></a>
391 365 ### DataType
  366 +The data type can be simple integers or string text, or rather complex, as shown below:
  367 +
  368 +![](images/SDT_UML_DataType.png)
  369 +
  370 +The various elements are described in the sections below.
392 371  
393 372 ![](images/DataType.png)
394   -![](images/TypeChoice.png)
395 373  
396 374 The *DataType* element is a "container" for the various aspects of a type.
397 375  
398 376 #### Attributes
399 377 - **name** : The name of the *DataType*. The name must be set for the [Struct](#Struct) types to distinguish individual fields in that structure. It can be used in other cases. Optional.
400   -- **unitOfMeasure** : This is the option to label the data with the units of measurement. A "Temperature" measurement is meaningless until the units Kelvin, Celcius, Fahrenheit etc are known. Because of the extreme variety of units, a string field is the default annotation method, although of course a SDO could decide to reference a standardized list of units. Optional.
  378 +- **unitOfMeasure** : Before considering the type of data in detail, there is the option to label the data with the units of measurement. A "Temperature" measurement is meaningless until the units Kelvin, Celcius, Fahrenheit etc are known. Because of the extreme variety of units, a string field is the default annotation method, although of course a SDO could decide to reference a standardized list of units. Optional.
401 379  
402 380 #### Elements
403 381 - **[Doc](#Documentation)** : Documentation for the *DataType* Element. Optional.
... ... @@ -410,7 +388,7 @@ The *DataType* element is a &quot;container&quot; for the various aspects of a type.
410 388 ---
411 389  
412 390 <a name="Constraint"/></a>
413   -### Constraint
  391 +### Constraint : Element of DataType
414 392  
415 393 ![](images/Constraint.png)
416 394  
... ... @@ -426,12 +404,20 @@ The *Constraint* element is an optional element allowing the manufacturer to pro
426 404  
427 405 ---
428 406  
  407 +### TypeChoice : Construct of *DataType*
  408 +
  409 + ![](images/TypeChoice.png)
  410 +
  411 +The *TypeChoice* construct is required for syntactic reasons in the UML diagram and the choice from the enumerated list simply designates the complexity of the following DataType.
  412 +
  413 +---
  414 +
429 415 <a name="SimpleType"/></a>
430   -### SimpleType
  416 +### SimpleType : Element of *TypeChoice*
431 417  
432 418 ![](images/SimpleType.png)
433 419  
434   -The "SimpleType" element is required in order for software to understand the format of the associated data, e.g. are the bytes an integer or real value? The selection choosen is based on practical experience to include some specific types which are slightly more complex:
  420 +The *SimpleType* element is required in order for software to understand the format of the associated data, e.g. are the bytes an integer or real value? The selection choosen by HGI is based on practical experience to include some specific types which are slightly more complex:
435 421  
436 422 1. the (technically redundant) options of *date* and *time* - to avoid problems which can arise interpreting a *datetime* value;
437 423 2. *url* because it is expected to become extremely common to provide links to other data sources;
... ... @@ -454,7 +440,7 @@ If not stated otherwise datatypes should comply to the equivalent datatypes defi
454 440 ---
455 441  
456 442 <a name="StructType"/></a>
457   -### StructType
  443 +### StructType : Element of *TypeChoice*
458 444  
459 445 ![](images/Struct.png)
460 446  
... ... @@ -467,7 +453,7 @@ The *StructType* element can be used to represent an ordered list of diverse Dat
467 453 ---
468 454  
469 455 <a name="ArrayType"/></a>
470   -### ArrayType
  456 +### ArrayType : Element of *TypeChoice*
471 457  
472 458 ![](images/Array.png)
473 459  
... ... @@ -479,8 +465,11 @@ The *ArrayType* element is provided for defining lists of data; the definition i
479 465 ---
480 466  
481 467 <a name="Documentation"/></a>
482   -# Documentation
483   -The *Doc* documentation element is optionally available in most components of the SDT. Its purpose is to provide a short documentation for the respective element. The documentation language *should* be English.
  468 +### Doc : Element for all Documentation
  469 +
  470 +![](images/Doc.png)
  471 +
  472 +*Doc* elements (optional for all the above Elements) are very important to help understand the software-readable information for specific devices and services. They contain the human-readable information. Many automation protocols describe every possible operation in a comprehensive specification, however SDT is designed to include the relevant information at the "point of use" for the software developer, inside the SDT (and XML files based on it).
484 473  
485 474 The text inside the *Doc* element can be structure using a very limited subset of HTML elements. The possible structuring is defined in EBNF as follows:
486 475  
... ...