Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Detailed Comparision of Elements with SensIDL

Revision as of 11:06, 3 March 2016 by Groenda.fzi.de (Talk | contribs) (Additional explanation on commonalities and differences. Added short intro that explains how both align.)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.

Back to the top