TC_4 Sensor Registry

1. Background

1.1 Short description

The "sensor registry" aims at supporting the management of sensors deployed for in-situ measurements.
Three sub-use cases are considered:

...

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.

1.2 Contact

1.3 Use case type

Test case

1.4 Scientific domain and communities

Scientific domain

• atmosphere
• hydrosphere
• geosphere

Community

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

Behavior

To be done

2. Detailed description

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).

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:

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