1 Introduction
Differential dynamic logic () is a prominent deductive method for verifying hybrid systems [Platzer18]. It extends dynamic logic with domainspecific inference rules for reasoning about the discrete control and continuous dynamics that characterise such systems. Continuous evolutions are modelled by
’s evolution commands within a hybrid program syntax. These declare a vector field and a guard, which is meant to hold along the evolution. Reasoning with evolution commands in
requires either explicit solutions to differential equations represented by the vector field, or invariant sets [Teschl12] that describe these evolutions implicitly. Verification components inspired by have already been formalised in the Isabelle proof assistant [MuniveS19]. Yet the shallow embedding used has shifted the focus from the original prooftheoretic approach to a semantic one, and ultimately to predicate transformer algebras supporting a quite different workflow.Dynamic logics and predicate transformers are powerful tools. They support reasoning about program equivalences and transformations far beyond what standard program verification requires [BackW98]. For the latter, much simpler Hoare logics generate precisely the verification conditions needed. Asking about the feasibility of a differential Hoare logic () is therefore natural and interesting. As Hoare logic is strongly related to Morgan’s refinement calculus [Morgan94], it is equally reasonable to ask whether and how a Morganstyle differential refinement calculus () might allow constructing hybrid programs from specifications.
A prima facie answer to these questions seems positive: after all, the laws of Morgan’s refinement calculus can be proved using the rules of Hoare logic, which in turn are derivable within dynamic logic. But the formalisms envisaged might not be expressive enough for hybrid program verification or less suitable than in practice. Conceptually it is also not obvious what exactly it would take to extend a standard Hoare logic or refinement calculus to hybrid programs.
Our main contribution consists in evidence that and are as feasible and applicable for verifying simple hybrid programs as , and that developing these novel methods requires simply adding a single Hoarestyle axiom and a single refinement rule for evolution commands to the standard formalisms.
This conceptual simplicity is reflected in the Isabelle verification components for and . These reuse components for (refinement) Kleene algebra with tests [Kozen97, ArmstrongGS16, afp:vericomp] ) for the propositional Hoare logic and refinement calculi—ignoring assignment and evolution commands. The axioms and laws for these two basic commands are derived in a concrete state transformer semantics for hybrid programs [afp:hybrid] over a generic hybrid store model based on lenses [FosterZW16], reusing other Isabelle components [afp:hybrid, Foster18cOptics, Foster19aIsabelleUTP]
. Datalevel verification conditions are discharged using Isabelle’s impressive components for ordinary differential equations
[ImmlerH12a].This simple modular development evidences the benefits of algebraic reasoning and shallow embeddings with proof assistants. Our verification components merely require formalising a state transformer semantics for and along the lines of [MuniveS19] and concrete store semantics for hybrid programs. Lenses [FosterZW16] give us the flexibility to switch seamlessly between stores based on real vector spaces or executable Euclidean spaces. Beyond that it suffices to derive a few algebraic laws for invariants and the Hoareaxioms and refinement laws for evolution commands in the concrete semantics. Program verification is then performed at the concrete level, but this remains hidden, as tactics generate datalevel verification conditions automatically and we have programmed boilerplate syntax for programs and correctness specifications.
Our Isabelle components support the workflows of in and . We may reason explicitly with solutions to differential equations and implicitly with invariant sets. We have formalised a third method in which solutions, that is flows, are declared ab initio in correctness specifications and need not be certified.
Our program construction and verification components have so far been evaluated on a small set of simple examples. We present some of them to explain the work flows supported by and . With Isabelle tactics for automated verification condition generation in place, we notice little difference relative to our predicate transformer components [MuniveS19]. The entire Isabelle formalisation is available online^{1}^{1}1https://github.com/yonoteam/HybridKATpaper; our repository contains instructions for using it and a postscript proof document for reading the Isabelle code without installing the tool.
2 Kleene Algebra with Tests
A Kleene algebra with tests [Kozen97] () is a structure where is a boolean algebra with join , meet , complementation , least element and greatest element , , and is a Kleene algebra—a semiring with idempotent addition equipped with a star operation that satisfies the axioms and , as well as their opposities, with multiplication swapped. The ordering on is defined by , as idempotent semirings are semilattices. We often write instead of , and use for elements of .
Elements of represent programs; those of tests, assertions or propositions. The operation models the sequential composition of programs, their nondeterministic choice, their finite unbounded iteration. Program aborts and skips. Tests are embedded implicitly into programs. They are meant to hold in some states of a program and fail in others; () restricts the execution of program in its input (output) to those states where test holds. The ordering is the opposite of the refinement ordering on programs (see Section 7).
Binary relations of type form s [Kozen97] when is interpreted as relational composition, as relational union, as reflexivetransitive closure and the elements of as subidentities—relations below the relational unit. This grounds within standard relational imperative program semantics. However, we prefer the isomorphic representation known as state transformers of type . Composition is then interpreted as Kleisli composition
as and as . Stars are defined with respect to Kleisli composition using and . The boolean algebra of tests has carrier set , where the order on functions has been extended pointwise, and complementation is given by
We freely identify predicates, sets and state transformers below , which are isomorphic: .
Proposition 2.1.
forms a , the full state transformer over the set .
A state transformer over is any subalgebra of .
We have already formalised via type classes in Isabelle [afp:kat]. As these allow only one type parameter, we use an alternative approach that expands a Kleene algebra by an antitest function from which a test function is defined as . Then forms a boolean algebra in which acts as test complementation. It can be used in place of . The formalised state transformer model of is a contribution to this article.
3 Propositional Hoare Logic and Invariants
provides a simple algebraic semantics for while programs with
It captures validity of Hoare triples in a partial correctness semantics as
or equivalently by or . It also allows deriving the rules of propositional Hoare logic [Kozen00]—disregarding assignments—which are useful for verification condition generation:
(hskip)  
(hcons)  
(hseq)  
(hcond)  
(hwhile) 
Rules for commands with invariant assertions are derivable, too (operationally, ). An invariant for is a test satisfying . Then, with as syntactic sugar for , we obtain
(hinv)  
(hinvmult)  
(hinvplus)  
(hwhileinv)  
(hloopinv) 
We use (hinv) for invariants for continuous evolutions of hybrid systems in Section 68. The rules (hinvmult) and (hinvplus) are part of a procedure, described in Section 6. Rule (hwhileinv) is standard for invariants for while loops; (hloopinv) is specific to loops of hybrid programs (see Section 4).
The rules for propositional Hoare logic in Isabelle have been derived for in [afp:kat, afp:vericomp]. The rules for invariants have been developed specifically for this article.
4 State Transformer Semantics for Hybrid Programs
Hybrid programs of differential dynamic logic () [Platzer18] are defined by the syntax
that adds evolution commands to the language of —function embeds tests explicitly into programs. Evolution commands introduce a time independent vector field for an autonomous system of ordinary differential equations (ODEs) [Teschl12] together with a guard , a predicate modelling boundary conditions or similar restrictions on temporal evolutions.
Formally, we fix a state space of the hybrid program, for example and . We model continuous variables algebraically using lenses [FosterZW16] to support different state space models generically. A lens, , is a tuple with variable type and state space . The functions and query and update the value of in a particular state. They are linked by three intuitive algebraic laws [FosterZW16]:
where and .
Lenses and can also be checked for independence using the predicate , which we use to distinguish variables. Each program variable is a lens . State spaces of the form thus have independent lenses corresponding to projections from . Yet more general state spaces such as vector spaces or infinite Euclidean spaces can be supported as well.
Systems of equations are modelled using vector fields: functions of type on some open set . Geometrically, vector field assigns a vector to any point of the state space . A solution to the initial value problem (IVP) for the pair and initial value , where is an open interval in containing , is then a function that satisfies —an autonomous system of ODEs in vector form—and . Solution is thus a curve in through , parametrised in and tangential to at any point in ; it is called a trajectory or integral curve of at whenever it is uniquely defined [Teschl12].
For IVP with continuous vector field and initial state we define the set of solutions on as
Each solution is then continuously differentiable and thus integrable in . For and , we further define the guarded orbit of along in [MuniveS19] with the help of the state transformer as
where , and the guarded orbital of along in [MuniveS19] via the state transformer as
In applications, is usually an interval . Expanding definitions,
If denotes the predicate that holds of all states in (or the set itself), we write instead of . We define the semantics of the evolution command [MuniveS19] for any continuous and as
(stevl) 
Defining the state transformer semantics of assignments is standard [MuniveS19], though we generalise using lenses. First, we use lenses to define state updates:
for , , and . Intuitively, this updates the value of variable in the state update to have the value given by . Here, the function models an “expression” that is evaluated in state . For example, if and are variables, then the expression is modelled by . We can also update variables simultaneously:
where id is the identity function. State updates commute, when assigning to independent lenses, and cancel one another out, when made to the same lens, in a natural way. We also define a substitution operator for state updates, , that simply composes expression with . We can then define a semantic analog of the substitution operator, that satisfies the expected laws [FosterZW16]. Finally, we define a generalised assignment operator:
(stassgn) 
This applies as an assignment. With our state update function, singleton assignment is a special case: , and we can also assign several variables simultaneously. These foundations allow us to derive standard laws for assignments algebraically, as for instance in schematic [AngusK01]:
Here, means that the semantic expression does not depend in its valuation on lens [FosterZW16]. An assignment of to itself is simply . Two assignments to result in a single assignment, with a semantic substitution applied. Assignments to independent variables and commute provided that neither assigned expression depend on the corresponding variable. Assignment can be distributed through conditionals by a substitution to the condition. Such laws can be applied recursively for symbolic evaluation of deterministic programs.
Lenses support various store models, including records and functions [FosterZW16]. We provide models for vector spaces, executable and infinite Euclidean spaces:
The vector lens selects the th element of an dimension vector using vecnth and vecupd from the HOL Analysis library [HolzlIH13], which provides an indexed type for the space . The Euclidean lens uses executable Euclidean spaces [ImmlerT19] that provide a list representation of the vectors in the dimensional via an ordered basis and an inner product. The function lens selects range elements of a function associated with a domain element . It can be used in particular with infinite Euclidean spaces, . All three satisfy the lens axioms above.
The development in this section has been formalised with Isabelle [afp:hybrid, Foster18cOptics, Foster19aIsabelleUTP], both for a state transformer and a relational semantics. An instance of the latter for particular vector fields with unique solutions forms the standard semantics of . By the direct connection to orbits or orbitals, the state transformer semantics is arguably conceptually simpler and more elegant.
5 Differential Hoare Logic for Flows
In the standard semantics of Hoare triples, the Kleisli composition in the left hand side of ensures that holds before executing . The left hand side guarantees that holds after its execution. With evolution commands, and consistently with , the holds at every point in the orbit of a solution for .
The assignment axiom of Hoare logic needs no explanation. Our concrete semantics allows us to derive it:
(hassgn) 
Hence, all we need to add to Hoare logic is a rule for evolution commands. We restrict our attention to Lipschitzcontinuous vector fields for which unique solutions to IVPs are guaranteed by PicardLindelöf’s theorem [Teschl12]. These are (local) flows and is the trajectory at . Guarded orbitals then specialise to guarded orbits
where is a time domain of interest, typically an interval for some [MuniveS19]. Accordingly, (stevl) becomes
(stevlflow) 
The following Hoarestyle rule for evolution commands is then derivable.
Lemma 5.1.
Let be a Lipschitz continuous vector field on and its local flow with . Then, for and ,
(hevl) 
This finishes the derivation of rules for a Hoare logic for hybrid programs—to our knowledge, the first Hoare logic of this kind. As usual, there is one rule per programming construct, so that their recursive application generates proof obligations that are entirely about datalevel relationships—the discrete and continuous evolution of hybrid program stores.
The rule (hevl) supports the following procedure for reasoning with an evolution command and set in :

Check that satisfies the conditions for PicardLindelöf’s theorem ( is Lipschitz continuous and is open).

Supply a (local) flow for with open interval of existence around .

Check that solves the IVP for each ; (, , and ).

If successful, apply rule (hevl).
Example 5.1 (Thermostat verification via solutions).
A thermostat regulates the temperature of a room between bounds . Variable stores an initial temperature; indicates whether the heater is switched on or off. Within time intervals of at most minutes, the thermostat resets time to , measures the temperature, and turns the heater on or off dependent on the value obtained. With , , , we define , for , as
abbreviation f a c T s a T c s 0 s 0 t s 1 Working alternatively with or , we write instead of for sequential composition and use a guard to restrict evolutions between and by setting
where if , and if . The hybrid program below models the behaviour of the thermostat. To simplify notation, we separate into a loop invariant (), discrete control (), and continuous dynamics ().
abbreviation I U T T 0 1abbreviation ctrl t 0 T IF 0 1 THEN 1 ELSE IF 1 1 THEN 0 ELSE skipabbreviation dyn a IF 0 THEN x f a 0 G a 0 on 0 UNIV 0 ELSE x f a G a on 0 UNIV 0abbreviation therm a LOOP ctrl dyn a INV I
The correctness specification and verification of the thermostat with is then lemma thermostatflow assumes 0 a and 0 and 0 and shows I therm a I applyhybhoare UI t0 T0 T prefer 4 prefer 8 using localflowtherm assms apply force using assms thermdynup thermdyndown by relauto
The first line uses tactic hybhoare to blast away the structure of therm using . To apply hybhoare, the program must be an iteration of the composition of two programs—usually control and dynamics. The tactic requires lifting the store to an Isabelle/UTP expression [FosterZW16], which is denoted by the U operator. Lemma localflowtherm, whose proof captures the procedure described above, supplies the flow for : , for all . The remaining proof obligations are inequalities of transcendental functions. They are discharged automatically using auxiliary lemmas. ∎
6 Differential Hoare Logic for Invariants
Alternatively, supports reasoning with invariants for evolution commands instead of supplying flows to (hevl). The approach has been developed in [MuniveS19]. Our invariants generalise the differential invariants of [Platzer18] and the invariant sets of dynamical systems and (semi)group theory [Teschl12] .
A predicate is an invariant of the continuous vector field and guard along if
The operation is the Kleisli extension in the powerset monad. Hence we could simply write . The definition of invariance unfolds to
For we call an invariant of along . Intuitively, invariants can be seen as sets of orbits. They are coherent with the invariants from Section 3.
Proposition 6.1.
Let be continuous, and . Then is an invariant for and along if and only if .
Hence we can use a variant of (hinv) for verification condition generation:
(hinvg) 
It remains to check invariance in the antecedent of this rule. The following lemma leads to a procedure.
Lemma 6.1 ([MuniveS19]).
Let be a continuous vector field, differentiable and .

If for all , then ,

if when , and when , for all , then

if and only if or ,

if and only if .
Condition follows from the well known fact that two continuously differentiable functions are equal if they intersect at some point and their derivatives are equal. Rules (hinvg), (hinvmult), (hinvplus), Proposition 6.1 and Lemma 6.1 yield the following procedure for verifying :

Check whether a candidate predicate is an invariant for along :

transform into negation normal form;

reduce complex (with (hinvmult), (hinvplus) and Lemma 6.1 (3,4);

if is atomic, apply Lemma 6.1 (1) and (2);
(if successful, holds by Proposition 6.1),


if successful, prove and to apply rule (hinvg).
Example 6.1 (Water tank verification via invariants).
A controller turns a water pump on and off to keep the water level in a tank within safe bounds . Variable stores an initial water level; indicates whether the pump is on or off. The rate of change of the waterlevel is linear with slope (assuming ). The vector field f for this behaviour and its invariant dI are abbreviation f k s 0 h s k s 0 t s 1abbreviation dI k Uh k t 0 t 0 1 This vector field differs from that of the thermostat (Example 5.1). A hybrid program for the controller is given once again by guard with that restricts evolutions beyond , loop invariant , control and dynamic part before the program itself: abbreviation G hx k Ut hx kabbreviation I U h h 0 1abbreviation ctrl t 0 h IF 0 1 THEN 1 ELSE IF 1 1 THEN 0 ELSE skipabbreviation dyn ci co IF 0 THEN x f cico G cico on 0 UNIV 0 DINV dI cico ELSE x f co G co on 0 UNIV 0 DINV dI coabbreviation tankdinv ci co LOOP ctrl dyn ci co INV I
The correctness specification and verification of the water tank with is then
lemma tankdiffinv 0 diffinvariant dI k f k 0 UNIV 0 Guard lemma tankinv assumes 0 and 0 co and co ci shows I tankdinv ci co I applyhybhoare UI t 0 h0 h prefer 4 prefer 7 using tankdiffinv assms apply force using assms tankinvarith1 tankinvarith2 by relauto
As in Example 5.1, tactic hybhoare blasts away the control structure of this program. The second proof line uses Lemma tankdiffinv to check that dI is an invariant, using the procedure outlined (see our repository for technical details). Auxiliary lemmas then discharge the remaining arithmetic proof obligations. ∎
7 Differential Refinement Calculi
A refinement Kleene algebra with tests () [ArmstrongGS16] is a expanded by an operation that satisfies, for all and ,
The element of corresponds to Morgan’s specification statement [Morgan94]. It satisfies and , which makes the greatest element of that satisfies the Hoare triple with precondition and postcondition . Indeed, in and for , .
Variants of Morgan’s laws [Morgan94] of a propositional refinement calculus—once more ignoring assignments—are then derivable in [ArmstrongGS16].
(rskip)  
(rcons)  
(rseq)  
(rcond)  
(rwhile) 
We have also derived and , but do not use them in proofs.
For invariants and loops, we obtain the additional refinement laws
(rinv)  
(rloop) 
In , moreover, the following assignments laws are derivable [ArmstrongGS16].
(rassgn)  
(rassgnl)  
(rassgnf) 
The second and third law are known as leading and following law. They introduce an assignment before and after a block of code.
Finally, we obtain the following refinement laws for evolution commands.
Lemma 7.1.
Let be a Lipschitz continuous vector field on and its local flow with . Then, for and ,
(revl)  
(revll)  
(revlr) 
The laws in this section form the differential refinement calculus . They suffice for constructing hybrid programs from initial specification statements by stepwise refinement incrementally and compositionally. To our knowledge, is the first refinement calculus for hybrid programs of this kind. A more powerful variant based on predicate transformers à la Back and von Wright [BackW98] has been developed in [MuniveS19], but applications remain to be explored. A previous approach to refinement for hybrid programs in [LoosP16] is quite different to the two standard calculi mentioned and much more intricate than the approach presented.
Example 7.1 (Thermostat refinement via solutions).
We now construct program therm from Example 5.1 by stepwise refinement using the rules of .
lemma Rthermdown assumes a 0 and 0 and 0 Tl and Th Tu shows 0 I Tl Th t 0 T0 T I Tl Th x f a 0 G Tl Th a 0 on 0 UNIV 0 applyrule localflowRgodeivlOF localflowtherm using thermdyndownOF assms13 of Th assms by relautolemma Rthermup assumes a 0 and 0 and 0 Tl and Th Tu shows 0 I Tl Th t 0 T0 T I Tl Th x f a Tu G Tl Th a Tu on 0 UNIV 0 applyrule localflowRgodeivlOF localflowtherm using thermdynupOF assms1 assms4 of Tl assms by relautolemma Rthermtime I Tl Th I Tl Th t 0 t 0 by rule Rassignlaw predsimplemma Rthermtemp I Tl Th t 0 I Tl Th t 0 T0 T T0 T by rule Rassignlaw predsimplemma Rthermostatflow assumes a 0 and 0 and 0 Tl and Th Tu shows I Tl Th I Tl Th therm Tl Th a Tu by refinementrule Rthermtimerule Rthermtemprule Rassignlaw rule RthermupOF assms rule RthermdownOF assms relauto The refinement tactic pushes the refinement specification through the program structure until the only remaining proof obligations are atomic refinements. We only refine the atomic programs needed to complete proofs automatically; those for the first two assignment and the evolution commands. ∎
Example 7.2 (Water tank refinement via invariants).
Alternatively we may use differential invariants with to refine tankdinv from Example 6.1. This time we supply a single structured proof to show another style of refinement. We abbreviate long expressions with schematic variables.
lemma Rtankinv assumes 0 and 0 co and co ci shows I hl hh I hl hh tankdinv ci co hl hh proof have I hl hh I hl hh LOOP t 0I hl hh t 0 I hl hh INV I hl hh is R by refinement relauto moreover have R LOOP t 0h0 hI hl hh t 0 h0 h I hl hh INV I hl hh is R by refinement relauto moreover have R LOOP ctrl hl hhI hl hh t 0 h0 h I hl hh INV I hl hh is R by simp only multassoc refinement force rule Rassignlaw relauto moreover have R LOOP ctrl hl hh dyn ci co hl hh INV I hl hh applysimp only multassoc refinement simp prefer 4 using tankdiffinv assms apply force using tankinvarith1 tankinvarith2 assms by relauto ultimately show I hl hh I hl hh tankdinv ci co hl hh by autoqed
The proof incrementally refines the specification of tankdinv using the laws of . As in Example 7.1, after refining the first two assignments, tactic refinement completes the construction of ctrl. Then, the invariant is supplied via lemma tankdiffinv from Example 6.1 to construct dyn. The final program is then obtained by transitivity of . A more detailed derivation is also possible. ∎
8 Evolution Commands for Flows
Finally, we present variants of and that start directly from flows instead of vector fields. This avoids checking the conditions of the PicardLindelöf theorem and simplifies verification proofs considerably. Instead of , we now use the command in hybrid programs and define
with respect to the guarded orbit of along in . It then remains to derive a Hoarestyle axiom and a refinement law for such evolution commands.
Lemma 8.1.
Let , where is a set and a preorder. Then, for ,
(hevlfl)  
(revlf)  
(revlfl)  
(revlfr) 
Example 8.1 (Bouncing ball via Hoare logic and refinement).
A ball of mass falls down from height , with denoting its position, its velocity and its acceleration. Its kinematics is modelled by the flow abbreviation g x g 22 v x v g v
The ball bounces back elastically from the ground. This is modelled by a discrete control that checks for and then flips the velocity. Guard excludes any motion below the ground. This is modelled by the hybrid program [Platzer18] abbreviation bbevol g h T LOOP EVOL g x 0 T IF v 0 THEN v v ELSE skip INV 0 x 2 g x 2 g h v v Its loop invariant conjoins the guard with a variant of energy conservation. The correctness specification and proof with and are then straightforward. lemma bouncingballdyn assumes g 0 and h 0 shows x h v 0 bbevol g h T 0 x x h applyhybhoare U0 x 2 g x 2 g h v v using assms by relauto simp bbrealarithlemma Rbouncingballdyn assumes g 0 and h 0 shows x h v 0 0 x x h bbevol g h T applyrefinement rule RbbassignOF assms using assms by relauto simp bbrealarith In the refinement proof, the tactic leaves only the refinement for the assignment v v. This is supplied via lemma Rbbassign and the remaining obligations are discharged with the same arithmetical facts. ∎
9 Conclusion
We have contributed new methods and Isabelle components to an open modular semantic framework for verifying hybrid systems that so far focussed on predicate transformer semantics [MuniveS19]; more specifically the first standalone Hoare logic for hybrid programs, the first Morganstyle refinement calculus for such programs, more generic state spaces modelled by lenses, improved Isabelle syntax for correctness specifications and hybrid programs, and increased proof automation via tactics. These components support three workflows based on certifying solutions to Lipschitzcontinuous vector fields, reasoning with invariant sets for continuous vector fields, and working directly with flows without certification.
Compared to the standard toolchain, and are simple. They emphasise the natural mathematical style of reasoning about dynamical systems, with minimal conceptual overhead relative to standard Hoare logics and refinement calculi. , in particular, remains invisible and is only used for automated verification condition generation. The modular approach with algebras and a shallow embedding has simplified the construction of these verification components and made it incremental relative to extant ones. Our framework is not only open to use any proof method and mathematical approach supported by Isabelle, it should also allow adding new methods, for instance based on discrete dynamical systems, hybrid automata or duration calculi [LiuLQZZZZ10], or integrate CAS’s for finding solutions. It should be equally straightforward to formalise and based on other Hoare logics in Isabelle with our hybrid store models.
The relevance of and to hybrid systems verification is further evidenced by the fact that such approaches are not new: A hybrid Hoare logic has been proposed by Liu et al. [LiuLQZZZZ10] for a duration calculus based on hybrid CSP and been widely used since. It is conceptually very different from and . A differential refinement logic based on has been developed as part of Loos’ PhD work [LoosP16]. It uses a proof system with inference rules for reasoning about inequalities between expressions, which are interpreted in a rather nonstandard way as refinements between hybrid programs. It differs substantially from the calculi developed by Back and von Wright [BackW98], Morgan [Morgan94] and others, and thus from the predicate transformer algebras in [MuniveS19] and from . The relative merits of these approaches remain to be explored.
The expressivity and complexity gap between Hoare logic and predicate transformer semantics is particularly apparent within algebra. The weakest liberal precondition operator cannot be expressed in [Struth18]. The equational theory of , which captures propositional Hoare logic, is PSPACE complete [KozenCS96], that of modal Kleene algebra, which yields predicate transformers, is in EXPTIME [MollerS06].
Finally, while and are convenient starting points for building program construction and verification components for hybrid programs, the simple and more general setting of Hoare semigroups [Struth18] would support developing hybrid Hoare logics for total program correctness—where balls may bounce forever—or even for multirelational semantics [FurusawaS16, FurusawaS15] as needed for differential game logic [Platzer18]. This, however, is left for future work.
Acknowledgements.
Second author is sponsored by CONACYT’s scholarship no. 440404.
Comments
There are no comments yet.