FIWARE Global Summit - Lessons from Building FIWARE Environment with IoT Agent
1 like285 views
The document discusses the implementation of a Fiware environment at the Okinawa Open Laboratory, focusing on IoT applications such as air quality monitoring. It highlights the challenges of using various sensor data formats and the importance of normalizing data models for efficient consumption. Additionally, it emphasizes the launch of a 'Fiware-as-a-Service' initiative to promote the use of open-source technologies in smart city projects across Japan and Asia.
![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](https://image.slidesharecdn.com/14-yujiazama-presentation01lessonsfrombuildingfiwareenvironmentwithiotagent-181204100122/85/FIWARE-Global-Summit-Lessons-from-Building-FIWARE-Environment-with-IoT-Agent-14-320.jpg)
FIWARE Global Summit - Lessons from Building FIWARE Environment with IoT Agent
- 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