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

Difference between revisions of "Vorto / Meta Information Model / Discussion / SensIDL"

Line 10: Line 10:
 
|  
 
|  
 
| Documentation of essential device and sensor properties as well as its preparation in a central repository
 
| Documentation of essential device and sensor properties as well as its preparation in a central repository
| Data structures and communication with sensors.
+
| Data structures and communication with sensors with the focus to generate the implementation code (sensor-side and receiver side) providing a sensor data specific API and code for serializing and deserializing the data.  
 
|-
 
|-
 
| Domain
 
| Domain
Line 20: Line 20:
 
|  
 
|  
 
| Hierarchical structure of device entities, function blocks and information models.
 
| Hierarchical structure of device entities, function blocks and information models.
| Data structures transmitted between sensors and receivers.
+
| Data structures transmitted between sensors and receivers. In contrast to VORTO reuse of model artifacts and a central repository is not a required key feature, anyhow nice to have
 
|-
 
|-
 
| Binding of concrete sensors
 
| Binding of concrete sensors
 
|  
 
|  
 
| Indirect within the scope of generators and binding elements, e.g. "InformationModelMapping"
 
| Indirect within the scope of generators and binding elements, e.g. "InformationModelMapping"
| Direct outcome. Using generators for creating device and platform specific data structures for the communication.
+
| Direct outcome. Using generators for creating device and platform specific data structures and code for the communication.
 
|-
 
|-
 
|  
 
|  

Revision as of 04:28, 25 November 2015

This page provides an overview about the compatibility between Vorto and SensIDL, providing a conceptional comparison regarding to different aspects of both approaches. Furthermore, a more detailed outlook in SensIDL usage can be found at the official web site [1].

Category Property Vorto SensIDL
General focus Documentation of essential device and sensor properties as well as its preparation in a central repository Data structures and communication with sensors with the focus to generate the implementation code (sensor-side and receiver side) providing a sensor data specific API and code for serializing and deserializing the data.
Domain Entire IoT domain Energie-self-sufficient and -constrained sensors and sensor systems with focus on data transmission.
Models Hierarchical structure of device entities, function blocks and information models. Data structures transmitted between sensors and receivers. In contrast to VORTO reuse of model artifacts and a central repository is not a required key feature, anyhow nice to have
Binding of concrete sensors Indirect within the scope of generators and binding elements, e.g. "InformationModelMapping" Direct outcome. Using generators for creating device and platform specific data structures and code for the communication.
Generation target Platform, e.g. "IoT Gateway" Sensor and receiver
Data structures Implicit via "Information Model" and chosen generator. Explicit.
Physical units Via explicit entities of Enums. Complete support for SI-Units as well as further chosen Non-SI-Units and the possibiltiy to automatic conversion between various units.
Interaction protocol - Planned.
Transmissionscoverage as well as authentification and authorisation Not considered. Not considered.
Tools and technical base Eclipse-based Eclipse-based
Perspective Yes No
Editor Yes, model-based DSL-Editor via Xtext Yes, model-based DSL-Editor via Xtext.
Code generators To be filled by Vorto colleagues C/C++, Java, JavaScript

Back to the top