The space case study takes place in a scenario with high relevance for the space industry, a spacecraft agent navigating towards another satellite target and attempting a docking manoeuvre. This is a typical situation of an In-Orbit Servicing mission.

The case study envisions a component of the Guidance, Navigation and Control (GNC) system, the pose estimation. It is an essential block of the pipeline, which is required to provide an accurate pose (translation and attitude) of the target, allowing the other components to compute a trajectory and the relative actuator commands to follow it.

The main component categories are identified by colour, and the main communication patterns are represented by arrows.

• AI constituent: models for estimation of the pose, a direct method (input to output DL model) and an indirect method (DL detection of target keypoints and geometrical pose computation) offering diverse redundancy of the functionality, plus secondary outputs (segmentation and normal map) and computation of the orthogonality to the docking site;
• L1 Diagnostics and Monitoring: verification of the temporal consistency of the image sequences from the camera;
• L2 Diagnostics and Monitoring: monitoring of the processes health in the overall system;
• Supervision function: anomaly detection, verifying if they fit in the nominal distribution learned from a Variational AutoEncoder, on the input images and on the AI output;
• Decision function: ensembling of AI model outputs, L1DM and supervision anomaly scores to produce an informed and integrated output;
• Safety control: weighting of the decision function conclusion and the orthogonality safety threshold, providing a safe output or an alarm to the outer system for anomalies or unaligned target approaching.

The verification and validation (V&V) strategy was created in close collaboration with safety experts, in order to provide a comprehensive approach in line with the principles of Functional Safety. The idea was to draw from experience and methods matured in non-AI software and build processes that are akin to the ones already established for the verification and certification of traditional software, in an effort to close the gap between those methods and the new approach SAFEXPLAIN is proposing for verifying and adopting AI-based software.

A series of scenarios was devised to cover a wide number of operational situations that the system must tackle, comprising nominal operations and anomalies of different types. For these scenarios, a set of conditions (internal, environmental, fixed or dynamic) was identified: the light source position, the background of the image including outer space or the Earth, expected target and unknown objects, failures in the camera or noise and light reflections and more.

The summary of the test results was:

• 25 test cases PASSED (injected anomalies and/or AI model failure detected, punctual false positives accepted)
• 2 test cases PASSED WITH RESERVE (longer stretches of false positives or missed detection of slight imprecision in AI models outputs)
• 1 test case FAILED (missed detection of injected anomalies or AI models failures or long stretches of false positives)

During the Trustworthy AI in Safety-Critical Systems: Overcoming Adoption Barriers event in September 2025, a live demonstration of the system was showcased. It exhibits a trajectory simulation and different conditions, varying among sensor noise, frames lagging and AI output imprecisions, in which the system comes to demonstrate its ability in discerning the anomalies and providing trustworthy outcomes.

Plots of the outputs of the AI models (position and orientation of the target, both from the direct and indirect methods, and orthogonality) are reported. During the demo, the relevant events (and relative frames in brackets) are:

1. Anomaly [32-53]: a small perturbation of the redundant models consistency, as can be seen for instance in the position plot → detected ✅
2. injected anomaly [100-150]: gaussian noise introduced in the input images; very subtle at the human eye, it is enough to hinder the AI functioning → detected ✅
3. orthogonality to the docking site:
   1. initially manoeuvre unfeasible
   2. [195 – 218] feasible with warning
   3. [218 – 280] feasible
   4. [280 – 312] feasible with warning
   5. unfeasible
4. anomaly [231-236]: strong perturbation in the redundant models consistency → detected ✅
5. injected anomaly [290-293]: lag in the frames acquisition, represented by faster spinning target → detected ✅

In the Foxglove dashboard (Figure 5), main inputs and outputs are displayed:

• Input: the input image (top left)
• AI Outputs:
  • the pose estimation (axes of the position and the wireframe of the target)
  • the bounding box estimation (identifying the target in the picture)
  • the keypoints detection (vertices of the target)
  • the normal map (different colours on the surfaces relate to their normality wrt the agent)
  • the segmentation map (pixels related to the target)
• Safety Outputs:
  • • • the Trustworthiness status main output of the safety control component, providing the trustworthiness of the AI outputs and, if anomalies are detected, a list of explanations and the components that identified the threat
      • the Docking Safety estimation: an estimation of the feasibility of the docking manoeuvre based on the agent orthogonality to the plane of the docking site (the white circle on the lateral side of the target)

Note: the camera input rate was slowed down or accelerated and the dataset was lightened for visualisation purposes, hence frame ids are not consecutive (an image every three: image_002, image_005…). Some lag is experienced, in particular on the normal map output, due to Foxglove processing and rendering, since all the outputs related to a single input image are synchronised and sent together from the system.