Eclipse Vorto to the rescue

Eclipse Vorto: Interoperability for the Internet of Things

Eclipse Vorto
Internet of Things image via Shutterstock

Interoperability is one of the key topics in the Internet of Things – and at the heart of this is the way in which individual, connected components work together. Communication between these elements makes sense only if the underlying language can actually be understood by the devices involved. Yet from a technological perspective, this can be difficult to achieve due to the wide variety of existing communication protocols. As a result, this calls for some means of translating between the individual languages.

Eclipse Vorto is an open source project set up to address this issue. It provides the technical capability required to describe the devices to be interconnected and their messages and helps define relevant mappings for translations. The aim of this article is to provide an overview of the project and demonstrate its potential applications based on two detailed examples.

Vorto components

It is common knowledge that industry consortia and standardization organizations are working on various projects to define and standardize abstract descriptions for electronic devices. Some of this work is domain-specific, whereas some reaches across domain boundaries. Eclipse Vorto deliberately takes a technological approach that does not prescribe any one standard. Instead, it provides a handy toolkit designed to integrate smart devices into IoT platforms or applications, reduce the development work required, and facilitate interoperability. Vorto consists of the following three technical components:

  • Vorto IoT toolset
  • Vorto repository
  • Code generator infrastructure

The IoT toolset is a well-structured and easy-to-use Eclipse application that enables users to create device descriptions known as “information models” on the basis of Vorto DSL (domain- specific language). As well as standard features such as syntax highlighting, auto completion, validation, etc., the toolset also offers integration with the Vorto Repository, which allows users to browse, check in, and check out information models. Code generators can also be run from within the toolset.

Existing information models can be managed in the Vorto repository. In addition to a user-friendly online interface, the repository offers a REST API that allows all the functions to be technologically integrated into existing solutions. Another feature of the repository is the ability to register code generators, which are realized as microservices. Once the code generators have been registered, their capabilities are available through the repository. Essentially this means that information models are converted into different formats using the registered code generators and are then made available to the user as a download or via the REST interface.

The key to Vorto component usability is ensuring that users do not have new formats “forced” on them. That’s why Vorto offers mechanisms that allow users to incorporate code generators, as these can convert Vorto-format device descriptions into different formats. Available formats include programming languages such as Java and C++, as well as formats for documentation purposes such as Markdown representations. It is also possible, however, to transform the models into formats defined by the standardization organizations and industry consortia mentioned above. Ultimately this means that users can retain their previously chosen format for device abstraction while still benefiting from the features of the Vorto project.


Example: communication in an automotive environment

Bosch Corporate Research is currently conducting a research project that uses Eclipse Vorto to describe the vehicle-to-cloud interface. The key data and services required for communication at this vehicle-to-cloud interface can be represented using Vorto. This makes these services and data available in a machine-readable format, which in turn makes automatic processing much simpler. In addition, the use of a common description language breaks down the barriers that still exist between the (physical) vehicle world and the (virtual) Internet of Things.

For the purposes of its description, a vehicle is regarded as a system that is represented in an information model. The various services are specified as function blocks. Each service generally offers executable procedures. For example, the “ParkHeating” (i.e. block heater) service might offer a SetTime procedure to start up the block heater at a specified time.

Services can also offer events that others can subscribe to. For example, to actually use the vehicle after warming it up, you need some charge in the battery. In this case, the battery could offer a service that allows you to check the battery charge level – and a “low battery” message would also be useful. An extract of the description can be seen in Listing 1, which uses the examples of the BatteryStatus and VehicleCommonDataType data types defined by W3C Vehicle Data [1].

// File: Vehicle.infomodel
infomodel Vehicle {
  functionblocks {
    Parkheating as ParkHeating
    Battery as Battery
// File: Battery.fbmodel
functionblock Battery {
  events {
    ChargingLevelLow {
      batteryStatus as BatteryStatus
  operations {
    getBatteryStatus() returns BatteryStatus
// File: BatteryStatus.type
entity BatteryStatus extends VehicleCommonDataType {
  chargeLevel as short <MIN 0> "MUST return battery charge level (Unit: percentage)"
  current as short <MIN 0> "Must return battery current (Unit: amperes)"
  voltage as short <MIN 0> "MUST return battery voltage (Unit: volts)"

To generate code for communication on the basis of the descriptions discussed above, you also need corresponding mappings. These contain information on addressing modes, for example, as well as other protocol specifications used by the code generator.


A demonstrator was set up to evaluate the concept and to show how all the information required for communication can be generated on the basis of the existing Vorto description. It consists of three components: The electronic control unit (ECU) provides a service (e.g. Battery), which is made available to an external application via the connectivity control unit (CCU).

ASOME/IP implementation is used for communication inside the vehicle. SOME/IP is a service-oriented middleware solution specially developed and standardized for the automotive industry. External communication with the application makes use of the RESTful protocol CoAP, which is widely used in IoT environments.

Eclipse Californium is put to use here: the CoAP server and client implementations based on Eclipse Californium are currently being generated on the CoAP side. Looking beyond what is possible today, one option for SOME/IP in the future would be to generate the configuration file, which contains information including the description of the services. Eventually, the mapping table available in the CCU, which is used to translate between the two protocols, can be generated from the Vorto model and the mappings for CoAP and SOME/IP.

SEE ALSO: A simple way to look at Eclipse IoT

Example: interoperability in the Industry 4.0 environment

The semantic description of machines and field devices is playing an increasingly important role in industrial automation, particularly in the context of the fourth industrial revolution and the Internet of Things. Bosch Rexroth is one of several companies investigating potential applications for semantic descriptions in industrial automation.

The modularization of machines offers an opportunity to reduce complexity and increase the reusability of source code. Coupled with the distribution of the application across multiple resources, this facilitates the development of a flexible control architecture. One prerequisite is an efficient communication infrastructure that makes communication possible both locally and across a network infrastructure.

A further prerequisite is a description of the interfaces in order to enable interoperable communication. Bosch Rexroth is therefore carrying out projects to investigate various possibilities, including the use of the Eclipse Vorto Toolset in combination with technologies that are already established and standardized in industrial automation, such as AutomationML.

Representing production systems in the form of skills makes it possible to describe the underlying technical potential provided by a resource in a production system [2]. Resources can be divided into three basic categories:

  • Mechatronic systems (e.g. autonomous production systems and machines)
  • Mechatronic machine modules (self-contained assemblies such as a gripper)
  • Mechatronic device components (i.e. field devices [3])

Eclipse Vorto offers a means of storing these skills in a simple and neutral format. It allows a resource’s services – for example, the opening and closing of a gripper – to be abstracted as operations. The parameters stored in configurations are used to configure and parameterize the resource during start-up; as a general rule, the data stored here is persistent and not tied to the current state of the resource. Using the data configured as the status and the events closely linked to this status, the data on a resource’s status is modeled and defined. To guarantee interoperability among multiple resources, the description of a function block needs to be as abstract as possible. Device-specific skills that cannot be modeled in an abstract way can then be encapsulated in a device-specific function block, for example.

Based on the information model, the abstract skills are then assigned to a specific resource. In most cases, a resource will then consist of multiple function blocks that describe the totality of the skills. Listing 2 shows a sample extract of an information model for a parallel gripper:

// File: Gripper.fbmodel
functionblock Gripper {
  Configuration {
    mandatory maxPressure as double
  status {
    mandatory state as GripperState
    mandatory angle as double
    mandatory pressure as double
  events {
    stateChanged {
      state as GripperState
      angle as double
  operations {
    open() returns boolean
    close() returns boolean
// File: Parallelgreifer.infomodel
infomodel Parallelgreifer {
  functionblocks {
    gripper as Gripper
    control as ModuleControl

Eclipse Vorto offers an optimum way to describe the skills of resources. What it does not offer, however, is a means of storing interdisciplinary information. This might include additional engineering data such as CAD drawings, process behaviors, or documentation on individual resources. Information from the overall system context (e.g. installation site and equipment identifier) also lies outside the scope of Vorto, even though this information is extremely important for developing production systems.

It is in this context that AutomationML has established itself as a container format in many areas of industrial automation. AutomationML is an XML format based on the CAEX standard (IEC 62424), and is used to describe system topologies, geometries and kinematics (COLLADA), logic and behavior (PLCopen XML) and semantics on the basis of libraries [4].

The expandable nature of the format facilitates the integration of Vorto information models and function blocks in the context of a production system. Definable classes (SystemUnitClass) in AutomationML make it possible to comprehensively model a resource and describe its own skills by incorporating an information model.

Embedding is carried out through a reference to the corresponding information model in the local or public Vorto Repository. References to external resources used by a specific resource can be modeled by a corresponding relation (interface) in AutomationML. Thanks to AutomationML’s instance hierarchy, it is then possible to model a complete production system. This is shown here based on a sample system.


The next step in the project is to investigate the potential applications of Vorto code generators in order to generate a communication framework for programmable logic controllers and enable the networking of resources.

Links & references

[1] “W3C Working Draft 19 January 2016”, W3C: (last updated: January 19, 2016)

[2] Schleipen, Miriam et al.: “AutomationML to describe skills of production plants based on the PPR concept”, 3rd AutomationML user conference, 2014

[3] Scheib, Jochen: “Modulares Engineering als Wegweiser für verteilte intelligente Systeme”, SPS/IPC/Drives conference proceedings, 2014

[4] “AutomationML – Fachexperten erklären das Format”, SPS-Magazin, 2013: (last updated: February 3, 2016)


Jeroen Laverman, Jochen Scheib, Marco Wagner, Olaf Weinmann

All Posts by Jeroen Laverman, Jochen Scheib, Marco Wagner, Olaf Weinmann

Jeroen Laverman is studying for his master’s degree in the corporate research and advance engineering department at Robert Bosch GmbH. His master’s thesis deals with vehicle-to-cloud interfaces and the development of a description of vehicle data and functions which is manufacturer and model independent. Jochen Scheib is a doctoral student in the software development department at Bosch Rexroth. He is working on a PhD in modular engineering in industrial automation. Part of his work involves studying the semantic descriptions of production facilities. Marco Wagner is a research engineer with a PhD in computer science who works in corporate research and advance engineering at Robert Bosch GmbH. One of his main areas of work is communication technologies within vehicles and between vehicles and cloud systems. Olaf Weinmann holds a PhD in mathematics and works at Bosch Software Innovations GmbH. His responsibilities as a project manager and senior expert include the Eclipse Vorto open source project, which was launched by Bosch Software Innovations in 2014.

Inline Feedbacks
View all comments