OSH Tutorial Part 1

Architecture

Software Components

Sensor Drivers

Persistence
Engine

Event
Bus

Service Interfaces

Processing
Engine

Stream Processing

Batch Processing

Event Flows

OGC

HTTP

TCP

P2P

...

Core APIs

  • Module API
  • Sensor/Actuator API
  • Low Level Communication API
  • Persistence API
  • Processing API
  • Client/Service API
  • Security API
  • Admin Interface API (Vaadin)

Module API

  • All top-level OSH components implement this API
  • All modules can be independently installed and loaded
    (enables to configure light weight instances for small devices)

  • Centralized/synchronized access via the ModuleRegistry

    • Install/Uninstall modules (can be done remotely)

    • Discover available modules

    • Load/unload and start/stop modules

    • Asynchronous lifecycle management since 1.1

  • Use of Java ServiceLoader framework
  • Plugs into OSGI for more advanced plugin management

Sensor API

  • Discovering what sensors measure and Getting their data
    • By polling the sensor at regular intervals
    • By pushing events to the event bus
  • Sending Commands to sensors (or actuators)
  • OGC® SWE Common standard to describe message content, and OGC® SensorML for more metadata about the sensor
  • Sensor Drivers need to be developed to translate to and from this standard data representation
  • SWE Structure,  Generic Protocol, and Robust Connection helpers are included to facilitate driver development
  • SensorML description can be generated programmatically or provided as XML (or a mix of both)

Low Level Comm API

  • Allows to abstract various communication ports and protocol
    (e.g. USB, Bluetooth, serial, TCP, UDP, SPI, I2C, etc.)
  • Current version uses blocking InputStream/OutputStream as the generic way of sending/retrieving data to/from a given port
  • Future version will introduce Asynchronous IO via NIO and callbacks
  • Used by sensor drivers so that:
    • We don't reinvent the wheel in each driver
    • A single driver can be used with several different ports by simple configuration (i.e. digital sensors can often send data on many different ports simultaneously)

Persistence API

  • Sensor Data with its Metadata
    • SWE common data record descriptions
    • Observation metadata (O&M)
  • Sensor and Process descriptions (SensorML)
  • Generic CRUD API allows implementing various backends
    (SQL, NoSQL, object DB, file system, distributed, store etc.)
  • Various index types can be supported
    (Hash, B-Tree, R-Tree, KD-Tree, etc.)

Examples: PERST Embedded Database, JPA, Post GIS, Flat Files, Accumulo/Geowave

Processing API

  • Generic API on top of SensorML processing engine
  • ... but internal processes can also be implemented in pure Java without SensorML (e.g. on small devices)
  • Can be run in streaming mode when processing data events
  • Can be run on-demand directly by any other module (e.g. can be run synchronously by a service call, or as a batch process)
  • Use of SensorML allows advanced remote configuration of processing chains...
  • API allows:
    • Retrieving input/output/parameter description and data
    • Running processes synchronously or asynchronously
    • Installing Java code of a new process remotely (not implemented yet!)

Client/Service API

  • Very generic API to deploy client and service interfaces used for external communications
  • OGC® Sensor Observation Service and Sensor Planning Service are supported natively and can be automatically configured from existing sensors and storage
  • Very thin API in addition to the common Module API, so mostly tagging interfaces

Examples: SOS/SPS (HTTP), MQTT, P2P, REST/JSON, WebView, RemoteAdmin

Security API

  • API for pluggable security related components:
    • User Registry
    • Role Registry
    • Authorizer
    • Authenticator (based on Jetty interface for now)
  • API for defining fine grained permissions in each module
    • Each module registers a permission tree
    • Permissions are then allowed or denied for users and/or roles

Examples: Config Based Security Realm, OAuth Authenticator, etc.

  • TODO: API for Denial Of Service and Anti Spoofing protections

Example Permission Trees

SOS

  • Get
    • Capabilities
      • Offering1
      • Offering2
      • ...
    • Sensor Descriptions
      • Offering1
      • Offering2
      • ...
    • Observations
      • Offering1
      • Offering2
      • ...
    • Features Of Interest
  • Insert ...
  • Update ...
  • Delete ...

Web Admin

  • View UI
  • Shutdown
  • Restart
  • Save Config
  • Add Module
  • Remove Module
  • Init Module
  • Start Module
  • Stop Module
  • Restart Module
  • Update Module Config

Admin UI API

  • Not Finalized!!
  • Customized UI panels (Vaadin based)
    • Modify generic form rules
    • Add new panels with custom UI components
    • Associate panel with config or module class
  • Annotations for customizing configuration forms look and feel
    • Field label and description (typically shown as tooltip)
    • Value enums and ranges
    • More specific text field types
      • Module ID and selectable type
      • Password
      • IP addresses
      • URLs

Example Annotations

@DisplayInfo(label="HTTP", desc="HTTP configuration")

@Required

@ValueRange(min=0, max=65535)

@TextInfo(numLines=2, maxSize=200)

@FieldType(Type.PASSWORD)
    
@FieldType(Type.REMOTE_ADDRESS)
@AddressType(NetworkType.IP)

Case 1 - SOS + SPS

Sensor Drivers

Data Storage

Event
Bus

Stream Processing
Engine

Sensor Description Storage

Data + Sensor Events

Data Events

Data Events

Sensor Events

SOS Interface
Live + Historical

SPS Interface
Direct Tasking

Command Messages

Case 2 - Transactional SOS

Virtual Sensor

Data Storage

Event
Bus

Sensor Description Storage

Data Events

SOS-T Interface

Data Events

Modules can be dynamically created and configured

This happens when registering a new sensor with SOS-T

Data + Sensor Events

Stream Records, Update Sensor Description

Create New Virtual Sensor

Create New Storage

Could also be future SensorThings or MQTT service

Case 3 - Local vs. Cloud

Virtual Sensors

Local Storage

Event
Bus

SOS-T Service

SOS-T Client

Local Hub

Cloud Instance

Real Sensors

High Capacity Cloud Storage

Event
Bus

OSH Tutorial - Part 1: Architecture

By Alex Robin

Made with Slides.com

OSH Tutorial - Part 1: Architecture

Overview of internal architecture and public APIs

  • 410

More from Alex Robin