## I Introduction

Engineering controllers for autonomous vehicles requires a range of models, e.g. of the dynamics and of the control algorithms, for validating and verifying their key properties [Luckcuck2018, Gleirscher2018-NewOpportunitiesIntegrated]. NC (NC, e.g. with MATLAB) is a widely used simulation technique for model validation (i.e. closing the reality gap) and controller testing. However, simulation is, like testing, mostly limited to the demonstration of defects, since it can only consider a small fraction of the input space. For correctness, particularly to assess safety, full coverage of this space is desirable or mandatory. For hybrid systems, full coverage can be achieved only using symbolic reasoning techniques, such as deductive verification [Platzer2008], due to the uncountable state space. We therefore need the translation of a validated model into a form amenable to verification in a proof environment such as Isabelle/HOL [Isabelle].

In this work, we investigate this translation for the case of a hybrid
model of an AMV and the formal verification of its safety properties.
We describe the dynamics of the vehicle’s motion, and controllers for
waypoint approach and obstacle avoidance. We model the controller
using hybrid state charts,
including the mode switching for
mitigating accidents between the operator and the safety
controller. We simulate our model in the NC tool GNU/Octave,^{1}^{1}1GNU/Octave. http://octave.sourceforge.io/ for the purpose of
validation against real-world trials, and translate this into an
implementation of differential Dynamic Logic [Platzer2008, Foster2020-dL] () in Isabelle/HOL for
deductive verification. To support this, we extend it to support matrices, discrete state, and a form of modular verification.

Our preliminary work serves as a template for how a translation from an NC tool to Isabelle can be achieved, and provides additional evidence that Isabelle provides a credible and flexible solution for hybrid systems verification. Our work is inspired by Mitsch et al. [Mitsch2017Obstacle] who provide a generic verified model for collision avoidance in KeYmaera X [KeYmaeraX]. We advance their work through provision of explicit support for transcendental functions in the system dynamics, a higher-level notation in our tool that bridges the semantic gap with control engineers, and access to Isabelle’s automated proof facilities.

After an overview of the technologies we use in Section II, we present our approach to validation-based formal verification in Section III and close with a discussion in Section IV.

## Ii Background

Isabelle/HOL [Isabelle] is a proof assistant for Higher Order Logic (HOL). It includes a functional specification language and an array of proof facilities, including sledgehammer [Blanchette2011]

, which integrates automated provers, such as Z3. Isabelle is highly extensible, and has a variety of mathematical libraries, notably for Multivariate Analysis

[Harrison2005-Euclidean]and Ordinary Differential Equations

[Immler2012, Immler2014] (ODEs), which provide the foundations for verification of hybrid systems.Isabelle/UTP [Foster2020-IsabelleUTP] is a semantic framework based on Hoare and He’s Unifying Theories of Programming (UTP) [Hoare&98], built on Isabelle/HOL. It supports diverse semantic models in a variety of paradigms, such as reactive, concurrent, and hybrid systems, and their application to verification. For example, it contains a tactic, hoare-auto, that automates verification of sequential programs using Hoare logic that by utilising sledgehammer to discharge verification conditions.

is a logic for deductive verification of hybrid systems, which is supported by the KeYmaera X tool [KeYmaeraX]. includes a hybrid program modelling language, and a verification calculus based on dynamic logic. It can be used to prove invariants both of control algorithms and continuous dynamics, which makes it ideal for verifying hybrid systems. It avoids the need for explicit solutions to differential equations, by using a technique called *differential induction*. Recently, differential induction has been embedded into Isabelle [Munive2018-DDL] and Isabelle/UTP [Foster2020-dL] to create differential Hoare logic (), which also supports verification of hybrid programs, but in a more general setting. In this paper, we integrate into Isabelle/UTP, and extend it.

## Iii Approach

Our case study, the C-Worker 5^{2}^{2}2C-Worker
5. https://www.asvglobal.com/product/c-worker-5/ (Figure (a)a)
is an AMV designed to support hydrographic survey work. It
operates in the open sea and so must avoid collisions with both static
and dynamic obstacles, such as rocky outcrops and other vessels.
We consider a safety controller that (1)
avoids collisions with obstacles where possible by taking evasive
maneuvers; and (2) mitigates the effects where
avoidance is impossible. Our industrial partner, D-RisQ^{3}^{3}3D-RisQ Software Systems. http://www.drisq.com/, is developing a safety controller called the LRE [Foster2020AUV] implementing the above
functionality when the boat is operating autonomously.
For verification, we focus on avoidance of static obstacles.

### Iii-a Modelling the Dynamics and the Controller

#### Modelling the AMV Dynamics

The dynamical model should be close enough to reality to do NC and abstract enough to reduce the complexity of formal verification to a level appropriate for a credible assurance case [Gleirscher2019-SEFM].

Indicated in Figure (b)b, at time , we consider the velocity and position of the AMV, the position of a next waypoint to be approached, and a set of obstacles, each described by its velocity and position . and

are vectors in planar coordinates

over . These parameters form a state space with tuplesBelow, we abbreviate by where . We also consider parameters calculated from , such as the distance to the next waypoint or the angle between the AMV velocity vector and the distance vector .

For sake of simplicity, we consider the AMV as a particle with mass and formulate its dynamics as the following system of ordinary differential equations

(1) |

where implements Newton’s second law of the kinetics of particle masses relating a force applied to the vehicle and this vehicle’s acceleration at time . To remain in scope of our investigation, we further simplify the AMV dynamics, omitting disturbances (e.g. crosswind) and perturbations (e.g. flow resistance), and restricting our analysis to static obstacles.

#### Modelling the AMV Controller

Figure 2 shows the structure of the plant consisting of the dynamical model of the AMV and its environment (as explained before) and a two-layered controller comprising the AP and the LRE.

The *discrete low-level control* of the vehicle is facilitated by
the AP through generating the propulsive force of the
AMV as an input to the AMV dynamics. Within the frame of
reference of the trajectory of the AMV, we model the AMV’s
single thruster by calculating two components of , the
longitudinal (or tangential) acceleration force collinear
with the AMV’s velocity and the radial acceleration
force perpendicular to , such that

The *discrete high-level control* of the AMV is partially
facilitated by the LRE through switching between several
operating modes: an OCM, a MOM, a HCM, and a CAM. When in OCM, the operator has responsibility for the AMV. When in MOM, the AMV navigates towards the next waypoint at maximum speed. If it gets close to, but not on collision course with, an obstacle then it switches to HCM. If a potential future collision is detected, it transitions to CAM to make evasive maneuvers.
Each of these modes provides the AP with a particular
setpoint (i.e. target
speed and location of next waypoint) for the calculation of
by the AP as described by the hybrid automaton in
Figure 3

(2) | ||||

(3) |

In this example, we use a simple proportional controller for
with directional proportionality factors as shown in
Equations 2 and 2.
For obstacle avoidance manoeuvres, we calculate the *safe braking
distance* by

(4) |

with a safety margin to capture modelling uncertainty and define
the *nO* and *oCC* hazards as the predicates

(5) |

In MOM, we add a *hysteresis* to
in order to delay manoeuvre cancellation.
Figure 3 describes the overall behaviour of how the
LRE switches between the four modes to provide to the
AP. From the components LRE and AP shown in
Figure 2 and from the modes shown in
Figure 3, one can then derive the interfaces for the
detailed software design of the AMV control system.

#### Note on Abstraction

The transition from the discrete LRE and AP to the continuous AMV physics is accomplished by a conversion of (D)iscretely timed inputs in form of (C)ontinuous, piece-wise constant signals, processed by actuators. Vice versa, the digital controller (particularly, the Aggregator in Figure 2) samples the environment through sensors at a certain rate. Figure 2 indicates this abstraction by D/C and C/D converters. Although we chose to apply this abstraction to the generation of , in practice, this will happen inside the thrusters where, e.g. digital signals control a servo motor of a combustion engine and a rudder to generate .

#### Simulating the Model

We implemented the AMV model in a simple integrator-based simulator in plain GNU/Octave. For that, we derived parameters, such as weight, maximum speed and propulsive force, from the C-Worker 5 specification. Additionally, we identified controller constants, such as , during simulation. Figure 4 shows a trajectory of the AMV (green dot) turning around to make its way to the next waypoint (blue dot) while circumventing a floating obstacle (pink dot). The initial state is set to

and the simulation run for the constants , , and the time interval sec. Note, the 2D trajectory from the AMV exhibits a deviation from its course where turned true. The lower middle graph shows this as the event of where the magenta curve touches the red curve at , simultaneous to the reduction of after the switch to (cf. top right graph).

#### Beyond Simulation

Our quest for covering the input space (Section I) requires us to ask how we can know that from wherever in we start, wherever an obstacle is, in whatever interval we evaluate a trajectory, will the AMV always steer away from an obstacle in CAM, will it always reduce speed in HCM, will it reach the next waypoint within a given time in MOM? Such questions require a more fundamental investigation of the model discussed in the next section.

### Iii-B Verification

In order to support deductive verification of AMV, we apply Isabelle/UTP to prove properties of the controller and system dynamics. For this, we utilise Isabelle/ which integrates [Munive2018-DDL, Foster2020-dL] into Isabelle/UTP. We extend it with matrices, discrete variables, and modular reasoning. Along with standard Hoare logic laws, Isabelle/ includes the key rules from , including differential induction and cut, which are at the core of our verification approach. We prove these laws as theorems of Hoare logic in Isabelle/UTP^{4}^{4}4We omit the proofs for reasons of space. They can be found in our repository (https://github.com/isabelle-utp/utp-main) and accompanying links..

Here, is a system of ODEs with an evolution domain . The dynamical system is permitted to evolve provided that the ODEs in , and predicate , are satisfied for all points on the solution trajectory. (6) states that if is everywhere differentiable, and its differentiated form follows from , then is an invariant. (7) shows that if we can prove that is invariant, then we can use it as an axiom of the dynamics to prove that is also an invariant [Platzer2008].

We extend [Foster2020-dL] with support for automation of Lie derivatives [Ghorbal2014-AlgInv] evaluation. The ODEs are encoded as a vector field . denotes the Lie derivative of the predicate along . is restricted to the form , for , over differentiable expressions , and their conjunctions and disjunctions, such as . We exemplify below.

(8) | ||||

(9) | ||||

(10) | ||||

(11) | ||||

(12) |

These are largely standard, such as the product rule (10). Of note, (12) shows the treatment of a continuous variable . We encode mutable variables using lenses [Foster07], which are pairs

for some suitable state space and variable type , that obey intuitive algebraic laws [Foster2020-IsabelleUTP]. Here, we require that every continuous variable has a bounded linear get function, which is satisfied, for example, when is a projection of a Euclidean space. The derivative of is an expression that applies the get function to the derivative of the state (). This can be seen as a semantic substitution of by its derivative [Foster2020-IsabelleUTP].

Invariants can contain transcendental functions such as and . We also support equalities between arbitrary Euclidean spaces, such as matrices. To close the gap between Octave and Isabelle, we have implemented a smart matrix parser. A matrix in Isabelle is represented by a function: , where and are finite types denoting the dimensions, and is the element type, usually . Thus, the Isabelle type system can be used to ensure that matrix expressions are well-formed. We use the syntax

to represent a by matrix in Isabelle, which is a list of lists. Our parser can infer the dimensions of a well-formed matrix, and produce suitable dimension types, which aids proof. Moreover, we have proved theorems that allow symbolic evaluation of certain vector operations, for example:

We also define the matrix lens

which accesses an element. With it, we can model both variables that refer to an entire matrix and also its elements.

We have developed a tactic in Isabelle/ called dInduct, which automates the application of Theorem III.1 by determining whether is indeed differentiable everywhere, and if so applying differentiation and substitution. The resulting predicate can be discharged, or refuted, using Isabelle’s tactics.

Hybrid systems in Isabelle/ follow the pattern of , where the controller and dynamics iteratively take turns in updating the variables [Mitsch2017Obstacle]. Proving a safety property of entails finding an invariant both of and , such that . Isabelle/ splits the state space of a hybrid system into its continuous and discrete variables. Continuous variables change during evolution, but discrete variables are constant and updated only by assignments.

The continuous state space () must form a Euclidean space, and so is typically composed of reals, vectors, and matrices. There are no restrictions on the discrete state space, and it may use any Isabelle data type.

#### Case Study

We describe each of the continuous variables using lenses, e.g. ^{5}^{5}5We omit the subscripts for brevity.. In addition to those mentioned in §III-A, we also include for the acceleration, and , for the linear speed. Technically, can be derived as , but its inclusion makes proving invariants easier. Most are monitored variables of the environment, except , which is updated by the AP. The discrete variables include
waypoint location ();
obstacle set ();
linear speed and heading set points ();
force vector (); and mode ().
Next, we describe the dynamics.

Dynamics is a system of six ODEs. For the linear speed derivative, we consider the special case when , where the speed derivative is derived from , and the rotational speed is 0. We also axiomatise some properties of the dynamics in : (1) the linear speed must be in ; (2) must be the same as multiplied by the orientation unit vector; (3) time must not advance beyond , which puts an upper bound on the time between control decisions.

Next, we model the LRE, which is encoded as a set of guarded commands derived from Figure 3. In each iteration, the LRE updates state variables and can transition to a different state. Whilst in MOM, the speed set point is the maximum speed (S), and the LRE invokes the command steerToWP that updates the heading towards the current way point.

If oCC is detected the LRE transitions to CAM. If nO holds but not oCC, then the LRE switches to HCM. From HCM, the speed set point is decreased to . Once the AMV is no longer close to an obstacle, the LRE may return to MOM. OCM exhibits no behaviour since the operator provides the control inputs. Finally, CAM is where collision avoidance procedures are executed. Its behaviour is left unspecified for now. The final component we model is the AP.

The AP takes and as inputs, computes , and calculates . The constants and limit the controller activity when the speed is close to the set point. Its representation in Isabelle/UTP is shown in Figure 5. Continuous variables are distinguished using the namespace , e.g. . Scalar multiplication and division are distinguished operators, and . Finally, we describe the overall AMV behaviour.

###### Definition III.5.

The LRE executes first to determine the new speed set points. Following this, the autopilot calculates the new acceleration vector. Finally, the dynamical system evolves the continuous variables for up to seconds, and then the cycle begins again. We will now proceed to verify some properties of the system using Isabelle/. We begin with some structural properties.

means that does not modify the variables in . It enables modular verification using the following theorem:

If is not modified by , then any predicate in is invariant. We can verify that the LRE does not modify any of the continuous variables, as it only updates the (discrete) set points. The AP modifies only the continuous variable . We can prove that is an invariant of both and , and therefore of the entire system. The dynamics can potentially change any of the continuous variables, but does not change any of the discrete variables. These structural properties are automatically proved, and are useful to ensure structural well-formedness of a controller under development.

We next prove some invariants of the system using .

###### Proof.

We first prove that and are both invariants by theorem III.1. We can then show these are equivalent with . ∎

Collinearity means that and have the same direction and the AMV is travelling straight. A corollary is below.

This states that if the AMV is travelling in a straight line, then its position can be obtained through integration of . By Theorem III.6, collinearity is also trivially an invariant of the , since it does not modify any continuous variables.

We show proof of a further corollary in Figure 6 in Isabelle/UTP: if the AMV is moving straight, then the
heading is constant. We introduce a ghost variable for the current heading . The proof proceeds by performing a differential cut (dCut_split’), which allows us to assume collinearity in the dynamical system. Theorem III.7 corresponds to the fact collinear_vector_accel in Isabelle. Then, we use differential induction via the dInduct_auto tactic, which also applies algebraic simplification laws. Finally, we call *sledgehammer* which provides SMT proofs to discharge the remaining proof obligation, which is essentially
. This technique allows us to harness all the mathematical results proved in HOL and HOL-Analysis in our proofs [Harrison2005-Euclidean, Immler2012].

Collinearity is established by when the heading set point is the same as the actual heading:

###### Proof.

Hoare logic reasoning and vector arithmetic. A crucial fact is that . ∎

The theorem shows that if the linear speed is between 0 and , and are sufficiently close, and can be derived from the linear speed and heading, then afterwards and are again collinear. Now, by the sequential composition law, we can compose this with III.7 to obtain the same Hoare triple for . Finally, we show a property of the LRE.

This shows that if the LRE is in MOM, and the heading is currently towards the waypoint, but an obstacle is close, then it will transition to HCM, drop the set point speed to and the requested heading remains close to the actual heading.

## Iv Discussion and Conclusion

In this paper, we have made preliminary steps to integrating NC with theorem proving in Isabelle. Octave and Isabelle’s approaches to mathematics are, in many ways, quite different. Octave is focused on efficient NC, whereas Isabelle is based on foundational mathematics and proof. Nevertheless, our investigation indicates that they can effectively be used together.

Most of the required Octave functions, such as, , , and the vector operations are present in Isabelle, and are accompanied by a large body of theorems [Harrison2005-Euclidean, Immler2012, Immler2014]. The Archive of Formal Proofs^{6}^{6}6Archive of Formal Proofs. https://www.isa-afp.org/. (AFP) has several useful libraries; for example, we used Manuel Eberl’s library for calculating angles [Triangle-AFP]. Combining libraries with the flexible syntax of Isabelle, the program notation of Isabelle/UTP, and our matrix syntax, we can achieve a fairly direct translation of Octave functions, as Figure 5 illustrates. Verification can be automated by the hoare-auto tactic, though this dependends on arithmetic lemma libraries, some of which we needed to prove manually for the verification. Nevertheless, in our experience, sledgehammer [Blanchette2011] performs quite well with arithmetic problems. Moreover, Isabelle has the approximation tactic, which can prove real and transcendental inequalities [Holzl2009-Approximate].

For the dynamics, it is necessary to produce an explicit system of first order ODEs, as shown in Definition III.2. Consequently, any algebraic equations must be converted. For example, we could not include the value of , but needed to give its derivative and include an axiom linking this with and . The challenge is finding invariants, and having sufficient background lemmas to prove the verification conditions.

There have been previous works on integrating NC with deductive verification. Notably, Zhan et al. [Zou2013-HHL] have used Hybrid CSP and an accompanying Hoare logic to verify Simulink block diagrams in Isabelle. Our work is more modest, in that we focus on sequential hybrid programs, but with a transparent translation and a high degree of automation. The dominant and most automated tool for hybrid systems deductive verification remains KeYmaera X [KeYmaeraX, Mitsch2017Obstacle]. Nevertheless, we believe that our preliminary results show the advantages of targeting Isabelle. Firstly, this allows integration of a variety of mathematical libraries to support reasoning. Secondly, we can combine notations with ODEs, and in the future aim to support refinement to code using libraries like Isabelle/C [Tuong2019-CIsabelle]. Thirdly, as illustrated by the obstacle register, with Isabelle/HOL we have the potential to extend with additional features like collections as used in quantified [Platzer2010-qDL].