SensorThings API

OGC SensorThings API - Part 1 Sensing
Status OGC Standard Implementation Specification
Year started 2015
Latest version 1.0
Editors Steve Liang (SensorUp), Chih-Yuan Huang (National Central University), Tania Tania Khalafbeigi (SensorUp)
Base standards JSON, OGC/ISO 19156:2011 O&M
Domain Open Geospatial Consortium, Internet of Things
Abbreviation OGC STA
Website OGC SensorThings API Standard GitHub Page

SensorThings API[1] is an Open Geospatial Consortium (OGC) standard providing an open and unified framework to interconnect IoT sensing devices, data, and applications over the Web. It is an open standard addressing the syntactic interoperability and semantic interoperability of the Internet of Things. It complements the existing IoT networking protocols such CoAP, MQTT, HTTP, 6LowPAN. While the above-mentioned IoT networking protocols are addressing the ability for different IoT systems to exchange information, OGC SensorThings API is addressing the ability for different IoT systems to use and understand the exchanged information. As an OGC standard, SensorThings API also allows easy integration into existing Spatial Data Infrastructures or Geographic Information Systems.

OGC SensorThings API was released for public comment on June 18, 2015.[2] The OGC Technical Committee (TC) approves start of electronic vote on December 3, 2015, and the SensorThings API passed the TC vote on February 1, 2016. The official OGC standard specification was published online on July 26, 2016.

Design

SensorThings API is designed specifically for resource-constrained IoT devices and the Web developer community. It follows REST principles, the JSON encoding, and the OASIS OData protocol and URL conventions. Also, it has an MQTT extension allowing users/devices to publish and subscribe updates from devices, and can use CoAP in addition to HTTP.

SensorThings API data model

The foundation of the SensorThings API is its data model that is based on the ISO 19156 (ISO/OGC Observations and Measurements), that defines a conceptual model for observations, and for features involved in sampling when making observations. In the context of the SensorThings, the features are modelled as Things, Sensors (i.e., Procedures in O&M), and Feature of Interests. As a result, the SensorThings API provides an interoperable Observation-focus view, that is particularly useful to reconcile the differences between heterogeneous sensing systems (e.g., in-situ sensors and remote sensors).

An IoT device or system is modelled as a Thing. A Thing has an arbitrary number of Locations (including 0 Locations) and an arbitrary number of Datastreams (including 0 Datastreams). Each Datastream observes one ObservedProperty with one Sensor and has many Observations collected by the Sensor. Each Observation observes one particular FeatureOfInterest. The O&M based model allows SensorThings to accommodate heterogeneous IoT devices and the data collected by the devices.[3]

SensorThings API provides two main functionalities, each handled by a profile. The two profiles are the Sensing profile and the Tasking profile. The Sensing profile provides a standard way to manage and retrieve observations and metadata from heterogeneous IoT sensor systems, and the Sensing profile functions are similar to the OGC Sensor Observation Service. The Tasking profile provides a standard way for parameterizing - also called tasking - of task-able IoT devices, such as sensors or actuators. The Tasking profile functions are similar to the OGC Sensor Planning Service. The Sensing profile is designed based on the ISO/OGC Observations and Measurements (O&M) model, and allows IoT devices and applications to CREATE, READ, UPDATE, and DELETE (i.e., HTTP POST, GET, PATCH, and DELETE) IoT data and metadata in a SensorThings service.

Entities (Resources)

SensorThings API defines the following resources. As SensorThings is a RESTful web service, each entity can be CREATE, READ, UPDATE, and DELETE with standard HTTP verbs (POST, GET, PATCH, and DELETE):[4][5]

Example Payload

http://example.org/v1.0/Datastream(id)/Observations

 1 {
 2   "@iot.count": 2,
 3   "value": [
 4     {
 5       "@iot.id": 1,
 6       "@iot.selfLink": "http://example.org/v1.0/Observations(1)",
 7       "phenomenonTime": "2016-01-01T05:00:00.000Z",
 8       "result": "-9",
 9       "resultTime": null,
10       "[email protected]": "http://example.org/v1.0/Observations(1)/Datastream",
11       "[email protected]": "http://example.org/v1.0/Observations(1)/FeatureOfInterest"
12     },
13     {
14       "@iot.id": 2,
15       "@iot.selfLink": "http://example.org/v1.0/Observations(2)",
16       "phenomenonTime": "2016-01-01T04:00:00.000Z",
17       "result": "-10",
18       "resultTime": null,
19       "[email protected]": "http://example.org/v1.0/Observations(2)/Datastream",
20       "[email protected]": "http://example.org/v1.0/Observations(2)/FeatureOfInterest"
21     }
22   ]
23 }

Data Array Extensions

In order to reduce the data size transmitted over the network, SensorThings API data array extension allows users to request for multiple Observation entities and format the entities in the dataArray format. When a SensorThings service returns a dataArray response, the service groups Observation entities by Datastream or MultiDatastream, which means the Observation entities that link to the same Datastream or the same MultiDatastream are aggregated in one dataArray.

Example request for data array

http://example.org/v1.0/Observations?$resultFormat=dataArray

Example data array response 

 1 {
 2   "value": [
 3     {
 4       "[email protected]": "http://example.org/v1.0/Datastreams(1)",
 5       "components": [
 6         "id",
 7         "phenomenonTime",
 8         "resultTime",
 9         "result"
10       ],
11       "[email protected]": 3,
12       "dataArray": [
13         [
14           1,
15           "2005-08-05T12:21:13Z",
16           "2005-08-05T12:21:13Z",
17           20
18         ],
19         [
20           2,
21           "2005-08-05T12:22:08Z",
22           "2005-08-05T12:21:13Z",
23           30
24         ],
25         [
26           3,
27           "2005-08-05T12:22:54Z",
28           "2005-08-05T12:21:13Z",
29           0
30         ]
31       ]
32     }
33   ]
34 }

Evaluation

Interoperability between OpenIoT and SensorThings "We believe that the implementation of the SensorThing API will be a major improvement for the OpenIoT middleware. It will give OpenIoT a standardized and truly easy to use interface to sensor values.This will complement the rich semantic reasoning services with a simple resource based interface. And the consistent data model mapping gives both a common context to describe the internet of things".[8]

Efficiency of SensorThings API A comprehensive evaluation of the SensorThings API is published in Jazayeri, Mohammad Ali, Steve HL Liang, and Chih-Yuan Huang. "Implementation and Evaluation of Four Interoperable Open Standards for the Internet of Things." Sensors 15.9 (2015): 24343-24373.

Quotes

SensorThings API was demonstrated in a pilot project[9] sponsored by the Department of Homeland Security Science and Technology. Dr. Reginald Brothers, the Undersecretary of the Homeland Security Science and Technology, was "impressed with the ‘state of the practical’ where these various industry sensors can be integrated today using open standards that remove the stovepipe limitations of one-off technologies.[10] "

OGC SensorThings API Standard Specification

Free and Open Source SensorThings API Implementations

Whiskers

In March 2016 SensorUp and the GeoSensorWeb Lab at the University of Calgary submitted an open source software project proposal to the Eclipse Foundation and has been approved. The project is called Whiskers.[11] Whiskers is an OGC SensorThings API framework. It will have a Javascript client and a light-weight server for IoT gateway devices (e.g., Raspberry Pi or BeagleBone). Whiskers aim to foster a healthy and open IoT ecosystem, as opposed to one dominated by proprietary information silos. Whiskers aims to make SensorThings development easy for the large and growing world of IoT developers.

GOST

GOST[12] is an open source implementation of the SensorThings API in the Go programming language initiated by Geodan. It contains easily deployable server software and a Javascript client. Currently (june 2016) it is in development but a first version can already be downloaded and deployed. The software can be installed on any device supporting Go (e.g. Windows, Linux, Mac OS and Raspberry Pi). By default sensor data is stored in a PostgreSQL database.

Fraunhofer STA

Fraunhofer implemented a server implementation of the OGC SensorThings API. The long-term goal is to create a fully featured implementation.[13]

SensorThings HcDT Charting SDK

SensorThings HcDT[14] is a javascript charting library for the OGC SensorThings API. It is based on the open source Highchart library[15] and Datatable.[16] It is a front-end charting library enable developers to connect to datastreams from any OGC SensorThings API service, and display the sensor observations in charts, tables, or dashboard widgets for web applications.

Example Applications

Smart Citizens for Smart Cities YYC - Crowd-sourced Air Quality Sensing

On Oct 8th 2016,[17] a group of volunteers (smart citizens) in Calgary gathered together, assembled their own sensors, installed at their houses, and formed a crowd-sourced air quality sensor network. All data are publicly available via OGC SensorThings API.[18] This citizen sensing efforts increased the number of Calgary's air quality sensors from 3 to more than 50.

Smart Emission Project in Nijmegen, NL

Smart emission[19] is an air quality monitoring project in the city of Nijmegen, NL. The project deployed multiple air quality sensors throughout the city. Data are published with open standards, including OGC SensorThings API. Part of the project is an open source ETL engine to load the project sensor data into an OGC SensorThings API.[20]

Comparison between OGC SensorThings API and OGC Sensor Observation Services

SensorThings API provides functions similar to the OGC Sensor Observation Service, an OGC specification approved in 2005. Both standard specifications are under the OGC Sensor Web Enablement standard suite. The following table summarizes the technical difference between the two specifications.[21]

OGC SensorThings API OGC Sensor Observation Service (SOS)
Encoding JSON XML
Architecture Style Resource Oriented Architecture Service Oriented Architecture
Binding REST SOAP
Inserting new sensors or observations HTTP POST (e.g., CRUD) using SOS specific interfaces, e.g., RegisterSensor(), InsertObservation()
Deleting existing sensors HTTP DELETE using SOS specific interfaces, i.e., DeleteSensor()
Pagination $top, $skip, $nextLink Not Supported
Pub/Sub Support MQTT and SensorThings MQTT Extension Not Supported
Updating properties of existing sensors or observations HTTP PATCH and JSON PATCH Not Supported
Deleting observations HTTP DELETE Not Supported
Linked data support JSON-LD Not Supported
Return only the properties selected by the client $select Not Supported
Return multiple O&M entities (e.g., FeatureOfInterest and Observation) in one request/response $expand Not Supported
  1. SensorThings API - GitHub
  2. Presentation: Sensor up your connected applications with OGC SensorThings API (FOSS4G)
  3. Chapter: Mapping the OGC SensorThings API onto the OpenIoT Middleware
  4. Tutorial in YouTube: Getting Started Series #1, SensorThings Tutorial Series #2 and SensorThings Tutorial Series #3
  5. Application: SensorThings Playground allows interested people and organizations to experiment with a SensorThings system via a friendly, step-by-step process.

References

  1. ↑ "OGC SensorThings API". https://github.com/opengeospatial/sensorthings. Retrieved 2016-01-26. External link in |website= (help)
  2. ↑ "OGC seeks public comment on SensorThings API standard for Internet of Things | OGC". www.opengeospatial.org. Retrieved 2016-01-26.
  3. ↑ "API Reference". www.sensorup.com. Retrieved 2016-01-26.
  4. 1 2 Liang, Steve; Huang, Chih-Yuan; Khalafbeigi, Tania (eds.). OGC® SensorThings API Part 1: Sensing.
  5. ↑ "SensorThings Data Model". ogc-iot.github.io. Retrieved 2016-01-26.
  6. ↑ tsbmail. "Y.2060 : Overview of the Internet of things". www.itu.int. Retrieved 2016-01-26.
  7. 1 2 "ISO 19156:2011 - Geographic information -- Observations and measurements". www.iso.org. Retrieved 2016-01-26.
  8. ↑ Schaaf, Hylke van der; Herzog, Reinhard (2015-01-01). Žarko, Ivana Podnar; Pripužić, Krešimir; Serrano, Martin, eds. Mapping the OGC SensorThings API onto the OpenIoT Middleware. Lecture Notes in Computer Science. Springer International Publishing. pp. 62–70. doi:10.1007/978-3-319-16546-2_6. ISBN 9783319165455.
  9. ↑ "OGC announces successful completion of Incident Management Information Sharing IoT Pilot".
  10. ↑ "S&T's Internet of Things Pilot Demonstrates 'State of the Practical'". Retrieved 2016-02-14.
  11. ↑ "Whisker, an Eclipse project proposal". Retrieved 2016-03-24.
  12. ↑ "Geodan/gost". GitHub. Retrieved 2016-06-30.
  13. ↑ "FraunhoferIOSB/SensorThingsServer". GitHub. Retrieved 2016-07-18.
  14. ↑ "SensorThings Highchart and DataTable (HcDT) | SensorUp". www.sensorup.com. Retrieved 2016-08-31.
  15. ↑ "Interactive JavaScript charts for your webpage | Highcharts". www.highcharts.com. Retrieved 2016-08-31.
  16. ↑ "DataTables | Table plug-in for jQuery". datatables.net. Retrieved 2016-08-31.
  17. ↑ "Calgary sensor pilot helps you plan a run with the best air quality | Metro News". metronews.ca. Retrieved 2016-11-04.
  18. ↑ "Air Quality in Calgary". calgary-air.sensorup.com. Retrieved 2016-11-04.
  19. ↑ contributors, Just van den Broecke - Geonovum original: Mark Otto, Jacob Thornton, and Bootstrap. "Smart Emission". data.smartemission.nl. Retrieved 2016-11-04.
  20. ↑ "Geonovum/smartemission". GitHub. Retrieved 2016-11-04.
  21. ↑ "Comparison of SensorThings API and Sensor Observation Service". Retrieved 2016-02-29.
This article is issued from Wikipedia - version of the 11/28/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.