Commit c9402c98794de3865fde3639e4953253e268b2e0

Authored by ankraft
1 parent f1208039

Added more documentation and examples

1 1 # Examples and Contributions
  2 +[A simple example](#simpleExample)
  3 +[Multi Socket Electrical-Extension-Block](#mseeb)
2 4  
3   -## HGI
  5 +<a name="simpleExample"></a>
  6 +## A very simple SDT example
  7 +In the ideal case, a large organization or SDO would define a widely-applicable set of [ModuleClasses](SDT_Components.md#ModuleClass), each of which could be used as needed to compose the description of a complex device. In order to show the appoach, this section will create a few example ModuleClasses based on - or inspired by - featues in the Echonet Lite protocol. Please note that the examples shown in this document are very "cut down" and by no means represent a true representation of Echonet Lite.
  8 +
  9 +The Echonet Consortium has standardized their specifications within IEC/ISO (IEC62394, ISO/IEC24767-1, ISO/IEC24767-2, IEC62480, ISO/IEC14543-4-1, ISO/IEC14543-4-2, IEC62457) and they provide a comprehensive collection of various types of home appliances relevant to SmartGrid applications as ECHONET Device objects (see [https://echonet.jp/spec_object_rf_en/](https://echonet.jp/spec_object_rf_en/) ).
  10 +
  11 +For the example in this document, to show re-use of ModuleClass definitions, two complex devices are chosen which have some common features and hence could be expected to both use some of the same ModuleClasses: an air conditioner and a washing machine.
  12 +
  13 +<table>
  14 +<tr><th>Funtionality</th><th>Air Conditioner</th><th>Washing Machine</th></tr>
  15 +<tr><td>operationStatus</td><td>operates on/off</td><td>operates on/off</td></tr>
  16 +<tr><td>measuredCumulativePowerConsumption</td><td>the cumulative power consumption</td><td>the cumulative power consumption</td></tr>
  17 +<tr><td>installationLocation</td><td>this sets/reads a string text describing the location (room) of the air-conditioner.</td><td>this sets/reads a string text describing the location (room) of the washing machine.</td></tr>
  18 +<tr><td>setTimer</td><td>(not applicable. there is no preset start for an air-conditioner)</td><td>This sets/reads use the on/off timer</td></tr>
  19 +</table>
  20 +
  21 +Based on the simplified example above, the two appliances will need the ModuleClasses below:
  22 +
  23 +- *air-conditioner*: operationStatus, measuredCumulativePowerConsumption, installationLocation;
  24 +- *washing-machine*: operationStatus, measuredCumulativePowerConsumption, and setTimer.
  25 +
  26 + <ModuleClass name="operationStatus">
  27 + <Data>
  28 + <DataPoint name="operationStatus" writable="true">
  29 + <Doc>This property sets/reads the ON/OFF status.</Doc>
  30 + <DataType>
  31 + <SimpleType type="boolean"/>
  32 + </DataType>
  33 + </DataPoint>
  34 + </Data>
  35 + <Events>
  36 + <Event name="operationStatus">
  37 + </Event>
  38 + </Events>
  39 + </ModuleClass>
  40 +
  41 + <ModuleClass name="measuredCumulativePowerConsumption">
  42 + <Data>
  43 + <DataPoint name="measuredCumulativePowerConsumption" writable="false">
  44 + <Doc>This indicates cumulative power consumption of the device in increments of 0.001kWh.</Doc>
  45 + <DataType>
  46 + <SimpleType type="integer"/>
  47 + </DataType>
  48 + </DataPoint>
  49 + </Data>
  50 + </ModuleClass>
  51 +
  52 + <ModuleClass name="installationLocation">
  53 + <Data>
  54 + <DataPoint name="installationLocation" writable="true">
  55 + <Doc>This property indicates the installation location</Doc>
  56 + <DataType>
  57 + <SimpleType type="string"/>
  58 + </DataType>
  59 + </DataPoint>
  60 + </Data>
  61 + <Events>
  62 + <Event name="installationLocation"> </Event>
  63 + </Events>
  64 + </ModuleClass>
  65 +
  66 + <ModuleClass name="onTimerSetting">
  67 + <DataPoint name="onTimer" writable="true">
  68 + <Doc>Timer value (HH:MM)</Doc>
  69 + <DataType>
  70 + <SimpleType type="time"/>
  71 + </DataType>
  72 + </DataPoint>
  73 + </ModuleClass>
  74 +
  75 +The structure and the according SDT now looks like this:
  76 +
  77 +<table>
  78 +<tr><td colspan="2" width="50%"><b>Example1.SDT</b></td></tr>
  79 +<tr><td> </td><td>Namespace information</td></tr>
  80 +<tr><td> </td><td>Modules (contains ModuleClasses)</td></tr>
  81 +<tr><td> </td><td>operationStatus<ul>
  82 + <li>measuredCumulativePowerConsumption</li>
  83 + <li>installationLocation</li>
  84 + <li>onTimerSetting</li></ul></td></tr>
  85 +</table>
  86 +
  87 + <?xml version="1.0" encoding="iso-8859-1"?>
  88 + <!-- Example1 SDT inspired by some Echonet Lite examples -->
  89 + <Domain xmlns="http://homegatewayinitiative.org/xml/dal/3.0"
  90 + xmlns:xi="http://www.w3.org/2001/XInclude"
  91 + id="example1.SDT">
  92 +
  93 + <Modules>
  94 + <!-- Various examples for module classes -->
  95 + <ModuleClass name="operationStatus">
  96 + <Data>
  97 + <DataPoint name="operationStatus" writable="true">
  98 + <Doc>This property sets the ON/OFF status.</Doc>
  99 + <DataType>
  100 + <SimpleType type="boolean"/>
  101 + </DataType>
  102 + </DataPoint>
  103 + </Data>
  104 + <Events>
  105 + <Event name="operationStatus">
  106 + </Event>
  107 + </Events>
  108 + </ModuleClass>
  109 +
  110 + <ModuleClass name="installationLocation">
  111 + <Data>
  112 + <DataPoint name="installationLocation" writable="true">
  113 + <Doc>This property indicates the installation location</Doc>
  114 + <DataType>
  115 + <SimpleType type="string"/>
  116 + </DataType>
  117 + </DataPoint>
  118 + </Data>
  119 + <Events>
  120 + <Event name="installationLocation"> </Event>
  121 + </Events>
  122 + </ModuleClass>
  123 +
  124 + <ModuleClass name="measuredCumulativePowerConsumption">
  125 + <Data>
  126 + <DataPoint name="measuredCumulativePowerConsumption" writable="false">
  127 + <Doc>This indicates cumulative power consumption of the device in increments of 0.001kWh.</Doc>
  128 + <DataType>
  129 + <SimpleType type="integer"/>
  130 + </DataType>
  131 + </DataPoint>
  132 + </Data>
  133 + </ModuleClass>
  134 +
  135 + <ModuleClass name="onTimerSetting">
  136 + <DataPoint name="onTimer" writable="true">
  137 + <Doc>Timer value (HH:MM)</Doc>
  138 + <DataType>
  139 + <SimpleType type="time"/>
  140 + </DataType>
  141 + </DataPoint>
  142 + </ModuleClass>
  143 + </Modules>
  144 + </Domain>
  145 +
  146 +
  147 +---
  148 +
  149 +<a name="mseeb"></a>
4 150 ### Multi Socket Electrical-Extension-Block
5 151  
6   -[mseeb.xml](../test/mseeb.xml)
  152 +This example is a specification for an imaginged device, a connected extension block with multiple power socket where each of the sockets are modeled as a
  153 +separate *SubDevice*.
7 154  
8   -![Multi Socket Electrical-Extension-Block Structure](images/examples/hgi_mseeb.png)
  155 +[mseeb.xml](../test/mseeb.xml)
9 156  
10   -## DECT ULE
11 157  
12   -## Echonet
  158 +---
13 159  
14   -## EnOcean
15 160 \ No newline at end of file
... ...
1 1 # SDT Components
2 2  
3 3 [Domain](#Domain)
4   -[RootDevice](#RootDevice) | [Device](#Device)
5   -&nbsp;&nbsp;&nbsp;[DeviceInfo](#DeviceInfo)
  4 +[Device](#Device) | [SubDevice](#SubDevice)
  5 +[Property](#Property)
6 6 [ModuleClass](#ModuleClass)
7 7 &nbsp;&nbsp;&nbsp;[Action](#Action)
8   -&nbsp;&nbsp;&nbsp;[Data / DataPoint](#Data)
9   -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[DataType](#DataType)
  8 +&nbsp;&nbsp;&nbsp;[DataPoint](#DataPoint)
10 9 &nbsp;&nbsp;&nbsp;[Event](#Event)
  10 +[Data Types](#Data_Types)
  11 +&nbsp;&nbsp;&nbsp;[DataType](#DataType)
  12 +&nbsp;&nbsp;&nbsp;[Constraint](#Constraint)
  13 +&nbsp;&nbsp;&nbsp;[SimpleType](#SimpleType)
  14 +&nbsp;&nbsp;&nbsp;[StructType](#StructType)
  15 +&nbsp;&nbsp;&nbsp;[ArrayType](#ArrayType)
11 16 [Doc](#Documentation)
12 17  
13 18 ---
... ... @@ -37,10 +42,6 @@ The followng UML diagram presents an overview about the SDT components.
37 42  
38 43 ![](images/SDT_UML_Basic_Elements.png)
39 44  
40   -The [DataType](#DataType) strukture is shown in the following UML diagram:
41   -
42   -![](images/SDT_UML_DataType.png)
43   -
44 45 The key to the diagram elements of the UML diagrams above and the snippets in the following sections:
45 46  
46 47 ![](images/SDT_UML_Key.png)
... ... @@ -53,176 +54,181 @@ The syntax used in the diagram to model an XML Schema Definition (XSD) as an UML
53 54  
54 55 ## Components
55 56  
56   -
57   -**NOTE** The content here is still SDT2 and needs to be updated
58   -
59   -
60   -
61   -
62 57 <a name="Domain"></a>
63 58 ### Domain
64   -The *Domain* is the top-level component that defines all modules and devices of a domain. A *Domain* can import definitions of other domains.
65   -
66   -A *Domain* can define [Modules](#ModuleClass) or [RootDevices](#RootDevice) only, or may choose to provide both.
67 59  
68 60 ![](images/Domain.png)
69 61  
  62 +The *Domain* element allows labeling of different SDT templates for different technologies and/or industry segments ("verticals"): for example eHealth and Building Management might prefer quite different detailed structures/templates. This also helps keep information in human-friendly and manageable blocks. It is assumed that there will be multiple "SDT Templates" and some of them may be completely proprietary.
  63 +
  64 +It can also be used to collect all specified [ModuleClasses](#ModuleClasses)
  65 + and [Devices](#Devices) in one referencable logical group.
  66 +
70 67 #### Attributes
71 68 - **id** : The identifier for that *Domain*. Required.
72 69  
73 70 #### Elements
  71 +- **[Doc](#Documentation)** : Documentation for the *Domain*. Optional.
74 72 - **Imports** : XML import/include of other XML files. Optional.
75   -- **Modules** : A list of [Module](#ModuleClass) components that are global to the whole domain. Optional.
76   -- **RootDevices** : a List of [RootDevices](#RootDevice) components. Optional.
  73 +- **[Module](#ModuleClass)** : A list of *Module* components that are global to the whole domain. Optional.
  74 +- **[Devices](#Device)** : a List of *Devices* components. Optional.
77 75  
78 76 #### Example
79 77  
80 78 <Domain xmlns:xi="http://www.w3.org/2001/XInclude"
81 79 xmlns="http://homegatewayinitiative.org/xml/dal/3.0"
82 80 id="org.homegatewayinitiative">
  81 + <Doc>Some documentation</Doc>
  82 +
83 83 <Imports>
84   - <xi:include href="./dal-core.xml" parse="xml" />
  84 + <!-- Import other SDTs via XInclude's include mechanism -->
  85 + <xi:include href="./dal-core.xml" parse="xml" />
85 86 </Imports>
  87 +
86 88 <Modules>
87 89 <!-- List of Domain global Modules goes here -->
88 90 </Modules>
89   - <RootDevices>
90   - <!-- List of RootDevices goes here -->
91   - </RootDevices>
  91 + <Devices>
  92 + <!-- List of Devices goes here -->
  93 + </Devices>
92 94 </Domain>
93 95  
94   -
95 96 ---
96 97  
97   -<a name="RootDevice"/></a>
98   -### RootDevice
  98 +<a name="Device"/></a>
  99 +### Device
99 100  
100   -A *RootDevice* is the definition of a physical device that may contain optional embedded sub-devices. It represents the idea an appliance that is addressable on a Home Area Network where one or more sub-[Devices](#Devices) provide certain functionalities.
  101 +![](images/Device.png)
101 102  
102   -For each physical device on the network at least one *RootDevice* **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 *Devices*. On the other hand, if the pyhsical is a compound device, ie. it does contain embedded devices that can be addressed separately, the *RootDevice* **should** contain *Devices* for each of the identifiable embedded devices.
  103 +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).
103 104  
104   -There is also the possibility to have more than one *RootDevice* for one physical device if a physical device offers more than one distinguishable services or when it is for other reasons meaningful to deliberatly separate the device's services.
  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.
105 106  
106 107 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".
107 108  
108   -If the *RootDevice* includes sub-[Devices](#Device) then each sub-device may be of the same type or of different types. The functionality ([Actions](#Action)) of the *RootDevice* may be different from the functionality of its sub-[Devices](#Device).
109   -
110   -If the *RootDevice* does not include sub-devices then the *RootDevice* is the actual adressable device that provides all the functionality of the connected appliance.
111   -
112   -*RootDevices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModulesClasses of the same or another *Domain*.
113   -
114   -![](images/RootDevice.png)
  109 +*Devices* may define their own [ModuleClasses](#ModuleClass) or refer to predefined ModulesClasses of the same or another [Domain](Domain).
115 110  
116 111 #### Attributes
117   -- **id** : The identifier for that *RootDevice*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
  112 +- **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.
118 113  
119 114 #### Elements
120 115  
121   -- **[Doc](#Documentation)** : Documentation for the *RootDevice*. Optional.
122   -- **Modules** : A list of [Module](#ModuleClass) components that are local to the *RootDevice*. Optional.
123   -- **[DeviceInfo](#DeviceInfo)** : Further meta-data about the *RootDevice*. Optional.
124   -- **Devices** : A list of [Device](#Device) components. Optional.
  116 +- **[Doc](#Documentation)** : Documentation for the *Device*. Optional.
  117 +- **[Properties](#Property)** : Further meta-data (or properties) about the *Device*. Optional.
  118 +- **[Modules](#ModuleClass)** : A list of *Module* components that are local to the *Device*. Optional.
  119 +- **[SubDevices](#SubDevice)** : A list of *SubDevice* components. Optional.
125 120  
126 121 #### Example
127 122  
128   - <RootDevice id="aRootDevice">
  123 + <Device id="aDevice">
129 124 <Doc>Some documentation</Doc>
  125 + <Properties>
  126 + <!-- The list of Properties for the Device goes here-->
  127 + </Properties>
130 128 <Modules>
131   - <!-- List of Modules local to the RootDevice goes here-->
  129 + <!-- List of Modules local to the Device goes here-->
132 130 </Modules>
133   - <DeviceInfo>
134   - <!-- The DeviceInfos for the RootDevice goes here-->
135   - </DeviceInfo>
136   - <Devices>
137   - <!-- List of Sub-Devices of the RootDevice goes here-->
138   - </Devices>
139   - </RootDevice>
  131 + <SubDevices>
  132 + <!-- List of Sub-Devices of the Device goes here-->
  133 + </SubDevices>
  134 + </Device>
140 135  
141 136 ---
142 137  
143   -### Device
144   -*Devices* are optional components of a [RootDevice](#RootDevice). They represent physical sub-devices inside another device (the RootDevice).
  138 +<a name="SubDevice"/></a>
  139 +### SubDevice
  140 +*SubDevices* are optional components of a [Device](#Device). They represent physical sub-devices and services inside another device (the *Device*).
145 141  
146   -*Devices* may define their own [ModuleClasses](#ModuleClass) or extend ModulesClasses of its or another [Domain](#Domain).
  142 +*SubDevices* may define their own [ModuleClasses](#ModuleClass) or extend ModulesClasses of its or another [Domain](#Domain).
147 143  
148   -![](images/Device.png)
  144 +![](images/SubDevice.png)
149 145  
150 146 #### Attributes
151   -- **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.
  147 +- **id** : The identifier for that *SubDevice*. The identifier must be unique at least in the scope of the domain, but the final scope is also influenced by implementing technologies. Required.
152 148  
153 149 #### Elements
154   -- **[Doc](#Documentation)** : Documentation for the *Device*. Optional.
155   -- **Modules** : A list of [Module](#ModuleClass) components that are local to the *Device*. Optional.
156   -- **[DeviceInfo](#DeviceInfo)** : Further meta-data about the *Device*. Optional.
  150 +- **[Doc](#Documentation)** : Documentation for the *SubDevice*. Optional.
  151 +- **[Properties](#Property)** : Further meta-data (or properties) about the *SubDevice*. Optional.
  152 +- **[Modules](#ModuleClass)** : A list of *Module* components that are local to the *SubDevice*. Optional.
157 153  
158 154 #### Example
159 155  
160   - <Device id="aDevice">
  156 + <SubDevice id="aSubDevice">
161 157 <Doc>Some documentation</Doc>
  158 + <Properties>
  159 + <!-- The list of Properties for the Device goes here-->
  160 + </Properties>
162 161 <Modules>
163 162 <!-- List of Modules local to the Device goes here-->
164 163 </Modules>
165   - <DeviceInfo>
166   - <!-- The DeviceInfo for the Device goes here-->
167   - </DeviceInfo>
168   - </RootDevice>
  164 + </SubDevice>
169 165  
170 166 ---
171 167  
172   -<a name="DeviceInfo"/></a>
173   -### DeviceInfo
174   -The *DeviceInfo* is an element of [RootDevice](#RootDevice) or [Device](#Device) where a device vendor can provide metadata for a device that may be presented to an end-user.
  168 +<a name="Property"/></a>
  169 +### Property
175 170  
176   -![](images/DeviceInfo.png)
  171 +![](images/Property.png)
  172 +
  173 +*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 +
  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).
  176 +
  177 +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.
177 178  
178 179 #### Attributes
179   -None.
  180 +- **name**: Name or identifier of a *Property*.
  181 +- **optional**: Boolean that indicates whether a *Property* is optional or mandatory. Optional, the default is *false*.
  182 +- **value**: Text representation of value of a *Property*. Optional.
180 183  
181 184 #### Elements
182   -- **Name** : Vendor-specific name of a device. Required.
183   -- **Vendor** : Name of the vendor for the device. Required.
184   -- **FirmwareVersion** : Current version number of the firmware or other version information. Optional.
185   -- **VendorURL** : A URL that points to further information for that device. This might be the product page on the web or an URL to the device manual. Optional.
186   -- **SerialNumber** : The serial number or serial string. Optional.
187   -- **[Doc](#Documentation)** : Documentation for the *DeviceInfo*. Optional.
188   -
  185 +- **[Doc](#Documentation)** : Documentation for the *Property*. Optional.
  186 +- **DataType** : The data type of the property. This must be a [SimpleType](#SimpleType).
189 187  
190 188 #### Example
191 189  
192   - <DeviceInfo>
193   - <Name>SomeDeviceName</Name>
194   - <Vendor>ACME</Vendor>
195   - <FirmwareVersion>1.0</FirmwareVersion>
196   - <VendorURL>http://www.example.com/</VendorURL>
197   - <SerialNumber>1234.5</SerialNumber>
198   - </DeviceInfo>
  190 + <Property name="ManufacturedDate" value="2015.10.30 10:06">
  191 + <SimpleType type="datetime" />
  192 + </Property>
199 193  
200 194 ---
201 195  
202 196 <a name="ModuleClass"/></a>
203 197 ### Module, ModuleClass
204   -The *ModuleClass* represents the concept of a reusable module that defines the [Actions](#Action), [Data](#Data) and [Events](#Event) for a single functionality of a device. A connected device may contain or refer to single or multiple *ModuleClasses* to specify its inherent services it exposes for use by applications.
205 198  
206   -*Modules* represent instantiations of *ModuleClasses*.
  199 +![](images/ModuleClass.png)
207 200  
208   -*ModuleClasses* can be defined by a domain (on the level of the [Domain](#Domain) component) or in [RootDevices](#RootDevice)/[Devices](#Device): The first are global to a [Domain](#Domain) and can be used (refered to) by all [RootDevices](#RootDevice) resp. [Devices](#Device) of a [Domain](#Domain); the later are local to the [RootDevices](#RootDevice)/[Devices](#Device) where it is defined in. *ModuleClasses* defined on the [Domain](#Domain) level can be imported, extended and used by other domains.
  201 +**Module**
209 202  
210   -New *ModuleClasses* can be defined by extending existing *ModuleClasses* from the same or other domains to add new or overriding defined [Actions](#Action), [Data](#Data) and [Events](#Event).
  203 +*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*.
211 204  
212   -![](images/ModuleClass.png)
  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.
  206 +
  207 +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 +
  209 +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.
  210 +
  211 +**ModuleClass**
  212 +
  213 +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).
  214 +
  215 +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.
213 216  
214 217 #### Attributes
215   -- **Name** : Name of the *ModuleClass*. The name must be unique in the scope of the [Domain](#Domain). Required.
  218 +- **name** : Name of the *Module* or *ModuleClass*. The name must be unique in the scope of the [Domain](#Domain). Required.
  219 +- **optional**: Boolean that indicates whether a *Module* or *ModuleClass* is optional or mandatory. Optional, the default is *false*.
216 220  
217 221 #### Elements
218   -- **extends** : Reference to a another *ModuleClass* that is extended with this *ModuleClass*. Optional.
  222 +
  223 +- **[Doc](#Documentation)** : Documentation for the *Module* or *ModuleClass*. Optional.
  224 +- **extends** : Reference to a another *ModuleClass* or *Module* which is extended with this *ModuleClass*. Optional.
219 225 The element has the following attributes:
220   - - **domain** : Identifier / Reference of the [Domain](#Domain) of the extended *ModuleClass*. Required when *extends* is specified.
221   - - **class** : Name of the *ModuleClass* in the [Domain](#Domain) thet is extended.
222   -- **[Doc](#Documentation)** : Documentation for the *ModuleClass*. Optional.
223   -- **Actions** : A list of [Action](#Action) components, each defining a single action. Optional.
224   -- **Data** : A list of [Data](#Data) components. Optional.
225   -- **Events** : A list of [Event](#Event) components. Optional.
  226 + - **domain** : Identifier / Reference of the [Domain](#Domain) of the extended *ModuleClass*. Required for this element.
  227 + - **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.
  229 +- **[Actions](#Action)** : A list of *Action* components, each defining a single action. Optional.
  230 +- **[Data](#DataPoint)** : A list of *DataPoint* components. Optional.
  231 +- **[Events](#Event)** : A list of *Event* components. Optional.
226 232  
227 233 #### Example
228 234  
... ... @@ -243,23 +249,21 @@ The element has the following attributes:
243 249  
244 250 <a name="Action"/></a>
245 251 ### Action
246   -An *Action* defines a single procedure call for a [ModuleClass](#ModuleClass). It is basically used for calling a function on a physical device in order to set or request data, or to invoke an action at a [Device](#Device). #
247   -
248   -It is also possible that an *Action* results in calling multiple functions on the device. Examples for this are the assembly of single function calls into one *Action* in order to provide sanity checks on the arguments, or for managing and fullfil transactional function calls on the device.
249 252  
250 253 ![](images/Action.png)
251 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 +
252 259 #### Attributes
253 260 - **name** : The name of the *Action*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
254   -- **type** : The return type of the *Action*. It must comply to one of the defined [DataTypes](#DataType). Optional. If no *type* is specified the *Action* does not return a value.
  261 +- **optional**: Boolean that indicates whether an *Action* is optional or mandatory. Optional, the default is *false*.
255 262  
256 263 #### Elements
257 264 - **[Doc](#Documentation)** : Documentation for the *Action*. Optional.
258   -- **Arg** : Zero or more occurances of argument definitions for an *Action*. Optional.
259   -The *Arg* has the following attributes and elements:
260   - - **name** : The name of the *Arg*. Attribute. Required.
261   - - **type** : The type of the *Arg*. It must comply to one of the defined [DataTypes](#DataType) Attribute. Required.
262   - - **Doc** : Documentation for the *Arg* element. 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.
263 267  
264 268 #### Example
265 269 The following are two examples for actions implementing a getter and a setter for boolean values.
... ... @@ -270,21 +274,43 @@ The following are two examples for actions implementing a getter and a setter fo
270 274  
271 275 <Action name="setTarget">
272 276 <Doc>Set the associated state to the specified value. Example of a setter.</Doc>
273   - <Arg name="value" type="boolean">
274   - <Doc>The desired value of the associated state.</Doc>
275   - </Arg>
  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>
276 285 </Action>
277 286  
278 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 +---
279 305  
280 306 <a name="Data"/></a>
281   -### Data
282   -The *Data* component represents a list of *DataPoints* of a [ModuleClass](#ModuleClass).
  307 +### DataPoint
283 308  
284   -![](images/Data.png)
  309 +![](images/DataPoint.png)
285 310  
  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.
286 312  
287   -*DataPoints* serve to provide information to application developers about the internal structure, types and attributes of a device's data model. There are no implicite setter or getter actions to manipulate the data points directly. To do this, [Actions](#Action) must be defined and used explicitly.
  313 +However, *DataPoints* are not the only way of controlling devices, so further "Actions" and "Events are described below.
288 314  
289 315 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.
290 316  
... ... @@ -298,32 +324,120 @@ In EBNF:
298 324  
299 325  
300 326 #### Attributes
301   -None.
  327 +- **name** : The name (and possible path in a hierarchical data model) of the *DataPoint*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
  328 +- **optional**: Boolean that indicates whether a *DataPoint* is optional or mandatory. Optional, the default is *false*.
  329 +- **writable** : Boolean value that indicates whether this *DataPoint* is writable by an application. Optional. Default: true.
  330 +- **readable** : Boolean value that indicates whether this *DataPoint* is readable by an application. Optional. Default: true.
  331 +- **eventable** : Boolean value that indicates whether an internal or external change of this *DataPoint* raises an event. Optional. Default: false.
302 332  
303 333 #### Elements
304   -- **DataPoint** : Zero or more occurances of *DataPoints. Optional.
305   -A *DataPoint* has the following attributes and elements:
306   - - **name** : The name (and possible path in a hierarchical data model) of the *DataPoint*. Attribute. The name must be unique in the scope of the [ModuleClass](#ModuleClass).Required.
307   - - **type** : The type of the *DataPoint*. It must comply to one of the defined *DataTypes*. Attribute. Required.
308   - - **writable** : Boolean value that indicates whether this *DataPoint* is writable by an application. Attribute. Optional. Default: false.
309   - - **readable** : Boolean value that indicates whether this *DataPoint* is readable by an application. Attribute. Optional. Default: false.
310   - - **eventable** : Boolean value that indicates whether an internal or external change of this *DataPoint* raises an event. Attribute. Optional. Default: false.
311   - - **[Doc](#Documentation)** : Documentation for the *DataPoint* element. Optional.
312   -
  334 +- **[Doc](#Documentation)** : Documentation for the *DataPoint*. Optional.
  335 +- **[DataType](#DataType)** : The type of the *DataPoint*. It must comply to the *DataType* definition. Required.
313 336  
314 337 #### Example
  338 +
315 339 <Data>
316   - <DataPoint name="attributeName" type="string" writable="false">
  340 + <DataPoint name="attributeName" writable="false">
317 341 <Doc>Some documentation for the DataPoint</Doc>
  342 + <DataType>
  343 + <SimpleType type="string" />
  344 + </DataType
318 345 </DataPoint>
319 346 </Data>
320 347  
321 348 ---
322 349  
  350 +<a name="Event"/></a>
  351 +### Event
  352 +
  353 +![](images/Event.png)
  354 +
  355 +*Event* elements are needed for automation protocols which "push" information, instead of relying on polling by the software application. A typical example would be a "SensorAlert" where a window sensor immediately transmits a change of its state from "closed" to "open", which could be used in a burglar alarm application, needs to be ready to accept such information immediately, and not wait for a regular polling of the device.
  356 +
  357 +#### Attributes
  358 +- **name** : The name of the *Event*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
  359 +- **optional**: Boolean that indicates whether an *Event* is optional or mandatory. Optional, the default is *false*.
  360 +
  361 +#### Elements
  362 +- **[Doc](#Documentation)** : Documentation for the *Event* Element. Optional.
  363 +- **[Data](#DataPoint)** : A list of *DataPoint* components for an event's payload. Optional.
  364 +
  365 +#### Example
  366 +
  367 + <Event name="stateChanged">
  368 + <Doc>Some documentation for the Event</Doc>
  369 + <Data>
  370 + <DataPoint name="state">
  371 + <DataType>
  372 + <SimpleType type="boolean" />
  373 + </DataType>
  374 + </DataPoint>
  375 + </Data>
  376 + </Event>
  377 +
  378 +---
  379 +
  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:
  383 +
  384 +![](images/SDT_UML_DataType.png)
  385 +
  386 +The various elements are described in the sections below.
  387 +
  388 +---
323 389  
324 390 <a name="DataType"/></a>
325 391 ### DataType
326   -The following *DataTypes* can be used in the SDT's [Action](#Action), *Arg* and [DataPoint](#Data) elements and attributes. If not stated otherwise datatypes should comply to the equivalent datatypes defined in [XML Schema Part 2: Datatypes Second Edition](http://www.w3.org/TR/xmlschema-2/#boolean):
  392 +
  393 +![](images/DataType.png)
  394 +![](images/TypeChoice.png)
  395 +
  396 +The *DataType* element is a "container" for the various aspects of a type.
  397 +
  398 +#### Attributes
  399 +- **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.
  401 +
  402 +#### Elements
  403 +- **[Doc](#Documentation)** : Documentation for the *DataType* Element. Optional.
  404 +- **TypeChoice** : This element is actual an element from the following list of data types:
  405 + - **[SimpleType](#SimpleType)**
  406 + - **[Struct](#StructType)**
  407 + - **[Array](#ArrayType)**
  408 +- **[Constraint](#Constraint)** : A list of *Constraint* elements. Optional.
  409 +
  410 +---
  411 +
  412 +<a name="Constraint"/></a>
  413 +### Constraint
  414 +
  415 +![](images/Constraint.png)
  416 +
  417 +The *Constraint* element is an optional element allowing the manufacturer to provide constraints on the permitted values of measured data or input parameters. It can significantly improve the reliability of software and validation of transmitted data.
  418 +
  419 +#### Attributes
  420 +- **name** : The name or ID that identifies the *Constraint*. Required.
  421 +- **type** : The basic data type of the constraint. Note that this may be different from the type of the [DataType](#DataType) that this *Constraint* is assigned to. For example, a *Constraint* that specifies a maximum length of a string is of type *integer*. Optional.
  422 +- **value** : A pre-assigned value for the constraint, for example the maximum number of characters in a string. Optional.
  423 +
  424 +#### Elements
  425 +- **[Doc](#Documentation)** : Documentation for the *Cosntraint* Element. Optional.
  426 +
  427 +---
  428 +
  429 +<a name="SimpleType"/></a>
  430 +### SimpleType
  431 +
  432 +![](images/SimpleType.png)
  433 +
  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:
  435 +
  436 +1. the (technically redundant) options of *date* and *time* - to avoid problems which can arise interpreting a *datetime* value;
  437 +2. *url* because it is expected to become extremely common to provide links to other data sources;
  438 +3. the "blob" type to represent binary data of arbitrary structure.
  439 +
  440 +If not stated otherwise datatypes should comply to the equivalent datatypes defined in [XML Schema Part 2: Datatypes Second Edition](http://www.w3.org/TR/xmlschema-2/#boolean):
327 441  
328 442 - **boolean** : A boolean value as defined in [http://www.w3.org/TR/xmlschema-2/#boolean](http://www.w3.org/TR/xmlschema-2/#boolean) .
329 443 - **byte** : An integer datatype with the range of [0 - 255] as defined in [http://www.w3.org/TR/xmlschema-2/#unsignedByte](http://www.w3.org/TR/xmlschema-2/#unsignedByte) .
... ... @@ -339,28 +453,28 @@ The following *DataTypes* can be used in the SDT&#39;s [Action](#Action), *Arg* and
339 453  
340 454 ---
341 455  
342   -<a name="Event"/></a>
343   -### Event
344   -An *Event* is a component that defines properties for events that are raised as reactions to changes in [DataPoints](#Data) of a [Device](#Device)'s data model. These state changes can happen either through a device-internal change, e.g. a low battery level, or by external means, e.g. a user operates a switch or the temperature in a room rises beyond a certain threshold.
  456 +<a name="StructType"/></a>
  457 +### StructType
345 458  
346   -![](images/Event.png)
  459 +![](images/Struct.png)
347 460  
348   -#### Attributes
349   -- **name** : The name of the *Event*. The name must be unique in the scope of the [ModuleClass](#ModuleClass). Required.
  461 +The *StructType* element can be used to represent an ordered list of diverse DataTypes, which are represented by the *name* attribute of each [DataType](#DataType), and can be used recursively.
350 462  
351 463 #### Elements
352   -- **Data** : A list of [Data](#Data) components for an event's payload. Optional.
353   -- **[Doc](#Documentation)** : Documentation for the *Event* Element. Optional.
  464 +- **[DataType](#DataType)** : A list of DataTypes elements representing the elements of a structure.
354 465  
355 466  
356   -#### Example
  467 +---
357 468  
358   - <Event name="stateChanged">
359   - <Data>
360   - <DataPoint name="state" type="boolean">
361   - </DataPoint>
362   - </Data>
363   - </Event>
  469 +<a name="ArrayType"/></a>
  470 +### ArrayType
  471 +
  472 +![](images/Array.png)
  473 +
  474 +The *ArrayType* element is provided for defining lists of data; the definition is recursive so that multi-dimensional arrays can be described. Note that a Constraint can be used to provide limits on Array size.
  475 +
  476 +#### Elements
  477 +- **[DataType](#DataType)** : A single DataType element that specifies the data type for the elements of the array.
364 478  
365 479 ---
366 480  
... ...
... ... @@ -5,8 +5,8 @@
5 5 <element>
6 6 <id>UMLNote</id>
7 7 <coordinates>
8   - <x>70</x>
9   - <y>420</y>
  8 + <x>21</x>
  9 + <y>427</y>
10 10 <w>217</w>
11 11 <h>182</h>
12 12 </coordinates>
... ... @@ -35,8 +35,8 @@ Cardinalities:
35 35 <element>
36 36 <id>Relation</id>
37 37 <coordinates>
38   - <x>154</x>
39   - <y>490</y>
  38 + <x>105</x>
  39 + <y>497</y>
40 40 <w>77</w>
41 41 <h>28</h>
42 42 </coordinates>
... ... @@ -49,8 +49,8 @@ m1=0..*
49 49 <element>
50 50 <id>Relation</id>
51 51 <coordinates>
52   - <x>154</x>
53   - <y>518</y>
  52 + <x>105</x>
  53 + <y>525</y>
54 54 <w>77</w>
55 55 <h>21</h>
56 56 </coordinates>
... ... @@ -61,8 +61,8 @@ fontsize=10&lt;/panel_attributes&gt;
61 61 <element>
62 62 <id>UMLClass</id>
63 63 <coordinates>
64   - <x>700</x>
65   - <y>763</y>
  64 + <x>651</x>
  65 + <y>770</y>
66 66 <w>105</w>
67 67 <h>154</h>
68 68 </coordinates>
... ... @@ -85,8 +85,8 @@ uri&lt;/panel_attributes&gt;
85 85 <element>
86 86 <id>Relation</id>
87 87 <coordinates>
88   - <x>406</x>
89   - <y>826</y>
  88 + <x>357</x>
  89 + <y>833</y>
90 90 <w>98</w>
91 91 <h>56</h>
92 92 </coordinates>
... ... @@ -98,8 +98,8 @@ m1= 0,1
98 98 <element>
99 99 <id>Relation</id>
100 100 <coordinates>
101   - <x>406</x>
102   - <y>770</y>
  101 + <x>357</x>
  102 + <y>777</y>
103 103 <w>98</w>
104 104 <h>56</h>
105 105 </coordinates>
... ... @@ -111,8 +111,8 @@ m1= 0,1
111 111 <element>
112 112 <id>UMLClass</id>
113 113 <coordinates>
114   - <x>70</x>
115   - <y>770</y>
  114 + <x>21</x>
  115 + <y>777</y>
116 116 <w>133</w>
117 117 <h>84</h>
118 118 </coordinates>
... ... @@ -129,8 +129,8 @@ fg=blue&lt;/panel_attributes&gt;
129 129 <element>
130 130 <id>Relation</id>
131 131 <coordinates>
132   - <x>175</x>
133   - <y>728</y>
  132 + <x>126</x>
  133 + <y>735</y>
134 134 <w>490</w>
135 135 <h>91</h>
136 136 </coordinates>
... ... @@ -142,8 +142,8 @@ m2=1..*
142 142 <element>
143 143 <id>Relation</id>
144 144 <coordinates>
145   - <x>175</x>
146   - <y>728</y>
  145 + <x>126</x>
  146 + <y>735</y>
147 147 <w>490</w>
148 148 <h>133</h>
149 149 </coordinates>
... ... @@ -155,8 +155,8 @@ m2=1
155 155 <element>
156 156 <id>UMLClass</id>
157 157 <coordinates>
158   - <x>490</x>
159   - <y>854</y>
  158 + <x>441</x>
  159 + <y>861</y>
160 160 <w>133</w>
161 161 <h>35</h>
162 162 </coordinates>
... ... @@ -169,8 +169,8 @@ fg=blue&lt;/panel_attributes&gt;
169 169 <element>
170 170 <id>Relation</id>
171 171 <coordinates>
172   - <x>616</x>
173   - <y>868</y>
  172 + <x>567</x>
  173 + <y>875</y>
174 174 <w>98</w>
175 175 <h>35</h>
176 176 </coordinates>
... ... @@ -182,8 +182,8 @@ m1= 1
182 182 <element>
183 183 <id>UMLClass</id>
184 184 <coordinates>
185   - <x>490</x>
186   - <y>910</y>
  185 + <x>441</x>
  186 + <y>917</y>
187 187 <w>133</w>
188 188 <h>70</h>
189 189 </coordinates>
... ... @@ -199,8 +199,8 @@ fg=blue&lt;/panel_attributes&gt;
199 199 <element>
200 200 <id>Relation</id>
201 201 <coordinates>
202   - <x>196</x>
203   - <y>840</y>
  202 + <x>147</x>
  203 + <y>847</y>
204 204 <w>308</w>
205 205 <h>98</h>
206 206 </coordinates>
... ... @@ -212,8 +212,8 @@ m1=0..*
212 212 <element>
213 213 <id>Relation</id>
214 214 <coordinates>
215   - <x>616</x>
216   - <y>910</y>
  215 + <x>567</x>
  216 + <y>917</y>
217 217 <w>147</w>
218 218 <h>56</h>
219 219 </coordinates>
... ... @@ -225,8 +225,8 @@ m1=1
225 225 <element>
226 226 <id>UMLClass</id>
227 227 <coordinates>
228   - <x>490</x>
229   - <y>770</y>
  228 + <x>441</x>
  229 + <y>777</y>
230 230 <w>133</w>
231 231 <h>35</h>
232 232 </coordinates>
... ... @@ -239,8 +239,8 @@ fg=blue&lt;/panel_attributes&gt;
239 239 <element>
240 240 <id>UMLClass</id>
241 241 <coordinates>
242   - <x>490</x>
243   - <y>812</y>
  242 + <x>441</x>
  243 + <y>819</y>
244 244 <w>133</w>
245 245 <h>35</h>
246 246 </coordinates>
... ... @@ -253,8 +253,8 @@ fg=blue&lt;/panel_attributes&gt;
253 253 <element>
254 254 <id>Relation</id>
255 255 <coordinates>
256   - <x>406</x>
257   - <y>805</y>
  256 + <x>357</x>
  257 + <y>812</y>
258 258 <w>98</w>
259 259 <h>35</h>
260 260 </coordinates>
... ... @@ -267,8 +267,8 @@ m1= 0,1
267 267 <element>
268 268 <id>UMLClass</id>
269 269 <coordinates>
270   - <x>70</x>
271   - <y>665</y>
  270 + <x>21</x>
  271 + <y>672</y>
272 272 <w>735</w>
273 273 <h>28</h>
274 274 </coordinates>
... ... @@ -282,8 +282,8 @@ lw=0.1&lt;/panel_attributes&gt;
282 282 <element>
283 283 <id>UMLClass</id>
284 284 <coordinates>
285   - <x>70</x>
286   - <y>0</y>
  285 + <x>21</x>
  286 + <y>7</y>
287 287 <w>840</w>
288 288 <h>28</h>
289 289 </coordinates>
... ... @@ -297,8 +297,8 @@ lw=0.1&lt;/panel_attributes&gt;
297 297 <element>
298 298 <id>UMLClass</id>
299 299 <coordinates>
300   - <x>308</x>
301   - <y>119</y>
  300 + <x>259</x>
  301 + <y>126</y>
302 302 <w>154</w>
303 303 <h>133</h>
304 304 </coordinates>
... ... @@ -310,7 +310,7 @@ lw=0.1&lt;/panel_attributes&gt;
310 310 /- extends/
311 311 / @domain : IDRF/
312 312 / @class : text /
313   -/* Property : Properties/
  313 +/* Properties : Property/
314 314 /* Actions : Action/
315 315 /* Data : DataPoint/
316 316 /* Events : Event/
... ... @@ -321,8 +321,8 @@ fg=blue
321 321 <element>
322 322 <id>UMLClass</id>
323 323 <coordinates>
324   - <x>546</x>
325   - <y>119</y>
  324 + <x>497</x>
  325 + <y>126</y>
326 326 <w>154</w>
327 327 <h>77</h>
328 328 </coordinates>
... ... @@ -339,8 +339,8 @@ fg=blue&lt;/panel_attributes&gt;
339 339 <element>
340 340 <id>UMLClass</id>
341 341 <coordinates>
342   - <x>791</x>
343   - <y>182</y>
  342 + <x>742</x>
  343 + <y>189</y>
344 344 <w>119</w>
345 345 <h>56</h>
346 346 </coordinates>
... ... @@ -355,8 +355,8 @@ fg=blue&lt;/panel_attributes&gt;
355 355 <element>
356 356 <id>Relation</id>
357 357 <coordinates>
358   - <x>693</x>
359   - <y>182</y>
  358 + <x>644</x>
  359 + <y>189</y>
360 360 <w>112</w>
361 361 <h>28</h>
362 362 </coordinates>
... ... @@ -367,8 +367,8 @@ m1= 0..*&lt;/panel_attributes&gt;
367 367 <element>
368 368 <id>UMLClass</id>
369 369 <coordinates>
370   - <x>70</x>
371   - <y>119</y>
  370 + <x>21</x>
  371 + <y>126</y>
372 372 <w>154</w>
373 373 <h>77</h>
374 374 </coordinates>
... ... @@ -385,8 +385,8 @@ fg=blue&lt;/panel_attributes&gt;
385 385 <element>
386 386 <id>Relation</id>
387 387 <coordinates>
388   - <x>217</x>
389   - <y>119</y>
  388 + <x>168</x>
  389 + <y>126</y>
390 390 <w>105</w>
391 391 <h>63</h>
392 392 </coordinates>
... ... @@ -397,8 +397,8 @@ m1= 0..*&lt;/panel_attributes&gt;
397 397 <element>
398 398 <id>UMLClass</id>
399 399 <coordinates>
400   - <x>70</x>
401   - <y>301</y>
  400 + <x>21</x>
  401 + <y>308</y>
402 402 <w>154</w>
403 403 <h>70</h>
404 404 </coordinates>
... ... @@ -406,7 +406,7 @@ m1= 0..*&lt;/panel_attributes&gt;
406 406 --
407 407 *@ id : Name*
408 408 /- Doc : Doc/
409   -/* Property : Properties/
  409 +/* Properties : Property/
410 410 /* Modules : Module/
411 411 fg=blue</panel_attributes>
412 412 <additional_attributes/>
... ... @@ -414,8 +414,8 @@ fg=blue&lt;/panel_attributes&gt;
414 414 <element>
415 415 <id>Relation</id>
416 416 <coordinates>
417   - <x>217</x>
418   - <y>175</y>
  417 + <x>168</x>
  418 + <y>182</y>
419 419 <w>49</w>
420 420 <h>63</h>
421 421 </coordinates>
... ... @@ -427,8 +427,8 @@ m1=0..*
427 427 <element>
428 428 <id>Relation</id>
429 429 <coordinates>
430   - <x>217</x>
431   - <y>308</y>
  430 + <x>168</x>
  431 + <y>315</y>
432 432 <w>105</w>
433 433 <h>49</h>
434 434 </coordinates>
... ... @@ -439,8 +439,8 @@ m1= 0..*&lt;/panel_attributes&gt;
439 439 <element>
440 440 <id>UMLClass</id>
441 441 <coordinates>
442   - <x>791</x>
443   - <y>350</y>
  442 + <x>742</x>
  443 + <y>357</y>
444 444 <w>119</w>
445 445 <h>35</h>
446 446 </coordinates>
... ... @@ -452,8 +452,8 @@ fg=blue&lt;/panel_attributes&gt;
452 452 <element>
453 453 <id>Relation</id>
454 454 <coordinates>
455   - <x>455</x>
456   - <y>119</y>
  455 + <x>406</x>
  456 + <y>126</y>
457 457 <w>105</w>
458 458 <h>42</h>
459 459 </coordinates>
... ... @@ -465,8 +465,8 @@ m1= 0..*
465 465 <element>
466 466 <id>Relation</id>
467 467 <coordinates>
468   - <x>735</x>
469   - <y>343</y>
  468 + <x>686</x>
  469 + <y>350</y>
470 470 <w>70</w>
471 471 <h>35</h>
472 472 </coordinates>
... ... @@ -478,8 +478,8 @@ m1=0,1
478 478 <element>
479 479 <id>Relation</id>
480 480 <coordinates>
481   - <x>455</x>
482   - <y>154</y>
  481 + <x>406</x>
  482 + <y>161</y>
483 483 <w>105</w>
484 484 <h>84</h>
485 485 </coordinates>
... ... @@ -491,8 +491,8 @@ m1= 0..*
491 491 <element>
492 492 <id>UMLClass</id>
493 493 <coordinates>
494   - <x>546</x>
495   - <y>210</y>
  494 + <x>497</x>
  495 + <y>217</y>
496 496 <w>154</w>
497 497 <h>98</h>
498 498 </coordinates>
... ... @@ -513,8 +513,8 @@ fg=blue
513 513 <element>
514 514 <id>UMLClass</id>
515 515 <coordinates>
516   - <x>546</x>
517   - <y>322</y>
  516 + <x>497</x>
  517 + <y>329</y>
518 518 <w>154</w>
519 519 <h>63</h>
520 520 </coordinates>
... ... @@ -531,8 +531,8 @@ fg=blue&lt;/panel_attributes&gt;
531 531 <element>
532 532 <id>Relation</id>
533 533 <coordinates>
534   - <x>455</x>
535   - <y>224</y>
  534 + <x>406</x>
  535 + <y>231</y>
536 536 <w>105</w>
537 537 <h>126</h>
538 538 </coordinates>
... ... @@ -544,8 +544,8 @@ m1= 0..*
544 544 <element>
545 545 <id>UMLClass</id>
546 546 <coordinates>
547   - <x>308</x>
548   - <y>273</y>
  547 + <x>259</x>
  548 + <y>280</y>
549 549 <w>154</w>
550 550 <h>21</h>
551 551 </coordinates>
... ... @@ -556,8 +556,8 @@ fg=blue&lt;/panel_attributes&gt;
556 556 <element>
557 557 <id>Relation</id>
558 558 <coordinates>
559   - <x>217</x>
560   - <y>273</y>
  559 + <x>168</x>
  560 + <y>280</y>
561 561 <w>105</w>
562 562 <h>98</h>
563 563 </coordinates>
... ... @@ -569,8 +569,8 @@ fg=blue&lt;/panel_attributes&gt;
569 569 <element>
570 570 <id>Relation</id>
571 571 <coordinates>
572   - <x>371</x>
573   - <y>245</y>
  572 + <x>322</x>
  573 + <y>252</y>
574 574 <w>21</w>
575 575 <h>42</h>
576 576 </coordinates>
... ... @@ -581,8 +581,8 @@ fg=blue&lt;/panel_attributes&gt;
581 581 <element>
582 582 <id>UMLClass</id>
583 583 <coordinates>
584   - <x>70</x>
585   - <y>210</y>
  584 + <x>21</x>
  585 + <y>217</y>
586 586 <w>154</w>
587 587 <h>77</h>
588 588 </coordinates>
... ... @@ -590,7 +590,7 @@ fg=blue&lt;/panel_attributes&gt;
590 590 --
591 591 *@ id : Name*
592 592 /- Doc : Doc/
593   -/* Property : Properties/
  593 +/* Properties : Property/
594 594 /* Modules : Module/
595 595 /* SubDevices : SubDevice/
596 596 fg=blue</panel_attributes>
... ... @@ -599,8 +599,8 @@ fg=blue&lt;/panel_attributes&gt;
599 599 <element>
600 600 <id>Relation</id>
601 601 <coordinates>
602   - <x>217</x>
603   - <y>273</y>
  602 + <x>168</x>
  603 + <y>280</y>
604 604 <w>49</w>
605 605 <h>56</h>
606 606 </coordinates>
... ... @@ -612,8 +612,8 @@ m1=0..*
612 612 <element>
613 613 <id>Relation</id>
614 614 <coordinates>
615   - <x>217</x>
616   - <y>245</y>
  615 + <x>168</x>
  616 + <y>252</y>
617 617 <w>105</w>
618 618 <h>56</h>
619 619 </coordinates>
... ... @@ -625,8 +625,8 @@ m1= 0..*
625 625 <element>
626 626 <id>Relation</id>
627 627 <coordinates>
628   - <x>217</x>
629   - <y>259</y>
  628 + <x>168</x>
  629 + <y>266</y>
630 630 <w>105</w>
631 631 <h>70</h>
632 632 </coordinates>
... ... @@ -636,8 +636,8 @@ m1= 0..*
636 636 <element>
637 637 <id>UMLClass</id>
638 638 <coordinates>
639   - <x>308</x>
640   - <y>308</y>
  639 + <x>259</x>
  640 + <y>315</y>
641 641 <w>154</w>
642 642 <h>77</h>
643 643 </coordinates>
... ... @@ -655,8 +655,8 @@ transparency=80&lt;/panel_attributes&gt;
655 655 <element>
656 656 <id>Relation</id>
657 657 <coordinates>
658   - <x>693</x>
659   - <y>210</y>
  658 + <x>644</x>
  659 + <y>217</y>
660 660 <w>56</w>
661 661 <h>147</h>
662 662 </coordinates>
... ... @@ -668,8 +668,8 @@ m1=0..*
668 668 <element>
669 669 <id>Relation</id>
670 670 <coordinates>
671   - <x>455</x>
672   - <y>238</y>
  671 + <x>406</x>
  672 + <y>245</y>
673 673 <w>49</w>
674 674 <h>98</h>
675 675 </coordinates>
... ... @@ -680,8 +680,8 @@ m1=0..*&lt;/panel_attributes&gt;
680 680 <element>
681 681 <id>UMLClass</id>
682 682 <coordinates>
683   - <x>280</x>
684   - <y>770</y>
  683 + <x>231</x>
  684 + <y>777</y>
685 685 <w>133</w>
686 686 <h>70</h>
687 687 </coordinates>
... ... @@ -698,8 +698,8 @@ Array : ArrayType
698 698 <element>
699 699 <id>Relation</id>
700 700 <coordinates>
701   - <x>196</x>
702   - <y>777</y>
  701 + <x>147</x>
  702 + <y>784</y>
703 703 <w>98</w>
704 704 <h>63</h>
705 705 </coordinates>
... ...

4.79 KB | W: | H:

4.81 KB | W: | H:

  • 2-up
  • Swipe
  • Onion skin

8.34 KB | W: | H:

8.34 KB | W: | H:

  • 2-up
  • Swipe
  • Onion skin