Developing a Sensor Driver

• Data events are pushed to the bus

• Drivers convert from native sensor protocols to OSH/SWE internal data models

Native protocol through e.g. UART

Push Events

Developing a Sensor Driver

• Sensor Drivers are based on SWE Common and SensorML models

• Drivers do the following
  • For each output, generate record description
  • Generate the sensor description
  • In separate thread
    • Read incoming data from sensor
    • Send "New Data Event" for each record received

• Optionally, if tasking is implemented
  • Generate message description for each control input
  • Handle commands by sending appropriate message to device

SWE Common Data Model

• Description and encoding of sensor data
  • ASCII
  • Binary
  • XML
  • JSON (coming in 1.2)

• Used by all other SWE standards (SensorML, O&M, SOS, SPS) and even WCS v2.0

• Provides low level metadata :
  • Data structure (scalar data types, records, arrays, choices)
  • Semantics (through URIs to ontologies)
  • Units of measure (through UCUM codes and URIs)
  • Nil values (reserved values with special meanings)
  • Constraints (allowed scalar values)
  • Quality (on scalars only)

XML Example

Data Stream Description:

<swe:DataStream id="EXAMPLE_01">
   <swe:elementType name="weather_data">
      <swe:DataRecord>
         <swe:field name="time">
            <swe:Time definition="http://www.opengis.net/def/property/OGC/0/SamplingTime">
               <swe:label>Sampling Time</swe:label>
               <swe:uom xlink:href="http://www.opengis.net/def/uom/ISO-8601/0/Gregorian"/>
            </swe:Time>
         </swe:field>
         <swe:field name="temperature">
            <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/air_temperature">
               <swe:label>Air Temperature</swe:label>
               <swe:uom xlink:href="Cel"/>
               <swe:constraint>
                  <swe:AllowedValues>
                     <swe:interval>-50 +50</swe:interval>
                     <swe:significantFigures>2</swe:significantFigures>
                  </swe:AllowedValues>
               </swe:constraint>               
            </swe:Quantity>
         </swe:field>
         <swe:field name="pressure">
            <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/air_pressure">
               <swe:label>Atmospheric Pressure</swe:label>
               <swe:quality>
                  <swe:Quantity definition="http://sweet.jpl.nasa.gov/2.0/sciUncertainty.owl#Accuracy">
                     <swe:uom code="%"/>
                     <swe:value>10</swe:value>
                  </swe:Quantity>
               </swe:quality>
               <swe:uom code="mbar"/>
            </swe:Quantity>
         </swe:field>
      </swe:DataRecord>
   </swe:elementType>
   <swe:encoding>
      <swe:TextEncoding tokenSeparator="," blockSeparator=" " decimalSeparator="."/>
   </swe:encoding>   
</swe:DataStream>

Actual Data Values:

2009-01-01T10:00:25Z,25.3,1098,5,56
2009-01-01T10:00:35Z,25.4,1098,15,59
2009-01-01T10:00:45Z,25.4,1098,12,42
2009-01-01T10:00:55Z,25.4,1098,5,40
2009-01-01T10:01:05Z,25.3,1098,5,66

SensorML

• Description of sensors (and actuators)

• Sensors are viewed as a process providing measurements

• Provides detailed description of:
  • Inputs, outputs and parameters (using SWE Common)
  • All components of the measurement process
  • High-level metadata (ids and classifiers, characteristics, contacts, external doc, etc.)
  • Relative and geo-referenced positions
  • Hardware interfaces

• Can describe both hardware and software components and combine them into processing chains

SensorML Content

SensorML Chain

Using an SOS-T Client

• SOS-T service implementation included in OSH core

• Full Fledge XML API to connect devices and provide all necessary metadata about sensors and measurements

• Internally, a virtual sensor is created, data is converted to OSH in-memory format, then published in the event bus for other modules to subscribe

• Used in OSH Android App

• If programming in Java, can use OSH SOS-T Client even without using the OSH core

SOS Example Requests

<sos:InsertObservation service="SOS" version="2.0.0">
   <sos:offering>http://www.my_namespace.org/water_gage_2_observations</sos:offering>
   <sos:observation>
      <om:OM_Observation gml:id="obsTest1">
         <om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_ComplexObservation"/>
         <om:phenomenonTime>
            <gml:TimeInstant gml:id="phenomenonTime">
               <gml:timePosition>2010-08-31T17:45:15.000+00:00</gml:timePosition>
            </gml:TimeInstant>
         </om:phenomenonTime>
         <om:resultTime xlink:href="#phenomenonTime"/>
         <om:procedure xlink:href="http://www.my_namespace.org/sensors/Water_Gage_2"/>
         <om:observedProperty xlink:href="http://sweet.jpl.nasa.gov/2.0/hydroSurface.owl#WaterMeasurements"/>
         <om:featureOfInterest xlink:href="http://wfs.example.org?request=getFeature&featureid=river1"/>
         <om:result xsi:type="swe:DataRecordPropertyType">
            <swe:DataRecord> ... </swe:DataRecord>
         </om:result>
      </om:OM_Observation>		
   </sos:observation>
</sos:InsertObservation>

<swes:InsertSensor service="SOS" version="2.0.0">
   <swes:procedureDescriptionFormat>http://www.opengis.net/sensorML/1.0.1</swes:procedureDescriptionFormat>
   <swes:procedureDescription>	
      <sml:SensorML/>
   </swes:procedureDescription>
   <swes:observableProperty>http://sweet.jpl.nasa.gov/2.0/hydroSurface.owl#WaterHeight</swes:observableProperty>
   <swes:metadata>
      <sos:SosInsertionMetadata>
         <sos:observationType>http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement</sos:observationType>
         <sos:observationType>http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Observation</sos:observationType>
         <sos:featureOfInterestType>http://www.opengis.net/def/samplingFeatureType/OGC-OM/2.0/SF_SamplingPoint</sos:featureOfInterestType>
      </sos:SosInsertionMetadata>
   </swes:metadata>
</swes:InsertSensor>

• Register a new sensor

• Push observations

Using the Arduino Library

• Provides simple SOS-T client as C++ library

• Helper C++ Classes
  • Measurement (metadata about measured quantity)
  • Sensor (outputs one or more measurements)
  • System (groups two or more sensors)

• Runs on Arduino Nano

• Connects directly to OSH SOS-T on remote server

• SOS connection works only through HTTP (so need device with Ethernet or Wifi)
  • Tested with ESP8266

• Concept could be adapted to work through serial as well

Connecting µC Device

to UART

Running OSH Arduino C++ Lib

Running OSH Java

Using a SensorThings Client

• SensorThings service implementation coming soon in OSH v1.2

• Very simple JSON based API to connect simple IoT devices, so it's very easy to develop your own client

• Internally, data will be converted to OSH in-memory format, so it will be available for all other modules to consume, just like with SOS-T

• Eventually SensorThings clients will become available in many languages

STA Example Requests

POST /v1.0/Sensors

{        
    "description": "SensorUp Tempomatic 2000",
    "encodingType": "http://schema.org/description",
    "metadata": "Calibration date:  Jan 1, 2014"
}

POST /v1.0/DataStreams

{
    "unitOfMeasurement": {
        "symbol": "%",
        "name": "Percentage",
        "definition": "http://www.qudt.org/qudt/owl/1.0.0/unit/Instances.html"
    },
  "observationType":"http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement",
    "description": "Temperature measurement",
    "Thing": {"@iot.id": 29761},
  "ObservedProperty": {"@iot.id": 5394816},
  "Sensor": {"@iot.id": 5394815}
}

• Register a new sensor

• Define one or more datastreams

POST /v1.0/DataStreams(id)/Observations

{
  "phenomenonTime": "2015-04-13T00:00:00Z",
  "resultTime" : "2015-04-13T00:00:05Z",
  "result" : 38
}

• Push observations