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
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.
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.
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:
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.
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.
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.
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:
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.
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.
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.
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.