FI-WARE architecture view. Figure 5 shows the IoT architecture as defined by the FI-WARE project. This architecture has already taken into account the ETSI M2M specification and has extended it to incorporate OMA NGSI work [9]. The following large functional blocks can be identified in this architecture: backend, Gateway, IoT devices and legacy devices. The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of devices, several Gateways and the backend. The Generic Enablers shown in the figure below implement functionalities distributed across these elements. The backend functional block provides a number of functions and acts as the main interfaces to access the IoT devices and the information they produce. It provides both REST and NGSI interfaces for interaction with the users as well as corresponding functions like things and resources management; publish/subscribe functionality and connectivity management. The backend can be connected southbound to Gateways and/or IoT compliant devices (devices that will implement the standardised interface i.e. ETSI M2M). Backend consists of three main GEs, namely IoT Broker, Configuration Management and Backend Device Management. The IoT Broker GE is a component for retrieving and aggregating information from the Internet of Things. The Configuration Manager GE (ConfMan GE for short) is the part of the IoT Backend which is responsible for context availability registration. The Backend Device Management GE is the central component for the IoT backend. It provides the resource-level management of remote assets (devices with sensors and/or actuators) as well as core communication capabilities such as basic IP connectivity and management of disconnected devices. The Gateway provides similar functionality, but on the local level, i.e. it provides functions like things and resource management for the IoT and legacy devices connected to the Gateway. It consists of three GEs, namely Data Handling, Gateway Device Management and Protocol Adapter. The Gateway Device Management GE contains much of the "core" Gateway functionality. It is responsible for the communication with the Backend and IoT and non-IoT devices. The Gateway Device Management GE includes the functional components to handle the registration/connection phases towards the Backend/Platform, to translate the incoming data or messages in an internal format and to send the outgoing data or messages in the ETSI M2M format (marshal/unmarshal). The Data Handling GE addresses the need of filtering, aggregating and merging real-time data from different sources. The Protocol Adapter GE deals with the incoming and outgoing traffic and messages between the Gateway and Devices registered, to be served by the Gateway towards the Gateway Device Management GE or the Data Handling GE. The Protocol Adapter GE translates device specific protocols into a uniform internal API. IoT devices can be connected to a Gateway (e.g. IPv4-based devices with private addresses) or directly to the backend (e.g. IPv6-based devices with public addresses). Legacy devices are always connected via a Gateway. The FI-WARE IoT platform provides two fundamental entry points, namely at the application and at the IoT resource level. The application level interface is based on the Next Generation Services Interface (NGSI) specified by Open Mobile Alliance (OMA) [37]. They take the form of a RESTful binding specification of the two interfaces defined in the OMA NGSI Context Management specifications, namely NGSI-9 and NGSI-10. The central aspect of the NGSI-9/10 information model is the concept of entities. Entities are the virtual representation of all kinds of physical objects in the real world. Examples for physical entities are tables, rooms, or persons. Virtual entities have an identifier and a type. For example, a virtual entity representing a person named “▇▇▇▇” could have the identifier “▇▇▇▇” and the type “person” [38]. The entities have their attributes and attribute domains when more attributes are grouped together. Exchange of entity information is performed with context elements which contain information about multiple attributes of one entity. The three main interaction types are allowed and these are: • One-time queries for context information • Subscriptions for context information updates (and the corresponding notifications) • Unsolicited updates (invoked by context providers)
Appears in 1 contract
Sources: Grant Agreement
FI-WARE architecture view. Figure 5 shows the IoT architecture as defined by the FI-WARE project. This architecture has already taken into account the ETSI M2M specification and has extended it to incorporate OMA NGSI work [9]. The following large functional blocks can be identified in this architecture: backend, Gateway, IoT devices and legacy devices. The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of devices, several Gateways and the backend. The Generic Enablers shown in the figure below implement functionalities distributed across these elements. The backend functional block provides a number of functions and acts as the main interfaces to access the IoT devices and the information they produce. It provides both REST and NGSI interfaces for interaction with the users as well as corresponding functions like things and resources management; publish/subscribe functionality and connectivity management. The backend can be connected southbound to Gateways and/or IoT compliant devices (devices that will implement the standardised interface i.e. ETSI M2M). Backend consists of three main GEs, namely IoT Broker, Configuration Management and Backend Device Management. The IoT Broker GE is a component for retrieving and aggregating information from the Internet of Things. The Configuration Manager GE (ConfMan GE for short) is the part of the IoT Backend which is responsible for context availability registration. The Backend Device Management GE is the central component for the IoT backend. It provides the resource-level management of remote assets (devices with sensors and/or actuators) as well as core communication capabilities such as basic IP connectivity and management of disconnected devices. The Gateway provides similar functionality, but on the local level, i.e. it provides functions like things and resource management for the IoT and legacy devices connected to the Gateway. It consists of three GEs, namely Data Handling, Gateway Device Management and Protocol Adapter. The Gateway Device Management GE contains much of the "core" Gateway functionality. It is responsible for the communication with the Backend and IoT and non-IoT devices. The Gateway Device Management GE includes the functional components to handle the registration/connection phases towards the Backend/Platform, to translate the incoming data or messages in an internal format and to send the outgoing data or messages in the ETSI M2M format (marshal/unmarshal). The Data Handling GE addresses the need of filtering, aggregating and merging real-time data from different sources. The Protocol Adapter GE deals with the incoming and outgoing traffic and messages between the Gateway and Devices registered, to be served by the Gateway towards the Gateway Device Management GE or the Data Handling GE. The Protocol Adapter GE translates device specific protocols into a uniform internal API. IoT devices can be connected to a Gateway (e.g. IPv4-based devices with private addresses) or directly to the backend (e.g. IPv6-based devices with public addresses). Legacy devices are always connected via a Gateway. The FI-WARE IoT platform provides two fundamental entry points, namely at the application and at the IoT resource level. The application level interface is based on the Next Generation Services Interface (NGSI) specified by Open Mobile Alliance (OMA) [37]. They take the form of a RESTful binding specification of the two interfaces defined in the OMA NGSI Context Management specifications, namely NGSI-9 and NGSI-10. The central aspect of the NGSI-9/10 information model is the concept of entities. Entities are the virtual representation of all kinds of physical objects in the real world. Examples for physical entities are tables, rooms, or persons. Virtual entities have an identifier and a type. For example, a virtual entity representing a person named “▇▇▇▇” could have the identifier “▇▇▇▇” and the type “person” [38]. The entities have their attributes and attribute domains when more attributes are grouped together. Exchange of entity information is performed with context elements which contain information about multiple attributes of one entity. The three main interaction types are allowed and these are: • One-time queries for context information • Subscriptions for context information updates (and the corresponding notifications) • Unsolicited updates (invoked by context providers).
Appears in 1 contract
Sources: Grant Agreement