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

FIWARE.OpenSpecification.IoT.Backend.DeviceManagement R3

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.IoT.Backend.DeviceManagement
Chapter IoT Services Enablement,
Catalogue-Link to Implementation [<not yet available> <not yet available>]
Owner Telefonica I+D, Juanjo Hierro


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

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.

Main Components

Inventory Manager

Backend applications will want to maintain an inventory of connected M2M devices and their relationship to remote assets (such as rooms, cars or machinery). The Inventory Manager provides the basic business logic for this task allowing the access to data of remote sensors.

Each managed object in the inventory has an own, "global" identifier that is synthetically generated by the Inventory Manager when the object is created. This identifier can be used to reliably reference the object, regardless of, for example, restructuring of networks or replacement of hardware parts.

Inventory

The Inventory component allows:

  • Access data of remote sensors and use remote controls independent of device manufacturer, but still capture manufacturer-specific data where required.
  • Capture application- or vertical-specific data.
  • Capture tenant-specific data.

This is facilitated through Managed Objects and Fragments. The Inventory component consists of subcomponents for capturing device information, events, readings, alarms.

Device Information

The Device Information stores devices and other assets or business objects known to the Backend Device Management GE, referred to as Managed Objects. Each managed object in the inventory has an own "global" identifier that is synthetically generated by the Backend Device Management GE when the object is created. This identifier can be used to reliably reference the object, regardless of, for example, restructuring of networks or replacement of hardware parts.

Events

Events are used to pass real-time information. Three types of events are distinguished: base events, alarm signals and audit records. A base event signals when something happens. An event could, for example, be sent when a switch is switched on or off. An alarm signals an event that requires action, for example, when a meter has been tampered with or the temperature of a fridge increases above a particular threshold. An audit record stores events that are security relevant and should be stored for auditing. For example, an audit log should be generated when a user logs into a gateway.

Measurements

Measurements represent regularly acquired readings and statistics from sensors. Measurements consist of a timestamp (when the measurement was taken) and the unique identifiers of the source of the measurement.

Device Control

Devices need to be remote controlled and managed. The main scenarios are the following:

  • Device control: Setting a switch, regulating a heating control.
  • Device configuration: Setting a tariff table in a smart meter.
  • Device operation: Requesting a home security camera to take a picture.
  • Device maintenance: Uploading a new firmware binary.

These use cases are implemented by the Device Control component via sending operations to the devices.

Device Communication Handling

To shield the backend applications from the diversity of IoT protocols, parameters and network connectivity options, the Backend Device Management GE uses the so-called agents or plug-ins at the Device Communication Handling level. An agent is a function that fulfills three responsibilities for a given vendor and type of devices:

Protocol translation Configuration parameters, readings, events and other information are either send to an agent ("push") or queried by the agent ("poll") through a device-specific protocol. The agent will convert these messages into the protocol that the Backend Device Management GE understands. It will also receive device control commands from the GE ("switch off that relay") and translate these to whatever protocol the device understands. The Backend Device Management GE uses a simple and secure reference protocol based on REST (i.e., HTTP) and JSON, which can be used from a wide variety of programming environments down to small embedded systems. To support near-real-time scenarios, the protocol is designed around a "push" model, i.e., data is sent as soon as it is available.


Model transformation Configuration parameters, readings and events. All have their device-specific name (and possibly units). An agent for a particular device will transform this device-specific model to the reference model. For example, an electricity meter may provide the main reading as a parameter "Received Wh", so the agent will transform this reading into a reference "Total active energy" in kWh.

Secure remote communication Devices may provide a protocol that is unsuitable for secure remote communication, in particular in public cloud environments. The protocol may only support local networking, it may not pass through firewalls and proxies and it may carry sensitive data over clear text. To overcome such situations, an agent can be co-located to the device and provide a secure, internet-enabled link to the remote device.

Administration

The Administration component is a set of REST-based admin interfaces responsible for Tenant (or M2M service framework), Application and User Management.

Tenant Management

The Backend Device Management GE supports multiple tenants. Several enterprises, or tenants, share the same instance of the GE. Each tenant has:

  • A dedicated URL for accessing the instance.
  • An own user database storing the tenant's users and their passwords.
  • A dedicated storage area keeping the data that is received from the tenant's devices and that is entered by the tenant users. This storage area is, by default, invisible to other tenants on the same instance.
  • A set of subscribed backend applications that the tenant can use.

Application Management

The usage of applications directly connected to the backend will typically be a paid service that tenants subscribe to. Hence, these applications are registered with the Backend Device Management GE. This allows the Backend Device Management GE to check subscriptions, make the applications visible in the user interface, monitor them and possibly charge on usage base.

User Management

The Backend Device Management GE uses a standard authentication and authorization model based on realms, users, user groups and authorities. A realm is a database of users and user groups that follow the same authentication and authorization policy. A user is a person or an external system entitled to access protected resources in the GE. Access is controlled through permissions, or authorities.

The Backend Device Management GE creates a new realm for each tenant to store the users of that tenant. Realms provide own name space for user names, allowing users to keep the names that they are familiar with from their own enterprise IT or other IT systems. There is no conflict between user names – a user "smith" of one particular tenant is different from a user "smith" of another tenant. Each new realm is automatically populated with an initial administrator user who can create further users and user groups, and who can assign permissions to these users and user groups.

Restful API Framework

The Backend Device Management GE provides a set of REST interfaces for the applications.

Basic Concepts

The Backend Device Management GE is based on the usage of the following protocols: FI-WARE NGSI and ETSI M2M.

FI-WARE NGSI

ETSI M2M

Main Interactions

The following picture depicts the interaction model of the Backend Device Management GE.



While the diagram showed in the previous section is more a functional one, the one right above shows the actual architecture as a set of assets, components, interfaces and APIs of the Backend Device Management GE.


Application M2M Service Creation

The first operational step of the BE Device Management GE is to create one (or more) M2M service framework. This M2M service will hold afterwards a number of devices to communicate with. For this purpose, Applications or end users will access the ADMINISTRATION REST API and create an M2M service.

Device Register

Once an M2M service has been created by an end-user, devices are able to register into that specific framework by sending a request to the SensorML COMMUNICATION REST API of the Backend Device Management GE.

Device Observation

Once a device is registered into an existing M2M service, it may send periodic or standalone observations (i.e. sensor readings) by sending requests to the SensorML COMMUNICATION REST API at the BE Device Management GE.

Application Subscription Service

Applications are able to subscribe to device notification events in two ways:

  • Subscription to specific devices within a M2M service.
  • Subscription to all devices within a M2M service.

The subscription is realized by sending the proper request to the ADMINISTRATION REST API of the Backend Device Management GE.

Application Device Command Service

Applications are able to send commands to bidirectional devices that have provided before a callback URL for that purpose. For this to happen, Applications send a request to the ADMINISTRATION REST API of the Backend Device Management GE that may return in turn the reslt of the command or a connectivity error if not accessible.

Interconnection with NGSI enabled components

Applications may interconnect an M2M service framework with other functional NGSI-enabled GEs via the NGSI9/10 API of the Backend Device Management GE. Those NGSI-enabled components will be receiving BGSI notifications whenever devices events (register, observations) occur.

Basic Design Principles

  • Today's IoT framework considers a number of vertical silos exploiting different M2M technologies and protocols. Thus, the Backend Device Management GE aims to offer a single Administration REST API interface for Applications as well as an NGSI adaptor (NGSI REST API) transforming devices events into NGSI notifications. In order to cope with several technologies, the Device Communication REST API will support several ones: SensorML, ETSI M2M, etc.


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

Other Open Specifications

N/A


Re-utilised Technologies/Specifications

The Backend Device 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