1 O PEN S ENSOR H UB AND SWE May 2016 Mike Botts Botts Innovative Research, Inc

What is OpenSensorHub? OpenSensorHub is a collaborative open source project aimed at developing software to allow anyone to easily build smart and scalable sensor networks interconnected through OGC® sensor standards Objectives: –Implement full OGC SWE vision –Hide the complexity –Make it easy (to deploy, to develop new sensor drivers) –Allow efficient live data streaming and stream processing –Support multiple computing platforms (from embedded to Cloud) –Not limited to SWE (SensorThings API, MQTT, etc.)

OpenSensorHub and OGC SWE OpenSensorHub's architecture is based on the models and implements the following OGC SWE encoding standards: –SWE Common Data Model v2.0 (SWE Common) –Sensor Model Language v2.0 (SensorML) –Observations & Measurements v2.0 (O&M) In addition, SensorHub implements the following standard OGC SWE web service interfaces out-of-the-box: –Sensor Observation Service v2.0 –Sensor Planning Service v2.0 Note: Simple implementations of OGC Web Feature Service & Web Coverage Service and other standards may also be provided but in a much more limited fashion since it is not the main focus of SensorHub.

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

Why OpenSensorHub? The SWE design is sound and several implementations of SWE services are in operation around the globe (but too few) Starting from scratch, SWE is still too hard to implement and deploy There is a strong need for open-source software that –is fully SWE-compliant and implements the full vision of SWE 2.0 –is efficient, modular, and scalable –most importantly, is easy to deploy and configure with very little or no software development The success of GeoServer serves as a model and incentive for the proposed project

Deployment Platforms

OpenSensorHub on Android phone

Video SensorHub using ARM/RPi

Web-based Configuration Interface

On-Demand Processing (SensorML v2.0)

M. Botts OpenSensorHub and GeoServer User Interface Web Services Data Sources PostGIS- PostGreSQL WFS WMS WMTS WCS KML GML OpenLayers Leaflets SensorHub Node SOS SPS SWE-Common SensorML Geospatial DataSensors/Actuators Web Browsers Event Pages / GeoQ Javascript

Client components for mapping

Client components for streaming data

Synchronizing streaming data

Two approaches for getting measurements from OSH-SOS getObservation – decent for “Products” Returns O&M – XML Lots of metadata about the measurement Not necessarily efficient for tuples, large, or streaming data getResult / getResultTemplate – highly efficient !!! Typically call getResultTemplate first but only once Returns SWE Common description of record and encoding example Call getResult to open a data stream/block or get latest values Returns values only (e.g ASCII CSV or binary) example Accessing Measurements

Code for requesting and parsing stream Javascript snip-it:

Some applications of SWE/OSH

Demonstration and tutorial videos: Real-time streaming video and location from vehicle and body cams Automated Vehicle Location (AVL) Laser Rangefinder remote location tagging Web-based configuration interface Lagrangian Plume model tasking and output OSH-enabled 3DR Solo Drone (on-demand video and georectification) Terrain draping of drone video and imagery Supporting Arduino sensors Supporting real-time and archived NEXRAD Radar from AWS Cloud Weather station and air quality station support Demonstration Videos

Current Directions Real, persistent and mobile-deployed systems Working with several federal and local agencies on OSH extension and real deployment Appliance (i.e. “device”) design and development Client support Dynamic/mobile deployment emphasis Small “stick” or “drop” technology (e.g. sticky-cam, drop air-quality station) Local communication (e.g. Serial, USB, BlueTooth LE, ZWave, even SPI, I2C) New device discovery API for Immediate discovery of newly deployed sensors and nodes Local storage push to cloud OpenSensorHub Security BasicAuth, OAuth Deeper permission/role-based a22uthorization Encryption – Full path: sensor to cloud Antispoofing, DoS protections Easing introduction of new sensors Libraries (e.g. communication protocol support, Arduino library) Spec-Sheet look SensorML viewer/editor Auto generation of drivers using SensorML Editor

Relevance This effort is vital to any organization that needs to: Bring sensor observations into your geospatial Common Op Picture Achieve interoperability across disparate sensor and sensor processing systems Enable workflows and cross-cueing across Multi-INT or multi- phenomenology systems Re-purpose various sensors and actuators in a variety of different orchestrated workflows, rather than slaving them to an individual stove- piped sensor network. Support on-the-fly reconfiguration of systems and processing to adapt to ever-changing operational environment and observable phenomenon. Deploy SensorHub nodes quickly, without generating new and costly engineering projects.

Social Media Links Github Web site YouTube demos/tutorials – Docs and downloads Wiki pages Example requests and responses Twitter – NOTE: We are proposing to the Eclipse Foundation (LocationTech/IoT groups) … come help!