OSH Tutorial Part 2

Connecting Devices

Integration Methods

  • Use an Existing Sensor Driver
  • Develop a New OSH sensor driver
    • Read measurement data from sensor
      • Persistent stream
      • Polling at regular intervals
    • Read other info from sensor (serial number, etc.)
  • Program sensor or board to send data to OSH service, e.g.
    • Transactional Sensor Observation Service (SOS-T)
    • SensorThings API
    • SWE-MQTT
    • Custom service

Use an Existing Sensor Driver

Developing a Sensor Driver

  • Data events are pushed to the bus
  • Drivers convert from native sensor protocols to OSH/SWE internal data models

Temp Sensor


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: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: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:interval>-50 +50</swe:interval>
         <swe:field name="pressure">
            <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/air_pressure">
               <swe:label>Atmospheric Pressure</swe:label>
                  <swe:Quantity definition="http://sweet.jpl.nasa.gov/2.0/sciUncertainty.owl#Accuracy">
                     <swe:uom code="%"/>
               <swe:uom code="mbar"/>
      <swe:TextEncoding tokenSeparator="," blockSeparator=" " decimalSeparator="."/>

Actual Data Values:



  • 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

Developing a Sensor Driver

OSH provides helper classes to avoid that each driver reinvents the wheel...

  • Low level communication protocols
    • TCP/UDP, USB, Bluetooth, BLE, Serial, SPI, I2C, etc.
    • Wrapper around existing libraries (Device I/O, RXTX, etc.)
    • Native impl. => Not always available on all platforms
  • Automatic reconnection helper for many protocols
    • To cope with network outages
    • To cope with remote device/service outages
    • Easy to use as inner class

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">
      <om:OM_Observation gml:id="obsTest1">
         <om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_ComplexObservation"/>
            <gml:TimeInstant gml:id="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>
<swes:InsertSensor service="SOS" version="2.0.0">
  • 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

Virtual Sensors

SOS-T Service

SOS-T Client

ESP8266 µC Board (with WiFi)

OSH Instance

Data Storage



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"
    "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

OSH Tutorial - Part 2: Connecting Devices

By Alex Robin

OSH Tutorial - Part 2: Connecting Devices

Patterns for development of sensor or actuator drivers

  • 404