symbIoTe builds an IoT interoperability middleware, it is not yet another IoT platform. In fact, symbIoTe components (the SymbioteCore, the SymbioteCloud and the SymbioteSmartSpace) never store any sensor data nor take over the management of IoT devices from existing platforms: they rather offer interoperability and mediation services on top of existing IoT platforms. In this blogpost, we introduce a novel concept of symbIoTe Enablers, which can be seen as “virtual” IoT platforms. The Enablers are Cloud-based services that add value on top of platforms and their resources within the symbIoTe ecosystem. The Enablers need to fetch required sensor data from symbIoTe-enabled platforms to provide, e.g., some sort of data analytics or real-time processing services. They are typically domain-specific and simplify the development of apps within the symbIoTe ecosystem.

Let us step back to quickly revise the symbIoTe ecosystem from a top-down approach. Since symbIoTe applications typically need to interact with multiple IoT platforms and their resources, this interaction may be complex and compute-intensive, or too dynamic and difficult to implement for mobile and web apps. Thus, Enablers are envisioned and designed as back-end services which take over such complex tasks to offer simple APIs to the applications. The Enablers greatly simplify the development of apps by concealing the complexity of the underlying symbIoTe ecosystem hosting many IoT platforms; they can even be used as a single point of access to this ecosystem. Moreover, the Enablers create opportunities for new stakeholders to enter into the IoT space, e.g., AI experts can provide specialized algorithms and data processing services on top of IoT infrastructure and platforms within the symbIoTe ecosystem. The vision of this ecosystem is depicted in the following figure, where symbIoTe-specific software is marked in green.

Enabler placement within a symbIoTe-enabled ecosystem

Here we see how an app can invoke services directly from the Domain Enabler, while the Enabler interacts with two platforms (A and B), which offer IoT resources over the symbIoTe-specific interface. The Core Services are used to advertise both the resources offered by IoT platforms and services offered by the Domain Enabler.

Within the symbIoTe ecosystem, an Enabler takes two roles:

• Platform, since it behaves as an IoT platform offering value-added IoT-based services, and
• Application, since it acts as any other application which accesses resources offered by the symbIoTe-enabled platforms.

In the platform role, an Enabler registers its value-added services with the symbIoTe Core Services, integrates symbIoTe Cloud components to become a symbIoTe-enabled platform, and serves application requests over its Inter-working Interface and domain-specific interface.

In the application role, the Enabler acts as any symbIoTe application which searches for resources using the Core Services and accesses resources offered by other symbIoTe-enabled platforms. Thus, each Enabler instance integrates generic symbIoTe-defined components which are independent of its domain-specific features. They represent the basic Enabler structure that is easy to use and deploy so that a developer only needs to focus on value-added and domain-specific features when building a new Enabler.

Generic Architecture of symbIoTe Enablers

The generic architecture of an Enabler is composed of two types of components:

• components in common with SymbioteCloud which implement the platform role (marked in orange)
• Enabler-specific components (marked in green).

Each Enabler handles two types of resources since it acts both as a symbIoTe application and an IoT platform. Enabler Resources are resources that the Enabler offers to applications (in its role of a “virtual” IoT platform), and Underlying Resources are defined as resources that the Enabler uses from the underlying symbIoTe-complaint IoT platforms. Enabler Resources are created by using the Underlying Resources.

Generic Architecture of symbIoTe Enablers

Components in common with SymbioteCloud are generic components for each Enabler. These include: Resource Access Proxy (RAP), Authentication & Authorization (AAM), Registration Handler (RH), and Monitoring. RAP serves as an access point for applications to use resources exposed by the Enabler. AAM is responsible for authenticating and authorizing users, applications and Enabler components. RH registers resources exposed by the Enabler to symbIoTe Core, while Monitoring tracks the availability and usage of the resources exposed by the Enabler.

Enabler-specific components implement domain-specific functionalities. These components are Resource Manager, Platform Proxy and Enabler Logic. Developers wanting to build their domain-specific enablers need to implement and deploy those components in accordance with their specific requirements. More specifically:

• Resource Manager is responsible to find Underlying Resources using the Core Services which are required by an Enabler to provide its value-added services. Domain-specific functionality of this component relates to the process of finding adequate Underlying Resources and replacing them with others when some resources become unavailable. This is a dynamic process which uses the Core Services.
• Platform Proxy is used to access the Underlying resources exposed by IoT platforms and found by the Resource Manager. A domain-specific functionality of this component relates to the interaction logic with those resources, for example the proxy can retrieve data from a sensor every 100 seconds or use a WebSocket to continuously receive sensor readings.
• Enabler Logic is an enabler-specific component responsible for specifying the type of resources that will be found by the Resource Manager, accessed by the Platform Proxy and offered to applications. It also integrates domain-specific logic, e.g., functions for processing the retrieved data (e.g. data aggregation), statistical operations and similar. These functionalities should be customized for each specific Enabler and that is the reason why it is published as a library that needs to be included in each specific Enabler component.

Examples of Enablers built by symbIoTe

In symbIoTe we have developed four specific Enablers which are used in some relevant use cases in which IoT platforms are to be integrated with external application service platforms.

Smart Mobility and Ecological Urban Routing (SMEUR) Enabler

The SMEUR Enabler offers the most preferable routes for cyclists and pedestrians in cities based on the available environmental data about air quality acquired through various platforms, e.g., official fixed stations and citizen-generated readings acquired by wearable air quality units. This enabler searches for sources of air quality readings for a specific city area, fetches these readings from symbIoTe-enabled platforms, and uses an Interpolator to estimate air quality over specific user routes. In addition, it integrates an external Routing Services to offer routes not only based on shortest distance, but taking into account air pollution on route segments provided by the Interpolator. In addition, this enabler provides an additional service, Point of Interest (PoI) Search, which allows users to search for PoIs, such as restaurants or bars based on air quality data. The user can choose and filter received results according to his/her preferences.

We have developed an Android application which uses this Enabler, available on Google Play for you to test: symbIoTe SMEUR. Currently the routing service is operational in Vienna, Zagreb and Porto.

SMEUR Enabler and application

Smart Yachting Enabler

The Smart Yachting Enabler eases the integration of data from the yachts with data available in the ports and port applications, to facilitate the mooring and automatic supply chain processes. The Smart Mooring process aims to automate the mooring procedure of the port, which is quite a bureaucratic and tedious process, since marinas operate in strongly regulated contexts. The Automated Supply Chain process aims to automatically identify the needs for goods and services on board of the Yacht, so that automated requests for offers can be issued on the marketplace platform of the Port. Both processes exploit the data from IoT sensors to automatically acquire information from the Yacht and to pass them to the aforementioned business applications that are connected to the Port infrastructure.

Smart Yachting Enabler and Application

Location-Based Resource Filtering Enabler

SymbioteSmartSpaces (SSP) are defined as physical areas where one or more IoT platforms coexist, each of them providing some kind of service: in this way, they define abstract boundaries for the IoT services and platforms they embrace. Different platforms, though, can use different names for the same spaces, areas and locations. For example, a platform could split a building in many floors, and register devices indicating to which floor they belong, as well as another platform can use rooms to indicate symbolic locations for its resources. This presents is a different way to subdivide the same building.
It is necessary for the symbIoTe Smart Residence use case to manage all the symbolic locations defined for an SSP, to classify them in some kind of a tree view, and to allow the Enabler to understand the actual hierarchy of the SSP’s topology. This operation is provided by a manual configuration made by the SSP administrator that must be able to rearrange all the registered areas to specify whether one contains or is contained by another (e.g. floors in buildings, rooms in floors, etc.); for this purpose, an administration console has to be provided to the SSP supervisor.

The Location-Based Resource Filtering Enabler is able to filter devices of the Smart Space basing on their registered position (which can be a building, floor, room, etc.), after the results gathered from the Search component (in the symbIoTe Core Services). This means that an additional filtering is applied to the result coming from the symbIoTe Core Services.

  Smart Residence – Enabler and Application for Location-Based Resource Filtering

Indoor Positioning Enabler

This enabler provides an integrated indoor-location service which estimates indoor location based on visible BLE beacons, WiFi access points and mobile network base stations. The process is started by a user device (typically a smartphone) as a sensor which detects various network technologies present in its environment and it sends this information as a parameter in the Enabler. After that the Enabler needs to query a certain SymbioteSmartSpace (SSP) to get relevant information and then it can calculate the position from the received data by doing a weighted average of the data received from multiple positioning platforms. Returned information can be either GPS location or symbiotic location (e.g. building room number in campus).

Enabler and Application for Indoor Positioning 

Make your Enabler

Interested in doing it for your app? Just download our Enabler software from GitHub and follow our step by step instructions there.

We look forward to welcoming you in our symbIote Middleware Community!