A brief description to FIWARE Ecosystem and detailed one of the FIWARE IoT framework. Introduction to Orion Context Broker, IoT Agent - Ultralight 2.0 and Short Term Historic - Comet.

1. 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)

2. 1
What is FIWARE ?

3. 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
Processing
Multimedia processing

4. Open Data
3

5. Cloud environment
4

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

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

8. 7

9. Traction
8

10. 9
FIWARE & Internet of Things

11. 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

12. 11
Why FIWARE?

13. Tenemos un plan
We have a plan :

14. 13
Smart* FIWARE most-used IoT Stack

15. 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

16. 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

17. 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

18. 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

19. Payload formats examples
 JSON
 Ultralight (UL)
18
{
"h": "45%",
"t": "23",
"l": "1570"
}
h|45%|t|23|l|1570

20. 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

21. Interaction models: Active Attributes
20
IOT Agent
DB
Device
Protocol
NGSI
Entity
information
Interaction
begins

22. Interaction models: Commands
21
IOT Agent
Device
Protocol
NGSI
Command
Execution
Interaction
begins
Result
Information
Requires the IOT Agent to be
registered as a Context
Provider

23. 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

24. 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"
}
]
}

25. 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"
}
]
}
]
}

26. Sending Measurements: Ultralight 2.0 HTTP
25
Simple HTTP Protocol
API 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

27. Orion Context Broker in a nutshell
26

28. 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

29. 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

30. 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

31. STH – Comet : How
(birds-eye functioning: minimal)
30
update
query (raw & aggregated)
Client
Orion
Context
Broker

32. 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)

33. 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

34. Question & Answer
fiware-tech-help@lists.fiware.org
fiware-lab-help@lists.fiware.org
33

35. Thank you!
http://fiware.org
Follow @FIWARE on Twitter
34

36. Thank you!
http://fiware.org
Follow @FIWARE on Twitter

37. BACKUP SLIDES
Backup slides
36

38. Active attributes
37
…
"attributes": [
{ "object_id": "t", "name": "temperature", "type": "float" },
{ "object_id": "h", "name": "humidity", "type": "float" }
],
…

39. Lazy attributes
 Q: Why all this complication? Why don’t use only active attributes?
38
…
"lazy":[
{ "object_id": "l", "name": "luminosity", "type": "percentage" }
],
…

40. 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" }
]
…

41. 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" }
],
…

42. Commands
41
…
"commands": [
{ "object_id": "u", "name": "turn", "type": "string" }
],
…
turn_status
turn_status
turn_info