Page tree
Skip to end of metadata
Go to start of metadata

Overview

The “sensor registry” aims at supporting the management of sensors deployed for in-situ measurements. Common sensors or families of sensors are used across different research infrastructures, for example, oxygen optodes that are equipped on platforms in multiple research infrastructures. The goal of this work is to define common methods to access the sensor metadata in such cases.

Four sub-use cases are considered:

  1. List and discover specifications of sensors and hardware on the market.
  2. Manage the park of sensor by owner, manage maintenance (e.g. calibrations), loan, etc.
  3. Edit deployments, enable traceability from observation data back to the sensor and procedures used for acquisition (link with implementation case on provenance IC_2).
  4. Discover infrastructures (observation network, equipped experiment sites, etc.) and enable their citation.

The use case is applicable to the management of various types of platforms, deep-sea observatories (e.g., EMSO), marine gliders (e.g., EuroGOOS gliders) as well as solid earth (e.g., EPOS) or atmosphere observations (e.g., ICOS).

This can also be used to track usage of specific sensor models (e.g., CO2) across the RI ‘s observation networks.

Scientific Objectives

The objective of Standardised sensor repositories to enable:

  • Easily discover sensors and their metadata
  • Sensors and sensor observations discoverable, accessible and usable via the web via standardised services
  • Seamlessly integrate sensors from one network with sensors from other networks

The sensor registry is based on OGC Sensor Web Enablement technologies (SWE) that have been developed and implemented by a range of national and European projects and activities. As part of the FP7 and H2020 projects ODIP, ODIP2, Oceans of tomorrow call and the BRIDGES project the Marine SWE profile was developed. The marine SWE profile is a marine specialisation of the OGC SensorML (for metadata) and OGC Observations & Measurements (O&M) standards. A significant advance within these templates was the use of controlled vocabularies to describe terms and values within the SensorML documents. The NERC vocabulary server (NVS, part of the European SeaDataNet infrastructure) was used to host the vocabularies. The vocaularies are the Wxx family of vocabularies and accessible at https://www.bodc.ac.uk/resources/vocabularies/vocabulary_search/. In addition to the human interface the NVS has machine readable access methods including SPARQL and SOAP with outputs including RDF, XML and JSON. The standards developed in the OoT projects are summarised in the SenseOcean project  joint deliverable D7.8 which also included future recommendations for future work.

Key outcomes of the marine SWE profile are:

  • Standardized web services will exist for accessing sensor information and sensor observations
  • Sensor systems will be capable of real-time mining of observations to find phenomena of immediate interest (event stream processing)
  • ISO/OGC O&M as data format and the OGC SOS as data access interface enable EC INSPIRE directive compliance with the data format
  • The associated OGC Sensor Observation Service (SOS) would be the natural way to achieve full INSPIRE compliance  (there exists additional INSPIRE technical guidance that describes how to use the SOS as INSPIRE download service).

Our goal in this test case is to demonstrate which elements of the standardised interface to data are available and how they could potentially be integrated. The development has happened across a number of projects and the alignment of the results is not fully achieved because each project has different requirements and deliverables. Consequently examples will be shown from different activities demonstrating each goal in the introduction. The outcomes of the WP9 Test Case TC_4 Sensor registry include:

  • Proposed goal to attempt to link repositories to users for specific examples
  • Demonstrate viability of the technology and test interoperability
  • Act as a precursor to future projects with broader linkages and harvesting

Description

List and discover specifications of sensors and hardware on the market.

For the RIs SIOS, EMSO, ANAEE, ICOS and CSEM, examples of sensor, site, station or platform descriptions have been collected in their native formats. The information models and tools used to manage the descriptions have also been shared.

Regarding standards, a sample of SIOS station description has been encoded in OGC/SensorML format. Examples of SSN ontology encoding and translation from SensorML to SSN have been provided from FixO3 project inputs.

One of the commonly used software packages for providing OGC SWE services in European projects is the 52°North Sensor Observation Service (SOS). This provides an interoperable web-based interface for inserting and querying sensor data and sensor descriptions. It aggregates observations from live in-situ sensors as well as historical data sets (time series data). This server component is complemented by an extensible Web-based JavaScript Sensor Web viewer which allows the visualisation of different types of sensor observation data: the 52°North Helgoland Viewer. More information is available from: https://52north.org/ .

These concepts have been used by the Oceanids Command and Control project along with the outcomes of the Marine SWE profile to store and expose the metadata for ocean glider deployments to the web. These metadata are then used to automate the curation and conversion of raw glider data to the EGO NetCDF (http://archimer.ifremer.fr/doc/00239/34980/ ) format which is the data exchange format within the Ocean Glider Network. Oceanids uses a database that supports both SSN and SensorML metadata representations so is strongly aligned with this demonstrator. The same database is being used for historical EMSO data (specifically the PAP site) that is held by BODC and development is on-going to expose the metadata in SensorML and data in O&M formats, this is scheduled to be complete in late 2018.

Figure 10. Sensor Deployment Graphical Editor and Sensor Model Database for EMSO

Figure 11. Data Model For ANAEE and ICOS Sensor Descriptions

Manage the park of sensor by owner, manage maintenance (e.g. calibrations), loan, …

The recording of a sensor history is now technically possible and facilitated by the SensorML template produced within the Marine SWE profile. To date this has not been fully implemented to the authors knowledge. BODC will be introducing the linking of documentation to SensorML records in the development scheduled prior to March 2019.

Edit deployments, enable traceability from observation data back to the sensor and procedures used for acquisition (link with implementation case on provenance IC_3).

For users of the 52°North software (one of the primary open source OGC SWE software suites) there has been a SensorML editor SMLE (pronounced smilee) that enables users to interact with and edit SensorML documents held in  OGC compliant SOS servers via a graphical user interface (editing is only supported for SOS servers supporting the transactional SOS operations). This is freely available from: https://github.com/52North/smle

Discover infrastructures (observation network, equipped experiment sites...) and enable their citation.

The discovery of infrastructures requires the recently developed federated sensor observation services. These have not been trialed or investigated on the marine domain to the authors knowledge at the time of writing. They may need refinement for the specific requirements of the use case, akin to the Marine SWE profile activity. Work on evaluation of these services was a key recommendation of the OoT projects (see previous reference above).

The citation of sensors is a on-going development activity in a newly formed Research Data Alliance working group on the persistent identification of sensors (https://www.rd-alliance.org/groups/persistent-identification-instruments-wg ).

Advantages

Standardised machine-readable sensor metadata links directly to the catalogue and provenance work in WP8 of ENVRIplus, it provides a machine-readable document can be linked to data filling a current capability gap in the provenance trace.

Common metadata standards allow the sharing of metadata and federation between RIs, especially as the scientific community moves toward observation requirements that span multiple RIs

The service has potential users spanning the data lifecycle and value chain. The standards are applied at the time of observation and can be embedded within sensors. At the other end of the chain they will enable users to dynamically harvest and discover data for use cases such as oil spill response. Using standard such as OGC SOS and ISO/OGC O&M this will even result in the INSPIRE compliant provision of observation data.

Usage scenarios include:

  • Embed in the standards within sensors or data processing systems to allow the automated processing and dissemination of data
  • Standardised machine readable recording and linking of metadata to a data provenance trace
  • Inclusion of data in OGC SWE services and endpoints
  • The standardised sharing of sensor metadata between organisations and RIs
  • The citation of specific sensors (dependent on the results of the RDA working group)

Link to the Demonstrator

Link to ESONET yellow pages: https://www.esonetyellowpages.com/

Link to selected 52North instances:

Example SensorML output from that follows the Marine SWE profile:

  • BODC

○      A model of an Aanderaa oxygen optode: http://linkedsystems.uk/system/prototype/TOOL0969 /current/

○      An instance of an oxygen optode: http://linkedsystems.uk/system/instance/TOOL0969_prospect/current/

  • OGS

○      An instance of a Wind Monitor-JR: http://europa.ogs.trieste.it/OGS_SOS/SensorML_3_0/Sensor_V3_E2M3A_WIND.xml

○      An instance of SBE 37-SMP-ODO MicroCAT high-accuracy conductivity and temperature  recorder: http://europa.ogs.trieste.it/OGS_SOS/SensorML_3_0/Sensor_V3_E2M3A_CT.xml

Contributors


  • No labels