Difference between revisions of "Detailed Comparision of Elements with SensIDL"
(Additional explanation on commonalities and differences. Added short intro that explains how both align.) |
|||
Line 1: | Line 1: | ||
− | + | Vorto describes '''what''' information is passed and SensIDL '''how''' the information is passed. | |
+ | |||
+ | Vorto uses generators to map the logical information to technology specifc interfaces and services, such as MQTT transports. Vorto relies that sender and receiver use the same generator to understand each other correctly. | ||
+ | |||
+ | SensIDL allows to specify how information is passed on a logical level, e.g. the byte representation of packets and their structure. SensIDL generators create platform-specific code to receive and transmit the information. A SensIDL description is sufficient to create a receiver (or sender) that matches exactly what even a customized sender (receiver) sends. | ||
+ | |||
+ | Vorto describes the logical information that can flow from and to a device. The Vorto concept was evaluated as follows: | ||
+ | {|class="wikitable" | ||
+ | ! Level | ||
+ | ! Model Element | ||
+ | ! Describes | ||
+ | ! Example | ||
+ | |- | ||
+ | | Logical | ||
+ | | FunctionBlock | ||
+ | | Configuration, Status, Events, Faults, Operations on this logical type. | ||
+ | | Accelerometer, TemperatureSensor, ... | ||
+ | |- | ||
+ | | Logical | ||
+ | | InformationModel | ||
+ | | The function blocks bundeled on one device. | ||
+ | | TI_SensorTag_CC2650 | ||
+ | |- | ||
+ | | Physical | ||
+ | | (not modelled) | ||
+ | | TI_SensorTag_CC2650 | ||
+ | |} | ||
+ | |||
+ | SensIDL describes how logical information is transmitted between devices. For packet-based communications, this shows what logical information is contained in packets and how the indivdual bytes are transmitted. It support reasoning reasoning on the resolution of transmitting information, e.g. that 1/10 °C are provided in a range between -5°C to 35°C. | ||
+ | |||
+ | The following table compares / matches Vorto meta model entities with entities of the SensIDL meta model: | ||
{|class="wikitable" | {|class="wikitable" | ||
! VORTO | ! VORTO | ||
! SensIDL | ! SensIDL | ||
− | ! | + | ! Comments or Questions |
|- | |- | ||
| FunctionBlock | | FunctionBlock | ||
− | | SensorInterface | + | | SensorInterface / SensorDataDescription |
− | | Container to handle | + | | Container to handle describing what (Vorto) and how (SensIDL) a sensor or part of a logical device can communicate. SensIDL complements the information in Vorto and could be used in Vorto Mapping specifications. |
|- | |- | ||
| Configuration | | Configuration | ||
− | | | + | | (no match) |
− | | | + | | Semantic meaning of data and probably even that this data is stored (permanently). SensIDL takes care about how information is transferred rather than its semantic meaning. It could get relevant when Configuration settings modify protocol and communication parameters, e.g. how (often) data is transferred. |
|- | |- | ||
| Status | | Status | ||
− | | | + | | (no match) |
− | | Semantical difference to Event | + | | Semantical difference to Event or Configuration remains unclear. |
|- | |- | ||
| Event | | Event | ||
− | | | + | | DataSet |
− | | | + | | One way data communication on the Vorto side. |
|- | |- | ||
| Operation | | Operation | ||
− | | not | + | | (two-way message exchange protocols with different request and response packets not covered yet) |
| in SensIDL addressed in a later version | | in SensIDL addressed in a later version | ||
|- | |- | ||
| Fault | | Fault | ||
| ? | | ? | ||
− | | semantical difference to Event? Just a special kind of Event? | + | | semantical difference to Event? Just a special kind of Event? Difference to Status? |
|- | |- | ||
− | | Property | + | | Property / PropertyType / Presence / Constraints |
− | | | + | | DataSet |
− | | | + | | Difference due to modelling as one conceptual unit instead of several explicity concepts. |
|- | |- | ||
− | | | + | | PrimitivePropertyType |
− | | | + | | Data (<--NonMeasurementData <--MeasurementData) |
− | | | + | | Explicit separation in Data and MetaInformation in Vorto not covered, SensIDL additionally includes a reference to units, which are only covered in a limited way by VORTO on the meta-model level (e.g. enums as in [http://vorto.eclipse.org/repo/#/details/examples.datatypes.measurement.units/TemperatureUnit/1.0.0]). |
|- | |- | ||
| ObjectPropertyType | | ObjectPropertyType | ||
| DataSet as subDataSet | | DataSet as subDataSet | ||
− | | | + | | Includes Vorto Elements Type, Entity and Enum |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
|- | |- | ||
| Presence | | Presence | ||
− | | | + | | (no match) |
− | | mandatory/optional is planned | + | | mandatory/optional transmission as part of packet specifications is planned. |
|- | |- | ||
| EnumLiteral | | EnumLiteral | ||
Line 56: | Line 82: | ||
| Constraint | | Constraint | ||
| DataRange | | DataRange | ||
− | | SensIDL | + | | SensIDL allows to define upper and lower bound for reasoning on what can be technically transmitted. |
|- | |- | ||
| Operation (+ Param, RefParam, PrimitiveParam, ReturnType, ReturnObjectType, ReturnPrimitiveType) | | Operation (+ Param, RefParam, PrimitiveParam, ReturnType, ReturnObjectType, ReturnPrimitiveType) | ||
− | | not | + | | (two way communication not covered yet) |
| is there a reason for not reusing the Property and related elements? | | is there a reason for not reusing the Property and related elements? | ||
− | |||
|- | |- | ||
| - | | - | ||
Line 68: | Line 93: | ||
| | | | ||
|- | |- | ||
− | | | + | | (no match) |
| EncodingSettings | | EncodingSettings | ||
| not covered in Vorto, since data transfer is not in the focus of VORTO | | not covered in Vorto, since data transfer is not in the focus of VORTO | ||
|} | |} | ||
+ | One general observation is that SensIDL allows navgation along the container hierarchy, whereas Vorto does not. |
Latest revision as of 11:06, 3 March 2016
Vorto describes what information is passed and SensIDL how the information is passed.
Vorto uses generators to map the logical information to technology specifc interfaces and services, such as MQTT transports. Vorto relies that sender and receiver use the same generator to understand each other correctly.
SensIDL allows to specify how information is passed on a logical level, e.g. the byte representation of packets and their structure. SensIDL generators create platform-specific code to receive and transmit the information. A SensIDL description is sufficient to create a receiver (or sender) that matches exactly what even a customized sender (receiver) sends.
Vorto describes the logical information that can flow from and to a device. The Vorto concept was evaluated as follows:
Level | Model Element | Describes | Example |
---|---|---|---|
Logical | FunctionBlock | Configuration, Status, Events, Faults, Operations on this logical type. | Accelerometer, TemperatureSensor, ... |
Logical | InformationModel | The function blocks bundeled on one device. | TI_SensorTag_CC2650 |
Physical | (not modelled) | TI_SensorTag_CC2650 |
SensIDL describes how logical information is transmitted between devices. For packet-based communications, this shows what logical information is contained in packets and how the indivdual bytes are transmitted. It support reasoning reasoning on the resolution of transmitting information, e.g. that 1/10 °C are provided in a range between -5°C to 35°C.
The following table compares / matches Vorto meta model entities with entities of the SensIDL meta model:
VORTO | SensIDL | Comments or Questions | |
---|---|---|---|
FunctionBlock | SensorInterface / SensorDataDescription | Container to handle describing what (Vorto) and how (SensIDL) a sensor or part of a logical device can communicate. SensIDL complements the information in Vorto and could be used in Vorto Mapping specifications. | |
Configuration | (no match) | Semantic meaning of data and probably even that this data is stored (permanently). SensIDL takes care about how information is transferred rather than its semantic meaning. It could get relevant when Configuration settings modify protocol and communication parameters, e.g. how (often) data is transferred. | |
Status | (no match) | Semantical difference to Event or Configuration remains unclear. | |
Event | DataSet | One way data communication on the Vorto side. | |
Operation | (two-way message exchange protocols with different request and response packets not covered yet) | in SensIDL addressed in a later version | |
Fault | ? | semantical difference to Event? Just a special kind of Event? Difference to Status? | |
Property / PropertyType / Presence / Constraints | DataSet | Difference due to modelling as one conceptual unit instead of several explicity concepts. | |
PrimitivePropertyType | Data (<--NonMeasurementData <--MeasurementData) | Explicit separation in Data and MetaInformation in Vorto not covered, SensIDL additionally includes a reference to units, which are only covered in a limited way by VORTO on the meta-model level (e.g. enums as in [1]). | |
ObjectPropertyType | DataSet as subDataSet | Includes Vorto Elements Type, Entity and Enum | |
Presence | (no match) | mandatory/optional transmission as part of packet specifications is planned. | |
EnumLiteral | not available | Fixed Datatype enums, required to prevent dependencies between SensIDL instance and generators. Generators should depend only on the SensIDL meta-model | |
Constraint | DataRange | SensIDL allows to define upper and lower bound for reasoning on what can be technically transmitted. | |
Operation (+ Param, RefParam, PrimitiveParam, ReturnType, ReturnObjectType, ReturnPrimitiveType) | (two way communication not covered yet) | is there a reason for not reusing the Property and related elements? | |
- | LinearDataConversion, LineraDataConversionWithInterval | automatic adjustments for data transfer e.g. mapping a byte 0..255 to the value range of 0..1 is not in the focus of VORTO | |
(no match) | EncodingSettings | not covered in Vorto, since data transfer is not in the focus of VORTO |
One general observation is that SensIDL allows navgation along the container hierarchy, whereas Vorto does not.