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:
-
OGC should continue to promote the SIF vision of integrated sensor systems as it is fully inline with the vision behind the OGC Sensor Web Enablement (SWE) standards.
-
The SIF can be refined/developed further at OGC by defining Best Practices based on existing OGC SWE standards, not by developing new data models.
-
OGC standards provide conceptual models and encodings to solve the interoperability issue at the syntactic level, but more work is needed to improve interoperability at the semantic level.
-
A fully harmonized conceptual model that encompasses, not only sensor observations but also command and control aspects, needs to be developed at OGC.
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:
-
Unmanned Aircraft System (UAS) video and telemetry data extracted from video conforming to Motion Imagery Standards Board (MISB) standards
-
UAS processed data for image and target georeferencing
-
Measurement and Signature Intelligence (MASINT) sensor data obtained from a MASBUS Sensor Observation Service
-
Chemical, Biological, Radiological, Nuclear, and Explosive (CBRNE) sensor data using the US Army ISA protocol
-
Entire water database from the United States Geological Survey (USGS)
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):
- Botts Innovative Research Inc.
- Sensiasoft LLC
- HeazelTech LLC
- University of Calgary
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
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
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:
-
Use SIF requirements as a guide for the overall architecture (refine and extend them as required). Maintain clear mappings from requirements to solutions proposed in the models and APIs. Produce an overall architecture document explaining how OGC standards fit together to implement the requirements documented in SIF.
-
Rather than DoDAF concepts, use SWE conceptual models as the core models for SIF (O&M/OMS, SensorML, SWE Common, SOSA/SSN, and see unified model presented in this ER).
-
From both observation and command & control sides, work on a better conceptual model that unifies the system view and the data view (see proposal in this ER). Existing OGC conceptual models (O&M/OMS, SensorML and SWE Common) fit into this larger model.
-
Map OGC SWE services to these core models in technical view 1 (SOS/SPS, SensorThings API, or a future OGC Sensors API).
-
Map specialized OGC services and APIs to these core models when appropriate (e.g. EDR).
-
Map any other standards to these core models through technical views (e.g. ISA, MISB, NITF, AIXM, WXXM, OPC-UA, etc.).
-
Focus on defining semantics, based on W3C SSN ontology in order to provide more specific concept definitions (such as mathematical objects used to represent mechanical state, generic qualifiers for observables like spectral bands, etc.).
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:
| Concept | Description |
|---|---|
| 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
6.1.1.1. 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 |
6.1.1.2. Components
SIF also defines the following enterprise level components:
| Component | Capability |
|---|---|
| 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)
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.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
| Capability | Description |
|---|---|
| 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
| Capability | Description |
|---|---|
| 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
| Capability | Description |
|---|---|
| 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
| Capability | Description |
|---|---|
| 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
| Capability | Description |
|---|---|
| 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
| Capability | Description |
|---|---|
| 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
| Capability | Description |
|---|---|
| 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 Class | SensorML Class | Comments |
|---|---|---|
| Observation | - | |
| Observation Description | DataStream | |
| Observable | ObservableProperty | |
| Performer, Performer Description | PhysicalComponent, PhysicalSystem | 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, Activity Description | SimpleProcess, AggregateProcess, | |
| Real-World Object | PhysicalComponent, PhysicalSystem | 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 Description | SensorML AbstractProcess | |||
|---|---|---|---|---|
| Property Name | Cardinality | Section Name | Cardinality | Comments |
| input | 1..n | inputs | 0..n | |
| output | 1..n | outputs | 0..n | |
| method | 0..1 | method | 0..1 | |
| parameters | 0..n | parameters | 0..n | |
| executedBy | 0..n | contacts, classification | 0..n | Performer can be referenced using a specific contact role or classifier |
| processingInformation | 0..n | characteristics, capabilities, documentation | 0..n | |
| hasProcessStep | 0..n | components, connections, method | 0..n | Depending 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 Description | SensorML PhysicalComponent | |||
|---|---|---|---|---|
| Property Name | Cardinality | Section Name | Cardinality | Comments |
| identifier | 1 | gml:id, identifier | 1 | Recommend using gml:id for local identification only, not to store any representation of the unique identifer which should aim at being globally unique |
| name | 0..n | name, identifiers | 0..n | Main name is provided by the name property; Further application specific identifiers can also be provided |
| definition | 0..1 | definition, classifiers | 0..n | The 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). |
| extent | 0..1 | boundedBy | 0..1 | The 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 |
| observables | 0..n | outputs, featuresOfInterest | ||
| pointOfContact | 0..n | contacts | 0..n | Modeled as ISO 19115 CI_ResponsibleParty |
| position | 0..1 | position | 0..n | In 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). |
| properties | 0..n | characteristics, capabilities, parameters | 0..n | |
| commands | 0..n | parameters | 0..n | Commands are modeled using parameters marked as ‘updatable’ |
| state | ||||
| hasComponent | 0..n | components | 0..n | When a PhysicalSystem is used, components can be described individually |
| isPartOf | 0..1 | attachedTo | 0..1 | Used to navigate up the hierarchy of components |
| executes | 0..n | typeOf | 1..1 | Performer 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, SystemCapability, SystemProperty, ObservableProperty, ActuatableProperty, Condition |
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:
7.3.1.1. 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.
7.3.1.2. ObservableProperty
An observable quality (property, characteristic) of the feature of interest that may be observed.
7.3.1.3. FeatureOfInterest
The Feature that is the subject of the Observation. More discussion on modeling features of interest is provided in section Clause 8.10.
7.3.1.4. 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.
7.3.1.5. Observer (OMS v3 only)
An identifiable entity that may generate Observations by performing a certain Procedure.
7.3.1.6. Host (OMS v3 only)
A grouping of Observers for a specific reason.
7.3.1.7. Deployment (OMS v3 only)
Information on the assignment of an Observer to a Host.
7.3.1.8. 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 Class | O&M Class | Comments |
|---|---|---|
| Observation | Observation | |
| Observation Description | - | |
| Observable | ObservableProperty | |
| Performer | Procedure | Both 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). |
| Activity | Procedure | |
| Real-World Object | Feature, SamplingFeature, 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 Class | OMS Class | Comments |
|---|---|---|
| Observation | Observation | |
| Observation Description | Observation Collection | |
| Observable | ObservableProperty | |
| Performer | Observer, Host | |
| Activity | Procedure, ObservingProcedure, SamplingProcedure | |
| Real-World Object | Feature, 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 Class | SWE Class | Comments |
|---|---|---|
| Performer | SensorML process or system description in SOS/SPS DescribeSensor and SOS InsertSensor | |
| Activity | - | |
| Observation | O&M Observation in SOS GetObservation and InsertObservation | |
| Observation Description | ObservationOffering in SOS Capabilities | |
| Observable | via reference to external ontologies only | |
| Command Description | SWE Common parameters within SPS DescribeTaskingResponse | |
| Command | SWE Common encoded message | |
| Real-World Object | GML Feature in GetFeatureOfInterest |
7.4.2. Mappings with SIF Enterprise Viewpoint
| SIF Use Case | SWE Service Operation | Comments |
|---|---|---|
| Discover Sensor | SOS/SPS GetCapabilities | Need to browse through offerings |
| Describe Sensor | SOS/SPS DescribeSensor | |
| Discover Observations | SOS GetCapabilities | Need to browse through observation offerings |
| Describe Observations | SOS GetResultTemplate | Does not include all static observation metadata, just the result structure and observables |
| Deliver Discrete Measures (Server to Client) | SOS GetObservation or GetResult | Filtering can be used |
| Deliver Discrete Measures (Sensor to Server) | SOS InsertObservation or InsertResult | |
| Deliver Streaming Measures | Non-standard websocket extension available in OSH SOS implementation | Filtering can be used |
| Set Sensor (or Actuator) Properties | SPS Submit | |
| Deliver Interactive Streaming Measures | Out of Scope |
7.4.3. Mappings with SIF Computational Viewpoint
| SIF Capability | SOS/SPS Operation/Protocol | Comments |
|---|---|---|
| Direct Messaging | SOS-SPS Get operations via HTTP GET. | |
| Post Message | SOS Insert operations via HTTP POST. SPS Submit via HTTP POST. | |
| Deliver Message | SOS-SPS Get operations via HTTP GET. | |
| Publish-Subscribe Messaging | Possible for SPS task status updates using WS-Notification | |
| Publish | - | |
| Subscribe | WS-Notification Subscribe operation | |
| Notify | WS-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: