TC_4 Sensor Registry

From
Revision as of 14:20, 26 August 2020 by Alexander Zilliacus (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Background[edit]

Short description[edit]

The "sensor registry" aims at supporting the management of sensors deployed for in-situ measurements.
Three 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, …
  3. Edit deployments, enable traceability from observation data back to the sensor and procedures used for acquisition (link with implementation case on provenance IC_3).

The use case is applicable to the management of various types of platforms, deep-sea observatories (e.g. EMSO), marine gliders (e.g. {+}http://eurogoos.eu/gliders-task-team/+) as well as solid earth (EPOS) or atmosphere (ICOS) observations.
This can also be used to track usage of specific sensor models (e.g. CO2) across the RI 's observation networks.

Contact[edit]

Background Contact Person Organization Contact email
RI-ICT (Use Case Proposor, Agile Group leader) Thomas Loubrieu Ifremer Thomas.loubrieu@ifremer.fr
ICT Alex Hardisty Cardiff Univ HardistyAR@cardiff.ac.uk
RI (EMSO) Jean-Francois Rolin Ifremer jrolin@ifremer.fr
RI (EMSO) Eric Delory Plocan eric.delory@plocan.eu
RI (Euro-ARGO) Grigor Obolensky Euro-ARGO Grigor.Obolensky@ifremer.fr
RI (Euro-ARGO, gliders) Justin Buck NERC/BODC juck@bodc.ac.uk
RI (marine gliders) Victor Turpin LOCEAN victor.turpin@locean-ipsl.upmc.fr
RI (EPOS) To Be Defined RESIF To Be Defined
RI (Drone) To Be Defined To Be Defined To Be Defined
RI (ICOS) Jean-Daniel Paris, Leonard Rivier, Lynn Hazan, IPSL jean-daniel.paris@lsce.ipsl.fr
leonard.rivier@lsce.ipsl.fr
leonard.rivier@lsce.ipsl.fr
lynn.hazan@lsce.ipsl.fr

Use case type[edit]

Test case

Scientific domain and communities[edit]

Scientific domain

  • atmosphere
  • hydrosphere
  • geosphere


Community

  • Data acquisistion
  • Data curation
  • Data service provision
  • Data usage


Behavior

To be done

Detailed description[edit]

Objective and Impact

Identified impacts are:

  • Shared knowledge across RI of on-the-shelf available sensors, specifications, costs…
  • Optimal use of sensor resources within RI by using tools to manage the network of sensors, calibration planning, spare parts, …
  • Better qualification, error bars on data by harmonized and high level documentation on data acquisition conditions.


Challenges

Main challenge is to satisfy the users which will maintain the sensor registry content : operators in charge of sensor maintenance, researcher in charge of the deployment.
This challenge can be overcome by 2 actions:

  • provide them with very user-friendly interfaces and services around this sensor registry (e.g., alerts or schedule for calibration, deployment reports, …) at RI level or cross-cutting.
  • enable interoperability with pre-existing and well established tools and systems maintained in the RI.


Detailed scenarios

Scenarios to be detailed are:

  • Edit a sensor model
  • Browse sensor model list
  • Edit a sensor instance, Use a sensor model to describe a sensor instance
  • Schedule, get alerts related to the maintenance of a network of sensors
  • Register operations and publish operation reports on sensors
  • Edit a deployment (on fixed or mobile platform), get a deployment report including graphical schemes.
  • Enable traceability from observation data back to the sensor and operations carried on the sensor (e.g., latest calibration), see connexion with provenance implementation case (IC_2).


Technical status and requirements

<Please describe the possible components in what detail you can, considering both functionality and current status (e.g. does it involve existing tools/data?). Please also consider the requirements for the use case.>

  1. Models: Sensor and hardware model distributed registry. Example available for EMSO RI: {+}http://www.esonetyellowpages.com/+
  2. Instances and operations: Sensor and hardware instances and operation distributed registry and tools (edition, reports, alerts, …). Example : LabCollector ({+} http://www.labcollector.com/+)
  3. Deployments: Sensor deployment edition, deployment report, traceability in observation data. Example : 52°North suite ({+}http://52north.org/+). Under development sensor nanny (see screenshot).

Worddavdd1294de25b573d15b80b19fa13cf455.png


Implementation plan and timetable

  1. Timeline
    1. Models: end 2016
    2. Instances and operations: 06/2017 (operations is an option)
    3. Deployments: end 2017
  2. Involved RI: EMSO, EPOS, Euro-ARGO, marine gliders, ICOS, drones,
  3. Resources in task 8.2 (catalogue), 8.3 (provenance) WP5 (reference model) and deployment (WP9). RI are also involved for tools reviews , requirement definition and test.


Expected output and evaluation of output

Possible measurable criteria on the success of the use case are:

  • Number of sensors or operations descriptions actually available
  • Number of observation data acquisition conditions documented (provenance links back to records in the sensor registry).

External Links[edit]

  1. TC_4 notebook: {+}https://envriplus.manageprojects.com/projects/wp9-service-validation-and-deployment-1/notebooks/655+