1. Lessons from Building FIWARE Environment
with IoT Agent
Yuji Azama
Hideyasu Hayashi
Okinawa Open Laboratory / NEC Solution Innovators, Ltd.
November 28th, 2018

2. Okinawa Open Laboratory
Topics
■ About Okinawa Open Laboratory (OOL)
■ Our Motivation and Environment
■ How to define the data model in FIWARE to utilizing data
■ How to define Entity ID to utilizing data
■ FIWARE in Okinawa
■ Summary
2

3. 3
China
Japan
ASEAN
Okinawa
Center of the
Asian Dynamism
Cities located 4 hours
or less from Okinawa
Narita
Souel
NagoyaKansai
Haneda
Dailian
Beijing
Shanghai
Tsingtao
Guangzhou
Taipei
Hong Kong
Hanoi
Bangkok
Ho Chi Minh
Kuala Lumpur
Manila
Singapore
Jakarta
OOL is an international research institute
in Urasoe City, Okinawa, Japan
the Center of the Asian Dynamism
Urasoe
City Okinawa Main Island
Promote the Practical Application
and Dissemination of
Advanced ICT Platform Technologies
Mission
Okinawa Open Laboratory (OOL)
Activities
Researching IoT, Cloud Computing and NFV
Hosting Test Bed, Education and Conference

4. Okinawa Open Laboratory
Motivation
■ Goal
■ Promote utilization and exchange of IoT data
■ Why do we need FIWARE?
■ Open Source and based on standard
■ Allows small start by selecting necessary components
■ Our Trial
■ Detect odor, temperature and humidity around our office by
sensors and grasp the trend
4

5. Okinawa Open Laboratory
Testing Environment
■ Sensing metrics to track air quality
around the office
■ Temperature
■ Humidity
■ Gas (Odor)
■ Each sensor connects to
the Raspberry Pi
■ Sensor data is sent to FIWARE
5
DHT 11
Temperature and
Relative Humidity
MQ 135
GAS for Air Quality

6. Okinawa Open Laboratory
Components of Our Environment
6
Short Time History
Quantum Leap
Orion Context Broker
IoT Agent JSON
Monsquitto MQTT Broker
Device(RaspberryPi)
GAS for Air Quality
Sensor
Temperature and
Relative Humidity
Sensor

7. Okinawa Open Laboratory
Our Sensors and Visualized data by FIWARE
7
Raspberry Pi and sensors
Visualized data of sensors

8. Okinawa Open Laboratory
Issues in consuming sensor data
■ #1: Different data format per sensor
■ #2: Free format of entity ID
8

9. Okinawa Open Laboratory
#1: Different data format per sensor
■ Every sensor has its own data format :(
■ Difficult to search by Entity Types
■ RoomStatus, RoomInfo, Room, room
■ Difficult to search by Attributes
■ temperature, temp, temp_value, t
■ Difficult to aggregate data which have unit of
no uniformity in attribute value
■ ℃, °F, ％,
■ Many expressions of Date Time
■ 2018-10-12T12:00+09:00 (ISO 8601)
■ 1539345600 (Unix Timestamp)
■ 2018/10/12 12:00:00.000 (Custom)
9
Temperature1
,Temp2=27°,
temp=25,unit
=degree,
timestampe:y
yyy:mm:dd
The accumulated data
Data Consumer
It is not easy to retrieve data by filtering

10. Okinawa Open Laboratory
#1: Different data format per sensor
■ Problem
■ It is not easy to retrieve data by filtering
■ Difficult to build queries
■ Solution
■ Normalizing accumulated data
by applying standardized data model
Normalizing consuming(accumulated) data a
10

11. Okinawa Open Laboratory
#1: FIWARE Data Models
■ The data models developed and
recommended for use in the FIWARE
community.
■ The data models have been
harmonized to enable data portability
for different applications including,
but not limited, to Smart Cities.
11https://www.fiware.org/developers/data-models/

12. Okinawa Open Laboratory
#1: Data model decision process in FIWARE
■ FIWARE Data Models recommends the reuse of existing data models.
1. Find in “FIWARE Data Models ”
1. Find in “Schema.org” Data models
1. Find in other community’s data models
example：Open311(standard for civic issue tracking),
Datex Ⅱ( traffic information and data), and so on.
1. Define your own data models.
12
Not exist
Not exist
Not exist

13. Okinawa Open Laboratory
#1: Data model we use
■ 「AirQualityObserved」
13Excerpt Schema list
Values of attribute

14. Okinawa Open Laboratory
#1: Applying “Air Quality Observed” data model
■ Improvements
■ The data model doesn’t
depend on the type of
sensor.
■ The data model doesn’t
depend on the context
provider.
■ Aggregation became
easier
14
{
“devices”: [{
“device_id”: “MySensor01”,
“entity_name”: “urn:ngsi-ld:AirQualityObserved:Sensor001”,
“entity_type”: “AirQualityObserved”,
“attributes”: [
{ “name”: “airQualityLevel”, “object_id”: “aql”, “type”: “Text” },
{ “name”: “airQualityIndex”, “object_id”: “aqi”, “type”: “Number” },
{ “name”: “relativeHumidity”, “object_id”: “h”, “type”: “Number” },
{ “name”: “temperature”, “object_id”: “t”, “type”: “Number” },
{ “name”: “TimeInstant”, “object_id”: “time”, “type”: “DateTime” }
],
“static_attributes”: [
{ “name”: “address”, “type”: “PostalAddress”, “value”: {
“addressCountry”: “JP”,
“addressLocality”: “Okinawa”,
“streetAddress”: “61, Kanekadan, Uruma-shi” }},
{ “name”: “reliability”, “type”: “Number”, “value”: “0.9” }
],
“transport”: “MQTT”
}]
}
A device definition JSON of IoT Agent

15. Okinawa Open Laboratory
#2: Problems of free format of Entity ID
■ How to keep Entity ID Uniqueness and Readability?
■ Duplicate management of Entity ID is difficult when there are
many types of sensor
■ Entity ID should be managed in common format by all users
■ How to define the naming rule of Entity ID?
■ It is hard to define a naming rule from scratch
15

16. Okinawa Open Laboratory
#2: Free format of Entity ID
■ Problem
■ The format depends on the definition of ContextProvider
■ How to keep Entity ID Uniqueness and Readability?
■ How to define the naming rule of Entity ID?
■ Solution
■ Use Entity ID based on NGSI-LD
Normalizing consuming(accumulated) data a
16

17. Okinawa Open Laboratory
#2: Readable, Clean and Simple Entity ID
■ A gap of NGSIv2 and NGSI-LD
■ Even in NGSIv2 specification, it is possible to define Entity ID by the
specification of the NGSI-LD.
■ NGSI-LD defines a URN Namespace that makes API users to design
readable, clean and simple identifiers.
■ URN Namespace
■ A URN is an identifier to identify a resource on the network by name.
■ Specification of URN Namespace
■ Namespace IDentifier(NID)： “ngsi-ld”
■ Namespace Specific String(NSS)： <EntityTypeName>“:”<EntityIdentificationString>
■ Example of Entity ID： urn:ngsi-ld:Person:28976543
17
NID NSS

18. Okinawa Open Laboratory
#2: Apply Entity ID based on NGSI-LD
■ Improvements
■ The Entity ID format doesn’t depends on Context Provider
■ Easy to keep Uniqueness and Readability
18
$ curl http://orion:1026/v2/entities/urn:ngsi-ld:AirQualityObserved:Sensor001
{
"id": "urn:ngsi-ld:AirQualityObserved:Sensor001",
"type": "AirQualityObserved",
"TimeInstant": {"type": "DateTime", "value": "2018-11-16T10:26:01.768041+09:00", "metadata": {}},
"address": {"type": "PostalAddress", "value": {"addressCountry": "JP", ･･･}, "metadata": {･･･}},
"airQualityIndex": {"type": "Number", "value": 45, "metadata": {･･･}},
"airQualityLevel": {"type": "Text", "value": "Good", "metadata": {･･･}},
"relativeHumidity": {"type": "Number", "value": 64, "metadata": {･･･}},
"reliability": {"type": "Number", "value": 0.9, "metadata": {･･･}},
"temperature": {"type": "Number", "value": 28, "metadata": {･･･}}
}
Retrieve context data from Orion by Entity ID based on NGSI-LD

19. Okinawa Open Laboratory
FIWARE in Okinawa
■ Projects on smart cities and IoT are coming up one after
another.
■ “Open Platform for Smart City” has been launched
■ Launched by NEC at Oct 2018
■ “FIWARE-as-a-Service”
■ Free of charge
■ First targets are companies and
government agencies in Japan.
■ Planed to expand to Asia.
19
Ready-for-use FIWARE environment
will bring many smart cities/IoT apps !!

20. Okinawa Open Laboratory
Summary
■ Our FIWARE environment is working correctly
■ Need some skills such as sensor, networking, container and so on
■ Not difficult to work FIWARE itself
■ Important to normalize data models to consume data
efficiently
■ Use FIWARE Data Models or Schema.org
■ Use Entity ID based on NGSI-LD specification
■ FIWARE-as-a-Service has been launched in Okinawa
■ Ready-for-use FIWARE env should encourage more FIWARE usage
20

21. Thank you
21