Subscribe Find out first about new and important news
  • Share via email
  • Subscribe to blog alert

Eclipse Vorto: The next step in IoT device integration

0 6 min

Alexander Edelmann

你好(Chinese for “Hello”), I am based in Singapore and have been working as a software engineer for Robert Bosch since 2006. I am passionate about IoT and believe in open standards that determine the successful interplay between devices across various IoT platforms. That is why I actively contribute to the Eclipse IoT Vorto project, which aims to provide cloud-based tools to uniformly describe IoT devices and integrate them into various IoT platforms based on open IoT standards. My IoT geeky side apart, I enjoy Asian cuisines that allow me to practice my chopsticks skills. You can also find me on the court hitting a few tennis balls with my friends.

Looking at examples like smart factories and homes, connected devices are improving not only the cost and resource efficiency of companies but are also increasing the safety and convenience of living. With the sheer number of device and sensor manufacturers, new challenges are surfacing for the manufacturers, platforms, and integrators.

The main problem is how to ensure connected devices can seamlessly communicate with cloud platforms, regardless of the different manufacturers, technologies, and systems. In the past, developers have built IoT solutions that were specifically designed for a limited set of devices that had the same API. When changing the device type or switching device manufacturers the device integration required time-consuming refactoring to work with the new device.

Imagine you plan to integrate an IoT solution for asset tracking on a large crop farm. You not only want to keep track of the current location but also temperature and acceleration of the tractors, plows, and other agricultural devices.

Two questions surface when thinking about choosing the right IoT devices:

  • How can we find out which devices have the type of functionality we want?
  • How can we avoid tight coupling between specific devices so it is easier to switch to a similar device without too much refactoring?

This is where the open source Eclipse Vorto steps in.

Introducing Eclipse Vorto

Infographic illustrating the features of Eclipse Vorto. Source: Eclipse Vorto

Eclipse Vorto provides an abstraction layer called the Vorto Information Model, and a domain specific language (DSL) which describes all the meta-information, like properties and functions, of a connected device.

By adding a layer of abstraction, we create a consistent interface that allows us to use different types of devices with similar functionality.

The Eclipse Vorto project is built on four main components:

  • Vorto DSL: The Vorto DSL is a readable and easily understood domain-specific language that was specifically designed to be usable even by non-developers. It is used to create the abstract models of different devices.
  • Metamodel: The metamodel is used to define the relationship between the different entities like Information Models, Function Blocks, and Datatypes.
  • Code Generators: Based on the DSL and metamodels, the code generators provide a sophisticated but simple way to create source code for a convenient integration of the defined IoT devices with an IoT solution platform.
  • Vorto Repository: The repository is used to store, manage, and distribute the created Information Models and Function Blocks for re-use.

Eclipse Vorto is fully open source and developed within the Eclipse IoT Working Group under the stewardship of Bosch.

Tim Grossmann

As a German computer science student, I have taken on assignments in 3 different departments at Bosch over the last one and a half years. I’m particularly interested in Open Source and EduTech technologies. I believe that the IoT and automation have a huge potential to both change and improve the way people live, work, and enjoy life. A passionate learner and developer, I’m always keen to learn new skills and tooling. In addition to my regular work, I have built and now maintain the world’s largest free open-source automation bot for Instagram. In my free time, I enjoy climbing outings with friends and travel in foreign countries.

Eclipse Vorto in practice

Let’s look at a more specific example to understand this abstraction better. Imagine an agriculture business that wants to keep track of the vehicles and assets used to collect the wheat crops. On larger farms with several harvesters, tractors, and other assets, we want to know the amount of time each vehicle was used and its location history.

When combining this kind of information with temperature and humidity values, we can enable a smart maintenance plan for all the vehicles and assets. The location of each vehicle and asset also provides us with anti-theft capabilities.

One of the solutions that provides this kind of functionality is the Asset Tracing Solution (TRACI) from Bosch.

Infographic showing the features of TRACI. Source: Bosch Software Innovations

In order to create a digital model of this specific device, we need to have some basic building blocks which will be used to assemble the TRACI Information Model.

One of the most important components of the tracking device is the battery. To be able to monitor the battery state of each device we can describe the state in what is called, a Function Block.

A Function Block is a generic model that can be reused later on in other device Information Models.

We can define one like this:

namespace org.eclipse.vorto version 1.0.0 displayname "Battery" description "Functionblock for Battery" category peripheral using org.eclipse.vorto.Voltage ; 1.0.0 functionblock Battery extends org.eclipse.vorto.Voltage { status { mandatory remainingCapacity as float <MIN 0, MAX 100> } }

Here we describe a Function Block that abstractly describes some entity that contains a mandatory numerical value between 0 and 100.

Since our status is a percentage value, we can further abstract this to, again, make the distinct components reusable. Therefore, we will create what is called a Datatype. Here we can define an entity (Percentage in this case) that has the same restrictions of being a numerical value between 0 and 100.

namespace org.eclipse.vorto.types version 1.0.0 displayname "Percentage" description "Datatype for Percentage" category units entity Percentage { mandatory value as float <MIN 0, MAX 100> }

Once we created this Datatype, it can be imported and used inside our Battery Function Block and replaces the concrete implementation.

namespace org.eclipse.vorto version 1.0.0 displayname "Battery" description "Functionblock for Battery" category peripheral using org.eclipse.vorto.types.Percentage ; 1.0.0 using org.eclipse.vorto.Voltage ; 1.0.0 functionblock Battery extends org.eclipse.vorto.Voltage { status { mandatory remainingCapacity as Percentage } }

We can repeat this process for all the sensors integrated into our TRACI device like the temperature sensor, GPS, acceleration, and connectivity modules. All those Function Blocks can then be assembled in a Vorto Information Model which can then be used as the starting point for the code generators to produce device integration code stubs for you.

namespace com.bosch.ps version 1.0.0 displayname "Traci" description "Information Model for Traci" using org.eclipse.vorto.Geolocation; 1.0.0 using org.eclipse.vorto.Acceleration; 1.0.0 using org.eclipse.vorto.MagneticStrength; 1.0.0 using org.eclipse.vorto.Temperature; 1.0.0 using org.eclipse.vorto.Battery; 1.0.0 using org.eclipse.vorto.Connectivity; 1.0.0 infomodel Traci { functionblocks { battery as Battery location as Geolocation acceleration as Acceleration temperature as Temperature magneticStrength as MagneticStrength bluetoothConnectivity as Connectivity lorawanConnectivity as Connectivity } }

Alright, so what do we do all this for?

Let’s say we now want to use devices from other manufacturers with similar features to the TRACI device. We’ve already created an IoT solution that integrated the TRACI device and it would be a huge pain to refactor our system to work with devices from different manufacturers.

Since we already have our Function Blocks and the Datatypes defined, we can define a new Information Model for our new device that uses the same Function Blocks as the TRACI model.

Let’s compare the TRACI model with a product with comparable functionality, the NL-AT2VS from NimbeLink.

namespace com.nimbelink.nl version 1.0.0 displayname "NLAT2VS" description "Information Model for NLAT2VS" using org.eclipse.vorto.Geolocation; 1.0.0 using org.eclipse.vorto.Battery; 1.0.0 using org.eclipse.vorto.Connectivity; 1.0.0 using org.eclipse.vorto.Temperature; 1.0.0 using org.eclipse.vorto.Humidity; 1.0.0 using org.eclipse.vorto.Acceleration; 1.0.0 infomodel NLAT2VS { functionblocks { battery as Battery acceleration as Acceleration location as Geolocation temperature as Temperature humidity as Humidity wifiConnectivity as Connectivity cellularConnectivity as Connectivity } }

We can see that even the connectivity modules are different in this model but are still using the abstract Connectivity Function Block. The abstraction allows us to replace or combine different devices with similar functionality without much integration overhead.

Who should use Eclipse Vorto?

Given the diversity of entities involved in manufacturing, integration, and development of IoT solutions, the entities that will benefit most from Eclipse Vorto are:

Device manufacturers

Eclipse Vorto can help device manufacturers enable interoperability with other devices in existing infrastructures. Flexibility is a huge advantage to customers when choosing devices that are to be integrated.

By using technology independent Information Models, device manufacturers avoid the overhead of generating ways of implementations for all kind of target platforms. This saves money and time by publishing Information Models that can be converted into concrete integrations using the code generators.

The big advantage of using Eclipse Vorto is that further evolutions of the device protocol layer are decoupled from the device controller logic.

Infographic showing the benefits of Eclipse Vorto for device manufacturers. Source: Eclipse Vorto

IoT platforms

IoT platforms have to connect a vast variety of different IoT devices from a wide range of manufacturers and support all the different protocols and formats. By using Eclipse Vorto’s code generators, this effort can be reduced drastically through either partial or full source code generation.

In addition, the Vorto Repository acts as a runtime repository which allows platforms to retrieve device capabilities as JSON schema. These schemas can then be interpreted and validated in the digital twin or used to bootstrap connectors for the communication.

Even though this means increased initial development work, it will pay off over time considering the vast amount of devices and the growth of IoT.

Solution developers

When integrating connected devices and smart sensors into IoT solutions, developers need to cover a wide range of different device APIs which results in a huge coding overhead. Eclipse Vorto can reduce the amount of development work involved by providing code generators that provide generic code stubs that simplify the integration of devices.

Infographic illustrating the benefits of Eclipse Vorto for solution developers. Source: Eclipse Vorto

Glancing into the future of the IoT

By guaranteeing interoperability and harmonizing the interface for devices, Eclipse Vorto has the potential to change the way device manufacturers, IoT platform operators and application developers work with IoT devices.

It can reduce the development work for manufacturers and ease the device integration for platform providers and integrators while tackling many of the mentioned challenges of IoT development.

If you want to learn more about the project, make sure to check out the GitHub repository and give it a star.

You can also give it a try and use the sophisticated tutorials for device creation, integration, and visualization provided in the Vorto Repository.

More about Eclipse Vorto

Putting Eclipse Vorto into practice: How to avoid tight coupling of devices in IoT solutions.

Get the whole picture: Check out Eclipse Vorto's Github page.

Learn more about Eclipse Vorto.

Check out device information models in the Vorto Repository.

Take a look at these Eclipse Vorto tutorials to get started.

0 Comments

Cookie Information

This website uses cookies for reasons of functionality, comfort, and statistics. If you consent to this use of cookies, please click ”Ok“. If you like to disable the cookies for webtracking, please click here. For more information see our Privacy Policy