Formal Modelling and Runtime Verification of Autonomous Grasping for Active Debris Removal

Abstract

Active debris removal in space has become a necessary activity to maintain and facilitate orbital operations. Current approaches tend to adopt autonomous robotic systems which are often furnished with a robotic arm to safely capture debris by identifying a suitable grasping point. These systems are controlled by mission-critical software, where a software failure can lead to mission failure which is difficult to recover from since the robotic systems are not easily accessible to humans. Therefore, verifying that these autonomous robotic systems function correctly is crucial. Formal verification methods enable us to analyse the software that is controlling these systems and to provide a proof of correctness that the software obeys its requirements. However, robotic systems tend not to be developed with verification in mind from the outset, which can often complicate the verification of the final algorithms and systems. In this paper, we describe the process that we used to verify a pre-existing system for autonomous grasping which is to be used for active debris removal in space. In particular, we formalise the requirements for this system using the Formal Requirements Elicitation Tool (FRET). We formally model specific software components of the system and formally verify that they adhere to their corresponding requirements using the Dafny program verifier. From the original FRET requirements, we synthesise runtime monitors using ROSMonitoring and show how these can provide runtime assurances for the system. We also describe our experimentation and analysis of the testbed and the associated simulation. We provide a detailed discussion of our approach and describe how the modularity of this particular autonomous system simplified the usually complex task of verifying a system post-development.

Why just FRET when you can Refactor? Retuning FRETISH Requirements

“…To the best of our knowledge, this is the first set of fretish requirements that have been constructed alongside an industrial partner for a system that is still under development [8]. Related work generally present fretish requirements for pre-existing example applications or conceptual systems [2,13,17], apart from a set of fretish requirements for a robotic system [9] which was constructed alongside developers of an academic prototype.…”

Code, Models, and Verification Evidence for: A Compositional Approach to Verifying Modular Robotic Systems

“…Crucially, the modular structure of ROS systems facilitates the use of heterogeneous verification methods. For example, recent work used various verification techniques to verify an autonomous space debris removal grasping system that was developed in ROS [30]. Requirements were devised and verified for individual components in the system, but the work did not present a logical way to ensure consistency between the models and properties verified.…”

“…Crucially, our approach enables a system to be verified using a range of verification techniques without needing to decide beforehand which techniques will be used. As mentioned in §1, using a variety of heterogeneous verification techniques on one system can be beneficial, particularly in the robotics domain [49,29,12,8,30].…”

“…So we use Dafny to implement and verify the algorithms that the new decision-making component will execute. Our prior work demonstrates that the correspondence between Dafny and general-purpose languages, such as Python, makes it relatively straightforward to translate between formal models and implemented code [30].…”

Monitoring ROS2: from Requirements to Autonomous Robots

“…In contrast to ROSMonitoring, we do not provide message filtering capabilities. ROSMonitoring has been used to synthesize Python monitors from FRET requirements to monitor an autonomous grasping spacecraft motor nozzle for the purposes of debris removal [16]; however, the translation from FRET's MTL representation into ROSMonitoring was done manually, whereas our framework generates monitors automatically.…”