Recent Trends in Formal Validation and Verification of Autonomous Robots Software

Abstract

The consequences of autonomous systems software failures can be potentially dramatic. There is no need to darken the picture, but still, it seems unlikely that people, insurance companies and certification agencies will let autonomous systems fly or drive around without requiring their makers and programmers to prove that the most critical parts of the software are robust and reliable. This is already the case for aeronautic, rail transportation, nuclear plants, medical devices, etc. were software must be certified, which possibly involve its formal validation and verification (V&V). Moreover, autonomous systems go further and embed onboard deliberation functions. This is what make them really autonomous, but open new challenges. We propose to consider the overall problem of V&V of autonomous systems software and examine the current situation with respect to the various type of software used. In particular, we point out that the availability of formal models is rather different depending on the type of component considered. We distinguish these different cases and stress the areas where we think we need to focus our efforts as to improve the overall robustness of autonomous systems.

Formally Modeling Autonomous Vehicles in LNT for Simulation and Testing

“…Existing work in formal models of autonomous driving (AD) systems focuses either on modelling one component in particular as in [10], or on verifying a given AD scenario as in [4], where a DSL is proposed to specify AD scenarios, which are subsequently translated into networks of stochastic hybrid automata and are verified using the UPPAAL-SMC model checker [2].…”

Software Engineering for AI-Based Systems: A Survey

“…Typically, the AI components are controlled by artificial neural networks (16 papers), in particular deep networks. Two papers [84,181] present an overview of current challenges and practices in V&V of autonomous systems, in particular those based on DL.…”

“…List of references Software Engineering Models and Methods [20,62,72,79,88,92,105,119,140,175,182] Software Requirements [80,88,92,202,224] Software Testing [29,62,81,150,172,175,182,224] Software Quality [62,79,80,88,92,113,135,172,182] Software Engineering Professional Practice [84,88,172,202] Software Construction [80,88,92,116,124,134,136,172,175,224 • Elicitation. The use of data as a source of requirements is attractive, but due to the high volume of such data, it requires tool support to detect features from massive data.…”

How do you architect your robots?

“…To design good quality robotic software in ROS, the work in [17,20] focuses on formally modeling ROS systems for real-time analysis and V&V. These do not really focus on the architecture of ROS systems, but could be used to generate or check the correctness of ROS systems. In terms of code quality, Pichler et al examine open source projects with tools such as cpplint and XML validation to analyze the quality of packages that many other ROS systems depend on [28].…”