The Vorto project, a no-standard approach to IoT interoperability


A few weeks ago I stumbled upon an interesting project while I was writing my article ‘Why smart services need better -not just more- data’: the open source Vorto project, which aims at developing information models for various connected devices. This framework provides programmers with an abstraction of the connected ‘things’, to describe generic states, interactions and functions. That is to say, instead of focusing on what a connected dishwasher from a specific brand can do, the information model describes what are the attributes and functions of a generic connected dishwasher.

This tool can thus be used to work on real life use cases without having to dig into the specificities of a particular device. The code can later be translated into the necessary language or framework to operate on a specific brand. The end goal of the Vorto tool is indeed to go past the thought experiment, and to incorporate the code in real life devices: that is made possible with the Code Generators, which translate the ‘generic’ code into specific brands compatible code. As of now, three code generators are available, one for Eclipse SmartHome, one for Bosch, and one for Kura. The Vorto Information Model also allows users to manage, share and reuse information models for various connected devices, including various sensors: geolocation, temperature, light, smoke, motion sensors…

The example published on the project’s website illustrates quite well how the Vorto environment can be used:
Let’s assume Vendor A creates a new Z-Wave smoke detector which can measure the temperature, return the battery status and also fire an alarm event in case of fire. Using the IoT tool set, vendor A creates a corresponding information model which describes the three functionalities. After creating the information model vendor A publishes the model to the Information Model Repository. Now user B who bought such a smoke detector wants to include it into his openHAB environment. Using the IoT tool set he can browse the repository to find the information model created by Vendor A. After downloading it he could create the openHAB representation of the device using a specific code generator. In a last step he would complete this representation by adding required Z-Wave configurations.’

The Vorto tool could prove useful to device manufacturers: by providing a generic description / information model of their products, their devices would easily be integrated in generic functions and scenarios of a platform vendor. From a platform vendor point of view, creating a Code Generator allows an easy integration of the devices into a solution, using the information models that are available in the repository. As for the end user, betting on a platform or devices working with this kind of framework is the guarantee of being able to add new devices or replace old ones without compatibility issues.

Other initiatives for the standardization of the Internet of Things do exist, among others:

While I don’t claim to have studied these initiatives in depth, what I think is most interesting about the Vorto project is that it’s not another attempt to make a new standard that would encompass all the existing technologies, like it is too often done. The Vorto project doesn’t have the ambition to describe how the communication interfaces should be between various devices. Instead, it provides the IoT ecosystem with a technology agnostic abstraction layer to describe potential interactions and use cases. The link with existing technologies -the code generators- can later be developed by any platform vendor or solution developer who believes in the project.

I think it is well worth keeping an eye on this initiative in the next few months, to see if how their approach is acknowledged by the IoT ecosystem. The Vorto project could indeed accelerate the adoption of IoT applications and multi-vendor solutions, despite the lack of a common standard to enforce interoperability.