We launch our Blog series with this first entry on the scope and vision of symbIoTe!
The word “symbiote” (pronounced sim-bee-oht), is often used in biology to describe an organism living in a state of symbiosis, i.e., the close association between two or more organisms of different species, often but not necessarily benefiting each member. In the context of IoT, symbIoTe is about IoT platforms operating in a symbiotic way. But why do IoT platforms need to harmonically co-exist? What are the obstacles for such a coexistence? And why this is problem? We will try to answer these questions in the few next paragraphs, and provide a high level overview of the symbIoTe’s vision.
Nowadays, as the IoT market is blooming, the number of IoT technologies and solutions is constantly increasing, resulting in a fragmented environment with a variety of protocols supported by the sensing and actuating devices. The offered IoT solutions focus on various domains, like the smart residence and the smart city, to name a few. However, such vertical solutions remain closed for third parties (i.e., external applications or platforms) that would like to re-use them in order to offer added-value solutions. This leads to high market entry barriers for SMEs and startups with innovative ideas, since they have to maintain an end-to-end solution (typically from sensors to gateways and cloud-based back end).
Apart from the inefficiencies suffered by the ICT solution providers, the consumers, are also faced with suboptimal experiences. Imagine a consumer using one mobile app to interact with his smart home, then switching to another app when commuting, and finally using a different app to interact with a smart office, a smart campus or even a smart stadium. Although variety is the spice of IoT, the need for cross-domain apps is becoming more and more emerging! Furthermore, owners of a smart environment (i.e., of a smart building) are faced with the complexity of installations required to meet their needs. Different IoT solutions are expected to co-exist in the same space while being able to take advantage of the sensors already deployed by pre-existing systems, hence adding value to both an existing and new installment.
To remedy the aforementioned situation, symbIoTe introduces the symbIoTe middleware. We are not talking about a new, “super” IoT platform, but rather about a middleware that allows IoT platforms to cooperate with 3rd party applications and external systems, as well as to collaborate with other IoT platforms. For this to happen, the IoT platforms need to open and expose (some of) their resources. By resources, we initially refer to primitive devices, like sensors and actuators, that the platform wants to expose. For example, a resource can be “Temperature Sensor X”, which measures the temperature of its environment. However, resources can also be composite services that the IoT platform chooses to offer to third parties. In this case, a resource can be the “Room A Temperature” service which uses the measurements of 5 different temperature sensors in a large room to provide the aggregated value of the measured temperature.
Based on the notion of opening and sharing resources, symbIoTe introduces 4 concepts: the advertisement and discoverability of IoT resources, the IoT federations, the roaming of smart devices and the Domain Enablers. Through its middleware, symbIoTe allows IoT platforms to advertise their resources. By performing the needed semantic translation, the middleware facilitates 3rd party applications or external systems to access the offered resources in a uniform and secure way, without interfering in the actual data exchange between the IoT platform and the external application.
From the above, it is obvious that not only external applications can access the resources that an IoT platform offers. It is also possible that another IoT platform can use the symbIoTe middleware to access the offered resources. However, in this special occasion that two (or more) IoT platforms decide to collaborate, symbIoTe introduces the concept of the federation. Through IoT federations, symbIoTe lays the proper trust and security mechanisms, as well as the necessary bartering rules, to allow IoT platforms to share their resources between them in a fair, secure and accountable way. It is important to note here that federations can happen either on the Cloud level (i.e., for remote cloud-based IoT platforms) or even on the gateway level (i.e., for collocated IoT platforms). Federations are also the means to allow for roaming of smart devices across different ecosystems. Through the appropriate authentication and authorization mechanisms between the federated IoT platforms, smart devices (sensors, actuators, mobile devices) can move from one platform to the other seamlessly and get automatically configured to interact with the local environment.
On top of all these, symbIoTe introduces the Domain Enablers. A domain enabler focuses on providing domain-specific intelligence to 3rd party applications, hiding at the same time the complexity of collecting the necessary data from numerous IoT platforms. A domain enabler undertakes the tasks of finding the appropriate resources from the available platforms, maintaining the desired quality on the provided data (by adding and removing resources on the fly), providing the necessary domain-specific logic to interpret the collected data, and storing historic data to complement the real-time readings. A domain enabler is seen by both the symbIoTe middleware and the IoT platforms as an external system (i.e., an application) that uses the available resources. 3rd party application developers can use different domain enablers so as to create cross-domain applications, without worrying about the interaction with underlying IoT platforms. symbIoTe will offer some domain enablers, bound to its use cases, but anyone can set-up and offer his own enabler to the IoT community.
At this point, I will try to give a more practical perspective to the aforementioned concepts, using symbIoTe’s use cases as an example. The Smart Residence use case is clearly a case where collocated (in-house) platforms federate to share and exchange sensor readings. Such a federation can be restricted only inside the house, which may simplify certain aspects of the federation. Smart applications can combine offerings from the different platforms to offer a cross-domain solution. In the EduCampus use case, a federation is again required, but this time remote platforms are involved. Hence, cloud based systems will be interconnected and special rules for the participation in the federation need to be in place (authorization, fair use of resources, etc), since the systems belong to different authorities. Additionally, roaming of devices will be possible in this case. The Smart Stadium use case resembles with the Smart Residence, in the sense that deployed platforms are collocated, but in this case, the owners of the various systems may differ. Hence a more strict control in the access of the required information may be required. The Smart Mobility and Ecological Urban Routing use case is all about city-wide platforms advertising their resources and 3rd party applications combining them to offer value added solutions. However, an environmental Domain Enabler could also be present to hide from the applications the complexity of interacting with all the underlying platforms (consider a city-wide or even country-wide scope). Such a Domain Enabler could provide aggregated and processed information that is still meaningful and valuable to the cross-domain apps, i.e., offering aggregated temperature and/or air-quality levels for a neighborhood (by combining the readings from tenths or hundreds of sensors). Finally, the Smart Yachting use case involves again platforms sharing their resources (on-board systems and marina’s management platforms), which may even form federations, possibly in a local scale (i.e, when the yacht approaches the marina).
Before closing this post, here’s a tip for all those who are thinking to apply to our 1st Open Call (open till 28 February): in order to successfully apply to the Open Call, you need to ask yourself three questions: i) Which resources does it make sense to expose to 3rd parties? ii) How these resources will be of use to 3rd parties? and iii) What is their added value when combined with 3rd party resources?
Stay tuned for the next blog entry by symbIoTe’s Technical Coordinator, Dr. Ivana Podnar Zarko, on some technical details of our “lightweight interoperability solution” which we call Level 1 compliance!
Sergios Soursos
Coordinator 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