We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
Internet of Things (IoT) Services Enablement Architecture - FIWARE Forge Wiki

Internet of Things (IoT) Services Enablement Architecture

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

Introduction

Internet of Things chapter provides the Generic Enablers to allow Things to become available, searchable, accessible, and usable context resources fostering FIWARE-based Apps interaction with real-life objects.

In this context, Things mean any physical object, living organism, person or concept interesting from the perspective of an application and whose parameters are totally or partially tied to sensors, actuators or combinations of them.


The successful innovative idea behind FIWARE IoT is that all Things or IoT resources are exposed to FIWARE App developers just as other NGSI Context Entities. Therefore developers will not have to deal at all with today's complexity and high fragmentation of IoT technologies and deployment scenarios. On the contrary, App developers will just need to learn and use the same NGSI ContextBroker API used in FIWARE to represent all Context information.

Developers will just read Entity attributes to gather sensors information and will just modify (update) specific attirbutes to trigger commands that will be delivered to actuators.

Normally, during FI-WARE Releases (R1 to R6), the Backend will refer to the IoT Backend enablers instances running in the FIWARE Lab, as described in the FIWARE Catalogue.

This page is for Release 4 of FIWARE. If you need to see the previous architecture for components of Release 3, please visit Internet of Things (IoT) Services Enablement Architecture R3

Architecture Overview

IoT chapter Architecture deployment varies from simple scenarios -connecting few devices using standard IoT communication protocols to the data chapter Context Broker- to more complex scenarios distributed across a large number IoT networks connecting IoT Gateways and IoT nodes and providing advanced composition and discovery functions.

IoT GEs are spread over two different domains:

  • IoT Backend. It comprises the set of functions, logical resources and services hosted in a Cloud datacenter. Up north, it is connected to the data chapter ContextBroker, so IoT resources are translated into NGSI Context Entities. South-wise the IoT backend is connected to the IoT edge elements, that is all the pyhsical IoT infrastructure.
  • IoT Edge. It is made of all on-field IoT infrastructure elements needed to connect physical devices to FIWARE Apps. Typically, it comprises: IoT end-nodes, IoT gateways and IoT networks (connectivity). The IoT Edge and its related APIs will facilitate the integration of new types of gateways and devices, which are under definition in many innovative research projects, and warranty the openness of FIWARE IoT architecture.


Complete Architecture

This section depicts a complete scenario with all FIWARE IoT GEs (Backend and IoT Edge) and their relationship in terms of APIs and communciation protocols.

Please, to avoid unnecessary complexity, check first our current and planned typical scenarios. Check them at the next subsections "Typical IoT use-case Scenarios".


File:FIWARE IoT R4 arch v3.png

Typical IoT use-case Scenarios (I): Common Simple scenario

This scenario stands for a simple integration of IoT devices into the Data chapter ContextBroker so that FIWARE App developers can interact with them. This use-case scenario is currently working and available to FIWARE users at the FIWARE Lab.

The mandatory GEs for this scenario are:

  • Backend Device Management GE. That will translate the Device or Gateway specific communication protocol into NGSI. It will always handle sensor notifications from the device towards the ContextBroker and for some specific protocols actuation/command messages from the ContextBroker to the device. Please refer to this GE architecture and documentation for more information.
  • Data Chapter ContextBroker GE. It will handle all Context Entities representing the IoT devices. It is the natural interface for FIWARE App Developers for reading IoT sensing information (Entity attributes) and, if implemented for the Device communication protocol, also to trigger commands (Entity specific attributes).

Optional GEs and functions are:

  • Gateway Logic GE. It will handle the IoT Edge management API and functions plus the gateway-to-gateway APi and functions. For the first (Edge Management) it needs the correspondent function/module to be activated and configured in the BE Device Management GE.


Typical IoT use-case Scenarios (II): NGSI Native Scenario enabling Devices composition

This scenario describes a use case where IoT end nodes or at least intermnediate Gateways implement the NGSI protocol. This use-case scenario is currently under experimentation and will be available soon to FIWARE users at the FIWARE Lab.


If devices are NGSI native they might be directly connected to the Data ContextBroker, but also they may be connected to the Gateway Data Handling GE to perform events classification and/or composition (Complex Event Processing) at the Gateway level.

Data Hanldling GE may push NGSI notifications directly to the Data ContextBroker or might be pushing them to the IoT Broker GE that combined with the IoT Discovery GE will be able to provide Things composition and discovery functions.

Backend Device Management GE is optional, as it is only needed in this scenario if IoT Edge Management functions are offered to IoT integrators.

Typical IoT use-case Scenarios (III): Full Scenario enabling Devices composition

This scenario includes all IoT enablers and it is depicted by the complete diagram shown at the beginning of this section. It is able to handle and combine (i.e. build Things from devices) native NGSI devices/Gateways and also any other kind of IoT devices/gateways (via the BE Device Management IoT Agents).

This use-case scenario is currently under experimentation and will be available at the end of Release 5 to FIWARE users at the FIWARE Lab.

Basic Concepts

Device, IoT-end node, IoT Resource, Thing and IoT NGSI Context Entity

A device or IoT end-node is a hardware entity, component or system that either measures or influences the properties of a thing/group of things or performs both activities concurrently. Sensors and actuators are devices. Normally, we will use the term IoT-end node for complex physical devices with several sensors and actuators (e.g arduino-based complex system). Devices migh use standard or propietary communication protocols that are natively pushed to the Backend GEs or might be translated into any other standard or prpietary communication protocol at IoT Gateways. A particular case of communciation protocol is OMA NGSI. However, we do not expect devices and gateways to implement it and therefore FIWARE GEs provide a way to translate these protocols into NGSI.

An IoT resource is a computational element providing access to sensor/actuator devices. An information model for the description of IoT resources can include context data like location, accuracy, status information, etc. IoT resource level data consists not only of the measured data, but also context information like the data type, a time stamp, accuracy of measurement, and the sensor by which the measurement has been performed. IoT resources can be addressed using a uniform addressing scheme. The resource is usually hosted on the device but it has a logical representation in the backend as well.

A thing can be any object, person, or place in the real world. Things are represented as virtual things having an entity ID, a type and several attributes. Sensors can be modelled as virtual things, but other real-world things like rooms, persons, etc. can be modelled as virtual things as well. So thing level data consists of descriptions of things and their attributes, while information on how the data has been obtained might be contained as meta data, but is in general out of scope.

In FIWARE, all Things, IoT resources or IoT end-nodes are represented in the end as IoT NGSI Context Entities in a Data chapter ContextBroker GE.

Interface Abstraction Levels

This section explains in detail the functionalities and interfaces implemented at each one of the IoT domains or levels.

Backend Level

From a functionality point of view, IoT backend GEs perform the following functions:

  • Provision of Things NGSI Context entities. This means to create an NGSI Context Entity per each one of the IoT resources. It is typically carried out by the Backend Device Management GE, although in some advanced scenarios it might be alternatively implemented by the IoT Broker GE. The GE in charge of this function plays the role of Context Producer for all Entity attributes related to IoT resources sensing/observations. On the other hand, it registers itself as Context Provider for those Entity Attributes related to actuation capabilities. This way, whenever a FIWARE developer modifies (udpates) one attribute related to actuation, the ContextBroker will push back the notification to this enabler that will in turn trigger a command to the device.
  • IoT Southbound protocol adaptation. The variety (fragmentation) of communication protocols for IoT devices and/or gateways is extremely high today. FIWARE implements the most reputed open standards in the market today to ease the connection of any kind of IoT devices. Moreover, it provides an easy way to extend the number of supported communication protocols regardles they are based on open or propietary specifications. This function (in the backend) is carried out by the Backend Device Manager GE so it handles the translation of IoT southbund protocols (sensing and actuation) into/from the OMA NGSI protocol. For some specific communication protocols, some tools (SDK) for specific or generic hardware platforms are also provided for IoT integrators convenience.
  • IoT Edge management. Some configuration, operation and monitoring functions regarding IoT Edge elements (Connectivity/Networks, Gateways, End-nodes) might be controlled from the Backend Device Management GE and thus exposing a convenient API to IoT integrators in addition to the NGSI API for ContextBroker interconnection.
  • IoT Devices composition and discovery. IoT resources might be combined into new IoT resources representing a more abstract concept. For instance, all temperature sensors in a room might be combined (e.g. average of all observations) to create an improved "Room-A_Temperature" thing with its related Context entity. Discovery facilities are provided for atomic and composed IoT resources. These functions are provided by the IoT Broker GE in combination with the IoT Discovery GE.

IoT Edge level

On the other hand, IoT Edge GEs implement the following functionalities:

  • IoT Southbound protocol adaptation. This functionality is similar but pretty much reduced compared to the one provided at the backend, it just means to translate specific protocols into NGSI within a gateway device so that native NGSI entities might be pushed directly to the backend enablers (typically the IoT Broker or directly the Data chapter ContextBroker). This function is provided by the Protocol Adaptor GE. Current supported technologies are Zigbee and RFID tags.
  • Complex (NGSI) Event Processing. Although there is one specific GE in the Cloud for this functionality (Data Chapter CEP GE), for some scenarios it might be useful to reduce the network traffic exchanged between the IoT edge elements and the Cloud infrastructure. It is provided by the Data Handling GE within a Gateway device. Data Handling GE consumes, processes and delivers NGSI events so it is typicall used together with the Protocol Adaptor in the same gateway device.
  • Gateway Logic. This function handles a gateway-to-gateway API (currently under definition) and the IoT Edge configuration API at the gateway level (currently under definition too). For the IoT Edge configuration of gateways existing protocols such as OMA-LWM2M management interfaces, OMA-DM or BBF TR.69 are to be considered. It will be provided by the Device Management GE.
  • IoT end-nodes Configuration. Some IP-capable nodes will not traverse gateways and therefore they might be operated and monitored directly. This means they will implement themselves an IoT Edge configuration API at the IoT-end nod level. In this specific case mainly the management interfaces of OMA-LWM2M are expected to be considered due to the constraint nature of IoT-end nodes.
  • IoT Networks Configuration. In complex scenarios such as smartcities, IoT-end nodes are not expected to be connected over a unique connectivity network. On the other hand, several IP alternatives are expected to co-exist, namelly: cellular (2G, 3G, 4G and soon 5G), meshed-radio networks (6LowPAN/IEEE.802.15.4), IP/BLE, LPWA, etc. It is important to note that this control plane is not the IoT devices or end-nodes control plane, but a different one that may include also interaction with network APIs. This function will be implemented at the IoT Edge module in the Backend Management GE, the Gateway Logic module at Gateways and in a similar module at IoT-end nodes.

A key design statement is that, whenever present, IoT Gateways are not expected to be permanently connected to the Backend as per communications design or because of failures. Another relevant remark is that IoT Gateways are expected to be constrained devices in some scenarios. Therefore, light-weight implementations of the same GEs as in the IoT Backend, plus additional GEs interfaces helping to save unnecessary features/GEs might be considered in the Gateway domain.

OMA NGSI – Context Management

The OMA NGSI Context Management standard provide the NGSI-9 and NGSI-10 interfaces to manage and exchange Context Information about Context Entities. A Context Entity is any entity which has a state. Values of attributes of defined entities becomes the Context Information that application have to be aware of in order to support context-awareness. Context Information is any volatile or persistent information, which describes a state of a Context Entity. Of course, Context Entities could be users, devices, places, buildings, therefore “things” as defined in the FI-WARE IoT chapter. Context Information related to things can be measured by sensors, and combined with other context information manually set by humans, derived from interactions with the user, operations on handsets or terminals, inferred from other information, or requested from databases. Adoption of OMA NGSI in the FI-WARE IoT chapter enables to manage the configuration of, and the data associated to, arbitrary physical objects in the real world, (Devices and Things). Interestingly, it enables this at a level of abstraction that allows getting rid of the complexity of managing connections with gateways and devices. Actually, updates on the state and configuration of those physical objects will come as updates on the Context Information (i.e., updates on attributes of Context Entities representing those physical objects) and Configuration (i.e., updates on information about available Context Entities). The purpose of the NGSI-9 interface is to exchange information about the availability of Context Information and Context Entities, while NGSI-10 is designed for exchanging the Context Information itself.


References:


Interfaces to other Chapters

Data

IoT chapter mainly interacts with the Datachapter ContextBroker GE as long as all IoT resources (Things) are translated into NGSI Context Entities that are provisiones in a specific ContextBroker. It uses both NGSI10 (for sensing and actuation attributes of Thing entities) and NGSI9 (just for actuation attributes, if implemented). Please refer to ContextBroker GE documentation for more information.

Security

IoT chapter GEs are secured by hiding themselves behind a Security Chapter IDM proxy GE that implements an Oauth2.0-token-based access control (including users permissions and roles plus the concept of FIWARE service-path and subservice-path). Please refer to IDM GE documentation for more information.

Security at the Backend domain APIs will be provided by the overall security access mechanism based in Oauth2.0, developed in the FI-WARE Security chapter and implemented as a reference in the FI-WARE testbed.

I2ND

IoT chapter will interact with Robots included in the I2ND chapter. The typical scenario will be Robots based on ROS architecture interacting with IoT resources represented as NGSI Entities in a ContextBroker. However, straight interactions with IoT elements might be envisaged. Please refer to I2ND Robotics section for more information.

Architecture Description

Backend

IoT Edge Generic Enabler implementation (GEis)products are:

IoT Edge

Personal tools
Create a book