OGC Engineering Report

OGC Testbed-17: Sensor Integration Framework Assessment ER
Alex Robin Editor
OGC Engineering Report


Document number:21-022
Document type:OGC Engineering Report
Document subtype:
Document stage:Published
Document language:English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

I.  Abstract

This OGC Testbed 17 Engineering Report (ER) documents the outcomes of a review and implementation of the Sensor Integration Framework Standards Profile (SIF-SP) v1.0.1, published by the National Center for Geospatial Intelligence Standards (NCGIS).

The Sensor Integration Framework Standard Profiles (SIF-SP) authors rightly acknowledge that sensing systems and the environments they operate in (e.g. hardware platform, computing resources, connectivity, ease of deployment, etc.) are very heterogeneous and that there will never be a single suite of technology or standards that can support the goal of providing unified access to sensor deployments employed in complex applications.

Instead, rather than trying to impose a single standard or suite of standards, the SIF-SP approach defines common conceptual models that can be mapped to existing and future standards, thus allowing integration of all these standards in a single framework.

This approach is fully compatible with the OGC Sensor Web Enablement (SWE) suite of standards that were designed for this type of integration. Thus, existing and upcoming SWE standards defined in the OGC can be used as the central pillar of a SIF implementation. The test implementation developed in this testbed, and based on OpenSensorHub, focused on demonstrating this aspect.

In addition to a thorough review of the SIF material — including standards documents, UML models and ontologies — a prototype implementation of the SIF standards was created during the Testbed using OpenSensorHub. This allowed the testbed participants to check the practical feasibility of fulfilling the SIF requirements using the OGC SWE suite of standards. Details and feedback regarding this implementation are also provided in this ER.

Suggestions to improve SIF-SP and make it an integral part of the OGC standard baseline are also provided.

NOTE  Please note that although SIF-SP was developed by military organizations, the approach and concepts are fully applicable to other domains and should thus be considered by a wider audience.

II.  Executive Summary

The OGC Testbed-17 Sensor Integration Thread focused on demonstrating the feasibility of implementing concepts described in the Sensor Integration Framework (SIF) standard developed by National System for Geospatial Intelligence (NSG) and United States MASINT System (USMS). A secondary objective was to demonstrate the possibility of integrating an OGC SensorThings API server with an existing SIF implementation called MASBUS.

The SIF provides a standards framework for the integration of sensor systems regardless of their technical constraints and deployment environment. The SIF thus targets systems that could be deployed on enterprise networks as well as in Denied, Degraded, Intermittent, or Limited Bandwidth (DDIL) environments. During the Testbed, a thorough assessment of the SIF standard documents and data models was first completed. The details of this analysis are provided in this report and the recommendations from the project are as follows:

The second part of this ER describes the implementation of a mediation server based on OpenSensorHub that was used to demonstrate the feasibility of heterogeneous sensor integration as envisioned by SIF. The following data sources were integrated to demonstrate the cross-domain applicability of this study:

The mediation server is able to ingest all data listed previously and make it available via various standard interfaces, including OGC Sensor Observation Service, SensorThings API and SensorWeb API. Experiments were successfully run with both live and historical data.

There is enormous business value in solving the interoperability problem between heterogeneous sensor systems (i.e. systems of different kinds or of the same kind but from different vendors and using different proprietary interfaces). Interoperability is, as of today, the main challenge preventing the original vision of an Internet of Things (IoT) to be full realized. Indeed, the lack of standardization and interoperability between sensor vendors, system integrators and data integration/processing platforms makes it difficult for organizations dealing with large numbers of sensors systems to efficiently process data and control their assets. Although standard protocols enable communications between all kind of devices and systems at low level, large amounts of code are still required to integrate heterogeneous systems so that they can be operated with common tools (e.g. common operating picture). Many domains such as smart cities, smart manufacturing or military operations would greatly benefit from such standardization efforts.

III.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, SIF, sensor, sensor integration, SWE, MISB, ISA, API, moving features

IV.  Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

V.  Security considerations

No security considerations have been made for this document.

VI.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

VII.  Submitters

All questions regarding this document should be directed to the editor or the contributors:

Name Organization Role
Alex Robin Botts Innovative Research / Sensiasoft Editor
Chuck Heazel HeazelTech / NGA Contributor
Mahnoush Mohammadi Jahromi University of Calgary Contributor
Sara Saeedi University of Calgary Contributor

OGC Testbed-17: Sensor Integration Framework Assessment ER

1.  Scope

This OGC Testbed 17 (TB-17) Engineering Report (ER) represents deliverable D030 of the Sensor Integration task.

The ER presents an analysis of the Sensor Integration Framework (SIF) developed for the NSG/MASINT community and suggests a path forward for integrating the SIF vision as part of OGC’s Sensor Web Enablement efforts.

The ER also contains information regarding the SIF implementation that was created during Testbed 17.

2.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

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


Denied, Degraded, Intermittent, or Limited Bandwidth


Full Motion Video


Feature of Interest


Field of View


Hypertext Transfer Protocol


Integrated Sensor Architecture


MASINT Enterprise Service Bus


Measurement and Signature Intelligence


Motion Imagery Standards Board


Message Queuing Telemetry Transport


Observations & Measurements


Observations, Measurements and Samples




Sensor Modeling Language


Sensor Integration Framework


Sensor Integration Framework Standards Profile


Sensor Observation Service


Sensor, Observation, Sample, and Actuator (Ontology)


Sensor Planning Service


Semantic Sensor Network (Ontology)


SensorThings API


SensorWeb API


Sensor Web Enablement


Unmanned Aircraft System


Unmanned Aerial Vehicle

3.  Introduction

Clause 6 introduces the current SIF-SP models and architecture, as well as their mapping to OGC SWE standards.

Clause 7 presents suggested improvements to the existing SIF-SWE mappings. This includes improvements to mappings already defined in SIF as well as mappings to other OGC standards or candidate standards.

Clause 8 presents the SIF implementation developed in Testbed 17, as well as draft conceptual models to bring together the observation viewpoint provided by O&M/OMS, the system viewpoint provided by SensorML and the tasking viewpoint, and also leveraging semantics used in W3C SOSA/SSN.

Annex A provides links to JSON Schemas for SWE encodings as well as code snippets of JSON examples built using the schemas.

Annex B provides the full OpenAPI definition document and query examples for the experimental Sensor Web API that is based on the unified conceptual models discussed in Clause 8.

4.  Key findings

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.

5.  Future Work

This section suggests a path for continuing the work initiated on SIF within the OGC Standards program. What is envisioned is a set of Best Practice documents that would provide guidelines as to how OGC web services, APIs and encodings standards (and SWE standards in particular) can be used jointly to fulfill the requirements described in the SIF reference view. Recommendations are also provided to move SIF-SP forward in the OGC standardization process so that it becomes useful for a broader community.

Some concepts in SIF and the Department of Defense Architecture Framework (DoDAF) are interesting as they help connect the dots between the Observations and Measurements (O&M) model that focuses on sensing activities and the tasking/command side of things that OGC does not have a comprehensive conceptual model for (only services and API). For example, the Performer concept as a generalization of OMS Observer is useful as many operational deployments need to deal both with observation data and command to control various assets.

In addition, the computational requirements expressed in the SIF Reference View are a good base to guide the OGC community for any further work on this topic. They are a good overview of the functionality required by organizations that need to deploy a large number of observing systems and orchestrate their use in a coherent manner.

However, the OGC, ISO and W3C have already developed conceptual models for many aspects of the problem. Therefore, defining new conceptual models as was done as part of the existing SIF work does not seem necessary. From the OGC perspective, it seems more appropriate to refine/extend these OGC conceptual models rather than defining new ones based on DoDAF concepts and mapping them to OGC models.

The following approach is thus recommended to continue this work at OGC:

6.  Review of SIF-SP Documentation

The Sensor Integration Framework (SIF) provides a standards framework for the integration of sensor systems regardless of their technical constraints. The SIF includes a Reference View that defines high level concepts and requirements and a set of Technical Views (TV). Each TV is representative of a typical deployment environment and its associated constraints. A TV defines the standards and provides guidance for the development of sensor systems within the constraints of that deployment environment.

The following three documents of the Sensor Integration Framework Standard Profiles (SIF-SP) were reviewed as part of this Testbed:

This section provides a summary of the concepts and mappings described in these documents.

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:

Enterprise Viewpoint Concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part
Information Viewpoint Concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information
Computational Viewpoint Concerned with the functional decomposition of the system into a set of objects that interact at interfaces

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:

Resource Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.
Activity Work, not specific to a single organization, system or individual that transforms inputs into outputs or changes their state.
Capability The ability to achieve a Desired Effect under specified performance standards and conditions through combinations of ways and means [activities and resources] to perform a set of activities.
Information Information is the state of a something of interest that is materialized — in any medium or form — and communicated or received.
Performer Any entity — human, automated, or any aggregation of human and/or automated — that performs an activity and provides a capability.

6.1.1.  Enterprise Viewpoint  Use Cases

The SIF reference view defines the following use cases:

Use Case 1 Discover Sensor
Use Case 2 Describe Sensor
Use Case 3 Discover Observations
Use Case 4 Describe Observations
Use Case 5 Deliver Discrete Measures
Use Case 6 Deliver Streaming Measures
Use Case 7 Deliver Interactive Streaming Measures
Use Case 8 Set Sensor (or Actuator) Properties  Components

SIF also defines the following enterprise level components:

Service Catalog Discovery
Observation Catalog Discovery
Sensor Manager Command and Control
Observation Server Delivery
Full Motion Video Server Streaming Delivery
Imagery Server Interactive Delivery

6.1.2.  Information Viewpoint (Conceptual Models)  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 TypeDefinition
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.1.3.  Computational Viewpoint

The computational viewpoint refines SIF requirements in terms of capabilities and activities available from the various components of the architecture. The following table summarizes requirements listed for each group of capability:

Table 2 — SIF Messaging Capabilities

Direct Entity sends a message to a specified recipient or group of recipients.
Pub/Sub Entity broadcasts a message which can be received by any number of recipients who subscribes to it.
Message Oriented Middleware Messaging system where the routing decisions are made by the messaging infrastructure, not the sender or recipient.

Table 3 — SIF Discovery Capabilities

Resource Discovery Discover resources regardless of their type.
Content Discovery Discover information resources, including data sets, files, and entries in relational databases.
Process Discovery Discover activities that are available for execution.
Performer Discovery Discover performers available to the user as well as their full description.

Table 4 — SIF Delivery Capabilities

Discrete Delivery Discrete delivery is the delivery of an information resource, either by providing the entire resource itself or a reference to it.
Streaming Delivery With streaming delivery, the client is provided a service access point from which the resource is available as a continuous stream of data (e.g. full motion video, audio, other real-time data feeds).
Interactive Delivery Interactive delivery allows the user to select which parts of a (large) resource to deliver at a time (e.g. large satellite imagery products).
Register Submit a resource to a delivery service so that it will be available for access.

Table 5 — SIF Command Capabilities

Command Issue a command that is used to start, modify, or stop the execution of a process/activity.
Actuation Issue a command that is used to start, modify, or stop the execution of a process/activity.

Table 6 — SIF Sensing Capabilities

Command and Control Covers all of the control and status activities needed to place the sensor where it needs to be, establish the parameters for a successful collection, start and stop the collection.
Sensor Collection Covers the activities performed by emitters, collectors, and all of the support processing required to produce a usable information resource.

Table 7 — SIF Human-Computer Interface (HCI) Capabilities

Query Builder An interface to help building complex queries that are used to filter query results and pub/sub data.
Content Presentation Tools to transform and display the raw data in a way that a human can comprehend.
User Input A way to convert a human input to a machine readable format understood by other components.
Response Handler A piece of software to receive and handle messages from pub/sub data sources asynchronously.

Table 8 — SIF Information Assurance Capabilities

Identification The process of discovering the true identity (i.e., origin, initial history) of a person or item from the entire collection of similar persons or items.
Authentication The act of verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.
Authorization The process of defining and maintaining the allowed actions.
Access Control The ability to allow or deny access to applications and resources at a granular level, such as per-user, per-group, and per-resources.
Confidentiality The ability to protect data so that unauthorized parties cannot view the data.
Integrity The ability to assure that data has not been altered in an unauthorized manner. Data integrity covers data in storage, during processing, and while in transit.
Non-Repudiation The ability to provide protection against an individual falsely denying having performed a particular action.

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.  Mappings to SWE Standards

This section discusses suggested improvements to the SIF mappings to better take into account existing and future OGC standards.

For existing mappings, suggested changes are highlighted in blue in the following tables.

7.1.  SensorML

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

SIF / DoDAF Performer, Activity, Platform, Process
O&M / OMS Procedure, ObservingProcedure, Observer, Host
SSN System, Platform, Sensor, Actuator

7.1.1.  Mappings with SIF Descriptions

Table 9 — Mapping between SIF and SensorML Classes

SIF ClassSensorML ClassComments
Observation DescriptionDataStream
Performer Description
Both type level (i.e. description of a sensor model) and instance level (i.e. description of a particular instance/deployment of a sensor model) descriptions can be implemented with SensorML. The link between the two is done using the typeOf property
Activity Description
Real-World ObjectPhysicalComponent,
When the feature of interest is the system itself (e.g. the aircraft/platform that we measure location of), a SensorML class can be used to model it. In this case the system can be both a Performer and a Real-World Object

Table 10 — Mapping between Activity and SensorML Process

SIF Activity DescriptionSensorML AbstractProcess
Property Name Cardinality Section Name Cardinality Comments
executedBy0..ncontacts, classification0..nPerformer can be referenced using a specific contact role or classifier
processingInformation0..ncharacteristics, capabilities, documentation0..n
hasProcessStep0..ncomponents, connections, method0..nDepending on the desired level of granularity, a SimpleProcess or an AggregateProcess can be used. When an AggregateProcess is used, components and connections are used to define the steps. When a SimpleProcess (atomic process) is used, the steps/algorithms can be described in the method section, either textually or using a more formal language such as MathML.

Table 11 — Mapping between Performer and SensorML Process

SIF Performer DescriptionSensorML PhysicalComponent
Property Name Cardinality Section Name Cardinality Comments
identifier1gml:id, identifier1Recommend using gml:id for local identification only, not to store any representation of the unique identifer which should aim at being globally unique
name0..nname, identifiers0..nMain name is provided by the name property; Further application specific identifiers can also be provided
definition0..1definition, classifiers0..nThe main definition specifies what this physical component is through a URI which resolves to an element in the SIF-SP ontology. More (domain) specific classifiers can also be provided (e.g. sensor or platform type).
extent0..1boundedBy0..1The boundedBy property could be used although in this case it is meant to be the extent within the performer operates, not the extent of the feature itself
observables0..noutputs, featuresOfInterest
pointOfContact0..ncontacts0..nModeled as ISO 19115 CI_ResponsibleParty
position0..1position0..nIn SensorML, position can be specified inside the component or system itself, or in the description of the system that encapsulates it (hence the 0..n cardinality).
properties0..ncharacteristics, capabilities, parameters0..n
commands0..nparameters0..nCommands are modeled using parameters marked as ‘updatable’
hasComponent0..ncomponents0..nWhen a PhysicalSystem is used, components can be described individually
isPartOf0..1attachedTo0..1Used to navigate up the hierarchy of components
executes0..ntypeOf1..1Performer is associated with Activity/Process though inheritance

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:

SIF / DoDAF Observation properties,
Performer parameters,
Performer capability,
Command inputs/outputs/parameters,
Activity inputs/outputs/parameters
O&M / OMS Observation result,
Observation parameters
SSN / SOSA Result,

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.2.1.  Supported Encodings

Various encodings are supported by the SWE Common standard. Compression methods are also supported via the BinaryEncoding (See Clause 8.13 in the implementation section).

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.3.1.  Definitions

Before presenting a mapping between O&M/OMS and SIF, the key concepts of O&M/OMS are summarized below:  Observation

An Observation is an act associated with a discrete time instant or period through which a number, term, or other symbol is assigned to a phenomenon. An observation involves application of a specified Procedure, such as a sensor, instrument, algorithm, or process chain. The procedure may be applied in-situ, remotely, or ex-situ with respect to the sampling location. The result of an observation is an estimate of the value of a property of some feature.  ObservableProperty

An observable quality (property, characteristic) of the feature of interest that may be observed.  FeatureOfInterest

The Feature that is the subject of the Observation. More discussion on modeling features of interest is provided in section Clause 8.10.  Procedure

A description of steps performed. More specifically, an ObservingProcedure describes the steps performed by an Observer to generate an Observation. Likewise, a SamplingProcedure describes the steps performed by a Sampler in order to extract a Sample from a sampled feature.  Observer (OMS v3 only)

An identifiable entity that may generate Observations by performing a certain Procedure.  Host (OMS v3 only)

A grouping of Observers for a specific reason.  Deployment (OMS v3 only)

Information on the assignment of an Observer to a Host.  Observation Result

The result of an Observation. The O&M conceptual models are agnostic of the result type and different result types can be modeled to accommodate the needs of different domains.

However, one thing to note is that OGC SWE Common Data Model (see Clause 7.2) provides a generic model for describing result types across communities. It allows defining both simple and more complex result types by providing a semantically robust schema and encoded values for the observation result.

7.3.2.  Mappings with SIF Concepts

The following table provides recommended mappings between O&M v2 classes and SIF / DoDAF concepts:

Table 12 — Mapping between SIF and O&M v2 Concepts

SIF ClassO&M ClassComments
Observation Description-
PerformerProcedureBoth Performer and Activity are mapped to Procedure which caused confusion in many applications of O&M in the past. These two concepts have been separated in OMS v3 for this reason (see below).
Real-World ObjectFeature,
as featureOfInterest,
as samplingFeature,
as sampledFeature

The following table provide recommended mappings between OMS v3 classes and SIF / DoDAF concepts:

Table 13 — Mapping between SIF and OMS v3 Concepts

SIF ClassOMS ClassComments
Observation DescriptionObservation Collection
Real-World ObjectFeature,
as featureOfInterest,
as proxyFeatureOfInterest,
as ultimateFeatureOfInterest

NOTE  SIF defines a “realizes” relationship between Observation and Observable. We think that may not be the best way to model this relationship as the Observation result is an “estimate” of the value of the Observable at a given point it time.

7.3.3.  Encodings

XML encodings for O&M 2.0 have been released as part of OGC O&M [10-025r1]. They are used by the Sensor Observation Service in particular.

JSON encodings for O&M 2.0 have been released as an OGC Discussion Paper (OGC 15-100r1) and can be used as a basis for OGC APIs serving observation resources.

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.4.1.  Mappings with SIF Information Model

SIF ClassSWE ClassComments
PerformerSensorML process or system description in SOS/SPS DescribeSensor and SOS InsertSensor
ObservationO&M Observation in SOS GetObservation and InsertObservation
Observation DescriptionObservationOffering in SOS Capabilities
Observablevia reference to external ontologies only
Command DescriptionSWE Common parameters within SPS DescribeTaskingResponse
CommandSWE Common encoded message
Real-World ObjectGML Feature in GetFeatureOfInterest

7.4.2.  Mappings with SIF Enterprise Viewpoint

SIF Use CaseSWE Service OperationComments
Discover SensorSOS/SPS GetCapabilitiesNeed to browse through offerings
Describe SensorSOS/SPS DescribeSensor
Discover ObservationsSOS GetCapabilitiesNeed to browse through observation offerings
Describe ObservationsSOS GetResultTemplateDoes not include all static observation metadata, just the result structure and observables
Deliver Discrete Measures
(Server to Client)
SOS GetObservation or GetResultFiltering can be used
Deliver Discrete Measures
(Sensor to Server)
SOS InsertObservation or InsertResult
Deliver Streaming MeasuresNon-standard websocket extension available in OSH SOS implementationFiltering can be used
Set Sensor (or Actuator) PropertiesSPS Submit
Deliver Interactive Streaming Measures Out of Scope

7.4.3.  Mappings with SIF Computational Viewpoint

SIF CapabilitySOS/SPS Operation/ProtocolComments
Direct MessagingSOS-SPS Get operations via HTTP GET.
Post MessageSOS Insert operations via HTTP POST.
SPS Submit via HTTP POST.
Deliver MessageSOS-SPS Get operations via HTTP GET.
Publish-Subscribe MessagingPossible for SPS task status updates using WS-Notification
SubscribeWS-Notification Subscribe operation
NotifyWS-Notification Notify operation
Route Message-

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: