2.2.1.1 Defining sensing requirements

Maritime guidance is highlighted

Authors: ALADDIN demonstrator project

Overview of approach

Sensing is key to enabling an autonomous robot to observe both its own state and the environment in which it is operating. These observations enable the robot to reason about the state of the world and the progress towards its goals, informing subsequent decisions about which actions it should take next. Therefore, when defining the sensing requirements for an autonomous system, we need to consider:

1. The goal or goals the system is seeking to achieve through its operation
2. Sensors that sense the system itself
3. Sensors or external data sources that provide information on the operating environment
4. Associated metadata

In this guidance, we consider the sensing requirements of an Autonomous Underwater Vehicle (AUV) as the domain-specific example studied in the ALADDIN project.

This guidance is highlighted in blue throughout.

However, the general considerations presented here share much in common with other robotic domains and thus the key concepts should be transferable to other domains.

1) Consideration of goals and associated sensors

When defining the sensing requirements of a robotic system, we first need to consider its intended functionality and what we intend to gain as a result of its operation. The majority of ocean-going AUVs are typically deployed with the goal of collecting data, for example, to inform oceanographic science or to monitor subsea infrastructure. As a result, this data collection goal forms the success criteria for the operation of the robotic system and thus the primary sensing requirement. Such sensors are often known in the AUV literature as payload sensors, and we will use this terminology here for clarity. However, in many cases, the line between payload sensors associated with the completion of mission goals, and sensors used for navigation etc are often blurred, with overlap exploited for efficiency benefits.

AUV example: An AUV may be tasked with completing a bathymetric survey of the seafloor, operating at a depth of 6000m below the sea surface. As the success criteria of the mission is the delivery of the bathymetry dataset, the sensing requirements of this deliverable should be considered first, e.g.:
 * What resolution is required?
 * What quality control metrics or constraints does the dataset need to satisfy?
 * What format does the data need to be delivered in?
 * Are there any environmental constraints (e.g. salinity, water clarity etc.), which may influence data quality?
 * Do I have sufficient power, space and buoyancy available to be able to operate this sensor on-board my chosen robot?
For many battery-driven AUVs (and other forms of mobile robot) there is likely to be a trade-off between data quality, power/space requirements, endurance and reliability.

For all sensors, calibration is fundamental to ensure that accurate measurements are made. All sensors should be calibrated before robotic and autonomous systems are deployed and regular checks are needed during operation to quantify the uncertainty in the sensor readings. More information on sensor calibration is provided by the National Physical Laboratory [1].

2) Sensing the state of the system itself

In order to operate as intended and to react to or reason about its own capabilities, the robotic system will require sensors to observe its own state. Within our AUV example, these can range from sensors that are integral to the operation of the robotic system, such as inertial navigation systems, to sensors that are installed specifically to detect faults and adverse behaviour, such as those which detect water leaks or an electrical ground fault. We can broadly group these sensors into four categories:

1. Sensors for navigation (e.g. inertial measurement units)
2. Sensors that provide control feedback from actuators (e.g. encoders for propeller rpm)
3. Sensors that monitor the health of the system (e.g. for detecting water leaks)
4. Sensors for communication (e.g. acoustic modems).

Much like payload sensors, sensors that sense the state of the system itself should ideally be configurable, enabling the choice of sensors to be optimised to suit the goals and constraints of a given operation. When determining the sensing requirements of these sensors, we recommend first defining the critical items list and associated safety functions. The critical items list is a widely used tool in reliability engineering that is defined through study of the system design specification, for example using Failure Mode and Effect Analysis (FMEA) [2], and summarises elements of the system whose failure modes may compromise its ideal function. Such failure modes can range from serious injury or loss of life to humans in the operating vicinity, to failure to complete the goals of the mission or meet the mission success criteria. Safety functions, which define mitigations to reduce the identified risk, should then be assigned to each element of the critical items list.

AUV example: For AUV applications, we start defining the critical items list with those with the most severe consequences and impacts (e.g. those which compromise human safety followed by those which put the AUV at an increased risk of becoming lost at sea). For robotic systems, additional sensors can be integral to implementing safety functions. Such over-observed systems are common when the impacts of potential failure are high, such as in automotive and aerospace, with sensor redundancy creating additional fault tolerance. For example, water ingress to an AUV pressure vessel can cause a critical failure, damaging batteries, electronics or, in the case of a severe flood, reducing the buoyancy of the system causing the AUV to sink to the seafloor. In order to provide early warning and enable an AUV to detect and mitigate against such an event, leak detection sensors can be installed within pressure vessels.

The data from sensors that sense the state of the system itself can both be used at run-time, to react to events or detect developing faults (such as developments made during the ALADDIN programme), and as part of long-term reliability analyses to provide assurance that the system and safety cases are operating as intended and inform future designs.

3) Sensing the operating environment

In addition to being able to sense its own state, it is important for a robotic system to also be able to sense the state of the environment in which it is operating. Such sensing capability can be provided by both sensors onboard the robot itself and external sources of data, either provided a priori or sent to the robot during operation.

Onboard sensors

Sensors such as altimeters provide information to the robotic system about the environment, but this is typically used to increase the estimate of robot state, for example, using terrain-aided navigation and SLAM (Simultaneous Localisation and Mapping) techniques to localise the robot within its environment. Others, such as those which measure temperature and salinity, provide both environmental measurements of scientific value, as well as enabling the calibration of other sensors, for example acoustic modems. Thus, when determining the sensing requirements for the operating environment, it is key to identify areas of overlap, where data from a given sensor can be potentially reused to increase the quality of data collected elsewhere by the robotic system and thus the success metrics for a given mission. When considering battery powered AUVs and other mobile robots, the multi-purpose nature of such sensors enables the utility of the mission to be maximised given limited battery availability.

External sources of data

In addition to data from the robotic system itself, external data sources can also be used to provide sensor information about the environment. In the context of AUVs, these datasets include satellite observations, data from nearby platforms such as Argo floats [3] and moorings, as well as fixed-platform observatories [4].

AUV example: Copernicus [5] is the European Union's Earth Observation Programme, combining data from satellite, ground-based, airborne and seaborne measurement systems. The information services provided are open and freely available to all users. The system has a dedicated service specific for marine data and products [6], e.g. assimilated models including Forecast Ocean Assimilated Model (FOAM) and Atlantic Margin Model (AMM) [7]. The satellite data provides altimetry, chlorophyll, sea surface temperature, resolving mesoscale features such as eddies and fronts.

Due to the need to assimilate data from remote platforms to a data centre and compile a distributable data product, observational data from services such as Copernicus will only be available sometime after the observation was made. This can prove useful for providing information on environmental trends across longer timescales but cannot be used at run-time. Instead, models such as FOAM provide a prediction of the current state of physical properties such as ocean currents, which can be used at run-time to inform AUV decision making.

4) Associated metadata

Whilst not directly recorded by the sensor itself, metadata is essential to the correct interpretation of data from both the robotic system and its sensors.

AUV example: In the case of an AUV, the metadata includes:
 * The dates and locations of the AUV deployment.
 * The names and identifiers of the associated project and key people involved.
 * The manufacturer, model and serial number of the robotic system, along with serial numbers of component parts such as sensors.
 * Data formats.
In the UK, the British Oceanographic Data Centre (BODC) is the designated national marine data centre for the Natural Environment Research Council (NERC). Sensor data from marine robotic systems, such as ocean gliders, is submitted to BODC for archiving and distribution to users of the data. To enable interpretation of the data, sensor data from the gliders is associated with accompanying metadata in the Marine Sensor Web Enablement (SWE) SensorML format [8], [9], which specifies properties of the sensor itself (e.g. make, model and serial number) and the parameters it measures (e.g. units). In addition, to create interoperable metadata, the Marine SWE SensorML makes use of the NERC vocabulary server [10] to standardise terminology and provide a controlled, consistent, machine-readable definition for variables (e.g. salinity) and units, etc.

Other sources of metadata which are key for the assurance of the robotic system and its operation are documentation and logs made by human operators and maintainers both before, during and after the system is operated in the field or executes a mission. These include:

• Functional test reports (including the weight and buoyancy of the AUV, for example) prior to a mission.

• Functional test reports (including the weight and buoyancy of the AUV, for example) prior to a mission.

• Condition reports which detail the state of the system upon completion of the operation (e.g. noting the presence of any biofouling, scratches, dents etc on the AUV).

• Condition reports which detail the state of the system upon completion of the operation (e.g. noting the presence of any biofouling, scratches, dents etc on the AUV).

• Observations logged by human operators during the mission (e.g. sea state and weather conditions on launch and recovery, any observed adverse behaviour, etc.).

• Observations logged by human operators during the mission (e.g. sea state and weather conditions on launch and recovery, any observed adverse behaviour, etc.).

Ideally, such documentation should be in standardised machine-readable formats, to aid subsequent inclusion in automated reliability analysis as well as processing by fault detection and diagnosis algorithms.

References

• [1] National Physical Laboratory. https://www.npl.co.uk/products-services/instruments/artefact Accessed 24/03/2021.
• [2] IEC, 60812:2018: Failure modes and effects analysis (FMEA and FMECA), 2018.
• [3] Argo data. https://argo.ucsd.edu/data/ Accessed 01/03/2021.
• [4] European Multidisciplinary Seafloor and water column Observatory (EMSO). https://data.emso.eu/home Accessed 01/03/2021.
• [5] Copernicus. https://www.copernicus.eu/en/access-data Accessed 01/03/2021.
• [6] Copernicus Marine Service. https://marine.copernicus.eu/ Accessed 01/03/2021.
• [7] Atlantic - European North West Shelf - Ocean Physics Analysis and Forecast. https://resources.marine.copernicus.eu/?option=com_csw&view=details&product_id=NORTHWESTSHELF_ANALYSIS_FORECAST_PHYS_004_001_b Accessed 01/03/2021.
• [8] Kokkinaki, A., Darroch, L., Buck, J., and Jirka, S. (2016). Semantically enhancing sensorml with controlled vocabularies in the marine domain. In Proceedings of GSWC 2016, Geospatial Sensor Webs Conference (Munster, Germany)
• [9] Sensor Model Language (SensorML). https://www.ogc.org/standards/sensorml Accessed 01/03/2021.
• [10] NERC Vocabulary Server. http://vocab.nerc.ac.uk/ Accessed 01/03/2021.