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.IoTDiscovery R3 - FIWARE Forge Wiki

FIWARE.OpenSpecification.IoT.Backend.IoTDiscovery R3

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.IoT.Backend.IoTDiscovery
Chapter IoT Services Enablement,
Catalogue-Link to Implementation Orion Context Broker, IoT-Discovery
Owner Telefonica I+D, UNIS, Fermín Galán, Tarek Elsaleh


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.


FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Copyright

Legal Notice

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

Overview

Data model outline

The Configuration Manager GE (ConfMan GE for short) is the part of the IoT Backend which is responsible for context availability registration. The underlying data model of this GE is based on the OMA NGSI9 Context Management Information Model. This model relies on the concept of context entities, which are generic entities whose state is described by the means of 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. Additionally - and more importantly -arbitrary physical objects (Things) like rooms, people, etc. and their attributes like temperature, geo-location, etc. can be used as well.

The ConfMan GE also optionally supports IoT descriptions that are semantically-annotated. The models chosen to represent the IoT Concepts is based on the IoT-A ontologies. They mainly describe an IoT Resource, a Virtual Entity and an IoT Service. When mapping to FIWARE IoT Concepts:

  • the IoT-A IoT Resource would map to the FIWARE IoT Resource.
  • the IoT-A Virtual Entity would map to the FIWARE IoT Thing.
  • the IoT-A Service would map to the FIWARE IoT Application Service.

Functionality outline

The ConfMan GE is in charge of context availability registrations from IoT Agents, thus becoming in the access point for information about entities and their attributes. In particular, the context availability information provided by the ConfMan GE is either forwarded from IoT Agents exporting the FI-WARE NGSI-9 interface. IoT Agents can be either 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.

Context availability information is typically forwarded to the FI-WARE Context Broker GE so that context information about Things becomes accessible to applications. However, note that the Context Broker GE may manage context availability information not necessarily provided by the ConfMan GE, therefore linked to the Internet of Things, but gathered from other parts of the application.

More precisely, using the FI-WARE NGSI-9 interface that the ConfMan 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 ConfMan GE is also specified to optionally support the registration, management and discovery of semantically-annotated IoT descriptions that are based on the IoT-A ontologies. The GE provides probabilistic and semantic search mechanisms for the discovery of IoT Descriptions that are stored in the configuration semantic repository of the GE.

Basic Concepts

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


Copyright

Legal Notice

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

Overview

Data model outline

The Configuration Manager GE (ConfMan GE for short) is the part of the IoT Backend which is responsible for context availability registration. The underlying data model of this GE is based on the OMA NGSI9 Context Management Information Model. This model relies on the concept of context entities, which are generic entities whose state is described by the means of 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. Additionally - and more importantly -arbitrary physical objects (Things) like rooms, people, etc. and their attributes like temperature, geo-location, etc. can be used as well.

The ConfMan GE also optionally supports IoT descriptions that are semantically-annotated. The models chosen to represent the IoT Concepts is based on the IoT-A ontologies. They mainly describe an IoT Resource, a Virtual Entity and an IoT Service. When mapping to FIWARE IoT Concepts:

  • the IoT-A IoT Resource would map to the FIWARE IoT Resource
  • the IoT-A Virtual Entity would map to the FIWARE IoT Thing
  • the IoT-A Service would map to the "providing application" endpoint where data can be retrieved for a FIWARE IoT Resource or Thing.

Functionality outline

The ConfMan GE is in charge of context availability registrations from IoT Agents, thus becoming in the access point for information about entities and their attributes. In particular, the context availability information provided by the ConfMan GE is either forwarded from IoT Agents exporting the FI-WARE NGSI-9 interface. IoT Agents can be either 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.

Context availability information is typically forwarded to the FI-WARE Context Broker GE so that context information about Things becomes accessible to applications. However, note that the Context Broker GE may manage context availability information not necessarily provided by the ConfMan GE, therefore linked to the Internet of Things, but gathered from other parts of the application.

More precisely, using the FI-WARE NGSI-9 interface that the ConfMan 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 ConfMan GE is also specified to optionally support the registration, management and discovery of semantically-annotated IoT descriptions that are based on the IoT-A ontologies. The GE provides probabilistic and semantic search mechanisms for the discovery of IoT Descriptions that are stored in the GE repository.

Basic Concepts

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


FI-WARE NGSI

The ConfMan GE implements the RESTful FI-WARE NGSI binding specification. FI-WARE NGSI Context Management specifications are based on the NGSI Context Management specifications defined by OMA (Open Mobile Alliance). They include two RESTful context management interfaces NGSI-9 and NGSI-10 (see Open RESTful API Specification), which 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.

ConfMan GE Architecture

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

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 NGSI-9 interface exposed by the Configuration Management.
  • Announce the availability of context information towards the Context 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 subsection. This repository is used to answer NGSI-9 request in the exposed interfaces described above.
  • Receive registrations from IoT Gateways and the Thing-level Adapter through the NGSI-9 southbound interface and store 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 a NGSI9 client send a 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.

With this approach, the ConfMan 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 specific sensors provide information about same car could be maintained only by the ConfMan GE.

Optional Features

There are some optional features which can provide more added-value and that could be included in the Generic Enabler ConfMan:

  • Geo-discovery supporting the usage of of geographic scopes in the operations "discoverContextAvailability" and "subscribeContextAvailability"
  • Semantic and Probabilistic Discovery using semantically-annotated descriptions and providing a set of search mechanisms for look-up and discovery

Additional Concepts

Associations in FI-WARE NGSI-9

ConfMan GE enables enhanced associations. See the following section in the IoT Broker GE Architecture page to have more information on this.

Main Interactions

The ConfMan 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 Context 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. There is also an interface between the IoT Broker GE and the ConfMan GE. In the following diagrams we abstract all these components using "NGSI9 Client".

Reception of RegisterContext operations from Agents

In order for their information on Things and/or Resources to be available at the Backend, IoT Agents (which play the role of "NGSI9 Client9") need to register their information to the ConfMan GE. This is done via the RegisterContext operation. Note that the registration can be performed at 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 Context Broker GE instance the registration is still stored in the ConfMan GE.

This sequence is used for both new registrations and registrations udpates.

File:NGSI9Register.png

Query Discover Availability

The entities that typically play the "NGSI9 Client" role in this case are the IoT Broker GE (when requesting context availability information to process NGSI10 query/updates) or any other NGSI application that wants to know the context availability associated with a given entity/attribute.

File:NGSI9Discover.png

Subscription to Context Availability

The entities that potentially could play the "NGSI9 Client" role are any application that needs to be aware of changes in context availability information. The "Subscribed App" could be the "NGSI9 Client itself".

File:NGSI9Subscribe.png

Notification

The entities that potentially could play the "NGSI9 Client" role are IoT Agents, while "Subscribed App" are applications subscribed to context availability information changed by the registration issued by the "NGSI0 Client" (we assume that such Subscribed Application are previously subscribed, as shown in the sequence diagram in previous section).

File:NGSI9Notify.png

Added-value (Optional) Features

The following sections describe additional features that a Configuration Manager may implement. However, they are not mandatory for a basic implementation of this GE.

Geo-discovery

As an optional feature, the Configuration Management GE supports the usage of geographic scopes in the operations discoverContextAvailability and subscribeContextAvailability. In particular, the geographic scopes defined under keyword SimpleGeoLocation in Appendix D of the OMA NGSI 9/10 specification[1] will be supported.


For specifying the geographic location of entities and/or context providers, a new type of registration metadata will be defined and implemented. The exact syntax and semantics of this metadata type is under discussion.

Reference [1]

Probabilistic and Semantic Discovery

Overview

This additional functionality is actually an optional component within the Configuration Manager GE targeted for:

  • Context Producers using semantic descriptions based on the IoT-A ontology models for IoT Description registration and management.
  • IoT Agents
  • Device Gateways
  • Context Consumers using SPARQL for discovering IoT Concepts.
  • Applications requiring Semantic Discovery of IoT Concepts.
  • Semantically-enabled GEs (Data/Context Chapter)

N.B: The term “Context” refers to descriptions based on concepts defined by IoT-A, which contains its identification, attributes and metadata about specificities concerning its Attributes.

This component, which has been materialized in the GE implementation "IoT Discovery", addresses the discovery of Internet of Things (IoT) Concepts, by providing a repository for IoT Context Producers to register their IoT Things, Resources, and Devices, using semantically-annotated Descriptions based on the IoT-A (Internet of Things Architecture) ontology models. In turn, it provides a set of search mechanisms for their look-up and discovery. One of the main goals of this component is to make use of semantic annotation in order to apply formal naming and relational conventions to the description of an IoT Concept, which is explicitly absent in NGSI-9/10.

The component makes use of the Sense2Web IoT Linked Data Platform baseline asset, which provides a repository for the CRUD (Create, Read, Update and Delete) management of Semantic IoT descriptions, that complies with the IoT-A ontology models. These descriptions are termed as the Advanced IoT Descriptions. Sense2Web also associates different IoT concept ontologies to domain data and other resources on the Web using Linked Open Data.

IoT Discovery Engine GE

Figure 5: Sense2Web Platform and NGSI-9 Server

New Interfaces Exposed

This additional component provides a set of interfaces a user can interact with. The first is a Web User Interface (UI) whereby a user can perform CRUD operations on the IoT Descriptions, and also query the IoT Descriptions as well. When registering or updating, a user can either upload an IoT Description or complete a form which is then sent to the server to be converted to RDF, and storing it in the RDF database. The second interface is a RESTful CRUD and SPARQL interface. This interface mainly supports M2M interactions. An application can also perform CRUD operations on the IoT descriptions in the repository, and query for a particular piece of information from the descriptions using SPARQL. The third interface allows users to query about an IoT description using keywords or templates that share the same structure as the IoT description. This type of query input is handled by the IoT Search Engine, which will search for the relevant query.

Main Concepts / Subcomponents

The main subcomponents for this component are the IoT Search Engine, which is a probabilistic search mechanism that is based on text analysis for indexing and searching, and the IoT Associations Engine which is a semantic search mechanism that is used to establish and maintain associations between IoT Concepts.

IoT Search Engine (Probabilistic)

Introduction

The IoT Search Engine is a component in the Configuration Management GE that uses machine learning (ML) techniques for resolving IoT Descriptions (whether XML or RDF). It uses unsupervised probabilistic ML techniques to group similar IoT Descriptions. Its purpose is to allow automated discovery, ranking and recommendation of IoT Descriptions. It provides an efficient mechanism for the search and discovery of registered IoT Descriptions by automatically clustering all the IoT Descriptions and hence allowing the IoT Search Engine to be scalable to large object repositories. It also automates the ranking of results in order of relevance.

Probabilistic Search - Basic Diagram

Figure 6: Probabilistic Search Overview

Training the Engine for Index Creation and Clustering

For the IoT Search Engine to effectively refine the searching process, it goes through several stages. First it involves a training process whereby all the Descriptions for each model type is retrieved from the repository. It will then extract "textual concepts" from the Descriptions using a parsing mechanism. The concepts are essentially the elements, attributes and values of a Description. The extracted textual concepts will then be used to create a "Document-term matrix", which is a mathematical matrix that is used to reflect the frequency of textual concepts in a particular IoT Description, whereby the rows represent the number of IoT Descriptions and the columns represent the numbers of concepts.


Concept Extraction

Figure 7: Concept Extraction


The next stage is another training process for clustering the IoT descriptions. The training involves a ML technique known as theLatent Dirichlet Allocation. The aim of this technique is to discover a hidden dimension behind the vector of concepts. This dimension essentially reflects a "topic" or "theme", which is shared by certain IoT Descriptions. The topic itself is modelled as Latent Factors, which allows any type of Descriptions to be represented in vector form, and hence making the search much more efficient compared to keeping them in text format. The model then associates the Latent Factors with the distribution of Concepts.


Latent Factor Extraction

Figure 8: Latent Factor Extraction

Once the second training process is done, the clusters are then created. The number of clusters created is based on the number of Latent Factors generated. The vector of Latent Factors that corresponds to an IoT Description is used to determine which Latent Factor best describes it.


Folding in new Descriptions

Figure 9: Folding in new Descriptions

After the training process, the IoT Search Engine becomes online and is ready to receive requests. During runtime, the repository is expected to receive more registrations of IoT Descriptions. When this occurs the IoT Search Engine will read the new IoT Description and "fold" it in to one of the clusters based in its probability of similarity with one of the Latent Factors in the vector.

Querying the Engine for Discovery

For discovery, a user can query the IoT Search Engine by providing a description template or a SPARQL query as the input to the search engine. The template should include concepts that are relevant to what the user is searching for. The search engine will then convert the query into Latent Factor vector- as done previously in the second training stage - and then match the query vector to the vector of Latent Factors that represents the IoT Descriptions stored in the repository. A query example is shown below.


Query Match

Figure 10: Query Match

A query about an Advanced Description is given in the form:

<?xml version="1.0"?>
 <rdf:RDF    
    <vm:VirtualEntity>
    <vm:hasDomainAttribute>
     <vm:DomainAttribute>
       <vm:hasAttributeType rdf:resource="http://purl.oclc.org/NET/ssnx/qu/quantity#humidity"/>
       <vm:hasAttributeName rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
       >humidity</vm:hasAttributeName>
     </vm:DomainAttribute>
   </vm:hasDomainAttribute>
   <vm:hasName rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
   >BA 38 01</vm:hasName>
   <vm:hasA rdf:resource="#HumidityAttributeBA38"/>
   <vm:hasType rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
   >http://www.surrey.ac.uk/ccsr/ontologies/LocationModel.owl#Room</vm:hasType>    
 </vm:VirtualEntity>
</rdf:RDF>


...whereby the query is asking for an Entity - in this case a room (38) - that has Humidity information about it.

The Search Engine does as follows:

  1. The query is converted to a vector of latent factors: {0.038, 0.916, 0.006, 0.006, 0.0, 0.006, 0.01, 0.008, 0.003, 0.0}
  2. After analysing the vector, the query belongs to latent factor #2 with the highest probability.
  3. Query is forwarded to the registry responsible for cluster #2 and query is matched within that cluster.
  4. The first five results obtained are:
  • Rank #1: 38_BA_01.owl with a score of 0.998479530076855
  • Rank #2: 44_BA_01.owl with a score of 0.998479530076855
  • Rank #3: 01_BA_02.owl with a score of 0.998479530076855
  • Rank #4: 37_BA_01.owl with a score of 0.998479530076855
  • Rank #5: 18_BA_02.owl with a score of 0.998479530076855

Once this is done, the respective IoT Descriptions are retrieved from the repository and returned to the user.

IoT Associations Engine (Semantic)

Introduction

The Association Engine (AE) is a component that establishes and maintains associations between IoT Advanced Descriptions such as Things/Entities and Resources, via a type of Advanced description known as a Service Description, which acts as the representative for interacting with a Resource. The associations are made based on spatial, temporal and thematic relativity:

  • Thematic (feature) match - using domain ontologies that capture an Entity's attributes and IoT Service's input/output parameter.
  • Spatial match - using either co-ordinate comparison between IoT Entities and Services for determining close proximity, or location ontologies that model logical locations with properties such as 'contains'
  • Temporal match - utilising temporal aspects of entities which have a temporal aspect, such as meeting rooms with the IoT Service's observation_schedule.
Association process

Figure 11: Association Process Overview

Creating the Associations

Formulation of associations utilises the IoT-A Entity and Service models (i.e. Advanced Descriptions). Dynamic association inference is maintained through rules that incrementally reason on theme, spatial aspects and time. At startup, the AE will retrieve from the database all the different types of Advanced Descriptions - Entities, and Services (N.B. Services represent Resources) - and processes them through an Association Engine for matching. The matching process first looks for similar themes between Entity Attributes and Service observation types, e.g. temperature, light intensity, acoustic level. It will then look for similar locations. Lastly in the matching process it will look for temporal availability of a Service. Once the matching process is done, the associations generated will then be stored, which can then be queried via SPARQL.


Association process

Figure 12: Association Mechanism

Querying for Associations

The association can then be queried by users via the SPARQL interface. In the query the predicate used to retrieve the association is "isAssociatedToService". This will return the URI of the IoT-A service description, which can then be retrieved by querying the IoT-A Service repository. It is this description that will provide access to contextual information (e.g. temperature reading) produced by the IoT-A Resource (e.g. temperature sensor).

Linking NGSI Entities to Advanced Descriptions

A Context Producer can link an NGSI Entity Description to an Advanced Description by adding a Context Attribute that provides the URI of the corresponding Advanced Description, when registering the NGSI Entity via the registerContextRequest operation. This requires the Advanced Description be registered beforehand.

New Interactions

Context Broker Semantic Extension (Data/Context Chapter)

The Sense2Web module may interact with the Semantic Extension of the Context Broker by acting as a repository for providing ontologies that are specifically related to the IoT. The Context Broker is able to query the repository via the SPARQL interface. Since the context broker receives ContextML and NGSI descriptions, the Context Broker needs to retrieve more information or metadata about the Entity in question. This can be done by linking the semantically-converted ContextML description to the IoT Descriptions stored in the Semantic Repository of the Sense2Web module. For example, if a ContextML description contains information about a room and its temperature value, then metadata with conventional naming about the room and temperature can be retrieved, e.g. room location, ambient entities, and temperature unit. The issue with only using NGSI to provide this information is that NGSI does not provide a convention for any defined entity and its attributes.


FIWARE.OpenSpecification.Details.IoT.Backend.Confman


Re-utilised Technologies/Specifications

The IoT Discovery GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1 (RFC2616)
  • XML/JSON 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 FIWARE 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