This blog entry introduces concepts and requirements for platforms to become symbIoTe-enabled (“symbIoTe Level 1 Compliance”) and is relevant to the symbIoTe 1st Open Call applicants.
Interoperability is an important IoT topic, not only in academic circles where semantic interoperability has been a hot topic in the last couple of years, but also for standardization bodies and industry. The later have done a good job at the protocol level (syntactic interoperability), but there is still a lot of confusion around interoperability at the data level (semantic interoperability).
symbIoTe-enabled app as a universal light switch
Let’s look at an example to illustrate semantic interoperability. I’d like to use a single mobile app to turn on/off and check the lights at home and in the office. Today I need two apps: one for my home automation system, and the other for the office environment. Both platforms are currently closed and third-party application developers cannot build a single app which will look for the lights at home that I can turn on remotely e.g. during my holidays, just for percussion. When leaving the office late in the evening, I could check the lights in my office and the coffee room using the same app, since I have valid credentials to turn them off. Perhaps I could even use the app in some public places where citizens (with adequate credentials) can light up or dim the lights.
If IoT platforms managing devices at home, in the office, and in public places were symbIoTe-enabled, we could build cross-platform applications that will 1) identify the lights at home, in the office, or in my vicinity, and 2) enable me to turn them on/off, but only in case I have proper credentials to do so. All symbIoTe-enabled platforms are actually performing the actuation tasks on their side using the existing hardware and software. symbIoTe plays an intermediary role between platforms and applications. In other words, it creates an environment where platforms become cooperative by exposing an open and symbIoTe-defined REST-based interface. Note that platforms stay in control of their environment by choosing the devices exposed to third parties and by managing the corresponding access rights.
The previous example seems quite simple, and yet it is challenging to implement since existing platforms speak different languages at the data level. Well, some say “we need to make things speak the same language;” however, we as humans do not like to be compelled to speak the same language, especially not at home. And I believe platforms are “at home” when talking to their devices ;-). It is thus highly unlikely that all IoT solutions will use the very same information model or a single standardized ontology.
The symbIoTe motto goes along the following lines: Let’s enable devices to understand each other to a certain extent. symbIoTe will facilitate the “translation process” (semantic alignment) between apps and cooperative platforms. To do so, symbIoTe needs to understand “platform’s offerings” so as to search for adequate devices and recommend them to application developers for easy integration into their IoT apps. Platform’s offerings refer here to virtualized devices exposed as REST-based Cloud services, since the IoT and Cloud convergence is prevailing in today’s commercial systems. Those devices need to be (partly) described using symbIoTe terms, i.e., in line with our Core Information Model (CIM). The CIM defines notions such as Sensor, Actuator, Service, Feature of Interest and Location, since apps are looking for the following:
- sensors producing data which a third-part app can consume or
- specific actuator primitives that can be accessed remotely, of course, only in case when adequate access tokens are disclosed.
symbIoTe architecture for Level 1 compliant platforms
We are currently building the registry, search and monitoring microservices to be augmented with our AuthN and AuthZ solution, and bundled into symbIoTe Core Services providing the mediation services between platforms and apps. The Core Services support the symbIoTe CIM, but also enable platforms to provide more information about their devices using platform-specific information models. Our approach is thus comparable to the oneM2M approach which specifies the oneM2M Base Ontology as the minimal ontology required so that other ontologies can be mapped into oneM2M, while an ontology such as SAREF can be seen as a platform-specific information model.
We are also working on the platforms side to provide a Java-based implementation of the Interworking Interface (symbIoTe-defined open platform interface) which apps access directly to retrieve sensor data or actuation services. We are currently evaluating whether an OData-like or NGSI-like interface is more suitable for the Interworking Interface. The platform-side components can use the Core Service REST endpoints (JSON as messages payload) to describe their devices if the symbIoTe CIM is sufficient for platform’s needs. However, if a platform needs to provide more information about its devices, it will have to extend the CIM, which requires the usage of semantic web technologies.
For more technical details on the symbIoTe approach to semantic interoperability please visit:
- 1st Open Call – Technical Details
- symbIoTe Deliverables: D1.2, D2.1 and D2.2
This blog relates to semantic interoperability aspects in symbIoTe which we call Level 1 compliance since platforms are extended with a “lightweight” set of features to create cooperative platforms. The consortium is also developing solutions for closer platform collaborations (platform federations); further details to follow in future blogs.
Ivana Podnar Žarko
Technical Manager of the symbIoTe project
This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 688156