1 of 49

Connected Systems

The 126^th OGC Member Meeting

Alex Robin,

06 June 2023

Hosted by

2 of 49

Session Agenda

Introduction to Connected Systems
SWG Progress Report
52° North Use Cases and Implementation (Christian Autermann)
Scope and Design of Connected Systems API
Questions and Discussion

2

3 of 49

Introduction

3

4 of 49

Introduction

Our goal is to create an API for describing and exchanging dynamic data with any kind of Connected Systems.

But what are Connected Systems?

This is NIST’s definition:

�“Collections of interrelated systems consisting of information technology (IT) devices, sensors, and actuators that can seamlessly interact. By incorporating the functions of sensing, actuation, and control these systems can measure, describe, and analyze data in order to make decisions thereby performing smart actions both with and without human-to-human or human-to-computer interactions.”

4

5 of 49

Connected Systems API in a Nutshell

5

Description of System with Subsystems

Datasheets of systems and their components

SensorML

1011011101110101111110010111101010111111000001110101001

Outgoing�“data streams” (observations)

1011011101110101111110010111101010111111000001110101001

Incoming “control streams”�(commands)

OMS / SWE Common�JSON, Protobuf

Observable and controllable properties

SensorML

QUDT, domain ontologies

Description of a particular Deployment

SensorML

Sampling�Features

6 of 49

Multi-Domain by Design

API is designed to work across domains
Fixed / mobile, in-situ / remote
Can be used with domain specific models

UxS Telemetry Model

6

Features:

WaterML HY Features
GroundWaterML Features
GeoSciML Features
CityGML / CityJSON Features

Observation Results and Commands:

UxS Telemetry, Mission and Tasking
GeoPose

7 of 49

How to Model Diverse Use Cases?

Systems and Features of Interest are 2 key concepts of the SOSA/SSN and OMS models

For each use case, we will:

Identify the (observing) systems
Identify the features of interest
Identify the properties that are measured
Identify the commands than can be sent

Features of Interest are shown in translucent pink

Systems are shown in translucent green

7

FOI

System

8 of 49

Logistics

Mobile Assets / Fused Location

FOI is a truck

Observing system is the GPS receiver/tracker

FOI is a package with an RFID tag

Observing system is the network of RFID antennas

FOI is a fork lift

Observing system is composed of LoRa routers and a trilateration algorithm

8

Image by upklyak on Freepik

Observations

Geographic Location (long-range)

GPS

Observations

Proximity Detections (approx. location)

RFID

LoRa Router

Observations

Relative Location (site-wide)

LoRa

RFID

GPS

RFID

9 of 49

Marine UxS

FOI is the Atmosphere��via the atmospheric sampling point

FOI is the Hydrosphere��via the water surface sampling point

FOI is the Hydrosphere��via a water sampling profile

FOI is the Saildrone Platform��via the CG sampling point

9

Observations

Air Temp.�Atm Pressure�Wind Velocity�Solar Irradiance

Observations

Sea Surface Temp.�Salinity�Wave Height�Dissolved O₂/ CO₂�

Observations

Currents at different depths

Acoustic Doppler

Weather Sensors

Water Surface Sensors

GPS / Compass

Observations

Position

Attitude

Course

Atmosphere

Hydrosphere

10 of 49

Aerial UxS

FOI is the UAV platform

Observing System is the INS-GPS Unit

Observing system is the video camera

Sampling feature is the view frustum of the camera (parametric)

FOI is ?

FOI is the UAV platform

Target System is the flight controller

Target System is the camera or gimbal

Mobile Vehicle / 6 DoF / Taskable

10

INS- GPS

Flight Controller

Video Camera

Observations

Navigation Info�- Position�- Attitude�- Velocity

Observations

RGB Image
Tilt Angle, Zoom

Nav Commands

Relative Move
Set Heading
Move to geographic coordinates
Hover
Orbit at radius
Fly Along Path

Payload Commands

Start/Stop Video
Set Frame Rate
Set Tilt / Zoom
LookAt geographic pos
Follow Object

11 of 49

Spaceborne Systems

FOI is the Earth surface��via a sampling surface corresponding to the image footprint

Observing system is the EO camera (telescope)

FOI is the satellite platform

Observing system is the orbit tracking system

FOI is the satellite platform

Observing system is a data fusion process (KF) combining data from multiple attitude sensors

Target system is the reaction wheels

11

Gyros + Star Tracker

EO�Camera

Observations

Platform Attitude

Observations

Multispectral Image

Observations

Platform Position

Orbit Tracking

Pointing Commands

Attitude in ECI frame
Look at geographic pos

Reaction Wheels

12 of 49

Integrated with other APIs

12

Using standard IETF Web Linking

Connected�Systems API

Features API

Coverages API

Maps API

EDR API

SensorThings API

Features of Interest�Buildings, Roads, Water bodies, Vehicle, etc.

Coverage Observation Results�Raster Imagery

LiDAR Point Cloud

etc.

3D Geo Volumes

3D Tiles

Sensor Obs. Service

Non-OGC or Proprietary APIs

Datastreams

13 of 49

Aerial UxS Video Draping

13

14 of 49

Smart Buildings

14

24

22

20

18

16

16:41:30

15 of 49

Aviation

15

Full-stack application to broadcast and display weather data in the cockpit (iPad EFB)

Used by 14000 pilots on 3300 flights per day!

16 of 49

Technical Demonstration

Featuring…

Today at 4:45pm

16

17 of 49

SWG Progress Report

17

18 of 49

We have a new home on OGC API website…

18

19 of 49

…and a new official logo!

Many thanks to the OGC marketing team !

19

20 of 49

OpenAPI Documentation

Focused our work on OpenAPI specs
Easier for early implementers to review
Part 1 and Part 2 fairly complete
Lots of embedded examples

20

21 of 49

Standard Documents

Migrated documents to Metanorma format for easier navigation

SWE Common 2.1: https://docs.ogc.org/DRAFTS/08-094r2.html

SensorML 2.2: No document yet, but complete JSON schemas on GitHub:�https://github.com/opengeospatial/connected-systems/tree/master/sensorml/schemas/json

OGC API - Connected Systems

Part 1: https://opengeospatial.github.io/connected-systems/api/part1/standard/23-001r0.html
Part 2: https://opengeospatial.github.io/connected-systems/api/part2/standard/23-002r0.html
Not fully aligned with OpenAPI spec yet
Missing section on Properties
Using WebLinking and RFC6690

Working on a Reviewers’ Guide

21

22 of 49

Work with other SWGs

EDR SWG

Discussions to harmonize pub/sub
Reviewed discussion paper => adopted AsyncAPI
More discussion tomorrow during OGC API Joint SWG (Wed June 7th, 8:00AM)

GeoPose SWG

Christine attended our SWG meeting
Presented more details in the GeoPose SWG

SOSA/SSN in SDWWG (OGC-W3C)

Proposed PR to update the ontology to align with OMS

22

23 of 49

Implementations

52° North (Open Source)

Started implementation based on latest OpenAPI spec

OpenSensorHub (Open Source)

Objective = Full implementation
Server in Java + Javascript and Python Clients
Currently not fully inline with latest draft spec but work in progress�

GeoRobotix NodeX / EdgeX / MorpheusX (Commercial)

Highly scalable implementation based on OpenSensorHub
Hybrid edge/cloud with robust node-to-node communications
Advanced administration capabilities (provisioning, fleet and multi-node management)
Multi-screen dashboards

23

24 of 49

More Resources

Please join our bi-weekly calls if you are interested in contributing to the design of the API

24

25 of 49

52° North Implementation� & Use Cases

25

26 of 49

Connected Systems API�Scope & Design

26

27 of 49

Overview

Built from lessons learnt from OGC Sensor Web Enablement (2001-2012)
Modernized REST API following latest OGC guidelines (OGC API - Common)
Designed as an extension of OGC API - Features
Standard has 2 initial parts:

Part 1 = Static Features Resources
Part 2 = Dynamic Data Feeds

27

28 of 49

API Part 1: Feature Types

Systems�Systems are entities that implement procedures (e.g. sensors, actuators, platforms, simulations, etc…). Systems can be real-world entities such as pieces of equipment, humans or other living things (acting as sensors or platforms), but they can also be logical things such as simulations or models. Systems can be composed of subsystems/components so that they can be used to describe complex systems.
Procedures�Procedures are implemented by systems (e.g. workflow, protocol, plan, algorithm, or computational method). For hardware systems, it usually corresponds to the datasheet of a given type of system (e.g. a particular model of sensor), describing its characteristics and capabilities. (e.g. sensors, actuators, platforms, etc…) that implement procedures.
Deployments�Deployments describe how one or more systems are deployed for a particular purpose, including where and when the systems are deployed.
Sampling Features�Sampling features describe exactly what part of the feature of interest is being observed or controlled (a particular sampling location along a river, a part of a larger system, e.g. the C.G of an aircraft or the CPU of the robot, etc.).

28

29 of 49

System Metadata

29

System Type vs. System Instance

System Type

(Procedure)

System Instance(s)

Datasheet of�Sensor Model XYZ�from manufacturer ABC

Sensor of type XYZ�serial number = SN123

owner = Bob�location = My House

System Instance(s)

Sensor

Actuator

Platform

Sampler�…

Power Source

Comm. Module

30 of 49

System Metadata

30

System Type

(Procedure)

System Instance(s)

System Deployment

Datasheet of�Sensor Model XYZ�from manufacturer ABC

Sensor of type XYZ�serial number = SN123

owner = My Agency

Using Deployments

Sensor SN123 deployed�time = 2023-06-01/now�location = river�operator = Weather Inc.

System Deployment

System Deployment(s)

System Instance(s)

31 of 49

System Metadata

31

With Subsystems

Weather Station XYZ�from manufacturer ABC

Weather Station�ID number = BobWS01

owner = Bob�location = My House

System Instance�of type XYZ

System Datasheet

(Procedure)

Temperature Probe�from manufacturer FGH

Component Datasheet

(Procedure)

Anemometer Sensor�from manufacturer PQR

Component Datasheet

(Procedure)

Anemometer�of type PQR

Temp Probe�of type FGH

32 of 49

System Metadata

32

Platform Datasheet

(Procedure)

Drone Platform� Model XYZ

Deployments of multiple systems with interchangeable payloads

Mission “EagleEye”�time = 2023-06-01/..�location = Ball Park

Multi-System Deployment

Payload Datasheet

(Procedure)

RGB Video Cam�Model CV12

Payload Datasheet

(Procedure)

Thermal Video Cam�Model TV45

System Instance�Drone 01 of type XYZ

Payload 1 of type CV12

Payload 2 of type TV45

System Instance�Drone 02 of type XYZ

Drone 01

Payload 2

Drone 02

Payload 1

33 of 49

System/Procedure/Deployment Descriptions

Simple GeoJSON descriptions (summary)

33

{

"type": "Feature",

"id": "52kcn6i0kp5l4",

"properties": {� "type": "Point",� "coordinates": [-65.2254848, 18.3950288]� },

"properties": {

"featureType": "http://www.w3.org/ns/sosa/Platform",

"uid": "urn:mrn:noaa:pmel:2021:1060",

"name": "Saildrone Hurricane Monitoring Drone 1060",

"description": "Saildrone drone used to study hurricanes by sailing across them",

"validTime": [

"2021-11-09T00:00:00Z",

"now"

]� }�}

Detailed SensorML descriptions
Semantic tagging using SOSA/SSN system and procedure types
Queryable

34 of 49

System/Procedure Descriptions

34

Link to SensorML JSON:�https://github.com/opengeospatial/connected-systems/tree/master/api/usecases/marine/saildrone/procedures

35 of 49

Deployment Descriptions

35

Link to SensorML JSON: https://github.com/opengeospatial/connected-systems/blob/master/api/part1/openapi/examples/deployments/deployment-sml.json

Identification

Mission ID: SD2025

Saildrone - 2017 Arctic Mission�

UID: urn:x-saildrone:mission:2025

description: In July 2017, three saildrones were launched from Dutch Harbor, Alaska, in partnership with NOAA Research...

Classification

Region: Arctic

Contact

Operator: Saildrone, Inc.�Data Provider: NOAA PMEL

Region of Interest

Polygon [[53.76,-173.7], [53.76,-155.07], [75.03,-155.07], …]

Valid Time

2017-07-17T00:00:00Z / 2017-09-29T00:00:00Z

Deployed Systems

System UID: urn:x-saildrone:platforms:SD-1001

System UID: urn:x-saildrone:platforms:SD-1002

System UID: urn:x-saildrone:platforms:SD-1003

Documentation

Link: https://data.saildrone.com/data/sets/id/2025

36 of 49

Resource Collections

Resources can belong to several collections simultaneously.�
API defines default mandatory collections containing all resources of a given type.�
Resources have a canonical URI in addition to their collection URI.

Systems/Procedures/Deployments can be organized into collections, according to any criteria (see OGC API - Common Part 2)

36

All Systems

All Systems of type Platform

All Systems from organization ABC

All UAV Platforms

37 of 49

Features of Interest

37

Ultimate Features of Interest are usually domain specific (also called domain features)
CONSYS API is also a Feature API, so it can host any other feature types in separate collections. Any of these other features can then serve as features of interest
Examples: buildings, roads, water bodies, living things, but also logical things such as statistical samples, an organization, etc.
Systems can also be Features of Interest themselves
Features of interest (or alternate representations of these features) can also be hosted on external servers (other endpoints), and links are used to reference them.

38 of 49

Sampling Features

Sampling features indicate what part of a larger feature is being observed or interacted with for control�
API includes support of various sampling feature types defined in O&M and OMS:

Spatial Sample (Point, Curve, Surface, Volume)
Specimen / Material Sample (rock, water, blood, etc.)
Statistical Sample�

Additional sampling features

Feature Part (identify a part by its name, e.g. CPU)
Feature Proxy (proxy for a feature defined outside the API)

38

39 of 49

Smart Buildings

FOI is the entire building

FOI is a room in the building

Sampling feature is the view frustum of the camera (parametric)

Observing system is the camera

39

Observations

Total Building Occupancy

Observations

Room Video�Feed

40 of 49

Environmental Monitoring

Observing System is composed of the sensors deployed in the well (the well is the platform)

FOI is a river or stream��via a sampling point located at the monitoring site

FOI is the Ocean��via a sampling point / sampling profile at the location of the buoy

Observing System is composed of the sensors attached to the buoy (buoy is the platform)

FOI is an Aquifer��via a sampling point located at the bottom of the well

Observing System is composed of the sensors deployed at the site (the monitoring station is the platform)

Fixed Monitoring Sites

⇒ Link to WaterML Features

40

Observations

Air Temp.�Wave Heights�CTD Profile

Observations

Groundwater Level

Water Temp.

Chemicals detection

Well Sensors

Buoy Sensors

Ocean

Observations

Gage Height�Discharge

Water Temp.

River

Water Monitoring Sensors

Aquifer

41 of 49

Energy & Utilities

FOI is a Transformer

FOI is a Generator

FOI is a Chimney

Transf.

Nested Features of Interest

FOI is the entire plant

FOI is a Boiler

41

Image by macrovector on Freepik

Observations

Total Power Output

Observations

Terminal Voltage

Frequency

Power Factor

Temperature

Observations

Output Voltage

Output Frequency

RPM

Temperature�Vibration

Observations

SO₂ Concentration�NOx Concentration�PM₁₀ Concentration

PM_2.5 Concentration

Chimney

Generator

Boiler

Observations

Input Water Temp

Boiler Temperature

O₂ Level

Steam Pressure

Steam Temperature

42 of 49

Aircraft Telemetry

FOI is the helicopter platform

Observing System composed of GPS Attitude Sensors, and Kalman Filter

FOI is the engine

Observing System is the set of “Engine Monitoring Sensors”

Helicopter can be described as a System (platform) with sub-components (engine, INS, engine sensors, etc.)

Mobile Vehicle / 6 DoF

42

Engine

Observations

Navigation Info�- Position�- Attitude�- Course

INS-GPS

Observations

Engine Info�- RPM�- Power�- Temp

43 of 49

API Part 1: Derived Properties

A model for defining system or project specific properties derived from more general properties

43

Cross domain ontologies�e.g. QUDT, SensorML onto server

Domain specific ontologies�e.g. CF, WMO

System or project specific properties�(via CS API)

44 of 49

API Part 2: Dynamic Data

Datastreams�Datastreams are collections of homogeneous observations produced by a system. All observations in the same datastreams have the same result schema.
Observations�Observations provide the estimated values of feature properties (result) at a given point in time.
Control Streams�Control streams are collections of homogeneous commands received by a system. All commands in the same control stream share the same parameters schema.
Commands�Commands contain the parameters describing how the system should change the feature properties (feature property value not always included directly).
Command Status Reports�Command status is used to provide progress and status of asynchronously executed commands.
System Events�System events provide information when significant changes occur on a given system (e.g. adding a subsystem, new deployment, recalibration, equipment swap, etc.)

44

45 of 49

Data Streams (Observations)

Any system can have zero to many datastreams

Support for JSON as well as efficient binary formats

Provide schema of the observation result

OMS JSON => JSON schema
SWE Common data records => SWE Common schema
Protobuf => Proto file

45

46 of 49

Command & Control

Same as Datastreams but for incoming command data

Any system can have zero to many control streams

Support for JSON as well as efficient binary formats

Ecah control stream provides schema of the command parameters

Asynchronous feedback on long running commands

46

47 of 49

System Lifecycle Events

Changes occurring to a system during its lifetime

Deployment
Component added or removed
Calibration
On/Off
Out for maintenance
etc.

Can get notified of system changes using pub/sub

47

48 of 49

Streaming & Pub/Sub

Websocket for Streaming

Stream observations in/out of datastreams
Stream commands in/out of control streams

⇒ Separate connection for each datastream/control stream

MQTT for pub/sub (and streaming)

Subscribe for obs from datastreams
Publish obs into datastreams
Subscribe for commands received in control streams
Publish commands to control streams

⇒ Share same connection for multiple datastreams and control streams

48

49 of 49

Thank You

Community

49

500+ International Members

110+ Member Meetings

60+ Alliance and Liaison partners

50+ Standards Working Groups

45+ Domain Working Groups

25+ Years of Not for Profit Work�10+ Regional and Country Forums

Innovation

120+ Innovation Initiatives

380+ Technical reports

Quarterly Tech Trends monitoring

Standards

65+ Adopted Standards

300+ products with 1000+ certified implementations

1,700,000+ Operational Data Sets �Using OGC Standards