Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Comparison between OGC Sensor Observation Service and SensorThings API


Published on

The recording of the webinar is here:

This webinar discussed the differences between the two OGC standards for IoT data exchange, i.e., OGC Sensor Observation Service and the OGC SensorThings API. It compares the two specifications in terms of interoperability, feature list, developer experience, efficiency, scalability/discoverability, and security. In summary, SOS and SensorThings are both interoperable. SensorThings can interoperate with SOS but not the other way around. SensorThings offers more features, better developer experience, better efficiency, and better scalability. In terms of security, SensorThings API can leverage the XML/SOAP security mechanisms by offering an SOS interface.

Published in: Internet
  • Be the first to comment

Comparison between OGC Sensor Observation Service and SensorThings API

  1. 1. Comparison between OGC SOS and SensorThings API 0.23 litre/minute 0.25 litre/minute 0.27 litre/minuteRH: 85 % Temp: 18 Celsius Dr. Steve Liang, Ph.D., P.Eng. Associate Professor, University of Calgary Founder and CEO, SensorUp Inc.
  2. 2. About Dr. Steve Liang ๏ Associate Professor, Geomatics Engineering, Uni. Calgary ๏ AITF-Microsoft Industry Research Chair on Open Sensor Web (2011~2014) ๏ Chair OGC SensorThings API Standard Working Group ๏ Rapporteur, ITU-T SG12/11 on Internet of Things Test Specifications ๏ Founder and CEO, SensorUp Inc ๏ Calgary’s Top 40 Under 40
  3. 3. About SensorUp ๏ We are a leader in Sensor Web and IoT Platforms ๏ We are leading several international IoT standard development efforts (OGC and ITU-T) ๏ We are proud member of Eclipse and Open Geospatial Consortium
  4. 4. News - 
 Whiskers ๏ Whiskers, a new Eclipse open source project proposal for OGC SensorThings API
  5. 5. News - Whiskers ๏ Whisker is ๏ a Javascript Client Library for SensorThings ๏ a light-weight SensorThings Server for IoT gateways (e.g., Raspberry Pi) ๏ First release - 2016 Q2 or Q3
  6. 6. Background ๏ Sensor Observation Service (SOS) v1.0 ๏ results of OWS-3 (2005) ๏ SOS v2.0 (2012)
  7. 7. SensorThings API Background ๏ OGC conducted several IoT workshops in 2011 and 2012, and identified the needs for a new SWE standard for IoT ๏ SWE for IoT SWG established in October 2012 ๏ SWE for IoT SWG changed its name to SensorThings API in September 2013 ๏ SensorThings API approved in February 2016
  8. 8. Lessons learnt from SWE Implementations ๏ Our team implemented multiple SWE services ๏ SOS 1.0 server, SOS 2.0 server, A Worldwind- based SWE client, a AJAX-based SWE client, a Pivotviewer Sensor Web Browser, etc. ๏ Published more than 20 peer-reviewed papers ๏ We tried to apply the lessons learnt to the development of SensorThings API
  9. 9. What are we comparing? ๏ Interoperability (between SOS and SensorThings) ๏ Features ๏ Developer Experience ๏ Efficiency ๏ Scalability ๏ Security
  10. 10. ๏ At a data exchange level, SensorThings and SOS are interoperable. ๏ Both are based on O&M (OGC/ISO 19156:2011). ๏ At a service interface level
 SensorThings API to SOS
 SOS to SensorThings API Interoperability
  11. 11. SensorThings to SOS ๏ You can build an SOS with SensorThings API interfaces. That means function-wise you can find 1:1 mapping from SensorThings API to SOS. ๏ SOS v.2.0 Example 9: ๏ SOS: ๏ GetObservations(observedProperty) ๏ SensorThings API: ๏ ~/ObservedProperties(id)/Datastreams? $expand=Observations ๏ then converting JSON to XML, Voilà!
  12. 12. ๏ For example: find all Observations whose Features-of- Interest’s descriptions contain ‘arctic’ ๏ SensorThings API ๏ ~/FeaturesOfInterest? $filter=substringof(‘arctic’,description)& $expand=Observations ๏ SOS ๏ N/A SOS to SensorThings
  13. 13. Feature Comparison
  14. 14. ๏ It is a choice of encoding ๏ SOS can have a JSON encoding extension ๏ Similarly SensorThings can have an XML encoding extension (e.g., OASIS OData has both JSON and XML) JSON or XML?
  15. 15. Developer Experience ๏ SensorThings API provides a much superior developer experience!
  16. 16. Developer Experience cont. ๏ Developer can explore SensorThings with any Web browser ๏ The linking structure allow developers to explore SensorThings even without reading the specification ๏ The standard-based REST style provides consistent HTTP verbs and status codes to CRUD entities
  17. 17. Developer Experience cont. ๏ Very compact code space for SensorThings clients ๏ e.g., insert an Observation with Terminal
 curl --request POST
 --data '{"result": "2.11" }'
 --header "Content-Type: application/json"
  18. 18. Developer Experience cont. ๏ Example, insert an Observation with SOS

  19. 19. ๏ At the Web Transfer Protocol Level ๏ SOS is based on HTTP ๏ SensorThings is designed for HTTP, CoAP, and MQTT ๏ At the Interface Level ๏ SensorThings offers efficient ways to get compact responses (shorter response time, less data transmitted, less power consumption) ๏ At the Encoding Level ๏ JSON vs XML Efficiency
  20. 20. MQTT vs HTTPS (power consumption)
  21. 21. MQTT vs HTTPS (power consumption)
  22. 22. ๏ MQTT has a structure similar to URL path to define pub/sub topics ๏ compatible with REST style! ๏ not compatible with Key Value Pair (KVP) encodings SOS over MQTT??
  23. 23.
 &offering= SOS over MQTT?? In the context of SOS, they are the same.
 In the context of MQTT, they are different topics.
  24. 24. ๏ CoAP uses UDP ๏ A typical CoAP request header is 10~20 Bytes ๏ Response Code uses a single Byte ๏ Support pushing by introducing ๏ CoAP Observe HTTP vs CoAP
  25. 25. ๏ GET Observations(id)/result
 result: "19.19"
 } ๏ GET Observations(id)/result/$value
 19.19 SensorThings’ Efficient Interfaces 
 (URL Patterns)
  26. 26. ๏ GET Observations(id)?$select=result
 { "@iot.count": 10326,
 "@iot.nextLink": "…",
 "value": [ 
 {"result": "20.79"},
 {"result": "20.81"},
 Efficient Interfaces ($select)
  27. 27. ๏ SOS does not provide pagination. ๏ SensorThings provides advanced pagination utilities. ๏ e.g., Observations(id)?$top=5&$skip=5 ๏ e.g., Datastreams(id)?$expand=Observations
 Efficient Interfaces (pagination)
  28. 28. ๏ SensorThings API is all about links, and it’s designed for easy discovery. ๏ selfLink - unique and shortest URI ๏ nextLink - short response time ๏ navigationLink - for relationships and 
 reuse of metadata Discoverability and Scalability
  29. 29. ๏ SensorThings’ link-based structure ๏ also means easy sharding (i.e., scalability) ๏ crawler and search engine friendly (e.g., easy to use ElasticSearch to index multiple SensorThings)
 there is no easy way to index an SOS Discoverability cont.
  30. 30. ๏ Sensor delivers data streams ๏ SOS’ Request/Response model means many unnecessary interactions between clients and servers. ๏ In oder to know if there’s new Observations inserted into an SOS, a client needs to send requests very frequently. Scalability - Pub/Sub vs Request/Response
  31. 31. ๏ MQTT Subscribe 
 Datastreams(id)/Observations? $select=result MQTT + OData URL Pattern + O&M URL path tells you how to find metadata, entity name tells you how to interpret the data Query option allows you to receive only the updates you want to receive
  32. 32. ๏ MQTT Subscribe: 
 Datastreams(id)/Observations? $select=result,phenomenonTime
 ๏ Notification:
 {result: "19.19",
 phenomenonTime: "2016-03-24T01:57:54Z"} MQTT + OData URL Pattern + O&M
  33. 33. Security ๏ XML vs JSON, which one is more secure? ๏ SOAP vs REST, which one is more secure? ๏ Don’t forget, SensorThings can easily provide a SOS interface, but not the other way around.
  34. 34. Summary ๏ SensorThings can interoperate with SOS (not the other way around) ๏ SensorThings API provides more features, better developer experience, better efficiency, and better scalability. ๏ While SOS can leverage the existing SOAP and XML security mechanisms, a SensorThings service can easily provide SOS interfaces if the SOAP and XML security mechanisms are desired.