Skip to main content
Jump to: navigation, search

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:
This table compares / matches vorto meta model entities with entities of the sensIDL meta model:
+
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
+
! Comments or Questions
 
|-
 
|-
 
| FunctionBlock
 
| FunctionBlock
| SensorInterface
+
| SensorInterface / SensorDataDescription
| Container to handle the sensor description
+
| 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
| not yet cover
+
| (no match)
| in SensIDL addressed in a later version
+
| 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
| SensorDataDescription + DataSet
+
| DataSet
| Describes Data sent by the sensor
+
| One way data communication on the Vorto side.
 
|-
 
|-
 
| Operation
 
| Operation
| not yet covered
+
| (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
| Data (<--NonMeasurementData <--MeasurementData)
+
| DataSet
| Separation in Data and MetaInformation in Vorto not covered, SensIDL additionally includes a reference to units, which are not covered by VORTO on the meta-model level.
+
| Difference due to modelling as one conceptual unit instead of several explicity concepts.
 
|-
 
|-
| PropertyType
+
| 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
| Include Vorto Elements Type, Entity and Enum
+
| Includes Vorto Elements Type, Entity and Enum
|-
+
| PrimitivePropertyType
+
| Enum in Data
+
|
+
 
|-
 
|-
 
| Presence
 
| Presence
| not yet covered
+
| (no match)
| mandatory/optional is planned to be covered in a next version
+
| mandatory/optional transmission as part of packet specifications is planned.
 
|-
 
|-
 
| EnumLiteral
 
| EnumLiteral
Line 56: Line 82:
 
| Constraint
 
| Constraint
 
| DataRange
 
| DataRange
| SensIDL only allows to define upper and lower bound
+
| 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 yet covered
+
| (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.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.