2.1.  Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

2.1.1. Sensor

An entity capable of observing a phenomenon and returning an observed value. Type of observation procedure that provides the estimated value of an observed property at its output. [OGC 12-000]

2.1.2. Actuator

A type of transducer that converts a signal to some real-world action or phenomenon. [OGC 12-000]

2.1.3. System

Something of interest as a whole or as comprised of parts. Therefore a system may be referred to as an entity. A component of a system may itself be a system, in which case it may be called a subsystem. NOTE — For modelling purposes, the concept of system is understood in its general, system-theoretic sense. The term “system” can refer to an information processing system but can also be applied more generally. [ISO/IEC 10746-2:2009]

2.1.4. Location

A point or extent in space relative to a coordinate system. For point-based systems, this is typical expressed as a set of n-dimensional coordinates within the coordinate system. For bodies, this is typically expressed by relating the translation of the origin of an object’s local coordinate system with respect to the origin of an external reference coordinate system. [OGC 12-000]

2.1.5. Orientation

The rotational relationship of an object relative to a reference frame. Typically expressed by relating the rotation of an object’s local coordinate axes relative to those axes of an external reference coordinate system. [OGC 12-000]

2.1.6. Position

The location and orientation of an object relative to an external reference frame. For body-based systems (in lieu of point-based systems) is typically expressed by relating the object’s local coordinate system to an external reference coordinate system. This definition is in contrast to some definitions (e.g. ISO 19107) which equate position to location. [OGC 12-000]

2.1.7. Reference Frame (or Frame of Reference)

parameter or set of parameters that realize the position of the origin, the scale, and the orientation of a coordinate system [ISO 19111:2019]

2.2.  Abbreviated terms

DDIL

Denied, Degraded, Intermittent, or Limited Bandwidth

FMV

Full Motion Video

FOI

Feature of Interest

FOV

Field of View

HTTP

Hypertext Transfer Protocol

ISA

Integrated Sensor Architecture

MASBUS

MASINT Enterprise Service Bus

MASINT

Measurement and Signature Intelligence

MISB

Motion Imagery Standards Board

MQTT

Message Queuing Telemetry Transport

O&M

Observations & Measurements

OMS

Observations, Measurements and Samples

OSH

OpenSensorHub

SensorML

Sensor Modeling Language

SIF

Sensor Integration Framework

SIF-SP

Sensor Integration Framework Standards Profile

SOS

Sensor Observation Service

SOSA

Sensor, Observation, Sample, and Actuator (Ontology)

SPS

Sensor Planning Service

SSN

Semantic Sensor Network (Ontology)

STA

SensorThings API

SWAPI

SensorWeb API

SWE

Sensor Web Enablement

UAS

Unmanned Aircraft System

UAV

Unmanned Aerial Vehicle

4.1.  Applicability of existing OGC Data Models

The first key outcome of this task is the demonstration that existing OGC SWE data models (O&M, SensorML and SWE Common) go a long way to fulfil the requirements expressed in the SIF standards. For this reason, it is recommended to build on these data models and map them directly to other community standards (by defining best practices) rather than creating new data models as it was done in the original SIF documentation.

Small improvements to these existing standards, combined with the development of domain specific profiles/ontologies seem sufficient to accomplish the goal. Read the Future Work section for more detailed recommendations regarding this aspect.

4.2.  Implications to OGC API Standardization

In addition to the review of SIF, a comparative review of the Sensor Observation Service (SOS), Sensor Planning Service (SPS) and SensorThings API standards was also conducted during the Testbed, leading to the following observations:

• SOS and SPS provide good cross-domain functionality, allowing access and tasking of many different sensor types, but these standards are based on older XML web services, are hard to understand and implement, and lack discovery capabilities needed for larger deployments.

• SensorThings follows a more modern REST/JSON approach that is easier to understand, but is limited to simple sensor systems as it does not have adequate support for more complex data types such as orientation and other vector quantities, imagery, video or observation profiles for example.

It seems that there is a place for a new REST/JSON OGC API (perhaps “OGC API: Sensor Systems”) that can fulfill all SIF requirements (which correspond to original SWE requirements), including support for any kind of sensor systems.

6.1.  Reference View

The SIF-SP reference view is based on a subset of the DoD Architecture Framework (DoDAF) and is organized according to the principles of the Reference Model of Open Distributed Processing (RM-ODP).

RM-ODP formalism allows specifying requirements by taking different viewpoints, each of which allowing to address a particular set of concerns. The reference view provides information in the first 3 RM-ODP viewpoints whose definition is recalled in the following table:

SIF also leverages some of the DoDAF concepts for which it aims at capturing information needed for the exploitation of measurement systems and their observations. These concepts are:

6.1.2.  Information Viewpoint (Conceptual Models)

6.1.2.1.  Resource Descriptions

SIF defines different types of resources for which robust metadata should be provided. General Resource Descriptions provide a general description suitable for any resource that can be referenced by its URI. In addition, specific resource types are defined to provide more details, an overview of which is provided in the following UML diagram and table:

Figure 1 — SIF Resource Descriptions

Table 1 — SIF Descriptions

Description Type	Definition
Performer	A Performer is an entity that performs tasks, independent of whether the entity is hardware, software, firmware or wetware. Most SIF Performers are platforms, sensors, actuators, or sensor systems.
Activity	A Performer by itself does not perform sensing. It is the Activities that are executed by the Performer that generate Observations. The SIF identifies two forms of Activities. Atomic Activities are Activities which follow a request-response pattern. Processing Activities are Activities which will execute for a period (in some cases unbounded) of time. Metadata describing the Atomic Activities are provided through the Command Descriptions. Metadata describing Processing Activities are provided through the Activity Description.
Observable	A parameter or a characteristic of a phenomenon subject to observation.
Observation	The result of measuring/observing (Activity) an observed property of a specific real-world object.
Command	Description of a command supported by a Performer
Process	An operation that takes one or more inputs and, based on a set of parameters and a methodology, generates one or more outputs.

6.2.  Technical View 1

The SIF-SP Technical View 1 provides mapping rules between the SIF Reference View and the following OGC Sensor Web Enablement standards:

• SensorML

• Observations & Measurement

• Sensor Observation Service

• Sensor Planning Service

Please read the Clause 7 section for more details and discussion about these mappings.

6.3.  Technical View 3

The SIF-SP Technical View 3 provide general mapping rules with Tactical Denied, Degraded, Intermittent, or Limited Bandwidth (DDIL) environments, including a specific test suite for implementations based on the Integrated Sensor Architecture (ISA) DoD standard.

Please read the Clause 8 section to learn more about how the ISA and MISB DoD standards were mapped to SWE conceptual models.

7.1.  SensorML

SensorML is a robust language that is well suited for describing the following types of resources and concepts:

7.2.  SWE Common Data Model

SWE Common is a robust low-level data model that is useful for providing detailed metadata about the structure and semantics of data records as well as the data record values themselves in different possible encodings (CSV, XML, JSON, binary).

In particular, SWE Common can be used to implement both schema and instance level information for the following concepts:

Work has been done on the JSON encoding for both SWE Common Data Model v2.0 and SensorML v2.0/2.1 standards.

See JSON schemas provided in Annex A.

7.3.  Observations & Measurements (O&M & OMS)

“Observations and Measurements” (O&M) version 2.0 has been published both as an OGC and as an ISO Standard. Version 3.0 is under development and is now called “Observations, Measurements and Samples” (OMS). OMS will also be released as a joint OGC/ISO standard.

The OMS v3 conceptual models introduce important refinements to the O&M models, including among others:

• The new ObservationCollection class;

• A clear distinction between an Observer and the ObservingProcedure it performs;

• The proxy feature of interest and ultimate feature of interest concepts that generalize O&M’s concepts of sampling feature vs. sampled feature.

Although the O&M/OMS design seems to be driven mostly by communities using in-situ sensors, the more flexible design of OMS v3 will help solve many problems related to encoding inefficiencies encountered with O&M v2.

A UML diagram of the core OMS v3 conceptual models is provided below:

Figure 2 — OMS Conceptual Observation Model

7.4.  Sensor Web Enablement (SWE) Services (SOS & SPS)

In this section, mappings between SIF and both Sensor Observation Service (SOS) and Sensor Planning Service (SPS) are considered. Both of these services are XML based web services and have been OGC standards since 2007 and 2010 respectively.

SOS and SPS information models are almost entirely based on O&M and SensorML/SWECommon, so the mappings defined above are still valid in the context of these services.

7.5.  SensorThings API

SensorThings API (STA) v1.1 is an API based on REST principles and OData. It provides access to both observations and tasking capabilities. The UML diagram of the core SensorThings classes/entities is provided below:

Figure 3 — SensorThings Core Entities

The additional classes/entities used for tasking are illustrated below:

Figure 4 — SensorThings Tasking Entities

7.6.  SensorWeb API (Draft)

The SensorWeb API is a REST API under development by the OpenSensorHub team. This API targets a full implementation of the SWE vision (i.e. observation access, streaming, tasking, processing and discovery using O&M, SWE Common and SensorML) using a REST approach.

The SensorWeb API uses the HTTP/REST protocol for discovery and historical data access, as well as Websocket and MQTT bindings providing streaming and publish/subscribe capabilities for both observation and command data feeds.

8.1.  Scope

The scope of the test implementation is to demonstrate the feasibility of integrating various standard interfaces as well as legacy systems into a common framework by following principles of the SIF-SP. The implementation focuses on the use of existing and upcoming OGC standards to implement the SIF/SWE vision. That is, to allow interaction with heterogeneous sensor systems in a unified manner, including access to system metadata, observation data and ability to send commands.

The implementation focuses on demonstrating the following aspects in particular:

• The extent of the metadata that is possible to transmit using OGC standards;

• The integration with existing legacy systems without requiring changes or duplication of existing datastores;

• The ability to transmit a wide range of data types, from simple in-situ measurement to high data-rate video feeds.

The following diagram illustrates the data sources that were successfully integrated during the Testbed:

Figure 5 — OSH Based SIF Implementation

8.2.  OpenSensorHub

OpenSensorHub (OSH) is a Java framework that can enable any sensor, actuator, process, forecast model, robot, or system to be discovered, accessed, and controlled through OGC/SWE standard services and APIs.

OSH can also act as a bridge between protocols, either between SWE protocols themselves (e.g. SensorThings-SOS bridge) or between SWE and other proprietary protocols or community standards (e.g. OnVIF video cams to SWE bridge). OSH achieves this goal by defining Java APIs based on the SWE conceptual models, towards which sensor drivers, web services/APIs, and datastore connectors can be developed.

A simplified view of OSH architecture is shown on the diagram below:

Figure 6 — OSH Architecture

8.3.  Core Models

OpenSensorHub is built on conceptual models defined in O&M/OMS, SensorML and SWE Common. Additional semantics are provided by the OGC/W3C SSN ontology as well as the SensorML ontology from Botts Innovative Research that is browsable at http://sensorml.com/ont.

In addition to leveraging concepts defined in the above standards, OSH is based on a unified implementation model that connects together classes from O&M/OMS, SensorML, SWE Common, and SSN. The model is presented here as it could be used as the base for further work on SIF.

Below is a simplified UML diagram showing the main classes of the model. The diagram also illustrates how the model “realizes” classes of the main standard conceptual models it is based on (shown with a dashed outline):

• The om prefix denotes classes from the O&M and OMS model.

• The ssn prefix denotes classes from the SOSA/SSN ontology.

• The sml prefix denotes classes from the SensorML model.

• The iso prefix denotes classes from the ISO feature model.

The role of many OSH extensions (e.g. sensor drivers, datastore connectors, etc.) is to adapt legacy data models and formats to this internal unified model.

Figure 7 — Unified SWE Model

In this model, the following definitions hold:

1. As in SSN, a System represents an instance of an observing system that implements a particular Procedure. A System can be a physical piece of hardware, a logical process executed in a processing unit or even a human performing predefined steps in a lab or in the field. The difference between these types of systems is made by semantic tagging rather than creating different classes.

2. As in SSN, a System can have members (i.e. subsystems) that are themselves Systems. This allows describing more complex hierarchical systems with the desired level of granularity.

3. Contrary to SSN, an OSH System can also be used to model a Platform, which can then have its own Datastreams and command channels.

4. Any System can have any number of Datastreams. Therefore describing the complete hierarchy of System components is not necessary, even when providing all data generated by these components. If desired, the System can be modeled as “black box” (i.e. without sub components) with multiple datastreams (although technically the data comes from individual system components). The same is true for commands.

5. Both Observation results and Command parameters are described and encoded using the SWE Common standard, which allows efficient binary encoding. See Clause 8.13 for details about the supported encoding and codecs.

8.4.  Multi-protocol Bridge

OSH implements the idea of a protocol bridge envisioned by SIF. Thus ingesting data using one protocol and expose it with another is possible. OSH takes care of the proper transformation and tries to minimize the loss of information in the process.

For example, the following transformations have been demonstrated in the Testbed:

• Ingest data from a standard SOS server and expose through SensorThings API and SensorWeb API.

• Ingest data using SOS-T and expose through SensorThings API and SensorWeb API.

• Ingest data using SensorThings API and expose via SOS and SensorWeb API.

• Ingest MISB data/metadata and expose via SOS, SensorThings API and SensorWeb API.

• Ingest ISA protocol buffer data and expose via SOS, SensorThings API and SensorWeb API.

• Ingest data from legacy United States Geological Survey (USGS) webservice and expose via SOS, SensorThings API and SensorWeb API.

Internally, all OSH components are interconnected using the datastore and event bus APIs that make this data interchange possible. Thanks to this architecture, interoperability between protocols is possible for both real-time and historical cases, and for both observation and command data flows.

8.5.  Integration Points

OpenSensorHub can integrate with a legacy system in different ways:

1. By developing a “Sensor Driver” (or System Driver) in a JVM programming language (Java, Groovy, Scala, Kotlin, etc.) that implements the OSH sensor API. Such a driver supports direct access to any locally connected device (e.g. via serial, USB, Bluetooth) or digital data feed (e.g. a datastream flowing from a remote server such as a message queue). A driver is designed to capture real-time data coming to/from a system and convert between legacy formats and OGC SWE data models. The driver can handle both observation and command flows and is also responsible for collecting metadata about the system it connects to.

2. Another way of integrating an external device or other real-time data feed is by developing a piece of software that runs separately from OSH and exchanges data with OSH using one of the available transactional APIs (SOS-T, SensorThings API and SensorWeb API). Note that since this extension will run outside of the OSH node itself, it can be developed in any programming language. This method can also be used to ingest large volumes of historical data in batch mode.

3. Finally, integrating directly with an existing datastore containing historical observations and/or metadata is also possible using the Datastore API. In this case, OSH acts as a proxy to an underlying datastore with or without maintaining its own cache (e.g. LRU cache of most commonly accessed data). This type of integration is especially of interest for large data collections that are difficult or costly to duplicate.

The following integrations have been implemented or improved during Testbed 17:

8.6.  Sensor Drivers/Adapters

Sensor drivers (or System drivers) provide translators from/to lower level protocols such as the ones described in SIF-SP Technical View 3 (e.g. ISA). In this Testbed, the following drivers have been developed and showcased:

8.6.1.  ISA Protocol Driver

This driver is used to connect systems that implement the ISA protocol, and has two modes of operation:

1. Connection to real-time ISA sensor feed supporting the protobuf encoding;

2. Generation of metadata and observation data for a simulated ISA sensor network.

In both cases, the driver exposes system level metadata as well as descriptions for its datastreams and command channels. A single instance of the driver is able to decode data for a large number of ISA compliant systems, each of which is able to generate observations and receive commands.

Figure 8 — ISA Driver Diagram

In addition to observable properties and observation values, sensor identifiers, classifiers, characteristics and capabilities are obtained from ISA encoded data and converted to SensorML. The following sensor properties are supported:

• Manufacturer name

• Model number

• Software version

• Sensor type

• Operating Range / Voltage

• Operating Range / Current

• Operating Range / Battery capacity

• Measurement resolution

• Measurement accuracy

• Integration time

• Sampling frequency

A snippet of the generated SensorML metadata in the JSON encoding is provided in Annex A.2.1. Note that properties are semantically tagged using concept URIs that are resolvable to external ontologies.

The following sensors & datastreams are available through this driver:

System Type	Datastreams	Comments
Radiation Sensor	Radiological Reading, Radio Link Status (Link State), Sensor Location	RADIO001 to RADIO004 in the demonstration, with simulated triggers when radioactive source is nearby
Biological Sensor	Biological Reading, Radio Link Status (Link State), Sensor Location	BIO001 to BIO004 in the demonstration, with simulated random measurements
Chemical Sensor	Chemical Reading, Radio Link Status (Link State), Sensor Location	CHEM001 to CHEM002 in the demonstration, with simulated random measurements
Weather Sensor	Atmospheric Humidity, Atmospheric Precipitation, Atmospheric Pressure, Atmospheric Temperature, Atmospheric Wind, Electrical Status, Radio Link Status (Link State), Sensor Location	ATM001 to ATM002 in the demonstration, with simulated random measurements

8.6.2.  MISB UAS Driver

This driver is used for ingesting a live or pre-recorded MPEG-TS video data stream with embedded MISB.0601 KLV tags (UAS Metadata Set). This type of datastream is typically generated by STANAG compliant Unmanned Aircraft System (UAS).

Figure 9 — MISB Driver Diagram

The following datastreams are made available by this driver:

Datastream	Feature of Interest	Comments
Platform Orientation	UAV Platform	Relative to local NED reference frame
Sensor Location	UAV Imaging Sensor	Geographic location (EPSG 9705)
Sensor Orientation	UAV Imaging Sensor	Relative to UAV platform
Sensor Parameters	UAV Imaging Sensor	Variable Field of View (FOV)
Georeferenced Image Frame	Imaged Area	Geographic coordinates (EPSG 4979)
Video Stream	Imaged Area	H264 frames wrapped in SWE Common binary stream
Video Moving Targets (VMTI)	Moving Targets	Target locations in both image and geographic reference frames

This driver showcases important capabilities provided by OGC SWE standards:

1. Be able to identify and describe the feature of interest for each datastream.

2. Be able to describe the relative positioning of various components of a remote sensing system.

Point 1 is of utmost importance in this UAS use case because a single MISB system generates datastreams that provide observations about different real-world objects, including:

• The drone platform

• The imaging sensor

• The remotely sensed area

• The moving targets detected and tracked in the video

Clearly identifying these real-world features is essential for a correct interpretation of the data (e.g. the location of the sensor or the location of the remote target on the ground are two very different things). The “feature of interest” (FoI) concept of O&M is used here to provide metadata about these objects and correctly associate them with datastreams and individual observations.

Point 2 is equally important for proper use of the positioning information provided by the system. The SWE Common Vector construct is used to unambiguously describe the frames of reference with respect to which location and orientation parameters are expressed (see Clause 8.11 for details). There are at least four main frames of reference in this use case:

• 3D geodetic coordinate reference systems. Note here the difference between EPSG 4979 corresponding to WGS84 lat/lon coordinates + height above ellipsoid and EPSG 9705 corresponding to WGS84 lat/lon coordinates + height above mean see level (MSL).

• The local horizontal North-East-Down (NED) reference frame.

• The platform reference frame that is rigidly attached to the aircraft/UAV.

• The sensor reference frame that is rigidly attached to the camera sensor (the sensor is typically mounted on a gimbal and can thus be rotated with respect to the platform).

The full SWE Common descriptions for MISB datastreams are provided in Annex A.2.2. Note that properties are semantically tagged using concept URIs that are resolvable to external ontologies.

8.7.  Datastore Connectors

Another way data was integrated during Testbed 17 is by proxying existing data stores using OSH datastore API. Two datastores were integrated:

• The MASBUS SOS server, using the standard OGC SOS protocol.

• The USGS Water Database, using the legacy webservice protocol and RDF text format.

8.7.1.  MASBUS SOS Server

This connector is used to connect to a MASBUS DSOSRI service hosted by Riverside Research using the standard OGC SOS protocol. The connector connects regularly to the MASBUS SOS server in order to retrieve all new sensors’ metadata records and observations, and updates/publishes the info to the OSH integration hub.

Figure 10 — MASBUS Connector Diagram

The following sensors & datastreams are made available by this connector:

System Type	Datastreams	Comments
Omnisense Detector	Passive Infrared, RGB Radiance, Vibration	Omnisense-10712, Omnisense-10721, Omnisense-10728,
TRSS Sensor	TARACT Reading = Detection of objects of interest	Sensors with IDs TRSS:MM*`

8.7.2.  Legacy USGS Datastore

This connector is used to proxy the entire USGS water database made available through USGS Instantaneous Values Web Service. This database contains historical data for millions of observation sites and hundreds of observed properties. Information about monitoring sites is fetched using the USGS Site Web Service.

Figure 11 — USGS Water Database Connector Diagram

The following sensors & datastreams are made available by this connector:

System Type	Datastreams	Comments
Water Monitoring Site	Discharge, Gage Height, Water Temperature, Wind Speed, Wind Direction, Ocean Surface Elevation, …​	See the complete list of parameters. Note that sites typically don’t report values for all parameters.

This connector demonstrates the feasibility of integrating large sensor networks and expose the corresponding metadata and observation data efficiently via OGC APIs. The connector was instantiated as a direct pass-through proxy (i.e. without caching) for the Testbed.

Individual stations provide in-situ measurements at fixed locations so they are modeled as features of interest using O&M SF_SamplingPoint. A different datastream is created for each site/parameter combination.

Future work on this connector is to better model the different site types (atmosphere, glacier, ocean/costal/estuary, lake, stream, spring, well, etc.) and expose metadata of each site using SensorML (for now, sites are only described using simple features of interest).

8.8.  Processing

Processing chains are also a point of focus of this implementation. OSH natively supports real-time and batch processing and uses SensorML to provide a complete description of the processing chains.

The processing chains presented below take raw observations as input (data extracted from MISB video stream in this case) and produce new observations as their output. These new “derived” or “processed” observations are modeled and made available by OSH through the same APIs as the raw observations.

8.8.1.  Image Frame Georeferencing

This process chain computes the ground coordinates of the area imaged by the sensor. The process outputs the geographic coordinates of each image corner as projected on the ground, taking into account the location and orientation of the image sensor, the platform attitude, and the sensor field of view.

Figure 12 — Image Corners Georerefencing Process Chain

For reference, the full SensorML description of this processing chain is available from the demo server in both XML and JSON formats.

8.8.2.  Video Object Tracking and Geolocation

This processing chain computes the ground location of one or more targets detected and tracked in the video. The process outputs the geographic coordinates of the targets for each video frame where they are detected. This processing chain takes the video frames as input and must also take into account all positioning parameters provided as part of the MISB stream.

Figure 13 — Target Geolocation Process Chain

The processing chain description (in SensorML) is a good example of why concepts defined in the SIF semantic framework (such as different kinds of reference systems, orientation, and location data) and robustly provided by OGC SWE encoding standards are important to unambiguously define relationships between various system components.

For reference, the full SensorML description of this processing chain is available from the demo server in both XML and JSON formats.

8.9.  Web Services and APIs

Several web services and APIs are part of the OSH based test implementation, exposing system metadata and observation data in various ways, and allowing the sensor hub to act as a bridge between various standard protocols (see Clause 8.4). This section provides some implementation details as well as the strengths and weaknesses of each of these interfaces.

8.9.3.  SensorThings API v1.0

OSH can expose observation data as well as sensor & actuator metadata via an implementation of the SensorThings API 1.0 standard (both HTTP/REST and MQTT are supported). An OSH based implementation of the SensorThings API Tasking Extension is under development.

8.9.3.1.  Implementation Details

OSH implements SensorThings by exposing all or a subset of the systems, datastreams and command streams registered on a given sensor hub. A filter is used to select which resources are exposed via the SensorThings API.

The OSH SensorThing implementation is based on OSH internal unified model, with the following design decisions:

• STA Things are modeled as OSH Systems.

• STA Sensors and Actuators are modeled as OSH Systems and are members (i.e. subsystems) of the System representing the Thing.

• STA Locations and HistoricalLocations are modeled as observations in a dedicated Datastream attached to the System/Thing.

This is illustrated on the following diagram comparing instances of the SensorThings resource model and OSH internal model:

Figure 14 — Things vs. Systems

The following mappings are applied between OSH internal unified model (see Clause 8.3) and SensorThings requests:

Operations on Things	How it is mapped to the Unified Model
GET	Retrieve the list of systems that have more than one member (i.e. systems with subsystems) or that are not tagged as either SSN Sensor or SSN Actuator + add a Thing representing the SensorHub that all “orphan” sensors will be attached to.
POST	Create a System with the provided name and description.
PUT/PATCH	Update the System description.
DELETE	Remove a System and all associated resources (Datastreams, Observations, CommandStreams, Commands).

Operations on Locations	How it is mapped to the Unified Model
GET	Retrieve the latest observation from the location Datastream of the System representing the STA Thing.
POST	Add an Observation with the current time to the location Datastream of the System representing the STA Thing.
PUT/PATCH	Update the Observation whose ID is the same as the Location ID.
DELETE	Delete the Observation whose ID is the same as the Location ID.

Operations on HistoricalLocations	How it is mapped to the Unified Model
GET	Retrieve all observations from the location Datastream of the System representing the STA Thing.
POST	Add an Observation with the provided time to the location Datastream of the System representing the STA Thing.
PUT/PATCH	Update the Observation whose ID is the same as the HistoricalLocation ID.
DELETE	Delete the Observation whose ID is the same as the HistoricalLocation ID.

Operations on Sensors	How it is mapped to the Unified Model
GET	Retrieve all Systems that have no members and at least one Datastream or that are tagged as SSN Sensor.
POST	Create a System and semantically tag it with SSN Sensor class.
PUT/PATCH	Update the description of the System with the given ID.
DELETE	Remove the System with the given ID and all nested resources (i.e. subsystems, datastreams, command streams).

Operations on Datastreams	How it is mapped to the Unified Model
GET	Retrieve the list of all Datastreams that are part of Systems exposed by the service and whose result type is a scalar data type (i.e. boolean, category, count or quantity).
POST	Add a Datastream to the System represented by the STA Sensor that the new STA Datastream must refer to.
PUT/PATCH	Update the Datastream with the given ID. Reject request if the Datastream contained observations and the updated result structure is different from the existing one.
DELETE	Delete the Datastream with the given ID.

Operations on MultiDatastreams	How it is mapped to the Unified Model
GET	Retrieve the list of all Datastreams that are part of Systems exposed by the service and whose result type is a record (exclude all Datastreams with more complex results such as arrays).
POST	Add a Datastream to the System represented by the STA Sensor referenced by the STA Datastream.
PUT/PATCH	Update the Datastream with the given ID. Reject if the Datastream contained observations and the updated result structure is different from the existing one.
DELETE	Delete the Datastream with the given ID.

Operations on Observations	How it is mapped to the Unified Model
GET	Retrieve Observations from all Datastreams exposed by the service.
POST	Add an Observation to the Datastream referenced by ID by the STA Observation.
PUT/PATCH	Update the Observation with the given ID.
DELETE	Delete the Observation with the given ID.

Operations on ObservedProperties	How it is mapped to the Unified Model
GET	Not implemented
POST	Not implemented
PUT/PATCH	Not implemented
DELETE	Not implemented

Operations on FeatureOfInterests	How it is mapped to the Unified Model
GET	Retrieve the list of all FeaturesOfInterest
POST	Add a new FeatureOfInterest.
PUT/PATCH	Update the FeatureOfInterest with the given ID.
DELETE	Delete the FeatureOfInterest with the given ID.

Operations on Actuators	How it is mapped to the Unified Model
GET	Retrieve all Systems that have no members and at least one CommandStream or that are tagged as SSN Actuator.
POST	Create a System and semantically tag it with SSN Actuator class.
PUT/PATCH	Update the System description.
DELETE	Remove the System and all associated resources.

Operations on TaskingCapabilities	How it is mapped to the Unified Model
GET	Retrieve the list of all CommandStreams that are part of Systems exposed by the service.
POST	Add a CommandStream to the System represented by the STA Actuator referenced by the STA Datastream.
PUT/PATCH	Update the CommandStream with the given ID. Reject if the CommandStream has already received commands and the updated parameter structure is different from the existing one.
DELETE	Delete the CommandStream with the given ID.

Operations on Tasks	How it is mapped to the Unified Model
GET	Retrieve Commands from all CommandStreams exposed by the service.
POST	Add a Command to the CommandStream referenced by ID by the STA Task.
PUT/PATCH	Update the Command with the given ID.
DELETE	Delete the Command with the given ID.

8.9.3.2.  Strengths & Weaknesses

Strengths

• A simple API that is easy to understand from the client point of view (although not necessarily easy to implement on the server side).

• Suited for discovery even if large collections are used.

• Covers both data access and tasking through a single API.

Weaknesses

• Difficult to model datastreams with vector observed properties (e.g. location, orientation vector or quaternions, etc.).

• Lack of support for binary data prevents the use of this interface to handle high bandwidth sensors such as video or point clouds. In this case, linking to out-of-band data or service endpoints is usually necessary.

• Modeling more complex systems and relations between their components is difficult. For example, Actuator and Sensor are separate entities, making it hard for sensors to accept commands and vice-versa. Datastreams are attached to both a Sensor and a Thing but there is no concept of system hierarchy where the sensor can be part of a larger system or platform.

• Missing a standard way of doing simple keyword or full-text search.

8.10.  Modeling of Features of Interest

Features of Interest (FoI) are an essential part of the O&M model because they provide more information about the object that is being observed. Features of Interest are often physical entities (i.e. real-world objects, geographic features, etc.) but can also be more abstract entities. They can also be an intermediary object (proxy feature of interest) that samples or represents a larger entity (ultimate feature of interest).

Below are several examples of possible features of interest:

• A natural geographic feature such as a river

• A man-made geographic feature such as a building

• A monitoring station on a river (i.e. 2D sampling point of a larger river feature)

• A well sampling an underground aquifer (i.e. 3D sampling point of a larger aquifer feature)

• The volume of space surrounding a radiation sensor (i.e. 3D sampling volume)

• A mobile ground vehicle (i.e. mobile sampling point)

• An aircraft or UAV

• The exact area imaged by a street camera (i.e. sampling of a larger road feature)

• The area of the earth surface sampled by a remote sensor (e.g. polygonal sampling surface)

• A financial asset (e.g. for which we observe price and transaction volume)

Particular attention should be given to the modeling of features of interest in the case of certain mobile and remote sensors. Difficulties typically arise in these cases because the sampling geometry varies quickly with time, sometimes at the same rate as the observations themselves (think of video cameras providing 30 observations per second or more). Note that geometry can vary, not only because of a change of location, but also because of a change of sensor orientation or other parameters (e.g. the field of view of an imager). In such cases, providing the sampling geometry as part of the feature of interest object at each time instant is not only highly inefficient but also make discovery much more difficult.

Another approach is to separate constant (or rarely updated) feature properties from the ones that are highly variable. Noting that highly variable feature properties are often the ones that are observed continuously and constant ones are often asserted or observed only once (because they are known to be fixed a-priori), it seems only natural to model variable properties as time series of observations. Following such an approach, the OSH model can capture constant properties inside the feature resource itself, while variable property values are captured as separate Datastreams of Observations. In more complex cases, the sampling geometry is not directly measured but rather computed from simpler observations

Note that there are still some use cases whereby creating a different feature of interest for each observation is desirable. This is typically true when each feature is considered to have its own identity. For example, images of the earth taken by a space-borne still imager can be associated with a different feature every time with its own identifier and sampling geometry. However, this typically does not make sense for video cameras that tend to image the same objects multiple times per second. Providing a different feature along with every single video frame would be confusing.

The table below provides several examples of relationships between Sensor Systems, their Datastreams and Features of Interest demonstrated during the testbed:

8.11.  Relative Positioning

SWE Common Vector and Matrix constructs are useful to describe any kind of vector and tensor quantities. In particular, they allow the provision of necessary metadata when dealing with relative positioning of remote sensing system components (including both location and orientation).

A SWE Common vector allows specifying both a reference frame (the frame or CRS with respect to which the position is provided) and a local frame (the frame whose position is provided by the vector). This allows providing the relative position between subsystems unambiguously. The following snippets show how reference frames are specified in a SWE Common Vector.

Example 1:

Location of sensor with respect to a geodetic coordinate reference system (here EPSG 9705):

{
    "type": "Vector",
    "label": "Sensor Location",
    "definition": "http://www.opengis.net/def/property/OGC/0/SensorLocation",
    "referenceFrame": "http://www.opengis.net/def/crs/EPSG/0/9705",
    "localFrame": "urn:osh:sensor:uas:predator001#SENSOR_FRAME",
    "coordinates": [
        latitude ...,
        longitude ...,
        altitude ...
    ]
}

Example 2:

Attitude (orientation) of platform with respect to a local North-East-Down frame:

{
    "type": "Vector",
    "label": "Platform Attitude",
    "definition": "http://www.opengis.net/def/property/OGC/0/PlatformOrientation",
    "referenceFrame": "http://www.opengis.net/def/cs/OGC/0/NED",
    "localFrame": "urn:osh:sensor:uas:predator001#PLATFORM_FRAME",
    "coordinates": [
        heading ...,
        pitch ...,
        roll ...
    ]
}

Example 3:

Orientation of sensor with respect to the platform it is mounted on:

{
    "type": "Vector",
    "label": "Sensor Orientation",
    "definition": "http://www.opengis.net/def/property/OGC/0/SensorOrientation",
    "referenceFrame": "urn:osh:sensor:uas:predator001#PLATFORM_FRAME",
    "localFrame": "urn:osh:sensor:uas:predator001#SENSOR_FRAME",
    "coordinates": [
        heading ...,
        pitch ...,
        roll ...
    ]
}

See Annex A.2.2 for full examples.

8.12.  Semantics

Metadata provided by OSH typically makes use of SWE Common which separates structure from semantics, allowing referencing semantical concepts in external dictionaries, taxonomies, or ontologies.

For example, the following snippet shows the description of a data field (for example a field that is part of an observation result) that is a quantity expressed in hPa and represents the value of “air pressure at cloud top” as defined by the CF dictionary:

{
    "name": "ctp",
    "type": "Quantity",
    "label": "Cloud Top Pressure",
    "description": "Atmospheric pressure at cloud top",
    "definition": "http://mmisw.org/ont/cf/parameter/air_pressure_at_cloud_top",
    "uom": {
        "code": "hPa"
    }
}

8.13.  Data Encoding

SWE Common defines the data encoding separately from the structure and semantics. This allows the same data to be encoded in different ways while keeping the structure/schema unchanged. The following encoding methods are supported:

• DSV / CSV (DSV = delimiter separated value; CSV is a particular case where the separator is a comma)

• XML

• JSON

• Binary

The SWE Common schema is provided as part of the Datastream description (exposed via SOS GetResultTemplate or via the SensorWeb API Datastream schema resource). Observation results can then be encoded efficiently using just the values.

NCGIS Standards

OGC/ISO Standards

• OGC 10-004r3, Topic 20: Observations and Measurements, Version 2.0, https://portal.ogc.org/files/?artifact_id=41579

• OGC 20-082r2, Topic 20: Observations, Measurements and Samples, Draft, Version 3.0, https://github.com/opengeospatial/om-swg/blob/master/oms-abstract-spec/ogc-as-topic20/20-082r2_OGC_Abstract_Specification_Topic_20_-_Observations_and_measurements.docx?raw=true

• OGC 12-000r2, OGC® SensorML: Model and XML Encoding Standard, Version 2.1, http://docs.ogc.org/is/12-000r2/12-000r2.html

• OGC 08-094r1, OGC® SWE Common Data Model Encoding Standard, Version 2.0, https://portal.ogc.org/files/?artifact_id=41157

• OGC 17-011r2, JSON Encoding Rules SWE Common / SensorML, Best Practice, http://docs.opengeospatial.org/bp/17-011r2/17-011r2.html

• OGC 12-006, OGC® Sensor Observation Service Interface Standard, Version 2.0, https://portal.ogc.org/files/?artifact_id=47599

• OGC 09-000, OGC® Sensor Planning Service Implementation Standard, Version 2.0, https://portal.ogc.org/files/?artifact_id=38478

• OGC 15-078r6, OGC® SensorThings API Part 1: Sensing, Version 1.0, http://docs.opengeospatial.org/is/15-078r6/15-078r6.html

• OGC 17-079r1, OGC® SensorThings API Part 2: Tasking Core, Version 1.0, http://docs.opengeospatial.org/is/17-079r1/17-079r1.html

• Semantic Sensor Network Ontology, W3C Recommendation, 19 October 2017, https://www.w3.org/TR/vocab-ssn/

Other Specifications

• ISA Data Model Specification, Release 6.0, rev 7, 29 March 2019