1. SWE and SensorML ESIP Summer Meeting July 2016 Durham, NC
Mike Botts
Botts Innovative Research, Inc

2. OGC Sensor Web Enablement (SWE)
SWE = sensor, actuator, and process interoperability and integration
Supported functionality:
Getting data … from ANY type of sensor
Tasking … ANY type of sensor or actuator that accepts commands
Receiving alerts … from ANY type of sensors or process
Robust metadata … about sensors and their measurements (provenance)
On-demand processing … within and between nodes
Version 2.0 (SWE Common, SensorML, O&M, SOS, SPS) is the result of more than 10 years of collective thinking and is very mature and has been deployed all around the world

3. OGC SWE Standards OGC SWE includes the encoding standards:
SWE Common Data Model v2.0 (SWE Common)
Sensor Model Language v2.0 (SensorML)
Observations & Measurements v2.0 (O&M)
OGC SWE includes the web service interface:
Sensor Observation Service v2.0 (SOS)
Sensor Planning Service v2.0 (SPS)
OGC SWE also supports the hardware interface standard:
PUCK v1.0

4. Today the focus is on SensorML 2.0
A presentation on Thursday will discuss and demonstrate Open Source implementation of OGC sensor web services (OpenSensorHub)
NOTE: SensorML is well harmonized with the OGC SWE standards, but can be used independent of them.

5. What is SensorML ? Models and XML encoding for describing:
sensor and actuator systems
processes and process networks associated with observation and measurement
SensorML models all components as processes
physical processes (e.g. sensors and actuators)
computational processes (e.g. spatial transforms, image processing, QC testing and QA assessment, fusion, image classification etc.)
Processes in SensorML can be combined in Aggregate Processes and Physical Systems
Explicit definition of inputs, outputs, and parameters
Explicit definition of data flow through network

6. Why is SensorML Important?
Discovery of sensors and processes / plug-n-play sensors –
SensorML is the means by which sensors and processes make themselves and their capabilities known; describes inputs, outputs and taskable parameters
Observation lineage –
SensorML provides history of measurement and processing of observations; supports quality knowledge of observations
On-demand processing –
SensorML supports on-demand derivation of higher-level information (e.g. geolocation or products) without a priori knowledge of the sensor system
Enables Intelligent, autonomous sensor network –
SensorML enables the development of taskable, adaptable sensor networks, and enables higher-level problem solving anticipated from the Semantic Web

7. Example Applications of SensorML
Electronic specification sheets for sensors
Describing the lineage of ocean buoy observations
Including sensors, deployment environment, processing, and QC tests performed
Describing sensors and data streams for virtually any environmental sensor
Adding geospatial capabilities for tasking of web cams
On-demand geolocation of imagery and video
Satellites, aircraft, UAVs, AUVs, and Doppler Radar
Note: Processes that can be executed on-demand
SensorML process chains are agnostic of execution engine protocols
An open-source Java-based SensorML execution engine exists

8. On-Demand Processing (SensorML v2.0)

9. On Demand Geolocation of Satellite Data
NASA
Purpose of Demo: illustrate access to satellite observations and on-demand geolocation
Client: UAH Space Time Toolkit
Services:
SOS – satellite footprints (UAH)
SOS – aircraft observations (NASA)
SOS – satellite observations (UAH)
SensorML – on-demand processing (UAH)

10. Typical SensorML Process Chain

11. SensorML

12. SensorML Models Simple Process Physical Component Aggregate Process
Indivisible computational process (e.g. linear interpolator, QC test)
Physical Component
Indivisible physical process (e.g. detector, actuator)
Aggregate Process
Computational collection of processes (e.g. computational model/simulation)
Physical System
Physical collection of processes (e.g. sensor system)

13. SensorML Properties Common Physical Unique ID, name, description
Identification (e.g. serial number, short name)
Classification (e.g. sensor type, intended application)
Characteristics (e.g. dimensions, power consumption)
Capabilities (e.g. sensitivity, dynamic range)
Constraints (e.g. time, legal, classification constraints)
Documents (e.g. online manuals, brochures)
Contacts (e.g. manufacturer, owner)
typeOf (e.g. link to OEM description or general model)
Inputs/Outputs/Parameters (e.g. atmospheric temperature, wave height)
History (e.g. recalibration, cleaning of barnacles)
Physical
Reference Frames (e.g. sensor frame, image frame)
Geospatial state (e.g. location, orientation, velocity, acceleration)
AttachedTo (e.g. mobile platform, building)

14. SensorML Properties (different view)

15. SensorML Semantic Connections
Properties
The SensorML framework is very flexible (based on soft typing of properties)
Most properties have a definition attribute (must be a resolvable URL)
The definition attribute typically links to an ontology entry
Improves interoperability (e.g. SST = sea surface temperature = ocean temperature at depth=0)
Allows semantic tools to provide robust search
Other
All SensorML descriptions require a uniqueID (e.g. serial number, UUID, etc.)
SensorML instances will be online resources and perhaps discoverable through a registry
NOTE: check out the use of definition in the examples on next page.

16. SensorML 2.0 Basic Examples
Example Page:
Simple Process Description (Linear Interpolator):
Sensor Instance (deployed gamma detector)
Sensor Model (gamma detector model 2070)

17. SensorML 2.0 Viewers / Editors
Provide user-friendly look for SensorML document (not XML !)
Provide user-friendly view for both viewers and editors (use same look for each)
The will be two sets of viewer / editors
SimpleProcess / PhysicalComponent (metadata for any process)
AggregateProcess / PhysicalSystem (components with flow of data between them)
Basic process viewer / editor (SimpleProcess / PhysicalComponent)
Use a “Spec Sheet” look-and-feel
Design to encourage OEMs (and us!) to create descriptions in SensorML
Support interactive features (e.g. graphs, maps, images, etc.)
Aggregate process viewer / editor (AggregateProcess / PhysicalSystem)
Workflow look-and-feel (boxes representing component with data flow lines between)
Support interactive execution of process chain

18. Spec Sheet Look-and-Feel

19. Workflow Look-and-Feel

20. Go To Live Demo (scary) or View Demo Video on Next Page

21. Demonstration Videos Start Live Demo here:
Davis Thermometer
ADCP Processing System
Martha's Vinyard Workhorse Sensor
RDI Workhorse 1200
Initial SensorML viewer/editor demo video:
Other demonstration and tutorial videos:

22. Directions SensorML viewer (v1.0 in Sep 2016)
Improve interface
Improve helper tools (e.g. graph viewer, map display, ontology view)
SensorML editor (v1.0 in Oct 2016)
Update RelaxNG schema for SensorML 2.0
Support profile use (in later version, support profile creation)
Improve interface for adding, deleting, and editing properties
Support local and remote saving
SensorML aggregate process viewer (v1.0 in Nov 2016)
Decide on workflow graph library
Improve interface for viewing inputs, outputs, and parameters
Provide back and forth connection to the other SensorML viewer
SensorML aggregate process editor (v1.0 in Dec 2016)
Support adding, deleting, and editing of component processes
Support creating and editing connections between component inputs, outputs, and parameters

23. Directions -2- Integrate SensorML editors into OpenSensorHub (OSH)
Support user-friendly view of response from describeSensor request (Sep 2016)
Support creating and editing of sensor descriptions from OSH admin panel (Oct 2016)
Support JSON encoding (Nov 2016)
Support creation of executable processing chains from OSH admin panel (Dec 2016)
Enable the ability to add new sensor drivers using SensorML (Jan 2017)
Support Spec Sheet generator (2017)

24. Links SensorML 2.0 Examples- Github OpenSensorHub –
Github OpenSensorHub –
Github SensorML Editor –
YouTube demos/tutorials –