introduction to fiware iot

Post on 23-Jan-2018

262 Views

Category:

Internet

4 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Introduction to FIWARE IoT

Fernando López Aguilar

FIWARE Cloud and Platform Senior Expert

fernando.lopez@fiware.org

@flopezaguilar

(Reference Orion Context Broker version: 0.24.0)

1

What is FIWARE ?

2

Open data publication

Once context information is gathered, a lot of useful complementary FIWARE enablers can be used

Context Broker

Advanced Web-based UI (AR,

3D)

Data/Apps visualization

Big Data AnalysisComplex Event

ProcessingMultimedia processing

Open Data

3

Cloud environment

4

5

FIWARE Catalogue (http://catalogue.fiware.org)

5

6

FIWARE Academy (http://edu.fiware.org)

7

Traction

8

9

FIWARE & Internet of Things

FIWARE IoT: Interoperability at Context Data Level

Satisfying Developers view

Common language for all Data Sources (IoT and non-IoT).

Single REST API. Query, Subscribe, Trigger Actions.

Open Source solutions published in GitHub, Read-the-docs, etc.

Street Devices• Location

• Observations

• Commands

Context Broker

NGSI API

Boiler• Manufacturer

• Last revision

• Product id

• Temperature

• Actions

Users• Name-

Surname

• Birthday

• Location

• ToDo list

City• OpenData

• Users Input

Public Bus T.System• Location

• Arrival time

APPs / Services / Data Scientist

11

Why FIWARE?

Tenemos un plan

We have a plan :

13

Smart* FIWARE most-used IoT Stack

IoT Agents

Device Protocol to NGSI Bridge:

• One entity per device.

• Constrained set of interactions.

Design principles:

• Modular approach.

• Deployment flexibility.

• Simplify the creation of Custom IoT Agents.

Provisioning of devices and groups of devices.

IoT Manager.

Additional services (e.g.: security, device registration, stats).

14

Integration with sensor networks

Smart solutions need to deal with the wide variety of IoT protocols today

Rather than trying to solve the battle of standards at IoT level, it brings a

standard where no standard exists today: context information management

15

Context Broker

IoT

Agent-1

IoT

Agent-2

IoT

Agent-n

IoT Agent

Manager

create/monitor

IoT Framework

Standard API (northbound interface)

(southbound interfaces)

MQTTETSI M2M IETF CoAP

What FIWARE provides?

1. Two out-of-the-box agents

• IOTA-JSON (JSON payloads)

• IOTA-UL (ultralight text-based data payloads)

• Both support HTTP and MQTT transports

2. A Node.js based SDK to program new IOTAs (iotagent-node-lib

library)

• Provides the common functionality for the northbound interface

(provisioning, NGSI-based interaction with Orion Context Broker, etc.).

• Protocol (transport and payload) is the part that has to be done by the

IOTA developer using the library

• IOTA-JSON and IOTA-UL has been implemented using this library

3. The IoTManager component.

16

Transport & Payload

Device protocol = transport protocol + payload format

Transports protocols

• HTTP

• MQTT

• Others

Payload format

• UL (ultralight)

• JSON

• Others

Transport and payload format are orthogonal, e.g.

• HTTP transport using JSON payload

• MQTT transport using JSON payload

• HTTP transport using UL payload

• MQTT transport using UL payload

• Etc.

17

Physical

Link

TCP

MQTT

Physical

Link

TCP

HTTP

Payload formats examples

JSON

Ultralight (UL)

18

{

"h": "45%",

"t": "23",

"l": "1570"

}

h|45%|t|23|l|1570

Ultralight 2.0 (Measures)

Simple HTTP-based protocol

Measure reporting:

• Key/Value pairs separated by | and #

• POST request with plain/text content to the IoTA path:

POST http://{{host}}:{{iota_ul-port}}/iot/d?k=&i={{device-id}}&t=2016-03-01T10:00:00Z

Payload example:

t|34#h|87#l|1900

Required query params

• k: Service API Key

• i: Device ID

Optional query params

• t: timestamp of the measure

19

Interaction models: Active Attributes

20

IOT Agent

DB

Device

ProtocolNGSI

Entity

information

Interaction

begins

Interaction models: Commands

21

IOT Agent

Device

ProtocolNGSI

Command

Execution

Interaction

begins

Result

Information

Requires the IOT Agent to be

registered as a Context

Provider

Attribute types

Active attributes

• Actively updated to CB

Lazy attributes

• Kept at the device, obtained using the CPr-forwarding

mechanism

Static attributes

• As active attributes, but with a “fixed” value

Commands

• For actuation capabilities

• Managed in a similar way to lazy attributes, but involving also an

info and a status CB attributes

22

Configuration API: Group provision

Create service

• /iot/services

Not exactly REST (check doc)

• POST

• GET

• DELETE

• PUT

Static attributes

Mandatory

• Resource

• Api key

• Entity Type

23

{

"services": [

{

"apikey": "4jggokgpepnvsb2uv4s40d59ov",

"cbroker": "http://0.0.0.0:1026",

"entity_type": "thing",

"resource": "/iot/d"

}

]

}

Configuration API: Device provision

Create device

• /iot/devices

Not exactly REST (check doc):

• POST

• GET

• DELETE

• PUT

Mandatory

• Device_id

• Entity_type

• protocol

Commands

• endpoint

24

{

"devices": [

{

"device_id": "my_device_01",

"entity_name": "my_entity_01",

"entity_type": "thing",

"protocol": "PDI-IoTA-UltraLight",

"timezone": "Europe/Madrid",

"attributes": [

{

"object_id": "t",

"name": "temperature",

"type": "int"

},

{

"object_id": "l",

"name": "luminosity",

"type": "number"

}

]

}

]

}

Sending Measurements: Ultralight 2.0 HTTP

25

Simple HTTP ProtocolAPI key (k)

Device Id (i)

Key Pair values

Push and Pull commands

POST /iot/d?k= k=4jggokgpepnvsb2uv4s40d59ov

&i=my_device_01 HTTP/1.1

Host: localhost:7896

Content-Type: text/plain

Cache-Control: no-cache

t|37#l|1200

HTTP/1.1 200 OK

Content-Length: 88

Content-Type: text/html

Connection: Closed

my_device_01@t|2| my_device_01@l|200

Orion Context Broker in a nutshell

26

Context Broker operations: create & pull data

Context Producer, publish data/context elements by invoking the

update operation on a Context Broker.

Context Consumer, can retrieve data/context elements by invoking

the query operations on a Context Broker.

27

STH-COMET: Why?

28

The Context Broker only stores

the latest attribute values:

• Event-driven action-oriented

paradigm

The Short Time Historic adds

memory into the equation:

• Continuous improvement

paradigm

STH-COMET: What?

29

Time series database:

• Optimized to deal with values

indexed in time

• Raw data vs. Aggregated data

• Basic aggregation concepts:

□ Range

□ Resolution

□ Origin

□ Offset

STH – Comet : How (birds-eye functioning: minimal)

30

update

query (raw & aggregated)

Client

OrionContextBroker

Help project content

31

Context Broker

IoT Agent

Ultralight 2.0

STH - COMET

MongoDB

7896

4041

1026 8666

Virtual Machine Instance

Ansible and docker-compose file to deploy a Virtual Machine with

Orion, IoT Agent Ultralight and Comet.

https://github.com/flopezag/fiware-iot-hackathon

Instruction to send data from sensor and recover them from Orion or

Comet (data aggregation)

Further reading

IoT Agent-Ultralight

• Base doc: https://github.com/fiware/iotagent-ul

Orion Context Broker

• Base doc: https://github.com/fiware/orion

• ReadTheDocs: https://fiware-orion.readthedocs.io

STH-Comet

• Github repository: https://github.com/fiware/fiware-sth-comet

• ReadTheDocs: https://fiware-sth-comet.readthedocs.io/en/latest

32

Question & Answer

fiware-tech-help@lists.fiware.org

fiware-lab-help@lists.fiware.org

33

Thank you!

http://fiware.org

Follow @FIWARE on Twitter

34

Thank you!

http://fiware.org

Follow @FIWARE on Twitter

BACKUP SLIDES

Backup slides

36

Active attributes

37

"attributes": [

{ "object_id": "t", "name": "temperature", "type": "float" },

{ "object_id": "h", "name": "humidity", "type": "float" }

],

Lazy attributes

Q: Why all this complication? Why don’t use only active attributes?

38

"lazy":[

{ "object_id": "l", "name": "luminosity", "type": "percentage" }

],

Static attributes

Similar to active attributes but…

• They don’t correspond to actual measures sent by the physical device

• They have a fixed value

• They are attached to every IOTA-to-CB update operation

Q: Why using static attributes?

39

"static_attributes": [

{ "name": "serialID", "type": "02598347", "value": "02598347" }

]

Commands

Three supporting attributes at CB (per command)

• <cmd> (write), the one used by the application (through update context

at CB) in order to execute command

• <cmd>_status (read only), the one in which IOTA published status

□ UNKNOWN: transient status, just after device provisioning and before any

execution is done

□ PENDING: command execution is in progress

□ ERROR: command execution finished in error status

□ FINISHED: command execution finished in ok status

• <cmd>_info (read only): upon completion, the result of the command

execution (if any) is published by IOTA in this attribute

Example:

• turn

• turn_info

• turn_status

40

"commands": [

{ "object_id": "u", "name": "turn", "type": "string" }

],

Commands

41

"commands": [

{ "object_id": "u", "name": "turn", "type": "string" }

],

turn_statusturn_status

turn_info

top related