1. Sensor Web Standards and the Internet of Things
COM.Geo 2011 Workshop
Expanding GeoWeb to an Internet of Things
May 24th, 2011
Scott Fairgrieve
Geospatial Research and Development

2. Internet of Things (IoT) Supporting Technologies/Research Areas*
Identification Technology
Architecture Technology
Communication Technology
Network Technology
Network Discovery
Software and Algorithms
Hardware
Data and Signal Processing Technology
Discovery and Search Engine Technologies
Relationship Network Management Technologies
Power and Energy Storage Technologies
Security and Privacy Technologies
Standardization
There are many technologies involved in supporting and enabling the IoT. The Cluster of European Research Projects on the Internet of Things lists these broad areas as primary supporting technologies and areas of research related to the Internet of Things. We could probably have one or more workshops on each of these areas. It’s almost overwhelming to read about the IoT and the number and type of technologies involved in creating that vision as evidenced by the diversity of presentations we’ve seen in this workshop. Bearing that in mind, this presentation touches on a few of these aspects (highlighted in red) with respect to sensors and looks at the role of sensors, sensor webs, and sensor web standards in the Internet of Things. Note that there are some big areas (e.g. security and privacy) that I’m not touching on. Richard brought up the point yesterday of security and privacy of location data and in a larger context, sensor data in general, and I think that’s a big challenge.
*From: “Vision and Challenges for Realising the Internet of Things”, March 2010

3. The Role of Sensors in the IoT
Sensors are important for tagging, tracking, locating, and monitoring things, and for enabling things to be aware of the environment around them
Sensors are a key enabler of the IoT and a foundational technology for many IoT building blocks and related technologies (highlighted in red)
Sensors are things in the IoT, but they also help to discover and monitor properties of other things in the IoT and help smart things to be aware of the environment around them. A 2008 US National Intelligence Council report on Disruptive Civil Technologies with a timeline of 2025 (referenced in “Visions and Challenges for Realising the Internet of Things”) lists the following technologies as enabling building blocks and synergistic technologies related to the IoT. Of these technologies, many rely on sensors as key components.
Table From: “Vision and Challenges for Realising the Internet of Things”, March 2010

4. The Need for Sensor Standards
Sensors are already prevalent today, but they will become even more necessary and prevalent in IoT-enabled devices and applications
RFID readers, cameras, accelerometers, GPS, thermometers, etc.
Sensors are developed by a variety of manufacturers, using many different protocols and formats, making the interoperability and large scale sensor integration required by the IoT difficult without standards
Effective use of sensors to enable and drive the IoT requires standards for discovering sensors, retrieving sensor data, tasking sensors, and subscribing to and receiving sensor alerts
The decentralised and heterogeneous nature of things and the entities with which they
interact requires a scalable, flexible, open, layered, event-driven architecture of standards that minimises or eliminates any bias towards any single programming language, operating system, information transport mechanism or other technology and makes efficient use of available network connectivity and energy, where required.*
*From: “Vision and Challenges for Realising the Internet of Things”, March 2010

5. Sensor Webs
So now let’s talk about Sensor Webs. In order to support the IoT vision, these sensors that are available today need to be web accessible. This slide illustrates the OGC’s vision of the Sensor Web. I like to think of Sensor Webs as components of the World Wide Web for sensors – they’re extensions of the World Wide Web with sensor-specific standards and interfaces that enable users and software to discover and utilize sensors anywhere.
“… web accessible sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application program interfaces (APIs)”
From OGC OGC Sensor Web Enablement: Overview and High Level Architecture

6. Open Geospatial Consortium (OGC) Sensor Web Enablement (SWE) Standards
Help to enable the vision of the Sensor Web by eliminating barriers to sensor interoperability
Include XML-based messaging formats and web service interfaces for discovering, accessing, and controlling all types of sensors
Include built-in support for location and a variety of coordinate reference systems that should address both outdoor and indoor location
Sensors, measured phenomena, geographic features, and other items are all identified using Uniform Resource Identifiers (URIs)
Built with the Semantic Web and shared vocabularies/ontologies in mind
Semantic interoperability is seen as a key building block of the IoT
The 1.0 versions have been around for a few years, with the 2.0 versions being adopted now. The 2.0 versions include:
Better support for asynchronous messaging
Improved consistency across standards
OGC has formed a Pub/Sub Standards Working Group (SWG) to address broader support for pub/sub technologies across its standards
Should help with real-time /event-driven IoT use cases
Bearing that in mind, the OGC has developed the Sensor Web Enablement (SWE) standards to help enable the Sensor Web vision. These standards can also help to enable the IoT vision, given the prominent role of the sensors in the IoT (see bullets)…

7. OGC SWE Standards Encoding Description Sensor Model Language
(SensorML)
Describes and models processes, sensors, and systems of
sensors
Observations and Measurements
(O & M)
Format for encoding sensor observation data
SWE Common
A common set of data types for describing sensor data, used by SensorML and O & M
Web Service
Sensor Observation Service (SOS)
Provides archived and near real-time access to sensors and their
data. Sensors are described in SensorML and sensor data
are described in O & M. Includes optional support for adding new sensors and publishing their observations.
Sensor Planning Service (SPS)
Provides access to controllable sensors and actuators and the means to task those sensors/actuators in a standard way.
Sensor Alert Service (SAS)
Provides the ability to subscribe to and receive sensor alerts in
real-time. Utilizes Extensible Messaging and Presence Protocol (XMPP) for delivering alerts in real-time
Sensor Event Service (SES)
Provides Complex Event Processing (CEP) and filtering of sensor data streams
Web Notification Service (WNS)
Standardized asynchronous messaging/notification mechanism
for receiving messages in many ways, including , Short
Message Service (SMS), phone, etc.

8. OGC GeoWeb Standards
These standards complement the sensor web standards and provide geospatial context to sensor web information in terms of populating mapping applications with maps and feature data and can support sensor data processing and fusion (e.g. the WPS).
Encoding
Description
Keyhole Markup Language (KML)
An OGC standard format for displaying geospatial data such as points, lines, polygons, and images in many mapping applications including Google Earth.
Geography Markup Language (GML)
An OGC standard format for describing geographic features like points, lines, and polygons.
Web Service
Catalog Service for the Web (CS/W)
Provides OGC web service and object discovery (i.e. sensors and other geographic features)
Web Map Service (WMS)
Provides access to raster map data (i.e. static images) that can be used to generate a map background.
Web Feature Service (WFS)
Provides access to vector map data (i.e. points, lines, and polygons). Could provide access to location/information about things in the IoT, since these things would be classified as features.
Web Coverage Service (WCS)
Provides access to geographic coverage data (i.e. geographically distributed measurements)
Web Processing Service (WPS)
Provides a standard interface for discovering, describing, and executing geo-processes.

9. User Applications - The SWE-Enabled Home
Sensor Observation Service (SOS)
Sensor Planning Service (SPS)
Sensor Alert Service (SAS)
Web Notification Service (WNS)
SensorML System
Thermometer(s)
Ice/Water Dispenser Switch
Door Switch
RFID Reader
SOS
SPS
Retrieve Inventory, Temperature, Other Data
Adjust Temperature, Other Settings
SAS
SWE Client
Receive Inventory, Food/Filter Expiration, Other Alerts
Alerts
In the future, we may see a rise in smart appliances and devices that are accessible utilizing the IoT. Take your refrigerator for example. It already has a sensor that knows when the door is open or closed and temperature/humidity sensors to ensure that food remains stored in the optimal environment. It has a sensor that tells you when the water filter needs to be changed. In the future, if manufacturers start embedding RFID chips in product packaging, it may even have an RFID reader that knows what products it is currently housing (there are already refrigerators out there that have RFID readers). It is a system of sensors that can be described using SensorML. Information from those sensors could be accessed from an SOS, sensors/actuators could be controlled via an SPS, and alerts could be subscribed to and received via an SAS. If my refrigerator and its associated SWE services were available over the Internet, I could be at the grocery store and use my mobile phone to ask my refrigerator what it contains or doesn’t contain. My refrigerator could alert me when a product has been stored too long and has expired. Or, my refrigerator or some SWE-enabled smart agent acting on my behalf could text me with a grocery list (generated for me based on my habits and current inventory) or me that I need to purchase a new water filter (via a WNS), or maybe the refrigerator or smart agent could even go to Amazon.com or some other online store and order a new water filter for me. In this case, the use of SWE allows IoT software on my mobile device or within my home to be reusable, assuming that all of the smart appliances in my home are SWE-enabled.
This simple use case extends to multiple application areas in the home like power management: smart meters, outlets, and the smart grid. A user utilizing the same SWE Client application from the previous example could access information on home power usage by outlet, retrieve the current temperature and environmental conditions in his/her home, etc. SWE-enabled smart agents could manage the power usage in the home by monitoring environmental/other sensors and adjusting the thermostat and other devices.
Alerts
Smart Appliances
SWE
Smart Agents
, text Alerts
, text Grocery List
WNS
Grocery List
Order New Filter

10. User Applications - The SWE-Enabled Home
Where are my keys?
Sensor Observation Service (SOS)
RFID Reader
SOS
SWE Client
Retrieve Inventory Data
In-home RFID sensor detects items and their location. The same SWE client application from previous examples could be used to query the RFID sensor for the location of a particular item or could be used to inventory items by location.

11. User Applications - The Smart Store
In-Store Navigation
Help me find items on my shopping list
Direct me to each item I want using the shortest path
Utilizes multiple OGC GeoWeb and Sensor Web services as well as other services
Need to discover available inventory services
Find the location of items on my list in local store coordinates (makes use of sensors/services for monitoring inventory locations)
Show me a local store map (WMS, WFS, etc.)
Calculate the shortest path using my current location along with the locations of various items (WPS)
Have you ever walked into one of the large chain hardware stores (or any large store for that matter) and been completely lost as to where to go to find the item you’re looking for? I’m convinced that might be partially intended or even planned to get you walking around looking at/buying other things, but it’s also partially a side effect of the large numbers of things in those stores. The quick solution to this problem involves asking one of the many employees walking around for help, but I’m a male, and I don’t like asking for directions or admitting that I don’t know something. So, I usually end up circling around the store several times, walking up and down aisles, and then I ask someone. Using sensor web services and public access to a store’s built-in sensors/devices for inventory monitoring, this problem could be alleviated, saving seconds for women and minutes/hours for men.
How do I find available inventory services when I don’t know about them ahead of time? In the previous examples, I know about the services that I setup in my house, but in this example these services are provided by the store. Perhaps there’s a peer-to-peer (P2P) approach to query local network for services or a P2P mechanism for services/sensors to advertise their existence, or maybe there’s a QR code printed somewhere that gives my client application access to the URLs of these services. Once I find available services, the client application then needs to query them for the location of items that I’m looking for. Once the client application has the items and their locations, it needs a local store map (perhaps provided through one or more of the OGC services), and it needs to calculate a shortest path to get to all of those items (perhaps provided by a WPS) that utilizes my current location and the location of all those items in local store coordinates.
Required technologies :
Indoor location with a local coordinate reference system
RFID/other tagging technologies
Geo web services for accessing store layout/maps (e.g. OGC WMS, WFS), calculating route (WPS)
In-Store Navigation
Help me find items on my shopping list
Direct me to each item I want using the shortest path.

12. User Applications – Environmental Monitoring Supplemented with Citizen Scientists
Sensor Observation Service (SOS)
SOS
Transactional
SWE Client
SWE Client
Register Sensors, Insert Observations
Crowd-Sourced Sensor Data
SWE Client
SWE Client
SWE Client
SWE
Smart Agents
SWE
Smart Agents
SWE
Smart Agents
Trend: Adding more mobile/dynamic sensors coupled with fixed/static sensors
Crowd-sourced sensor data – access to finer grained information on a variety of environmental conditions (weather, traffic patterns, popular places, etc.). This information can be coupled with existing reference environmental data to augment information for making decisions.
Sensor Data from “official” Sensors
SOS
Official and Reference Environmental Sensors

13. Challenges Scaling Discovery Performance Standards Harmonization
Can/how do the SWE standards work in an IoT environment on a large scale – billions/trillions or more sensors/“things”?
Discovery
How do I find sensor services? How do I make my sensors discoverable? Is there a central catalog or set of catalogs or a search engine for the sensor web where I go to find services, or is there some peer-to-peer mechanism where sensors/services notify me of their availability?
Performance
Moving towards event-driven, publish/subscribe, CEP mechanisms to optimize the flow of information  information can be stored as needed, filtered and sent to the appropriate recipients/applications
Standards Harmonization
Multiple sensor and IoT standards need to be harmonized in order to realize interoperability across sensor systems
Big Data
Sensors and the IoT add to the growing amount of monitoring data that is available to a wide range of users. How do we effectively analyze all of this data and ensure that meaningful and relevant data and decisions are made?
Security and Privacy

14. Questions

15. Contact Information
Scott Fairgrieve
Phone:
Stefan Falke
Phone: