Componend-Based Deductive Verification of Cyber-Physical

Submitted by Andreas M¨uller

Submitted at Department of Cooperative Information Systems

Supervisor and First Examiner Wieland Schwinger

Second Examiner Component-based Andr´ePlatzer Co-Supervisor Deductive Veriﬁcation of Stefan Mitsch Cyber-physical Systems October 2017

Doctoral Thesis to obtain the academic degree of Doktor der technischen Wissenschaften in the Doctoral Program Technische Wissenschaften

JOHANNES KEPLER UNIVERSITY LINZ Altenbergerstraße 69 4040 Linz, Osterreich¨ www.jku.at DVR 0093696

To Katrin – that much.

Eidesstattliche Erkl¨arung

Ich erklärean Eides statt, dass ich die vorliegende Dissertation selbstständigund ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäßentnommenen Stellen als solche kenntlich gemacht habe. Die vorliegende Dissertation ist mit dem elektronisch übermittelten Textdokument identisch.

Acknowledgements

First of all and most importantly, I want to thank my beloved wife Katrin: Without you, all this would have been impossible! Thank you for your repeated encouragement and your almost endless patience, especially over the last 5 years. Furthermore, I want to thank my parents Klaus and Gertrude, my brother Daniel, my grandparents Karl and Rosi, and my parents-in-law Karl and Gundi. Thank you for your ongoing support and for always believing in me. During my time as a doctoral candidate I had the pleasure of meeting numerous further inspiring people from all over the world. I want to thank all of you, for making this time of my life so special. Many thanks to my supervisors in Linz, Wieland Schwinger and Werner Retschitzegger, for your support and the countless fruitful discussions. Special thanks, to my supervisor in Pittsburgh, Andr´ePlatzer, who made it possible for me to visit Carnegie Melon University in Pittsburgh twice. These visits along with your continuous support, allowed me to dive into the fascinating world of cyber-physical systems. Last but definitely not least, a very special thank you to my colleague, mentor and friend Stefan Mitsch. Thank you for the countless discussions— regardless if you were in the next office, or on another continent. Thank you for your answering my endless questions—no matter how stupid. Thank you for the numerous evenings we spent together—no matter if at a bar, a football match or at home.

vii

Abstract

Cyber-physical systems (CPS) are pervasively embedded into our lives and increasingly act in close proximity to as well as with direct impact on humans. Because of their safety-criticality, formal verification techniques that guarantee correctness properties for all of the infinitely many possible states of a CPSare of paramount importance. Since formal verification of CPS is known to be undecidable for realistic models, techniques to handle system complexity are needed. Verification methods based on hybrid automata focus on full automation andare therefore restricted to less expressive classes of CPS, while deductive verification methods rely on human guidance to make progress despite undecidability. To make human guidance possible, however, the inherent complexities of CPS practically mandate techniques to handle system complexity. This thesis introduces a component-based verification approach for CPS based on deductive verification. Crucially, the approach builds safety proofs about systems from smaller component proofs without analyzing the systems as a whole. As a result, the approach reduces verification complexity while simultaneously increasing proof reusability and maintainability. We develop the approach in three stages of increasing generality and suitable to various areas of application. First, we focus on modeling and verification of large traffic networks, and aim at avoiding traffic breakdowns on roads (i. e., the number of cars must not exceed the road’s capacity) as fixed safety property. Second, we generalize flow exchange between components to instantaneous, lossless information exchange being restricted to globally known regions (e. g., robot position relative to a fixed reference point) and allow arbitrary safety properties. Third, we relate component time to global system time in order to describe information exchange history in terms of the magnitude of change and rate of change (e. g., robot position relative to previous position some time ago). We show the applicability of these three approaches by modeling examples from traffic control, vehicle control and autonomous robots. The results indicate that, compared to monolithic analysis, our approaches reduce verification effort, increase proof automation, facilitate reuse of component proofs and increase the overall maintainability of a verified CPS.

Kurzfassung

Cyber-physische Systeme (CPS) sind untrennbar mit unserem täglichen Leben verbunden und arbeiten immer mehr in unserer direkten Umgebung bzw. mit direktem Einfluss auf Menschen. Weil die Sicherheit solcher Systeme dadurch besonders kritisch ist, sind formale Verifikationstechniken, die die Sicherheit aller möglichen Zuständeeines solchen CPS sicherstellen, von größterWich- tigkeit. Da formale Verifikation von realistischen cyber-physischen Modellen aber unentscheidbar ist, sind Techniken zur Komplexitätsreduktion(z.B. zer- legen eines Systems in kleinere Teilsysteme) unabdingbar. In dieser Disserta- tion präsentieren wir einen komponentenbasierten Ansatz zur Verifikation von CPS, basierend auf deduktiver Verifikation. Der Ansatz ermöglicht es, von kleineren Komponenten-Beweisen auf systemweite Sicherheitseigenschaften zu schließen, ohne das System als Ganzes analysieren zu müssen. Dadurch re- duziert sich die Verifikationskomplexität,währendgleichzeitig die Wiederver- wendbarkeit und Wartbarkeit von Beweisen erhöht wird. Wir entwickeln den Ansatz in drei Schritten, welche die Analyse von immer allgemeineren Syste- men erlauben. Zuerst fokussieren wir uns auf Modellierung und Verifikation von großen Verkehrsnetzen, mit dem festen Ziel einen Zusammenbruch des Fließverkehrs zu verhindern (d.h., es dürfensich nie mehr Fahrzeuge gleichzeitig auf einer Straße befinden, als erlaubt). Im nächsten Schritt verallge- meinern wir Kommunikation und Sicherheitseigenschaften, weg von Verkehrs- komponenten und Fließverkehr, hin zu beliebiger Informationsweitergabe und frei wählbarenSicherheitseigenschaften. Die kommunizierten Werte sind dabei durch global festgelegte Regionen beschränkt(z.B. die Position eines Roboters, relativ zu einem festgelegten Referenzpunkt). Im letzten Schritt synchronisieren wir die Zeit zwischen Komponenten und dem Gesamtsystem und ermöglichen Zugriff auf früherkommunizierte Werte, um Aussagen über die Größenordnung und die Rate der Werteänderungtreffen zu können(z.B., die Position eines Roboters, relativ zu seiner letzten Position und der Zeit die seitdem vergangen ist). Wir zeigen die Anwendbarkeit unserer Ansätzeanhand von Fallstudien aus den Bereichen Straßenverkehr, Fahrzeugsteuerung und autonome Roboter. Die Ergebnisse legen nahe, dass unsere Ansätzetatsächlich zu einer Verringerung der Beweiskomplexitätführenund gleichzeitig die Wiederverwendbarkeit und Wartbarkeit von Beweisen erhöhen.

Contents

I Fundamentals

1 Introduction...... 3 1.1 Challenges...... 4 1.2 Contribution ...... 5 1.3 Structure ...... 6 1.4 Disclaimer...... 8

2 Modeling and Verification of CPS – A Conceptual Reference Model.. 9 2.1 (Cyper-physical) Systems ...... 10 2.2 Modeling ...... 12 2.2.1 Modeling Formalism ...... 12 2.2.2 Specification Formalism ...... 14 2.3 Verification ...... 16 2.3.1 Verification Goal ...... 16 2.3.2 Verification Evidence...... 16 2.4 Tool Support ...... 17 2.4.1 Tool ...... 17 2.4.2 Artifacts...... 17 2.4.3 Verification Tools...... 19 2.5 Summary – Scope of our Approach...... 20

3 Component-based Modeling...... 21 3.1 Terminology...... 21 3.1.1 Component and Interface ...... 21 3.1.2 Composition and Compatibility...... 24 3.1.3 Contracts and Refinement...... 27 3.2 Strategy...... 30 3.3 Requirements Summary ...... 33

4 Related Work...... 35 4.1 Selection of Approaches ...... 35

xiii CONTENTS

4.2 Component-based CPS Verification...... 36 4.3 Assume-Guarantee Reasoning...... 39 4.4 Summary ...... 41

5 Motivational Examples...... 43 5.1 Flow Components ...... 43 5.1.1 Traffic Control ...... 43 5.1.2 Traffic Modeling ...... 44 5.1.3 Summary ...... 47 5.2 Vehicle Cruise Control...... 48 5.2.1 Components and Composition...... 48 5.2.2 Summary ...... 49 5.3 Tele-operated Robot...... 50 5.3.1 Components and Composition...... 50 5.3.2 Summary ...... 51 5.4 Example Summary...... 52

6 Preliminaries ...... 53 6.1 Differential Dynamic Logic ...... 53 6.1.1 Hybrid Time ...... 54 6.1.2 KeYmaera X ...... 55 6.1.3 Proof Rules ...... 56 6.2 Notation...... 57

II Domain-Specific Approach with Traffic Contracts

7 Introduction...... 61

8 Concept...... 63 8.1 Flow Interfaces...... 63 8.2 Contracts for Safe Flow Interfaces ...... 64 8.3 Safe Sequential Composition of Safe Flow Interfaces ...... 65

9 Evaluation...... 69 9.1 Verified Traffic Flow Component Library...... 69 9.1.1 Traffic Light Component...... 70 9.1.2 Traffic Flow Merge Component...... 71 9.1.3 Traffic Flow Merge with Fairness...... 73 9.1.4 Traffic Flow Split Component...... 76 9.2 Implementation–SAFE-T Modeling Tool...... 77 9.2.1 Example: Highway Exit ...... 79 9.2.2 Example: Spillback Analysis...... 79 9.3 Conclusion and Open Issues...... 82

xiv CONTENTS

III Generic Approach with Global Contracts

10 Introduction...... 87

11 Concept...... 91 11.1 Components and Contracts ...... 91 11.1.1 Components...... 91 11.1.2 Example: Components...... 92 11.1.3 Contracts ...... 93 11.1.4 Example: Contracts ...... 94 11.2 Composition and Compatibility...... 94 11.2.1 Composition...... 94 11.2.2 Example: Composition...... 98 11.2.3 Compatibility...... 99 11.2.4 Example: Compatibility...... 99 11.3 Transfering Local Component Safety to System Safety ...... 100 11.4 Plausibility and Refinement...... 101 11.4.1 Plausibility ...... 101 11.4.2 Refinement ...... 101 11.5 Proofs...... 102 11.5.1 Proof – Composition Retains Contracts ...... 102 11.5.2 Proof – Refinement Theorem ...... 113

12 Evaluation...... 115 12.1 Case Study: Vehicle Cruise Control ...... 115 12.1.1 Cruise Control with Autonomous Controller ...... 116 12.1.2 Cruise Control with Guided Controller ...... 118 12.2 Conclusion and Open Issues...... 121

IV Generic Approach with Change- and Delay Contracts

13 Introduction...... 125

14 Concept...... 129 14.1 Specification: Components and Interfaces ...... 129 14.1.1 Components...... 129 14.1.2 Example: Components...... 131 14.1.3 Interfaces ...... 132 14.1.4 Example: Interfaces ...... 134 14.1.5 Time...... 134 14.1.6 Example: Interfaces and Time ...... 135 14.2 Proof Obligations: Contract Compliance ...... 137 14.2.1 Example: Change Contract ...... 138 14.2.2 Example: Delay Contract ...... 138

xv CONTENTS

14.3 Proof Obligations: Composition...... 140 14.3.1 Parallel Composition...... 140 14.3.2 Example: Composition...... 142 14.3.3 Compatibility...... 143 14.3.4 Example: Compatibility...... 143 14.4 Transferring Local Component Safety to System Safety ...... 144 14.5 Proof – Composition Retains Contracts ...... 145 14.5.1 Lemmas...... 146 14.5.2 Proof for Two Components ...... 147 14.5.3 Proof Sketch for any number of Components...... 154

15 Evaluation...... 157 15.1 Implementation...... 157 15.1.1 Implementing the Lemmas...... 157 15.1.2 Implementing the Proof ...... 158 15.2 Case Studies ...... 159 15.2.1 Results...... 159 15.2.2 Discussion...... 160 15.3 Conclusion and Open Issues...... 161

V Final Remarks

16 Lossy Communication ...... 165 16.1 Parallel Composition with Lossy Communication ...... 165 16.2 Compatibility with Lossy Communication ...... 166 16.3 Lossy Composition Retains Contracts ...... 167 16.4 Example...... 167 16.5 Conclusion ...... 170

17 Conclusion and Future Work ...... 171 17.1 Conclusion ...... 171 17.2 Future Work ...... 173 17.2.1 Identification of Artifacts ...... 173 17.2.2 Delayed Communication...... 174 17.2.3 Multicast Ports...... 174 17.2.4 Improved Tool Support...... 175

List of Figures ...... 177

List of Algorithms ...... 178

Bibliography ...... 181

xvi Part I

Fundamentals

Chapter 1

Introduction

Early computers (around the middle of the twentieth century) were primarily used to solve equation systems [76], but soon application areas grew rapidly including the use of computers as control loops around physical systems [55]. Such systems that interface and interact directly with their real-world surroundings through sensors and exhibit physical behavior through actuators are commonly known as cyber-physical systems1 (alternative terms are hybrid systems2 or embedded systems3). Today, these cyber-physical systems (CPS) are pervasively embedded into our lives and increasingly act in close proximity to as well as with direct impact on humans. For example, cars equipped with adaptive cruise control form a typical CPS [63], which is responsible for controlling acceleration/braking on the basis of distance sensors: setting the acceleration of a car is the cyber part while the car and its motion form the physical part. Further prominent examples can be found in many safety-critical areas where lives are at stake, such as in factory automation [85], medical equipment [61], aviation [120], automotive [45], railway industries [102], robotics [71], and power plants [116]. Because of their safety-criticality, we have to ensure correctness properties, such as safety, i. e., nothing bad will ever happen [57]. However, CPS are almost impossible to get right without proper analysis of their behavior, which emerges from combined discrete dynamics (the cyber part) and the entailed continuous dynamics (the physical part) [90]. Thus, formal verification techniques that guarantee correctness properties for all of the infinitely many possible states of the cyber and physical part of a CPS in conjunction (i. e., techniques for hybrid systems [3])—not just for some, as in testing or simulation—are of paramount importance. Such formal verification techniques include reachability analysis, i. e., approximating all states reachable by a system and comparing them to a set of infinitely many desirable states,

1The term cyber-physical systems has its origin at the U.S. National Science Fund (NSF) and was coined by Helen Gill. [60] 2Hybrid systems often refer to the models of CPS, so-called hybrid system models. [60] 3Computers embedded into the environment (often invisible to the user) are called embedded systems. In that sense CPS comprise embedded systems. [68]

3 CHAPTER 1. INTRODUCTION described by a safety property, and deductive verification, i. e., transforming models using deduction rules (axioms) until the resulting model is known to be correct according to the axioms of some mathematical foundation [122] (for more details, cf. Section 2.4.3). Formal verification techniques rest on models of a CPS, which abstract from unnecessary implementation details to facilitate verification and still capture these infinitely many possible states. Since formal verification of CPS isknown to be undecidable for realistic models [49] (i. e., no automated decision procedure exists), current methods make a trade-off between full automation and modeling expressiveness: Verification methods based on model checking and reachability analysis (e. g., [39]) focus on full automation and are therefore restricted to less expressive classes of CPS (often piecewise linear approximations). In contrast, deductive verification methods (also called theorem proving methods, e. g., [92]) rely on human guidance to make progress despite undecidability so that more realistic models (e. g., including non-linear differential equations, e. g., for circular motion) can be verified and additional insight into the modeled CPS’s behavior can be provided. To make human guidance possible, however, the inherent complexities of CPS practically mandate techniques to handle system complexity. A common means of dealing with complexity is decomposing a model into smaller pieces (e. g., split an autonomous car into various subsystems like, acceleration-, braking- or steering system) using a component-based approach.

1.1 Challenges

Component-based approaches have already been successfully applied in other areas, such as engineering (e. g., electrical engineering), or in computer science disciplines, like software engineering leading to component-based software engineering (also called component-based development)[24, 110]. Although the goals of component-based software engineering are similar to the goals of component- based approaches for CPS verification (i. e., reduce complexity, increase maintainability and reusability), these purely discrete approaches do not apply to the hybrid nature of CPS. Additionally, component-based CPS verification (i. e., verification of components in isolation and transferring these verification results to composite level) is challenging because both local component behavior (e. g., decisions and motion of a robot) and inherently global phenomena (e. g., time) co-occur, because components can interact virtually (e. g., robots communicate) and physically (e. g., a robot manipulates an object), and because their interaction is subject to communication delays (e. g., transfer of signals takes time), measurement uncertainty (e. g., a position measured by a sensor might differ slightly from the actual position), and actuation disturbance (e.g., a robot chooses an acceleration, but the actual acceleration as controlled by the actuator can differ slightly). For CPS verification, component-based approaches so far have only been applied to reachability analysis. As such approaches over-approximate the possibly huge set of states reachable by a system (especially if multiple components

4 1.2. CONTRIBUTION are composed), so-called assume-guarantee approaches are intended as a way of dealing with the state explosion problem (i. e., the number of reachable states can grow exponentially). Assume-guarantee reasoning approaches allow reasoning about the guarantees that components can make if assumptions about their environment hold. However, these approaches are often limited to linear dynamics and use over-approximations (e. g., [7, 13, 16, 26, 28, 27, 40, 50]). On the other hand, with current deductive verification methods, the price for component-based development is full re-verification on every composition step [75]. In other words, deductive verification results over components do not transfer to systems composed of such verified components. This can be particularly painful, if verification of the whole system is strikingly more challenging than verification of individual components, and even more so, ifparts of the system (i. e., some of the components) have previously been verified, but must be re-verified as part of the system under consideration. For instance, a traffic network consisting of multiple intersections can become huge andhard to verify as a whole. Also, if an intersection is part of multiple models, it has to be re-verified repeatedly. Furthermore, even if only small parts of asystem evolve, repeated re-verification of the whole system model is necessary. Forin- stance, a collision avoidance system, where a robot tries to avoid colliding with an adversarial obstacle, might at first be verified using a stationary obstacle and subsequently be extended to an obstacle moving in straight lines and an obstacle moving in curves. In such a setting, even though the robot—probably representing the major part of the model—does not change, the whole system, including the robot, needs to be re-verified on every step. As hybrid system models are often developed in such an incremental fashion [73]—which entails that only small parts of a system evolve—and since deductive verification often requires human guidance, this re-verification can be very costly.

1.2 Contribution

This thesis introduces a component-based modeling and verification approach for CPS based on deductive verification that supports the transfer of verification results on component-level to the system level.

Our approach uses abstractions of component behaviors (i. e., contracts) to compose verified components and their safety proofs to a verified CPS. We build compositionality for a notion of components and interfaces: We focus on modeling a system in terms of components that each capture only a part of the system’s behavior (as opposed to a single system model) and a way to compose components by connecting their interfaces. That way, correctness of the smaller components’ functionality is first established, before the model is made more complete by composition to thus work the way towards fully verified realistic model representations of the CPS.

5 CHAPTER 1. INTRODUCTION

The overall goal is threefold: Reduce Verification Complexity: Our approach can be used to split a CPS into components, establish safety properties about these components in isolation and re-compose these components to recreate the initial system. This way, we intend to reduce the verification complexity, by verification of smaller components instead of the system as a whole. Ideally, this reduction of complexity also entails an increase of verification speed, as smaller models often require less variables and as the number of variables can be crucial because decision procedures like quantifier elimination— which we will use later on to decide upon the satisfiability of formulas—are doubly-exponential in the number of variables [20, 23, 29]. Increase Maintainability: Our approach intends to increase maintainability of hybrid system models, as the adaptation of a single part of a CPS solely requires re-verification of the component containing this part, as opposed to the re-verification of the whole system. This is especially important, as hybrid system models are often developed in an incremental fashion. [73] Increase Reusability: Since our approach supports analysis of components in isolation, we intend to allow reuse of a previously verified component when modeling CPSs, which consist of similar parts. We measure the verification complexity by the time required by the proof automation to verify the components of a system automatically, compared to the time required to verify the respective system in the same way. For models where proof automation fails, we measure the number of human guided steps required to verify the components, compared to the number of user guided steps required to verify the respective system as a whole. We measure the increase in maintainability and reusability by comparing the size of the component proofs used to verify the component models when using our approach, to the proof effort when verifying the system as a whole.

1.3 Structure

This thesis is divided into five parts: In PartI, we subsequently introduce the field of CPS modeling and verification: First, we discuss the backgrounds from the field of hybrid system verification in Chapter2 following a conceptual reference model (CRM) that allows us to span the field of CPS modeling and verification and in further consequence to distinguish our approach from other approaches. Furthermore, it helps the reader by unifying important terminology and positioning our approach in the field. In Chapter3 we discuss the terminology of component-based modeling that we employ, outline a generic strategy that can be applied to model and verify a CPS in a component-based fashion, and finally, derive a set of basic requirements for a component-based modeling and verification approach. The introduced strategy can be utilized toapply our approach, while the introduced requirements allow us to specify the class of

6 1.3. STRUCTURE systems that our approach can tackle. Following this discussion, we identify and discuss related work in Chapter4. In Chapter5, we further motivate our work with introductory examples, which emphasize the necessity and advantages of a component-based approach. Finally, in Chapter6, we introduce preliminaries used throughout the thesis. The three parts following thereafter represent the main part of this thesis. In PartII we introduce a domain-specific component-based modeling and verification approach for traffic control systems, using macroscopic traffic flow models. Traffic control acts as a first showcase for our approach, as it is virtually predes- tinated for component-based modeling because traffic networks consist of few recurring patterns, which can naturally be modeled as components. We analyze traffic models on a macroscopic scale (i. e., considering traffic flow asawhole, abstracting away from the behavior of single cars), which simplifies modeling of components (i. e., no need to model single cars), and their composition (i. e., traffic flows in parallel and travels sequentially from component to component). Consequently, we define components representing various parts of a traffic network, verify a fixed safety property for each of these components and use them to build a traffic network in a way that preserves the component safety property for the entire network. This represents the first step towards a component-based verification approach, with fixed component types (i. e., traffic patterns likein- tersections), fixed types of input and output ports (i. e., roads entering and exiting a traffic component), and fixed safety properties (i. e., traffic doesnot break down). In PartIII we generalize our component-based approach for traffic flow models to a more generic notion of components. Components can consist of a discrete control part and a continuous part, and ports and safety properties can reason about constant global properties of a system (e. g., robot position relative to a fixed reference point, i. e., global contracts). Again we introduce a composition operation that transfers the safety properties of single components to composed systems. The contracts in this part are far more flexible then in the previous part, as they are no longer fixed to “traffic does not break down”, butcanbe chosen freely. However, due to the fact that the contracts are restricted to properties about global constants, they still only represent an intermediate step towards the definition of a more comprehensive component-based verification approach. Finally, in PartIV we extend our approach to contracts that allow reasoning about both constant global properties and the change of values (e. g., robot position relative to the last measurement). Furthermore, we synchronize time for single components (i. e., in contrast to global contracts, they enforce realistic equal duration of continuous evolution across components, which happens automatically for a single system model, but needs to be enforced in component- based approaches). This final approach comprises all previous approaches, but is not as domain-oriented as the approach presented in PartII and entails a more complex contract definition than in PartIII to ensure synchronized component operation and storage of changed values. Each of these three parts starts with a short introduction, before we in-

7 CHAPTER 1. INTRODUCTION troduce the theoretical concept of the approach. We end each part with an evaluation of the presented approach and discuss open issues. Additionally, PartII and PartIV include prototypical implementations that allow creation of verified traffic networks, respectively verified generic components. Finally, we present some final remarks in PartV, starting by demonstrating how to extend our approach with additional communication options, in Chap- ter 16. Chapter 17 concludes our work, discusses open issues and points towards future research directions.

1.4 Disclaimer

Parts of the contents of this thesis are published in international journals, conferences and workshops. Detailed citations of the publications can be found in the respective parts of the thesis. The contributions of the author of this thesis comprise (i) original ideas, (ii) definitions and proofs, (iii) implementation, and (iv) major parts of the manuscripts. Parts of the research were funded by FWF grant P28187-N31, BMVIT grant FFG FIT-IT 829598, OeAD Marietta Blau grant ICM-2014-08600, a Marshall Plan scholarship and a Top Stipendium scholarship.

8 Chapter 2

Modeling and Verification of CPS – A Conceptual Reference Model

In the previous chapter we already introduced some terms and concepts from the field of CPS. In order to unify the terminology with the various terminologies used in literature and to span the field of CPS modeling and verification, in this chapter, we present some background on hybrid system modeling, formal verification, logic and component-based techniques. All contents inthis chapter of the thesis are based on our previous work “A Conceptual Reference Model of Modeling and Verification Concepts for Hybrid Systems” as published in “Knowledge Science, Engineering and Management - 7th International Con- ference”, cf. [79]. A major difficulty for systematically analyzing modeling and verification, and managing knowledge in the verification process of hybrid systems is a lack ofa common classification of hybrid system modeling and hybrid system verification concepts [79]. This lack of classification partly stems from the many different fields that study CPS: modeling, verification, hybrid systems, timed systems, real-time systems, etc. To overcome this lack of a common classification and to guarantee a systematic relation of the field of CPS with respect to the topics discussed in this thesis, we unify different terminologies and concepts of a variety of modeling and verification tools in a conceptual reference model (CRM). The rationale behind constructing the CRM (cf. Fig. 2.1) is as follows: In principle we followed a top-down approach, meaning that several concepts of the CRM have been adopted from existing other surveys in this area (e. g., [1, 19, 18, 43, 113, 111, 124, 55]). We supplemented our CRM in a bottom-up way with complementary concepts prevalent in existing tools. As formal verification can be challenging (cf. Chapter1), it is crucial to model these system in a way that allows formal verification, as implemented in formal verification tools. Accordingly, we structured our CRM into four packages:

9 CHAPTER 2. CONCEPTUAL REFERENCE MODEL

• the Systems package describes the real world systems; • the Modeling package abstracts from real-world systems to models of their behavior and specifications of important properties; • the Verification package aims at verifying the modeled systems; • the ToolSupport package contains tool-related aspects. These packages comprise artifacts and techniques essential for the application of formal methods (or here rather formal verification) to CPS. In the following sections, the concepts of the CRM are explained in detail along these four packages. Furthermore, we will position our approach in the CRM and highlight the techniques and concepts we use for our approach. We express the CRM as Unified Modeling Language (UML) classes [121], since UML is the prevail- ing standard in object-oriented modeling and expose the basic components of hybrid systems and the interrelations between them. In Fig. 2.1, we highlighted the classes representing the main aspects of hybrid system modeling and verification in green with a bold border. A hybrid system is modeled using a modeling formalism (describing the actual behavior of the system) and its verification specification is modeled using a specification formalism (describing the desired behavior of the system). A specification is aimed at a verification goal and refuted or verified by some verification evidence, produced by some tool. The (sub-)classes included in the CRM do not claim to be comprehensive, but represent a careful selection of popular concepts, relevant for this thesis. A more comprehensive version of the CRM can be found in the original paper [79].

Our Approach. The classes highlighted in blue with a dashed border, represent the main aspects discussed in this thesis. We model hybrid systems using hybrid programs, which employ ODEs and specify their behavior using dL. Our specifications aim at safety and are verified by a proof produced by a verification tool. The resulting verification results can then be composed using our approach.

2.1 (Cyper-physical) Systems

The classes in the Systems package of the CRM describe a high-level systems perspective to anchor modeling and verification tools. Following Teschl [119], we distinguish DynamicalSystems into DiscreteDynamicalSystems (state space N/Z) and ContinuousDynamicalSystems (state space R); systems that have both characteristics are CyberPhysicalSystems (CPS, or hybrid systems) [48], focused on in this thesis. Static systems, which produce output solely based on the current static system state are neglected, as they do not match the dynamic nature of real world systems. Systems like cars equipped with adaptive cruise control, where the discrete control decisions of the controller steer the continuous movement speed of the

10 2.1. (CYPER-PHYSICAL) SYSTEMS

{disjoint} * Analyzer Deductive Proof PartialProof Safety Reachability Reachability Liveness SuccessfulProof VerificationGoal VerificationTool ReachableStates CounterExample * implements

t UserInput * VerificationEvidence verifies

t *

u produces u refutes u aims at u allows allows VerificationTool uses

t * Tool produces u * Criterion Correctness Correctness Hint/Strategy * StartCondition Verification Verification t

expectations on * SpecificationTool interacts * starts at u Model Verification Specification Verification t utilizes supported by u uses produces u ensures u t

* t constrains * Collaboration ModelingTool * dL * CTL* Logic LTL CTL TCTL Artifact Condition utilizes

t t constrains * Refactoring Composition Specification Formalism Specification influences *

t describes LinearPDE LinearODE PartialDE OrdinaryDE Equation Differential Differential models

t references

* t Continuous Continuous DynamicalSystem

u u System Formalism contains contains contains contains CyberPhysical CyberPhysical DynamicalSystem ModelingFormalism * * Timed Automaton Hybrid t Hybrid

describes Program System Automaton

Program u Automaton DiscreteDynamical DiscreteDynamical describes describes

Figure 2.1: Conceptual Reference Model

11 CHAPTER 2. CONCEPTUAL REFERENCE MODEL vehicle, show that in CPS the cyber- and the physical part are often inseparably intertwined and influence each other. Thus, for a comprehensive analysis of a system, these CPSs cannot be separated, but have to be analyzed as a whole (i. e., cyber- and physical parts). Hence, special modeling and verification techniques that can handle both aspects of a system are needed, and will be introduced in the subsequent sections.

2.2 Modeling

In this package we introduce modeling concepts for dynamical systems, focusing on concepts for CPS. We distinguish models describing the actual and desired behavior of a system, and the formalisms used to create these models. The contents of the packages emphasize the difference between a model of a system, which can be described by various modeling formalisms (e. g., model of a robot: a robot can move with a specific speed on a plane), and the specification of a system, which can be described by various specification formalisms (e. g., specification of a robot: a robot will never crash into obstacles on that plane). The UML specification states that a model always is a model of “something”. As this “something” strongly depends on the use case at hand, countless modeling formalisms for most diverse objectives exist. What all of these formalisms have in common is that they abstract from irrelevant details of a system and focus on a specific part, which depends on the goals of the model (e. g., clear graphical representation) and the potential subsequent analysis (e. g., formal verification). In this work, we focus on models of CPS aimed at formal verification of their behavior. Traditionally, computer programs are sets of instructions that describe com- putations. Numerous such programing languages and abstractions (e. g., UML), to capture the cyber part of a system, exist. Differential equations are used to describe the behavior of physical systems [60]. So called hybrid-system models are used to capture both the system’s cyber and physical properties, which makes analysis of such models a challenging task [60]. The included formalisms are the most commonly used in literature, namely Automata and Programs [46] for modeling of discrete systems, Differential Equation for modeling of continuous systems [21], as well as their combination in the form of HybridAutomata/HybridPrograms [48, 90] for modeling of hybrid systems. To allow further constraining of a model, the CRM introduces Conditions. These conditions can, for instance, be used to describe how a system is initialized (e. g., if a ball is dropped, its initial direction of movement is downwards), or to avoid unrealistic behaviors in a model (e. g., a ball falling through the floor). Following Meyer [70], these conditions can further be subdivided into preconditions, postconditions and invariants.

2.2.1 Modeling Formalism Modeling formalisms are used to express models of dynamical systems.

12 2.2. MODELING

Discrete Modeling Formalisms As a basis for hybrid system modeling formalisms, we include the purely discrete automata and programs, which can be used to model discrete dynamics (e. g., set the acceleration to the maximum braking power to initiate emergency braking). An automaton comprises a set of States and a set of Transitions, and can be visualized as a directed graph [52]. A condition, when attached to an AutomatonElement, restricts or details the behavior of the automaton. Al- ternatively, programs represent a sequence of instructions. Although they are often interchangeable we separate these formalisms, because their structural differences can be utilized by verification tools.

Continuous Modeling Formalisms The purely continuous physical characteristics of a system are specified by differential equations1 [60], which in our case, represent the variation of values over time, e. g., v′ = a (where v′ is the time-derivative of v), i. e., the change of velocity v with a rate of acceleration a. There are many different types of differential equations (DE) and also multiple ways to classify them [128]. Continuous dynamics are typically modeled using ordinary differential equations [59]. Accord- ingly, we chose a classification into OrdinaryDE (ODE) and PartialDE (PDE). Moreover, several CPS modeling and verification tools restrict their analysis to a specific class of ODEs, namely linear ODEs (e. g.,[38], [39]). Accordingly, we include both linear forms (i. e., LinearPDE and LinearODE) as subclasses in our CRM. For instance, while general (or more specifically, non-linear) ODEs can be used to describe a circular two-dimensional motion of a robot, the restriction to linear ODEs constrains the robot to linear motion. In accordance with [91], we allow conditions to restrict a DE to remain within a particular region.

Hybrid Modeling Formalisms In this section, we discuss hybrid modeling formalisms, combining capabilities of discrete and continuous formalisms to allow modeling of CPS. Popular examples of hybrid system modeling formalisms are hybrid automata [48] and hybrid programs [97]).

Hybrid Automata. In analogy to theoretical computer science, where properties of computer programs are often studied in terms of automata (e. g., [32]), in CPS we have Hybrid automata [48]. Hybrid automata are based on finite state machines, where the discrete dynamics of the system are modeled by the state transitions, while continuous dynamics are modeled by differential equations, attached to the states of the system as so-called flow conditions. These differential equations represent the continuous behavior of a system while their respective state is active.

1For an introduction to differential equations, see [123].

13 CHAPTER 2. CONCEPTUAL REFERENCE MODEL

The generic concept of hybrid automata is the basis for numerous hybrid formalisms with different levels of expressiveness and detail, such as HybridUML [15] or Hybrid Petri Nets [30, 88]. Hybrid automata are not compositional, i. e., for a hybrid automaton it is not sufficient to establish a property about its parts in order to establish a property about the automaton. A compositional extension basing on a notion of input- and output-ports (so-called hybrid I/O automata [65]) allows decomposition of models. A special case of hybrid automata are TimedAutomata, which do not allow general differential equations, but limit the continuous dynamics to clocks that measure time and are thus used to model real-time systems [5]. Through this restriction, however, reachability analysis of such automata becomes decidable [11]. Similarly, a restriction of continuous dynamics to a subclass of linear ODEs also entails decidability of the reachability problem [104].

Hybrid Programs. Hybrid programs [97] are a program notion for hybrid system modeling, which comprise discrete program statements as well as continuous dynamics described by differential equations. Like above, we introduce hybrid programs [90, 94] as the subclass of programs which allows differential equations as instructions. Hybrid programs are compositional for each of their operators. Although hybrid automata can be encoded as hybrid programs [90], they differ in structural aspects that can be exploited by hybrid system verification tools.

Our Approach. In this thesis we will base on hybrid programs as modeling formalism as their compositionality is a helpful basis for our component-based modeling and verification approach.

2.2.2 Specification Formalism A VerificationSpecification describes a model’s expected behavior utilizing a SpecificationFormalism [22, 46]. A verification specification often consists of a StartCondition that specifies the initial conditions under which we wanta system to be safe to start, and a CorrectnessCriterion that we want a system to fulfill (e. g., throughout, after all, or after one of its executions). Furthermore, it is often possible to annotate models with Hints/Strategies, that guide a verification tool but do not influence the behavior of a model directly (e.g., inductive invariants holding during execution). A verification specification is expressed in terms ofa Logic [46], such as Temporal Logic (TL) [103] or differential dynamic logicd ( L)[90]. A logic typically consists of the following ingredients: (i) a syntax representing the used language, (ii) a semantics defining how to interpret the statements and (iii) a deductive system used to derive facts and relationships among semantic objects [47]. The rules of a deductive system are used in deductive verification (or theorem proving) to verify formulas that define properties of a system. The kinds of logic differ in terms of capabilities and expressiveness, and support various

14 2.2. MODELING kinds of quantifiers and modalities (e. g., [] or <> modalities in dL, A or E path quantifiers in CTL). First-order Logic [37] allows the definition of formulas which use quantifiers and variables. However, it does not support referring to state transitions, which is crucial for systems where the state changes over time like in CPS. Temporal Logic [103] allows the use of modal operators to refer to state transitions. Such formulas, however, only express generic properties, which do not consider actual system behavior. Examples of temporal logic include computation tree logic (CTL; future is not fixed, but is represented as a tree with different possible paths to the future, any one of which might be actually chosen), linear-time temporal logic (LTL; formulas considers the future as a trace and cannot switch between branches) and their common super-set CTL*. [53] Another example is the timed computation tree logic (TCTL) which extends CTL with the ability to measure time [2]. Dynamic Logic [47] allows the reasoning about programs by internalizing a program notation into the logical formulas through parametrized modal operators. The box modality [·] refers to all states which are reachable by execution of a program, i. e., the formula [α]ϕ states that all runs of a program α satisfy formula ϕ. Likewise the diamond modality ⟨...⟩ refers to the existence of at least one state after the execution of a program, i. e., the formula ⟨α⟩ϕ states that there exists at least one run of α that satisfies formula ϕ. These modalities can be combined and—when using first-order dynamic logic—include quantifiers. For example, the formula ∀v . ⟨α⟩[β]ϕ states that for all parameter choices v there exists at least one run of program α such that all subsequent runs of β lead to a state that satisfies ϕ. Differential Dynamic Logic (dL)[90] is a first-order dynamic logic over the reals for hybrid systems. Similar to dynamic logic, it supports (real-valued) quantifiers and parametrized modalities. However, in dL the modalities are parametrized with hybrid programs, thus allowing reasoning about CPS. dL comes with a sequent calculus for deductive verification, where the idea isto symbolically compute the effects of hybrid programs and transform them into logical formulas. Several extensions of dL exists, such as stochastic dL for stochastic systems [94] or quantified dL for hybrid programs with quantified statements [93]. The CRM includes logics typically used for the specification of properties for formal verification. Temporal logic is mostly used for specification of properties in model checking, which is why we include the popular CTL, LTL, their common superset CTL* and TCTL in our CRM. Differential dynamic logic is used for specifications of properties about hybrid programs and thus dL is part of our CRM.

Our Approach. In this thesis we use dL as it allows reasoning about hybrid programs and comes with a proof calculus for deductive verification. The calculus is based on uniform substitution and implemented in KeYmaera X [42]. Furthermore, hybrid programs and dL support non-linear ODEs and allow fully

15 CHAPTER 2. CONCEPTUAL REFERENCE MODEL symbolic reasoning. Thus, they act as an ideal basis for our component-based verification approach.

2.3 Verification

Verification methods for hybrid system models can roughly be grouped into two popular types [86]: methods based on model checking and verification by deduction (also called theorem proving [22]) . Irregardless of the type, verification is aimed at a specific VerificationGoal and results in some kind of VerificationEvidence.

2.3.1 Verification Goal Verification is usually defined to check the behavior of a system with respect to its intent [56]. Kern et al. [54] conceptually distinguish between property- and implementation verification. Property verification is concerned with specifying properties that are desired for a design, while implementation verification deals with the relationship between high-level models and the implementation. In the CRM we focus on property verification. For ensuring such an intended behavior, several verification methods exist, such as Model Checking and Verification by Deduction [56]. Such methods provide rigorous evidence (e. g., a proof) that a specification aiming at a verification goal is correct. Common verification goals include Safety (i. e., something will not happen) or Liveness (i. e., that something must happen) [57].

Our Approach. In this thesis we will focus on property verification aiming at safety. Nevertheless, it is important to keep in mind that formal verification is only performed for a model and never for an actual system. Thus, even if a hybrid system model is formally verified to be safe, this does not necessarily guarantee a safe system operation, since a model is at best an approximation of the real behavior of a system. However, when combined with run-time model validations, the guarantees about models transfer to systems [74].

2.3.2 Verification Evidence A verification evidence is any kind of result of attempting to formally verify a model. It is produced during the process of verifying the correctness of a model with respect to a verification specification. Regardless of the employed technique, verification tools usually attempt to reveal certain witnesses ofthe correctness of a model (e. g., reachable states, a formal proof). A Proof aims at verifying that the model is correct w.r.t. the specification. If some proof steps remain unverified, the proof isa PartialProof. Note that a partial proof does not necessarily imply refutation of the specification, as it might still be verified with a different proof attempt.

16 2.4. TOOL SUPPORT

A specification for a selected technique can be refuted bya CounterExample, which is mutually exclusive to a SuccessfulProof. Multiple counter examples might be found for each open proof step. As soon as one is found, the refutation of the entire verification specification is inferred. Another possible output is the set of ReachableStates, if a reachability analysis was performed. This set of states can then be compared to a set of desirable or undesirable states.

Our Approach. Due to our focus on deductive verification, in this thesis we aim at deriving successful proofs to guarantee the safety of our models.

2.4 Tool Support

The ToolSupport package includes Tools and additional information regarding their usage and configuration.

2.4.1 Tool In general, a tool (e. g., a specification tool) works with various Artifacts; it uses input (e. g., a model) to produce a corresponding output (e. g., a verification specification). Tools might require UserInput at run-time (e. g., user-guidance during verification). Furthermore, tools might interact with each other to enable Collaboration between instances of a single tool (e. g., multiple users might collaboratively produce a complex model using component-based modeling approaches) or different kinds of tools (e. g., different verification tools canbe used to verify a single specification). Our CRM includes three kinds of tools, according to the three major concepts for modeling and verification previously introduced in the CRM (i. e., model, specification and verification):

1. ModelingTools to support creation of models using a modeling formalism,

2. VerificationSpecificationTools to allow the formulation of a verification specification about a model using a specification formalism, and

3. VerificationTools that take the model and its specification and produce a verification result.

Note that a single tool can support multiple tasks, i. e., implement multiple tool subclasses.

2.4.2 Artifacts Artifacts are all kinds of information processed by a tool, e. g., a counter example, a model, a proof.

17 CHAPTER 2. CONCEPTUAL REFERENCE MODEL

Refactorings Artifacts can influence other artifacts (e. g., a counterexample may lead tore- vision of the initial model), since hybrid systems are often developed iteratively by model refinement. Refactorings support the refinement process through automated restructuring of different artifacts. They can for instance be used if a simple model should be enhanced to become more realistic.

Compositionality Since every component is also an artifact (e. g., a model can either be of an entire system or of a part of a system), through Composition, multiple artifacts can be composed to form further artifacts, i. e., components can be composed to form entire systems. Composition of artifacts can either be sequential or parallel. Sequential composition strings together the composed artifacts in a designated order, while parallel composition results in a model that executes composed artifacts simultaneously. As physical real-world phenomena usually occur in parallel (e. g., all cars on a road usually move at the same time, not one after the other), parallel composition is important for CPS—especially for the continuous physical parts. While hybrid programs—which we use in this thesis—are compositional for each of their operators (i. e., instead of establishing a property for a sequential composition of two hybrid programs, it suffices to reason about each program in isolation), they only support parallel composition for differential equations (for more details, cf. Section 6.1). Hybrid automata can be composed in parallel. However, the associated verification procedure (i. e., verify that a formula holds throughout all runs of the automaton) is not compositional, but requires verification of the exponential product automaton [3]. Thus, for a hybrid automaton it is not sufficient to establish a property about its parts in order to establish a property about the automaton. Hybrid I/O automata [65] (HIOA) extend hybrid automata with a notion of external behavior. The associated implementation relation (i. e., if automaton A implements automaton B, properties verified for B also hold for A) is respected by their composition operation in the sense that if A1 implements A2, then the composition of A1 and B implements the composition of A2 and B. The approach presented in [31] describes the use of HIOA in the reachability analysis tool SpaceEx [39]. A similar abstraction based on hybrid automata without explicit specification of inputs and outputs was introduced in[117]. Their approach includes a construction algorithm using state aggregation to create abstractions of models. Their parallel composition respects their simulation relation (analogously defined as the implementation relation above) ina similar fashion: if A1 simulates B1 and A2 simulates B2, then A1||A2 simulates B1||B2. In general, abstraction (e. g., implementation relation in [65], simulation relation in [117]) and compositional reasoning are two typical ways of dealing with verification of complex system [40]. Thus, many related component-based ap-

18 2.4. TOOL SUPPORT proaches (i. e., [7, 13, 16, 26, 28, 27, 40, 50]) are based on hybrid (I/O) automata (for more details, cf. Chapter4).

2.4.3 Verification Tools In our CRM we include two popular types of verification tools derived from two important verification techniques, being deductive verification and model checking [86].

Deductive Verification Deductive verification (or theorem proving) is the process of finding aproof that a model complies with its verification specification, by application of proof rules [22]. Kern et al. [54] refer to these techniques as Deductive Methods. For deductive verification, we introduce the class DeductiveVerificationTool. Based on some logic, deductive verification uses inference rules (i. e., proof rules) and axioms to transform formulas to mathematical truth. For instance, the proof calculus associated with dL can be used to transform dL formulas to first-order real arithmetic formulas, which are decidable [118]. The result of successfully proving a system property by deductive verification is a formal proof, containing the sequence of proof rules that were applied in order to verify the formula. On the one hand, general purpose deductive verification tools like Coq2 and Isabelle3 focus on proof techniques that enable proving anything about any problem rather than on libraries that make proving some very specific area easy. Thus, these general purpose tools require a lot of effort to describe all that is needed for hybrid systems. On the other hand, deductive verification tools specifically aimed at CPS—like KeYmaera X (supporting hybrid programs together with dL) and its predecessor KeYmaera—are rare, but focus on proof techniques and libraries that are relevant to prove hybrid systems.

Reachability Analysis Model checkers calculate the states that can be reached by a model (i. e., exhaus- tive state space exploration) and check if all are desirable [22]. However, since the term model checking, refers to a technique mainly used for verification of purely discrete systems, we use the term reachability analysis as the equivalent of model checking for hybrid systems. A ReachabilityAnalyzer [60] calculates reachable states. Since the continuous state space of hybrid system models does not admit finite-state abstractions, reachability analysis calculates reachable states either in an exact manner by limiting the continuous dynamics to simple abstractions or in an approximate manner by over-approximating the set of reachable states [4]. Many of the techniques that work with (over-)approximations have to deal with floating

2https://coq.inria.fr 3https://isabelle.in.tum.de

19 CHAPTER 2. CONCEPTUAL REFERENCE MODEL point issues. Reachability analysis is often performed when using hybrid (I/O) automata. Reachability analysis starts from a finite number of starting states (as opposed to deductive verification, which can handle infinite sets of starting states. The verification specification usually consists of the set of desirable states, which is then compared to the actually reachable states. If there is no overlap between the undesired states and the reachable states, or if the reachable states are a subset of the desirable states respectively, the verification specification is satisfied and the system behaves as desired. In general however, the verification specification is expressed in terms of a logic[46], e. g., UPPAAL uses TCTL.

Our Approach. As we base our work on hybrid programs and dL, we naturally use the associated deductive verification tool KeYmaera X. We do not use any specific modeling- and verification specification tools, but create ourmodels and specifications using a text editor.

2.5 Summary – Scope of our Approach

Overall the CRM provides an overview of the field of CPS modeling and verification, especially with respect to the topics of this thesis, where we dealwith CPSs (i. e., CyberPhysicalSystem), which we model using HybridProgram as a modeling formalism. Hybrid programs are associated with dL as a formalism for implementation of verification specifications. We focus on Safety as proof goal and do not consider other proof goals, like liveness. Consequently, we aim at finding Proof for the safety of our models, using a VerificationTool (i. e., verifying that the behavior of our Model complies with our VerificationSpec- ification). As we use dL, we focus on the associated deductive verification tool KeYmaera X and do not employ reachability analysis, which is often performed in conjunction with hybrid automata. Since we deal with component-based verification, we deal with components and Composition and furthermore, facilitate Collaboration by means of component reuse and exchange. As our focus is on verification, the modeling part is kept at a minimum. However, the CRM also highlights possible starting points for related approaches, which we will analyze in Chapter4. Especially approaches using a HybridAutomaton together with a ReachabilityAnalyzer to analyze the set of ReachableStates are often used for component-based CPS modeling and verification as well.

20 Chapter 3

Component-based Modeling

In this chapter, we describe the fundamentals of component-based modeling on which our subsequent work on component-based verification is based, cf. Sec- tion 3.1. Furthermore, we introduce a strategy for applying a component-based verification approach to a CPS, cf. Section 3.2. Finally, we derive requirements for a component-based modeling and verification approach, which allow identification of the class of systems an approach can tackle, cf. Section 3.3.

3.1 Terminology–Elements of Component-based Modeling

The definitions in subsequent parts of this thesis will use the terms and baseon the notation introduced in this section. We use the term monolithic model to refer to a hybrid system model that comprises every aspect of the respective CPS. Thus, a monolithic model does not interface with other models, but is instead self-contained and must thus be modeled and analyzed as a whole.

3.1.1 Component and Interface Generally speaking, Gossler et al. [44] define a component as a superposition of a behavior model and an interaction model, where the former describes the dynamic behavior of the component, while the latter defines the component connectors and their properties. A similar separation into behavioral and in- teractional parts of a system can be found in the unified modeling language’s (UML) section on components:

“A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. [...] A component specifies a formal contract of the services that it provides to its clients and those that it requires from

21 CHAPTER 3. COMPONENT-BASED MODELING

other components or services in the system in terms of its provided and required interfaces.” [121, p. 207]

This definition additionally highlights the replaceability of components within their environment, which is an important factor for reuse of a component and maintenance of a system. Furthermore, the definition distinguishes provided and required interfaces. Specifically for hybrid system models—more precisely for hybrid programs and dL—Ruchkin et al. [109] define a component as “a primary entity for information hiding and reuse”. Since their architecture is aimed at CPS, a component in their sense consists of a control part, comprising all discrete parts of a component specification and a physical part, consisting of differential equations representing the continuous parts of a component specification. Their definition additionally comprises a state, including a set of variables together with state constraints, and ports as a set of variables that allow interaction between components. Basing on this previous work, in this thesis, we use the following notion of components and interfaces.

Component Components in our sense consist of a discrete cyber part and a physical control part, which represent the component’s internal behavior. Components do not share any variables, i. e., each component has a set of local variables, which is exclusively accessed in the component’s cyber part and physical part (cf. information hiding). Additionally, all components share a set of global constants, which can be accessed everywhere, but never modified 1.

Interface Interfaces define a component’s interactions with other components and their respective interfaces. While the component itself describes its internal behavior, the interface describes the component’s external behavior. An interface consists of a set of input ports and a set of output ports. Through input port variables, a component receives external values from other components. Through output port variables, a component passes values to other components. Thus, interfaces define the information shared with other components (cf. information hiding). To allow interaction between components through these ports, the involved components must agree on the values that are actually transferred. Thus, an interface in our sense comes with a contract, which is a set of logical formulas—one formula for each input- and each output port—representing input requirements that state what values are allowed on a specific input port,

1Although, a set of globally shared constants works nicely in a model, in real-world component-based systems, a global constant would require a shared memory that can be accessed by every component. Since such a shared memory might not be available, global constants can be implemented as local constants with uniform values in an implementation.

22 3.1. TERMINOLOGY respectively output guarantees that state what values an output port actually delivers. Even though we separate components and interfaces, they usually appear in pairs (i. e., a component with an interface). A component without an interface does not support any interaction and is nothing more than a monolithic model. The other way around, an interface without a component would describe interactions of a non-existing component, as an interface is a purely theoretical construct. Fig. 3.1 shows a graphical representation of a component with its interface.

Input ports 퐼푛푖 with Output ports 푂푢푡푗 푖푛 표푢푡 requirements 휋푖 with guarantees 휋푗 transferring values 푥푖 transferring values 푦푗

퐼푛1 푂푢푡1 푥1 푦1

푖푛 표푢푡 휋1 휋1 … Component … 퐼푛푛 푂푢푡푚 푥푛 푦푚

푖푛 표푢푡 휋푛 휋푚 Interface

Figure 3.1: Generic structure of a component and its interface: The internal behavior of a component is encapsulated by the interface, which provides interaction with the component’s surroundings, through (arbitrary many) input ports Ini and output ports Outj. The ports allow transfer of values xi to- or yj from the encapsulated component, cf. dashed arrows. If two ports should in be connected, the key (i. e., input requirement πi ) must fit into the respective out lock (i. e., output guarantee πj ).

We refer to a port that transmits multiple values as a multi-port. Multi- ports can be viewed as sets of input ports (respectively output ports), which share a common input requirement (respectively output guarantee). The main difference to regular ports is that in this case, the requirement (respectively guarantee) describes the behavior of all associated ports, and not just the behavior of a single port. For example, two regular ports a and b allow separate properties only, e. g., a ≤ 1 and b ≤ 1. A multi-port comprising a and b however, would allow combined properties, e. g., a + b ≤ 1.

Types of Models

As with all formal models (cf. Section 2.2), component-based models can be used for various purposes. Since in this work, we focus on formal verification,

23 CHAPTER 3. COMPONENT-BASED MODELING our models are specifically targeted at describing and reasoning about a component’s behavior. Formal languages tend towards a minimal syntax, since formal verification relies on correct instructions. Consequently, our models neither focus on sophisticated forms of visualization that facilitate modeling (cf. UML), nor on object-oriented capabilities like dynamic binding, classes and inheritance (cf. programming languages), complex modes of component interactions, and dynamic reconfigurations at runtime. We aim at static models (i. e., models that do not change at runtime), which can be verified at design time.

3.1.2 Composition and Compatibility To build comprehensive hybrid system models for CPS using components, a composition operation to compose compatible components through their interfaces is needed.

Composition A composition operation can be formalized as an n-ary operation, taking a number of components with their interfaces and additional information about their interactions, and returning a composed component and interface [44]. Com- position operations can be roughly distinguished into sequential and parallel composition, cf. Section 2.4.2. Hybrid programs can be composed sequentially on operation-level, by using the sequential composition operator “;”. Parallel composition is supported for differential equations in hybrid programs, but gives rise to issues of interleaving and synchronization [17] in the discrete fragment. Interleaving specifies how component operations are transferred to the composite, while synchronization defines the coordination of operations across components. On component-level, Ruchkin et al. [109] propose a composition operation that executes control parts sequentially, while continuous plant parts are executed in parallel. Thus, their composition operation uses just one possible interleaving of discrete statements and synchronizes continuous operations to run in parallel (i. e., all differential equations are started at the same timeand run for equal duration). However, they suggest further composition operations, like an alternating composition, which might consider further interleavings, as future work. Ultimately, considering hybrid time, where discrete operations do not consume any time, every interleaving of discrete statements is conceivable (for more details, cf. Section 6.1.1). Thus, to compose two such components (each consisting of a control part and a plant part) comprehensively in parallel, the control parts must be composed as a non-deterministic choice of all possible operation interleavings (e. g., by means of an extension function like [14]), while the plant parts are actually composed to execute in parallel. However, this might lead to an enormous amount of branches. Conversely, Lunel et al. [64] present a parallel composition operation for dL, which does not consider interleavings at all, but uses non-deterministic choice

24 3.1. TERMINOLOGY between all control parts and the parallel composed plants. On the one hand, such a composition operation is rather flexible as the resulting system is free to choose in which order the control parts and the plant are executed. Even more so, it allows repeated execution of a single control part. On the other hand, this composition operation introduces the issue of “fairness”, as it can no longer be guaranteed that each controller is allowed to run. To the contrary, the resulting system allows repeated execution of just one single control part, or a single control part and the composed plant. Thus, it is up to the user to design the models in a way that ensures such fairness properties, i. e., ensure that each control part is executed.

In order to, on the one hand reduce the number of branches when compared to comprehensive composition on operation level, and on the other hand, avoid the issues of fairness, in this thesis we consider all possible interleavings between entire control parts, and compose the resulting control sequentially with the (parallel) composed differential equations.

푖 1 Component 퐶4 표 푖 표1 휋1 ↔ 휋1 Interface 퐼4

표2 Component 퐶1 푖2 표 푖 표3 휋3 → 휋2 푖3 휋표 ↛ 휋푖 표 4 3 4 Component 퐶2

Interface 퐼1 푖4

푖 Component 퐶3 5 표 푖 표5 휋5 ↔ 휋5 Interface 퐼3 Interface 퐼2

Figure 3.2: Port Connection: The output port o3 in the interface I1 of component C1 is compatible with the input port i2 in the interface I2 of component C2, since the key (i. e., the output guarantee of the port) fits into the respective lock (i. e., the input requirement of the port) and can thus be connected, o i even though it is not a perfect match (i. e., π3 → π2). Ports o4 and i3 are not compatible—as visualized through the key not fitting into the respective lock— and thus, a connection is not allowed between these ports. Output port o2 and input port i4 are not connected yet and remain open. Input port i5 of I2 can be connected to a different component’s interface I3, as long as the respective ports i5 and o5 are compatible. Similarly, output port o1 of I1 can be connected to a different component’s interface I4, as long as the respective ports o1 and i1 are compatible.

25 CHAPTER 3. COMPONENT-BASED MODELING

Compatibility

Another aspect of composition is the associated connection of interfaces through ports to exchange information between components. If components are composed, any number of input ports can be connected to output ports, provided they are compatible. An input port and an output port are compatible, if the output port’s output condition matches the input port’s input condition. Fig. 3.2 shows compatible and non-compatible ports when composing two components through their interfaces. For instance, if the output condition πout is at least as strong as the input condition πin, i. e., πout → πin, a value emitted from the output port will always fulfill the input requirement of the input port andcan thus be received on the input port. A port, which guarantees the output property πout ≡ x ≤ 5 can thus be connected to a port, which requires πin ≡ x ≤ 5, but also to a port, which requires ρin ≡ x ≤ 10. Note that not all ports of a component must be connected to the ports of a single other component. Ports can remain unconnected after composition and might be connected to other components later on. Also note that multi-ports can naturally only be connected to other multi-ports of the same size (i. e., multi- ports, which contain the same number of ports). Even though the individual ports of the multi-port must be connected one by one, compatibility must only be checked once for the multi-port as a whole, cf. Fig. 3.3.

휋표푢푡 ↛ 휋푖푛

Component 퐶1 휋표푢푡 → 휋푖푛 Component 퐶2

휋표푢푡 → 휋푖푛

Interface 퐼1 Interface 퐼2

Figure 3.3: Multi-port Compatibility: a multi-port delivers more than one values to- or from the encapsulated component (denoted by multiple dashed arrows), which share a single common assumption or guarantee (denoted by a single lock/key for multiple values). The first multi-port of I1 bundles the same number of individual values of C1 as the respective multi-port of I2. Nevertheless, they cannot be connected, as the respective assumptions and guarantees do not match. The guarantees of the second multi-port of I1 match the assumptions of the respective multi-port of I2, but as the number of individual values does not match, again they cannot be connected. The third multi-port of I1 is compatible with the respective multi-port of I2. As both ports comprise the same number of values, they can be connected.

26 3.1. TERMINOLOGY

3.1.3 Contracts and Refinement Parts of the contents in this section of the thesis are based on our previous work “A Benchmark for Component-based Hybrid Systems Safety Verification” as published in “4th International Workshop on Applied Verification of Continuous and Hybrid Systems”, cf. [83].

Contract A contract is an assertion on the behavior of a component, including its input- and output behavior as described by its interface. More specifically, a contract contains on the one hand, the assumptions under which a component may be used and on the other hand the guarantees it warrants under such correct use [12, 112]. Similarly, Bauer et al. [8] define a contract as a pair (A/G), where A is a specification of an assumption and G is a specification of a guarantee. In software engineering so-called assertions are used to state what is required and ensured by a function (here in Eiffel [69] notation) [70]: function-name(arguments) is require Precondition do Function body ensure Postcondition end

This contract for the function “function-name” requires a precondition to hold before running the functions body, and ensures a postcondition after the run, similar to a Hoare triple P {Q}R [51], with precondition P , postcondition Q and program (or function) Q. This contract has to hold for each run of the function. Similarly, a contract can be defined for a hybrid program. The initial state describes the precondition that has to hold before each run of the program. The safety condition describes the postcondition that has to be ensured by all runs of the program. Using dL, such a contract can be written as

φ → [a]ψ , where φ is the initial state description, a is a hybrid program and ψ is the postcondition. The box modality ensures that the postcondition has to hold after all runs of the program. Such a property is also called a safety property, cf. Section 2.3.1. When working with component-based hybrid system verification, two major challenges arise: handling local component contracts (i. e., individual contracts for individual components) and dealing with component interaction and communication. In a monolithic system, these interactions are baked into the system

27 CHAPTER 3. COMPONENT-BASED MODELING model, so a system contract defines properties of the initial states and overall system safety. When working with components, however, a local contract for each component together with a way of handling component interaction is needed, and might include assumptions and guarantees about the communication and interaction between components. For example, a contract might restrict a vehicle’s movement to prevent it from teleporting, or specify the acceptable degree of input sensor uncertainty.

Levels of Contracts. Component contracts ensure safety properties of a single component in isolation. Contracts can be classified according to their capabilities, which can comprise static regions, magnitude of change or rate of change over time, cf. Fig. 3.4.

푋 푥 푡 푥 푡 푥 푡

푡 푡 푡 (a) Static regions (b) Magnitude of change (c) Rate of change

Figure 3.4: Levels of Contracts

Accordingly, contracts scale in complexity as follows:

Global contracts restrict values to globally known (symbolic) regions. For instance, a robot might be confined in a known, fixed area, e. g., the robot’s position x must always be in a fixed interval (e. g., −9 ≤ x ≤ X, where X ∈ R is a constant). Change contracts restrict the magnitude of change (e. g., relate a value from the last control cycle or a previously communicated value with the current value). For instance, a robot may guarantee to not request sudden changes in the sense that the current request x and the previous request x− are not too far apart (e. g., −9 ≤ x − x− ≤ X).

Delay contracts restrict the rate of change. For instance, a robot may guarantee to change its position according to its speed, so the current position x and the previous position x− are related by time t as in −9·t ≤ x−x− ≤ X · t.

Dimensions of Communication. Communication and interaction between components can be subject to information loss and delay.

Lossy communication occurs, since in real-world environments ports are often subject to information loss or sensor uncertainty and thus, provide

28 3.1. TERMINOLOGY

slightly off approximations of the actual values. Even though the actual error might be unknown, the maximum error is often bounded (e. g., according to a sensor specification). Lossy communication could, for instance, be modeled using a non-deterministically chosen error value λ (λ := ∗ non- deterministically assigns any real value to λ), bounded by the maximum error Λ (the test ? |λ| ≤ Λ ensures that the value of λ is between −Λ and Λ), which distorts the communicated value, so λ := ∗;? |λ| ≤ Λ;x ˆ := x+λ.

Delayed communication results in accumulated error, e. g., a distance sensor in a car may report slightly outdated values. The error then depends on speed and time delay.

Instantaneous, lossless communication—not considering information loss or delay—is often used as a first approximation of sensing and communication, and can be modeled by a direct assignment of variables, e. g.,x ˆ := x. Also, communication might be lossy as well as delayed, leaving us with the dimensions

of communication as in Fig. 3.5.

Lossy Lossless Instantaneous Delayed

Figure 3.5: Dimensions of Communication: Communication can be subject to information loss, delay or both.

In this thesis, we define contracts and communication according to these categories: We introduce global contracts with instantaneous, lossless communication for traffic control systems in PartII and for generic systems in PartIII. In PartIV we extend our approach to support change and delay contracts. Finally, in Chapter 16, we further extend our approach to support lossy communication. Communication delay is not approached in this thesis and remains as future work, cf. Section 17.2.

Refinement A contract refines another contract, if under weaker assumptions the component promises stronger guarantees. This definition of refinement (or dominance), is inspired by the work of Benvenuti et al. [13], who defined dominance checking. Similar notions of refinement can be found in the literature (e. g.,[6,8, 75]). If a contract refines another contract, the refined (hybrid) programs can replace the original (hybrid) program. The program of the refined contract guarantees to hold under weaker assumptions, and thus it will also hold under the stricter assumptions of the original contract. Likewise, the program of the refined contract guarantees a stricter postcondition then the original one,and

29 CHAPTER 3. COMPONENT-BASED MODELING

(1) identify system contract Φ → [CPS]Ψ

(2) model components and interfaces (C1,I1) , (C2,I2) , ..., (Cn,In)

safe out (3) identify contracts φi, ψi , and πi such that ⋀ ⋀ ( safe out ) Φ → i φi and i ψi ∧ πi → Ψ

(4) verify contract compliance ( safe out ) φi → [Ci] ψi ∧ πi and Verification Contract Definition (5) compose and check compatibility (C1,I1)∥(C2,I2) not compatible

compatible |= Φ → [C1∥C2]Ψ, thus |= Φ → [CPS]Ψ

Figure 3.6: Stratety: Steps for component-based modeling and verification thus if the stricter condition holds, the less strict original one will hold as well. Hence, if the program of the refined contract obeys its contract, it even more so fulfills the original contract.

3.2 Strategy–Applying Component-based Veri- fication

In this section, we present a strategy demonstrating the modeling and verification steps necessary to apply a component-based verification approach, cf. Fig. 3.6. To illustrate the steps, we will use an example of a vehicle cruise control system, which consists of an engine component adapting the vehicle speed according to a target speed chosen by a cruise control component (for more details, cf. Section 5.2). The vehicle moves continuously, while the control behavior is described by a discrete control part (e. g., choose speed and acceleration). The goal is to keep the actual speed in some range [0,S], where S denotes a maximum speed. Note that we consider fully symbolic components, which means that each component represents actually a family of concrete components. The approach consists of the following steps:

(1) identify global contract: Before decomposing the system, it is important to learn what properties the system as a whole should fulfill. This step

30 3.2. STRATEGY

might require the assistance of domain experts, to identify the properties and other technical details of a CPS. The global contract specifies the initial state of the whole system (Φ) as well as its overall safety property (Ψ). The initial state of a system determines the possible valuation for the system’s variables at the start of each program run. Considering our example, the initial state might fix the vehicle’s initial speed to 0 (i. e., the vehicle is initially stopped). The global safety property describes the desired behavior of the overall system. For instance, the vehicle cruise control system has to ensure vehicle speeds within a certain interval 0 ≤ s ≤ S. Note that the hybrid program for the overall system does not necessarily have to be known beforehand. As the hybrid program resulting from the composition of different components obeys the global safety property (i. e., refinement, cf. step (3)), this program can be used to describe the behavior of the overall system, thus replacing the (potentially unknown) monolithic program.

(2) model components and interfaces: Next, the system has to be split into components. We illustrate three possible strategies on an exemplary basis in Chapter5. Recalling our cruise-control example, we split the system into a cruise controller component and an engine component. In this case, the strategy is to separate those parts of a system that will most likely be adjusted, replaced or revised separately at later stages. A general rule of thumb is to keep the number of different components small, so that the verification effort remains low; still, there have tobe sufficiently many components that can be instantiated to assemble the system. Modeling components and their interfaces is a manual effort (e. g., by modeling experts). A component has a behavior, while its interface defines public input ports and output ports (cf. Section 3.1.1).

(3) identify contracts: For each component and its interface, local initial states φi (e. g., initial target speed is 0), as well as a local safety prop- safe erty ψi (e. g., actual speed does not exceed the maximum speed), have to be identified. The local initial and safety conditions depend onthe partitioning, but should always be chosen with the global safety criterion in mind. Besides the local safety property, each component additionally has indi- out vidual output properties πi (e. g., target speed is always in the desired range), one for each output port identified through its interface. These properties ensure that a component actually delivers the values it promises at its outputs. For example, the automated cruise controller component from our running example guarantees to request only valid speeds (i. e., speeds within the target interval) on its output port.

31 CHAPTER 3. COMPONENT-BASED MODELING

Note that these properties have to be chosen such that the global con- ⋀ ⋀ safe tract follows by refinement (cf. Section 3.1.3): Φ → i φi and i(ψi ∧ out πi ) → Ψ. Thus, the system composed from components guarantees at least the same safety property as initially desired for the overall system, starting from a potentially more general initial state. (4) verify contract compliance: After all local contracts have been identified, formal verification ensures that each component satisfies its contracts. (5) compose and check compatibility: Finally, the system has to be recon- structed by connecting ports to compose verified components in parallel (cf. Section 3.1.2). Components can be used multiple times throughout the system (i. e., use one engine for the first car, using a maximum speed of S1 and a second engine for the second car, with a maximum speed of S2) and—as components are defined fully symbolical—can use different valuation (e. g., connect the controller with the first engine; later instantiate maximum speed parameter S1 with an actual value). Note that the variables of each component instance are considered unique names, which can be ensured by renaming. In order to transfer proofs about components to a global system proof, the compatibility of the components must be ensured (cf. Section 3.1.2). Intuitively, the compatibility check ensures that the possible values of an output port of one component are compatible with the values required on a connected input port of the second component (e. g., if the cruise control component provides values from the interval 0 ≤ s ≤ S, while the engine requires values from the interval −S ≤ s ≤ S, the two are compatible, as all transferred values are guaranteed to be within the target interval). If components are not compatible, components, interfaces and contracts must be refined until compatibility can be ensured.

The strategy above outlines the—in our experience—most common work- flow when dealing with component-based modeling and verification. However, depending on the knowledge about the overall system, the exact strategy may differ. If parts of the global contract are not available (i. e., initial condition or safety condition), the respective part of the refinement check in step (3) can be neglected. If no global contract is available at all, the refinement check is omitted completely and the conjunction of all local contracts can be used as global contract. Remark 1. After compatibility has been ensured and the components have been composed in step (5), we can derive a monolithic hybrid program for the resulting composite system. This is especially useful, if the system requires a centralized controller (e. g., a traffic control center that steers traffic from a central point, cf. Section 5.1) However, for distributed systems the component programs can still be used separately, as long as they are compatible and their local contracts are fulfilled (e. g., a robot and a remote are two distinct physical entities, which have to be controlled separately, cf. Section 5.3).

32 3.3. REQUIREMENTS SUMMARY

Remark 2. Steps (2) to (4) (ignoring the refinement check) can be used without the rest of the strategy to create a library of components and verify their behavior. Also, as the composite does not only retain the local properties, but is still a component, step (5) can be applied to create larger library components, by composition of previously verified components. The main result of this process is that the component safety proofs—done for compatible components in isolation—transfer to an arbitrarily large system built by instantiating these components. PartII–PartIV describe the formal details.

3.3 Requirements Summary

From the fundamentals introduced in this chapter, we now derive the basic requirements for a component-based modeling and verification approach. These requirements determine the class of systems that such an approach can address and lay the foundation necessary to reach our initially presented goals, namely, reducing verification complexity and increasing maintainability and reusability. Following the terminology introduced in this chapter, for a component-based approach we require notions of components, interfaces and contracts, their compatibility and their composition. Components: As components are the central part of every component-based approach, a formal notion of a component—comprising its discrete and continuous parts—is needed, to allow reasoning about a components behavior. Interfaces: An interface describes the external behavior of a component. An interface can hold any number of input- and output ports, and includes a property for each of these ports, describing its expected (respectively guaranteed) behavior. Additionally, ports could be grouped into multi- ports. Thus, a formal notion, encompassing the (multi-) ports and their properties is needed. Contracts: A contract describes the desired behavior of a component with an interface and must be analyzable in isolation. A formal notion of a contract is needed, encompassing the initial state and the safety property. It can be distinguished between the levels of contracts introduced in Section 3.1.3, i. e., global-, change- and delay contracts. Composition: Finally, we need a notion of (parallel) composition of components, which allows communication through ports. We can distinguish the dimensions of communication introduced in Section 3.1.3, i. e., instantaneous- or delayed-, lossless- or lossy communication. In PartII–PartIV we will gradually introduce the respective notions following these requirements, and use them to derive theorems that ensure transfer of local safety property to system level, as described by our strategy in Section 3.2.

Chapter 4

Related Work

The research field of hybrid-systems is wide and comprises a lot of modeling and verification approaches. Thus, it is important to filter the actually related approaches from this multitude of existing work, like we do in Section 4.1. We start our discussion of related approaches with the most closely related approaches, namely component-based CPS verification approaches, in Section 4.2. In Section 4.3 we then review the related field of assume-guarantee reasoning for hybrid automata. Finally, we will conclude this chapter in Section 4.4, where we summarize the insights gained from our survey.

4.1 Selection of Approaches

Following our CRM, we will only consider approaches that can be located in all of the four top-level packages (i. e., systems, modeling, verification and tool support). Consequently, we will only consider approaches that support component- based formal verification to reason about safety of hybrid systems. Note that we compare related approaches to our approach, following the requirements presented in Section 3.3. Consequently, we will not discuss approaches like UML [121] or Modelica [41] in detail, which are well suited for purely discrete and purely continuous systems, but do not focus on hybrid system models. We will not discuss approaches like Ptolemy [34] in detail, which are aimed at hybrid system modeling, but do not focus on formal verification. We will not discuss approaches like CheckMate [114], C2E2 [33, 36], HSolver [105], PHAVer [38], SpaceEx [39] in detail, which support monolithic hybrid system verification, but do not focus on component- based verification. We will not discuss component-based modeling approaches, which allow compositional modeling, like [66] (using UPPAAL [10]) or hybrid process algebras (e. g., Hybrid χ using PHAVer [126], HyPA using HyTech [67], Φ-Calculus using SPHIN [115]) in detail, because for verification purposes they analyze models using simulation or reachability analysis in a non-compositional fashion. We will also not discuss approaches focusing on architectural properties

35 CHAPTER 4. RELATED WORK of component-based hybrid system models like [109] in detail, as they do not transfer verification results from components to composites. Although manyof these approaches served as valuable input and provided us with several starting points for our work, we will focus our below discussion of related work on the most related approaches.

4.2 Component-based CPS Verification

In this section, we discuss related component-based CPS verification approaches, starting with the most closely related approaches, which employ deductive verification with dL ([64],[63]), or a similar formalism ([107]). This is followed by a discussion of approaches based on hybrid automata ([7], [26], [28]).

Compositional proofs in differential dynamic logic dL [64]. A component-based verification approach using dL was presented in [64]. The authors define components separated into discrete and continuous parts, using hybrid programs. Their associated composition operator transfers safety from component level to system level, i. e., the conjunction of component contracts holds for the composed system. However, their composition operation results in a hybrid program consisting of a non-deterministic choice of all control parts and the parallel composed plants, which introduces issues of “fairness” (cf. Sec- tion 3.1.2), while we consider interleavings of control parts to ensure fairness by design. Furthermore, their approach aims at composition of contracts with restrictions on variables, but does not consider compatibility of ports. We on the other hand, use interfaces to explicitly designate inputs and outputs together with their behavior, which facilitates reuse of components and allows a notion of compatibility.

Adaptive cruise control: hybrid, distributed, and now formally verified [63]. A first approach of splitting hybrid program models into smaller parts was presented in [63], with an adaptive cruise control system for autonomous cars on a highway. The approach used quantified hybrid programs [93] to verify that an arbitrary number of cars will not collide. In quantified hybrid programs, all components have the same structure (e. g., many cars each controlled with the same kind of controller, or many identically constructed robots) whereas we focus on different components.

Modular deductive verification of sampled-data systems [107]. A formal verification approach based on the proof assistant1 Coq was presented in [107]. Their formalism is based on the discrete-time linear logic RTLA (inspired by Lamport’s Temporal Logic of Actions, TLA [58]). Each component contains an action formula specifying the discrete controller, and operates on a set of differential equations shared among all components, representing the

1https://coq.inria.fr

36 4.2. COMPONENT-BASED CPS VERIFICATION global continuous world. Additionally, each component comes with a formula describing its initial state. They do not use a notion of interfaces, as their components are closely coupled through shared variables. If a component guarantees a property P and if, under the assumption that P always holds, a second component guarantees a property Q, their composition guarantees that both properties P ∧ Q always hold. Composition is defined as follows: the composite initial state is the conjunction of both initial state formulas and the composite discrete controller is the conjunction of both discrete controller formulas) . In [108] they add further ways of composing components, like disjunctive composition, which states that in the composition, at least one discrete controller formula must hold. Their approach is aimed at verification of closely coupled (i. e., shared variables) controllers operating on a shared continuous world, while we employ a notion of interfaces to verify independent components in isolation, which are then connected through ports.

A compositional approach to the verification of hybrid systems [7]. A compositional verification approach based on linear hybrid automata in[7] (i. e., convex linear guards and linear continuous dynamics) uses invariants to over-approximate component behavior and interactions. Composition is only allowed for automata with disjoint sets of variables and actions, and yields the cross-product of all automata states. They use an abstraction of components and interactions through invariants: Component invariants characterize the reachable states of the individual components; interaction invariants disregard certain states as infeasible in the composition and thus identify the states reachable in the composition. If the conjunctions of the invariants of all components together with the interaction invariant implies a global invariant (i. e., a safety property), the global invariant holds in every reachable state of the parallel composition of the components. Time progresses across components is synchronized with history clocks, which measure for each action the time that has passed since its last occurrence. While in this approach, based on invariants as abstraction for linear hybrid automata, interactions between components are restricted to synchronization (i. e., no variables can be transferred between components), we allow communication through ports using contracts as abstractions for (potentially) non-linear hybrid programs.

Towards component based design of hybrid systems: safety and stability [26]. An approach for the compositional design of hybrid controllers with linear dynamics, and with focus on realistic reaction times (i. e., task switching takes time) and distributed controller design (i. e., no centralized mode switching) is presented in [26]. The approach supports sequential composition of controllers, which cooperatively control a shared plant, where only one controller at a time is actively operating the plant. If a state in which the controller can no longer guarantee safety or stability properties of the system is reached, the component raises an alarm. Each outgoing alarm can be connected to several inputs, annotated with a guard condition, as long as there is at least one con-

37 CHAPTER 4. RELATED WORK troller to handle an occurring alarm. An algorithm, which allows distributed identification of helpers that can deal with the different arising alarms (e.g.,a braking component, that can stop the car in time, when it comes close to an obstacle), is used to find a composed component to take control of the plant, after a predefined reaction time. This alarm propagation system allows ade- centralized setting, in which each component is aware whether or not a mode switch is necessary, without a centralized controller. The alarms raised by a controller component and the alarms handled by a controller component are part of its interface, together with guarantees about the safety and stability of the associated plant (e. g., duration how long a component can keep the plant state safe after it raised an alarm, time it takes an alarm receiving component to react to an alarm). When a controller is activated through an alarm, it can instantaneously receive any number of values from the previously active controller. Even though outgoing alarms can be connected to multiple alarm- receiving inputs, the actual communication occurs between one sender and one receiver, where the target receiver is chosen using a negotiation algorithm. Lya- punov functions are used to verify that a controller component complies with its interface. When composing components that are able to mutually handle each others alarm (i. e., after a compatibility check), the approach guarantees that the resulting system controller complies with the resulting interface. In contrast to our approach, [26] is solely concerned with sequential composition of controllers of hybrid systems. We, instead, focus on parallel composition of components through their contracts.

Component based design of hybrid systems: a case study on concurrency and coupling [28]. A case study on supporting parallel composition in [26] is presented in [28] and—with further details—in [27]. The approach supports multiple controller components operating on a shared plant. The components are assumed to be loosely coupled (i. e., sparse direct communication and less mutual influence) and to communicate through events. These events are different from the alarms of their previous approach, as they can beused to temporarily weaken the interface restriction on a single component (e. g., a controller component steering the movement direction of a car can inform a velocity controller steering the speed of the car that a straight stretch of road is coming up, and thus, temporarily higher speeds are possible). Additionally, the interfaces include base assumptions and guarantees (e. g., cars move according to the laws of physic), which have to match (i. e., be compatible), when composing components in parallel. If compatible components are composed, safety and stability properties from single components transfer to the composed system. While [27] assumes parallel composition of loosely coupled controllers operating on a shared plan, we consider independent components, where each component can come with its individual plant.

38 4.3. ASSUME-GUARANTEE REASONING

4.3 Assume-Guarantee Reasoning

Hybrid automata [3] are mainly verified using reachability analysis, which com- putes or approximates the states reachable by a system and is thus subject to the state-space explosion problem, when multiple automata are composed. Therefore, techniques to prevent state-space explosion are needed, like assume- guarantee reasoning (AGR, e. g., [13, 40, 50]), which was developed to decompose a verification task into subtasks. In general, AGR approaches use abstraction to simplify parts of the system and show that the composition of these simplified parts resembles the original system. It then suffices to show safety properties for these simplified systems. We on the other hand, subsume the external behavior of a component through its contract. Safety properties for a single component are then verified in isolation, considering only the contracts of interacting components. We provide more detailed distinction to our work individually for each subsequently analyzed approach. We begin the discussion again with the most closely related approach, allowing non-linear continuous dynamics ([13]). The remaining approaches are limited to linear continuous dynamics and ordered by the conservativeness of the used abstractions ([16], [40], [50]).

Assume-guarantee verification of nonlinear hybrid systems with Ari- adne ([13]). The AGR approach of [13] uses contracts—consisting of input assumptions and output guarantees—to verify properties about single components. They focus on two problems: contract satisfaction and dominance checking. Regarding dominance, they introduce a dominance relation, which states that a component C1 with assumptions A1 and guarantees G1, dominates another component C2 with assumptions A2 and guarantees G2, if A2 ⊆ A1 (i. e., assumptions on C1 are weaker then the assumptions on C2) implies G1 ⊆ G2 (i. e., guarantees of C1 are stronger then guarantees of C2). Then, if C1 dominates C2, C1 can replace C2 in the system, without affecting the overall system behavior. This notion of dominance is similar to our notion of contractual refinement, cf. Section 3.1.3. For verification of the contract satisfaction problem, they consider a hybrid automaton modeling the input assumptions that provides values for all input variables of the component under consideration. Then their approach calculates the states reachable by the output ports of the component, which can then be compared to the output guarantees: if the reachable states are a subset of the guaranteed output states, the contract is satisfied. Furthermore, they support non-linear dynamics, which—as they state—limits the scalability of the computational engine, because for instance, determining accuracy parameters for the discretization, like grid size, is challenging. On the contrary, our approach is based on hybrid programs and dL, and thus supports fully symbolical analysis. However, while we focus on transferring safety properties from component level to system level, they do not present a way of composing contracts, but focus on contract satisfaction and dominance.

39 CHAPTER 4. RELATED WORK

Assume-guarantee abstraction refinement meets hybrid systems [16]. An AGR approach for affine hybrid systems focusing on stratified controllers (i. e., controllers consisting of multiple layers, each responsible for one plant parameter) is presented in [16]. Their approach is based on the following AGR rule, considering a safety property P , a Plant H1, a controller H2 and an assumption about the controller A (i. e., A is an abstraction of H2): If (i) P holds for a system consisting of the plant and the assumption P ∥ A and (ii) the controller H2 guarantees that assumption A holds, then plant and controller together H1 ∥ H2 satisfy P . Their approach can be used to calculate such abstractions that are over-approximations of controllers and thus fulfill (i). If (ii) holds as well, the abstraction fulfills their AGR rule and the overall system safety property holds. If (ii) does not hold, either a spurious counter example was found, which the algorithm tries to eliminate, or a real counter example was found, and the system actually violates the safety property. Their abstraction is based on merging of states, which is why it is especially well suited for stratified controllers because states belonging to the same stratum can oftenbe merged. However, in the worst case their approach will end up with the original system as an abstraction. While [16] is concerned with automatic generation of abstractions for controllers for a specific class of systems, we use contracts to abstract the behavior of a wide range of components, which completely replace the original components in the analysis.

Assume-guarantee reasoning for hybrid I/O-automata by over-approximation of continuous interaction [40]. In [40], the behavior of a component modeled as hybrid I/O automata (HIOA) is approximated by an associated hybrid labeled transition system (HLTS), called its timed transition system. Formally, the timed transition system for a HIOA H is the HLTS [[H]]. A HLTS represents an over-approximation of a HIOA’s behavior and abstracts away continuous path information. Furthermore, the authors define a simulation relation, where a HIOA Q simulates another HIOA P (or formally, P ≼ Q), if all states of Q show the same or more behavior than corresponding states in P , i. e., Q is an over-approximation of P . Timed transition systems are then used in place of the more complicated HIOA to verify refinement properties, using a circular AGR rule, where Q = Q1 ∥ Q2 represents a specification (e. g., a safety property expressed in terms of a HIOA) for a system P = P1 ∥ P2: if the parallel composition of the timed transition system of P1 with the timed transition system of the specification Q2 is simulated by the timed transition system of the complete specification Q1 ∥ Q2, i. e., [[P1]] ∥ [[Q2]] ≼ [[Q1 ∥ Q2]] and accordingly for Q1 and P2, i. e., [[Q1]] ∥ [[P2]] ≼ [[Q1 ∥ Q2]], then Q simulates P and is thus an over-approximation of the system behavior, i. e., P1 ∥ P2 ≼ Q1 ∥ Q2. The implementation of their approach is limited to linear hybrid automata. In analogy, we discretize (potentially non-linear) plants to contracts; however, in our approach, contracts completely replace components and do not need to retain simplified transition systems.

40 4.4. SUMMARY

Assume-guarantee reasoning for hierarchical hybrid systems [50]. A similar AGR rule is presented in [50], where the approximation drops continuous behaviors of single components entirely. If a component A refines a component B, B is a more abstract (permissive) version of A. Thus if a property holds for the specification B it also holds for implementation A. They define rlax(A) as the component resulting from dropping all continuous behavior of A. Their theorem states that, if A1 ∥ rlax(B2) refines A2 ∥ rlax(B2), and A2 ∥ B1 refines A2 ∥ B2, then the implementation A1 ∥ B1 refines the specification A2 ∥ B2. Thus, the approach requires verification of properties without continuous behavior. Our contracts still preserve knowledge about continuous behavior.

4.4 Summary

In summary, only few component-based approaches handle generic CPS with both discrete and continuous aspects, cf. Section 4.1.

Most of these approaches are based on hybrid (I/O) automata [3, 65] or similar formalisms [117] (i. e., [7, 13, 16, 26, 28, 27, 40, 50]). The reasons for this are many-fold. On the one hand, approaches for hybrid automata often use reachability analysis as verification technique, which is prone to suffer from state- space explosion. Typical ways to counteract state-space explosion are abstraction and decomposition, which has led to the introduction of AGR approaches ([13, 16, 40, 50]). On the other hand, hybrid I/O automata are inherently compositional with respect to the attached simulation relation, which makes them a good starting point for component-based analysis. However, approaches based on hybrid (I/O) automata are often restricted to linear continuous dynamics ([7, 26, 28, 27, 40]), focused solely on composition of controllers operating on a shared plant ([16, 26, 28, 27]), rely on discretization to approximate the reachable states of a system ([50] drops continuous parts of the system, [13] requires determination of accuracy parameters for discretization), or impose severe restrictions to the systems under consideration, like [7] restricting communication between components to synchronization.

Component-based deductive verification approaches are very rare. First at- tempts towards component-based analysis in [63] use quantified hybrid programs to reason about local correctness properties of components with uniform structure, and their relationship to global correctness. A component-based deductive verification approach based on the Coq was presented in[107, 108] and composes closely coupled components with overlapping variables. Neither approach considers versatile and independent components, which can be verified in isolation.

41 CHAPTER 4. RELATED WORK

In this thesis we present a component-based deductive verification approach, specifically targeting the requirements of Section 3.3. Our approach • is aimed at independent components, which can be verified in isolation, as opposed to closely coupled approaches like [63, 107, 108], • allows communication between components through explicitly defined interfaces and ports, as opposed to [7], which does not allow communication at all, • considers components that comprise individual discrete and continuous parts, as opposed to approaches considering controller components operating on shared plants like [16, 26, 28, 27],

• considers parallel composition, transferring proofs for components to the composite, as opposed to approaches focusing on sequential composition like [26], • is based on hybrid programs and dL and thus allows for non-linear ODEs, as opposed to purely linear approaches like [7, 26, 28, 27, 40],

• uses a deductive technique to formally verify safety of components rather than reachability analysis, thus avoiding the necessity of iteratively calculating or approximating the set of reachable states, as opposed to [7, 13, 16, 40, 50].

42 Chapter 5

Motivational Examples

In this chapter, we introduce three examples of CPS, which can be modeled using component-based hybrid system modeling and verification. The examples are of increasing complexity—regarding the internal behavior of components and the capabilities of interfaces—and illustrate different areas of application covered by our approach. The description does not comprise details about the actual implementation, since the purpose of these examples is to further motivate our approach and emphasize its practicality. Implementation details will however be introduced later on in the respective parts of the thesis.

5.1 Flow Components

Flow-based systems are a class of systems that can be analyzed using hybrid system modeling and verification. Examples for flow-based systems include smart grid applications, transportation systems, water distribution systems, oil and gas pipelines and traffic control systems. Our first example is such aflow- based system from the field of road traffic control, aimed at ensuring the safety of control decisions in a road network.

5.1.1 Traffic Control A traffic control system is a system, where traffic operators monitor large road networks with the goal of influencing their behavior with control actions in order to ensure smooth flow of traffic. On the one hand, traffic modelsfound in literature mostly consider the continuous aspects of a traffic system, i. e., the flow of traffic through the road network. On the other hand, however, control actions as selected by traffic operators represent discrete actions, like the closing of a road because of roadworks. Naturally, purely continuous models do not consider these control actions. Accordingly, since the discrete and continuous parts of road traffic are inseparably intertwined and mutually influence each other (e. g., a speed limit influences traffic flow, which in turn determines the

43 CHAPTER 5. MOTIVATIONAL EXAMPLES chosen speed limit), we consider a traffic control system as aCPS. Traffic operators rely on software when selecting appropriate control measures to resolve potentially critical traffic situations. The safety of the suggested actions is crucial (e. g., expected traffic volume should not overload a detour); even more so, when traffic control software decides autonomously. Since traffic networks tend to be huge and consist of rather few but repeatedly occurring parts, such models practically mandate for a component-based modeling and verification approach. Hybrid system models of traffic networks can be used for various purposes, such as calculating approximate travel times, network planning or prediction of traffic breakdowns1. Here, we focus on macroscopic traffic models for large networks, as used by traffic operators in control centers to monitor and influence road traffic. These macroscopic models abstract from unnecessary details of single cars and focus on the behavior of the flow of traffic. Poor decisions in traffic centers can imply serious consequences for the flow of road traffic: e.g., congestion caused by a misplaced road-block can propagate to a highway, where the resulting large speed differences increase the risk of accidents.

5.1.2 Traffic Modeling Traffic management systems intend to support operators by suggesting actions, which entail desirable results (e. g., congestion dissolves) and avoid undesirable side effects (e. g., traffic breakdowns). The goal in this example istoavoid a potential traffic breakdown. We consider a traffic breakdown as any kind of congestion that is not restricted to a single part of the road network, but propagates through multiple parts of the network, which happens as soon as the load of cars in front of any intersection (i. e., the queue in a link) exceeds the road’s capacity (i. e., maximum queue size). Consequently, the safety property that we want to verify is that no road will exceed its capacity. Unfortunately, due to the complex structure of larger traffic networks, the respective hybrid system models become large: they consist of innumerable roads and intersections, which all have to be checked for potential breakdowns. However, typical traffic networks are formed from only a small number of traffic control patterns, such as traffic lights or intersections, which can be used to build entire road networks. Fig. 5.1 shows which sample patterns can be extracted from an exemplary traffic network (we focus on traffic lights, split and merge, similar to [25] and [127]). Their structural similarity makes them amenable to component-based modeling. Thus, we want to represent each pattern as a traffic component with a separate hybrid system model (cf. Fig. 5.2) consisting of:

• one or more incoming roads (i. e., inputs/inflows) where vehicles can enter the component (i. e., In),

1A traffic breakdown occurs when traffic load (i. e., queue in a link) exceeds capacity (i.e., maximum queue size) [125]. Variations of exact definitions of traffic breakdown exist in the literature (e. g., [35, 87]).

44 5.1. FLOW COMPONENTS

• one or more outgoing roads (i. e., outputs/outflows) where vehicles can exit the component (i. e., Out), • the maximum number of vehicles that can pass through the incoming road in a given time (i. e., imax, number of vehicles per time unit), which is usually restricted by physical characteristics (e. g., number of lanes or speed limits), • the maximum number of vehicles that pass through the outgoing road in a given time (i. e., omax, number of vehicles per time unit), • the actual number of vehicles present on the corresponding incoming road at some point in time (i. e., current queue in link l) and • the number of vehicles allowed on an incoming road without exceeding the infrastructural limits (i. e., maximum queue size c, number of vehicles), which usually depends on environmental characteristics (e. g., number of lanes or length of road).

Road ------

Network - - - - - extract ------pattern Pattern Traffic Light Traffic Merge Traffic Split apply pattern Model

Figure 5.1: Extraction: Re-occuring traffic patterns can be extracted froma road network and modeled using a component-based approach.

The actual and maximum number of cars present on a road at some point in time can only be accessed by the component itself. In the sense of our component-based modeling terminology as introduced in Chapter3, incoming roads represent input ports (or inflows) and outgoing roads represent output ports (or outflows). Their values are the actual number of vehicles passing through this road at a certain interval (i. e., throughput, e. g., vehicles per minute). The respective input requirements and output guarantees are the maximum number of cars that are allowed on any road due to infrastructural limitations. If the maximum number of cars allowed on an output does not exceed the maximum number of cars on a connected input, the two roads are compatible and can thus be connected.

45 CHAPTER 5. MOTIVATIONAL EXAMPLES

Traffic Lights Traffic Flow Merges Traffic Flow Splits

extract common pattern Out…Outputs/

c1 푖푚푎푥1 표푚푎푥1 l1

Inflows Flow … Component … cn Outflows 푖푚푎푥푛 표푚푎푥푚

ln In…Inputs/ Flow Interface

Figure 5.2: Components and Interfaces: The common structure of the extracted components can be used to extract a common interface pattern. Each interface has a number of roads with certain properties (e. g., maximum traffic throughput) leading into the component and away from the component. The interface encapsulates the flow component and its actual functionality (e. g., split traffic, merge traffic). Additionally, the component stores the current number andthe maximum number of cars for each input road.

The flow component describes how cars are routed from input ports tooutput ports (can for instance be derived from compiled real-world driving patterns).

In order to build the entire network from these components, we need a composition operation, cf. Fig. 5.3. The composition of two traffic components represents consecutive parts of the traffic network: cars leaving the first traffic component through its interface move on to the second traffic component. However, the composition is rather a parallel one, since vehicles move simultaneously at all intersections (i. e., in parallel). In other words, for single vehicles the composition is a sequential one (i. e., they move through the components one by one), but for a macroscopic view of traffic flow, the composition isa parallel one (i. e., traffic flow moves in components simultaneously).

As we want to avoid traffic breakdowns, we have to show that load never exceeds the capacity throughout the traffic network. Although this is impractical for large networks, it can be done for single components.

46 5.1. FLOW COMPONENTS

풊풏ퟑ

풊풏ퟑ 풐풖풕ퟑ 풐풖풕ퟑ

퐶1 퐶2 풊풏ퟏ 풊풏ퟏ 표푢푡1 푖푛4 풐풖풕ퟒ 풐풖풕ퟒ

풊풏ퟐ 풊풏ퟐ 풐풖풕ퟐ 퐼1 퐼2

풐풖풕 푪ퟑ ퟐ

푰ퟑ

Figure 5.3: Composition: The composition of two components C1 and C2 through their interfaces I1 and I2 leads to a composite construct C3, which is again a component with an interface I3. Connected roads become part of the composite component, while unconnected roads remain incoming/outgoing roads in the composite interface.

5.1.3 Summary

The traffic network was divided into components by extracting recurring patterns, i. e., split, merge and traffic light. This way the verification effortcan be reduced for large traffic networks, since a small number of repeatedly used components (i. e., in this case three) suffices to build large systems. Thus, the example models consist of designated traffic components, each representing a specific part of a road network. Each component has an arbitrary number of inputs and outputs and directs traffic flow between these ports. These ports come with uniform input- and output properties, i. e., the maximum flow must not be exceeded. The local component safety properties as well as the overall system safety property are fixed to the avoidance of a traffic breakdown. Ac- cordingly, if each individual component obeys its safety property, system safety can be inferred. The advantages of component-based analysis become even more apparent, when such a traffic model is used for planning of road works or entire road networks. In the former case, the parameters of a single component must be adapted (e. g., road works might reduce the available number of lanes). For a monolithic model, this would require full re-verification of the potentially huge road network. For the component-based approach, only the single component must be re-verified and re-composed. In the latter case, the component-based approach would allow the use of a library of pre-verified components, which can be composed in various ways using the safe composition operation. That way, a large number of verified network variations can be built, while in the monolithic case each single variant has to be verified separately.

47 CHAPTER 5. MOTIVATIONAL EXAMPLES

5.2 Vehicle Cruise Control

For the second example, we zoom in from macroscopic traffic flow networks to microscopic models of specific cars. We consider a cruise control system, which has to limit the car’s maximum speed to avoid damaging its engine. Accordingly, the goal of the system is to keep the speed within a fixed interval at all times, i. e., it will never happen that the actual speed is outside the validity interval. Further goals, such as when to start braking to reach a permitted speed on time, are not considered here. Although, this example is also from the field of road traffic, it requires more generic components and a different kind ofports. We consider multiple versions of cruise control: one where the target speed is chosen autonomously by the cruise control system and one where a user provides a speed suggestion for the new target speed, cf. Fig. 5.4. In both cases the new target speed must be within the validity interval and additionally, should not be too far from the previously requested target speed, to avoid sudden acceleration, which could damage the engine and are inconvenient for the passengers.

Autonomous Guided Engine Current Cruise Controller Component speed Cruise Controller Current Component Target Target Current Component Target speed speed speed speed speed

Library Autonomously choose Accelerate until target User Choose target speed

target speed speed is reached speed respecting driver input Component Component

Current speed Current speed

Target speed Target speed

Model Composed Composed

I want to

world world reduce speed!

System Real

Figure 5.4: Vehicle Cruise Control: The system can be divided into two parts: a cruise controller component chooses a valid speed (i. e., below a certain thresh- old) and the engine component adapts the acceleration to match the received speed. The engine component should work with both, the autonomous cruise control (autonomously selects a target speed) and the guided cruise control (considers a speed suggestion from a user).

5.2.1 Components and Composition In this case a separation into components does not follow as natural as in the previous example. While the compartmentalization in the traffic control system followed from the reoccurring patterns of a traffic network, the vehicle cruise control has no obvious reoccurring parts. As we deal with a single physical entity (i. e., a car), it could even be argued to model and verify the system in a monolithic manner. However, another way of splitting a system into components is to separate unchanging parts from evolving ones. Thus, for component-based

48 5.2. VEHICLE CRUISE CONTROL analysis we divide the system into two parts (cf. Fig. 5.4), where one component (i. e., the engine) receives target speeds on an input port and adapts the acceleration of the vehicle accordingly. The vehicle moves, changing its speed following the chosen acceleration and providing its current speed on an output port. The input port requires the target speed to be within a certain constant interval (i. e., only accept speeds allowed to prevent engine damage) and the output port ensures speeds that are always within a certain constant target interval (i. e., chosen speed will not damage the engine). This part of the system is independent of a specific cruise controller implementation, as the engine does not care about the way the new target speed was selected. The second part is the cruise controller component. Its responsibility is to provide a new target speed on its single output port, based on the current vehicle speed it receives on its single input port. Again, the received actual speed, as well as the provided target speed have to be within the validity interval. This part of the system is mutable: how the cruise controller component actually calculates the new target speed depends on the chosen implementation. For the example we consider two versions: the autonomous controller and the guided controller, cf. Fig. 5.4. The autonomous controller calculates a new target speed solely based on the current vehicle speed. The only restriction is that the new speed should not be too far from the current one, to avoid severe acceleration. The guided controller has an additional input port where it receives a suggestion for the new speed from a user. It then adapts this speed to be within the validity interval and further restricts it to the small interval around the current speed, again to keep acceleration low. Both controller implementations guarantee the same output property on the port providing the target speed. As the cruise controller needs to communicate its speed requests to the engine, a composition operation is needed to compose the vehicle cruise control system from the chosen components. As the values are passed via digital circuits within the vehicle, connected ports pass their values instantaneous and lossless from output port to input port in variable intervals. Accordingly, values are passed sequentially from one component’s controller to the other. The components remain parallel, so time and continuous behavior still pass simultaneously in all components.

5.2.2 Summary The example comprises three components, two of which form a vehicle cruise control system. The ports pass speeds between the components and are restricted to global constant intervals. The overall safety property of the system is to keep the current speed within a desired interval. While the engine component’s responsibility is to obey the speed advice of the controller, the controller is responsible for providing target speeds within the validity interval. In this case, the system safety property follows immediately from the components, as it concurs with the local safety property of the engine component: keep the current speed withing a desired interval. Here the system has no real natural splitting point. However, the component-

49 CHAPTER 5. MOTIVATIONAL EXAMPLES based approach is still useful as it can be used to separate the presumably immutable parts, i. e., the engine component, from the versatile cruise controller. Thus, even if the cruise controller is changed (as shown above), not the whole vehicle cruise control system needs re-verification, but only the cruise controller component.

5.3 Tele-operated Robot

Our final example is a tele-operated robot with collision avoidance inspired by [63, 71]: a robot periodically reads speed advice from a remote control, but automatically overrides the advice to avoid potential collisions with an obstacle that moves with an arbitrary but known maximum speed (models, e. g., stationary walls, but also persons moving in corridors). Additionally, two consecutive speed advisories from the remote control should not be too far apart in speed, to avoid inconveniently strong acceleration. While the flow components example (cf. Section 5.1) and the vehicle cruise control example (cf. Section 5.2) are expressible with global contracts, the tele-operated robot example requires change- and delay contracts to reason about the magnitude and rate of change of communicated values.

5.3.1 Components and Composition

In this example, the components can neither be inferred from reoccurring patterns (the system consists of rather versatile parts), nor from mutable and immutable parts of the system (yet, no adaptation of any part of the model is planned). However, the example features three physically separated entities (i. e., a robot, an obstacle and a remote control) that provide a rather natural splitting point. Accordingly, for the case study, we introduce three components: a remote control, an obstacle and a robot, cf. Fig. 5.5. The remote control component picks a new demanded speed, which must not be too far from the previously chosen speed, and provides it on an output port. Note that the output port’s values are not restricted to a fixed interval, but depend on the previously sent value. The component has no input ports. How the new demanded speed is chosen, again depends on the component’s implementation (cf. Section 5.2). The second component is the obstacle, which must be avoided by the robot. The obstacle chooses an arbitrary speed and continuously changes its position accordingly. Note that the obstacle moves without any further considerations of its environment and has no intention to avoid collision with any other entities. The obstacle provides its current position on an output port and guarantees that this position will be within a certain radius around its previous position (i. e., the obstacles does not “teleport” to random positions). Note that the output port’s value does not only depend on the previously sent value, but also on the time that has passed since the last value transfer.

50 5.3. TELE-OPERATED ROBOT

Remote Control Obstacle Target Robot Component speed Component Component Target Obstacle speed position

Library Calculate next Move Obstacle Move with advised speed, but

speed advice freely position avoid collisions with the obstacle Component Component

Target speed

Model Obstacle position

Composed Composed

world world

System Real

Figure 5.5: Tele-operated Robot: The system consists of three physically separated entities, which can be directly mapped to components. The robot receives the freely moving obstacle’s position and a new target speed from the RC, and tries to avoid collisions.

Finally, the robot component has two input ports and no output ports. On one port the robot reads demanded speeds, and on the other one it reads the current position of the obstacle. The robot itself moves continuously trying to match the demanded speed, but overrides it to avoid colliding with the obstacle. In the composed system, the robot is connected to both, the obstacle (i. e., reading its position) and the remote control (i. e., receiving demanded speeds). Regarding composition, we could again use an instantaneous and lossless parallel composition as described in the previous example (cf. Section 5.2). How- ever, as in this example we are no longer dealing with a single system split into components, but rather with a system which might be physically distributed, the transmission of values through ports might no longer be lossless. Thus, we could also use an inexact (but still instantaneous) parallel composition, which takes measurement errors (e. g., for the obstacle position) and transmission errors (i. e., for the demanded speed sent from the remote) into account.

5.3.2 Summary Here the system is divided into components according to its real-world parts (i. e., the remote control, the obstacle and the robot), which allows for high reusability, since similar parts could be found in other systems (e. g., a moving obstacle could also be needed in other systems). The overall safety property of the system is to keep the robot from colliding with the obstacle. Here, the system safety property does not follow directly from one (or all) of the local component safety properties. However, the property can be implied from the robot’s and the obstacle’s safety properties, which both guarantee to stay inside an area around their respective last positions, cf. Fig. 5.6. Neither area is fixed, but if the areas are always disjoint, the system safety property can be inferred.

51 CHAPTER 5. MOTIVATIONAL EXAMPLES

Global Safety

Robot Obstacle

Local Safety Local Safety

Figure 5.6: System Safety vs. Local Safety: As long as the robot and the obstacle each obey their local safety property (i. e., stay within their predicted areas of movement), the system safety property can be inferred (i. e., robot and obstacle never meet as long as their areas of movement do not overlap).

5.4 Example Summary

In this section, we presented three application scenarios for a component-based modeling and verification approach for CPS, ranging from (possibly huge) traffic models, to a vehicle cruise control and to robot collision avoidance. The examples suggest different ways in which a system can be decomposed into components: • Decomposition by extraction of reoccurring patterns, cf. Section 5.1. • Decomposition by functionality and extraction of immutable parts, cf. Section 5.2. • Decomposition according to the real-world component structure of the system, cf. Section 5.3. Even though each example is addressed using a component-based approach, they impose different requirements on the underlying approach (cf. Section 3.3). The first example assumes that values are passed lossless, instantaneous and picked from a fixed range, has unified safety properties for all components, and uses components with a fixed purpose (i. e., each component represents a traffic pattern). Even though the second example still works on fixed global ranges for the lossless and instantaneous transmission of values along ports, the components have diverse safety properties and are aimed at different functionality (e. g., cruise control versus engine). Finally, the third example requires port properties beyond global value ranges and—since the system is a distributed one—lossy transmission of values along ports. In the following parts, we will show how our component-based verification approach can be used to model all of the above examples and ensure their safety.

52 Chapter 6

Preliminaries

Before moving on to subsequent parts, where we introduce our approaches, in this chapter, we outline the preliminaries used in this thesis. We will list several associated techniques and terminologies in a central place for easy reference.

6.1 Differential Dynamic Logic

For specifying and verifying correctness statements about hybrid systems, we use differential dynamic logic (dL)[91, 95], which is a real-valued first-order dynamic logic for hybrid systems and supports hybrid programs as a program notation for hybrid systems. The syntax of hybrid programs is generated by the following EBNF grammar:

∗ ′ ′ α ::= α; β | α ∪ β | α | x := θ | x := ∗ | [{x1 = θ1, . . . , xn = θn & H} |?F The sequential composition α; β expresses that β starts after α finishes. The non-deterministic choice α ∪ β follows either α or β. The non-deterministic repetition operator α∗ repeats α zero or more times. Discrete assignment x := θ instantaneously assigns the value of the term θ to the variable x, while x := ∗ assigns an arbitrary value to x. {x′ = θ & H} describes a continuous evolution of x (x′ denotes derivation with respect to time) within the evolution domain H. The test ?F checks that a condition expressed by property F holds, and aborts if it does not. In this thesis, we represent a no-operation statement skip ≡?true as a test that always holds. A typical pattern x := ∗;?a ≤ x ≤ b, which involves a non-deterministic assignment and a test, is to limit the assignment of arbitrary values to known bounds. Such a bounded assignment can for instance be used when a distance sensor reads a new distance: The received value can be arbitrary, however, it is bound by the sensor’s minimum and maximum range. Thus, for a distance sensor with a range between 1 and 5 meters, the bounded assignment

dist := ∗; ? (1 ≤ dist ≤ 5)

53 CHAPTER 6. PRELIMINARIES would result in a new distance measurement within the validity range of the sensor. An if-then-else construct can also easily be derived using the above primi- tives. The construct if(F) a; else b; endif can be expressed as ?F ; a ∪ ?(!F ); b . Note that sequential composition ; binds stronger than non-deterministic choice ∪. Other control flow statements can be expressed similarly with these primi- tives [91]. To specify correctness properties about hybrid programs, dL provides modal operators [α] and ⟨α⟩. When φ is a dL formula describing a state and α is a hybrid program, then the dL formula [α]φ expresses that all states reachable by α satisfy φ. Dually, dL formula ⟨α⟩φ expresses that there is a state reachable by the hybrid program α that satisfies φ. The set of dL formulas is generated by the following EBNF grammar (where ∼ ∈ {<, ≤, =, ≥, >} and θ1, θ2 are arithmetic expressions in +, −, ·,/ over the reals).

φ ::= θ1 ∼ θ2 | ¬φ | φ ∧ ψ | φ ∨ ψ | φ → ψ | φ ↔ ψ | ∀xφ | ∃xφ | [α]φ | ⟨α⟩φ

6.1.1 Hybrid Time When using dL and the associated programs, time only passes during continuous evolution [3]. Discrete statements are executed in the order specified by the hybrid program. However, since no time passes when executing discrete statements, all of them are executed at the same point in time. This leads to the notion of hybrid time, where time can be thought of as a tuple comprising the current continuously changing system time and a discrete counter, determining the order of discrete actions at a point in time. This is especially important for considerations regarding parallel composition: Since discrete statements happen at the same time, it seems to be of uttermost importance to consider them in the right order. At the same time, continuous parts of a hybrid system model must actually run in parallel, as in reality time passes everywhere simultaneously. For example, consider a self driving car, which measures the distance dist to an obstacle, calculates and sets a new speed s, drives for some time, where the position x changes according to the chosen speed s and then repeats these steps. The respective hybrid program might look as follows.

(dist := ∗; s := f(dist); {x′ = s})∗

54 6.1. DIFFERENTIAL DYNAMIC LOGIC

The hybrid time tuple consists of the time t and a natural number j ∈ N used to count discrete operations. Fig. 6.1 shows a sample trajectory of the speed s for the above example. At time (t0, 0), dist is assigned a new value (i. e., new distance is measured). At time (t0, 1), the new speed s is calculated and then continuous evolution begins and the continuous time t starts to evolve. The position x changes with rate s, until time (t1, 1). Then again, at (t1, 2) a new distance is measured, continuous evolution begins, and so on.

j 4 4 3 3 2 2 1 1

푡0 푡1 푡2 푡3 t

Figure 6.1: Sample trajectory of position x plotted over the hybrid time domain, where t is continuous time and j are discrete time steps (cf. [89])

However, the car only moves whenever the actual time t changes. Fig. 6.2 plots the evolution of the car’s position x over time. Thus, even though at t0, t1,... multiple operations are executed in a specific order, they consume no time and thus seem to happen simultaneously. x

푡0 푡1 푡2 푡3 t

Figure 6.2: Position over time (cf. [89])

6.1.2 KeYmaera X KeYmaera X [42] is an automated and interactive deductive verification tool (i. e., theorem prover) for dL and hybrid programs. KeYmaera X supports a set of proof rules that can either be applied by the user or by an automatic strategy that selects suitable rules, to transform dL formulas before it uses quantifier elimination to close the proof. Additionally, if no proof can be found, KeYmaera X supports the generation of counter examples.

55 CHAPTER 6. PRELIMINARIES

Γ, φ ⊢ ψ, ∆ ([; ]) [α][β]φ ↔ [α; β]φ (→r) Γ ⊢ φ → ψ, ∆ ([∪]) [α]φ ∧ [β]φ ↔ [α ∪ β]φ Γ ⊢ φ, ∆ Γ, ψ ⊢ ∆ (→l) Γ, φ → ψ ⊢ ∆ ([:=]) [x := e]φ(x) ↔ φ(e) Γ ⊢ φ, ∆ Γ ⊢ ψ, ∆ (∧r) ([?]) (H → ψ) ↔ [?H]ψ Γ ⊢ φ ∧ ψ, ∆ Γ, φ, ψ ⊢ ∆ (DW) [x′ = f(x)&q(x)]q(x) (∧l) Γ, φ ∧ ψ ⊢ ∆ Γ ⊢ ∆ Γ, φ(X) ⊢ ∆ (Wr) (∀l) Γ ⊢ φ, ∆ Γ, ∀x φ(x) ⊢ ∆

Γ ⊢ ∆ Γ ⊢ φ(s(X1,..,Xn)), ∆ (Wl) (∀r) 1 Γ, φ ⊢ ∆ Γ ⊢ ∀x φ(x), ∆ Γ ⊢ φ, ∆ Γ, φ ⊢ ∆ Γ ⊢ [α]φ, ∆ φ ⊢ ψ (cut) ([]gen) Γ ⊢ ∆ Γ ⊢ [α]ψ, ∆ ∀X [x := X]φ Γ ⊢ φ, ∆ φ ⊢ [α]φ φ ⊢ ψ ([:∗]) (ind) [x := ∗]φ Γ ⊢ [α∗]ψ, ∆ φ ⊢ ψ Γ ⊢ C (Q) , ∆ P ↔ Q ([] M) (CER) [α]φ ⊢ [α]ψ Γ ⊢ C (P ) , ∆ p (¯x) ↔ q (¯x) Γ,C (Q) ⊢ ∆ P ↔ Q (CE) (CEL) C (p (¯x)) ↔ C (q (¯x)) Γ,C (P ) ⊢ ∆

1 s is a new (Skolem) function symbol and X1,..,Xn are all free logical variables of ∀x φ(x).

Figure 6.3: Proof Rules

KeYmaera X is implemented in Scala, expands upon functionality by introduction of tactics and is based on a significantly smaller soundness-critical core than other hybrid systems verification tools, which makes it easier to ensure correct verification results. We will use the tactic language and Scala implementation later on to implement our theorems, which will allow programmatic application of our results to component-based hybrid programs.

6.1.3 Proof Rules

Throughout this thesis we will use the proof rules and axioms listed in Fig. 6.3, cf. [100]. The axioms for the transformation of hybrid programs can be applied using the CER and CEL proof rules, which allow the application of logical equivalences in any context. The usage of CER and CEL will not be explicitly mentioned throughout the paper.

56 6.2. NOTATION

6.2 Notation

In dL (and thus throughout the thesis) all variables are real-valued. We use V to denote a set of variables. FV (.) is used as an operator on terms, formulas and hybrid programs returning the free variables, whereas BV (.) is an operator returning the bound variables.1 Similarly, V (.) = FV (.) ∪ BV (.) returns all variables occurring in terms, formulas and hybrid programs. We use dL in definitions and formulas to denote the the set ofall dL formulas. Throughout this thesis, subscript indices represent enumerations (e. g., xi position of item i) and denominations (e. g., xr position of the robot). Super- script indices are used to further specify the kinds of items described by the max respective variables (e. g., xr maximum position of the robot). If needed, a double (super- and subscript) one-letter index is used for double numeration j (e. g., zi represents element j of the vector zi). We use “↦→” to define functions. f = (a ↦→ b) means that the (partial) function f maps argument a to result b and is solely defined for a.

1Bound variables of a hybrid program are all those that may potentially be written to, while free variables are all those that may potentially be read [99].

Part II

Domain-Specific Approach with Traffic Contracts

Chapter 7

Introduction

As described in Chapter5, a traffic network is a typical example of a CPS: traffic operators monitor large road networks, in which continuous physical characteristics (e. g., traffic flow, travel times) are influenced by discrete control measures (e. g., speed limits). They need to be modeled and formally verified in conjunction. However, hybrid system models of entire traffic networks are huge and thus, potentially hard to verify. Handling a CPS model of a full traffic network is currently hopeless without exploiting its structure during a proof. The basic observation making mathematical proof possible is that traffic networks, while large, are composed ofmany instances of only a small number of similar patterns (cf. Section 5.1)—a char- acteristic, which can be exploited by component-based modeling approaches. In this part, we present a way to ensure that proofs about traffic components transfer to the network level. Our key conceptual insight is that the external behavior of flow-based CPS can be modeled with interfaces having contracts on flow inputs and flow outputs. We define composition operations related to load and capacity, which are important characteristics of traffic systems. When we check contracts statically during modeling, we can conclude safety of the load and capacity of networks from the verification results of their individual parts. Our technical contribution is to show that safety properties of the individual parts (e. g., their capacity is such that a certain amount of traffic can be handled) transfer to safety ofthe whole network. The hybrid systems verification results that we present fora library of important traffic patterns require human guidance, but the proofs only need to be done once. The checks for correct composition of the contracts that are required at the network level reduce to simple arithmetic checks, which can be performed at scale with marginal computational cost. That way contracts modeled and verified by hybrid system experts at design-time, canbe composed and parametrized by traffic operators at run-time. According to our definition of components and interfaces (cf. Section 3.1), in this part we rather introduce interfaces for flow components instead of actual flow components, as these interfaces suffice to ensure transfer of safety properties to system level.

61 CHAPTER 7. INTRODUCTION

Consequently, components do not have a fixed structure, but must be introduced individually in conformance with the respective interfaces. Exemplary component implementations complying with these interfaces are introduced as part of our traffic component library later in this part. We evaluate our approach by introducing a library of traffic components to build modular traffic network models and by implementing it in a component- based model analysis and design tool for traffic networks. The tool checks for correct composition of the higher-level composite model to ensure that the presented proofs about its components reunite to a large safety proof about the entire network. The rest of this part is structured as follows:

• Chapter8 introduces the theoretical concepts required to model traffic networks using a flow-based component approach. First, we define the structure of flow interfaces in Section 8.1, before we define safety of such flow interfaces in Section 8.2. In Section 8.3 we then introduce a way of composing flow interfaces such that safety of single interface transfers to composites.

• Chapter9 evaluates our approach. First, in Section 9.1 we apply our approach to create a library of flow interfaces for reoccurring patterns ofa traffic network, and verify the safety of these patterns (i. e., nooverflow occurs). We then introduce exemplary flow components and verify that these components comply with the respective interfaces. In Section 9.2 we present a modeling tool for provably safe traffic networks using the verified components from our library. We use the tool to model thetraffic network around a highway exit near Johannes Kepler University, Linz, Austria. Finally, in Section 9.3, we conclude and review the capabilities and shortcomings of the domain-specific approach.

All contents in this part of the thesis are based on our previous work “Ver- ified Traffic Networks: Component-based Verification of Cyber-Physical Flow Systems” as published in “18th International Conference on Intelligent Trans- portation System”, cf. [78].

62 Chapter 8

Concept

In this chapter, we formally define the foundations of a component-based modeling and verification approach for traffic network properties abstractly modeled as capacity, load and flow. As a global safety property we are interested in proving that the network does not exceed its capacity for a designated time, cf. step (1) of our strategy as introduced in Section 3.2. We introduce notions of interfaces, compatibility and composition, cf. step (2) and (5). These lay the foundation for the next chapter, where we model traffic components, cf. step (2), and identify and verify the associated local contracts, cf. step (3) and (4).

Finite vs. Infinite Time. During normal operation, a traffic network should never exceed its capacities and thus, an overflow should never occur. However, when analyzing traffic networks it is often of certain interest how the network behaves when unusual events (like the installation of roadworks or an accident) happen. In such cases, it is likely that the network’s capacity will be exceeded at a certain point in time and thus, if a model is aimed at safety for an infinite duration, it will always detect a traffic breakdown. Thus, we will consider models, which guarantee safety (i. e., no traffic breakdown) for a finite amount of time only. Such models can be used to analyze for how long a traffic network can function before its capacities are exceeded.

8.1 Flow Interfaces

We model (traffic) networks as directed graphs G of vertices V and edges E. The concrete behavior of a flow component is described by its hybrid systems model (cf. Section 9.1). Its abstract role in the traffic network is merely a vertex, representing an interface, which takes flow from a set of input edges and directs it to a set of output edges, each having a maximum flow. The inputs furthermore have a capacity and a load which is influenced by the in- and outflows. Def.1 gives a definition of flow interfaces, representing the external behavior ofaflow component, according to the pattern described in Section 5.1.2. The internal

63 CHAPTER 8. CONCEPT behavior of a component is represented by a controller, which decides how flow from the inputs is directed to outputs and thus, how the actual load evolves on each input. Exemplary controller implementations are presented in Section 9.1. Definition 1 (Flow Interfaces). Let E be the set of all edges. A flow interface F is defined as a tuple F = (In, Out, imax, omax, l, c) where

• In ⊆ E is a finite ordered set {In1,..., Inn} of n input names.

• Out ⊆ E is a finite ordered set {Out1,..., Outm} of m output names.

• imax : In → R+ is a function assigning a non-negative maximum inflow to each input in In. We lift to ordered sets as follows imax(In) = max max {i (In1) , . . . , i (Inn)}.

• omax : Out → R+ is a function assigning a non-negative maximum outflow to each output in Out. We lift to ordered sets as follows omax(Out) = max max {o (Out1) , . . . , o (Outm)}.

• c : In → R+ is a function assigning a maximum capacity (i. e., maximum manageable load) to each input in In. We lift to ordered sets c(In) = {c (In1) , . . . , c (Inn)}. ( + + + m) + • l : In, R , R , (R ) → R is a function calculating the load (i. e., capacity used) of an input depending on the time passed since system start, the inflow imax and all outflows omax.

8.2 Contracts for Safe Flow Interfaces

Here, we define contracts that must hold to ensure that a flow component complying with its flow interface does not exceed the capacity of its inputs. These contracts are conditions on the maximum inflows, outflows, capacities and loads of an interface, as well as on the time that has passed. Outputs of a interface do not need a capacity, because they are included in the input capacities of subsequent interfaces. The actual flow to and from an interface can vary between 0 and the provided maximum flow values. Safe uses of a traffic flow interface need to ensure that, within a given time horizon, the load on any input never exceeds the capacity of the input (cf. Def.2). Definition 2 (Load Safety). A flow interface is load-safe for time t ≥ 0, if and only if its load l does not exceed the capacity c of any of its inputs until time t:

( max max ) loadsafe (t) ≡ ∀Ini ∈ In . l Ini, t, i (Ini) , o (Out) ≤ c (Ini) .

Note that in Def.2 omax(Out) is applied to the set of all output names max {Out1,..., Outm}, as o can be lifted to sets following Def.1.

64 8.3. SAFE SEQUENTIAL COMPOSITION OF SAFE FLOW INTERFACES

8.3 Safe Sequential Composition of Safe Flow Interfaces

After defining safe interfaces, we want to compose them in a way that remains safe. A sequential composition of two flow interfaces links one or more outputs of the predecessor interface to the same number of inputs of the successor interface (cf. Def.3). We focus on loop-free composition, since cyclic flows are undesirable in road traffic. When there are loops present in a traffic network, wefocuson paths between a source and a destination point (e. g., the beginning and end of an area of road work) and analyze the resulting sequential paths.

Definition 3 (Sequential Composition). Let

max max Fs = (Ins, Outs, is , os , ls, cs) , for s ∈ {1, 2} be two flow interfaces, with disjoint inputs and outputs (i. e.,In1 ∩ In2 = Out1 ∩ Out2 = ∅) and C : Out1 ⇀ In2 be a partial (i. e., not every output must be mapped when connecting two interfaces), injective (i. e., every input is only mapped to one output upon connection of interfaces) function, mapping connected outputs and inputs between the two interfaces. We define O as the domain of C (i. e., all values x ∈ Out1 such that C(x) is defined) and I as the the image of C (i. e., all values y ∈ In2 such that y = C(x) holds for some x ∈ Out1). C We define the sequential composition F3 = F1 ¡ F2 of the flow interfaces F1 and F2 by connecting outputs of F1 to inputs of F2 according to the function C, where max max F3 = (In3, Out3, i3 , o3 , l3, c3) with

• In3 = (In2 \I) ∪ In1 is the set of inputs remaining open after composition,

• Out3 = Out2 ∪ (Out1 \O) is the set of outputs remaining open after composition,

• n3 = |In3| = |In1| + |In2| − |I| and m3 = |Out3| = |Out1| + |Out2| − |O| is the number of inputs and outputs of the composite,

max + • i3 : In → R , with max max ∀Ink ∈ In1 . i3 (Ink) = i1 (Ink) and max max ∀Inl ∈ In2 \I . i3 (Inl) = i2 (Inl)

max + • o3 : Out → R , with max max ∀Outk ∈ Out1 \O . o3 (Outk) = o1 (Outk) and max max ∀Outl ∈ Out2 . o3 (Outl) = o2 (Outl),

( + + + m3 ) + • l3 : In, R , R , (R ) → R , with max max ∀Ink ∈ In1 . l3 (Ink, t, i3 (Ink) , o3 (Out1)) max max = l1 (Ink, t, i3 (Ink) , o3 (Out1)) and

65 CHAPTER 8. CONCEPT

max max ∀Inl ∈ In2 ∩ In3 . l3 (Inl, t, i2 (Inl) , o3 (Out2)) max max = l2 (Inl, t, i2 (Inl) , o3 (Out2))

+ • c3 : In → R , with ∀Ink ∈ In1 . c3(Ink) = c1(Ink) and ∀Inl ∈ In2 ∩ In3 . c3(Inl) = c2(Inl) .

The composition of two flow interfaces is only safe if the composite flow interface further guarantees that the connected—and thus hidden—inputs of the flow interface receiving the flow (i. e., F2 as in Def.3) do not overflow. C Definition 4 (Composite Flow Interfaces). The composition F1 ¡ F2 of two flow interfaces F1 and F2 is internally safe, if and only if

( max max ) ∀Outj ∈ O . Ink = C(Outj) → l2 Ink, t, o1 (Outj) , o2 (Out2) ≤ c2 (Ink) .

Load-safety for composite flow interfaces is defined as in Def.2. Our goal is, however, to transfer load-safety from component level to system level without the necessity of reevaluating the condition of Def.2 for the composed system. In order to achieve this goal, we first introduce the notion of compatibility for flow interfaces. Compatibility ensures that the maximum outflow of any output does not exceed the maximum inflow of a connected input port.

Definition 5 (Compatibility). Two flow interfaces F1 and F2 are compatible, if and only if max max ∀Outj ∈ O . Ink = C(Outj) → o1 (Outj) ≤ i2 (Ink) .

Compatibility is a sufficient (even if not necessary) criterion to ensure that the sequential composition of two load-safe flow interfaces is again a load-safe flow interface, cf. Theorem1.

Theorem 1 (Load-safe composition). Let F1 and F2 be compatible flow inter- C faces, which are both load-safe at time t and F3 = F1 ¡ F2 their sequential composition. Then F3 is a load-safe composite flow interface for time t. Proof. To save space, we first define max max l(Ins) = l (Ins, t, i (Ins) , o (Out))

To show that F3 is a load-safe composite flow interface, we now have to show that F3 is load-safe until time t (cf. Def.2), i. e.,

loadsafe (F3, t) ≡ ∀Ink ∈ In . l3 (Ink) ≤ c3 (Ink) , (8.1) and that F3 is internally safe (cf. Def.4), i. e.,

( max max ) ∀Outj ∈ O . Ink = C(Outj) → l2 Ink, t, o1 (Outj) , o2 (Out2) ≤ c2 (Ink) (8.2)

66 8.3. SAFE SEQUENTIAL COMPOSITION OF SAFE FLOW INTERFACES

• Case (8.1): We use the definition of load-safety for all the remaining inputs of F3 (with I according to Def.3), i. e.,

∀Ink ∈ In1 . l3 (Ink) ≤ c3 (Ink) and

∀Inl ∈ In2 \I . l3 (Inl) ≤ c3 (Inl) .

We know from the definition of l3 and c3 that

1 ∀Ink ∈ In . l3 (Ink) = l1 (Ink) ∧ c3 (Ink) = c1 (Ink) and

2 ∀Inl ∈ In . l3 (Inl) = l2 (Inl) ∧ c3 (Inl) = c2 (Inl) .

Since F1 and F2 are load-safe it follows that F3 is load-safe. • Case (8.2): We know—since F 2 is load-safe—that

( max max ) loadsafe (F2, t) ≡ ∀Ini ∈ In2 . l2 Ini, t, i2 (Ini) , o2 (Out) ≤ c2 (Ini)

max holds. Since i (Ins) is the maximum flow of input Ins, all values less or equal to this maximum are allowed. As we further know that max max o1 (Outj) ≤ i2 (Ink) for all pairs of connected ports Ink = C(Outj) max (with C according to Def.3), we can replace i2 (Ink) with the smaller max value o1 (Outj) which concludes (8.2).

Theorem1 implies that it is sufficient to check compatibility for all connected pairs of ports to ensure that a composition of load-safe interfaces is load-safe. This is crucial, as it provides a purely arithmetic condition that can easily be checked by a modeling tool at run-time, even for a large number of components and interfaces.

Chapter 9

Evaluation

In the previous chapter we have defined interfaces that describe a flow components external behavior. In this chapter, we will now introduce three example flow components that comply with their respective flow interfaces. Furthermore, we will present an implementation, which allows creation of traffic flow models using these three components. Finally, we will present concluding remarks and provide an outlook to the following parts.

9.1 Verified Traffic Flow Component Library

To demonstrate how actual flow components complying with our presented flow interfaces can be defined and to show the applicability of our flow interfaces, we develop a small library of actual traffic components consisting of (i) atraffic light, (ii) a traffic flow merge component, which merges two roads into oneroad and (iii) a traffic flow split component, which splits a road into two roads. We furthermore verify that their high-fidelity hybrid systems dynamics satisfies their safe flow interfaces and respective contracts. These components can already be used to model a good deal of actual road networks, as they can be combined to form larger components (e. g., n-way merges and splits), cf. Section 5.1. To allow modeling of traffic with a flow model, we assume that all vehicles are of uniform size and similar behavior. We do not account for changes in driver behavior due to changes in flow (e. g., during congestion), but we consider changes in route preferences through nondeterministic flow ratios in components with multiple outflows. Note that, while we consider an arbitrary positive inflow bound by imax, we assume that outflow from a component is maximal (i. e., omax as long as l > 0 and equal to the current inflow otherwise), since we expect drivers want to pass through the network as fast as possible. We map the members of a flow interface F to a part of the road network as proposed in Section 5.1.2. Our models use dL as a formalism and were verified using KeYmaera [101] (i. e., the predecessor of KeYmaera X).

69 CHAPTER 9. EVALUATION

9.1.1 Traffic Light Component We define a traffic light as a stretch of road, having two states, namely red and green (the orange state is ignored here, since it is just a heads-up for red). If the traffic light is red, no flow along the road is possible and vehicles startto queue up at the traffic light. Upon switching to green, the vehicles start toflow away from the traffic light as fast as possible. This represents a simplification of the actual behavior of vehicles in front of a traffic light, which usually brake and accelerate slowly, resulting in so-called shock-waves [106]. We consider a basic traffic light with equally long red and green cycles and with parametric cycle length Tc ∈ R+. Extension with different phases and timings is possible, but not discussed here. A traffic light interface has a single inflow(n = 1) and a single outflow (m = 1), which are separated through a traffic light. The hybrid program of the traffic flow at a traffic light tl with a constant cycle length Tc can be found in Model 9.1.

Model 9.1 Traffic flow in a traffic light

∗ tl ≡ (ctrltl; planttl) (9.1) 2 ctrltl ≡ if (tc = Tc) then tc := 0; go := (go − 1) fi (9.2) iact := ∗; ?(0 ≤ iact ≤ imax); (9.3) if (l > 0) then oact := omax (9.4) else oact := min(iact, omax) fi; (9.5) ′ act act ′ ′ planttl ≡ l = i − o · go, t = 1, tc = 1 (9.6) & tc ≤ Tc ∧ l ≥ 0 (9.7)

In Model 9.1, go is the status of the traffic light (i. e., red is 0, green is1), Tc is the length of a red- and a green-cycle and tc is the timer measuring the cycle length. The variables l, imax and omax represent the load, maximum inflow, and maximum outflow as per Def.1, while iact and oact are the actual flows. The model consists of a discrete controller and a continuous plant, which are repeated a non-deterministic number of times, cf. (9.1). In (9.2) we check whether or not the timer measuring the cycle length has been running for exactly Tc units of time, (i. e., the traffic light status has not changed within thelast Tc units of time). If so, we reset the timer tc and toggle the traffic light status in(9.2). In (9.3) we set the actual inflow—which models how upstream components hand over flow—non-deterministically to be between 0 and imax. In (9.4) and (9.5) we set the actual outflow depending on the current load. Outflow is setto maximum if the load is positive; otherwise the outflow is determined by the inflow, but still restricted by omax. The continuous evolution in (9.6) and (9.7) linearly increases the global system time t (i. e., overall time that has passed since the start of the system) and the traffic light timer tc (i. e., time since the

70 9.1. VERIFIED TRAFFIC FLOW COMPONENT LIBRARY last signal switch occurred), and runs at most for Tc units of time and while the load l is non-negative (i. e., there can be no negative amount of cars on a road). Furthermore, it updates the load l by actual flows iact and oact depending on the traffic light status go.

Proposition 1 (Traffic Light Load Safety). We want the traffic light to be load- safe in order to avoid an overflow, which would result in a traffic breakdown. A flow interface with one input and one output is load-safe perDef.2 if

max max l (In1, t, i (In1) , {o (Out1)}) ≤ c (In1) .

A traffic light is safeψ ( tl) if it is load-safe for up to a maximum time T .

ψtl ≡ (t ≤ T → l ≤ c)

When started in a safe initial state φtl, the traffic light component tl ensures load safety ψtl φtl → [tl ]ψtl (9.8) where

φtl ≡ t = 0 ∧ 0 ≤ tc ≤ Tc ∧ Tc > 0 ∧ T > 0 ∧ l = 0 ( T − Tc) ∧ c ≥ max(Tc · imax,T · imax − max 0, omax · ) 2 ∧ 0 ≤ imax ∧ 0 ≤ omax ∧ go · (go − 1) = 0 .

The dL formula in (9.8) expresses that all runs of the traffic light model tl, when started in states where φtl is true, reach states where ψtl is true. The precondition φtl ensures that the system timer is reset and all roads are initially empty. It ensures a positive maximum time T , a positive cycle length Tc, and a non-negative cycle time counter tc, which does not exceed the cycle length initially. The state of the traffic light is either stop go = 0 or go go = 1, and the maximum inflow and outflow are non-negative. Furthermore, the capacity must be big enough to handle the load of cars, which might accumulate until T . We proved Proposition1—i. e., dL formula (9.8)—using KeYmaera. The deductive verification tool enforces to find correct conditions φtl and ψtl, which are non-trivial, but necessary to successfully verify the models.

Infinite time. If we want the traffic light to be load-safe forever, we needto increase T towards infinity. As a result, we can obtain a traffic light component that is safe for infinite time when omax ≥ 2 · imax.

9.1.2 Traffic Flow Merge Component A traffic flow merge component is defined as two roads with certain maximum inflows and capacities, which merge into one road. Accordingly a trafficflow merge interface has two inflows (n = 2) and only one outflowm ( = 1). In a

71 CHAPTER 9. EVALUATION microscopic modeling view, vehicles can only pass from one input road through the component. With a macroscopic view, flow can merge from two inputs onto one output at the same time. Here, hybrid programs allow us to talk about both views at the same time: a discrete jump in the controller chooses the flow ratio between the two roads non-deterministically. If the controller chooses only the boundary values (0 or 1), then the model describes a microscopic per vehicle view; otherwise it describes a macroscopic flow view.

Model 9.2 Traffic flow in a traffic flow merge component

∗ tfm ≡ (ctrltfm; planttfm) (9.9)

ctrltfm ≡ road := ∗; ?(0 ≤ road ≤ 1); (9.10) i1act := ∗; ?(0 ≤ i1act ≤ i1max); (9.11) i2act := ∗; ?(0 ≤ i2act ≤ i2max); (9.12) if (l1 > 0 ∨ l2 > 0) then oact := omax (9.13) else oact := min(i1act + i2act, omax) fi; (9.14) ′ act act ′ planttfm ≡ l1 = i1 − o · (1 − road), t = 1, (9.15) l2′ = i2act − oact · road & l1 ≥ 0 ∧ l2 ≥ 0 (9.16)

In Model 9.2 road selects the ratio of flow directed from inflows to the outflow. For boundary values 0 or 1 this models a switch between roads. The variables l1, l2, i1max, i2max and omax represent the loads, maximum inflows, and maximum outflow as per Def.1. In (9.10) the flow ratio is changed. If road = 0, all flow from the first input is directed to the output while the second input isblocked, if road = 1, all flow comes from the second input. In(9.11)–(9.14) we again set the actual flows. The continuous evolution in(9.15) and (9.16) increases time t linearly and updates the loads l1 and l2 by actual flows i1act, i2act and oact depending on the current road distribution. Continuous evolution ensures non-negative loads in (9.16), as no negative amount of cars can be present on a road. Thus, before a negative load would be reached, continuous evolution stops and the controller adapts the flows accordingly.

Proposition 2 (Merge Load Safety). We want the traffic flow merge component to be load-safe in order to avoid an overflow, which would result in a traffic breakdown. A flow interface with two inputs and one output is load safeif

max max l (Ini, t, i (Ini) , {o (Out1)}) ≤ c (Ini) for i ∈ {1, 2} .

A traffic flow merge isψ safe( tfm) if it is load-safe for up to a maximum time T : ( ) ψtfm ≡ t ≤ T → (l1 ≤ c1 ∧ l2 ≤ c2) .

A traffic flow merge component tfm ensures load safety ψtfm, cf. (9.17), when

72 9.1. VERIFIED TRAFFIC FLOW COMPONENT LIBRARY

started in a safe initial state φtfm (9.18).

φtfm → [tfm]ψtfm (9.17)

max max max φtfm ≡ t = 0 ∧ 0 ≤ i1 ∧ 0 ≤ i2 ∧ 0 ≤ o ∧ c1 ≥ T · i1max ∧ c2 ≥ T · i2max (9.18) ∧ l1 = l2 = 0 ∧ 0 ≤ road ≤ 1 We used KeYmaera to verify that Proposition2—i. e., dL formula (9.17)— holds for the merge component of Model 9.2. This means that the traffic flow merge component is load-safe until time T , as long as the capacities c1 and max c2 of the traffic flow merge component are larger than T · i1 for c1 and T · i2max for c2.

Infinite time. Infinite load safety for a traffic flow merge component cannot be guaranteed for Model 9.2, because only one single road could be active all the time. Thus, the other road would require infinite capacity to be load-safe. Infinite-time load safety requires a fairness condition inModel 9.2, which we elaborate further in the next section.

9.1.3 Traffic Flow Merge with Fairness Currently, each input of the traffic flow merge component has to assume that the other input is active all the time, which in turn means that none of them actually ever assumes any outflow. This is due to the fact that the non-deterministic assignment in hybrid programs (cf. Section 6.1) could choose any value for the flow distribution, cf. (9.10), and thus it might always choose the extreme values 0 or 1. To overcome this issues, one can introduce a fairness criterion by means of a fairness factor X that indicates to which degree each input participates in the production of the actual outflow.

Variant 1 – Fixed Ratios One way of introducing such a factor is to fix the ratio to which the roads contribute to the outflow, namely set a constant X (with 0 ≤ X ≤ 1) as outflow from the first road, and 1 − X from the second road. The resulting Model 9.3 sets the actual flows in (9.21)–(9.24). The road distribution is fixed to 1 − X and X in the continuous evolution, cf. (9.25)– (9.26). We introduce this factor X into the proposition as follows. Proposition 3 (Fair Merge Load Safety – 1). We want the fair traffic flow merge component to be load-safe in order to avoid an overflow, which would result in a traffic breakdown. A flow interface with two inputs and oneoutput is load safe if

max max l (In1, t, i (In1) , {o (Out1)}) ≤ c (In1)

73 CHAPTER 9. EVALUATION and max max l (In2, t, i (In2) , {o (Out1)}) ≤ c (In2) .

A fair traffic flow merge is safe(ψtfmf) if it is load-safe for up to a maximum time T . ( ) ψtfmf ≡ t ≤ T → (l1 ≤ c1 ∧ l2 ≤ c2)

When started in a safe initial state φtfmf, a fair traffic flow merge component tfmf ensures load safety ψtfmf

φtfmf → [tfmf ]ψtfmf (9.19) with

max max max φtfmf ≡ t = 0 ∧ i1 > 0 ∧ i2 > 0 ∧ o > 0 ∧ 0 ≤ X ∧ X ≤ 1 ∧ l1 = l2 = 0 ∧ c1 ≥ T · (i1max − omax · (1 − X)) ∧ c2 ≥ T · (i2max − omax · X) .

We used KeYmaera to verify that Proposition3—i. e., dL formula (9.19)— holds for the fair traffic flow merge component of Model 9.3. The introduction of fairness provides us with less strict condition for the proposition.

Model 9.3 Model of traffic flow in a fair traffic flow merge component

∗ tfmf ≡ (ctrltfmf; planttfmf) (9.20) act act max ctrltfmf ≡ i1 := ∗; ?(0 ≤ i1 ≤ i1 ); (9.21) i2act := ∗; ?(0 ≤ i2act ≤ i2max); (9.22) if (l1 > 0 ∨ l2 > 0) then oact := omax (9.23) else oact := Min(i1act + i2act, omax) fi; (9.24) ′ act act planttfmf ≡ l1 = i1 − o · (1 − X), (9.25) l2′ = i2act − oact · X, t′ = 1 (9.26)

Infinite Time. A fair traffic flow merge component is load safe for infinite- time, if omax · (1 − X) ≥ i1max and omax · X ≥ i2max.

Variant 2 – Minimum Outflow An alternative definition of a fairness is, to use the constant factor X as the minimum rate of the outflow that is guaranteed for each of the inputs. This way, the road distribution road is still set non-deterministically, but restricted by X, thus avoiding permanent use of extreme values 0 or 1.

74 9.1. VERIFIED TRAFFIC FLOW COMPONENT LIBRARY

Model 9.4 Alternative model of a fair traffic flow merge component

∗ tfmf ≡ (ctrltfmf; planttfmf) (9.27)

ctrltfmf ≡ road := ∗; ?(X ≤ road ≤ (1 − X)); (9.28) i1act := ∗; ?(0 ≤ i1act ≤ i1max); (9.29) i2act := ∗; ?(0 ≤ i2act ≤ i2max); (9.30) if (l1 > 0 ∨ l2 > 0) then oact := omax (9.31) else oact := Min(i1act + i2act, omax) fi; (9.32) ′ max max planttfmf ≡ l1 = i1 − o · (1 − road), (9.33) l2′ = i2max − omax · road, t′ = 1 (9.34)

The resulting program (cf. Model 9.4) assigns a new non-deterministic road distribution road in the allowed interval (i. e., X ≤ road ≤ (1 − X), with 0 < 1 X ≤ 2 ) in (9.28). This results in a minimum outflow used by each input of at least omax · X. The actual flows are set in(9.29)–(9.32). The continuous evolution in (9.33)–(9.34) updates the load according to the road distribution. We introduce this factor X into the proposition as follows. Proposition 4 (Fair Merge Load Safety – 2). We want the fair traffic flow merge component to be load-safe in order to avoid an overflow, which would result in a traffic breakdown. A flow interface with two inputs and oneoutput is load safe if

max max l (In1, t, i (In1) , {o (Out1)}) ≤ c (In1) and max max l (In2, t, i (In2) , {o (Out1)}) ≤ c (In2) .

A fair traffic flow merge is safe(ψtfmf) if it is load-safe for up to a maximum time T . ( ) ψtfmf ≡ t ≤ T → (l1 ≤ c1 ∧ l2 ≤ c2)

When started in a safe initial state φtfmf, a fair traffic flow merge component tfmf ensures load safety ψtfmf

φtfmf → [tfmf ]ψtfmf (9.35) with

max max max φtfmf ≡ t = 0 ∧ i1 > 0 ∧ i2 > 0 ∧ o > 0 ∧ 0 ≤ X ∧ X ≤ 0.5 ∧ l1 = l2 = 0 ∧ c1 ≥ T · (i1max − omax · X) ∧ c2 ≥ T · (i2max − omax · X) .

75 CHAPTER 9. EVALUATION

The advantage of this alternative is that the flows are not static, but can still vary within the bounds as restricted by X. Still, the introduction of fairness provides us with a less strict condition for the proposition.

Infinite Time. A fair traffic flow merge component following this definition is load safe for infinite-time, if omax · X ≥ i1max and omax · X ≥ i2max.

9.1.4 Traffic Flow Split Component A traffic flow split component is defined as a road having a certain maximum inflow and a capacity, which splits into two roads. Accordingly a trafficflow split interface has one inflow (n = 1) and two outflowsm ( = 2). Akin to the merge component, a discrete jump in the controller chooses the flow ratio between the two roads non-deterministically. If the controller chooses only the boundary values (0 or 1), then the model describes a microscopic per vehicle view; otherwise it describes a macroscopic flow view.

Model 9.5 Traffic flow in a traffic flow split component

tfs ≡ (ctrl; plant)∗ (9.36) act act max ctrltfs ≡ i := ∗; ?(0 ≤ i ≤ i ); (9.37) road := ∗; ?(0 ≤ road ≤ 1); (9.38) if (l > 0) then o1act := o1max; o2act := o2max (9.39) else o1act := min(iact, o1max); (9.40) o2act := min(iact, o2max) fi; (9.41) ′ act act act planttfs ≡ l = i − o1 · (1 − road) − o2 · road, (9.42) t′ = 1 & l ≥ 0 (9.43)

In Model 9.5, l, imax, o1max and o2max represent the load, maximum inflow, and maximum outflows as per Def.1. The actual inflow is set in(9.37). The variable road selects the flow distribution to the outflows and is changed in (9.38). In a sense, it models expected driver preferences: If road = 0 then all flow is directed to the first output, if road = 1 to the second output. Then, in (9.39)–(9.41) the outflows are adjusted depending on the load. For example, consider a highway exit where drivers prefer to exit instead of following the mainline, so that a queue builds up on the mainline upstream from the exit (l > 0). The model captures the exit preference with a choice of road close to one. Even though in this case the mainline downstream of the exit could have o1max outflow in theory, it will only produce o1max · (1 − road) flow, cf. (9.42). When there is no queue on the mainline (l ≤ 0), in (9.40)–(9.41) we simply distribute the inflow (again obeying the maximum possible outflows). The continuous evolution in (9.42) and (9.43) linearly increases time t and updates the load l by

76 9.2. IMPLEMENTATION–SAFE-T MODELING TOOL actual flows iact, o1act and o2act depending on the flow ratio. Again, continuous evolution stops before the load becomes negative. Proposition 5 (Split Load Safety). We want traffic flow split components tobe load-safe in order to avoid an overflow, which would result in a traffic breakdown. A flow interface with one input and two outputs is load-safe perDef.2 if

max max max l (In1, t, i (In1) , {o (Out1) , o (Out2)}) ≤ c (In1) .

A traffic flow split is safe ψtfs if it is load-safe for up to a maximum time T .

ψtfs ≡ (t ≤ T → l ≤ c)

When started in a safe initial state φtfs, the traffic flow split component tfs ensures load safety ψtfs φtfs → [tfs]ψtfs (9.44) where

max max max φtfs ≡ t = 0 ∧ T > 0 ∧ 0 ≤ i ∧ 0 ≤ o1 ∧ 0 ≤ o2 ( ) ∧ c ≥ max 0,T · (imax − min (o1max, o2max)) ∧ l = 0 ∧ 0 ≤ road ≤ 1 .

We used KeYmaera to verify that Proposition5—i. e., dL formula (9.44)— holds for the component in Model 9.5. Thus we can infer, that as long as the capacity c of the traffic flow split component exceeds ( ) max 0,T · (imax − min (o1max, o2max)) the intersection component is load-safe until time T .

Infinite time If we want the intersection to be load-safe forever, we need to increase T towards infinity. This way we can obtain that a traffic flow split component is safe for infinite time, if o1max ≥ imax ∧ o2max ≥ imax.

9.2 Implementation–SAFE-T Modeling Tool

To evaluate our traffic flow component library, we implemented a prototypical modeling tool (SAFE-T, i. e., Safety Analysis Flow-component Editor for Traffic networks) for traffic network configuration. This evaluation scenariois motivated by traffic control information systems [9], where human traffic operators have to make decisions with little support in assessing the effects of their decisions (e. g., how would closing a specific part of the road network affect flow). SAFE-T lets traffic operators instantiate and compose traffic components, and automatically check load-safety of the resulting network using the criteria of Propositions1–5. The respective properties (e. g., capacities, flows) can be set

77 CHAPTER 9. EVALUATION according to environmental features (e. g., number of lanes) and traffic situations (e. g., flows differ from rush hour to off-peak times). In order to form a traffic network from our traffic component library, the modeling tool uses the sequential composition operation as defined in Sec- tion 8.3. It checks the arithmetic conditions required to ensure compatibility (cf. Def.5 and Theorem1) and highlights connections where the maximum outflow might become too large with a “(!)”. Additionally, since sequential composition of two traffic components means that the components represent consecutive parts of the traffic network, the tool sets the flows of connected In andOutto the minimum of the respective imax and omax. Because SAFE-T checks this and all traffic components presented above are proven load-safe in KeYmaera, we know that their composition in the whole network is again load-safe.

Analysis Panel

Name C1 i_max 1.0 o_max 1.0 …

Component t=7: OVERFLOW@‘C1‘ Properties load=10.0 … Load Graph

Network Graph

Time Slider

Figure 9.1: Screenshot with illustrations, showing a SAFE-T traffic model of an actual highway exit in Austria

The toolbar at the top of the tool—as seen in Fig. 9.1—provides access to the component library to form a network graph. Besides the components introduced in Section 9.1 (i. e., traffic light, merge and split), the tool supports a dedicated start component without inputs, supplying constant flow on a single output, and an end component without outputs, consuming flow. Start- and end components represent parts of the road network, which are not part of the model. A start component approximates the number of cars arriving at the network at hand through an incoming road (e. g., a highway exit through which cars enter the network under consideration). An end component consumes cars that exit the network under consideration and can additionally have a specific

78 9.2. IMPLEMENTATION–SAFE-T MODELING TOOL capacity approximating the number of cars that can enter this part of the traffic network safely (e. g., one end component might represent the center ofa city, which has limited capacities, while another one might represent a highway diverting a much larger number of cars). The time slider at the bottom of the screen sets the current time t used in calculations. Upon component selection, the left part of the work area visualizes input load over time in a load graph per input, and allows adaption of the component properties (e. g., name, flows). For each input, the tool prints the loads with respect to the selected time and capacities above the components. Furthermore, the tool allows analysis of spillback (i. e., overflow propagation) within the network, where we assume that as soon as an overflow in a component occurs (i. e., as soon as the load reaches the capacity, or to put it another way, as soon as the queue is no longer limited to the component at hand, but spills back to the preceding component) all inflow and outflow of this component is reduced to zero, thus changing the behavior of connected components and propagating the overflow through the network. The analysis panel contains a list of overflow events, ordered ascendingly by time. When selecting a list entry, the respective component is highlighted red and all components affected by the overflow (i. e., all connected components, as their flows to respectively fromthe overflown component are reduced to zero) become yellow. This way, theuser can not only see at which point in time an overflow occurs, but also how this overflow propagates through the network and reaches a point of interest (e.g., when does a traffic jam caused by a road block reach the highway).

9.2.1 Example: Highway Exit The example in Fig. 9.1 shows the model of a highway exit in Austria, created using only components presented in this part of the paper (and additional start components, representing the highway, and end components representing the surrounding traffic network). By moving the time slider, one can see howthe load within the different components changes or which component produces an overflow. On the right hand side, the analysis panel is displayed andthe selected traffic light component, producing an overflow after 7 units oftimefor the configuration at hand, is highlighted in red. This leads to a reduction of flow to zero in the two connected components, which are highlighted in yellow. The advantage of our approach is that the safety of the overall system can be derived from properties of the single components, because the behavior of the components, as well as their compositions are verified. Also the flow values can be adapted depending on current events (e. g., rush hour) by changing certain parameters, without remodeling the entire network.

9.2.2 Example: Spillback Analysis To demonstrate the capabilities of our analysis panel for spillback analysis, we modeled a small traffic network with one split and two traffic lights, connected as in Fig. 9.2.

79 CHAPTER 9. EVALUATION

Figure 9.2: Extract of an example traffic network, consisting of a traffic split and two traffic lights. Two end components consume the outgoing traffic flow.

Upon opening, the analysis panel highlights that the first component to produce an overflow will be the traffic light at the bottom,at t = 0.73. Upon selection in the panel, the respective component is highlighted red in the network graph, while all components affected by this overflow are highlighted yellow, cf. Fig. 9.3. The load graph also shows the time at which an overflow occurs. The impacts of the overflow become apparent, when selecting the split component directly connected to the traffic light, cf. Fig. 9.4. Here, the load graph reveals that the load of the component remained zero initially. However, as the overflow in the subsequent traffic light reduced the outflow of the split component, the load starts to increase, leading to an overflow at t = 1.23. The example shows how the tool can be used to analyze the overflow propagation through a traffic network. It reveals, how overflow in succeeding components influences preceding components.

80 9.2. IMPLEMENTATION–SAFE-T MODELING TOOL

Figure 9.3: The selected traffic light (highlighted red) produces an overflow at t = 0.73. Affected components are highlighted yellow.

Figure 9.4: The selected split component (highlighted red) produces an overflow at t = 1.23. The components behavior changes because of the overflow in its successor component.

81 CHAPTER 9. EVALUATION

9.3 Conclusion and Open Issues

In this part, we presented a component-based modeling and verification approach for traffic flow in road networks that can be used to reduce verification complexity of CPS models. The approach uses two modeling levels: (i) high- fidelity flow models, which define the hybrid system behavior of flow components, and (ii) higher-level specifications to build a large network from provably correct components. We further presented the modeling tool SAFE-T for composition of verified traffic flow components. SAFE-T supports automatic checking of the derived arithmetic conditions to ensure safety of the overall traffic network and to analyze the propagation of overflows. The tool can be (i) enhanced with further flow components, (ii) adapted for different flow-based CPS application areas and (iii) extended to check further constraints (e. g., actual flow). This initial approach is just a first step towards a proof-aware modeling and verification approach. Nevertheless, it acts as a starting point, focused on flow-based CPS considering maximum flow values and simplified continuous dynamics, which we will generalize and extend in subsequent parts of this thesis. Fig. 9.5 summarizes the capabilities of the approach presented in this part of the thesis. Components do not yet have a unified structure. Interfaces have a unified structure, and allow the definition of inputs and outputs, but are restricted to inflows and outflows. As the ports forwarding traffic flow in our approach always transfer single values from one output port to one input port, multi-ports are neither needed, nor supported. Following our classification of contracts from Section 3.1.3, our traffic flow contracts are global contracts, however, witha fixed property (i. e., no overflow). Composition is instantaneous and lossless, but limited to flow propagation. In the subsequent parts, we will address the shortcomings highlighted in Fig. 9.5. Additionally, potential further research directions with respect to the field of traffic control, which will not be approached in this thesis include 1. extending component definitions with actual flow, 2. extending models to consider traffic phenomena (e. g., shock-waves),

3. considering models with loops, 4. introducing further traffic components (e. g., multi-lane merge/split), and 5. exploring methods to automatically transform road network graphs into components and compositions.

82 9.3. CONCLUSION AND OPEN ISSUES

 supported  not supported Part 1 Part 2 Part 3 Traffic Contracts Global Contracts Change/Delay Components unified  Interfaces unified  ports (flow only) multi-ports  Contracts global (flow only) change  delay  Composition instantaneous (flow only) delayed  lossless (flow only) lossy 

 supported  not supported

Figure 9.5: Capabilities of the approach with regard to the requirements presented in Section 3.3.

Part III

Generic Approach with Global Contracts

Chapter 10

Introduction

In the previous part, we have introduced a domain-specific component-based modeling and verification approach, geared towards traffic flow networks, as needed to address the issue of avoiding traffic breakdowns, cf. Section 5.1. However, recall the motivational example on cruise control, cf. Section 5.2: Even though the origin of the vehicle cruise control example is still the traffic scenario, it does not deal with traffic networks or flow, but moves from the macroscopic view to the microscopic (i. e., single car) case, and can thus not be handled by the approach of PartII. On that account, in this part, we will extend the notion of interfaces to allow ports to transfer arbitrary information, not just traffic flow on roads. We will further clarify what constitutes a component and will define, under which conditions such a component complies with a related interface (i. e., the interface is admissible for the component). We will unify the previously individual notion of safety of traffic components, to a common notion of contract compliance. Again, we will base upon a notion of compatibility, which—together with the unified definition of components—allows the introduction of a structured composition operation. Furthermore, we define a technique to compose components such that safety properties about the whole system emerge from component safety proofs. In this part, we will focus on global contracts (e. g., robots will not collide when staying in disjoint spatial regions). Global contracts already allow verification of a range of systems (e. g., Section 5.2), without the additional overhead required for change- and delay contracts, cf. PartIV. We illustrate our approach with the vehicle cruise control case study introduced in Section 5.2 as a running example. The system consists of an engine component adapting the vehicle speed according to a target speed chosen by a cruise control component, cf. Fig. 10.1. The vehicle moves continuously, while the control behavior is described by a discrete control part (e. g., choose speed and acceleration). The goal is to keep the actual speed in some range [0,S], where S denotes a maximum speed. Detailed models, interfaces and contracts for each part of the system are introduced in Chapter 12.

87 CHAPTER 10. INTRODUCTION

Constant Global Knowledge Maximum speed 푺 ≥ 0

푠푎푐 ↦ 푠푒

Autonomous Cruise Controller Engine Component Component 푡푟 푡푟 푡푟 푡푟 0 ≤ 푠푎푐 ≤ 푺 0 ≤ 푠푎푐 ≤ 푺 푠푎푐 ↦ 푠푒 0 ≤ 푠푒 ≤ 푺 0 ≤ 푠푒 ≤ 푺

Figure 10.1: Running Example: The engine receives target speeds, and sends the current speed to the cruise controller. Transmitted values must be within the constant global interval, i. e., below the globally known maximum speed.

Note that we model components fully symbolically, which means that each component represents actually a family of concrete components (with different valuations for the constants and variables). Formal definitions of the two components, their interfaces, and the respective contracts, will be introduced step-by-step along the definitions in Chapter 11. Additionally, we will introduce notions of refinement, as needed in our strategy (cf. Section 3.2), and plausibility to determine, if a system consisting of multiple components is still reasonable. For instance, a plausible composite prevents the composition of components with contradictory assumptions. The rest of this part is organized as follows:

• In Chapter 11 we introduce the theoretical background for the global contracts approach, which comprises (i) a definition of structure and behavior of components together with notions of safety and plausibility, cf. Sec- tion 11.1, (ii) parallel composition such that safety and plausibility transfer from components to composites, cf. Section 11.2, and (iii) a notion of refinement that allows replacement of a monolithic program witha component-based one, cf. Section 11.4. Section 11.5 concludes the chapter, with proofs for all introduced theorems.

• In Chapter 12 we first use our approach to address the vehicle cruise control example from Section 5.2, cf. Section 12.1. We illustrate the advantages of the component-based approach by comparing it to a monolithic version. Section 12.2 concludes the part with a discussion of open issues and possible future research directions.

88 All contents in this part of the thesis are based on our previous work “A Component-Based Approach to Hybrid Systems Safety Verification” as published in “Integrated Formal Methods - 12th International Conference”, cf. [82], respectively on the associated report, cf. [81].

Chapter 11

Concept

In this section, we introduce essential definitions and theorems as needed fora component-based modeling and verification approach based on global contracts, and roughly aligned with the strategy presented in Section 3.2. Section 11.1 introduces components, cf. step (2), and their contracts, cf. steps (3) and (4). Section 11.2 introduces composition, cf. step (5), and ensures that the local properties transfer to the overall system. Finally, Section 11.4 discusses the plausibility of composites and introduces the notion of refinement, cf. step (3).

11.1 Components and Contracts

In general, components can observe a shared global state, and modify their internal state. Definition 6 (Global Variables). The global variables V global are a set of variables shared by all components. None of the global variables can ever be bound in any part of any component.

11.1.1 Components In the following, we define the internal behavior of a component in the canonical order of a control part followed by a plant. Definition 7 (Component). A component C is defined as a tuple C = (ctrl, plant) , where • ctrl is the discrete control part of a hybrid program (HP) and does not contain continuous parts (i. e., differential equations), and • plant is the continuous part of the form

′ ′ {x1 = θ1, ..., xn = θn&H} for n ∈ N , i. e., an ordinary differential equation with evolution domain constraint H.

91 CHAPTER 11. CONCEPT

Remark 3. Note that this formal definition of a component enables the definition of a structured composition operation for components and interfaces, as opposed to the solely interface-based composition in the previous part of the thesis. The interface of a component describes the external behavior of the component. It consists of input and output ports (i. e., Vin and Vout), which can have contracts that restrict the values passed through them (i. e., πin and πout, e. g., value range for the target speed). Definition 8 (Interface). An interface I is defined as a tuple

I = (V in, πin, V out, πout) , where

• V in is a set of input variables, V out is a set of output variables, • V in ∩ V out = ∅ input variables and output variables are disjoint, • πin : V in → dL specifies an input predicate (dL represents the set of all dL formulas, cf. Section 6.2) representing input requirements and assumptions, exactly one per input variable (i. e., input port), accordingly for πout : V out → dL, •∀ v ∈ V in : V (πin(v)) ⊆ (V \ V in) ∪ {v}, i. e., no input predicate can mention other input variables, which lets us reshuffle port ordering. An interface I is called admissible for a component C, if none of the input variables are bound in ctrl or plant, i. e., (BV (ctrl) ∪ BV (plant)) ∩ V in = ∅. Even though their is no explicit restriction for the use of variables in the output predicate, only the respective output variable and global constants should be used in these formulas. Use of other variables (i. e., other output variables or local variables) leads to ports, which can never be compatible with any input port, cf. Def. 11. Note that this generic interface definition is no longer limited to ports propagating flow values, and allows arbitrary global properties as input assumptions (respectively output guarantees), as opposed to the static intervals of PartII.

11.1.2 Example: Components Consider our running example of the vehicle cruise control, where the engine component chooses the acceleration according to a target speed, cf. Fig. 11.1. Consider our running example of the vehicle cruise control, where the engine component chooses the acceleration according to a target speed, cf. Fig. 11.1. As illustrated in Fig. 11.1a, the component has a single input port to receive a target speed and a single output port to provide the current speed. Fig. 11.1b describes this component and interface formally: The engine re- tr ceives a target speed between 0 and S on its single input port se , cf. (11.1). The controller chooses the acceleration of the vehicle such that it will not exceed

92 11.1. COMPONENTS AND CONTRACTS the target speed until the next run at most ε time later and stores the current system time, cf. (11.2). It is a time-triggered controller with sampling period ε. The plant adapts the speed accordingly and runs for at most ε time to enforce the sampling period1, cf. (11.3). The single output port yields the resulting actual speed, which still has to be between 0 and S, cf. (11.4).

in tr tr πe (se ) ≡ 0 ≤ se ≤ S (11.1) requirement: 0 ≤ str ≤ S e str − s ctrl ≡ a := e e ; t0 := t (11.2) str e e ε e e ve se ′ 0 ae plante ≡ {se = ae & t − te ≤ ε} (11.3) out πe (se) ≡ 0 ≤ se ≤ S (11.4) guarantee: 0 ≤ se ≤ S (a) Engine illustration: The en- (b) Formal component and interface: The input tr in tr gine has one input port se and one assumption πe (se ) and the output guarantee out output port se, with respective as- πe (se) form the interface around the compo- sumptions/guarantees. nent (ctrle, plante).

Figure 11.1: Engine component and interface (Ce,Ie)

11.1.3 Contracts The contract links the component and its admissible interface, and includes information about the components initial- and target states, cf. Def.9.

Definition 9 (Contract). Let C be a component, I be an admissible interface for C, and φ be a formula over the component’s variables V, which determines the component’s initial state. Let ψsafe be a predicate over the component’s variables V, i. e., a property describing the desirable target system state (i. e., a def safe out out ⋀ out safety property). We define ψ ≡ ψ ∧ Π , where Π ≡ v∈V out π (v) is the conjunction of all output guarantees. The contract of a component C with its interface I is defined as

Cont(C,I) ≡ φ → [(in; ctrl; {plant})∗]ψ

def ( in ) ( in ) in with input in ≡ v1 := ∗;?π (v1) ; ...; vr := ∗;?π (vr) for all vi ∈ V .

As the input predicates are not allowed to mention other inputs, the order of inputs in in is irrelevant. We call a component with an admissible interface that provably satisfies its contract to be contract compliant. This means, if started in a state satisfying φ, the component only reaches states that satisfy safety ψsafe and all output guarantees πout.

1System time t is omitted for space reasons, but evolves with t′ = 1.

93 CHAPTER 11. CONCEPT

11.1.4 Example: Contracts In our running example of Fig. 11.1, the engine component has an output guarantee out π ≡ (0 ≤ se ≤ S) (i. e., the speed must always be in range), and when starting from the initial conditions

φ ≡ (se = 0 ∧ ε > 0 ∧ S > 0) (i. e., the vehicle is initially stopped) it can provably guarantee safety2

safe ψ ≡ 0 ≤ se ≤ S.

As opposed to the previous part of the thesis, where we introduced individual contracts for each component, this formal definition provides us with a unified contract for each component with an admissible interface. These unified contracts will later enable the derivation of a theorem transferring local verification results to a composite that fits all components.

11.2 Composition and Compatibility

Now that we have defined the structure and behavior of single components and their interfaces, we specify how to compose a number of those component- interface pairs by defining a syntactic composition operator for components with admissible interfaces.

11.2.1 Composition Following Section 3.1.2, we compose the discrete ctrl of multiple components in parallel by executing them sequentially in any order, while keeping their ′ ′ plants truly parallel through {x1 = θ1, . . . , xn = θn & H}. Interaction between components is then possible by observing plant output. Such interaction, which exchanges information between components, will be defined by connecting ports when composing components through their interfaces. The port connections are represented by a mapping function X , which pairwise assigns output ports to input ports. In this part of the thesis, we focus on instantaneous lossless interaction (cf. Section 3.1.3), where the input variable v instantaneously takes on the value of the output port it is connected to, cf. v := X (v) in Def. 10. As we do not require all ports to be connected, the mapping function is a partial function. Ports which are not connected become ports of the composite, while ports which are connected become internal variables.

2Note that in this case the output property and the safety property coincide. This is not necessarily always the case.

94 11.2. COMPOSITION AND COMPATIBILITY

Definition 10 (Parallel Composition). Let Ci denote one of n components

Ci = (ctrli, planti) for i ∈ {1, ..., n} with their corresponding admissible interfaces

( in in out out) Ii = V i , πi , V i , πi for i ∈ {1, ..., n} where

( in out ) ( in out ) V i ∪ V i ∪ V(ctrli) ∪ V(planti) ∩ V j ∪ V j ∪ V(ctrlj) ∪ V(plantj) ⊆ V global for i ̸= j , i. e., only variables in V global are shared between components, and let ⎛ ⎞ ⎛ ⎞ ⋃ in ⋃ out X : ⎝ V j ⎠ ⇀ ⎝ V i ⎠ 1≤j≤n 1≤i≤n be a partial (i. e., not every input must be mapped), injective (i. e., every output is only mapped to one input) function, connecting inputs to outputs. We define IX as the domain of X (i. e., all variables x ∈ V in such that X (x) is defined) and OX as the the image of X (i. e., all variables y ∈ V out such that y = X (x) holds for some x ∈ V in).

def (C,I) ≡ ((C1,I1)∥...∥(Cn,In))X is defined as the composite of n components and their interfaces (with respect to X ), where • the sensing for non-connected inputs remains unchanged

in in in X in ≡ vk := ∗;?π (vk); ... ; vs := ∗;?π (vs) for {vk, . . . , vs} = V \I    open inputs

• the order in which the control parts (and the respective port mappings) are executed is chosen non-deterministically (considering all the n! possible permutations of {1, ..., n}), so that connected ports become internal behavior of the composite component

ctrl ≡ (ports1; ctrl1; ports2; ctrl2; ...; portsn; ctrln) ∪

(ports2; ctrl2; ports1; ctrl1; ...; portsn; ctrln) ∪ ...

(portsn; ctrln; ...; ports2; ctrl2, ports1; ctrl1)

def X in with portsi ≡ vj := X (vj); ... ; vr := X (vr) for {vj, . . . , vr} = I ∩ V i ,    connected inputs

95 CHAPTER 11. CONCEPT

• continuous parts are executed in parallel, staying inside all evolution domains

{ (1)′ (1) (k)′ (k) (1)′ (1) (m)′ (m) plant ≡ x1 = θ1 , . . . , x1 = θ1 , . . . , xn = θn , . . . , xn = θn       component C1 component Cn } & H1 ∧ ... ∧ Hn ,

in ⋃ in X • the respective sets of variables are merged, so V = 1≤i≤n V i \I , out ⋃ out X V = 1≤i≤n V i \O , i. e., ports not connected within the composite component remain input and output variables of the resulting interface,

• input port requirements of all interfaces are preserved, except for connected inputs, i. e., πin : V in → dL becomes πin(v), accordingly for πout(v) ⎧ πin(v)if v ∈ V in \IX ⎨⎪ 1 1 πin(v) ≡ ... ⎪ in in X ⎩πn (v)if v ∈ V n \I

⎧ πout(v)if v ∈ V out \OX ⎨⎪ 1 1 πout(v) ≡ ... . ⎪ out out X ⎩πn (v)if v ∈ V n \O

As opposed to the composition of traffic flow components in PartII, Def. 10 composes a component as well as its interface. Thus, composition does not only yield a composite interface, but furthermore provides a composite component, i. e., hybrid program, while in PartII the hybrid program for the composite had to be derived manually for each individual component. This definition of parallel composition uses a conjunction of all evolution domains, which resembles synchronization on the most restrictive component (i. e., as soon as the first and most restrictive condition is no longer fulfilled all plants have to stop and hand over to ctrl). A more liberal component might be forced to execute its control part because the evolution domain of a more restrictive component did no longer hold. For example a component increasing a counter on every run of its control is then forced to count although its own evolution domain might have allowed it to postpone control. If this is undesired, a component’s control can be defined as ctrli ∪ ?H; skip, which would allow the component to skip when forced to run its control part, as long as its evolution domain H holds (i. e., as long as its plant could still run).

Remark 4. We define this composition operation for any number of components, since it is not associative, because the composition of three components results in 3! = 6 possible execution orders, whereas composing two components and adding a third yields only 2! ∗ 2! = 4 of the possible 6 execution

96 11.2. COMPOSITION AND COMPATIBILITY

orders. Consider three components Ci = (ctrli, planti) for i ∈ {1, 2, 3}. If these components are composed altogether with respect to a mapping X , i. e.,

(Ccomp,Icomp) = ((C1,I1)∥(C2,I2)∥(C3,I3))X , the control part of the resulting component is

ctrlcomp ≡ ctrl1; ctrl2; ctrl3 ∪

ctrl1; ctrl3; ctrl2 ∪

ctrl2; ctrl1; ctrl3 ∪

ctrl2; ctrl3; ctrl1 ∪

ctrl3; ctrl1; ctrl2 ∪

ctrl3; ctrl2; ctrl1 .

However, if we first compose (Cy,Iy) = ((C1,I1)∥(C2,I2))Y , with respect to mapping Y and then compose (Ccomp,Icomp) = ((Cy,Iy)∥(C3,I3))Z , with respect to mapping Z, where X = Y ∪ Z, we get

ctrly ≡ ctrl1; ctrl2 ∪

ctrl2; ctrl1 , and subsequently

ctrlcomp ≡ ctrly; ctrl3 ∪

ctrl3; ctrly

≡ ((ctrl1; ctrl2 ∪ ctrl2; ctrl1) ; ctrl3) ∪

(ctrl3; (ctrl1; ctrl2 ∪ ctrl2; ctrl1))

≡ ctrl1; ctrl2; ctrl3 ∪

ctrl2; ctrl1; ctrl3 ∪

ctrl3; ctrl1; ctrl2 ∪

ctrl3; ctrl2; ctrl1 .

Thus, the cases where ctrl3 is rotated in between ctrl1 and ctrl2 are lost, because ctrly ≡ (ctrl1; ctrl2 ∪ ctrl2; ctrl1) is considered in unity. Remark 5. Note that verifying the hybrid program for a composite according to Def. 10 would require a proof of each of the n! branches of ctrl individually, as they all differ slightly. For a large number of components, this entailsa huge proof effort. Previous non-component-based case studies (e. g.,[63, 71, 72]), therefore, chose only one specific ordering. Our component-based approach verifies all possible orderings at once because the permutations are all proven correct as part of proving Theorem2 later in Section 11.5.1. It remains to show that the result of a parallel composition according to Def. 10 is again a component with an admissible interface by Def.7 and Def.8. Thus, we have to compare the resulting constructs to the definitions. In particular, we have to ensure the following properties (notation following Def. 10; note that variables without subscript index refer to the composite):

97 CHAPTER 11. CONCEPT

• (Vin ∪ Vglobal) ∩ (BV (ctrl) ∪ BV (plant)) = ∅: We know from the definition of ctrl and plant in Def. 10 that ⋃ BV (ctrl) = (BV (ctrli) ∪ BV (portsi)) 1≤i≤n and ⋃ BV (plant) = BV (planti) . 1≤i≤n Thus, we have to show

( in global) (i) V ∪ V ∩ BV (ctrli) = ∅: ( in global) From Def.6 and Def.8 we know that Vi ∪ Vi ∩BV (ctrli) = ∅ in ⋃ in holds for Ci/Ii. Furthermore, since V ⊆ 1≤i≤n Vi , we know that in global ⋃ (V ∪ V ) ∩ 1≤i≤n BV (ctrli) = ∅. ( in global) (ii) V ∪ V ∩ BV (portsi) = ∅: X in X From BV (portsi) ⊆ I for all i,V ∩ I = ∅, and BV (portsi) ⊆ in in global in ⋃ in Vi ,Vi ∩V = ∅ for all i (by Def.7), and V ⊆ 1≤i≤n Vi (by in global ⋃ Def. 10), we further get that (V ∪V )∩ 1≤i≤n BV (portsi) = ∅. ( in global) (iii) V ∪ V ∩ BV (planti) = ∅: in global Since Ci are components we know (Vi ∪ V ) ∩ BV (planti) = ∅. Hence, also (Vin ∪ Vglobal) ∩ BV (plant) = ∅. ( ) From (i) and (ii) we infer that Vin ∪ Vglobal ∩ BV (ctrl) = ∅. Together with (iii) we conclude (Vin ∪ Vglobal) ∩ (BV (ctrl) ∪ BV (plant)) = ∅. • Global variables must not be bound: Follows immediately, since global variables cannot be bound anywhere. •∀ v ∈ Vin : V (πin(v)) ⊆ (V \ Vin) ∪ {v}: in in in Since the definition π (v) is defined as πi (v) for v ∈ Vi , and since Ci/Ii are components/interfaces, this condition transfers to the composite. As a result, composite components are again components with interfaces and can thus be used in yet another composition.

11.2.2 Example: Composition To demonstrate parallel composition in our running example, we first introduce a cruise controller component, cf. Fig. 11.2. The cruise control selects a target tr speed from the interval 0 ≤ sac ≤ S, but keeps the difference between the current (received) speed and the chosen target speed below δS, cf. (11.6)–(11.7). That way, the acceleration set by the engine component is bounded by δS/ε (i. e., the vehicle does not accelerate too fiercely). We connect this cruise controller component to the engine component, as illustrated in Fig. 11.3.

98 11.2. COMPOSITION AND COMPATIBILITY

in requirement: 0 ≤ sac ≤ S πac(sac) ≡ 0 ≤ sac ≤ S (11.5) tr ( tr tr ctrlac ≡ s := ∗;? 0 ≤ s ≤ S (11.6) sac target speed sac ac ac tr ⏐ tr ⏐ ) sac ∧ ⏐sac − sac⏐ ≤ δS (11.7) πout(str ) ≡ 0 ≤ str ≤ S (11.8) tr ac ac ac guarantee: 0 ≤ sac ≤ S (a) Cruise controller illustration: (b) Formal component and interface: The input in The cruise controller has one in- assumption πac(sac) and the output guarantee out tr put port sac and one output port πac (sac) form the interface around the compo- tr sac, with assumptions/guarantees. nent (ctrlac, plantac).

Figure 11.2: Cruise controller component and interface (Cac,Iac)

11.2.3 Compatibility

Note that Def. 10 replaces the non-deterministic input guarded by a test from Def.7 with a deterministic assignment that represents instantaneous and lossless interaction between components (i. e., portsi), as illustrated in Fig. 11.3. Hence, the respective output guarantees and input assumptions must match.

Definition 11 (Compatible Composite). A composite of n components with admissible interfaces ((C1,I1)∥...∥(Cn,In))X is a compatible composite iff dL formula

def ( out in ) CPO(Ii) ≡ [v := X (v)] πj (X (v)) → πi (v)

X in is valid for all input ports v ∈ I ∩ V i , for all interfaces Ii and where Ij is the interface containing the port that is connected to the input port v of Ii. We call CPO(Ci) the compatibility proof obligation for the interfaces Ii and say the interfaces Ii are compatible (with respect to X ) if CPO(Ii) holds for all i.

In other words, ((C1,I1)∥...∥(Cn,In))X is a compatible composite if all internal port connections are appropriate, i. e., if the guarantee of the output port implies the requirements of the respective input port to which it is connected.

11.2.4 Example: Compatibility

tr For instance, a cruise controller component providing speeds 0 ≤ sac ≤ 70 is tr compatible with an engine demanding 0 ≤ se ≤ 100, but a controller component tr providing speeds 0 ≤ sac ≤ 100 is not compatible with an engine demanding tr tr 0 ≤ se ≤ 70, since the controller component might provide a speed sac which tr is outside the validity interval of the engine (i. e., sac = 100 is allowed, but tr se = 100 is not).

99 CHAPTER 11. CONCEPT

sac := se ve tr tr ae se := sac Composite component: Cruise Control

Figure 11.3: Cruise control composed of a cruise controller and an engine by { tr tr } Def. 10: The port connections X = (sac ↦→ se), (se ↦→ sac) replace the input tr tr tr tr port se := ∗; ?(0 ≤ se ≤ S) with an internal port assignment se := sac, tr tr ( out tr in tr ) provided the compatibility check [se := sac] πac (sac) → πe (se ) succeeds, cf. Def. 11. Accordingly for the second port.

11.3 Transfering Local Component Safety to Sys- tem Safety

Now that we have defined components and interfaces, their contracts, andhow to compose them to form larger composites, we prove that the contracts of single components transfer to composites if compatible.

Theorem 2 (Composition Retains Contracts). Let C1 and C2 be components, with admissible interfaces I1 and I2, that are contract compliant (i. e., their contracts (11.9) and (11.10) are valid)

∗ |= φ1 → [(in1; ctrl1; {plant1}) ]ψ1 and (11.9) ∗ |= φ2 → [(in2; ctrl2; {plant2}) ]ψ2 (11.10) and compatible with respect to X (i. e., compatibility proof obligations (11.11) and (11.12) are valid)

X in for all input ports v ∈ I ∩ V 2 : ( out in ) |= [v := X (v)] π1 (X (v)) → π2 (v) and (11.11) X in for all input ports v ∈ I ∩ V 1 : ( out in ) |= [v := X (v)] π2 (X (v)) → π1 (v) . (11.12)

Then, the parallel composition C3,I3 = ((C1,I1)∥(C2,I2))X satisfies the contract

∗ |= (φ1 ∧ φ2) → [(in3; ctrl3; {plant3}) ](ψ1 ∧ ψ2) (11.13) with in3, ctrl3, and plant3 according to Def. 10. The proof for Theorem2 can be found at the end of this chapter in Sec- tion 11.5.1. This central theorem (along with a generalization to n components, cf. Sec- tion 11.5.1) allows us to infer how properties from single components transfer to their composition. As such, it suffices to prove the properties for the components

100 11.4. PLAUSIBILITY AND REFINEMENT and conclude that a similar property holds for the composite, without explicitly having to verify it. The composite contract states that, considering both preconditions hold (i. e., φ1 ∧ φ2), all states reached by the parallel execution of the components, both postconditions hold (i. e., ψ1 ∧ ψ2).

11.4 Plausibility and Refinement

Finally, we introduce a notion of plausibility that ensures meaningful composite contracts, and a notion of refinement as required in step (3) of our strategy, cf. Section 3.2.

11.4.1 Plausibility Although, through Theorem2 safety of the composite is ensured, the contract might be vacuously true, if the precondition is not satisfiable. Even if that is avoided for single components, their composition (conjunction) could still not be satisfiable, because they might share global variables. For example, assume two components with their interface A = (CA,IA) and B = (CB,IB) that have neither input- nor output-variables, but share a single global global global constant V1 = V2 = {K}. Both control parts and both plants safe are empty. The contract of A is φA ≡ K > 0 and ψA ≡ K > 0. The safe contract of B is φB ≡ K < 0 and ψB ≡ K < 0. Each contract is valid, as K > 0 → [skip]K > 0 and K < 0 → [skip]K < 0 always hold. However, even though their composition is again a safe component according to Theorem2, the resulting contract is vacuously true, as the system can never be started: (K > 0 ∧ K < 0) → [skip](K > 0 ∧ K < 0).

Definition 12 (Plausible Composite). Let Ci be compatible components, with admissible interfaces Ii. We call the parallel composition (∥i (Ci,Ii)) of these ⋀ X components a plausible composite, iff i φi is satisfiable. Note that the above example is not a plausible composite, since—even though each contracts precondition is satisfiable individually—there is no K satisfying the composite precondition (K > 0 ∧ K < 0).

11.4.2 Refinement Our notion of contractual refinement is according to Section 3.1.3.

Definition 13 (Contractual Refinement). Let (C,I) be a component with its interface and let Cont1(C,I) and Cont2(C,I) be contracts, with preconditions φ1 and φ2 and postconditions ψ1 and ψ2. We say Cont1 refines Cont2, iff (φ1 → φ2) ∧ (ψ2 → ψ1).

If Cont1 refines Cont2, we know from a proof of Cont2 that Cont1 must hold as well, see Theorem3.

101 CHAPTER 11. CONCEPT

Theorem 3 (Refinement Theorem). Let (C,I) be a component with its interface, with contracts Cont1(C,I) and Cont2(C,I). If Cont1 is valid and Cont2 refines Cont1 under these contracts, then Cont2 is valid. The proof for Theorem3 can be found at the end of this chapter in Sec- tion 11.5.2. Theorem3 allows replacement of the original (possibly unknown) monolithic program with the composite program, as depicted as last step of the strategy presented in Section 3.2, given that the conjunction of the component contracts refines the global contract, as required in step (3) of the strategy.

11.5 Proofs

In this section, we present proofs for the theorems introduced throughout this chapter.

11.5.1 Proof – Composition Retains Contracts The proof for Theorem2 follows the proof sketch below. The main idea is to match the behavior and properties of the composite with the behavior of its components, so that component proofs fill in most proof obligations. 1. split the proof along component contracts (prove that the composite preserves the component contracts) 2. drop plant behavior that is irrelevant for the current contract (Lemma2) 3. re-introduce (idle) tests for the deterministic port assignments (Lemma5, Lemma6 and Corollary1) 4. replace deterministic with non-deterministic assignment to resemble port behavior of unconnected components (Lemma3) 5. reorder port assignments to match the order in the respective component (Lemma4) 6. drop port assignments and control statements, which are irrelevant for the current contract (Lemma1)

Lemmas We first introduce lemmas for these steps before proceeding with aproofof Theorem2. Lemma1 allows us to drop irrelevant control parts from a hybrid program. Lemma 1 (Drop Program). Let A be an arbitrary dL formula and α, β be hybrid programs, with FV (A) ∩ BV (β) = ∅ and FV (α) ∩ BV (β) = ∅. Then [α]A → [β][α]A and [α]A → [α][β]A are valid.

102 11.5. PROOFS

Proof of Lemma1. We first show that [α]A → [β][α]A. This follows immediately from the V-axiom of dL (i. e., φ → [γ]φ, if FV (φ) ∩ BV (γ) = ∅) with φ = [α]A and γ = β, since we know that FV (A) ∩ BV (β) = ∅ and FV (α) ∩ BV (β) = ∅. ∗ [α]A ⊢ [α]A V (since FV ([α]A) ∩ BV (β) = ∅)[α]A ⊢ [β][α]A →r ⊢ [α]A → [β][α]A The proof of [α]A → [α][β]A uses monotonicity and the V axiom.

∗ A ⊢ A V (since FV (A) ∩ BV (β) = ∅) A ⊢ [β]A [] M [α]A ⊢ [α][β]A →r ⊢ [α]A → [α][β]A

Lemma2 allows us to drop irrelevant parts from the plant of a hybrid program.

Lemma 2 (Drop Plant). Let θ1(x1) and θ2(x2) be terms possibly containing x1 (respectively x2), where x1 and x2 are vectors with x1 ̸= x2. Let t be a variable with t∈ / x1 and t∈ / x2. Let A(x1) be an arbitrary dL formula over x1 and H1(x1),H2(x2) be predicates over x1 (respectively x2). Then

′ ′ [(t = 1, x1 = θ1(x1)&H1(x1))]A(x1) → ′ ′ ′ [(t = 1, x1 = θ1(x1), x2 = θ2(x2)&H1(x1) ∧ H2(x2))]A(x1) is valid. Proof of Lemma2. The proof uses one side of the differential ghost axiom (DG) and differential cut (DC). First we use DC in the unusual inverse direction to get rid of H2(x2). The precondition for the differential cut,

′ ′ ′ [{t = 1, x1 = θ1(x1), x2 = θ2(x2)&H1(x1) ∧ H2(x2)}]H2(x2) follows immediately, since an evolution domain holds throughout (by differential weakening axiom DW, cf. Section 6.1.3), i. e., we know that

′ ′ ′ [{t = 1, x1 = θ1(x1), x2 = θ2(x2)&H1(x1) ∧ H2(x2)}]A(x1) and thus, H2(x2) obviously holds after the continuous evolution. Next we add a universal quantifier using ∀-eliminate3, i. e., (∀x . p(¯x)) → p(¯x), and then we apply DG. Note, that DG is phrased in terms of an ex- istentially quantified variable y, which occurs in a linear ordinary differential

3x¯ is the vector of all relevant variables, cf. [99].

103 CHAPTER 11. CONCEPT equation (ODE). However, in the direction that we need (see step DG), the axiom is stronger, i. e., [x′ = f(x)&q(x)]p(x) → ∀y[x′ = f(x), y′ = η&q(x)]p(x), and uses a universal quantifier and an arbitrary ODE [99]. For space reasons, ′ ′ let Φ ≡ [{t = 1, x1 = θ1(x1)&H1(x1)}]A(x1).

∗ ′ ′ Φ ⊢ [{t = 1, x1 = θ1(x1)&H1(x1)}]A(x1) DG ′ ′ ′ Φ ⊢ ∀x2 . [{t = 1, x1 = θ1(x1), x2 = θ2(x2)&H1(x1)}]A(x1) ∀i ′ ′ ′ Φ ⊢ [{t = 1, x1 = θ1(x1), x2 = θ2(x2)&H1(x1)}]A(x1) DC ′ ′ ′ Φ ⊢ [{t = 1, x1 = θ1(x1), x2 = θ2(x2)&H1(x1) ∧ H2(x2)}]A(x1)

The next lemma states that instead of proving a safety property about a deterministic assignment, we can replace it with a proof for a non-deterministic assignment (cf. [62]).

Lemma 3 (Overapproximate Assignment). Let A(x) be an arbitrary dL formula, θ be a term, and x be a variable. Then

[x := ∗]A(x) → [x := θ]A(x) is valid.

Proof of Lemma3. For the proof, we expand the definition of non-deterministic assignments and use universal instantiation (i. e., if the formula is true for all x it is also true for θ). ∗ A(θ) ⊢ A(θ) ∀l ∀x . A(x) ⊢ A(θ) [:=] ∀x . A(x) ⊢ [x := θ]A(x) [:∗] [x := ∗]A(x) ⊢ [x := θ]A(x) →r ⊢ [x := ∗]A(x) → [x := θ]A(x)

The next lemma allows us to reorder assignments, which do not depend on each other.

Lemma 4 (Reorder Assignment). Let A(x, y) be an arbitrary dL formula and let x, y be different variables and F (x),G(y) be predicates over x, respectively y. Furthermore, let y∈ / V (F (x)) and x∈ / V (G(y)). Then

[x := ∗;?F (x); y := ∗;?G(y)]A(x, y) ↔ [y := ∗;?G(y); x := ∗;?F (x)]A(x, y) is valid.

104 11.5. PROOFS

Proof of Lemma4. The proof follows from the definition of non-deterministic assignments and the axiom for tests. The step all distribute follows, as we know that y∈ / V (F (x)) and x∈ / V (G(y)). The step impl uses the equivalence (a → (b → c)) ↔ (b → (a → c)). We have to show both directions of the equivalence. For space reasons, we write A short for A(x, y). ∗ ∀x . ∀y . (F (x) → (G(y) → A)) ⊢ ∀x . ∀y . (F (x) → (G(y) → A)) impl ∀x . ∀y . (F (x) → (G(y) → A)) ⊢ ∀x . ∀y . (G(y) → (F (x) → A)) all distr ∀x . (F (x) → ∀y . (G(y) → A)) ⊢ ∀y . (G(y) → ∀x (F (x) → A)) [:∗],[:=],[?] [x := ∗][?F (x)][y := ∗][?G(y)]A ⊢ [y := ∗][?G(y)][x := ∗][?F (x)]A [; ] [x := ∗;?F (x); y := ∗;?G(y)]A ⊢ [y := ∗;?G(y); x := ∗;?F (x)]A

The second direction works accordingly.

The next lemma allows the addition of tests, which are known to be true.

Lemma 5 (Introduce Test). Let A be an arbitrary dL formula, α be a hybrid program and F be a formula. Then

[α]F → ([α;?F ]A ↔ [α]A)

Proof of Lemma5. For the proof, we first apply proof rules for implication, before we split the equivalence into two implications, which we verify one after the other. ... ① ... ② ∧r [α]F ⊢ ([α;?F ]A → [α]A) ∧ ([α]A → [α;?F ]A) equiv [α]F ⊢ [α;?F ]A ↔ [α]A →r ⊢ [α]F → ([α;?F ]A ↔ [α]A)

To prove ① we use the K-axiom and modus ponens (MP). ∗ MP F,F → A ⊢ A →r F ⊢ (F → A) → A [] M [α]F ⊢ [α] ((F → A) → A) K [α]F ⊢ [α](F → A) → [α]A [?] [α]F ⊢ [α][?F ]A → [α]A [; ] [α]F ⊢ [α;?F ]A → [α]A ① continued

Similarly, for ②. Since (A → (F → A)) ≡ true, this equivalence also holds in the context of [α] (cf. CE).

105 CHAPTER 11. CONCEPT

∗ F ⊢ true [] M[α]F ⊢ [α]true CE [α]F ⊢ [α](A → (F → A)) K [α]F ⊢ [α]A → [α](F → A) [?] [α]F ⊢ [α]A → [α][?F ]A [; ] [α]F ⊢ [α]A → [α;?F ]A ② continued

The final lemma allows us to weaken a test, if we know that the oldtest implies the new one. Lemma 6 (Weaken Test). Let A be an arbitrary dL formula and F and G be formulas. Then (([?G]A) ∧ (F → G)) → [?F ]A

Proof of Lemma6. The proof uses transitivity of logical implication.

∗ trans G → A, F → G ⊢ F → A [?] [?G]A, F → G ⊢ [?F ]A ∧l ([?G]A) ∧ (F → G) ⊢ [?F ]A →r ⊢ (([?G]A) ∧ (F → G)) → [?F ]A

Corollary1 is a variation of Lemma6, including an assignment before the tests. Corollary 1 (Weaken Test – Assignment). Let A be an arbitrary dL formula, x and y variables and F (x) and G(y) be formulas. Then

(([y := x][?G(y)]A(x, y)) ∧ ([y := x](F (x) → G(y)))) → [y := x][?F (x)]A(x, y)

Proof of Corollary1. After applying the assignments we can again use Lemma6. ∗ L.6 [?G(x)]A(x, x), (F (x) → G(x)) ⊢ [?F (x)]A(x, x) [:=] [y := x][?G(y)]A(x, y), [y := x](F (x) → G(y)) ⊢ [y := x][?F (x)]A(x, y) ∧l ([y := x][?G(y)]A(x, y)) ∧ ([y := x](F (x) → G(y))) ⊢ [y := x][?F (x)]A(x, y)

Note that in the proof of Theorem2 we will use these lemmas in the context of other logical and modal formulas, as described in Section 6.1.

106 11.5. PROOFS

Proof for Two Components Now we finally have all we need to prove that two safe components, which communicate using ports, result in another safe component upon composition. We repeat Theorem2 below for easy reference.

Theorem 2 (Composition Retains Contracts). Let C1 and C2 be components, with admissible interfaces I1 and I2, that are contract compliant (i. e., their contracts (11.9) and (11.10) are valid)

Then, the parallel composition C3,I3 = ((C1,I1)∥(C2,I2))X satisfies the contract

∗ |= (φ1 ∧ φ2) → [(in3; ctrl3; {plant3}) ](ψ1 ∧ ψ2) (11.13) with in3, ctrl3, and plant3 according to Def. 10. Proof of Theorem2. For space reasons let

def (C3,I3) ≡ ((C1,I1)∥(C2,I2))X def ctrl3 ≡ (ports1; ctrl1; ports2; ctrl2) ∪ (ports2; ctrl2; ports1; ctrl1) def plant3 ≡ plant1, plant2 def φ3 ≡ φ1 ∧ φ2

def ψ3 ≡ ψ1 ∧ ψ2 safe def safe safe ψ3 ≡ ψ1 ∧ ψ2 out ⋀ out Π1 ≡ π1 (v) out v∈V1 out ⋀ out Π2 ≡ π2 (v) out v∈V2 ⎛ ⎞ ⎛ ⎞ out def ⎜ ⋀ out ⎟ ⎜ ⋀ out ⎟ Π3 ≡ ⎝ π1 (v)⎠ ∧ ⎝ π2 (v)⎠ out out out out v∈(V3 ∩V1 ) v∈(V3 ∩V2 )

107 CHAPTER 11. CONCEPT

We will use the above abbreviations throughout the proof. We know that

Def.9 ∗ ( safe out) Cont( C1,I1) ≡ φ1 → [(in1; ctrl1; plant1) ] ψ1 ∧ Π1

Def.9 ∗ ( safe out) Cont( C2,I2) ≡ φ2 → [(in2; ctrl2; plant2) ] ψ2 ∧ Π2

Def.9 ∗ ( safe out) Cont( C3,I3) ≡ φ3 → [(in3; ctrl3; plant3) ] ψ3 ∧ Π3

Def. 11 ( out in ) CPO( I1) ≡ [v := X (v)] π1 (X (v)) → π2 (v) and Def. 11 ( out in ) X in CPO( I2) ≡ [v := X (v)] π2 (X (v)) → π1 (v) for all v ∈ I ∩ V1,2 .

We have to show that the contract of the parallel composition Cont( C3,I3) is valid, i. e., [ ∗] φ3 → (in3; ctrl3; {plant3}) ψ3 (11.14)

Assume that formulas (11.9) and (11.10) are valid, hence there exist invariants ϕ1 and ϕ2 [96] (if (11.9) and (11.10) were verified using loop induction, the invariants are even known), such that:

φ1 → ϕ1 φ2 → ϕ2 (11.15)

ϕ1 → [in1; ctrl1; {plant1}]ϕ1 ϕ2 → [in2; ctrl2; {plant2}]ϕ2 (11.16) ( safe out) ( safe out) ϕ1 → ψ1 ∧ Π1 ϕ2 → ψ2 ∧ Π2 (11.17)

By imply-right and loop induction, where we choose ϕ3 = ϕ1 ∧ ϕ2 (i. e., the loop invariant for the proof is the conjunction of the two invariants known to exist from the independent proofs), we get (starting at (11.14)):

... ① ... ② ... ③

φ3 ⊢ ϕ3 ϕ3 ⊢ [in3; ctrl3; {plant3}] ϕ3 ϕ3 ⊢ ψ3 ind [ ∗] φ3 ⊢ (in3; ctrl3; {plant3}) ψ3 →r [ ∗] ⊢ φ3 → (in3; ctrl3; {plant3}) ψ3

We will transform the three resulting branches until we get formulas that correspond to (11.15), (11.16) and (11.17). To prove the induction base case and the use case, we use the loop invariants ϕ1 and ϕ2, for which (11.15) and (11.17) hold. ∗ ∗ (11.15) (11.15) φ1 ⊢ ϕ1 φ2 ⊢ ϕ2 Wl Wl φ1, φ2 ⊢ ϕ1 φ1, φ2 ⊢ ϕ2 ∧l ∧l φ1 ∧ φ2 ⊢ ϕ1 φ1 ∧ φ2 ⊢ ϕ2 ∧r φ1 ∧ φ2 ⊢ ϕ1 ∧ ϕ2 def ① continued

108 11.5. PROOFS

Note that in the first step (i. e., def ) of the proof of ③ below, we use

• ϕ3 ≡ ϕ1 ∧ ϕ2 ,

( safe out) ( safe safe out) • ψ3 ≡ ψ3 ∧ Π3 ≡ ψ1 ∧ ψ2 ∧ Π3 ,

out out out • Π1 ∧ Π2 → Π3 , since out out (⋀ out ) (⋀ out ) Π ∧ Π ≡ out π (v) ∧ out π (v) and 1 2 v∈V1 1 v∈V2 2 out (⋀ out ) (⋀ out ) Π3 ≡ out out π1 (v) ∧ out out π2 (v) v∈(V3 ∩V1 ) v∈(V3 ∩V2 ) (i. e., if the conjunction on the left side of the implication holds, the one with fewer elements on the right side of the implication holds even more so), and • associativity and commutativity of logical conjunction. ∗ ∗ (11.17) safe out (11.17) safe out ϕ1 ⊢ ψ1 ∧ Π1 ϕ2 ⊢ ψ2 ∧ Π2 Wl safe out Wl safe out ϕ1, ϕ2 ⊢ ψ1 ∧ Π1 ϕ1, ϕ2 ⊢ ψ2 ∧ Π2 ∧r ( safe out) ( safe out) ϕ1, ϕ2 ⊢ ψ1 ∧ Π1 ∧ ψ2 ∧ Π2 ∧l ( safe out) ( safe out) ϕ1 ∧ ϕ2 ⊢ ψ1 ∧ Π1 ∧ ψ2 ∧ Π2 def ③ continued It remains to show the induction step, which we do by proving invariance of ϕ1 and ϕ2 separately. ... ④ ... ⑤ ϕ1, ϕ2 ⊢ [in3; ctrl3][{plant3}]ϕ1 []split,[; ] ϕ1, ϕ2 ⊢ [in3; ctrl3][{plant3}](ϕ1 ∧ ϕ2) [; ] ϕ1, ϕ2 ⊢ [in3; ctrl3; {plant3}](ϕ1 ∧ ϕ2) ∧l ϕ1 ∧ ϕ2 ⊢ [in3; ctrl3; {plant3}](ϕ1 ∧ ϕ2) def ϕ3 ⊢ [in3; ctrl3; {plant3}] ϕ3 ② continued We have to prove that both, ϕ1 (i. e., ④) and ϕ2 (i. e., ⑤) hold. We illustrate the strategy only for branch ④ because branch ⑤ follows in a similar manner. First, we apply Lemma2, which is possible because plant2 does not bind any variable of ϕ1 (i. e., BV (plant) ∩ V (ϕ1) = ∅, cf. Def. 10), and thus does not influence the truth value of our formula (by bound effect lemma,cf.[99, Lemma 1]). Then we apply the proof rule for non-deterministic choice and get two branches. ... ⑥ ... ⑦ ϕ1, ϕ2 ⊢ [in3; ports1; ctrl1; ports2; ctrl2][{plant1}]ϕ1 [∪],∧r ϕ1, ϕ2 ⊢ [in3; ((ports1; ctrl1; ports2; ctrl2) ∪ ...)][{plant1}]ϕ1 def ϕ1, ϕ2 ⊢ [in3; ctrl3][{plant1}]ϕ1 L.2 ϕ1, ϕ2 ⊢ [in3; ctrl3][{plant1, plant2}]ϕ1 def ϕ1, ϕ2 ⊢ [in3; ctrl3][{plant3}]ϕ1 ④ continued

109 CHAPTER 11. CONCEPT

We will now transform ⑥ until we get (11.16). First, we remove control ctrl2, and reorder in3 so that we can then remove the assignments in2. We reintroduce tests and turn the deterministic assignments of connected ports into non-deterministic ones until they behave like non-connected inputs, and finally get (11.16). The detailed proof steps are explained below and can be cross-referenced using enumeration and the step number in the sequent proof. ∗ (11.16) ϕ1 ⊢ [in1][ctrl1][{plant1}]ϕ1 Wl ϕ1, ϕ2 ⊢ [in1][ctrl1][{plant1}]ϕ1 cf. 8.,L.4,def † ( in ) ϕ1, ϕ2 ⊢ [in1; vj := ∗;?π (vj) ][ctrl1][{plant1}]ϕ1 cf. 7.,L.3 † ( in ) ϕ1, ϕ2 ⊢ [in1; vj := X (vj); ?π (vj) ][ctrl1][{plant1}]ϕ1 cf. 6.,C.1 † ( out ) ϕ1, ϕ2 ⊢ [in1; vj := X (vj); ?π (X (vj)) ][ctrl1][{plant1}]ϕ1 cf. 5.,L.6 † ϕ1, ϕ2 ⊢ [in1;(vj := X (vj); ?ϕ2)][ctrl1][{plant1}]ϕ1 ··· ⑧ cf. 4.,L.5 † ϕ1, ϕ2 ⊢ [in1;(vj := X (vj))][ctrl1][{plant1}]ϕ1 def † ϕ1, ϕ2 ⊢ [in1][ports1][ctrl1][{plant1}]ϕ1 cf. 3.,L.1 † † ϕ1, ϕ2 ⊢ [in1][in2][ports1][ctrl1][{plant1}]ϕ1 [; ] † † ϕ1, ϕ2 ⊢ [in1; in2][ports1][ctrl1][{plant1}]ϕ1 cf. 2.,L.4 ϕ1, ϕ2 ⊢ [in3][ports1][ctrl1][{plant1}]ϕ1 cf. 1.,L.1 ϕ1, ϕ2 ⊢ [in3][ports1][ctrl1][ports2; ctrl2][{plant1}]ϕ1 [; ] ϕ1, ϕ2 ⊢ [in3; ports1; ctrl1; ports2; ctrl2][{plant1}]ϕ1 ⑥ continued In detail, we applied the following lemmas:

1. We apply Lemma1 to get rid of ports2; ctrl2, with

def def def α ≡ ctrl1 , β ≡ ports2; ctrl2 , and A ≡ [{plant1}]ϕ1 ,

in ( global in) since BV (ports2) ⊆ V2 , BV (ctrl2) ⊆ V 2 \ V2 ∪ V2 (and thus global BV (ports2) ∪ BV (ctrl2) ⊆ V 2 \ V ), FV (ctrl1) ⊆ V 1, FV (ϕ1) ⊆ V 1 global and V 1 ∩ V 2 \ V = ∅, and thus FV (α) ∩ BV (β) = ∅ and FV (A) ∩ BV (β) = ∅.

2. We use Lemma4 to reorder the assignments in in3 in a way that the assignments of C1 precede the ones of C2. Note, that these assignments are only the non-connected ports of C1 and C2, while the connected ports are † † still in ports1. Hence, we use in1 and in2 to denote that these assignments are not the full in1 and in2.

3. Using Lemma1 we can remove the assignments from component C2, with def † def † def α ≡ in1, β ≡ in2 and A ≡ [ports1][ctrl1][{plant1}]ϕ1. 4. By multiple applications of Lemma5 (i. e., once for each connected port vj), starting from the rightmost deterministic assignment, we can insert tests for ϕ2 after each deterministic assignment in ports1 without changing the behavior (side conditions verified in ⑧).

110 11.5. PROOFS

5. We can then relax all the tests for ϕ2 using Lemma6 (i. e., once for each out connected port vj) since ϕ2 → π2 (X (vj)), cf. (11.17).

6. We then relax the tests to πin since we know [v := X (v )]πout(X (v )) → vj j j 2 j in π (vj), cf. (11.9)–(11.10), and because all these test are preceded by deterministic assignments vj := X (vj) in ports1 (cf. Corollary1).

7. By multiple applications of Lemma3 we can then replace the deterministic port assignments with non-deterministic assignments (i. e., once for each connected port vj).

8. Finally, by multiple applications of Lemma4 we change the order of the † assignments vj and the assignments in in1 and transform them until we get in1.

It remains to prove the side condition for Lemma5, as used in step 4 above, def † def with α ≡ in1 and F ≡ ϕ2 (cf. ⑧). ∗ ϕ2 ⊢ ϕ2 L.1 † ϕ2 ⊢ [in1]ϕ2 ⑧: Side Condition, Lemma5

The proof for ⑦ works similarly. We first split in3, apply Lemma5, as the resulting side condition still holds (cf. ⑨) and apply Lemma3 before Lemma1, def ( in ) so that its preconditions are fulfilled. With α ≡ vj := ∗;?π (vj); ... ; ctrl1, def def in β ≡ ports2; ctrl2 and A ≡ ϕj, we can apply Lemma1, since BV (ports2) ⊆ V2 , ( global in) BV (ctrl2) ⊆ V 2 \ V2 ∪ V2 (and thus BV (ports2) ∪ BV (ctrl2) ⊆ V 2 \ global ( in ) V ), FV (ctrl1) ⊆ V 1, FV vj := ∗;?π (v1); ... ⊆ V 1, FV (ϕ1) ⊆ V 1 and global V 1 ∩ V 2 \ V = ∅, and thus FV (α) ∩ BV (β) = ∅ and FV (A) ∩ BV (β) = ∅. † Finally, we apply Lemma1 again to remove in2 and are done after reordering. Note that, in some steps below, we abbreviate [ports2; ctrl2] as [···] for space reasons. ∗ (11.16) ϕ1 ⊢ [in1; ctrl1][{plant1}]ϕ1 Wl ϕ1, ϕ2 ⊢ [in1; ctrl1][{plant1}]ϕ1 L.4,def † ( in ) ϕ1, ϕ2 ⊢ [in1][ vj := ∗;?π (vj) ; ctrl1][{plant1}]ϕ1 L.1 † † ( in ) ϕ1, ϕ2 ⊢ [in1][in2][ vj := ∗;?π (vj) ; ctrl1][{plant1}]ϕ1 L.1 † † ( in ) ϕ1, ϕ2 ⊢ [in1][in2][···][ vj := ∗;?π (vj) ; ctrl1][{plant1}]ϕ1 L.3 † † ( in ) ϕ1, ϕ2 ⊢ [in1][in2][···][ vj := X (vj); ?π (vj) ; ctrl1][{plant1}]ϕ1 L.6 † † ϕ1, ϕ2 ⊢ [in1][in2][···][(vj := X (vj); ?ϕ2); ctrl1][{plant1}]ϕ1 ··· ⑨ L.5 † † ϕ1, ϕ2 ⊢ [in1][in2][···][(vj := X (vj)) ; ctrl1][{plant1}]ϕ1 def ϕ1, ϕ2 ⊢ [in3][ports2; ctrl2][ports1; ctrl1][{plant1}]ϕ1 [; ] ϕ1, ϕ2 ⊢ [in3; ports2; ctrl2; ports1; ctrl1][{plant1}]ϕ1 ⑦ continued

111 CHAPTER 11. CONCEPT

The side condition still holds, since we also know ϕ2 → [in2; ctrl2]ϕ2 from 4 (11.16), by reflexivity of {plant2}. We first use Lemma1 to remove the un- † used input ports in1, introduce the test through Lemma5, and weaken the test using Corollary1. Finally, we change the deterministic assignments to non- deterministic ones (cf. Lemma3) and get (11.16) by reordering assignments (cf. Lemma4). The side condition for this application of Lemma5 follows immedi- † ately (cf. ⑧, with in2 and ϕ1). ∗ ϕ1, ϕ2 ⊢ [in2; ctrl2]ϕ2 L.4 † ( in ) ϕ1, ϕ2 ⊢ [in2][ vk := ∗;?π (vk) ; ctrl2]ϕ2 L.3 † ( in ) ϕ1, ϕ2 ⊢ [in2][ vk := X (vk); ?π (vk) ; ctrl2]ϕ2 L.6 † ϕ1, ϕ2 ⊢ [in2][(vk := X (vk); ?ϕ1); ctrl2]ϕ2 L.5 † ϕ1, ϕ2 ⊢ [in2][(vk := X (vk)) ; ctrl2]ϕ2 def † ϕ1, ϕ2 ⊢ [in2][ports2; ctrl2]ϕ2 L.1 † † ϕ1, ϕ2 ⊢ [in1][in2][ports2; ctrl2]ϕ2 ⑨: Side Condition, Lemma5

The proof for ⑤ follows accordingly, using ϕ2 in place of ϕ1. Thus, we [ ∗] conclude φ3 → (in3; ctrl3; {plant3}) ψ3, i. e. (11.14) is valid.

Proof Sketch for any number of Components. So far, we proved Theorem2 for two components. Next, we sketch how the proof can be extended to n ∈ N, n > 2 components. In order to generalize the proof, we have to consider n contracts, one for each component with its interface (Ci,Ii) (for i ∈ {0, . . . , n}).

∗ Cont( Ci,Ii) ≡φi → [(ini; ctrli;(planti)) ]ψi (11.18)

Again, we assume that formula (11.18) was proven for all i, hence there exist invariants ϕi, cf. (11.15)-(11.17). We still need to verify (11.14), except that plant now executes all n plants in parallel and ctrl contains all n! permutations of all control parts, i. e.,

ctrl ≡ (ports1; ctrl1; ports2; ctrl2; ...; portsn; ctrln) ∪

(ports2; ctrl2; ports1; ctrl1; ...; portsn; ctrln) ∪ ...

(portsn; ctrln; ...; ports2; ctrl2, ports1; ctrl1) .

We define our invariant ϕ as the conjunction of all ϕ1. The base case and use case follow immediately from the loop invariants ϕi, analogous to the two- component case. The induction step remains, but can be traced back to the steps carried out to prove the two-component version.

4In dL, continuous evolution is reflexive since differential equations can evolve for time0.

112 11.5. PROOFS

We consider one example branch, where we need to show that ϕ2 holds after each of its runs. ⋀ ϕi ⊢ [in][(ports1; ctrl1; ports2; ctrl2; ...; portsn; ctrln); {plant1}]ϕ2 i We ultimately have to reduce the branch to the loop induction step of component C2, cf. (11.16). Thus, we have to remove the unnecessary plants using Lemma2 and the unnecessary control parts using Lemma1. Again we introduce tests and replace assignments, until we reduced the formula to (11.16). In a similar way, all other branches can be proved.

11.5.2 Proof – Refinement Theorem Finally, it remains to proof Theorem3, repeated below for easy reference. Theorem 3 (Refinement Theorem). Let (C,I) be a component with its interface, with contracts Cont1(C,I) and Cont2(C,I). If Cont1 is valid and Cont2 refines Cont1 under these contracts, then Cont2 is valid. Proof of Theorem3. We know that

( ∗ ) |= Cont1(C,I), i. e., |= φ1 → [(in; ctrl; {plant}) ]ψ1 (11.19)

|= φ2 → φ1 (11.20)

|= ψ1 → ψ2 (11.21) and need to prove

( ∗ ) |= Cont2[C,I], i. e., |= φ2 → [(in; ctrl; {plant}) ]ψ2 (11.22)

We define def HPC ≡ [(in; ctrl; {plant})∗] ... ① ∗ (11.20) φ1 ⊢ [HPC]ψ2 φ2 ⊢ φ1 Wl Wr φ2, φ1 ⊢ [HPC]ψ2 φ2 ⊢ [HPC]ψ2, φ1 cut φ2 ⊢ [HPC]ψ2 →r ⊢ φ2 → [HPC]ψ2 ∗ (11.21) ψ1 ⊢ ψ2 ∗ [] M (11.19) [HPC]ψ1 ⊢ [HPC]ψ2 φ1 ⊢ [HPC]ψ1 Wl Wr φ1, [HPC]ψ1 ⊢ [HPC]ψ2 φ1 ⊢ [HPC]ψ2, [HPC]ψ1 cut φ1 ⊢ [HPC]ψ2 ① continued

113

Chapter 12

Evaluation

In this chapter, we first evaluate our approach using the vehicle cruise control case study, before we conclude this part of the thesis and present open issues.

12.1 Case Study: Vehicle Cruise Control

In this section, we will further elaborate our running example of a vehicle cruise control system, cf. Section 5.2. The overall system requirement is to keep the speed se in a desired range [0,S] at all times, i. e., 0 ≤ se ≤ S → [CruiseControl]0 ≤ se ≤ S. The system is split into two components, cf. tr Fig. 12.1: an engine component adapts speed according to a target speed se tr provided by an autonomous cruise controller component as sac. If the autonomous cruise controller component (Fig. 11.2) provides a valid target speed tr to the engine (i. e., 0 ≤ se ≤ S), the engine component (Fig. 11.1) ensures to keep the actual speed sac in the desired range (i. e., 0 ≤ se ≤ S), thus ensuring the overall system property. Additionally, the engine provides the current speed on an output port that is read by the controller, acting as a feedback loop.

out tr in tr πac (sac) πe (se )

 tr   tr  tr 0 ≤ sac ≤ S 0 ≤ se ≤ S tr sac se tr tr se := sac se ae autonomous engine sac := se sac se 0 ≤ sac ≤ S 0 ≤ se ≤ S       in out πac(sac) πe (se) Composite component: Cruise Control

Figure 12.1: Cruise control composed of the autonomous cruise controller and an engine. Port conditions of connected ports must be compatible.

115 CHAPTER 12. EVALUATION

12.1.1 Cruise Control with Autonomous Controller The detailed components and their interfaces according to Def.7 and Def.8 are listed for easy reference in Model 12.6 and Model 12.7.

Engine. Intuitively, the engine’s task is to regulate the vehicles acceleration, such that a received target speed is not exceeded until the next controller run. Thus, a timer ε restricting the plant runtime is needed, to guarantee the car does not move with the same acceleration forever. Accordingly, in its control part, the engine component first sets a new acceleration in a way that guarantees that the target speed is not exceeded after ε time units. Then it stores the current time, which is necessary to ensure a plant runtime of at most ε time units, cf. (12.1). In the plant the speed is changed according to the selected acceleration and the linear time together with the evolution domain ensure the maximum runtime of ε, cf. (12.2). As motivated in Section 5.2, the engine component has tr one input port se , on which it receives a positive target speed that is bounded by the maximum speed S, cf. (12.3). Furthermore, it has one output port se, which provides the actual current speed, which is guaranteed to be in the interval 0 ≤ se ≤ S, cf. (12.4).

Model 12.6 Component and Interface of the engine

Ce = (ctrle, plante) str − s ctrl ≡ a := e e ; t0 := t (12.1) e e ε e ′ ′ 0 plante ≡ {t = 1, se = ae & t − te ≤ ε} (12.2)

( in in out out) Ie = Ve , πe , Ve , πe in tr in tr tr Ve = {se }, πe (se ) ≡ 0 ≤ se ≤ S (12.3) out out Ve = {se}, πe (se) ≡ 0 ≤ se ≤ S (12.4)

Autonomous Cruise Controller. The main objective of the autonomous cruise controller component is to select a target speed, which is rather close to the current speed, in order to avoid sudden acceleration. Thus, its control part first chooses an arbitrary target speed. Then it checks that the selected tr speed is within the interval 0 ≤ sac ≤ S (i. e., drive forward and at most with the maximum speed possible) and not further from the current speed than δS (i. e., ensure a smooth acceleration), cf. (12.5). In other words, this autonomous cruise controller implementation selects target speeds at random from an interval around the current speed. The interval bound δS influences how drastically the target speed differs from the current speed. The component’s plant is empty. The autonomous cruise controller component has one input port sac, on which

116 12.1. CASE STUDY: VEHICLE CRUISE CONTROL it receives the current target speed, which is assumed to be non-negative and tr bounded by S, cf. (12.7). Furthermore, it has one output port sac, on which it outputs the chosen target speed, which is guaranteed to be within the interval tr 0 ≤ sac ≤ S, cf. (12.8).

Model 12.7 Component and Interface of the autonomous cruise controller

Cac = (ctrlac, plantac) tr ( tr ⏐ tr ⏐ ) ctrlac ≡ sac := ∗;? 0 ≤ sac ≤ S ∧ ⏐sac − sac⏐ ≤ δS (12.5)

plantac ≡ {} (12.6)

( in in out out) Iac = Vac, πac, Vac , πac in in Vac = {sac}, πac(sac) ≡ 0 ≤ sac ≤ S (12.7) out tr out tr tr Vac = {sac}, πac (sac) ≡ 0 ≤ sac ≤ S (12.8)

Contracts. Following Def.9, we specify a contracts for each component, which consists of initial conditions φ, cf. (12.9)–(12.10), safety conditions ψsafe, cf. (12.11), and the output port conditions, cf. (12.4) and (12.8). Initially, maximum speed S > 0 and cycle time ε > 0 must be positive (i. e., allows the car to move and guarantees that both—controller and plant—can eventually run). tr Additionally, the autonomous cruise controller initializes sac = 0 (i. e., target velocity is initialized to 0, and has to be set by the controller) and δS > 0 (i. e., must be positive to allow any change in speed), cf. (12.9). The engine restricts the initial speed to 0 ≤ se ≤ S (i. e., car either stands still or moves forward with a valid speed), cf. (12.10). Since the autonomous cruise controller component safe has no additional safety property, the sole safety property ψe restricts speed of the engine component to the interval 0 ≤ se ≤ S, cf. (12.11).

φe ≡ 0 ≤ se ≤ S ∧ ε > 0 ∧ S > 0 (12.9) tr φac ≡ sac = 0 ∧ ε > 0 ∧ S > 0 ∧ δS > 0 (12.10) safe ψe ≡ 0 ≤ se ≤ S (12.11) The set of global variables follows by Def.6:

Vglobal = {ε, S} .

1 Composition. After verifying that both contracts, i. e., Cont( Cac,Iac) and Cont( Ce,Ie), hold, we want to compose the components to get the overall sys- ( tr tr ) tem, using the mapping function X = sac ↦→ se, se ↦→ sac (cf. Fig. 11.3).

1All proofs were done in KeYmaera X [42].

117 CHAPTER 12. EVALUATION

Therefore, we have to check the compatibility proof obligations for both connected ports. As we connect the output port of the autonomous cruise controller providing the target speed, to the respective input port of the engine component, we have to verify CPO( Ie,Iac), cf. (12.12). Since we connect the actual speed as provided by the engine to the respective input port of the autonomous cruise controller, we furthermore have to verify CPO( Iac,Ie), cf. (12.13). Then the overall system property directly follows from the contract of the engine component.

tr tr ( out tr in tr ) CPO( Ie,Iac) ≡ [se := sac] πac (sac) → πe (se ) tr tr ( tr tr ) ≡ [se := sac] 0 ≤ sac ≤ S → 0 ≤ se ≤ S (12.12) ( out in ) CPO( Iac,Ie) ≡ [sac := se] πe (se) → πac(sac)

≡ [sac := se] (0 ≤ se ≤ S → 0 ≤ sac ≤ S) (12.13)

Summary. Splitting a system into components has the potential to reduce the model complexity considerably, since a component needs to know neither about the differential equation systems of other components, nor about their control choices. In combined models, we have to analyze all the possible permutations of control choices, while in the component-based approach, by Theorem2, we can guarantee correctness for all possible sequential orderings, without the proof effort entailed by listing them explicitly. The first part ofTable 12.1 (i. e., “Au- tonomous”) compares the proof effort of the component based version tothe monolithic version, when using an autonomous controller. Although, the proof effort is relatively low, the combined number of proof steps is evidently smaller when using our approach, rather than a monolithic model.

12.1.2 Cruise Control with Guided Controller

out tr πout (suser) π (s ) in tr gc gc gc gc πe (se )          0 ≤ suser ≤ S 0 ≤ str ≤ S tr gc user tr gc 0 ≤ se ≤ S tr sgc sgc se tr tr se := sgc se ae

guided sgc := se engine wgc sgc se (wgc = 1 ∨ wgc = 0) 0 ≤ sgc ≤ S 0 ≤ se ≤ S          in in πout (s ) πgc (wgc) πgc (sgc) e e Composite component: Guided Cruise Control

Figure 12.2: Cruise control composed of the guided cruise controller and an engine. Port conditions of connected ports must be compatible. Unconnected ports remain open.

118 12.1. CASE STUDY: VEHICLE CRUISE CONTROL

The benefit of component-based verification becomes even more apparent when replacing components in a system, cf. Fig. 12.2. For example, we can easily replace the autonomous cruise controller from Model 12.7 with a more sophisticated guided cruise controller, cf. Model 12.8.

user Guided Cruise Controller. The guided controller receives a user speed sgc on an additional input port, which represents a user suggestion for the new target speed, cf. (12.18). In order to keep the acceleration at a smooth level, the guided cruise controller checks if the user-chosen speed is close to the current speed and uses an additional output port to issue warnings if not, cf. (12.19). More precisely, if this user speed is close enough to the current actual speed, it is chosen as target speed and no warning is issued (i. e., w = 0), cf. (12.16). Otherwise, if the user speed is too high or low, the target speed is modified and a warning is issued (i. e., w = 1). If the speed is too high, the guided controller uses the current actual speed increased by δS as target speed, cf. (12.14), and if the speed is too low, the guided controller uses the current actual speed decreased by δS as target speed, cf. (12.15). The guided cruise controller—like the autonomous cruise controller—has an empty plant, cf. (12.17).

Model 12.8 Component and Interface of the guided cruise controller

( ) Cgc = ctrlgc, plantgc (( ( user ) tr ) ctrlgc ≡ ? sgc − sgc ≥ δS ; sgc := sgc + δS; wgc := 1 ∪ (12.14) ( ( user ) tr ) ? sgc − sgc ≥ δS ; s := sgc − δS; wgc := 1 ∪ (12.15) ( (⏐ user ⏐ ) tr user )) ? ⏐sgc − sgc⏐ < δS ; sgc := sgc ; w := 0 (12.16)

plantgc ≡ {} (12.17)

( in in out out) Igc = Vgc, πgc, Vgc , πgc in user Vgc ≡ {sgc, sgc }, in user user πgc ≡ {(sgc ↦→ 0 ≤ sgc ≤ S), (sgc ↦→ 0 ≤ sgc ≤ S)} (12.18) out tr Vgc ≡ {sgc, wgc}, out tr tr πgc ≡ {(sgc ↦→ 0 ≤ sgc ≤ S), (wgc ↦→ (wgc = 1 ∨ wgc = 0)} (12.19)

Contract. Again we specify a contract for the component following Def.9. The contract consists of an initial condition φ, cf. (12.20), and the output port conditions, cf. (12.19). The controller has no additional safety condition. Like the autonomous cruise controller (cf. Section 12.1.1), the guided cruise controller initializes the maximum speed S > 0, the cycle time ε > 0, the target velocity

119 CHAPTER 12. EVALUATION

tr sgc = 0 and the maximum velocity delta δS > 0. Furthermore, it restricts the initial actual speed to the usual interval 0 ≤ sgc ≤ S. The initial user speed suggestion is assumed to coincide with the actual speed for the sake of simplicity user (is changed in the controller) sgc = sgc. Accordingly, initially the warning flag is off wgc = 0.

tr user φgc ≡ sgc = 0 ∧ ε > 0 ∧ S > 0 ∧ δS > 0 ∧ 0 ≤ sgc ≤ S ∧ sgc = sgc (12.20) Again, the set of global variables follows by Def.6:

global V = {ε, S, δS} .

Composition. After verifying the user guided cruise control component, we only have to re-check the compatibility proof obligations. In a monolithic model, in contrast, the whole system including the engine component must be re-verified.

Table 12.1: Case study summary

Model Proof Description Dim. Steps Branches Time [s] Engine component 5 47 4 0.19 Autonomous cruise controller com- 3 55 4 0.12 ponent Compatibility proof obligation 2 3 1 0.02 CPO( Iac,Ie) Compatibility proof obligation 2 3 1 0.02

Autonomous CPO( Ie,Iac) Sum Component Effort 108 10 0.35 Monolithic system (e; ac) ∪ (ac; e) 7 170 11 0.83 Engine component (proof reused) – – – Guided cruise controller component 4 435 17 1.00 Compatibility proof obligation 2 3 1 0.02 CPO( Igc,Ie) Compatibility proof obligation 2 3 1 0.02 Guided CPO( Ie,Igc) Sum Component Effort 861 50 2.40 Monolithic system (e; gc) ∪ (gc; e) 9 955 53 7.71

Summary. In this case, the advantage of our approach is even more obvious, as the second part of Table 12.1 (cf. “Guided”) shows. Note, that in the monolithic system using the guided cruise controller two ports remain unconnected (i. e., the input port providing the desired speed and the output port issuing

120 12.2. CONCLUSION AND OPEN ISSUES warnings), which can, for instance, be connected to a user-interface, where a driver chooses a speed and receives a warning if the difference is too high. Despite those unconnected ports, the model can be verified–a suitable user- interface component can be connected later on, if the respective port conditions are fulfilled. The example furthermore highlights how our approach can increase reusability, as the engine component can be reused without re-verification. It also increases maintainability, as a change in a single component only requires re-verification of the changed component.

12.2 Conclusion and Open Issues

In this part of the thesis, we presented an approach for component-based modeling and verification of CPS that (i) splits a CPS into components, (ii) verifies a global contract for each of these components and (iii) composes component instances in a way that transfers the component contracts to a composite contract. We have demonstrated that our approach can reduce the verification effort and increase reusability and maintainability, using an example of a vehicle cruise control system. So far, our approach is limited to global properties that are stated relative to the initial system state. Port conditions are only allowed to mention global variables and the port variable itself, which prevents conditions on the change of a port since the last measurement (e. g., how far has a vehicle moved since the beginning rather than how far has it moved since the last measurement). This restriction can be removed with ports that remember their previous value and relate measurements over time, which we will introduce in the subsequent part of the thesis. Fig. 12.3 summarizes the capabilities of the approach presented in this part of the thesis and the improvements compared to the domain-specific approach of PartII. Components now have a unified structure and interfaces are no longer restricted to inflows and outflows. However, multi-ports are still not supported. Following our classification of contracts from Section 3.1.3, the approach supports global contracts only. Composition is, again following Section 3.1.3, limited to instantaneous and lossless communication, but no longer restricted to traffic flow only.

121 CHAPTER 12. EVALUATION

 supported  not supported Part 1 Part 2 Part 3 Traffic Contracts Global Contracts Change/Delay Components unified   Interfaces unified   ports (flow only)  multi-ports   Contracts global (flow only)  change   delay   Composition instantaneous (flow only)  delayed   lossless (flow only)  lossy  

 supported  not supported

Figure 12.3: Capabilities of the approach with regard to the requirements presented in Section 3.3.

122 Part IV

Generic Approach with Change- and Delay Contracts

123

Chapter 13

Introduction

In the previous parts, we first introduced a component-based modeling and verification approach geared to traffic flow models (cf.PartII), which we then lifted to more general CPS with global contracts (cf. PartIII). Even though these approaches are applicable to a variety of systems (e. g., our first two motivational examples, cf. Section 5.1–Section 5.2), they restrict conditions in contracts to pick from constant ranges (e. g., speed of a car is non-negative and at most some maximum speed). Such global contracts require substantial static independence of the components, and thus, can only show coarse safety properties when components make decisions based on measurements about the behavior of other components. To verify more liberal properties, we need contracts that quantify how values change over time.

2 표 푥표 Robot

푥 0 푥푟 1 푥푟 1 푥 0 푥 2 푟

푥표 표 푥푟 Obstacle Obstacle

Figure 13.1: Global Contracts (robot and obstacle move in fixed disjoint areas): The obstacle stays within a fixed area, while the robot guarantees to stay out i i of that same area. Robot position xr and obstacle position xo are visualized at times i ∈ {0, 1, 2}.

For instance, consider the tele-operated robot from Section 5.3. Using global contracts, the robot and the obstacle must remain in constant areas for all times, e. g., a robot in the kitchen will not collide with obstacles in the back yard. This is visualized in Fig. 13.1, where the obstacle always moves within its globally fixed area. If the robot guarantees to stay outside this area, the system canbe modeled and verified using the approach from PartIII.

125 CHAPTER 13. INTRODUCTION

A more liberal property is visualized in Fig. 13.2. The robot measures the obstacle’s position and calculates an area around this position, in which the obstacle might move until the next measurement. As long as the robot stays far enough away from this region, it cannot crash into the obstacle. The area is re-calculated after every measurement.

1 2 푥푟

표 푥 푟 Robot 푥 0 푥표 1

푥표 푥

2 푟 푥표 Obstacle Obstacle 0 푥푟

Figure 13.2: Delay Contracts (robot considers the obstacle’s current position, but ignores earlier positions): The lighter red circles represent the areas, in 0 1 which the obstacle might have moved starting at xo and xo respectively. The 2 red circle represents the area, in which the obstacle might move starting at xo. While the robot cannot move into the obstacle’s current area of movement (i. e., red circle), it is allowed to move into previous areas of movement (i. e., light i i red circles). Robot position xr and obstacle position xo are visualized at times i ∈ {0, 1, 2}.

Fig. 13.2 shows that the robot can move to positions, which were prohibited earlier, as long as it stays out of the area around the obstacle’s current position 3 (e. g., robot’s position xr is in the area around the obstacle’s earlier position 1 xo). To allow components with such behavior, however, we need contracts that allow relating the new value of a port with its previous value and the time that has passed since the last value was transferred.

Therefore, in this part, we extend components and their interfaces with concepts to specify the magnitude of change of a variable between two states (e. g., current speed is at most twice the previous speed at the last control). We further capture the delay between the states to measure the rate of change (e. g., current speed is previous speed increased by accelerating for some time ε). To- gether, change- and delay contracts make the hybrid (continuous-time) behavior of one component available as a discrete-time measurement abstraction in other components. The isolated hybrid behavior of a component in question is now analyzed with respect to discrete-time abstractions of all other components in the system. We show that this approach makes safety proofs about components transfer to the joint hybrid behavior of the monolithic system built from these components, given that each component provably satisfies its contract.

126 To illustrate the concepts, we use the tele-operated robot with collision avoidance, as described in Section 5.3, as a running example. The system consists of three components, cf. Fig. 13.3:

1. The remote control (RC) component periodically issues a new speed advisory d on its single output port.

2. The obstacle component moves with arbitrary speed so limited to at most S and provides its current position on its single output port po (e. g., a wall or a moving person).

3. The robot component reads speed advice on input port dˆ and follows the speed advice, if the obstacle position measured on input portp ˆo is at a safe distance.

Remote Control Component

ctrl ≡ 푑 ∶= ∗; ? 푑 − 푑− ≤ D plant ≡ 푠푘푖푝 Robot Component 푑 ↦ 푑መ cp ≡ 푠푘푖푝 መ ctrt ≡ ? Safe 푥ො표 ; 푠푟 ∶= 푑 ∪ ? ¬Safe(푥ො표) ; 푠푟 ∶= 0 Obstacle Component plant ≡ 푥 ′ = 푠 & 푡 − 푡− ≤ 휀 푥 ↦ 푥ො 푟 푟 표 표 cp ≡ 푠푘푖푝 ctrl ≡ 푠표 ∶=∗; ? 0 ≤ 푠표 ≤ 푆 plant ≡ 푥표′ = 푠표 cp ≡ 푠푘푖푝

Figure 13.3: Running Example: Robot receives speed advice and obstacle position, and has to avoid crashes. Note that Safe (ˆxo) determines, if it is safe for the robot to move depending on the measured obstacle position.

The RC is a (software) component without physics that issues speed advice to the robot. Two such consecutive speed advisories from the RC should be at most D apart to avoid sudden acceleration (i. e., |d − d−| ≤ D). The obstacle chooses a new non-negative speed but at most S and moves according to its plant. The robot measures the obstacle’s position. If the distance is safe, the robot chooses the speed suggested by the RC; otherwise, the robot stops. The overall system target is to keep the robot from actively colliding with the obstacle, i. e., the robot’s and the obstacle’s position must not coincide when safe the robot is driving. Formally, this property can be written as ψsys ≡ sr > 0 → po ̸= pr. Formal definitions of these three components, their interfaces, and the respective contracts, will be introduced step-by-step along the definitions in subsequent sections.

127 CHAPTER 13. INTRODUCTION

The remainder of this part is structured as follows: • Similar as in the previous part, in Chapter 14 we will introduce the necessary theoretical background for our approach. This comprises specification of (i) components, interfaces and a notion of time, cf. Section 14.1, (ii) change- and delay contracts, cf. Section 14.2, and (iii) a composition operation for compatible components, cf. Section 14.3. In Section 14.5 we conclude the chapter by proving that our composition operation transfers verification results from component- to system level. • In Chapter 15, we present an implementation of our approach, cf. Sec- tion 15.1, and use it to so solve a series of case studies, which highlight the advantages of our approach when compared to a monolithic approach, cf. Section 15.2. Finally, we conclude this part of the thesis in Section 15.3. All contents in this part of the thesis are based on our previous work “Change and Delay Contracts for Hybrid System Component Verification” as published in “Fundamental Approaches to Software Engineering - 20th International Con- ference”, cf. [84], respectively on the associated report, cf. [80].

128 Chapter 14

Concept

In this chapter, we again introduce notions of components, interfaces, contracts, compatibility and composition, because the notions required for the generic approach with change- and delay contracts we introduce in this part differ slightly from the previous notions. Throughout the chapter, we will highlight the differences between the definitions in this part and the definitions in the previous parts.

14.1 Specification: Components and Interfaces

Change components and interfaces specify what a component assumes about the magnitude of change at each of its inputs, and what it guarantees about the magnitude of change on its outputs. To make such conditions expressible, every component will use additional variables to store both the current and the previous value communicated along a port. These so-called ∆-ports can be used to model jumps in discrete control, and for measurement of physical behavior if the rate of change is irrelevant.

14.1.1 Components Components may consist of a discrete control part and a continuous plant, cf. Def. 14. However, Def. 14 does not prescribe how control and plant are composed; the composition to a hybrid program is specified later in Def. 19. We allow components to be hierarchically composed from sub-components, so components list the internally connected ports of sub-components.

Definition 14 (Component). A component C∆ = (ctrl, plant, ports) is defined as follows:

• ctrl is the discrete part without differential equations,

′ ′ • plant is a differential equation (x1 = θ1, . . . , xn = θn&H) for n ∈ N,

129 CHAPTER 14. CONCEPT

• ports are deterministic assignments connecting ports of sub-components, and

def • Vi = V(ctrl) ∪ V(plant) ∪ V(ports), correspondingly for BV (Ci) .

∆ Remark 6. Note that we use Vi short for V(Ci ), i. e., the set of all variables ∆ of a component Ci . If a component is atomic, i. e., not composed from sub-components, the port connections ports are empty (skip statement of no effect). The variables ofa component are the variables of its controller, plant, and all its sub-components. We aim at components that can be analyzed in isolation and that communicate solely through ports. Global shared constants (read-only and thus not used for communication purposes) are included for convenience to share common knowledge for all components in a single place.

∆ ∆ Definition 15 (Variable Restrictions). A system of components C1 , ..., Cn is well-defined if

• global variables V global are read-only and shared by all components

global V ∩ BV (Ci) = ∅ ,

• no variables of other components can be read or written

global ∀i ̸= j . Vi ∩ Vj ⊆ V .

Def. 15 implies that each component can access all global variables. However, if a global variable is not needed by a component, it can be avoided.

Remark 7. In contrast to the components introduced in Part III (cf. Def.7), Def. 14 identifies internally connected ports (i. e., during an earlier composition) as part of the component definition. The reason lies in the different handling of connected ports when composing components and will become apparent later in this chapter (cf. Def. 20). Intuitively, while in Part III the internally connected ports became a part of the respective control part and were executed at the end of these control parts, here they remain separate and are executed at the end of the composite program.

In order to allow integration of additional knowledge about the global constants, we introduce a global property (cf. Def. 16), which holds for each component and—since it may only reason about global constants—is invariant throughout the system.

Definition 16 (Global Property). A global property Ω is a dL formula with V (Ω) ⊆ V global.

130 14.1. SPECIFICATION: COMPONENTS AND INTERFACES

Global properties are especially useful when a library of components is used. In that case, the components do not necessarily use the same global constants, but relate them to one another using global properties. For instance, one component might know that x ≤ X, while a second knows that x ≤ Y , where X and Y are global constants. While x ≤ X does not necessarily imply x ≤ Y , global knowledge can relate X ≤ Y and thus ensure x ≤ X ∧ X ≤ Y → x ≤ Y . Parts of the global property, which are not needed for the verification of a certain formula can be omitted (i. e., if a component does not use a global variable, all associated parts of the global property can be avoided).

14.1.2 Example: Components

Consider the robot collision avoidance system. Its global variables are the maximum obstacle speed S and the maximum difference D between two speed advisories, i. e., Vglobal = {S, D}. They can neither be bound in control nor plant of any component, cf. Def. 15. The respective global property includes additional information about these global constants, i. e., both upper bounds must not be negative,

Ω ≡ S ≥ 0 ∧ D ≥ 0 . (14.1)

∆ RC. Model 14.9 describes the RC component Crc, cf. (14.2). Its controller ctrlrc picks a new speed advisory d and ensures that it is not too far from the previous speed advice d−, cf. (14.3). Since the RC is an atomic component without any physical characteristics, plantrc and portsrc are empty, cf. (14.4)– (14.5).

Model 14.9 Remote Control Component

∆ Crc = (ctrlrc, plantrc, portsrc) (14.2) ⏐ −⏐ ctrlrc ≡ d := ∗;? ⏐d − d ⏐ ≤ D; (14.3)

plantrc ≡ skip (14.4)

portsrc ≡ skip (14.5)

∆ Obstacle. The obstacle component Co (cf. Model 14.10) moves with an arbitrary but limited speed. Thus, the obstacle controller chooses a new non- negative speed so limited by the maximum speed S, cf. (14.7). The obstacle plant adapts the obstacle position according to the chosen speed (i. e., the obstacle moves), cf. (14.8). The internally connected ports portso are empty, since the obstacle is an atomic component, cf. (14.9).

131 CHAPTER 14. CONCEPT

Model 14.10 Obstacle Component

∆ Co = (ctrlo, planto, portso) (14.6) ( ) ctrlo ≡ so := ∗;? 0 ≤ so ≤ S ; (14.7) ′ planto ≡ po = so (14.8)

portso ≡ skip (14.9)

∆ Robot. The robot component Cr (cf. Model 14.11) should follow speed advice from the RC and measures the position of the obstacle to avoid collisions. The duration ε is the maximum time that the robot plant can run. This ensures that the robot’s controller ctrlr runs regularly. The robot controller first chooses a new speed. If the obstacle is far enough away, i. e., the distancep ˆo − pr between obstacle and robot is greater than the maximum distance S · ε that the obstacle can move, plus the maximum distance dˆ· ε the robot itself can move, the robot follows the speed advice of the RC, cf. (14.11). Otherwise, it stops, cf. (14.12). This behavior is visualized in Fig. 14.1. The robot’s plant (14.13) adapts the robot’s position according to the chosen speed (i. e., the robot moves). The internally connected ports portsr (14.14) are empty since the robot is an atomic component.

Model 14.11 Robot Component

∆ Cr = (ctrlr , plantr , portsr ) (14.10) ( ( ˆ ) ) ˆ ctrlr ≡ ? pˆo − pr > d + S · ε ; sr := d; (14.11) ( ( ˆ ) ) ∪ ? pˆo − pr ≤ d + S · ε ; sr := 0; (14.12) ′ plantr ≡ pr = sr (14.13)

portsr ≡ skip (14.14)

14.1.3 Interfaces An interface defines how a component may interact with other components through its ports, what assumptions the component makes about its inputs, and what guarantees it provides for its outputs, see Def. 17. As the interfaces in this section contain ∆-ports that store previous values and thus allow reasoning about the magnitude and rate of change on a port, we label them I∆ to distinguish them from the interfaces I of PartIII. Definition 17 (Admissible Interface). An admissible interface I∆ for a com- ( ) ponent C∆ is a tuple I∆ = V in, πin, V out, πout, V δ, V −, pre with

132 14.1. SPECIFICATION: COMPONENTS AND INTERFACES

풅 ⋅ 휺 풙풐 − 풙풓 풅 ⋅ 휺 풙풐 − 풙풓 푺 ⋅ 휺 푺 ⋅ 휺

풙풓 풙풐 풙풓 풙풐

풙풐 − 풙풓 > 풅 ⋅ 휺 + 푺 ⋅ 휺 풙풐 − 풙풓 ≤ 풅 ⋅ 휺 + 푺 ⋅ 휺 (a) The robot is safe to move as the areas (b) The robot stops as overlapping areas do not overlap. indicate imminent collision.

Figure 14.1: The robot only accepts the speed suggestion if it is safe: The green circle represents the area that the robot might reach until the next controller run (i. e., within ε time units) with the suggested speed d. The red circle represents the area that the obstacle might reach during the same interval ε with maximum speed S.

• V in ⊆ V and V out ⊆ V with V in ∩ V out = ∅ are disjoint sets of input- and output variables, • V in ∩ BV (C∆) = ∅, i. e., input variables may not be bound in the component, • πin : V in → dL is a function specifying exactly one formula per input variable (i. e., input port), representing input requirements and assumptions, • πout : V out → dL specifies output guarantees for output ports, •∀ v ∈ V in : V (πin(v)) ⊆ (V \ (V in ∪ V out))∪{v} such that input formulas are local to their port, • V δ = V δp ∪ V δi ⊆ V is a set of ∆-ports of unconnected public V δp ⊆ V in ∪ V out, and connected internal V δi, with V δi ∩ (V in ∪ V out) = ∅, so V δp ∩ V δi = ∅, • V − ⊆ V with V − ∩ BV (C) = ∅ is a read-only set of variables storing the previous values of ∆-ports, disjoint from other interface variables V − ∩ (V in ∪ V out ∪ V δ) = ∅, • pre : V δ → V − is a bijective function, assigning one variable to each ∆-port to store its previous value.

Input assumptions are local to their port, i. e., no input formula can mention other input variables (which lets us reshuffle port ordering) nor any output variables (which prevents cyclic port definitions). Not all ports of a component need to be connected to other components; unconnected ports simply remain input/output ports of the resulting composite system. Note that, while Def. 17 does not explicitly restricts the use of variables in the output predicate, use of any variables except the respective output variable leads to ports, which can never be compatible with any input port, cf. Def. 21.

133 CHAPTER 14. CONCEPT

Multi-ports. The definition is accordingly for vector-valued ports that share multiple variables along a single port, provided that each variable is part of exactly one vectorial port. This leads to multi-ports, which transfer the values of multiple variables, but have a single joint output guarantee/input assumption over the variables in the multi-port vector. Remark 8. Def. 17 extends the previous interface definition of Part III (cf. Def.8), with additional variables to store previous values, which can also be used in input assumptions and output guarantees.

14.1.4 Example: Interfaces Considering our example, we have to define admissible interfaces for the three ∆ ∆ components, i. e. the RC interface Irc, the obstacle interface Io and the robot ∆ interface Ir . We start with the RC interface. in The RC controller interface in Model 14.12 has no input ports, so Vrc and in πrc are empty, cf. (14.16)-(14.17). The single output port d provides the speed advice, which is guaranteed to be no further than D from the previous advice, out cf. (14.18)-(14.19). The output property πrc limits the magnitude of change between the previous advice d− and the current advice d, so the port d is a ∆-port with previous value d−, cf. (14.20)-(14.22).

Model 14.12 Remote Control Interface

∆ ( in in out out δ − ) Irc = Vrc , πrc , Vrc , πrc , Vrc, Vrc, prerc (14.15) in Vrc = {} (14.16) in πrc = () (14.17) out Vrc = {d} (14.18) out ( ⏐ −⏐ ) πrc = d ↦→ ⏐d − d ⏐ ≤ D (14.19) δ Vrc = {d} (14.20) − − Vrc = {d } (14.21) ( −) prerc = d ↦→ d (14.22)

14.1.5 Time In a monolithic hybrid program with a combined plant for all components, time passes synchronously for all components and their ODEs evolve for the same amount of time. When split into separate components, the ODEs are split into separate plants too, thereby losing the connection of evolving for identical amounts of time. From the viewpoint of a single component, other plants reduce to discrete abstractions through input assumptions on ∆-ports. These input assumptions are phrased in terms of worst-case behavior (e. g.,

134 14.1. SPECIFICATION: COMPONENTS AND INTERFACES from the viewpoint of the robot, the obstacle may jump at most distance S · ε between measurements because it lost a precise model). The robot’s ODE, however, still runs for some arbitrary time that might be less than ε, which makes the measurements and the continuous behavior of the robot drift (i. e., robot and obstacle appear to move for different durations). To unify the timing for all components of a system, we introduce a globally synchronized time t and a global variable t− to store the time before each run of plant. Both are special global variables, which cannot be bound by the user, but only—unlike global constants, which can never be bound—on designated locations specified through the contract, cf. Def. 18.

∆ Definition 18 (Time). Let Ci , i ∈ N be any number of components with variables according to Def. 15. When working with delay contracts, we assume

• the global system time t changes with constant rate t′ = 1,

• t− is the plant time at the start of the current plant run,

− − •{ t, t } ∩ BV (Ci) = ∅, thus clocks t, t are not written by a component.

14.1.6 Example: Interfaces and Time We continue our running example with the obstacle’s and the robot’s interfaces, which use the introduced global time in some of their input and output properties.

Obstacle. The obstacle interface in Model 14.13 contains no input ports, cf. (14.24)-(14.25). The single output port provides the current obstacle position, which is guaranteed to be in an interval of size S · (t − t−) centered at the obstacle’s previous position, cf. (14.26)-(14.27). The output property (14.28) of − po captures the rate of change between the previous value po and the current − value po by considering global time t. The previous value of po is kept in po , cf. (14.29)-(14.30).

Robot. The robot interface in Model 14.14 has two input ports, cf. (14.32)– (14.33). On input portp ô it receives the obstacle’s current position, which is guaranteed to be within the area around the previous measured obstacle position. This property describes the rate of change of the obstacle position measurement, instead of a fixed global region (cf. Fig. 13.1 and Fig. 13.2). Thus, a global contract as in PartIII would not suffice here. On input port dît receives a speed advice, which is guaranteed to be close to the previous value. This property describes the magnitude of change in speed advice. The robot has no output ports, cf. (14.34)-(14.35). As the properties of both input ports reason about the magnitude of change, they are ∆-ports, cf. (14.36)-(14.38). However, onlyp ô considers the rate of chance, using time in its input assumption.

135 CHAPTER 14. CONCEPT

Model 14.13 Obstacle Interface

∆ ( in in out out δ − ) Io = Vo , πo , Vo , πo , Vo, Vo , preo (14.23) in Vo = {} (14.24) in πo = () (14.25) out Vo = {po} (14.26) out ( ⏐ −⏐ ( −)) πo = po ↦→ ⏐po − po ⏐ ≤ S · t − t (14.27) δ Vo = {po} (14.28) − − Vo = {po } (14.29) ( −) preo = po ↦→ po (14.30)

Model 14.14 Robot Interface

∆ ( in in out out δ − ) Ir = Vr , πr , Vr , πr , Vr , Vr , prer (14.31) in ˆ Vr = {pô, d} (14.32) ( ⏐ ⏐ ) in ⏐ −⏐ ( −) ˆ ⏐ ˆ ˆ−⏐ πr = pô ↦→ ⏐pô − pô ⏐ ≤ S · t − t , d ↦→ ⏐d − d ⏐ ≤ D (14.33) out Vr = {} (14.34) out πr = () (14.35) δ ˆ Vr = {pô, d} (14.36) − − ˆ− Vr = {pô , d } (14.37) ( − ˆ ˆ−) prer = pô ↦→ po , d ↦→ d (14.38)

136 14.2. PROOF OBLIGATIONS: CONTRACT COMPLIANCE

14.2 Proof Obligations: Contract Compliance

Contract compliance ties together components and interfaces by showing that a component guarantees the output changes that its interface specifies under the input assumptions made in the interface. Contract compliance further shows a local safety property, which describes the component’s desired safe states. For example, a safety property of a robot might require that the robot will not drive too close to the last measured position of the obstacle. Together with the obstacle’s output guarantee of not moving too far from its previous position, the local safety property implies a system-wide safety property (e. g., robot and obstacle will not collide, cf. Fig. 5.6), since we know that a measurement previously reflected the real position. Contract compliance can be verified using KeYmaera X [42]. In order to make guarantees about the behavior of a composed system we use the synchronized system time t to measure the duration (t − t−) between controller runs in contract compliance proof obligations, cf. Def. 19. Definition 19 (Contract Compliance). Let C∆ be a component with its admissible interface I∆ (cf. Def. 17). Let formula φ describe initial states of C∆ and formula ψsafe the safe states, both over the component variables V. Ω is the out ⋀ out global property of the system. The output guarantees Π ≡ v∈V out π (v) extend safety to ψsafe ∧ Πout. Change contract compliance CC(C∆, I∆) of C∆ with I∆ is defined as the dL formula:

def CC(C∆, I∆) ≡ (Ω ∧ φ) → [(∆; ctrl; plant; in; ports)∗](ψsafe ∧ Πout) and delay contract compliance DC(C∆, I∆) is defined as the dL formula:

def Cont(C∆, I∆) ≡ ∗ (t = t− ∧ Ω ∧ φ) → [(∆; ctrl; t− := t;(t′ = 1, plant) ; in; ports) ](ψsafe ∧ Πout) where def in ≡ (v := ∗;?πin(v)) for all v ∈ V in , are (vectorial) assignments to input ports satisfying input assumptions πin(v) and ∆ are (vectorial) assignments storing previous values of ∆-ports:

def ∆ ≡ pre(v) := v for all v ∈ V δ .

The order of the assignments in both in and ∆ is irrelevant because the assignments are over disjoint variables and πin(v) are local to their port, cf. Def. 17. The function pre can be used throughout the component to read the previous value of a ∆-port. Remark 9. This notion of contracts crucially changes compared to Part III (cf. Def.9) with respect to where ports are read and how change is modeled: reading

137 CHAPTER 14. CONCEPT from input ports at the beginning of a component’s loop body (i. e., before the controller runs) as in the previous part may seem intuitive, but it would require severe restrictions to a component’s plant in order to make inputs and plant agree on duration. Instead, we prepare the next loop iteration at the end of the loop body (i. e., after plant), so that actual plant duration can be considered for computing the next input values.

14.2.1 Example: Change Contract RC. We continue the collision avoidance system with a change contract (14.41) according to Def. 19 for the RC from Fig. 13.3, since the output property relates the current value d to the previous value d−. Synchronization is irrelevant, because the RC has no physical part (i. e., plantrc ≡ skip). The precondition for the RC bootstraps the output port’s previous value d− from the current demanded speed d, cf. (14.39). The relevant part of the global property specifies the bound for the global variable D, cf. (14.1). The property for S can be avoided here, as S is not used in the RC. Here, ψrc comprises only the output port guarantees of the RC, since the RC has no additional safety property, cf. (14.40). Thus, the RC guarantees that consecutive speed advisories are at most D apart.

− φrc ≡ d = d (14.39) ⏐ −⏐ ψrc ≡ ⏐d − d ⏐ ≤ D (14.40) The resulting change contract per Def. 19 for the RC was verified using KeYmaera X, cf. (14.41). We thus know that the component is safe and complies with its interface. Compared to contracts with fixed ranges as in PartII and PartIII, we do not have to assume a global limit for demanded speeds d, but consider the previous advice d− as a reference value when calculating the next speed advice.

∆rc ctrlrc plantrc inrc − d  ⏐  −⏐        (Ω ∧ φrc) →[(d := ; d := ∗;? ⏐d − d ⏐ ≤ D; skip ; skip; ∗ (⏐ −⏐ ) skip) ] ⏐d − d ⏐ ≤ D (14.41)       ports out rc Πrc

14.2.2 Example: Delay Contract Obstacle. Change in obstacle position depends on speed and the time passed ′ in the ODE planto ≡ po = so, cf. (14.8). Hence, we follow Def. 19 to specify the obstacle delay contract in (14.44). The precondition for the obstacle bootstraps the output port’s previous value − po from the position po and initializes the obstacle speed to 0, cf. (14.42). The relevant part of the global property specifies the bound for the global variable

138 14.2. PROOF OBLIGATIONS: CONTRACT COMPLIANCE

S, cf. (14.1). Here, ψo again comprises only the output port guarantees of the obstacle, since our liberal notion of obstacles should not assume obstacles to cooperate for safety, cf. (14.43).

− φo ≡ po = po ∧ so = 0 (14.42) ⏐ −⏐ ( −) ψo ≡ ⏐po − po ⏐ ≤ S · t − t (14.43) The resulting delay contract (14.44) per Def. 19 for the obstacle was verified using KeYmaera X.

∆o ctrlo planto ( − ) −      − ′ ′   t = t ∧ Ω ∧ φo →[(po := po; so := ∗; ?(0 ≤ so ≤ S); t := t; {t = 1, po = so}; (⏐ −⏐ ( −)) skip; skip)∗] ⏐po − po ⏐ ≤ S · t − t (14.44)          ino ports out o Πo Remark 10. An abstraction as in (14.43) can, for instance, be found by solving the plant ODE or from differential invariants [98]. Consider an ODE as in the ∂p obstacle plant above, i. e., ∂τ = s, where position p changes over time τ with a rate of speed s. If we solve the differential equation for p, we get p = s · τ. Since we know that the plant runtime τ is limited by (t − t−) and since speed s ≤ S, we can infer that the change in position is bounded by |p − p−| ≤ S · (t − t−).

Robot. Finally, we turn to the contract for the robot. Since the robot receives the obstacle position on a ∆-port with a property using time, the robot uses a delay contract, respecting Def. 19. − ˆ− The precondition bootstraps the input ports’ previous valuesp ˆo and d ˆ fromp ˆo and d, initializes the robot’s speed to 0, and ensures a positive control cycle time ε (i. e., maximum plant duration ε), cf. (14.45). The entire global property is needed and specifies the bound for the global variables S and D, cf. (14.1). The safety property for the robot states that the robot’s position and the obstacle’s position must never coincide, unless the robot is stopped. Since the robot has no output ports it suffices to verify its safety property, cf.(14.46).

− ˆ ˆ− φr ≡ S ≥ 0 ∧ D ≥ 0 ∧ pˆo =p ˆo ∧ d = d ∧ sr = 0 ∧ ε > 0 (14.45)

ψr ≡ sr > 0 → pˆo ̸= pr (14.46) The resulting delay contract per Def. 19 for the robot was verified using KeYmaera X, see (14.47).

∆r ctrlr       ( − ) − ˆ− ˆ ˆ − t = t ∧ Ω ∧ φr → [(pô :=p ô; d := d; ?Safe; sr := d ∪ ?¬Safe; sr := 0; t := t; ′ ′ in ˆ in ˆ {t = 1, pr = sr};p ô := ∗;?πr (ˆpo); d := ∗;?πr (d); skip)∗](sr > 0 → pô ̸= pr)             plantr inr portsr ψr (14.47)

139 CHAPTER 14. CONCEPT

14.3 Proof Obligations: Composition

From components with verified contract compliance, we now once again compose systems in a way that provides safety guarantees about them, without redoing system proofs.

14.3.1 Parallel Composition

For this, Def. 20 introduces a quasi-parallel composition, where the discrete ctrl parts of the components are executed sequentially in any order, while the continuous plant parts run in parallel, cf. Section 3.1.2. The internally connected ports of all components are composed sequentially in any order, since the order of independent programs (e. g., deterministic assignments, having disjoint free and bound variables) is irrelevant. Values can be exchanged between components using ∆-ports; all other variables are internal to a single component, except for globals (i. e., global variables, which are never bound, and system time t, t−, which is only bound at specific locations fixed by the delay contract, cf.Def. 19), which can be read everywhere. ∆-ports store their previous values in the composite component, regardless if connected or not. For all connected ports, composition replaces the non-deterministic assignments to open inputs (cf. in) with a deterministic assignment from the connected port (cf. ports). This represents an instantaneous and lossless interaction between components.

∆ Definition 20 (Parallel Composition). Let Ci = (ctrli, planti, portsi) denote components with their corresponding admissible interfaces

∆ ( in in out out δ − ) Ii = V i , πi , V i , πi , V i , V i , prei for i ∈ {1, . . . , n} ,

global global sharing only globals (i. e., V and global times) such that Vi ∩Vj ⊆ V ∪ {t, t−} for i ̸= j. Let further

(⋃ in) (⋃ out) out in X : 1≤j≤n V j ⇀ 1≤i≤n V i , provided X (v) ∈/ V j , for all v ∈ V j be a partial (i. e., not every input must be mapped), injective (i. e., every output is only mapped to at most one input) function, connecting some inputs to some outputs, with domain IX = {x ∈ V in | X (x) is defined} and image OX = {y ∈ V out | y = X (x) for some x ∈ V in}. The composition of n components and their interfaces according to X

∆ ∆ def ( ∆ ∆ ∆ ) (C , I ) ≡ (C1 , I1 )∥...∥(Cn,In ) X

140 14.3. PROOF OBLIGATIONS: COMPOSITION is defined as follows:

• controllers are executed in non-deterministic order of all the n! possible permutations of {1, . . . , n},

ctrl ≡ (ctrl1; ctrl2; ... ; ctrln) ∪

(ctrl2; ctrl1; ... ; ctrln) ∪ ...

(ctrln; ... ; ctrl2; ctrl1)

⋀ • plants are executed in parallel, with evolution domain H ≡ i∈{1,...,n} Hi

plant ≡ (1)′ (1) (k)′ (k) (1)′ (1) (m)′ (m) x1 = θ1 , . . . , x1 = θ1 , . . . , xn = θn , . . . , xn = θn & H,       ∆ ∆ component C1 component Cn

• port assignments are extended with connections for some {vj, . . . , vr} = IX

def ports ≡ ports1; ports2; ... ; portsn; vj := X (vj); ... ; vr := X (vr) ,       component ports connected inputs

− def ⋃ − • previous values V = 1≤i≤n V i are merged; connected ports become δi def (⋃ δi) X X internal V = 1≤i≤n V i ∪I ∪O ; unconnected ports remain public δp def (⋃ δp) X X V = 1≤i≤n V i \ (I ∪ O ),

• prei are combined such that

δ pre(v) ≡ prei(v) if v ∈ V i for all i ∈ {1, . . . , n}

δ (well-defined as V i are disjoint),

in (⋃ in) X • unconnected inputs V = 1≤i≤n V i \I and unconnected outputs out (⋃ out) X V = 1≤i≤n V i \O are merged and their requirements preserved

in in in X π (v) ≡ πi (v) if v ∈ V i \I for all i ∈ {1, . . . , n} out out out X π (v) ≡ πi (v) if v ∈ V i \O for all i ∈ {1, . . . , n} .

∆ ∆ The user provides component specifications i(C , Ii ) and a mapping function X defining, which output is connected to which input. The composed system of parallel components can be derived automatically from Def. 20.

141 CHAPTER 14. CONCEPT

The order of port assignments is irrelevant because all sets of variables are disjoint and a port can only be either an input port or an output port, cf. Def. 14 and Def. 17, and thus the assignments share no variables. This also entails that in out δ in out the merged pre, π and π are well-defined since Vi ,Vi , respectively Vi , are disjoint between components by Def. 15. It follows that the set of variables of the composite component V is the ⋃ union of all involved components’ variable sets V i, i. e., V = 1≤i≤n V i. The set of global variables Vglobal contains all global variables in the system (i. e., in all components) and thus, its contents do not change. δ ⋃ δ Note that since V = 1≤i≤n Vi , this definition implies that internally connected ∆-ports Vδi of sub-components, as well as the previous values Vδp for all open ∆-ports are still stored. As a result, the current and previous values of ∆-ports can still be used internally in the composite, even when the ports are no longer exposed through the external interface of the composed system.

Remark 11. The composition operation in Def. 20 differs from the one of Part III (i. e., Def. 10) mostly in the handling of ports. Connected ports are no longer merged into the composite control part, but are identified separately in the ports part and read at an uniform location at the end of the program (cf. Def. 19), whereas open and closed ports were read at different locations in Part III.

14.3.2 Example: Composition

Returning to our running example of Fig. 13.3, after every component’s contract was verified separately, we compose the components to form the overall collision avoidance system. The mapping function (14.48) connects the output ports of the RC and the obstacle with the respective input ports of the robot.

( ˆ ) X = pˆo ↦→ po, d ↦→ d (14.48)

∆ ∆ The component Csys in (14.49) and interface Isys in (14.50) result from parallel composition of the RC, the robot, and the obstacle, using the introduced mapping function. The robot’s input ports are connected to the RC’s and obstacle’s output ports.

∆ ˆ Csys = ((ctrlrc; ctrlr ; ctrlo ∪ ctrlo; ...), (plantr , planto), pô := po; d := d)          ctrlsys plantsys portssys (14.49) ∆ ( ˆ − − − ˆ− ( − )) Isys = {} , () , {} , () , {po, d, pô, d}, {po , d , pô , d }, po ↦→ po , ...              Vin πin Vout πout Vδ V− pre (14.50)

142 14.3. PROOF OBLIGATIONS: COMPOSITION

14.3.3 Compatibility Similar to PartIII, during composition, the tests guarding the input ports of an interface are replaced with deterministic assignments modeling the port connections of the components, which is only safe if the respective output guarantees and input assumptions match. Hence, in addition to contract compliance, users have to show compatibility of components. In contrast to global contracts, compatibility for change- and delay contracts additionally requires that the components in consideration agree on the previous values of the connected ports. Naturally, the global property, which is invariant throughout the system, also holds.

Definition 21 (Compatible Composite). A compatible composite with change- and delay contracts is defined as in Def. 11, except that additionally previous values must match and the global property Ω holds ( ) ∆ def ( ) ( ) CPO(Ii ) ≡ pre(X (v)) = pre(v) ∧ Ω →

out in [v := X (v)](πj (X (v)) → πi (v)) .

To achieve local compatibility checks for pairs of connected ports, instead of global checks over entire component models, Def. 17 restricts input assumptions to only mention variables of the associated ports. Note that even though Def. 17 does not restrict output guarantees, in order to show compatibility each output guarantee should also only mention variables of the associated ports.

14.3.4 Example: Compatibility In our example, we have to ensure compatibility (cf. Def. 21) of the components with respect to X . Since we have two connected ports, we discharge two compatibility proof obligations, one for each port, cf. (14.51)-(14.52). Unused parts of the global property are omitted.

∆ ( − ˆ− ) ˆ CPO(Irc) ≡ d = d ∧ D ≥ 0 → [d := d] ( ⏐ ⏐ ) ⏐ −⏐ ⏐ ˆ ˆ−⏐ ⏐d − d ⏐ ≤ D → ⏐d − d ⏐ ≤ D (14.51) ∆ ( ) CPO(Io ) ≡ po =p ô ∧ S ≥ 0 → [ˆpo := po] ( ) ⏐ −⏐ ( −) ⏐ −⏐ ( −) ⏐po − po ⏐ ≤ S · t − t → ⏐pô − pô ⏐ ≤ S · t − t (14.52)

Formulas (14.51)-(14.52) can be proved automatically using KeYmaera X, ∆ ∆ ∆ so the three interfaces Irc,Io and Ir are compatible.

143 CHAPTER 14. CONCEPT

14.4 Transferring Local Component Safety to System Safety

From contract compliance and compatibility proofs, Theorem4 below transfers the safety properties in component contracts to safety of the composed system. As a result, for showing safety of the monolithic system, we no longer need a (probably huge) monolithic proof. The proof of Theorem4 can be found at the end of this chapter in Section 14.5. ∆ ∆ Theorem 4 (Composition Retains Contracts). Let C1 and C2 be components ∆ ∆ with admissible interfaces I1 and I2 that are delay contract compliant (cf. def Def. 19) and compatible with respect to X (cf. Def. 21). Initially, assume φp ≡ ⋀ v∈IX X (v) = v to bootstrap connected ports. Then, if the side condition (14.53) holds (ϕi is the loop invariant used to prove the component’s contract) − ′ out |= ϕi → [∆i][ctrli][t := t][(t = 1, planti)]Πi (14.53)

∆ for all components Ci , the parallel composition

∆ ∆ ( ∆ ∆ ∆ ∆ ) (C , I ) = (C1 , I1 )∥(C2 , I2 ) X satisfies the contract (14.54) with in, ports, ctrl, and plant according to Def. 20: ( − p) − ′ |= t = t ∧ φ1 ∧ φ2 ∧ φ →[(∆; ctrl; t := t;(t = 1, plant); in; ∗ ( safe out safe out) ports) ] ψ1 ∧ Π1 ∧ ψ2 ∧ Π2 . (14.54)

The composite contract’s precondition φp ensures that the values of connected ports are consistent initially. Side condition (14.53) shows that a component already produces the correct output from just its ctrl and plant; preparing the port inputs for the next loop iteration does not change the current output. Theorem4 easily extends to any number of components (cf. proof sketch in Section 14.5.3) and also holds for change contracts. Note that a change port cannot be attached to a delay port and vice versa. Remark 12. The side condition (14.53) is trivially true for components without out output ports, since Πi ≡ true. This side condition can—often automatically— be verified using KeYmaera X. For atomic components without input ports, the proof of (14.53) automatically follows from the contract proof, since in; ports is empty. Remark 13. Because of the precondition φp and because ports is executed after every execution of the main loop (cf. Def. 19, as opposed to Def.9 in Part III), we know that the values of connected input and output ports coincide in the safety property, as one would expect. Thus, for instance, if the local safety property of safe a single component mentions an input port (e. g., ψ1 ≡ |pr − pˆo| > 0), we can replace the input port with the original value as provided by the output port for safe the composite safety property (e. g., ψ ≡ |pr − pˆo| > 0 ≡ |pr − po| > 0).

144 14.5. PROOF – COMPOSITION RETAINS CONTRACTS

Example. In Section 14.3.4 we proved that RC, the robot, and the obstacle component are compatible. The remaining proof below discharges the three side conditions from Theorem4—one for each component.

∆ ∆ − SC(Crc, Irc) ≡ ϕrc → [∆rc][ctrlrc][t := t] ′ ⏐ −⏐ [{t = 1, plantrc}] ⏐d − d ⏐ ≤ D (14.55) ∆ ∆ − SC(Co , Io ) ≡ ϕo → [∆o][ctrlo][t := t] ′ ⏐ −⏐ ( −) [{t = 1, planto}] ⏐po − po ⏐ ≤ S · t − t (14.56) ∆ ∆ − ′ SC(Cr , Ir ) ≡ ϕr → [∆r ][ctrlr ][t := t][{t = 1, plantr }]true (14.57) The side condition for the robot is trivially true, since the robot component has no output ports and thus we have to verify that true holds, cf. (14.57). For the other side conditions we need the respective invariants used to verify each component’s contract.

⏐ −⏐ ϕrc ≡ D ≥ 0 ∧ ⏐d − d ⏐ ≤ D (14.58) ⏐ −⏐ ( −) ϕo ≡ S ≥ 0 ∧ 0 ≤ so ≤ S ∧ ⏐po − po ⏐ ≤ S · t − t (14.59) The invariant of the RC component preserves the bound for the global variable D and ensures that the target speed is always in bounds, cf. (14.58). The invariant of the obstacle component also preserves the bound for the respective global variable S, restricts the obstacle speed to valid values and ensures that the obstacle position stays within bounds, cf. (14.59). Using these invariants, (14.55)-(14.56) can be verified automatically using KeYmaera X. Note, that in this case the side conditions also follow from Remark 12, since the RC component and the obstacle are atomic component without input ports. Finally, we have verified all component contracts as well as the compatibility proof obligations and the side conditions. Theorem4 then guarantees system safe safe safety ψsys ≡ sr > 0 → po ̸= pr from the robot’s safety property ψr ≡ sr > 0 → pˆo ̸= pr together with the port connectionp ˆo = po having the connected ports coincide (cf. Remark 13).

14.5 Proof – Composition Retains Contracts

In this section, we present the proof of Theorem4. The proof follows a similar proof sketch as the proof of Theorem2 in PartIII. The main idea is to match the behavior and properties of the composite with the behavior of its components, so that component proofs fill in most proof obligations. For the proof, we reused some of the lemmas presented in Section 11.5, namely Lemma1–Lemma3 and Lemma5–Lemma6. Additionally, we introduce Lemma7 and Corollary2 as improved versions of Lemma4 and Corollary1. Thus, in the following we first introduce the additional lemmas needed for the proof, cf. Section 14.5.1. Then, we proof Theorem4 for two components

145 CHAPTER 14. CONCEPT in Section 14.5.2, followed by a proof sketch for any number of components in Section 14.5.3.

14.5.1 Lemmas While Lemma4 can only be used to reorder non-deterministic assignments, Lemma7 allows reordering of several variations of assignments, non-deterministic assignments and tests.

Lemma 7 (Reorder Programs). Let x, y, a, b be variables, A, F, G be dL formulas and B(a) be a dL formula allowed to mention a bound variable a free in B. Then

[x := a; y := b]A(x, y)A(x, y) ↔ [y := b; x := a]A(x, y) (14.60) [x := ∗; y := ∗]A(x, y) ↔ [y := ∗; x := ∗]A(x, y) (14.61) [x := ∗; y := b]A(x, y) ↔ [y := b; x := ∗]A(x, y) (14.62) [x := ∗;?B(a)]A(x, y) ↔ [?B(a); x := ∗]A(x, y) (14.63) [x := a;?B(a)]A(x, y) ↔ [?B(a); x := a]A(x, y) (14.64) [?F ;?G]A ↔ [?G;?F ]A (14.65) are valid.

Proof of Lemma7. The proofs follow from the definition of (non-deterministic) assignments and the axiom for tests. We start with proving (14.60)–(14.62). We only show one direction of the equivalence–the other one follows accordingly. ∗ A(a, b) ⊢ A(a, b) [; ],[:=],[:=][x := a; y := b]A(x, y) ⊢ [y := b; x := a]A(x, y) →r ⊢ (14.60)

∗ [x := ∗]A(x, b) ⊢ [x := ∗]A(x, b) [; ],[:=][x := ∗; y := b]A(x, y) ⊢ [y := b; x := ∗]A(x, y) →r ⊢ (14.61)

∗ ∀x . ∀y . A(x, y) ⊢ ∀x . ∀y . A(x, y) [; ],[:∗][x := ∗; y := ∗]A(x, y) ⊢ [y := ∗; x := ∗]A(x, y) →r ⊢ (14.62) Next, we show formulas (14.63)–(14.64). Again we just show one direction of the equivalence–the second direction follows accordingly. ∗ [?B(a)]A(a, y) ⊢ [?B(a)]A(a, y) [:=],[; ][x := a;?B(a)]A(x, y) ⊢ [?B(a); x := a]A(x, y) →r ⊢ (14.63)

146 14.5. PROOF – COMPOSITION RETAINS CONTRACTS

∗ ∗ B(a) ⊢ A(x1, y),B(a) A(x1, y),B(a) ⊢ A(x1, y) [?],→l ([?B(a)]A(x1, y)) ,B(a) ⊢ A(x1, y) ∀l ∀x . ([?B(a)]A(x, y)) ,B(a) ⊢ A(x1, y) ∀r ∀x . ([?B(a)]A(x, y)) ,B(a) ⊢ ∀x . A(x, y) [?],→r ∀x . ([?B(a)]A(x, y)) ⊢ [?B(a)] (∀x . A(x, y)) [; ],[:∗] [x := ∗;?B(a)]A(x, y) ⊢ [?B(a); x := ∗]A(x, y) →r ⊢ (14.64) Finally, we show (14.65). First, we apply the tests and then use the equivalence (a → (b → c)) ↔ (b → (a → c)) (i. e., step impl). ∗ F → (G → A) ⊢ F → (G → A) impl F → (G → A) ⊢ G → (F → A) [?] F → ([?G]A) ⊢ [?G](F → A) [?],[; ] [?F ;?G]A ⊢ [?G;?F ]A →r ⊢ (14.65)

Corollary2 is a generalization of Corollary1, which allows weakening of a test preceded by an arbitrary program, in contrast to Corollary1, which allows weakening of a test preceded by an assignment only. Corollary 2 (Weaken Test – Context). Let A, F and G be arbitrary dL formulas and let α be any program. Then ( ) ([α][?G]A) ∧ ([α](F → G)) → [α][?F ]A (14.66)

Proof of Corollary2. After removing α we can again use Lemma6. ∗ L.6 ([?G]A) ∧ (F → G) ⊢ [?F ]A [] M ([α] ([?G]A ∧ (F → G))) ⊢ [α][?F ]A [] split inv(([α][?G]A) ∧ ([α](F → G))) ⊢ [α][?F ]A →r ⊢ (14.66)

Note that in the proof of Theorem4 we will use these lemmas in the context of other logical and modal formulas, as described in Section 6.1.

14.5.2 Proof for Two Components Next, we prove that the composition of two safe components with interfaces results in a safe composed system, given proven contract compliance for each component and compatibility of the connected ports. We repeat Theorem4 below for easy reference.

147 CHAPTER 14. CONCEPT

∆ ∆ Theorem 4 (Composition Retains Contracts). Let C1 and C2 be components ∆ ∆ with admissible interfaces I1 and I2 that are delay contract compliant (cf. def Def. 19) and compatible with respect to X (cf. Def. 21). Initially, assume φp ≡ ⋀ v∈IX X (v) = v to bootstrap connected ports. Then, if the side condition (14.53) holds (ϕi is the loop invariant used to prove the component’s contract)

− ′ out |= ϕi → [∆i][ctrli][t := t][(t = 1, planti)]Πi (14.53)

∆ for all components Ci , the parallel composition

∆ ∆ ( ∆ ∆ ∆ ∆ ) (C , I ) = (C1 , I1 )∥(C2 , I2 ) X satisfies the contract (14.54) with in, ports, ctrl, and plant according to Def. 20:

( − p) − ′ |= t = t ∧ φ1 ∧ φ2 ∧ φ →[(∆; ctrl; t := t;(t = 1, plant); in; ∗ ( safe out safe out) ports) ] ψ1 ∧ Π1 ∧ ψ2 ∧ Π2 . (14.54)

Proof of Theorem4. For space reasons let

δ def ( δ δ ) (C3,I3 ) ≡ (C1,I1 )∥(C2,I2 ) X def ctrl3 ≡ (ctrl1; ctrl2) ∪ (ctrl2; ctrl1)

def plant3 ≡ plant1, plant2 def p φ3 ≡ φ1 ∧ φ2 ∧ φ safe def safe safe ψ3 ≡ ψ1 ∧ ψ2 out ⋀ out Π1 ≡ π1 (v) out v∈V1 out ⋀ out Π2 ≡ π2 (v) out v∈V2 ⎛ ⎞ ⎛ ⎞ out def ⎜ ⋀ out ⎟ ⎜ ⋀ out ⎟ Π3 ≡ ⎝ π1 (v)⎠ ∧ ⎝ π2 (v)⎠ out out out out v∈(V3 ∩V1 ) v∈(V3 ∩V2 ) def − ′ prog3 ≡ ∆3; ctrl3; t := t;(t = 1, plant3 ); in3; ports3

We will use the above abbreviations throughout the proof. From the component proofs and because the composed components are compatible, we know

148 14.5. PROOF – COMPOSITION RETAINS CONTRACTS

δ δ Def. 19 − − DC( C1 ,I1 ) ≡ t = t ∧ φ1 → [(∆1; ctrl1; t := t; ′ ∗ ( safe out) (t = 1, plant1); in1; ports1) ] ψ1 ∧ Π1 (14.67)

δ δ Def. 19 − − DC( C2 ,I2 ) ≡ t = t ∧ φ2 → [(∆2; ctrl2; t := t; ′ ∗ ( safe out) (t = 1, plant2); in2; ports2) ] ψ2 ∧ Π2 (14.68)

δ δ Def. 19 − − DC( C3 ,I3 ) ≡ t = t ∧ φ3 → [(∆3; ctrl3; t := t; ′ ∗ ( safe out) (t = 1, plant3); in3; ports3) ] ψ3 ∧ Π3 (14.69)

δ Def. 21 CPO( I1 ) ≡ pre(X (v)) = pre(v) → ( out in ) [v := X (v)] π1 (X (v)) → π2 (v) (14.70) δ Def. 21 CPO( I2 ) ≡ pre(X (v)) = pre(v) → ( out in ) X in [v := X (v)] π2 (X (v)) → π1 (v) for all v ∈ I ∩ V1,2 (14.71) We have to show that the contract (14.69) resulting from parallel composition is valid. We know that formulas (14.67) and (14.68) are valid, hence there exist invariants ϕ1 and ϕ2 such that

− t = t ∧ φ1 → ϕ1 (14.72) − ′ ϕ1 → [∆1; ctrl1; t := t;(t = 1, plant1); in1; ports1]ϕ1 (14.73) ⎛ ⎞ safe ⋀ out ϕ1 → ⎝ψ1 ∧ π1 (v)⎠ (14.74) v∈Vout

Formulas (14.72)–(14.74) are phrased accordingly for component C2 with invariant ϕ2. If (14.67) and (14.68) were verified using loop induction, the invariants are even known. Note, that ϕ1 is an inductive loop invariant for the first component, global − so it can be phrased such that FV (ϕ1) ⊆ V 1 ∪ V ∪ {t, t }, accordingly for ϕ2. p By imply-right and loop induction, where we choose ϕ3 = ϕ1 ∧ ϕ2 ∧ φ (i. e., the loop invariant for the proof is the conjunction of the two invariants known to exist from the independent proofs, plus the knowledge that the values of connected ports are equal), we get (prog3 as introduced above): ... ① ... ② ... ③ − ( safe out) t = t ∧ φ3 ⊢ ϕ3 ϕ3 ⊢ [prog3] ϕ3 ϕ3 ⊢ ψ3 ∧ Π3 ind − [ ∗] ( safe out) t = t ∧ φ3 ⊢ (prog3) ψ3 ∧ Π3 →r − [ ∗] ( safe out) ⊢ t = t ∧ φ3 → (prog3) ψ3 ∧ Π3 We will transform the three resulting branches until we get formulas that correspond to (14.72), (14.73) and (14.74). To prove the induction base case

149 CHAPTER 14. CONCEPT

and the use case, we use the loop invariants ϕ1 and ϕ2, for which (14.72) and (14.74) hold. ∗ ∗ (14.72) − (14.72) − t = t , φ1 ⊢ ϕ1 t = t , φ2 ⊢ ϕ2 Wl − p Wl − p t = t , φ1, φ2, φ ⊢ ϕ1 t = t , φ1, φ2, φ ⊢ ϕ2 ∧l − p ∧l − p t = t ∧ φ1 ∧ φ2 ∧ φ ⊢ ϕ1 t = t ∧ φ1 ∧ φ2 ∧ φ ⊢ ϕ2 ... ④ ∧r − p p t = t ∧ φ1 ∧ φ2 ∧ φ ⊢ ϕ1 ∧ ϕ2 ∧ φ def ① continued

The last branch of the use case follows directly from the definition of ϕ3: ∗ φp ⊢ φp Wl − p p t = t , φ1, φ2, φ ⊢ φ ∧l − p p t = t ∧ φ1 ∧ φ2 ∧ φ ⊢ φ ④ continued Note that in the first step (i. e., def ) of the proof of ③ below, we use

p • ϕ3 ≡ ϕ1 ∧ ϕ2 ∧ φ ,

( safe out) ( safe safe out) • ψ3 ≡ ψ3 ∧ Π3 ≡ ψ1 ∧ ψ2 ∧ Π3 ,

150 14.5. PROOF – COMPOSITION RETAINS CONTRACTS

We have to prove that both, ϕ1 (i. e., ⑤) and ϕ2 (i. e., ⑥) hold. We illustrate the strategy only for branch ⑤, because branch ⑥ follows in a similar manner. For ⑤, we first extend the definition of ctrl3 and apply the proof rule for non- deterministic choice and get two branches, which only differ in the order of control parts (i. e., ctrl1; ctrl2 in ⑦ and ctrl2; ctrl1 in ⑧). Note that below we p replace the left hand side of the sequent (i. e., ϕ1, ϕ2, φ ) with “···” for space reasons. ... ⑦ [; ] ⑧ − ′ ... · · · ⊢ [∆3][ctrl1; ctrl2][t := t (t = 1, plant3) in3; ports3]ϕ1 [∪],[]split,∧r − ′ · · · ⊢ [∆3][((ctrl1; ctrl2) ∪ ...)][t := t (t = 1, plant3) in3; ports3]ϕ1 def p − ′ ϕ1, ϕ2, φ ⊢ [∆3][ctrl3][t := t (t = 1, plant3) in3; ports3]ϕ1 ⑤ continued We illustrate the strategy for ⑦, which we will now transform until we get (14.73). First, we remove control ctrl2, and reorder in3 so that we can then remove the assignments in2. We reintroduce tests and turn the deterministic assignments of connected ports into non-deterministic ones until they behave like non-connected inputs, and finally get (14.73). The detailed proof steps are explained below and can be cross-referenced using enumeration and the step number in the sequent proof, cf. Fig. 14.2a. For space reasons we define

out def − ′ out F2 ≡ ϕ2 → [∆3][ctrl1; ctrl2][t := t][(t = 1, plant1, plant2)]Π2 .

In detail, we applied the following lemmas:

out 1. First, we cut in F2 , which we will need later throughout the proof, to verify the side condition of Lemma5. The side condition of the cut is verified in ⑨ below. ∗ cf. (c) − ′ out ϕ2 ⊢ [∆2][ctrl2][t := t][(t = 1, plant2)]Π2 cf. (b),L.1 − ′ out ϕ2 ⊢ [∆1; ∆2][ctrl2][t := t][(t = 1, plant2)]Π2 cf. (b),L.1 − ′ out ϕ2 ⊢ [∆1; ∆2][ctrl1; ctrl2][t := t][(t = 1, plant2)]Π2 def − ′ out ϕ2 ⊢ [∆3][ctrl1; ctrl2][t := t][(t = 1, plant2)]Π2 cf. (a),L.2 − ′ out ϕ2 ⊢ [∆3][ctrl1; ctrl2][t := t][(t = 1, plant1, plant2)]Π2 →r − ′ out ⊢ ϕ2 → [∆3][ctrl1; ctrl2][t := t][(t = 1, plant1, plant2)]Π2 ⑨: Side Condition, cut

(a) We apply Lemma2 to remove plant1.

(b) By multiple applications of Lemma1 we remove ∆ 1 and ctrl1. (c) The proof closes, since we know that the side condition of Theorem4 holds, cf. (14.53).

2. We use Lemma7 to reorder the assignments in in3 and ports2 in a way that the assignments of C1 precede the ones of C2. Note, that in3 contains only the non-connected ports of C1 and C2, while the connected ports are

151 CHAPTER 14. CONCEPT ) ⑨ 1 1 ) j ϕ ϕ v ] ] ... ( ∗ 1 ∗ 1 1 in 1 π ϕ ] ∗ 1 ports ports → 1 )][ ϕ ))][ j ] )) )) j v j ∗ 1 j ports 1 v ( v v ( ϕ )) ( ( ] )][ X j 1 j 1 X v X ( v ( ϕ ( ports pre ] ( := 2 1 j )][ in out 1 2 out 2 pre j v ports ϕ π π π ] v ][ ; ( )) = ( 1 1 1 ∗ 1 ∗ 1 j ports ϕ ϕ )][? )][? )] in 1 v ] ] ; in in )) = j j j ( π 1 1 1 j v v v 1 1 1 1 v ( ( ( X ports ))][ ))][ ][? ( ϕ ( 1 ϕ ϕ ϕ ] ][ ] ] ] j j ∗ X X X ϕ 1 1 1 3 3 X v v ] ports ports ports ( ( ( pre 1 ; ; in ][ := := := := 1 1 ∗ 2 ∗ 2 X X 1 ]( j j j j ϕ ϕ ( ( pre )][ ] ] v v v v ports ports in in ports ports 2 in 1 1 ... ][ ][ ][ ; ; ; ]( ][ ][ ; ; ports out out 2 2 ; 1 ∗ 1 ∗ 1 3 ∗ 1 ∗ 1 ∗ 1 3 ∗ 1 ∗ 1 ∗ 1 )][ ][ j π π 1 1 v in in in in in in in in in in in plant ports ports in )][ , )][ )][ )][? )][? )][ )][ )][ )][ )][ )][ )][ )][ ][ ][ 1 1 3 3 3 3 3 3 3 3 3 3 3 3 1 1 )][ ) := plant 1 j , in in v ( )][ )][ plant plant plant plant plant plant plant plant plant plant plant plant plant plant 1 1 = 1 , , , , , , , , , , , , , , plant ′ pre )) , t ; j v = 1 = 1 = 1 = 1 = 1 = 1 = 1 = 1 = 1 = 1 = 1 = 1 = 1 = 1 ][( ( plant plant t ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ′ ... = 1 )) , , t t t t t t t t t t t t t t j ′ ); t v pre := ][( ][( ][( ][( ][( ][( ][( ][( ][( ][( ][( ][( ][( ][( j ( t t t t t t t t t t t t t t v = 1 = 1 ][( − ( t ′ ′ t t t pre := := := := := := := := := := := := := := ][ X )) = 2 := j ][( ][( − − − − − − − − − − − − − − t t v t t t t t t t t t t t t t t − ( ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ t )) = ctrl 2 2 2 2 2 2 2 2 2 2 2 2 2 2 )) := := := j X ][ ; j ( v 1 1 v − − ( t t ( ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl X ][ ][ ; ; ; ; ; ; ; ; ; ; ; ; pre ; ; ctrl ctrl X ( 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ( ][ ][ ]( 2 2 2 pre ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl ctrl pre ; ][ ][ ; ∆ ; ∆ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ; ∆ ]( ][ ][ 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 3 1 3 3 3 ... continued [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [∆ [ ⊢ ⊢ ⊢ ⊢ ⊢ ⊢ ⊢ ⊢ ⊢ ⊢ ⊢ ∗ ⊢ ⊢ ⊢ ⊢ ⑦ ⊢ ∗ ⊢ ⊢ ⊢ ⊢ ⊢ 2 2 2 2 2 2 2 1 p p p p p p p p v ϕ out out out out 2 2 2 2 , φ , φ , φ , φ , φ , φ , φ , φ , ϕ , ϕ , ϕ , ϕ , ϕ , ϕ , ϕ 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 ) = ,F ,F ,F ,F ϕ ϕ ϕ ϕ ϕ ϕ ϕ v p p p p , ϕ , ϕ , ϕ , ϕ , ϕ , ϕ , ϕ , ϕ ( 1 1 1 1 1 1 1 1 , φ , φ , φ , φ X ϕ ϕ ϕ ϕ ϕ ϕ ϕ ϕ 2 2 2 2 X , ϕ , ϕ , ϕ , ϕ ∈I 1 1 1 1 v ϕ ϕ ϕ ϕ ⋀ , 2 cut , ϕ 1 Wl ϕ (14.73) cf. 6. , def cf. 9. , L.3 cf. 5. , L.5 cf. 4. , L.1 cf. 3. , L.1 cf. 1. , cf. 7. , L. 7 cf. 10. , def cf. 8. , C. 2 cf. 13. , L.1 cf. 13. , L.1 cf. 11. , L.2 cf. 2. , def L. 7 cf. 12. , def L. 7 def def L.1 (14.70) (a) Transform ③ until we get (14.73) (b) Use compatibility

Figure 14.2: Proof Steps – Theorem4

152 14.5. PROOF – COMPOSITION RETAINS CONTRACTS

∗ ∗ still in ports3. Hence, we use in1 and in2 to denote that these assignments are not the full in1 and in2.

def def 3. We apply Lemma1 to remove ports2, with α ≡ ports1, β ≡ ports2 def and A ≡ ϕ1, so FV (α) ∩ BV (β) = ∅ since FV (ports1) ⊆ V 1 and in ( global − ) BV (ports2) ⊆ V2 (and thus BV (ports2) ⊆ V 2 \ V ∪ {t, t } )

are disjoint. Further FV (A) ∩ BV (β) = ∅ since FV (ϕ1) ⊆ V 1 and ( global − ) V 1 ∩ V 2 \ V ∪ {t, t } = ∅.

∗ def ∗ def ∗ def 4. We apply Lemma1 to remove in2, with α ≡ in1, β ≡ in2 and A ≡ ∗ ∗ [ports1]ϕ1, so FV (α) ∩ BV (β) = ∅ since FV (in1) ⊆ V 1 and BV (in2) ⊆ in ∗ ( global − ) V2 (and thus BV (in2) ⊆ V 2 \ V ∪ {t, t } ) are disjoint. Fur-

ther, FV (A) ∩ BV (β) = ∅ since FV ([ports ]ϕ1) ⊆ V 1 and V 1 ∩ V 2 \ ( ) 1 Vglobal ∪ {t, t−} = ∅.

out 5. By application of Lemma5, we can insert a test for π2 (X (vj)), for the leftmost deterministic assignment in ports1 without changing the behavior out out (side condition follows immediately from F2 ). Additionally, we hide F2 for space reasons.

∗ 6. We then split ports1 into two parts: the leftmost assignment and ports1, which represents the remaining port assignments.

out 7. We change the order of programs to move the test for π2 (X (vj)) introduced in step 5, behind the leftmost deterministic assignment. This is ∗ possible because in1 and ports1 bind only input variables from C1, while out ∗ π2 (X (vj)) only reasons about variables from C2, so BV (in1; ports1) ∩ out FV (π2 (X (vj))) = ∅ (cf. Lemma7). 8. We then relax the test to πin using compatibility as depicted in Fig. 14.2b. vj − − Step L. 1 is justified from pre(X (vj)) ∈ V2 and pre(vj) ∈ V1 with Def. 17 specifying that (BV (ctrl) ∪ BV (plant) ∪ BV (ports)) ∩ V− = ∅, and all variables except global ones being disjoint across components. We then expand ∆1; ∆2 according to Def. 19, so we get pre(X (vj)) := X (vj) and pre(vj) := vj, among further assignments to previous values per X . This p concludes the step, since φ holds initially and thus X (vj) = vj. 9. By Lemma3 we can replace the deterministic port assignment with a non- deterministic assignment.

10. After repeating steps 8–9 once for every connected port vj and after multiple applications of Lemma7 (to change the order of the assignments) we get in1; ports1.

11. Using Lemma2, we remove the plant of component two (i. e., plant2), because BV (plant2) ∩ FV ([in1][ports1]ϕ1) = ∅.

153 CHAPTER 14. CONCEPT

12. We use Lemma7 to reorder assignments in ∆ 3 in a way that assignments to previous variables from the first component (i. e., ∆1) precede the ones to previous variables from the second component (i. e., ∆2). 13. By multiple applications of Lemma1, we remove all remaining control of C2 until we get (14.73) (for the second component).

Note that if we use multi-ports, the test for the multi-port has to be moved at the respective position and the assignments to all of the port’s variables have to be kept together. The proof for ⑧ works almost alike, where the only difference is the order of the control parts. Thus we can apply the same proof steps as above, except step 13, where we have to use the second part of Lemma1. The proof for ⑥ follows accordingly, using ϕ2 in place of ϕ1. Thus, we δ δ conclude that DC( C3 ,I3 ) is valid.

14.5.3 Proof Sketch for any number of Components. So far, we proved Theorem4 for two components only. The proof sketch for n ∈ N, n > 2 components is very similar to the proof sketch for the composition of n components with global contracts, cf. Section 11.5.1. We have to consider ∆ ∆ n change contracts, one for each component with its interface (Ci , Ii ) (for i ∈ {0, . . . , n}).

δ δ − DC( Ci ,Ii ) ≡ t = t ∧ φi → ( − ′ )∗ [ ∆i; ctrli; t := t;(t = 1, planti) ][ini; portsi]ψi (14.75)

Again, we assume that formula (14.75) was proven for all i, hence there exist δ δ invariants ϕi, cf. (14.72)-(14.74). We still need to verify DC( C ,I ), except that plant now executes all n plants in parallel, ports contains all old port assignments of all components and ctrl contains all n! permutations of all control parts, i. e.,

ctrl ≡ (ctrl1; ctrl2; ...; ctrln) ∪

(ctrl2; ctrl1; ...; ctrln) ∪ ...

(ctrln; ...; ctrl2, ctrl1) and

ports ≡ports1; ports2; ...; portsn

The order of port assignments is irrelevant and can be changed at will using Lemma7, since all port assignments are independent. As in Section 11.5.1, we define our invariant ϕ as the conjunction of all ϕi and φp. Base case and use case follow immediately; the induction step remains,

154 14.5. PROOF – COMPOSITION RETAINS CONTRACTS but can be traced back to the steps carried out to prove the two-component version. We consider one example branch, where we need to show that ϕ2 holds after each of its runs:

⋀ p ′ ϕi, φ ⊢ [∆3;(ctrl1; ctrl2; ...; ctrln);(t = 1, plant1)][in3; ports3]ϕ2 i As in Section 11.5.1, we have to reduce the branch to the loop induction step ∆ of component C2 , cf. (14.73). Thus, we have to transform the connected ports back to unconnected ones and remove the unnecessary parts. First, we remove ∆ all in and ports parts, which do not belong to C2 . For each connected port, we introduce a test and replace the assignment. Then, the plants and the unnecessary control parts are removed, until we reduced the formula to (14.73). In a similar way, all other branches can be proved.

155

Chapter 15

Evaluation

In this chapter, we present an implementation of our approach, cf. Section 15.1, and use it to evaluate our approach on several case studies previously verified without component-based modeling and verification, cf. Section 15.2. We conclude this part of the thesis in Section 15.3.

15.1 Implementation

We implemented the proof steps of Theorem4 as a KeYmaera X tactic, which automatically reduces a system safety proof to separate proofs about components. This gave us the best of the two worlds: the flexibility of reasoning with components that our Theorem4 provides, together with the soundness guarantees we inherit from KeYmaera X, which derives proofs by uniform substitution from axioms [100]. This is to be contrasted with the significant soundness- critical changes we would have to do if we were to add Theorem4 as a built-in rule into the KeYmaera X prover core. Uniform substitution guarantees, e.g., that the subtle conditions on how and where input and output variables can be read or written in components are checked correctly. So far the theorem has only been implemented for the composition of two components. Thus, in order to apply the tactic to examples using multiple components, components might have to be merged manually beforehand. This is especially easy, if the merged components are completely independent and share no connected ports. For instance, for our third motivational example in Section 5.3, we merged the RC component and the obstacle component into a single component, which is possible since the RC and the obstacle are utterly independent.

15.1.1 Implementing the Lemmas As the proof does not only use built-in proof rules provided by KeYmaera X, but also makes use of the lemmas introduced in Section 11.5 and Section 14.5,

157 CHAPTER 15. EVALUATION we transfer the lemmas into KeYmaera X. Below, we provide insights on how the various lemmas were implemented. Lemma1: Since the lemma bases on assumptions about the intersection of free and bound variables of program constants α and β, it is not expressible in KeYmaera X yet. However, when implemented as a tactic that operates on concrete programs α and β, their free and bound variables can be computed (e. g., α ≡ x := y has bound variable x and free variable y) and the assumptions checked; uniform substitution in the KeYmaera X kernel will fail the tactic if it operates on programs that violate the assumptions. Lemma2: Similarly to Lemma1, we implement the lemma as a tactic that operates on concrete programs and relies on uniform substitution for soundness. Unfortunately, differential equations x′ = θ can so far only be dropped one by one from the ODE system. Dropping of multiple differential equations at once would require vectorial ⃗x′ = θ⃗ in the prover kernel. Lemma3: We proved this lemma as a derived axiom and it can thus be used as a fact in subsequent KeYmaera X proofs. The proof in KeYmaera X first performs the deterministic and the non-deterministic assignment and then instantiates the resulting universal-quantifier with θ. Lemma7: Most of the proofs for these formulas cannot be verified as derived axioms in KeYmaera X because they contain generic formulas that reason about more than one specific variable (e. g., A(x, y)) and so far KeYmaera X only allows formula constants that reason about single variables (e. g., A(x)). Thus, we implemented a tactic for each of the lemmas that operates on a concrete program and relies on uniform substitution soundness, because again for actual programs the uniform substitution will fail if the conditions for the application of the lemmas are violated. Basically, the tactics perform all assignments, tests and non-deterministic assignments with according instantiations of the resulting all-quantifiers. Lemma5: We proved this lemma as a derived axiom and it can thus be used as a fact in subsequent KeYmaera X proofs. Lemma6 and Corollary2: Both, Lemma6 and Corollary2, could be verified as derived axioms in KeYmaera X. Since the formulas F , G and A, and the program constant α are not restricted to reasoning about any number of specific variables, Lemma6 can be verified by applying the implications and tests, which leads to the same formulas in antecedent and succedent. For Corollary2, we used box monotonicity to remove the context (i. e., program α), which then allows application of Lemma6.

15.1.2 Implementing the Proof The implementation of the tactic for the base case and use case is fairly straight- forward. First apply the structural proof rules (i. e., ∧ and weakening), then

158 15.2. CASE STUDIES apply the proofs of the single components. The initial steps of the proof of the induction step could almost be implemented directly as a tactic. However, the proof steps in Fig. 14.2a require detailed knowledge of the exact structure of the respective formulas, which complicates automatic verification. The dropping of a specific part requires the fragmentation of sequential compositions to separate boxes, followed by a reassembling of the remaining boxes to sequential compositions after the removal. Especially rotation of tests and assignments in steps 7 and 10 require a great number of decompositions and compositions, and multiple applications of the correct part of Lemma7. For the proof to close, we have to ensure that the resulting formula has the exact same structure as (14.73), which again requires a larger number of decomposition and composition steps.

Using the Implementation. The user provides control, plant and the contract for the individual components, and a tactic to proof that each component obeys its respective contract. The implementation uses the provided information and follows the steps as depicted above to derive a tactic, which can be used to automatically verify the composite system.

15.2 Case Studies

To evaluate our approach, we use the running example of a remote-controlled robot (RC robot) and revisit prior case studies on the European Train Con- trol System (i. e., ETCS) [102], two-component robot collision avoidance (i. e., Robix) [71], and adaptive cruise control (i. e., LLC) [63]. In ETCS, a radio-block controller (RBC) communicates speed limits to a train, i.e., it requires the train to have at most speed d after some point m. The RBC multi-port change contract relates distances m, m− and demanded speeds d, d− in input assumptions/output guarantees of the form d ≥ 0 ∧ (d−)2 − d2 ≤ 2b(m − m−) ∧ state = drive, thus avoiding physically impossible maneuvers. In Robix, a robot measures the position of a moving obstacle with a maximum speed S. The obstacle guarantees to not move further than S · (t − t−) in either axis between measurements, using a delay contract. In LLC, a follower car measures both speed vl and position xl of a leader car, with maximum acceleration A and braking capabilities B. Hence, we use a − − multi-port delay contract with properties of the form 2·(xl−xl ) ≥ vl+vl ·t∧0 ≤ − vl ∧ −B · t ≤ vl − vl ≤ A · t tying together speed change and position progress.

15.2.1 Results Table 15.1 summarizes the experimental results of the component-based approach in comparison to monolithic models in terms of duration and degree of proof automation. The column Contract describes the kind of contract used in the case study (i. e., multiport, delay contract or change contract), as well as whether or not the models use non-linear differential equations. The column

159 CHAPTER 15. EVALUATION

Table 15.1: Experimental results for case studies

Contract Automation Duration [s]

Mono- Mono-

Multi Change Delay Non- linear C1 C2 Th. lithic C1 C2 Th. Sum lithic RC Robot XXXXX 32 101 56 189 1934 ETCS [102] XXXXXX 127 608 179 873 15306 Robix [71] XX (31) XX (96) 469 117 132 718 902 LLC [63] XXX (50) X (131) 135 351 267 753 568

Automation indicates fully automated proofs with checkmarks; it indicates the number of built-in tactics composed to form a proof script when user input is required. The column Duration compares the proof duration, using Z3 [77] as a back-end decision procedure to discharge arithmetic. The column Sum sums up the proof durations for the components (columns C1 and C2) and Theorem4 (column Th., i. e., checking compatibility, condition (14.53) and the execution of our composition proof). Checking the composition proof is fully automated, following the proof steps of Theorem4. All measurements were conducted on an Intel i7-6700HQ [email protected] GHz with 16GB memory.

15.2.2 Discussion Tele-operated Robot (RC Robot). The tele-operated robot example (cf. Section 5.3), which was used as a running example throughout Chapter 14 uses delay contracts and was proved automatically. The proof for the monolithic system took more than 10 times longer than for the component-based version using our approach.

European Train Control System (ETCS). The ETCS case study used a multi-port change contract, which was verified automatically using KeYmaera X. Even though the train component C2 took much longer than the controller component C1, the proof duration of our component-based approach is almost 20 times shorter than for the monolithic approach.

Two-component Robot Collision Avoidance (Robix). The Robix case study used delay contracts and required the use of non-linear ODE’s to model the robots movement. In this case both versions—the component-based version (i. e., the robot component) and the monolithic version—required manual guidance to complete the proof. While the proofs for the obstacle component and the theorem (including side conditions) finished automatically, the proof for the robot required 31 manual tactic applications. The monolithic proof required

160 15.3. CONCLUSION AND OPEN ISSUES more than three times as many manual steps. Due to the optimizations introduced in the long tactic for the monolithic proof, the proof durations are almost equal.

Adaptive Cruise Control (LLC). Finally, the LLC used a multi-port delay contract, where the follower component and the monolithic system required human guidance. The number of manual proof steps for the monolithic approach is almost three times the number required for the component-based approach. Again the proof durations are almost equal.

Summary. In summary, the results indicate that our verification approach improves performance and reduces the size of the user-provided proof scripts. When the proof automation of KeYmaera X verifies the contracts, our component-based approach outperformed the monolithic approach by more than a factor of 10, cf. RC Robot and ETCS. When manual proof steps (i. e., manual application of tactics) are required, the proof duration of the component-based approach and the monolithic approach are almost equal. However, the number of manual steps needed to verify the contracts reduces by a factor of almost 3, when using our component-based approach. With respect to our goals set initially, the results are very promising. Ver- ification complexity is reduced, as indicated by the reduced number ofman- ual proof steps. The reduction of proof duration and number of manual proof steps furthermore increases maintainability. Especially the reuse of components, which required manual proof steps when verifying their contracts, leads to an increase of reusability. For instance, consider the Robix example: If a similar system with a different type of obstacle must be verified, the robot component can be reused, i. e., the robot proof does not have to be repeated. Assuming that the new obstacle component can also be verified automatically, only the theorem (including side conditions) must be re-verified, as opposed to the monolithic version, where a new manual proof must be found for the new combination of components.

15.3 Conclusion and Open Issues

In this part, we presented a fundamentally extended approach for component- based modeling and verification of CPS that again splits a CPS into components, but now allows contracts to reason about the rate of change of values on ports. Furthermore, it now allows communication using multi-ports and still transfers the component contracts to a composite contract. We have demonstrated the capabilities of the approach in Section 15.2, where we applied the approach to CPS case studies, which were previously analyzed in a monolithic fashion. The results are promising and show that our approach can reduce the verification effort and time. Fig. 15.1 summarizes the capabilities of the approach presented in this part of the thesis and compares them to the capabilities of the previous approaches

161 CHAPTER 15. EVALUATION of PartII and PartIII. Besides unified components and interfaces, this approach allows multi-ports. Following our classification of contracts from Section 3.1.3, the approach additionally supports change- and delay contracts. Composition is however (again following Section 3.1.3) still limited to instantaneous and lossless communication.  supported  not supported Part 1 Part 2 Part 3 Traffic Contracts Global Contracts Change/Delay Components unified    Interfaces unified    ports (flow only)   multi-ports    Contracts global (flow only)   change    delay    Composition instantaneous (flow only)   delayed    lossless (flow only)   lossy   

 supported  not supported

Figure 15.1: Capabilities of the approach with regard to the requirements presented in Section 3.3.

162 Part V

Final Remarks

163

Chapter 16

Lossy Communication

Composition operations so far focused on modeling instantaneous, lossless communication, to immediately transfer exact values from output ports to connected input ports. In this chapter, we introduce a concept for an instantaneous, lossy communication to transfer values immediately but not necessarily exact. This resembles a measurement error, when values are measured with sensors. Throughout this chapter we highlight the necessary changes to the definitions and theorems of Chapter 14 for introducing lossy communication. A new type of communication changes the way how components with interfaces and their contracts are composed. Thus, we have to introduce lossy communication into the parallel composition operation, as the port assignments are no longer exact but distorted by a bounded error. We model such an error through introduction of an error variable λ, which is chosen non- deterministically and bounded by an error bound Λ. The error is then added to the transmitted value resulting in bounded lossy communication.

16.1 Parallel Composition with Lossy Commu- nication

Parallel composition with lossy communication is defined as in Def. 20, except that communication can now be lossy for any number of connected ports. Definition 22 (Parallel Composition with Lossy Communication). Parallel composition with lossy communication is defined as in Def. 20, except for port X assignments, which are extended with lossy connections for all {vj, . . . , vr} = I

components’ ports def    ports ≡ ports1; ports2; ... ; portsn;

λj := ∗;? |λj| ≤ Λj; vj := X (vj) + λj; ... ; λr := ∗;? |λr| ≤ Λr; vr := X (vr) + λr    connected inputs where

165 CHAPTER 16. LOSSY COMMUNICATION

global • Λl is a non-negative global constant (i. e., Λl is added to V and Λl ≥ 0 is added as a conjunction to the global property Ω), representing the maximum error, for all l ∈ {j . . . r}, and

• λl is the error variable, which may neither be part of any component’s ⋃ variables, i. e., λl ∈/ 1≤i≤n Vi, nor used for another lossy communication, i. e., λl ̸= λk, for all l ̸= k ∈ {j . . . r}.

Def. 22 allows an arbitrary combination of lossless and lossy communication through ports, as lossless communication can be achieved with a maximum error Λ = 0. The variable λ is neither part of the global variables nor part of any component’s variables because otherwise the composition operation would influence the component behavior, since lossy composition assigns a newvalue to λ. A unique error variable is needed for each lossy connection so that the order of port assignments remains irrelevant. At the same time, the error bound Λ is a global constant and can potentially be used for multiple pairs of connected ports.

16.2 Compatibility with Lossy Communication

Next we have to consider compatibility of components and interfaces. The compatibility proof obligation as defined in Def. 21 is focused on lossless communication, and thus assumes that previous values of the connected ports match and that the current values are transferred instantaneous and lossless through deterministic assignment. For lossy communication however, values are now distorted by a bounded error and thus, neither current nor previous values necessarily match exactly.

Definition 23 (Compatible Lossy Composite). A composite of n components ( ∆ ∆ ∆ ∆ ) with admissible interfaces (C1 , I1 )∥...∥(Cn , In ) is compatible iff for input X X in ∆ X out ∆ ports v ∈ I ∩V i from Ii connected to X (v) ∈ O ∩V j from Ij using lossy communication, dL formula ( ) ∆ def ( ) CPO(Ii ) ≡ |λ| ≤ Λ ∧ pre(v) = pre(X (v)) + λ ∧ Ω →

out in [λ := ∗;? |λ| ≤ Λ; v := X (v) + λ](πj (X (v)) → πi (v)) is valid over (vectorial) equalities and assignments.

Note that the global property Ω may contain further restriction on the maximum error, e. g., Λ ≥ 0. For lossless communication exact previous- and new values are guaranteed. Lossy communication allows a measurement error for previous values. The measurement error introduced by the newly transferred values can be different, but is bound by a maximum error.

166 16.3. LOSSY COMPOSITION RETAINS CONTRACTS

16.3 Parallel Composition with Lossy Commu- nication Retains Contract

Finally, we have to ensure that the composition of compatible components with lossy communication still retains the contract. Theorem 5 (Lossy Composition Retains Contracts). Lossy composition retains the contract as in Theorem4, except that the bootstrapping of connected ports can now be lossy: def φp ≡ |λ| ≤ Λ ∧ v = X (v) + λ .

The proof for Theorem5 follows the same sketch as the proof for Theorem4, but differs in the following details: 1. Compatibility proof obligations in (14.70)–(14.71) must be updated according to Def. 23. 2. Invariance of φp still follows immediately, since new values with a bounded measurement error are assigned to connected ports in portsi. 3. As Def. 22 guarantees that ports with lossy communication operate on distinct bound variables and Lemma7 allows arbitrary reordering of un- related non-deterministic assignments and tests (as used for lossy composition), step (2) of Fig. 14.2a follows. 4. In steps (3)–(4) of the proof of Fig. 14.2a the free- and bound variables are disjoint by Def. 22. 5. In step (6) of the proof of Fig. 14.2a, we split the whole port communication, i. e., the error assignment with the test and the following port assignment, from the remaining ports. 6. In step (9) of the proof of Fig. 14.2a, we use Lemma3 to replace the lossy assignment with a non-deterministic one. Additionally, we use Lemma1 to drop the error assignment with the test. 7. Step (8) of the proof of Fig. 14.2a, follows according to Fig. 16.1. We use the compatibility proof obligation for lossy communication to remove the program parts. Note that at step L.1 invariance of |λj| ≤ Λj must be p shown and follows immediately from φ and the fact that λj is no longer bound.

16.4 Example

We consider a simple example of two components with interfaces: a sensor measuring the position of an object and a controller processing a received object

167 CHAPTER 16. LOSSY COMMUNICATION ) j λ ) ) j )) + v j ( v ( in 1 π X ( → pre )) j v ) = ( j v X ( ( out 2 pre ) π j ]( ( λ ] j ... λ ; j v )) + j ) + v j ( v ) := ( X j ( v X ) ( j ) λ pre := j pre j λ ; v ; ) = )) + j j ... v v Λ ( )) + ( ); j j X v ( v ( pre | ≤ ( j X ∧ X λ ( pre | j Λ ;? pre ) = ∗ )) := v j ( | ≤ := v ) = j ( j j λ v | pre λ X ( ( ]( ][ ]( 2 pre ...... pre ; ; ∆ ]( ][ ][ 1 3 3 3 ... [ [∆ [∆ [∆ [∆ ∗ ⊢ ⊢ ⊢ ⊢ ⊢ j p p p p λ , φ , φ , φ , φ 2 2 2 2 ) + j , ϕ , ϕ , ϕ , ϕ 1 1 1 1 v ( ϕ ϕ ϕ ϕ X = j v ∧ ,... 2 , ϕ 1 ϕ def def L.1 CPO

Figure 16.1: Relax the test to πin using compatibility for lossy communication. vj − ′ ∗ We abbreviate [...] ≡ [ctrl1; ctrl2][t := t][(t = 1, plant3)][in1] for space reasons.

168 16.4. EXAMPLE position. For the example we disregard the components and solely focus on the interfaces. The sensor has one output port xout, where it provides the measured position, which is guaranteed to be within the interval 0 ≤ xout ≤ Xsen. The controller has one input port xin, where it reads an object position for further processing. It requires the position to be within the interval −Xctr ≤ xin ≤ Xctr. The global property for the system is Xsen ≥ 0 ∧ Xctr ≥ 0, i. e., both interval bounds must be non-negative. We now compose the sensor and the controller using lossy communication. The composition operation does not influence the component and interface definitions, but changes the compatibility proof obligation. We add the error bound to the global property following Def. 22

Ω ≡ Xsen ≥ 0 ∧ Xctr ≥ 0 ∧ Λ ≥ 0 .

−푿풄풕풓≤ 풙풊풏 ≤ 푿풄풕풓 ≥ 횲 ≥ 횲

−푿풄풕풓 ퟎ 푿풔풆풏 푿풄풕풓

ퟎ ≤ 풙풐풖풕 ≤ 푿풔풆풏

Figure 16.2: The (green) interval, describing the guaranteed values as produced by the sensor, has to be small enough to fit into the (blue) interval describing the required values as assumed by the controller. If Xctr is at least Λ larger than Xctr and if Xctr is at least Λ, the ports are compatible. The additional global property Xctr ≥ Λ + Xsen ensures both conditions.

In order to verify the compatibility proof obligation, we extend the global property to ensure that the error bound of the sensor is small enough to ensure valid values for the controller, even though the transmission is lossy, cf. Fig. 16.2,

Ω ≡ Xsen ≥ 0 ∧ Xctr ≥ 0 ∧ Λ ≥ 0 ∧ Xctr ≥ Λ + Xsen . The resulting compatibility proof obligation is as follows (∆-ports are not required for this example and thus, previous values are omitted):

Xsen ≥ 0 ∧ Xctr ≥ 0 ∧ Λ ≥ 0 ∧ Xctr ≥ Λ + Xsen ( → [λ := ∗;? |λ| ≤ Λ; xin := xout + λ] ) (0 ≤ xout ≤ Xsen → −Xctr ≤ xin ≤ Xctr)

As we verified this property with KeYmaera X, we know that the portsare compatible and thus, local safety properties transfer to the composed system, using lossy composition.

169 CHAPTER 16. LOSSY COMMUNICATION

16.5 Conclusion

In this chapter, we introduced a lossy composition operation with bounded error. Such a lossy composition operation can be used to represent sensor uncertainty or unreliable communication channels (e. g., as suggested in Section 5.3). Fig. 16.3 shows the capabilities of our approach, including the extensions of this chapter. Delayed composition remains for future work, which we will further elaborate in Section 17.2.  supported  not supported Part 1 Part 2 Part 3 Extensions Traffic Contracts Global Contracts Change/Delay Error-prone Components unified     Interfaces unified     ports (flow only)    multi-ports     Contracts global (flow only)    change     delay     Composition instantaneous (flow only)    delayed     lossless (flow only)    lossy    

 supported  not supported

Figure 16.3: Capabilities of the approach, including extensions, with regard to the requirements presented in Section 3.3.

170 Chapter 17

Conclusion and Future Work

This final chapter concludes the thesis and points out potential directions for future work.

17.1 Conclusion

This thesis approaches the issues of verification of complex CPS using a component-based modeling and verification approach. To that end, we introduced three approaches aimed at different aspects of component-based CPS modeling. The first approach (PartII) specifically targets the modeling and verification of traffic networks based on macroscopic traffic models, i. e., modeling trafficon a high level as flow. Although components themselves have not been formally defined in this part, the included interface definitions suffice to show thatmodels of traffic network components, which are composed in a compatible fashion, are always “safe”. In this context “safe” means that the number of cars on a stretch of road does not exceed the road’s capacity (i. e., no overflow occurs). We implemented several example components using hybrid programs and showed that they comply with their corresponding interfaces using dL and KeYmaera. Using our approach, it suffices to perform a simple arithmetic check for compatibility between components in order to ensure a safe traffic network from verified components. Even though the implementation is only a first step with rather simplified models, multiple application areas for such a tool are conceivable: • The tool can be used to model existing traffic networks and analyze their behavior in case of a change of capacities (e. g., caused by roadworks or a closed road). • It can be used for road planing, to analyze in advance how the traffic will propagate through a road network and to check for possible traffic overflows.

171 CHAPTER 17. CONCLUSION AND FUTURE WORK

• The presented Java implementation can be extended with further components, which have to be verified once (e. g., using KeYmaera X) and can then be used in the tool. In PartIII, we extend the first domain-specific approach by introducing a generic component-based modeling and verification approach based on contracts. While the initial domain-specific approach is specifically targeted at traffic flow networks, this approach is no longer restricted to a specificarea of application, but introduces a generic blueprint for component models that can be used with our approach. The interfaces used with these components can contain any number of ports and transfer arbitrary values, not just flow. The respective contracts restrict the behavior of the components and their interfaces to ensure safety on the one hand, and to determine the behavior of the ports on the other hand. However, the description of port behavior in the contracts of this part is limited to conditions over global variables. Such contracts require substantial static independence of the components, and thus, can only show coarse safety properties when components make decisions based on measurements about the behavior of other components. In PartIV we allow contracts to additionally reason about a port’s previous value (i. e., before the current transmission) using so-called change contracts, and furthermore synchronize time throughout components using so-called delay contracts (i. e., the same amount of time passes for all components between port transmissions). Additionally, we introduce multi-ports, which combine multiple ports and allow shared port properties. This kind of contracts can already be used for a broad variety of use cases. Even though the final generic approach with change- and delay contracts subsumes all previous approaches, each approach has its own individual advantages. Change- and delay contracts must be used, if synchronization and the rate of change on a port are needed. If properties solely reason about global properties, global contracts are favorable, as they avoid the introduction of additional internal variables for synchronization of time and storage of previously transmitted values. This can be crucial, as decision procedures like quantifier elimination—which KeYmaera X uses to decide upon the satisfiability of formulas—are doubly-exponential in the number of variables [20][23][29]. Global contracts could also be used to model traffic flow networks in a component-based fashion. However, the traffic approach presented in PartII comes with its own implementation. This implementation allows automatic analysis of traffic flow networks and does not support global (or change- and delay) contracts. Additionally, in PartV we show how to extend our approach with lossy communication. Further types of communication, like delayed communication (cf. Section 3.1.3), are conceivable. As stated in Chapter1, the overall goal was threefold, and comprised reduction of verification complexity and increase of maintainability and reusability. Reduce Verification Complexity: The results of our case studies suggest that our approach improves the verification speed and reduces the number of manual proof steps (cf. Section 12.1 and Section 15.2).

172 17.2. FUTURE WORK

Increase Maintainability: In PartIII (cf. Section 12.1) we have shown that our global contracts can improve maintainability, as the adaptation of a single component no longer requires re-verification of the entire system, but is limited to the proofs of the altered components. Thus, the verification effort for the revised system could be reduced. Similarly, re- verification is limited to local proofs if only a single component model changes in PartII or PartIV.

Increase Reusability: All components verified using our approach are known to satisfy their contracts. These contracts include a specification of input- and output properties that determines how a component might be composed with other components. As long as these rules are obeyed (i. e., compatibility is ensured), each verified component can be reused. In PartII we extensively exploited the reusability introduced by our approach, to create a model of a road network using only three different types of components (cf. Chapter9).

17.2 Future Work

Several future research directions remain.

17.2.1 Identification of Artifacts A standardized procedure for identifying components, interfaces and contracts would be desirable, as so far, these artifacts have to be identified manually by system- and verification experts.

Components. A possible way to support the identification of components is to extract parts of a monolithic model, which operate on a common set of variables. A potential starting point is the separation of the plant into separate systems of ODEs. For instance, in a model of a system, where a robot has to avoid collisions with an obstacle, the part controlling speed and direction of the obstacle could be identified as a component that way, as it is the only part ofthe model, where the speed- and direction variables are altered. Additionally, we have shown three typical ways to split a model into components in Chapter5, namely extraction of reoccurring patterns, extraction of immutable parts, and exploitation of the real-world component structure of the system. For instance, the analysis of multiple traffic network models lead to the identification of typical traffic patterns (e. g., traffic splits, traffic lights).

Interfaces. The identification of the ports of an interface often follows from the previously identified components. For instance, consider the robot collision avoidance system, where the obstacle and the robot have been identified as components. In this example, the robot needs to avoid collisions with the obstacle,

173 CHAPTER 17. CONCLUSION AND FUTURE WORK which requires the obstacle’s position. Thus, the obstacle must provide its position on an output port, and the robot must receive position information on an input port. However, identification of input- and output properties can be more challenging and requires an insight into the respective component behaviors. A rule of thumb is to keep output properties as strict as possible, while input assumptions should rather be lenient. A possible way to support the discovery of input- or output properties might be thorough analysis of the behavior of the respective variable within the component.

Contracts. If a contract for the monolithic system is known, this contract could be split into multiple local contracts for the individual components. If no monolithic contract is available, a safety property for each contract has to be derived individually. A safety specification of a system might be available in some other syntax, language or diagram, which could be translated—ideally supported by an automated tool—to component safety properties. Initial conditions strongly depend on the use-case at hand. Consider again the robot component above: If the system should be analyzed from scratch, the robot’s initial speed might be zero, but if an already moving robot should be analyzed, the initial speed might be any non-negative value.

17.2.2 Delayed Communication Delayed communication becomes important when the components are physically separated. For instance, a sensor measuring the distance between two successive cars always delivers slightly outdated data. One way of implementing a composition operation considering delayed communication could be the introduction of a bounded error, similar to the lossy communication in Chap- ter 16. To account for the time td that has passed since the value was read, the rate of change ρ of the port’s value must be known. The resulting measurement error can then be calculated as τ = td ∗ ρ and bound by some maximum delay |τ| ≤ T , resulting in delayed communicationx ˆ := x + τ. Another way of implementing delayed communication could be to include the possibility that no new value is transferred upon communication, cf. (17.1). (?ξ < Ξ; ξ := ξ + 1) ∪ (ˆx := x; ξ := 0) . (17.1) The left side of the non-deterministic choice in (17.1) represents communication delay, as the delay counter ξ is increased, but no new value is transferred. The delay ξ is bounded by the maximum delay ξ ≤ Ξ. The second branch of the non-deterministic choice transfers a new value and resets the delay counter. That way, the transmission of a new value can be delayed for at most Ξ control cycles. Such a delayed communication could also be used to model packet loss.

17.2.3 Multicast Ports Throughout this thesis we introduced different types of (input and output) ports: In PartII, ports were limited to the transfer of traffic flow. In PartIII, we

174 17.2. FUTURE WORK generalized ports to allow transfer of arbitrary values. In PartIV, we introduced the concept of multi-ports, i. e., groups of ports. However, in each case each output port can only be connected to a single input port (respectively each group of output ports, to a group of input ports of equal size) because connected ports are removed from the respective interfaces. The above behavior resembles the process of putting a plug into a socket: neither the socket, nor the plug can be connected a second time. For instance, the connection of roads, as presented in Section 5.1, represents such a behavior: each road can only be connected to one other road at a time. However, consider the robot collision avoidance system as presented in Sec- tion 5.3. The robot uses an input port to receive the position of the obstacle, which the obstacle provides on an output port. Again, the ports are removed from the interface after connection. In this case however, the ports depict a measurement: the robot measures the position of the obstacle. If further components want to measure the obstacle’s position, further output ports producing the same value, i. e., the obstacles position, must be added to the obstacle. To overcome such a redundant creation of output ports, so-called multicast ports could be introduced, which are output ports that can be connected to multiple input ports in consecutive compositions. Introduction of multicast ports would at least require adaptation of the respective composition operation (i. e., do not remove the port from the interface upon connection).

17.2.4 Improved Tool Support Improved tool support does not entail introduction of fundamentally novel concepts, but merely the implementation of presented concepts.

Implementation PartII (SAFE-T). As part of our first approach, we provided the Java tool SAFE-T, which can be used to analyze traffic networks, cf. Section 9.2. So far the tool supports the three types of components verified in Chapter9 (i. e., traffic merge, traffic split, traffic light), and additional start- and end components that produce and accept flow. However, further component types are conceivable. Components modeling multi-lane traffic merge/split with an adjustable number of inflows or outflows, roundabouts or other common traffic patterns would simplify the task of building larger traffic networks with complex intersections. The currently implemented models are furthermore rather simplified and do not consider common traffic phenomena like shock- waves. The inclusion of further component types, as well as the adaptation or improvement of current component implementations requires the introduction of a new interface, the preparation of a new component model, the verification of the safety of interface and model and the implementation of the component for SAFE-T. Specifically the preparation of a new component model canbe challenging, as the component comprises the actual behavior of the traffic pattern, e. g., the actual behavior of traffic flow in a roundabout. The inclusion of traffic patterns with adjustable numbers of inflows and outflows, like multi-lane

175 CHAPTER 17. CONCLUSION AND FUTURE WORK merge/split or roundabouts, furthermore requires the introduction of dynamic interfaces parametrized with the desired number of ports.

Implementation PartIII and PartIV. As part of our third approach (cf. Section 15.1) we provide a Scala-based implementation supporting the automatic derivation of a proof for a composed system, given the proofs for the individual components. So far, the tool exclusively supports instantaneous, lossless composition of two delay contracts. Thus, natural extensions of the tool are the additional implementation of global- and change contracts, the inclusion of further composition operations, and to allow composition of an arbitrary number of components. As the current tactic implementation strongly relies on structural information about the involved component contracts, which is for instance used when rotating port connections (cf. Fig. 14.2a), implementation of such extensions is challenging. Besides fine-grained bookkeeping of the component structure, it might entail definition of additional lemmas, e. g., to allow alterna- tion of larger programs (as opposed to the alternations introduced in Lemma7). Furthermore, due to limitations of the underlying KeYmaera X implementation, the tool is currently not able to derive a composite proof, if one or more of the involved components have circular dependencies among their differential equations. Consider, for instance, an example with two components, with the following continuous parts:

′ ′ plant1 ≡ x = y, y = x&true ′ plant2 ≡ z = 1&z ≤ 42

After composition, the plant of the composite component is:

′ ′ ′ plant3 ≡ x = y, y = x, z = 1&z ≤ 42

In the proof of Theorem4—which is used as blueprint for the implementation— we use Lemma2 to remove all parts of the ODE, which belong to one of the components. Lemma2 bases on the differential ghost axiom, which is defined for vectors of variables (or rather systems of ODE’s) [100], but implemented only for a single ODE. Thus, in our implementation we repeatedly call this axiom to remove unnecessary ODEs one by one. In the example, such a step-by-step ′ approach does not work because removing only x = y from plant3 without also removing y′ = x changes the behavior of the system:

∗ ′ ′ plant3 ≡ y = x, z = 1&z ≤ 42

∗ In plant3, x is now a constant unlike before, where it was supposed to change according to x′ = y. For future work, this issue could be resolved by extending the capabilities of KeYmaera X.

176 List of Figures

2.1 Conceptual Reference Model...... 11

3.1 Generic Structure of Component and Interface ...... 23 3.2 Port Connection ...... 25 3.3 Multi-port Compatibility ...... 26 3.4 Levels of Contracts...... 28 3.5 Dimensions of Communication ...... 29 3.6 Strategy...... 30

5.1 Extraction of Traffic Patterns...... 45 5.2 Derivation of Traffic Components and Interfaces ...... 46 5.3 Composition of Traffic Components...... 47 5.4 Example: Vehicle Cruise Control...... 48 5.5 Example: Tele-operated Robot ...... 51 5.6 System Safety vs. Local Safety ...... 52

6.1 Hybrid Time: Sample Trajectory of Position...... 55 6.2 Hybrid Time: Flat Trajectory of Position ...... 55 6.3 Proof Rules...... 56

9.1 SAFE-T: Highway Exit ...... 78 9.2 SAFE-T: Spillback Analysis Example 1 ...... 80 9.3 SAFE-T: Spillback Analysis Example 2 ...... 81 9.4 SAFE-T: Spillback Analysis Example 3 ...... 81 9.5 Capabilities – Traffic Contracts...... 83

10.1 Running Example: Global Contracts...... 88

11.1 Example: Engine Component and Interface...... 93 11.2 Example: Cruise Controller Component and Interface ...... 99 11.3 Example: Composed Cruise Control System ...... 100

12.1 Example: Vehicle Cruise Control with Autonomous Controller . . 115 12.2 Example: Vehicle Cruise Control with Guided Controller . . . . . 118

177 LIST OF FIGURES

12.3 Capabilities – Global Contracts...... 122

13.1 Robot-Obstacle: Global Contract...... 125 13.2 Robot-Obstacle: Delay Contract ...... 126 13.3 Running Example: Change- and Delay Contracts ...... 127

14.1 Robot-Obstacle Areas ...... 133 14.2 Proof Steps – Theorem4...... 152

15.1 Capabilities – Change- and Delay Contracts ...... 162

16.1 Proof Steps – Theorem5...... 168 16.2 Example: Lossy Composition ...... 169 16.3 Capabilities – Lossy Communication ...... 170

178 List of Algorithms

9.1 Traffic Light Component...... 70 9.2 Traffic Merge Component...... 72 9.3 Fair Traffic Merge Component...... 74 9.4 Alternative Fair Traffic Merge Component...... 75 9.5 Traffic Split Component ...... 76 12.6 Engine Component and Interface ...... 116 12.7 Autonomous Cruise Controller Component and Interface . . . . 117 12.8 Guided Cruise Controller Component and Interface ...... 119 14.9 Remote Control Component...... 131 14.10 Obstacle Component ...... 132 14.11 Robot Component...... 132 14.12 Remote Control Interface...... 134 14.13 Obstacle Interface...... 136 14.14 Robot Interface ...... 136

179

Bibliography

[1] Alur, R.: Formal verification of hybrid systems. In: Chakraborty, S., Jerraya, A., Baruah, S.K., Fischmeister, S. (eds.) Proceedings of the 11th International Conference on Embedded Software, part of the Seventh Em- bedded Systems Week. pp. 273–278. ACM (2011), http://doi.acm.org/ 10.1145/2038642.2038685 [2] Alur, R., Courcoubetis, C., Dill, D.L.: Model-checking for real-time systems. In: Proceedings of the Fifth Annual Symposium on Logic in Com- puter Science. pp. 414–425. IEEE (1990), http://dx.doi.org/10.1109/ LICS.1990.113766 [3] Alur, R., Courcoubetis, C., Henzinger, T.A., Ho, P.H.: Hybrid automata: An algorithmic approach to the specification and verification of hybrid systems. In: Grossman, R.L., Nerode, A., Ravn, A.P., Rischel, H. (eds.) Hybrid Systems, Lecture Notes in Computer Science, vol. 736, pp. 209– 229. Springer (1993), http://dx.doi.org/10.1007/3-540-57318-6_30 [4] Alur, R., Dang, T., Ivancic, F.: Reachability analysis of hybrid systems via predicate abstraction. In: Tomlin, C., Greenstreet, M.R. (eds.) Hybrid Systems Computation and Control, 5th International Workshop, Proceed- ings. Lecture Notes in Computer Science, vol. 2289, pp. 35–48. Springer (2002), http://dx.doi.org/10.1007/3-540-45873-5_6 [5] Alur, R., Dill, D.L.: A theory of timed automata. Theoretical Com- puter Science 126(2), 183–235 (1994), http://dx.doi.org/10.1016/ 0304-3975(94)90010-8 [6] Alur, R., Grosu, R., Lee, I., Sokolsky, O.: Compositional refinement for hierarchical hybrid systems. In: Di Benedetto, Maria Domenica, Sangiovanni-Vincentelli, A.L. (eds.) Hybrid Systems: Computation and Control, 4th International Workshop, Proceedings. Lecture Notes in Com- puter Science, vol. 2034, pp. 33–48. Springer (2001), http://dx.doi.org/ 10.1007/3-540-45351-2_7 [7] A¸stefanoaei,L., Bensalem, S., Bozga, M.: A compositional approach to the verification of hybrid systems. In: Abrah´am,E.,´ Bonsangue, M.M., Johnsen, E.B. (eds.) Theory and Practice of Formal Methods - Essays

181 BIBLIOGRAPHY

Dedicated to Frank de Boer on the Occasion of His 60th Birthday. Lecture Notes in Computer Science, vol. 9660, pp. 88–103. Springer (2016), https: //doi.org/10.1007/978-3-319-30734-3_8 [8] Bauer, S.S., David, A., Hennicker, R., Guldstrand Larsen, K., Legay, A., Nyman, U., Wasowski, A.: Moving from specifications to contracts in component-based design. In: de Lara, J., Zisman, A. (eds.) Fundamen- tal Approaches to Software Engineering - 15th International Conference, Proceedings. Lecture Notes in Computer Science, vol. 7212, pp. 43–58. Springer (2012), http://dx.doi.org/10.1007/978-3-642-28872-2_3 [9] Baumgartner, N., Mitsch, S., M¨uller,A., Retschitzegger, W., Salfinger, A., Schwinger, W.: A tour of BeAware! - A situation awareness framework for control centers. Information Fusion 20, 155–173 (2014), http://www. sciencedirect.com/science/article/pii/S156625351400013X [10] Bengtsson, J., Larsen, K.G., Larsson, F., Pettersson, P., Yi, W.: UP- PAAL - A tool suite for automatic verification of real-time systems. In: Alur, R., Henzinger, T.A., Sontag, E.D. (eds.) Proceedings of the DI- MACS/SYCON Workshop. Lecture Notes in Computer Science, vol. 1066, pp. 232–243. Springer (1996), http://dx.doi.org/10.1007/BFb0020949 [11] Bengtsson, J., Yi, W.: Timed automata: Semantics, algorithms and tools. In: Desel, J., Reisig, W., Rozenberg, G. (eds.) Lectures on Concurrency and Petri Nets, Advances in Petri Nets: This tutorial volume originates from the 4th Advanced Course on Petri Nets. Lecture Notes in Computer Science, vol. 3098, pp. 87–124. Springer (2003), http://dx.doi.org/10. 1007/978-3-540-27755-2_3 [12] Benveniste, A., Caillaud, B., Ferrari, A., Mangeruca, L., Passerone, R., Sofronis, C.: Multiple viewpoint contract-based specification and design. In: Boer, F.S.d., Bonsangue, M.M., Graf, S., Roever, W.P.d. (eds.) Formal Methods for Components and Objects, 6th International Symposium. Lec- ture Notes in Computer Science, vol. 5382, pp. 200–225. Springer (2007), http://dx.doi.org/10.1007/978-3-540-92188-2_9 [13] Benvenuti, L., Bresolin, D., Collins, P., Ferrari, A., Geretti, L., Villa, T.: Assume-guarantee verification of nonlinear hybrid systems with Ariadne. International Journal of Robust and Nonlinear Control 24(4), 699–724 (2014), http://dx.doi.org/10.1002/rnc.2914 [14] Bergstra, J.A., Klop, J.W.: Algebra of communicating processes with abstraction. Theoretical Computer Science 37, 77–121 (1985), http:// dx.doi.org/10.1016/0304-3975(85)90088-X [15] Berkenk¨otter, K., Bisanz, S., Hannemann, U., Peleska, J.: The Hy- bridUMl profile for UML 2.0. International Journal on Software Tools for Technology Transfer 8(2), 167–176 (2006), http://dx.doi.org/10. 1007/s10009-005-0211-z

182 BIBLIOGRAPHY

[16] Bogomolov, S., Frehse, G., Greitschus, M., Grosu, R., Pasareanu, C.S., Podelski, A., Strump, T.: Assume-guarantee abstraction refinement meets hybrid systems. In: Yahav, E. (ed.) Hardware and Software: Verification and Testing - 10th International Haifa Verification Conference. Lecture Notes in Computer Science, vol. 8855, pp. 116–131. Springer (2014), http: //dx.doi.org/10.1007/978-3-319-13338-6_10

[17] Bornot, S., Sifakis, J.: On the composition of hybrid systems. In: Hen- zinger, T.A., Sastry, S. (eds.) Hybrid Systems: Computation and Control, First International Workshop, Proceedings. Lecture Notes in Computer Science, vol. 1386, pp. 49–63. Springer (1998), http://dx.doi.org/10. 1007/3-540-64358-3_31

[18] Broman, D., Lee, E.A., Tripakis, S., Törngren, M.: Viewpoints, formalisms, languages, and tools for cyber-physical systems. In: Hardebolle, C., Syriani, E., Sprinkle, J., Mészáros,T. (eds.) Proceedings of the 6th Inter- national Workshop on Multi-Paradigm Modeling, MPM at MoDELS. pp. 49–54. ACM (2012), http://doi.acm.org/10.1145/2508443.2508452

[19] Carloni, L.P., Passerone, R., Pinto, A., Sangiovanni-Vincentelli, A.L.: Languages and tools for hybrid systems design. Foundations and Trends in Electronic Design Automation 1(1/2), 1–193 (2006), https://doi.org/ 10.1561/1000000001

[20] Caviness, B.F., Johnson, J.R. (eds.): Quantifier Elimination and Cylin- drical Algebraic Decomposition. Texts and Monographs in Symbolic Com- putation, A Series of the Research Institute for Symbolic Computa- tion, Johannes-Kepler-University, Linz, Austria, Springer, Vienna, Aus- tria (1998), http://dx.doi.org/10.1007/978-3-7091-9459-1

[21] Cellier, F.: Continuous System Modeling. Springer (1991), http:// books.google.at/books?id=c8pODAtyEUAC

[22] Clarke, E.M., Wing, J.M.: Formal methods: State of the art and future directions. ACM Computing Surveys 28(4), 626–643 (1996), http://doi. acm.org/10.1145/242223.242257

[23] Collins, G.E.: Quantifier elimination for real closed fields by cylindri- cal algebraic decomposition. In: Barkhage, H. (ed.) Automata Theory and Formal Languages, 2nd GI Conference. Lecture Notes in Computer Science, vol. 33, pp. 134–183. Springer (1975), http://dx.doi.org/10. 1007/3-540-07407-4_17

[24] Crnkovic, I., Sentilles, S., Vulgarakis, A., Chaudron, M.R.V.: A classification framework for software component models. IEEE Transactions on Software Engineering 37(5), 593–615 (2011), http://dx.doi.org/10. 1109/TSE.2010.83

183 BIBLIOGRAPHY

[25] Daganzo, C.F.: The cell transmission model, part II: Network traffic. Transportation Research Part B: Methodological 29(2), 79– 93 (1995), http://www.sciencedirect.com/science/article/pii/ 019126159400022R [26] Damm, W., Dierks, H., Oehlerking, J., Pnueli, A.: Towards component based design of hybrid systems: Safety and stability. In: Manna, Z., Peled, D.A. (eds.) Time for Verification, Essays in Memory of Amir Pnueli. Lec- ture Notes in Computer Science, vol. 6200, pp. 96–143. Springer (2010), https://doi.org/10.1007/978-3-642-13754-9_6 [27] Damm, W., Möhlmann,E., Rakow, A.: A design framework for con- current hybrid system controllers with safety and stability annotations: Reports of SFB/TR 14 AVACS, http://www.avacs.org/fileadmin/ Publikationen/Open/avacs_technical_report_105.pdf [28] Damm, W., Möhlmann, E., Rakow, A.: Component based design of hybrid systems: A case study on concurrency and coupling. In: Fränzle, M., Lygeros, J. (eds.) 17th International Conference on Hybrid Systems: Computation and Control (part of CPS Week). pp. 145–150. ACM (2014), http://doi.acm.org/10.1145/2562059.2562120 [29] Davenport, J.H., Heintz, J.: Real quantifier elimination is doubly exponential. Journal of Symbolic Computation 5(1-2), 29–35 (1988), http: //dx.doi.org/10.1016/S0747-7171(88)80004-X [30] David, R., Alla, H.: On hybrid petri nets. Discrete Event Dy- namic Systems 11(1-2), 9–40 (2001), http://dx.doi.org/10.1023/A: 1008330914786 [31] Donzé,A., Frehse, G.: Modular, hierarchical models of control systems in SpaceEx. In: European Control Conference 2013. pp. 4244–4251. IEEE (2013) [32] Drumea, A., Popescu, C.: Finite state machines and their applications in software for industrial control. In: Electronics Technology: Meeting the Challenges of Electronics Technology Progress, 27th International Spring Seminar on. vol. 1, pp. 25–29 (2004), https://doi.org/10.1109/ISSE. 2004.1490370 [33] Duggirala, P.S., Mitra, S., Viswanathan, M., Potok, M.: C2E2: A verification tool for stateflow models. In: Baier, C., Tinelli, C. (eds.) Tools and Algorithms for the Construction and Analysis of Systems - 21st International Conference, Proceedings. Lecture Notes in Computer Sci- ence, vol. 9035, pp. 68–82. Springer (2015), http://dx.doi.org/10. 1007/978-3-662-46681-0_5 [34] Eker, J., Janneck, J.W., Lee, E.A., Liu, J., Liu, X., Ludvig, J., Neuen- dorffer, S., Sachs, S.R., Xiong, Y.: Taming heterogeneity - The Ptolemy

184 BIBLIOGRAPHY

approach. Proceedings of the IEEE 91(1), 127–144 (2003), https://doi. org/10.1109/JPROC.2002.805829 [35] Evans, J.L., Elefteriadou, L., Gautam, N.: Probability of breakdown at freeway merges using markov chains. Transportation Research Part B: Methodological 35(3), 237–254 (2001), http://www.sciencedirect.com/ science/article/pii/S0191261599000491 [36] Fan, C., Qi, B., Mitra, S., Viswanathan, M., Duggirala, P.S.: Auto- matic reachability analysis for nonlinear hybrid models with C2E2. In: Chaudhuri, S., Farzan, A. (eds.) Computer Aided Verification - 28th In- ternational Conference, Proceedings. Lecture Notes in Computer Science, vol. 9779, pp. 531–538. Springer (2016), http://dx.doi.org/10.1007/ 978-3-319-41528-4_29 [37] Fitting, M.: First-Order Logic and Automated Theorem Proving. Texts and Monographs in Computer Science, Springer (1990), http://dx.doi. org/10.1007/978-1-4684-0357-2 [38] Frehse, G.: PHAVer: Algorithmic verification of hybrid systems past HyTech. In: Morari, M., Thiele, L. (eds.) Hybrid Systems: Compu- tation and Control, 8th International Workshop, Proceedings. Lecture Notes in Computer Science, vol. 3414, pp. 258–273. Springer (2005), https://doi.org/10.1007/978-3-540-31954-2_17 [39] Frehse, G., Le Guernic, C., Donz´e,A., Cotton, S., Ray, R., Lebeltel, O., Ripado, R., Girard, A., Dang, T., Maler, O.: SpaceEx: Scalable verification of hybrid systems. In: Gopalakrishnan, G., Qadeer, S. (eds.) Computer Aided Verification - 23rd International Conference, Proceed- ings. Lecture Notes in Computer Science, vol. 6806, pp. 379–395. Springer (2011), http://dx.doi.org/10.1007/978-3-642-22110-1_30 [40] Frehse, G., Zhi Han, Krogh, B.: Assume-guarantee reasoning for hybrid I/O-automata by over-approximation of continuous interaction. In: 43rd IEEE Conference on Decision and Control, CDC. vol. 1, pp. 479–484 (2004), https://doi.org/10.1109/CDC.2004.1428676 [41] Fritzson, P., Engelson, V.: Modelica - A unified object-oriented language for system modelling and simulation. In: Jul, E. (ed.) Object-Oriented Programming, 12th European Conference. Lecture Notes in Computer Science, vol. 1445, pp. 67–90. Springer (1998), http://dx.doi.org/10. 1007/BFb0054087 [42] Fulton, N., Mitsch, S., Quesel, J.D., V¨olp, M., Platzer, A.: KeY- maera X: An axiomatic tactical theorem prover for hybrid systems. In: Felty, A.P., Middeldorp, A. (eds.) 25th International Conference on Au- tomated Deduction, Proceedings. Lecture Notes in Computer Science, vol. 9195, pp. 527–538. Springer (2015), http://dx.doi.org/10.1007/ 978-3-319-21401-6_36

185 BIBLIOGRAPHY

[43] Giese, H., Henkler, S.: A survey of approaches for the visual model- driven development of next generation software-intensive systems. Journal of Visual Languages & Computing 17(6), 528–550 (2006), http://www. sciencedirect.com/science/article/pii/S1045926X06000589

[44] G¨oßler,G., Sifakis, J.: Composition for component-based modeling. Sci- ence of Computer Programming 55(1-3), 161–183 (2005), http://dx.doi. org/10.1016/j.scico.2004.05.014

[45] Goswami, D., Schneider, R., Masrur, A., Lukasiewycz, M., Chakraborty, S., Voit, H., Annaswamy, A.: Challenges in automotive cyber-physical systems design. In: 2012 International Conference on Embedded Com- puter Systems: Architectures, Modeling, and Simulation. pp. 346–354. IEEE (2012), http://dx.doi.org/10.1109/SAMOS.2012.6404199

[46] Gupta, A.: Formal hardware verification methods: A survey. In: Kurshan, R. (ed.) Computer-Aided Verification, pp. 5–92. Springer (1993), http: //dx.doi.org/10.1007/978-1-4615-3556-0_2

[47] Harel, D., Kozen, D., Tiuryn, J.: Dynamic logic. Founda- tions of computing, MIT Press, Cambridge, Mass (2000), http://search.ebscohost.com/login.aspx?direct=true&scope= site&db=nlebk&db=nlabk&AN=138542

[48] Henzinger, T.A.: The theory of hybrid automata. In: Proceedings, 11th Annual IEEE Symposium on Logic in Computer Science. pp. 278–292. IEEE (1996), http://dx.doi.org/10.1109/LICS.1996.561342

[49] Henzinger, T.A., Kopke, P.W., Puri, A., Varaiya, P.: What’s decidable about hybrid automata? Journal of Computer and System Sciences 57(1), 94–124 (1998), http://dx.doi.org/10.1006/jcss.1998.1581

[50] Henzinger, T.A., Minea, M., Prabhu, V.S.: Assume-guarantee reasoning for hierarchical hybrid systems. In: Di Benedetto, Maria Domenica, Sangiovanni-Vincentelli, A.L. (eds.) Hybrid Systems: Computation and Control, 4th International Workshop, Proceedings. Lecture Notes in Com- puter Science, vol. 2034, pp. 275–290. Springer (2001), http://dx.doi. org/10.1007/3-540-45351-2_24

[51] Hoare, C.A.R.: An axiomatic basis for computer programming. Commu- nications of the ACM 12(10), 576–580 (1969), http://doi.acm.org/10. 1145/363235.363259

[52] Hopcroft, J.E., Motwani, R., Ullman, J.D.: Introduction to automata theory, languages, and computation. Addison-Wesley, Boston, 3 edn. (2007)

[53] Huth, M., Ryan, M.: Logic in computer science: Modelling and reasoning about systems. Cambridge Univ. Press, Cambridge, 2 edn. (2011)

186 BIBLIOGRAPHY

[54] Kern, C., Greenstreet, M.R.: Formal verification in hardware design: A survey. ACM Transactions on Design Automation of Electronic Systems 4(2), 123–193 (1999), http://doi.acm.org/10.1145/307988.307989

[55] Kim, K.D., Kumar, P.: Cyber-physical systems: A perspective at the centennial. Proceedings of the IEEE 100(Centennial-Issue), 1287–1308 (2012), https://doi.org/10.1109/JPROC.2012.2189792

[56] Kreiker, J., Tarlecki, A., Vardi, M.Y., Wilhelm, R.: Modeling, analysis, and verification - The formal methods manifesto. Dagstuhl Manifestos 1(1), 21–40 (2011), http://dx.doi.org/10.4230/DagMan.1.1.21

[57] Lamport, L.: Proving the correctness of multiprocess programs. IEEE Transactions on Software Engineering 3(2), 125–143 (1977), https:// doi.org/10.1109/TSE.1977.229904

[58] Lamport, L.: The temporal logic of actions. ACM Transactions on Pro- gramming Languages and Systems 16(3), 872–923 (1994), http://doi. acm.org/10.1145/177492.177726

[59] Lee, E.A., Niknami, M., Nouidui, T.S., Wetter, M.: Modeling and simu- lating cyber-physical systems using CyPhySim. In: Girault, A., Guan, N. (eds.) 2015 International Conference on Embedded Software. pp. 115–124. IEEE (2015), http://dx.doi.org/10.1109/EMSOFT.2015.7318266

[60] Lee, E.A., Seshia, S.A.: Introduction to embedded systems: A cyber physical systems approach. MIT Press, 2 edn. (2017), http://leeseshia. org/index.html

[61] Lee, I., Sokolsky, O., Chen, S., Hatcliff, J., Jee, E., Kim, B., King, A.L., Mullen-Fortino, M., Park, S., Roederer, A., Venkatasubramanian, K.K.: Challenges and research directions in medical cyber-physical systems. Proceedings of the IEEE 100(1), 75–90 (2012), http://dx.doi. org/10.1109/JPROC.2011.2165270

[62] Loos, S.M., Platzer, A.: Differential refinement logic. In: Grohe, M., Kosk- inen, E., Shankar, N. (eds.) Proceedings of the 31st Annual ACM/IEEE Symposium on Logic in Computer Science. pp. 505–514. ACM (2016), http://doi.acm.org/10.1145/2933575.2934555

[63] Loos, S.M., Platzer, A., Nistor, L.: Adaptive cruise control: Hybrid, distributed, and now formally verified. In: Butler, M.J., Schulte, W. (eds.) 17th International Symposium on Formal Methods. Lecture Notes in Com- puter Science, vol. 6664, pp. 42–56. Springer (2011), http://dx.doi.org/ 10.1007/978-3-642-21437-0_6

[64] Lunel, S., Boyer, B., Talpin, J.P.: Compositional proofs in differential dynamic logic dL. In: 17th International Conference on Application of Concurrency to System Design, Proceedings. pp. 19–28. IEEE (2017)

187 BIBLIOGRAPHY

[65] Lynch, N.A., Segala, R., Vaandrager, F.W.: Hybrid I/O automata. Infor- mation and Computation 185(1), 105–157 (2003), http://dx.doi.org/ 10.1016/S0890-5401(03)00067-1 [66] Madl, G., Abdelwahed, S., Karsai, G.: Automatic verification of component-based real-time CORBA applications. In: Proceedings of the 25th IEEE Real-Time Systems Symposium. pp. 231–240. IEEE (2004), http://dx.doi.org/10.1109/REAL.2004.13 [67] Man, K.L., Reniers, M.A., Cuijpers, P.J.L.: Case studies in the hybrid process algebra Hypa. International Journal of Software Engineering and Knowledge Engineering 15(2), 299–306 (2005), http://dx.doi.org/10. 1142/S0218194005002385 [68] Marwedel, P.: Embedded system design: Embedded systems foundations of cyber-physical systems. Springer, Dordrecht and New York, 2 edn. (2011), http://lib.myilibrary.com/Open.aspx?id=299662 [69] Meyer, B.: Eiffel: The Language. Prentice-Hall (1991) [70] Meyer, B.: Applying design by contract. IEEE Computer 25(10), 40–51 (1992), http://dx.doi.org/10.1109/2.161279 [71] Mitsch, S., Ghorbal, K., Platzer, A.: On provably safe obstacle avoidance for autonomous robotic ground vehicles. In: Newman, P., Fox, D., Hsu, D. (eds.) Robotics: Science and Systems IX (2013), http: //www.roboticsproceedings.org/rss09/p14.html [72] Mitsch, S., Loos, S.M., Platzer, A.: Towards formal verification of freeway traffic control. In: Proceedings of the 2012 IEEE/ACM Third Interna- tional Conference on Cyber-Physical Systems. pp. 171–180. ICCPS ’12, IEEE (2012), http://dx.doi.org/10.1109/ICCPS.2012.25 [73] Mitsch, S., Passmore, G.O., Platzer, A.: Collaborative verification-driven engineering of hybrid systems. Mathematics in Computer Science 8(1), 71–97 (2014), https://doi.org/10.1007/s11786-014-0176-y [74] Mitsch, S., Platzer, A.: ModelPlex: Verified runtime validation of verified cyber-physical system models. Formal Methods in System Design 49(1), 33–74 (2016), https://doi.org/10.1007/s10703-016-0241-z [75] Mitsch, S., Quesel, J.D., Platzer, A.: Refactoring, refinement, and reasoning - A logical characterization for hybrid systems. In: Jones, C.B., Pihla- jasaari, P., Sun, J. (eds.) Formal Methods - 19th International Symposium, Proceedings. Lecture Notes in Computer Science, vol. 8442, pp. 481–496. Springer (2014), http://dx.doi.org/10.1007/978-3-319-06410-9_33 [76] Mobley, B.P.: The ingenuity of common workmen: and the invention of the computer. Retrospective theses and dissertations. paper 660., Iowa State University, Ames, Iowa (2001), http://lib.dr.iastate.edu/rtd/ 660/

188 BIBLIOGRAPHY

[77] Moura, L.M.d., Bjørner, N.: Z3: An efficient SMT solver. In: Ramakr- ishnan, C.R., Rehof, J. (eds.) Tools and Algorithms for the Construction and Analysis of Systems, 14th International Conference, Proceedings. Lec- ture Notes in Computer Science, vol. 4963, pp. 337–340. Springer (2008), http://dx.doi.org/10.1007/978-3-540-78800-3_24

[78] M¨uller,A., Mitsch, S., Platzer, A.: Verified traffic networks: Component- based verification of cyber-physical flow systems. In: 18th International Conference on Intelligent Transportation Systems. vol. 9681, pp. 757–764 (2015), https://doi.org/10.1109/ITSC.2015.128

[79] M¨uller,A., Mitsch, S., Retschitzegger, W., Schwinger, W.: A conceptual reference model of modeling and verification concepts for hybrid systems. In: Buchmann, R., Kifor, C.V., Yu, J. (eds.) Knowledge Science, Engineering and Management - 7th International Conference, Proceed- ings. Lecture Notes in Computer Science, vol. 8793, pp. 368–379. Springer (2014), http://dx.doi.org/10.1007/978-3-319-12096-6_33

[80] M¨uller,A., Mitsch, S., Retschitzegger, W., Schwinger, W., Platzer, A.: Change and delay contracts for hybrid system component verification

[81] M¨uller,A., Mitsch, S., Retschitzegger, W., Schwinger, W., Platzer, A.: A component-based approach to hybrid systems safety verification

[82] M¨uller,A., Mitsch, S., Retschitzegger, W., Schwinger, W., Platzer, A.: A component-based approach to hybrid systems safety verification. In: Abrah´am,E.,´ Huisman, M. (eds.) Integrated Formal Methods - 12th In- ternational Conference, Proceedings. Lecture Notes in Computer Science, vol. 9681, pp. 441–456. Springer (2016), http://dx.doi.org/10.1007/ 978-3-319-33693-0_28

[83] M¨uller,A., Mitsch, S., Retschitzegger, W., Schwinger, W., Platzer, A.: A benchmark for component-based hybrid systems safety verification. In: Frehse, G., Althoff, M. (eds.) 4th International Workshop on Applied Verification of Continuous and Hybrid Systems, EPiC Series in Comput- ing, vol. 48, pp. 65–74. EasyChair (2017), http://www.easychair.org/ publications/paper/342725

[84] M¨uller,A., Mitsch, S., Retschitzegger, W., Schwinger, W., Platzer, A.: Change and delay contracts for hybrid system component verification. In: Huisman, M., Rubin, J. (eds.) Fundamental Approaches to Software Engineering - 20th International Conference, Proceedings. Lecture Notes in Computer Science, vol. 10202, pp. 134–151. Springer (2017), http: //dx.doi.org/10.1007/978-3-662-54494-5_8

[85] Niemueller, T., Ewert, D., Reuter, S., Karras, U., Ferrein, A., Jeschke, S., Lakemeyer, G.: Towards benchmarking cyber-physical systems in factory automation scenarios. In: Timm, I.J., Thimm, M. (eds.) Advances in

189 BIBLIOGRAPHY

Artificial Intelligence - 36th Annual German Conference on AI, Proceed- ings. Lecture Notes in Computer Science, vol. 8077, pp. 296–299. Springer (2013), http://dx.doi.org/10.1007/978-3-642-40942-4_28

[86] Ouimet, M., Lundqvist, K.: Formal software verification: Model checking and theorem proving, http://www.mrtc.mdh.se/index.php?choice= publications&id=1436

[87] Persaud, B., Yagar, S., Brownlee, R.: Exploration of the breakdown phe- nomenon in freeway traffic. Transportation Research Record 1(1634), 64– 69 (1998), http://dx.doi.org/10.3141/1634-08

[88] Pettersson, S., Lennartson, B.: Hybrid modelling focused on hybrid petri nets. In: 2nd European Workshop on Real-time and Hybrid systems. pp. 303–309 (1995)

[89] Platzer, A.: Lecture notes on foundations of cyber-physical systems, http://symbolaris.com/course/fcps16/fcps16.pdf

[90] Platzer, A.: Differential dynamic logic for hybrid systems. Journal of Automated Reasoning 41(2), 143–189 (2008), http://dx.doi.org/10. 1007/s10817-008-9103-8

[91] Platzer, A.: Differential-algebraic dynamic logic for differential-algebraic programs. Journal of Logic and Computation 20(1), 309–352 (2010), http://dx.doi.org/10.1093/logcom/exn070

[92] Platzer, A.: Logical Analysis of Hybrid Systems - Proving Theorems for Complex Dynamics. Springer (2010), http://dx.doi.org/10.1007/ 978-3-642-14509-4

[93] Platzer, A.: Quantified differential dynamic logic for distributed hybrid systems. In: Dawar, A., Veith, H. (eds.) Computer Science Logic 24th International Workshop, 19th Annual Conference of the EACSL Proceedings. Lecture Notes in Computer Science, vol. 6247, pp. 469– 483. Springer (2010), https://link.springer.com/chapter/10.1007% 2F978-3-642-15205-4_36

[94] Platzer, A.: Stochastic differential dynamic logic for stochastic hybrid programs. In: Bjørner, N., Sofronie-Stokkermans, V. (eds.) Au- tomated Deduction, CADE-23, Lecture Notes in Computer Science, vol. 6803, pp. 446–460. Springer (2011), http://dx.doi.org/10.1007/ 978-3-642-22438-6_34

[95] Platzer, A.: A complete axiomatization of quantified differential dynamic logic for distributed hybrid systems. Logical Methods in Computer Science 8(4) (2012), http://dx.doi.org/10.2168/LMCS-8(4:17)2012

190 BIBLIOGRAPHY

[96] Platzer, A.: The complete proof theory of hybrid systems. In: Proceedings of the 27th Annual IEEE Symposium on Logic in Computer Science. pp. 541–550. IEEE (2012), http://dx.doi.org/10.1109/LICS.2012.64 [97] Platzer, A.: Logics of dynamical systems. In: Proceedings of the 27th Annual IEEE Symposium on Logic in Computer Science. pp. 13–24. IEEE (2012), http://dx.doi.org/10.1109/LICS.2012.13 [98] Platzer, A.: The structure of differential invariants and differential cut elimination. Logical Methods in Computer Science 8(4), 1–38 (2012), https://doi.org/10.2168/LMCS-8(4:16)2012 [99] Platzer, A.: A uniform substitution calculus for differential dynamic logic. In: Felty, A.P., Middeldorp, A. (eds.) 25th International Conference on Automated Deduction, Proceedings. Lecture Notes in Computer Science, vol. 9195, pp. 467–481. Springer (2015), http://dx.doi.org/10.1007/ 978-3-319-21401-6_32 [100] Platzer, A.: A complete uniform substitution calculus for differential dynamic logic. Journal of Automated Reasoning 59(2), 219–265 (2017), https://doi.org/10.1007/s10817-016-9385-1 [101] Platzer, A., Quesel, J.D.: KeYmaera: A hybrid theorem prover for hybrid systems (system description). In: Armando, A., Baumgartner, P., Dowek, G. (eds.) Automated Reasoning, 4th International Joint Conference, Pro- ceedings. Lecture Notes in Computer Science, vol. 5195, pp. 171–178. Springer (2008), https://doi.org/10.1007/978-3-540-71070-7_15 [102] Platzer, A., Quesel, J.D.: European train control system: A case study in formal verification. In: Breitman, K.K., Cavalcanti, A. (eds.) Formal Methods and Software Engineering. Lecture Notes in Computer Science, vol. 5885, pp. 246–265. Springer (2009), http://dx.doi.org/10.1007/ 978-3-642-10373-5_13 [103] Pnueli, A.: The temporal logic of programs. In: 18th Annual Symposium on Foundations of Computer Science. pp. 46–57. IEEE (1977), http:// dx.doi.org/10.1109/SFCS.1977.32 [104] Prabhakar, P., Vladimerou, V., Viswanathan, M., Dullerud, G.E.: A decidable class of planar linear hybrid systems. Theoretical Computer Science 574, 1–17 (2015), http://dx.doi.org/10.1016/j.tcs.2014.11. 018 [105] Ratschan, S., She, Z.: Safety verification of hybrid systems by constraint propagation based abstraction refinement. In: Morari, M., Thiele, L. (eds.) Hybrid Systems: Computation and Control, 8th Interna- tional Workshop, Proceedings. Lecture Notes in Computer Science, vol. 3414, pp. 573–589. Springer (2005), http://dx.doi.org/10.1007/ 978-3-540-31954-2_37

191 BIBLIOGRAPHY

[106] Richards, P.I.: Shock waves on the highway. Operations Research 4(1), 42–51 (1956), https://doi.org/10.1287/opre.4.1.42

[107] Ricketts, D., Malecha, G., Alvarez, M.M., Gowda, V., Lerner, S.: To- wards verification of hybrid systems in a foundational proof assistant. In: 13. ACM/IEEE International Conference on Formal Methods and Models for Codesign. pp. 248–257. IEEE (2015), http://dx.doi.org/10.1109/ MEMCOD.2015.7340492

[108] Ricketts, D., Malecha, G., Lerner, S.: Modular deductive verification of sampled-data systems. In: 2016 International Conference on Embedded Software. pp. 17:1–17:10. ACM (2016), http://doi.acm.org/10.1145/ 2968478.2968495

[109] Ruchkin, I., Schmerl, B., Garlan, D.: Architectural abstractions for hybrid programs. In: Kruchten, P., Becker, S., Schneider, J. (eds.) Proceedings of the 18th International Symposium on Component-Based Software En- gineering. pp. 65–74. CBSE’15, ACM (2015), http://doi.acm.org/10. 1145/2737166.2737167

[110] Sametinger, J.: Software Engineering with Reusable Components. Springer (1997), http://dx.doi.org/10.1007/978-3-662-03345-6

[111] Sanislav, T., Miclea, L.: Cyber-physical systems - Concept, challenges and research areas. Journal of Control Engineering and Applied Informatics 14(2) (2012)

[112] Schreiter, L., Bresolin, D., Capiluppi, M., Raczkowsky, J., Fiorini, P., W¨orn,H.: Application of contract-based verification techniques for hybrid automata to surgical robotic systems. In: European Control Conference. pp. 2310–2315. IEEE (2014), http://dx.doi.org/10.1109/ECC.2014. 6862231

[113] Shi, J., Wan, J., Yan, H., Suo, H.: A survey of cyber-physical systems. In: International Conference on Wireless Communications and Signal Pro- cessing. pp. 1–6 (2011), https://doi.org/10.1109/WCSP.2011.6096958

[114] Silva, B., Richeson, K., Krogh, B., Chutinan, A.: Modeling and verification of hybrid dynamical system using CheckMate. In: Engell, S., Kowalewski, S., Zaytoon, J. (eds.) International Conference on Automa- tion of Mixed Processes: Hybrid Dynamic Systems, Proceedings. Berichte aus der Automatisierungstechnik, Shaker (2000)

[115] Song, H., Compton, K.J., Rounds, W.C.: SPHIN: A model checker for reconfigurable hybrid systems based on SPIN. Electronic Notes inTheo- retical Computer Science 145, 167–183 (2006), http://dx.doi.org/10. 1016/j.entcs.2005.10.011

192 BIBLIOGRAPHY

[116] Sridhar, S., Hahn, A., Govindarasu, M.: Cyber-physical system secu- rity for the electric power grid. Proceedings of the IEEE 100(1), 210–224 (2012), http://dx.doi.org/10.1109/JPROC.2011.2165269

[117] Tabuada, P., Pappas, G.J., Lima, P.U.: Compositional abstractions of hybrid control systems. Discrete Event Dynamic Systems 14(2), 203–238 (2004), http://dx.doi.org/10.1023/B:DISC.0000018571.14789.24

[118] Tarski, A.: A decision method for elementary algebra and geometry. In: Caviness, B.F., Johnson, J.R. (eds.) Quantifier Elimination and Cylindri- cal Algebraic Decomposition, pp. 24–84. Springer, Vienna, Austria (1998), https://doi.org/10.1007/978-3-7091-9459-1_3

[119] Teschl, G.: Ordinary differential equations and dynamical systems, Grad- uate studies in mathematics, vol. 140. American Math. Soc, Providence, RI (2012)

[120] Tomlin, C., Pappas, G.J., Sastry, S.: Conflict resolution for air traffic management: A study in multiagent hybrid systems. IEEE Transactions on Automatic Control 43(4), 509–521 (1998), https://doi.org/10.1109/ 9.664154

[121] UML Revision Task Force: OMG unified modeling language specification, version 2.5: OMG document number: formal/15-03-01, http://www.omg. org/spec/UML/2.5/

[122] van der Schaft, Arjan J., Hans Schumacher: Introduction to hybrid dynamical systems, Lecture Notes in Control and Information Sciences, vol. 251. Springer, London, UK, 1 edn. (2000)

[123] Walter, W.: Ordinary Differential Equations, Graduate Texts in Math- ematics, Readings in Mathematics, vol. 182. Springer, New York, NY (1998), http://dx.doi.org/10.1007/978-1-4612-0601-9

[124] Wan, K., Hughes, D., Man, K.L., Krilavicius, T., Zou, S.: Investigation on composition mechanisms for cyber physical systems. International Journal of Design, Analysis and Tools for Integrated Circuits and Systems 2(1), 30–40 (2011)

[125] Wang, H., Rudy, K., Li, J., Ni, D.: Calculation of traffic flow breakdown probability to optimize link throughput. Applied Mathematical Modelling 34(11), 3376–3389 (2010), http://www.sciencedirect.com/ science/article/pii/S0307904X10000880

[126] Xinyu, C., Huiqun, Y., Xin, X.: Verification of Hybrid Chi model for cyber-physical systems using PHAVer. In: Barolli, L., You, I., Xhafa, F., Leu, F.Y., Chen, H.C. (eds.) Seventh International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing. pp. 122–128. IEEE (2013), http://dx.doi.org/10.1109/IMIS.2013.29

193 BIBLIOGRAPHY

[127] Yperman, I., Logghe, S., Immers, B.: The link transmission model: An efficient implementation of the kinematic wave theory in traffic networks. In: Proceedings of the 10th EWGT Meeting (2005) [128] Zwillinger, D.: Handbook of differential equations. Academic Press, San Diego, CA, USA, 3 edn. (1997)

194

Curriculum Vitae – Andreas Müller

Personal Information Name: Dipl.-Ing. Andreas Müller, BSc Date of Birth: 06. April 1985 Place of Birth: Waidhofen/Ybbs, Austria Home Address: Freistädterstraße 311/45 4040 Linz Austria Mobile Phone: +43 650 772 09 26 Email: [email protected] Citizenship: Austrian Family Status: Married

Current Position Employment: Research Fellow Project: ProofAwarE CPS - Proof-Aware Engineering of Cyber-Physical Systems Institution: Department of Cooperative Information Systems Johannes Kepler University (JKU), Linz Address: Altenberger Straße 69 4040 Linz Austria Room: S3 0307 Phone: +43 732 2468 4678 Email: [email protected]

Education 1991 – 1995 Primary Level: Elementary school, Biberbach (Austria) 1995 – 1999 Secondary Level: Monastery secondary school, Seitenstetten (Austria) 1999 – 2004 Third Level: Polytechnic for IT and Organization, St. Pölten (Austria) June 2004 Graduation Diploma: Higher School Certificate with Distinction 2004 – 2005 Military service, St. Pölten (Austria) 2005 – 2007 Bachelor’s degree courses, Technical Mathematics, JKU Linz (Austria) 2007 – 2009 Bachelor’s degree courses, Informatics, JKU Linz (Austria) March 2010 Bachelor’s degree, Bachelor of Science (BSc) 2010 – 2012 Master’s degree courses, Software Engineering, JKU Linz (Austria) February 2012 Master’s degree, Master of Science (MSc) Since November 2011 Doctoral program, Technical Sciences – Informatics, JKU Linz (Austria) August – November 2013 Visiting Researcher at School of Computerscience, Carnegie Mellon University, Pittsburgh (PA),enabled by Marshall Plan Foundation Grant January – June 2015 Visiting Researcher at School of Computerscience, Carnegie Mellon University, Pittsburgh (PA), enabled by Marietta Blau Grant

Further Qualifications Languages: German (native language) English Other: Driver’s license (Austria) Past Positions Projects: Development of a web application for X-Net Technologies GmbH (duration: 2 months, employed techniques: python, java script, ajax, HTML, zope, XML) Development of the server application for CD image creation tool for X- Net Technologies GmbH (duration: 2 months, employed techniques: python) Collaborative Situation Awareness in Distributed Traffic Control Systems (November 2011 – September 2014) University tutorship: Programming for mathematicians (2 semesters) IT systems for mathematicians (2 semesters)

Publications Conference “PPPJ 2010: 8th International Conference on the Principles and Practice attendances: of Programming in Java, Vienna (Austria), Sept. 2010”, presentation of the bachelor’s thesis “Bytecode Analysis for Checking Java Access Modifiers” as part of the “Work in progress poster session”. “ITS 2012: 19th ITS World Congress, Vienna (Austria), Oct. 2012”, presentation of the paper“ The Situation Radar - Visualizing Collaborative Situation Awareness in Traffic Control Systems”. “KSEM 2014: The 7th International Conference on Knowledge Science, Engineering and Management, Sibiu (Rumania), Oct. 2014”, presentation of the paper“ A Conceptual Reference Model of Modeling and Verification Concepts for Hybrid Systems“. “Doctoral Symposium of Formal Methods co-located with the 20th International Symposium on Formal Methods, Oslo (Norway), June 2015”, presentation of the research abstract “Component-based CPS Verification: A Recipe for Reusability”. “ITSC 2015: 18th IEEE International Conference on Intelligent Transportation Systems, Gran Canaria (Spain), Sept. 2015”, presentation of the paper“18 th IEEE International Conference on Intelligent Transportation Systems”. “IFM 2016: 12th International Conference on Integrated Formal Methods, Reykjavik (Iceland), June 2016”, presentation of the paper“ A Component-Based Approach to Hybrid Systems Safety Verification”. “FASE 2017: 20th International Conference on Fundamental Approaches to Software Engineering, Uppsala (Schweden), April 2017”, presentation of the paper“ Change and Delay Contracts for Hybrid System Component Verification”.

Conference Andreas Müller: Bytecode Analysis for Checking Java Access Modifiers, proceedings: Proceedings of the Work-in-Progress Session at the 8th International Conference on the Principles and Practice of Programming in Java (PPPJ 2010), Vienna, Austria, CEUR-WS, Sept. 2010. Norbert Baumgartner, Stefan Mitsch, Andreas Müller, Werner Retschitzegger, Andrea Salfinger, Wieland Schwinger: The Situation Radar - Visualizing Collaborative Situation Awareness in Traffic Control Systems. Proceedings of the 19th World Congress on Intelligent Transport Systems, Vienna, Austria, 2012. Stefan Mitsch, Andreas Müller, Werner Retschitzegger, Andrea Salfinger, Wieland Schwinger: A Survey on Clustering Techniques for Situation Awareness. Proceedings of the 15th Asia-Pacific Web Conference (APWeb), Sydney, Australia, Springer, Apr. 2013. Norbert Baumgartner, Stefan Mitsch, Andreas Müller, Werner Retschitzegger, Andrea Salfinger, Wieland Schwinger: A tour of BeAware – A situation awareness framework for control centers. Journal of Information Fusion 20 2( 014), pp. 155–173, 2014. Andreas Müller, Stefan Mitsch, Werner Retschitzegger, Wieland Schwinger: A Conceptual Reference Model of Modeling and Verification Concepts for Hybrid Systems. Proceedings of the 7th International Conference on Knowledge Science, Engineering and Management (KSEM), Sibiu, Romania, Oct. 2014. Andreas Müller: Component-based CPS Verification: A Recipe for Reusability. Doctoral Symposium of Formal Methods, co-located with the 20th International Symposium on Formal Methods (FM 2015). Oslo, Norway, pages: 33-37. June, 2015. Andreas Müller, Stefan Mitsch, André Platzer: Verified Traffic Networks: Component-based Verification of Cyber-Physical Flow Systems. Proceedings of the 18th IEEE International Conference on Intelligent Transportation Systems (ITSC 2015). Gran Canaria, Spain, pages: 757- 764. IEEE, September, 2015 Andreas Müller, Stefan Mitsch, Werner Retschitzegger, Wieland Schwinger, André Platzer: A Component-Based Approach to Hybrid Systems Safety Verification. Integrated Formal Methods - 12th International Conference, IFM 2016, Proceedings. Reykjavik, Iceland,9681 of Lecture Notes in Computer Science, pages: 441-456. Springer, June, 2016. Andreas Müller, Stefan Mitsch, Werner Retschitzegger, Wieland Schwinger, André Platzer: Change and Delay Contracts for Hybrid System Component Verification. Fundamental Approaches to Software Engineering - 20th International Conference, FASE 2017, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2017, Proceedings. Uppsala, Sweden,10202 of Lecture Notes in Computer Science, pages: 134-151. April, 2017 Other publications: Automatic Dependency Reduction between Java Classes and Packages, Master’s Thesis, 2012.

Linz, 10/4/2017 Andreas Müller