Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Vorto / Code Generators

This page provides information about existing Vorto code generators.

Code Generators on Virtual Developer

The Virtual Developer Platform lets you execute code generators on a server. We (Generative Software GmbH) provide an integration of Vorto with Virtual Developer that provides you with an easy way to use Vorto models for your own code generators. You can generate code for Vorto information models by going through the Vorto repository web UI or by using a Virtual Developer connector (Eclipse plug-in or command line). Generative Software's first available code generator to use Vorto models is "IoT Gateway for Kura". You can easily create your own code generator and make it available through the Vorto repository web UI. Any code generator that is developed by means of the Vorto SDK can run on Virtual Devleoper without changing a single line of code.

2017-02-17 Virtual Developer Vorto Integration.png

Generative Software GmbH is participant member of the Eclipse IoT Working Group and helps other software developing companies to come up with code generators for the creation of IoT solutions.

Java Code Generator

The Java Code Generator allows to transform an Information Model and all related Functionblocks, Entities, and Enums into corresponding Java classes. For example the Entity

namespace examples.datatypes.measurement
version 1.0.0
description "Data type for describing a temperature."
using examples.datatypes.measurement.units.TemperatureUnit ; 1.0.0

entity Temperature {
	mandatory value as float "The value representing the temperature."
       mandatory measurementUnit as TemperatureUnit "The measurement unit for the temperature."

is transformed into

package entities; 

* Data type for describing a temperature.
public class Temperature { 

	* The value representing the temperature.
	private float value;
	* The measurement unit for the temperature.
	private TemperatureUnit measurementUnit;
	* Getter for value.
	public float getValue() {
		return this.value;
	* Setter for value.
	public void setValue(float value) {
		this.value = value;
	* Getter for measurementUnit.
	public TemperatureUnit getMeasurementUnit() {
		return this.measurementUnit;
	* Setter for measurementUnit.
	public void setMeasurementUnit(TemperatureUnit measurementUnit) {
		this.measurementUnit = measurementUnit;

Markdown Code Generator

The Markdown Code Generator allows to easily create documentation for an Information Model. The "Temperature" Entity for example is transformed into:

## Entity *Temperature*
### Unique Identification
 ### Description
 Data type for describing a temperature. 
 ### Properties
 	<tr><td>value</td><td>float</td><td>The value representing the temperature.</td></tr>
 	<tr><td>measurementUnit</td><td>TemperatureUnit</td><td>The measurement unit for the temperature.</td></tr>

When using a Markdown editor this looks like:

20151111 Vorto Markdown Example.png

Web Device Code Generator

The Web Device Code Generator creates a simple web application providing a UI to the related Information Model. The application can for example be deployed in a Jetty. An example for a simple multi sensor looks like:

20151111 Vorto MultiSensor WebApp Screenshot.png

iOS Code Generator

The iOS Code Generator currently supports the generation of BlueTooth Low Energy specific Swift code in order to bind your device to BLE. Note that this generator requires additional mapping files. Please find more information here.

Planned Code Generator for Reactive Blocks

In a few words: We consider to build a Vorto code generator for Reactive Blocks. A developer can use it to generate a reactive building block for any device that is described by a Vorto model. The building blocks makes it simple to integrate the device with an application gateway. The generated building block communicates with the device.

Here, we are looking for suggestions for which kind of communication we should assume between the gateway and the device to generate the necessary code, as well as any other feedback to this idea. We added this section to the page by invitation from Alexander Edelmann from Bosch. (Many thanks!)

About Reactive Blocks: Reactive Blocks is an Eclipse plugin and high productivity tool for generating Java applications from UML-like models built with off-the-shelf, reusable building blocks. It's purpose is to replace 'thread plumbing' while still offering flexibility to insert manual source coding. Building blocks can refer to Java methods which are edited within the integrated JDT editor, so that the generated code for the overall application is complete. Depending on the building blocks, used, the applications run on standard Java, OSGi or Eclipse Kura.

About the integration with Vorto: An integration would not only allow Vorto users to generate source code representing Vorto device info models, but also actually generate reusable blocks that hold knowledge about the communication technology/protocol for the device. The generated blocks can in turn be used to build application models in RB from which Java source code is generated after a state space check. Overall this would be a next stage in equipping developers with tools to make application development quicker and simpler by generating APIs as well as application source code.

Development with Vorto + Reactive Blocks: We want to create a typical IoT system Vorto Code Generator for Reactive Blocks consisting of three tiers, sensor node (1), smart gateway (2), and cloud backend (3). The smart gateway runs application-specific logic to ensure that the application will work locally also when the connection to the backend is down, to reduce latency and response time for local decision, reduce workload for the backend and reduce bandwidth.

The capabilities of the sensor node are described as Vorto Information model (4).


One development scenario can work out as follows: A developer uses the information model and the Vorto code generator for Reactive Blocks (5) to generate some building blocks (6). These building blocks represent the sensor tags in Reactive Blocks, so that the developer can create a Java/OSGi/Kura application for the gateway that can communicate with the sensor node. The building blocks make the capabilities of the sensor node available so that they can be combined with other building blocks (7). As usual in Reactive Blocks, the complete application is then generated automatically as a Kura OSGi bundle, running on the gateway (8).

The same information models could be used by complementary code generators. One code generator could for instance write the code for the sensor node itself, i.e., the code to communicate with the gateway application (9). There can also be a code generate for the backend code running in the cloud, to receive data about this sensor node via the gateway (10). The Challenge with Mappings: To be most effective, the building blocks for communicating with the sensor nodes should be complete building blocks, including the Java code inside them. (I.e. not only code skeletons.) For that, of course, we need to know how the information model is mapped to how the sensor nodes communicates. This means, we need to know how we communicate with the sensor node. This is holds for the communication between the sensor node and the gateway (11) and between the gateway and the cloud backend (12).

For the different communication links, different protocols, security mechanisms and and serialization formats may be adequate. For instance, the link between the gateway and the sensor node may use DTLS + CoAP with a very compact representation of all data over BLE, or (like in the Kura example) some communication over BLE but without CoAP. The link between gateway and backend may use HTTPS + JSON or TLS + MQTT + JSON to transfer the data.

To build the code generator, we would like to know more about which mapping makes most sense. This may depend on the technologies available (i.e., Bluetooth or Thread) and which application protocol (CoAP, HTTP, MQTT,…) should be used in a specific domain.

So, if you have any ideas and would like to collaborate, contact me via

Back to the top