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
FIWARE.OpenSpecification.IoT.Backend.ThingsManagement - FIWARE Forge Wiki

FIWARE.OpenSpecification.IoT.Backend.ThingsManagement

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.IoT.Backend.ThingsManagement
Chapter IoT Services Enablement,
Catalogue-Link to Implementation Backend Things Management
Owner NEC, Telefonica I+D, Tobias Jacobs


Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.


Overview

Data model outline

The IoT Things Management GE (TM GE for short) is the part of the IoT Backend which is responsible for Thing-level interaction. The underlying data model of this GE is based on the OMA NGSI Context Management Information Model which relies on the concept of context entities, which are generic entities whose state is described based on values of attributes and associated metadata. In the context of IoT, context entities and context entity attributes can be used to model IoT resources and the variables they measure, respectively, but also - and more importantly - arbitrary physical objects (Things) like rooms, persons, etc. and their attributes like temperature, geo-location, etc.

Functionality outline

The TM GE is the point of contact for accessing information about entities and their attributes. The northbound interface supports one-time queries and continuous subscriptions for that kind of context information. Applications or other GEs can further receive unsolicited information updates from the TM GE about both the availability of context information and actual context information. In the FI-WARE architecture, the Publish/Subscribe Broker GE takes the role of the Application consuming context information from the TM GE.

Using the FI-WARE NGSI-9 interface that the TM GE provides, applications will be able to register, query for and subscribe to updates on context availability information, that is:

● Information about IoT resources and the variables they measure

● Information about Things and their attributes

● Information about Associations establishing how attributes of Things can be derived from attributes of other Things or from variables measured by IoT resources

The TM GE implements the subset of the FI-WARE NGSI interfaces required to support integration with the FI-WARE Publish/Subscribe Broker GE so that context information about Things becomes accessible to applications. Actually, using the FI-WARE NGSI-10 interface that the Publish/Subscribe Broker GE provides, applications will be able to:

● Query about attributes of Things

● Subscribe about updates on attributes of Things

Note that the Publish/Subscribe Broker GE may manage context information not necessarily provided by the TM GE, therefore linked to the Internet of Things, but gathered from other parts of the application.

The context information and context availability information provided by the TM GE is either (a) forwarded from IoT Agents exporting FI-WARE NGSI interfaces, or (b) derived from lower-level context information inside the TM GE. In case (a), IoT Agents can be both the Data Handling GE in IoT Gateways, or the Backend Device Management GE. It is also possible that the context information is provided by other IoT Backend systems. In case (b), the TM GE applies basic mapping rules derived from associations registered through the FI-WARE NGSI-9 interface that the TM GE exports. It may also apply more complex rules based on inference engine capabilities it will support.


Things Management GE and the interacting components

Basic Concepts

The Things Management GE is based on the OMA NGSI context data model.

FI-WARE NGSI

The TM GE the FI-WARE NGSI Context Management specifications (FI-WARE NGSI specifications for short).

FI-WARE NGSI Context Management specifications are based on the NGSI Context Management specifications defined by OMA (Open Mobile Alliance). They take the form of a RESTful binding specification of the two context management interfaces defined in the OMA NGSI Context Management specifications, namely NGSI-9 and NGSI-10 (see FI-WARE NGSI Open RESTful API Specification (PRELIMINARY)).They also solve some ambiguities in the OMA specs and extend them when necessary to implement the FI-WARE Vision.

You can visit the FI-WARE NGSI Context Management tutorial to learn the main concepts underlying FI-WARE NGSI Context Management specifications.

Associations in FI-WARE NGSI-9

Background

OMA NGSI-9 is an interface for exchanging information on the availability of context information. The central information container of NGSI-9 is a data structure called ContextRegistration. Each ContextRegistration instance contains a list of entities, a list of attributes, the URI of an application where context information about these entities/attributes is available, and a list of metadata.

In NGSI-9 is implicitly assumed that the providing application exposes an NGSI-10 interface, where the context information can be queried. It is also implicitly assumed that the context information is provided using the same entity/attribute combinations. For example, a ContextRegistration instance containing the entity "Car_2", attribute "speed", and URI "http://cars.info" represents the information that the speed of "Car_2" can be queried at "http://cars.info" by an NGSI-10 queryContext operation asking for attribute "speed" of entity "Car_2".

Enhanced Associations

In the following paragraphs we describe a generalization of this principle. We introduce a special type of metadata which modifies the query that has to be invoked at the providing application in order to obtain the desired information. In NGSI, each piece of metadata has a name, a type and a value. The metadata introduced at this point has name "knownAs" and type "QueryContextRequest". The metadata value represents the necessary query message for the providing application: When invoking the query context operation on the providing application using this message, the returned result will be the context information described in the ContextRegistration structure.

Before formally defining this special type of ContextRegistration instances, let us walk through an example. Assume that a ContextRegistration contains one entity ID "Car_2", one attribute "speed", providingApplication is "http://cars.info", an there is a piece of metadata as described above. The metadata value is an instance of QueryContextRequest which contains one entityId "speedometer_38" and one attribute "measurement". The information described by the ContextRegistration instance just described is as follows: in order to find out the speed of Car_2, one has to go to "http://cars.info" and query for the "measurement" of "speedometer_38".

An instance of ContextRegistration as the one just described is called an Association. Formally, a ContextRegistration instance is an Association, if

  • It contains exactly one entity ID and exactly one attribute. This attribute is not a domain name, and the entity ID is no pattern.
  • It contains a piece of metadata with name "knownAs" and type "QueryContextRequest".
  • The value of the "knownAs" metadata is an instance of QueryContextRequest which contains exactly one entity ID and one attribute. The entity ID is no pattern, and the attribute is no domain.

TM GE Architecture

This section describes the internal architecture of the FI-WARE TM GE implementation.

IoT TM GE internal architecture

The main components of the TM GE are described in the following sections.

IoT Broker

The IoT Broker is the point of contact for accessing Thing-level information via the northbound NGSI-10 interface.

When requests arrive through this interface, the IoT Broker first discovers the IoT resources that can provide the required information. The discovery is typically realized by interacting with the Configuration Management via the NGSI-9 interface. Following the discovery, the IoT Broker queries the discovered information sources through its southbound NGSI-10 interface.. In the FI-WARE Architecture, these information sources are Data Handling GE instances on IoT Gateways or the information of interest is provided by the Backend Device Management GE. Subscriptions through the northbound interface are handled similarly.

The IoT Broker can also receive NGSI-10 updates via the southbound interface. In this case, the received information is forwarded through the northbound interface to a fixed information sink. In the FI-WARE architecture, this information sink is the Publish/Subscribe Broker GE.

Configuration Management

The Configuration Management component implements a context information registry in which context provider applications can be registered. In addition, components interacting with the Configuration Management can perform discovery operations on that context registration information or subscribe to changes on it.

It detail, the component provides the following functionality;

● Allow IoT Broker discovery and subscription of context information, through the internal NGSI-9 interface exposed by the Configuration Management..

● Announcing the availability of context information in the towards the Publish/Subscribe Broker GE (or any other component supporting the NGSI-9 interface) through the northbound NGSI-9 interface.

The Configuration Management component stores the context information in a Configuration Repository described in next section. This repository is used to answer NGSI-9 request in the exposed interfaces described above.

Receiving registrations from IoT Gateways and the Thing-level Adapter through the NGSI-9 southbound interface and storing this information in the Configuration Repository , thus updating the context information registry.

Configuration Repository

The Configuration Repository stores information on the availability of context information and can be accessed through the Configuration Management. When the IoT Broker receives a context query, its first step is to use the queryContextAvailability operation on the Configuration Management in order to find out where the desired context information can be found. The Configuration Management returns a number of ContextRegistration instances, which can possibly be associations.

By this approach, the TM GE can maintain higher-level context information that is not available in the IoT Gateways or Devices. For example, a Gateway might not know the concept of cars, but only maintains a list of sensors and their measurements. The information about which sensors provides information about which car could be maintained only by the TM GE (moreover, the relationship between sensors and cars could have been automatically derived by the Discovery Engine component described in next section). Still taking as example the cars, when an application queries the status of a certain car, the TM GE determines what sensors provide that information, queries those sensors' measurements, and returns the measured values to the application.

Discovery Engine (PRELIMINARY)

The discovery engine is a component that makes use of machine learning (ML) techniques for resolving object descriptions, whereby objects can refer to Things or Resources. The component uses probabilistic ML techniques to group objects with similar descriptions. Its purpose is to allow automated discovery, ranking and recommendation of objects. The probabilistic machine-learning approach is completely unsupervised. It provides an efficient mechanism for publication and discovery by: · Automatically clustering all the object descriptions within a repository, hence allowing the Discovery Engine to be scalable to large object repositories. · And automating the ranking of results in order of relevance. It is also Interoperable between different types of description technologies as it bases its technique on text analysis, as long as wrappers are provided for a particular description format. With regards to the Discovery Engine’s role in the Things Management GE, it will first retrieve available NGSI-9 descriptions from the repository, which in this case is the Configuration Repository. The Discovery Engine will use the NGSI-9 descriptions to extract the link for a semantic description of the object. This is description is termed as the Advanced Description. The Advanced Description is essentially an RDF description based on W3C SSN and IoT-A IoT models. It will be used for extracting semantic concepts which will be used for training the engine. The discovery engine will also host a repository based on the “Linked IoT Data Platform” for storing the Advanced Descriptions. The Advanced Description will also enable the dynamic binding of spatial, temporal, and thematic associations between Things and Resources.

When upon startup, there are no descriptions; the Discovery Engine will wait until an acceptable number of descriptions have been stored in order to start the training process and defining the clusters. In the case when discovery requests are received by the Configuration Management from the IoT Broker via NGSI-9, the request can be forwarded to the discovery engine to provide a recommended, ranked set of results, especially in the case where a request providing an ID/attribute is not exactly matched with the descriptions in the repository.

Geo-Discovery (PRELIMINARY)

Geo-Discovery is an optional component which is specialized to perform fast and robust discovery of all entities (possibly of a certain type) within given geographic scopes. To this end it communicates with the IoT Broker and/or the Configuration Management. Details are still under discussion.

Additional Concepts

Enhanced Associations by OMA NGSI-9

Background

OMA NGSI-9 Normal 0 21 false false false FR ZH-CN AR-SA

is an interface for exchanging information on the availability of context information. The central information container of NGSI 9 is a data structure called ContextRegistration. Each ContextRegistration instance contains a list of entities, a list of attributes, the URI of an application where context information about these entities/attributes is available, and a list of metadata.

In NGSI-9 is implicitly assumed that the providing application exposes an NGSI-10 interface, where the context information can be queried. It is also implicitly assumed that the context information is provided using the same entity/attribute combinations. For example, a ContextRegistration instance containing the entity "Car_2", attribute "speed", and URI "http://cars.info" Normal 0 21 false false false FR ZH-CN AR-SA represents the information that the speed of "Car_2" can be queried at Normal 0 21 false false false FR ZH-CN AR-SA "http://cars.info" by an NGSI-10 queryContext operation asking for attribute "speed" of entity "Car_2". .

Enhanced Associations

In the following paragraphs we describe a generalization of this principle. We introduce a special type of metadata which modifies the query that has to be invoked at the providing application in order to obtain the desired information. In NGSI, each piece of metadata has a name, a type and a value. The metadata introduced at this point has name "knownAs" and type "QueryContextRequest". The metadata value represents the necessary query message for the providing application: When invoking the query context operation on the providing application using this message, the returned result will be the context information described in the ContextRegistration structure.

Before formally defining this special type of ContextRegistration instances, let us walk through an example. Assume that a ContextRegistration contains one entity ID "Car_2", one attribute "speed", providingApplication is "http://cars.info", an there is a piece of metadata as described above. The metadata value is an instance of QueryContextRequest which contains one entityId "speedometer_38" and one attribute "measurement". The information described by the ContextRegistration instance just described is as follows: in order to find out the speed of Car_2, one has to go to "http://cars.info" and query for the "measurement" of "speedometer_38".

An instance of ContextRegistration as the one just described is called an Association. Formally, a ContextRegistration instance is an Association, if

● It contains exactly one entity ID and exactly one attribute. This attribute is not a domain name, and the entity ID is no pattern.

● It contains a piece of metadata with name "knownAs" and type "QueryContextRequest".

● The value of the "knownAs" metadata is an instance of QueryContextRequest which contains exactly one entity ID and one attribute. The entity ID is no pattern, and the attribute is no domain.

Usage in the IoT TM GE

The Configuration Repository stores information on the availability of context information and is made accessible via the Configuration Management. When the IoT Broker receives a context query, its first step is to use the queryContextAvailability operation on the Configuration Management in order to find out where the desired context information can be found. The Configuration Management returns a number of ContextRegistration instances, which can possibly be associations.

By this approach, the TM GE can maintain higher-level context information that is not available in the IoT Gateways or Devices. For example, a Gateway might not know the concept of cars, but only maintains a list of sensors and their measurements. The information about which of the sensors provides information about which car could be maintained only in the backend, automatically derived by the Discovery Engine. When applications query the status of a certain car, the TM GE will find determine the sensors providing that information and, query for these sensors' measurements, and return the measured values to the application.

More examples of how associations are used can be found below .

Main Interactions

The TM GE has a number of interfaces for interacting with applications, users, and other GEs of the FI-WARE architecture. In that context, the GE communicates with the Publish/Subscribe Broker GE via the Northbound Interface and with the IoT Agents on the Southbound Interface. The role of IoT Agent can be played by either the Backend Device Management GE, or by the Gateway Data Handling GE.

Reception of RegisterContext operations from Agents

In order for their information on Things and/or Resources to be available at the Backend, IoT Agents need to register their information to the TM GE. This is done via the RegisterContext operation. Note that the registration can be performed on various levels of granularity: registering specific Entity/Attribute combinations, registering that information about certain entity type is available, or even in general registering that some entity information is available (without getting more specific) are all possible registrations. Also note that in absence of a Publish/Subscribe GE instance the registration is still stored in the TM GE. File:registration.jpg

Query Handling

Queries are one-time requests for information. They are realized by the queryContext operation of OMA NGSI-10. File:Query.jpg

Subscription Handling

Subscriptions are requests for information updates the issuer wishes to receive under conditions that have to be specified in the request message. The picture below shows the interaction diagram for the OMA NGSI-10 subscribeContext operation, but the same interaction pattern applies to the updateContextSubscription and unsubscribeContext operations. File:Subscription.jpg

Notification

Notifications are the counterpart of subscriptions. A notification is sent whenever the condition for it (that has been specified in the subscription) is satisfied. File:Notification.jpg


Detailed Open Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications

The Things Management GE has a number of Interfaces, each of which implements a subset of the FI-WARE binding of OMA NGSI-9 or OMA NGSI-10. In particular:

Other Open Specifications

N/A


Re-utilised Technologies/Specifications

The Backend Things Management GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1 (RFC2616)
  • XML data serialization format.

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Thing. One instance of a physical object, living organism, person or concept interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Examples of physical objects are: building, table, bridge (classes), the Kreml, the tennis table from John’s garden, the Tower bridge (instances). Examples of living organisms are: frog, tree, person (classes), the green frog from the garden, the oak tree in front of this building, Dr. Green.
  • Class of thing. Defines the type of a thing in the style of object-oriented programming: a construct that is used as a blueprint to create instances, defining constituent members which enable class instances to have state and behavior. An example of class of thing is “person”, whereas an instance of a thing is “Dr. Green”, with all the static/dynamically changing properties of this particular person.
  • Group of things. A physical/logical group of things. Examples are all office buildings from Munich, all bridges above the Thames, all screws from a drawer, the planes of Lufthansa currently above Germany, all cars inside a traffic jam driven by a female driver, the trees from the Amazonian forest, the squids from the Mediterranean see the mushrooms from Alice’s garden, all the fish from the aquarium of John., the soccer team of Manchester, the colleagues from OrangeLabs currently working abroad (from the perspective of France), all patients above 60 years of age of Dr. Green, the traffic jams from Budapest, the wheat crop in France in the year 2011, the Research and Development Department of the company Telefónica.
  • Device. Hardware entity, component or system that may be in a relationship with a thing or a group of things called association. A device has the means either to measure properties of a thing/group of things and convert it to an analog or digital signal that can be read by a program or user or to potentially influence the properties of a thing/group of things or both to measure/influence. In case when it can only measure the properties, then we call it a sensor. In case when it can potentially influence the properties of a thing, we call it an actuator. Sensors and actuators may be elementary or composed from a set of elementary sensors/actuators. The simplest elementary sensor is a piece of hardware measuring a simple quantity, such as speed of the wind, and displaying it in a mechanical fashion. Sensors may be the combination of software and hardware components, such as a vehicle on-board unit, that consists of simple sensors measuring various quantities such as the speed of the car, fuel consumption etc and a wireless module transmitting the measurement result to an application platform. The simplest elementary actuator is a light switch. We have emphasized potentially because as a result of the light switch being switched on it is not sure that the effect will be that light bulb goes on: only an associated sensor will be able to determine whether it went on or not. Other examples of devices are smart meters, mobile POS devices. More sophisticated devices may have a unique identifier, embedded computing capabilities and local data storage utilities, as well as embedded communication capabilities over short and/or long distances to communicate with IoT backend. Simple devices may not have all these capabilities and they can for instance only disclose the measurement results via mechanical means. In this latter case the further disclosure of the measurement result towards IoT backend requires another kind of device, called IoT Gateway.
  • Association. It is a physical/logical relationship between a device and a thing or a device and a group of things or a group of devices and a group of things from the perspective of a FI-WARE instance, an application within a usage area project or other stakeholder. A device is associated with a thing if it can sense or (potentially) influence at least one property of the thing, property capturing an aspect of the thing interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Devices are associated with things in fully dynamic or mainly static or fully static manner. The association may have several different embodiments: physical attachment, physical embedding, physical neighborhood, logical relation etc. Physical attachment means that the device is physically attached to the thing in order to monitor and interact with it, enabling the thing to be connected to the Internet. An example is the on-board device installed inside the vehicle to allow sending sensor data from the car to the FI-WARE instances. Physical embedding means that the device is deeply built inside the thing or almost part of the thing. An example of physical embedding is the GPS sensor inside a mobile phone. Physical neighborhood means that the device is in the physical neighborhood of the thing, but not in physical contact with it. An example of physical neighborhood is the association of the mobile phone of a subscriber who is caught in a traffic jam with the traffic jam itself: the mobile phone is the device, the traffic jam is the thing and the association means that the mobile phone is in the physical neighborhood of the area inside which the traffic jam is constrained (e.g. within 100 m from the region where the average speed of cars is below 5 km/h). Logical association means that there is a relationship between the device and the thing which is neither fully physical in the sense of attachment or embedding, nor fully physical proximity related. An example of logical association is between the car and the garage door opener of the garage where the car usually parks during the night.
  • IoT gateway. A device that additionally to or instead of sensing/actuating provides inter-networking and protocol conversion functionalities between devices and IoT backend potentially in any combination of these hosts a number of features of one or several Generic Enablers of the IoT Service Enablement. It is usually located at proximity of the devices to be connected. An example of an IoT gateway is a home gateway that may represent an aggregation point for all the sensors/actuators inside a smart home. The IoT gateway will support all the IoT backend features, taking into consideration the local constraints of devices such as the available computing, power, storage and energy consumption. The level of functional split between the IoT backend and the IoT gateway will also depend on the available resources on the IoT gateway, the cost and quality of connectivity and the desired level for the distribution of intelligence and service abstraction.
  • IoT resource. Computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. There may be one-to-one or one-to-many relationship between a device and its IoT resource. Actuation capabilities exposed by the IoT resource may comprise configuration of the management/application features of the device, such as connectivity, access control, information, while sensing may comprise the gathering of faults, performance metrics, accounting/administration data from the device, as well as application data about the properties of the thing with which the device is associated. The resource is usually hosted on the device.
  • Management service. It is the feature of the IoT resource providing programmatic access to readable and/or writable data belonging to the functioning of the device, comprising a subset of the FCAPS categories, that is, configuration management, fault management, accounting /access management/administration, performance management/provisioning and security management. The extent of the subset depends on the usage area. Example of configuration management data is the IP endpoint of the IoT backend instance to which the device communicates. Example of fault management is an error given as a result of the overheating of the device because of extensive exposure to the sun. Example of accounting/administration is setting the link quota for applications using data from a certain sensor. Example of security management is the provisioning of a list of device ID-s of peer devices with which the device may directly communicate.
  • Application service. It is the feature of the IoT resource providing programmatic access to readable or writable data in connection with the thing which is associated with the device hosting the resource. The application service exchanges application data with another device (including IoT gateway) and/or the IoT backend. Measured sensory data are example of application data flowing from devices to sensors. Setting the steering angle of a security camera or sending a “start wetting” command to the irrigation system are examples of application data flowing from the application towards the sensor.
  • Event. An event can be defined as an activity that happens, occurs in a device, gateway, IoT backend or is created by a software component inside the IoT service enablement. The digital representation of this activity in a device, IoT resource, IoT gateway or IoT backend instance, or more generally, in a FI-WARE instance, is also called an event. Events may be simple and complex. A simple event is an event that is not an abstraction or composition of other events. An example of a simple event is that “smart meter X got broken”. A complex event is an abstraction of other events called member events. For example a stock market crash or a cellular network blackout is an abstraction denoting many thousand of member events. In many cases a complex event references the set of its members, the implication being that the event contains a reference. For example, the cellular network blackout may be caused by a power failure of the air conditioning in the operator’s data center. In other cases such a reference may not exist. For example there is no accepted agreement as to which events are members of a stock market crash complex event. Complex events may be created of simple events or other complex events by an IoT resource or the IoT backend instance.
  • IoT Backend. Provides management functionalities for the devices and IoT domain-specific support for the applications. Integrant component of FI-WARE instances.
  • IoT application. An application that uses the application programming interface of the IoT service enablement component. May have parts running on one/set of devices, one/set of IoT gateways and one/set of IoT backends.
  • Virtual thing. It is the digital representation of a thing inside the IoT service enablement component. Consists of a set of properties which are interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Classes of things have the same set of properties, only the value of the properties change from instance to instance.
Personal tools
Create a book