Verifying Cyber-Physical Systems

A Path to Safe Autonomy

Sayan Mitra

The MIT Press
Cambridge, Massachusetts
London, England

© 2021 Massachusetts Institute of Technology

All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher.

Library of Congress Cataloging-in-Publication Data

Names: Mitra, Sayan, author.

Title: Verifying cyber-physical systems: a path to safe autonomy / Sayan Mitra.

Description: Cambridge, Massachusetts: The MIT Press, [2021] | Series: Cyber physical systems

 series | Includes bibliographical references and index.

Identifiers: LCCN 2020013897 | ISBN 9780262044806 (hardcover)

Subjects: LCSH: Cooperating objects (Computer systems)–Mathematical models.

Classification: LCC QA76.5915.M57 2021 | DDC 004.01/51135–dc23

LC record available at https://lccn.loc.gov/2020013897

d_r0

To my parents,
Mamata and Tapan Mitra,
with gratitude

Preface

The verification enterprise aims to establish whether a system meets a set of requirements. For cyber-physical systems, such as driverless cars, autonomous spacecraft, and systems for air-traffic management, verification technologies promise the creation of safe and high-assurance systems. Most verification problems for cyber-physical systems are undecidable, and until recently, their approximate solutions did not scale to realistic systems. In this textbook, I have attempted to distill the key ideas and algorithms that have emerged from three decades of research and have led to the creation of industrial-scale modeling and verification techniques for cyber-physical systems.

This book is based on the lecture notes from a graduate-level course on “Modeling and Verification of Cyber-Physical Systems” that I taught at the University of Illinois at Urbana-Champaign several times from 2009 to 2018. In 2017, I taught a compressed version of the course at the Indian Institute of Technology Guwahati. These experiences helped me refine the material into this current form. New examples were added and topics related to new results on data-driven verification were included over the last few years.

This book discusses computer science concepts such as undecidability and abstractions, along with concepts from control theory like multiple Lyapunov functions and barrier certificates, within a unified mathematical language. It explains algorithms for model checking, reachability analysis, counterexample-guided abstraction refinement, and data-driven verification, as well as the data structures that allow their effective implementation. The topics include invariants, deductive verification, progress analysis, sensitivity analysis, simulation relations, fairness, satisfiability modulo theory (SMT), temporal logics, compositional reasoning, synchronous and asynchronous processes, and verification of black-box systems. The principles of modeling and verification are illustrated with more than 20 examples ranging from abridged models of advanced driver-assistance systems (ADAS) to distributed protocols and autonomous spacecraft maneuvers. The examples are written in a common specification language that reflects the input formats of many of the verification tools available for cyber-physical systems.

This book is suitable for a semester-long course for upper-level undergraduate or first-year graduate students in computer science, computer engineering, and other engineering disciplines that provide a background in control theory. Chapter 1 discusses alternative ways of covering the chapters for organization of such a course. This book is self-contained, and background materials in linear algebra, real analysis, complexity theory, and the specification language used for describing all the examples are covered in the appendices. The chapters are of balanced size and could each be covered in three to four lecture hours. Each chapter has exercise problems and additional supporting materials in the form of slides, simulation code, and additional exercises, as well as the solutions, all provided on this book’s website (https://sayanmitracode.github.io/cpsbooksite/).

Acknowledgments

This book was inspired by the research of many individuals in the hybrid systems community. I am indebted to several people who influenced my thinking and offered valuable insights into the subject. I would like to thank my former advisors, Nancy Lynch, Richard Murray, Mani Chandy, and Tapan Ghoshal. I am grateful to my colleagues at the University of Illinois for fostering a tranquil environment with vigorous scholarship. The book benefited from my collaborations with Geir Dullerud, Daniel Liberzon, Nitin Vaidya, and Mahesh Viswanathan. In particular, Chapter 11 is largely based on a string of papers with Mahesh Viswanathan, Chuchu Fan, and Sridhar Duggirala.

Stanley Bak, Purandar Bhaduri, Goran Frehse, Taylor Johnson, Richard Murray, and Necmiye Ozay read earlier drafts and made many detailed suggestions that improved the book. Calin Belta was very generous with his advice and encouragement.

Over the years, I have been fortunate to have worked with an outstanding group of graduate students. Thanks to them for providing comments and writing solutions: Nicole Chan, Sridhar Duggirala, Chuchu Fan, Ritwika Ghosh, Chiao Hsieh, Zhenqi Huang, Taylor Johnson, Yangge Li, Ted Liu, Bolun Qi, and Hussein Sibai.

I would like to thank the National Science Foundation, the U.S. Air Force Office of Scientific Research, and the National Security Agency’s Science of Security program for providing sustained funding to my research projects related to cyber-physical systems.

Jenny Applequist and Theresa Carcaldi read through the entire manuscript, pointed out mistakes, and corrected typos. I would like to take the opportunity to thank Marie Lufkin Lee, Alex Hoopes, and Marcy Ross for shepherding the book through at the MIT Press.

Finally, I thank my family, particularly Shinjinee, Lahori, and Aranya, for their tolerance and support.

Sayan Mitra

September 2020

1

Introduction

1.1  What is this book about? The verification problem

Verification is the task of establishing the truth of statements. The subject of this book is the verification of statements that are assertions about engineered systems.

Does system 𝒜 meet requirement R?

Assertions about engineered systems are variously called requirements, properties, and specifications. For example, can a device driver hang on a particular computer? Is the performance of certain facial recognition software racially unbiased? Does a delivery drone land at the correct waypoint without crashing into buildings or trees? These are all examples of verification questions. In this book, we are concerned with the last type of verification question, where the system being interrogated involves a computer that is doing something physical. Such systems are called cyber-physical systems (CPS).

The term cyber-physical systems was minted recently, but computers that control things have been around since at least the 1950s. From electromagnetic relays to solid-state circuits, microcontrollers, and networks, all the way to real-time operating systems and deep learning, advances in computing and communication technologies have coevolved with their applications in control systems. We will not linger here on the precise definition of cyber-physical systems, but their ubiquity should be self-evident. From thermostats to autonomous cars to city-scale power distribution networks, cyber-physical systems appear in a broad swath of domains. A number of other terms overlap with the term CPS: embedded computing systems, embedded control systems, internet of things, autonomous systems, real-time systems, networked control systems, and safety-critical systems.

A requirement for a cyber-physical system 𝒜 says something about the desired or claimed behaviors of the system. For example, for safety reasons, a drone is required not to crash into buildings. Requirements might also be related to performance, timely response, efficiency, or security, among others. Requirements are also called specifications or properties. A real-world cyber-physical system can have thousands of requirements. Just the top-tier requirements of a semiautonomous car have to subsume all the rules of the road found in drivers’ manuals. In addition, the requirements have to capture the correct detection of situations in which the vehicle is outside of the designed envelope so that the human driver must take over. Those top-tier requirements then translate to many, many more requirements for individual sensors, actuators, and communication buses, as well as for the perception and control algorithms.

1.2  Testing and verification for establishing system requirements

Testing is the most common method for establishing “the truth” of claims about a system’s ability to meet its requirements. A single test involves running the system 𝒜 from a particular initial condition and with particular input, and analyzing the resulting behavior data to check whether R is met. Running the system can take many forms, with different costs. For example, for an autonomous vehicle, testing options can range from the execution of abstract models of the system in a computer, to the simulation of the actual control software code on a high-fidelity simulation engine with realistic models of sensors and actuators, to test-driving the actual vehicle in controlled environments like test tracks, all the way to test-driving on public roads. By running many tests with different initial conditions and inputs, one hopes to discover the important design defects in 𝒜 that compromise R, or amend the requirements R to something more realistic and achievable for 𝒜.

Tests can find behaviors that violate the requirements, and discovering them can reveal design defects, or bugs. However, the set of possible behaviors of most interesting cyber-physical systems is uncountably infinite, and therefore it is impossible for finitely many tests to establish the absence of bugs. For many systems, it is not only possible but likely that even with abundant resources devoted to simulations and tests, only a small fraction of the set of possible behaviors is covered. Shalev-Shwartz et al. (2017) argue that “the amount of [test-driving] data required to guarantee a probability of 10⁻⁹ fatality per hour of driving is proportional to its inverse, 10⁹ hours of data, which is roughly in the order of thirty billion miles.” Koopman and Wagner (2016) similarly argue that the amount of naive test-driving required to achieve acceptable catastrophic failure rates for a fleet of vehicles can grow to hundreds of billions of miles. Those figures are beyond the capability of even the best-resourced organizations.

In contrast to testing, a verification approach mathematically proves that a model 𝒜 of the system meets the requirements R.

An ideal verification algorithm takes as input a system model 𝒜 and the requirements R and produces one of two types of outputs: either it produces a mathematical proof that all possible behaviors of 𝒜 meet the requirements R or it produces a single counterexample behavior of 𝒜 that shows particular initial conditions and inputs to 𝒜 that lead to a violation of R. The second type of output can be useful for designers in fixing design defects or changing the requirements. The first type of output can be useful for designers in gaining high assurance about the actual system design, and it can also be useful for regulatory and certification purposes.

In summary, this book is about writing programs that prove the correctness of programs that control things in the real world. We will discuss mathematically precise models that represent cyber-physical systems, and we will endeavor to obtain verification algorithms that give guarantees.

1.3  From systems to models of systems

The key input to a verification algorithm is a model of a system. The proofs and counterexamples that come out can be only as good as the models that go in. Thus, mathematical models of cyber-physical systems are a centerpiece of the verification enterprise. There are two steps to creating a model:

Step 1.

Choose a model class in which to express the system.

Step 2.

Find parameters to instantiate a specific model in the chosen class.

Consider the analogous curve-fitting problem for creating a function model y = f(x) from k data points . First, we choose a function class; for example, it could be a linear model [f(x) = ax + b], a quadratic model [f(x) = ax² + bx + c], or a higher degree polynomial model. Next, we find the appropriate values of the model parameters a, b, and so on, for that class in order to match the data (closely, we hope). Similarly, in modeling a cyber-physical system, Step 1 is to choose a model class and Step 2 is to identify the parameters based on available data and knowledge about the system.

Many model classes are available for cyber-physical systems, with attendant strengths and weaknesses. In the remainder of this section, we outline the key factors that inform the choice of model classes in Step 1 from the point of view of verification. Step 2 of modeling is the subject of a whole subdiscipline of decision and control theory called system identification, to which several textbooks are dedicated (Kumar and Varaiya, 2016; Ljung, 1999), and which is beyond the scope of this book. To discuss different dimensions of cyber-physical model classes concretely, we introduce an archetypal system: a highly autonomous vehicle (HAV).

Advanced driver-assistance systems (ADAS)   Safety-enhancing driver-assistance capabilities such as automatic emergency braking (AEB), automatic parking, stability control, and adaptive cruise control are becoming standard features of vehicles. The next level of autonomy features constituting an HAV include automatic lane change maneuvers, platooning, and autonomous driving in urban traffic. The computational pipeline and the corresponding models for such an HAV are shown in Figure 1.1. Data from sensors like cameras, radars, global positioning systems (GPS), and light detection and ranging (LIDAR) devices are used in computer vision, machine learning, and filtering algorithms to construct an internal representation of the vehicle’s situational awareness. That representation is used for downstream decision-making (e.g., deciding whether to overtake), path planning, and low-level steering and throttle control.

Figure 1.1
An autonomous vehicle system. Top. Polaris GEM-based electric vehicle platform created by AutonomousStuff. Bottom. Modules in the computational pipeline of an HAV and their typical models. Perception modules work on sensor data and construct representations for location, obstacles, and other elements. Decision, planning, and control modules are based on geometric and dynamical representation of the physical space and agents around the vehicle.

At a very high level, a model of a cyber-physical system has to describe the state of the system and how the state can change. The state has to capture all the information needed to determine the system’s future behavior. Mathematically, a state is represented by the valuations of a set of state variables. For example, the state variable of the HAV model has to include variables representing physical quantities like position, velocity, and angular speed of the wheels, as well as variables representing the state of the software modules used for perception, planning, and control. A model of a cyber-physical system can have hundreds or thousands of state variables, but, broadly speaking, there are two kinds: (1) continuous variables, such as real-valued variables and vectors, for representing physical quantities; and (2) discrete variables, such as integers, floating point numbers, and graphs, for representing program variables and data structures.

In addition to defining the state variables, a model has to describe how the values of these variables can change. Changes in a program variable x are naturally described by programs or statements like

that update the value of the variable x as a function of other variables. On the other hand, the natural language for describing the laws that govern the physical world is the language of ordinary differential equations (ODE):

Bringing together discrete-continuous variables, programs, and ODEs within the same mathematical model gives rise to hybrid models, which will be discussed next.

Hybrid models for cyber-physical systems   Techniques for analyzing programs are developed by computer scientists, and techniques for ODEs are developed by dynamical systems and control theorists. In the early 1990s, these two communities came together to create what we now know as hybrid systems theory. Several model classes fall under the umbrella term hybrid systems, such as hybrid automata (HA) (Alur et al., 1995; Tabuada, 2009; Lygeros et al., 2003), hybrid input/output automata (Kaynar et al., 2005; Lynch et al., 2001), hybrid dynamical systems (Goebel et al., 2012), switched systems (Liberzon, 2003b), and hybrid programs (Platzer, 2008, 2018). In this book, we will use a version of the hybrid input/output automata of Lynch et al. (2001) that is closely related to the other formalisms.

Boundaries and interactions   Complex models are typically created by putting together simpler modules. Modularity facilitates reuse in modeling, as well as in verification. How modules are allowed to interact with each other across their own boundaries is an important dimension of a modeling formalism. Modules may interact discretely through events (also called actions) or continuously through shared variables (also called channels or signals). For example, the decision to brake in front of a pedestrian, made by the tactical decision-making unit of an HAV, is conveyed to the planning and control unit as a discrete event. The range sensor input to a spacecraft docking controller could be modeled as a continuous signal or a periodically sampled signal. The hybrid input/output (I/O) automaton formalism can express those types of interactions among modules, as we shall see in Chapters 5 and 8.

Uncertainty: Nondeterministic and probabilistic choices   Hybrid system models, and specifically hybrid I/O automata, allow uncertainty in models to be captured in several ways. Uncertainty in initial conditions is modeled by a set of valuations of the state variables instead of a single value. For example,

declares two real-valued variables for modeling the position of an HAV and initializes the position as being within the unit circle. Uncertainty in program execution is modeled by nondeterministic choices in the selection of the program statements to be executed or in the variable assignments that result from executing a particular statement:

The latter type of choice can also be seen as a set-valued assignment function. Uncertainty in continuous dynamics can be modeled in terms of differential inclusions:

or as input variables or bounded disturbances. In addition, models can be parameterized with known or unknown parameters.

All of these forms of nondeterministic choices are useful for worst-case modeling and analysis—which is quite often what we wish to perform for safety-critical systems. In contrast, probabilistic models of uncertainty are useful for average-case analysis. Stochastic hybrid system models, as developed by Teel and Hespanha (2015); Hespanha (2004); Hu et al. (2000); Meseguer and Sharykin (2006); and others, allow uncertainties to be modeled by probabilistic choices. For example, initial state uncertainty is described by a distribution on states, program transitions are described by transition probabilities or an exponential process, and continuous evolution is described by stochastic differential equations. There are also hybrid models that allow both nondeterministic and probabilistic choices (Mitra, 2007; Cattani, 2005; Cattani et al., 2005); however, the semantics of such models can get complicated, and there are few algorithms and software tools that can effectively verify them.

Explicit and black-box models   All of the hybrid model classes mentioned so far describe how state variables change explicitly in terms of programs, differential equations, or their variations. For real-world systems, such as the HAV, parts of the model may be available only as black-box executables, without explicit descriptions. For example, simulation modules may be available only as binaries, and models created using tools like MATLAB may be too complicated—with delays, filters, and look-up tables—to be written out as HA. That observation has led Fan et al. (2017) to create CPS models that combine HA with black-box modules that can be executed but cannot be explicitly written out.

1.4  Design automation ecosystem

It should be clear at this point that verification is a piece of the bigger design automation ecosystem for cyber-physical systems. The process usually starts with modeling and system identification (see Figure 1.2), which leads to the creation of a model 𝒜 of the cyber-physical system. Another parallel process is requirements analysis, which leads to the creation of the requirements R. These two items are the input to the verification engine. One possible output from verification is a mathematical proof that establishes that the model 𝒜 meets the requirements R. That proof can then be used as documentation and evidence for certifying 𝒜. The second possible output from a verification process is a counterexample α, showing how and when 𝒜 violates the requirements R. A counter-example could mean several different things:

First, α could be a spurious counterexample. That is, it could arise because of the gap between the model 𝒜 and the actual system. In other words, in this case there is no real behavior of the cyber-physical system corresponding to α that violates the requirements R. Thus, the model 𝒜 can be refined to reduce the gap between it and the actual system. This model validation process relates to the system identification problem mentioned earlier, and until recently it has been somewhat overlooked by the research community. For some recent work on this topic, see Mitsch and Platzer (2016); Jiang et al. (2011); and Beg et al. (2017).

Second, α could be a real counterexample. In other words, α is reproducible in the real system, demonstrating a violation of R. There are two further possible subcases here: (1) α could demonstrate a design bug, which then leads to debugging and modification of the system 𝒜; or (2) α could lead to a realization that the requirements R are wrong or inconsistent and need to be modified.

This iterative cycle of verification, refinement, and improvement is repeated until, ideally, a satisfactory system model 𝒜 is proved to meet a satisfactory set of requirements R.

Figure 1.2
Verification in the design automation ecosystem.

1.5  Challenges and state of the art

Verification of cyber-physical and autonomous systems is a hard problem at several levels.

Theoretical undecidability   Like many interesting verification problems, the problem of checking whether a model of a cyber-physical system meets a requirement is generally undecidable. That is, there is no algorithm that can perform that check automatically, even for relatively simple models (e.g., constant-slope). We will study such an undecidability result in Chapter 9.

Practical scalability   Relaxing the verification question (e.g., by asking the bounded-time horizon version of this question and by tolerating some false positives in the answers) leads to decidable problems. Indeed, several successful algorithms and tools have been developed for answering such questions. However, until very recently, real and perceived lack of scalability has been the scourge of progress in verification.

Missing models   This point is so obvious that academic research on CPS verification has been blind to it: complete models of cyber-physical systems are difficult to come by. Often, models lack succinct descriptions, are distributed, and are protected intellectual property.

Learning-enabled systems and missing requirements   An especially florid case of this arises in systems like the HAV that use deep neural networks and other machine learning (ML) modules for perception and control. There is not only a lack of models for such modules, but also a lack of requirements.

In summary, we are currently far from having gold-standard verification technology: automatic, efficient tools for establishing truth about systems like the HAV. Even so, there are at least four good reasons why you might want to learn about verification of hybrid systems.

Understand the connections between computer science and control theory   Computer science and control theory research is evolving in two separate islands. Nevertheless, just like convergent evolution of echolocation in bats and dolphins, the two communities have independently developed many overlapping (but not identical) concepts and techniques. It can be confusing, as similar-sounding terms often mean slightly different things in the two islands. The field of hybrid system and CPS verification serves as an ecobridge between the islands—a bridge that is increasingly well trodden, with the rise of robotics and ML. Not surprisingly, much of the recent work on safe reinforcement learning and verification of neural networks is coming from the hybrid systems community. See, for example, the works of Dutta et al. (2019); Ivanov et al. (2019); Dreossi et al. (2019); and Xiang et al. (2018a).

Model everything   Hybrid systems have been used to model everything from transistors to spacecraft, including mixed-signal circuits, networks of cardiac cells, molecular networks, complex engine control systems of cars, bipedal robots, and autonomous vehicles. They are an expressive formal language for describing a very wide variety of systems. Even prior to verification, formal modeling adds value to engineering practice by exacting precision, supporting machine-readability, and providing modularity.

Abstract models can also serve naturally as requirements. State diagrams or automata are routinely used to specify network protocols like the Border Gateway Protocol (BGP), telnet, and Secure Shell (SSH), in Request for Comments (RFC) documents. As safety certification standards for control systems, such as the DO178C RTCA (2011) for avionics systems, gravitate toward accommodating verification tools, we hope that requirements for control systems will one day be written in terms of a precise mathematical language like HA.

Get introduced to formal methods   Despite the dull name, formal methods represent one of the three foundational subdisciplines of computer science, alongside the theory of computation (algorithms) and cryptosystems. Verification of cyber-physical systems serves as an introduction to formal methods.

The subdiscipline has several sub-subdisciplines that approach the problem of verification from different angles. For example, model-checking algorithms explore all possible states of a system in a systematic fashion and check the requirements at those states, much like a chess player who looks ahead and analyzes all possible future board positions. Theorem proving, by contrast, is based on deducing the properties of 𝒜 from a set of axioms. Deduction is the process that a student uses in rewriting a complicated trigonometric or Boolean expression to obtain a simpler one. There are techniques that combine deduction and exploration in interesting ways. Process algebras define logics for describing computer systems that support deductive algebraic reasoning.

This book presents a selection of those concepts—invariants, temporal logics, progress and stability proofs with ranking functions and Lyapunov functions, reachability analysis, compositional reasoning, abstraction-refinement, and substitutivity—in the context of cyber-physical systems. Topics are first introduced for elementary models like automata and differential equations, and then generalized to tackle hybrid models.

Learn powerful algorithms and tools   Through a series of conceptual and algorithmic breakthroughs and discovery of clever data structures, CPS verification has made astonishing progress. Nonlinear hybrid models with dozens of continuous variables are routinely verified, and linear hybrid models with sparse dynamics with thousands and even millions of variables can be verified. As the following examples illustrate, CPS verification tools have arrived at the point of being commercially viable:

The pioneering tool UPPAAL (Bengtsson et al., 1996; Behrmann et al., 2011) has been used to verify network protocols implemented by ABB (David and Yi, 2000) and Ericsson (Hessel and Pettersson, 2006).

Scalability of verification algorithms for linear hybrid systems has improved by several orders of magnitude in the last decade. One of the groundbreaking tools that have been developed, SpaceEx (Frehse et al., 2011), demonstrated the feasibility of verification of linear hybrid systems with dozens of continuous dimensions. Among many other applications, in Frehse et al. (2014), SpaceEx is used to verify the timing and functional properties of the control software of an electromechanical braking system modeled as a network of HA. Recent tools, such as HyLAA (Bak and Duggirala, 2017; Bak et al., 2019), exploit sparse dynamics, the superposition principle of linear systems, and clever data structures to successfully verify models with more than 10,000 dimensions.

Cyber-physical verification technologies are playing an important role at the bleeding edge of personalized medical devices. The survey by Kushner et al. (2019) gives an overview of the recent developments in the modeling and verification of artificial pancreas systems. Safety verification (Chen et al., 2017) of insulin infusion control systems with idealized patient models has been accomplished using the verification tool Flow* from Chen et al. (2013). Devices undergoing clinical trials have been analyzed by Sankaranarayanan et al. (2017) using the falsification tool S-TaLiRo (Annapureddy et al., 2011). Data-driven approaches suitable for verifying devices with existing patient data have been developed (Kushner et al., 2018; Dutta et al., 2018).

Researchers from Toyota introduced a suite of powertrain benchmark models in Jin et al. (2014). This is an important automotive control system as it affects both fuel efficiency and emissions. The benchmarks were first verified with C2E2 by Fan et al. (2016a), and subsequently with other hybrid verification tools (Roohi et al., 2017b; Arechiga et al., 2015).

A parallel landing protocol developed by the National Aeronautics and Space Administration (NASA) (Perry et al., 2013) to ensure that aircraft approaching closely separated runways always raise an alarm 4 seconds before “loss of safe separation” status was verified using C2E2 (Duggirala et al., 2014). The analysis identified false positives and runway configurations for which the 4-second warning is violated.

Based on informal requirements for the European Train Control System, Platzer and Quesel (2009) have synthesized correct controller parameter values and ranges using the hybrid theorem-proving tool KeYmera (Platzer and Quesel, 2008).

The feasibility of online verification for checking the safety of automatic lane change maneuvers on a real vehicle is demonstrated in Althoff and Dolan (2014). The analysis was performed with linearized approximations of the vehicle dynamics relative to all possible behaviors of pedestrians and other obstacles (e.g., arising from sensor noise, disturbances, and partially unknown initial states) and applied to a Cadillac SRX at the Robotics Institute at Carnegie Mellon University.

An aircraft electric power system uses one or more supervisory control units to actuate a set of electromechanical switches to dynamically and reliably distribute power from generators to loads. In Nuzzo et al. (2015), a methodology for design space exploration for such distributed power systems is presented and demonstrated; a key element of the methodology is the use of the Breach verification tool (Donzé, 2010) for checking requirements.

Ready to launch into the world of cyber-physical system verification? There are several noteworthy online resources that complement this textbook. For the avid experimentalist, the annual Workshop on Applied Verification for Continuous and Hybrid Systems (ARCH) and the related competitions (Althoff et al., 2018; Frehse and Althoff, 2019) will be valuable resources. ARCH publishes dozens of machine-readable benchmark problems and their verification results. The HyST tool from Bak et al. (2015) supports model transformation across the various input languages of the tools, which simplifies comparisons across tools and repeatability. A comprehensive list of cyber-physical system verification tools is maintained at the CPS-virtual organization website (Cyber-Physical Systems Virtual Organization (CPS-VO), 2019).

1.6  Road map

The rest of this book is laid out as follows. Chapters 2–5 cover the modeling of cyber-physical systems. Chapter 6 presents a brief discussion of requirements. Finally, Chapters 7–11 cover the topic of verification. In addition, three appendices provide background material: linear algebra and real analysis are dealt with in Appendix A, computability and complexity theory are addressed in Appendix B, and the specification language for hybrid systems used throughout the book is detailed in Appendix C.

Chapter 2 introduces automata, also known as discrete transition systems, for modeling programs. We discuss the fundamental concepts of states, variables, transitions, executions, reachable states, and invariants. In addition, we introduce the basic constructs of a specification language used throughout the book to succinctly define automata and cyber-physical systems. Examples of simple circuits and distributed mutual exclusion are given to illustrate synchronous and asynchronous modeling styles. It concludes with an example illustrating how automata models can be used to prove simple impossibility results for distributed systems.

Chapter 3 introduces ODEs, which are the language of physics and control systems. We connect ODEs with the notions defined in Chapter 2 and introduce new concepts such as solutions and various types of stability. Also, the chapter presents the standard Lyapunov techniques for verifying stability of linear ODEs and concludes with a short discussion on design of controllers.

Chapter 4 links the automata of Chapter 2 to the differential equations of Chapter 3, in a presentation of the HA modeling framework for cyber-physical systems. We revisit concepts from the previous chapters—executions, reachability, invariants, and stability—in the context of hybrid models, and also note surprising new phenomena, like Zeno executions and switching instability, that are unique to hybrid systems. Example models introduced in this chapter include a simple, rimless walker, an autonomous spacecraft docking system, and a distributed air-traffic management protocol.

Chapter 5 is about composition. Large models are created by putting together or composing smaller pieces. The composition operation combines a pair of interacting pieces to output a single model. Pieces of a cyber-physical system can interact in several ways. We first introduce the input/output automaton (IOA), which generalizes the automata of Chapter 2 with input and output actions. Using I/O actions, the IOA components can interact discretely. We show that distributed algorithms interacting over first-in, first-out (FIFO) channels, for instance, can be modeled as IOAs. Next, we introduce hybrid I/O automata (HIOA), which generalize the hybrid models of Chapter 4. In addition to the composition operation, the chapter discusses the compatibility of automata that allows composition to be valid, and several other operations on automata executions and traces. Examples in this chapter include a platoon of interacting vehicles and a simple model of a pacemaker interacting with excitable cardiac oscillators.

Chapter 6 paints a broad-strokes picture of the amorphous topic of requirements for cyber-physical systems. First, we discuss the DO-178C safety standard, which is required for aerospace software certification; the ISO 26262, which is used in the automotive industry; and the evolving landscape of safety standards for autonomous vehicles. In the second part of the chapter, we present formal requirements in terms of safety, liveness, and temporal logic statements.

Chapter 7 gives a first taste of verification with a simple, yet powerful technique for verifying the invariant requirements of general HA. When applied to pure programs, it is called Floyd-Hoare style reasoning. Invariants capture some of the most fundamental and commonly occurring requirements for cyber-physical systems. The proof techniques presented in this chapter are general in the sense that their implementation could be carried out using pencil and paper, and they could be partially or fully mechanized using theorem provers and satisfiability modulo theory (SMT) solvers. We relate this program analysis technique to the corresponding approaches for reasoning about differential equations that use subtangential conditions and barrier certificates.

Chapter 8 is about verification using composition and abstraction. Suppose that we want to verify that a system 𝒜 meets a specific requirement. If 𝒜 is a complicated model, it may be easier first to verify a simpler model 𝒜′ and then transfer the results to 𝒜. For the transfer to work, 𝒜′ should be related to 𝒜 such that establishing the requirement for 𝒜′ is sufficient to infer the same for 𝒜. Abstraction formalizes that relationship. We also introduce a number of notions of abstractions and techniques for proving abstraction relations, including forward and backward simulations, bisimulations, and time-abstract bisimulations. Further, we discuss substitutivity theorems that allow algebraic reasoning with compositions and abstractions, and we conclude with a brief introduction to counterexample-guided abstraction refinement (CEGAR).

Chapter 9 discusses reachability analysis, which is the cornerstone of modern automatic verification for safety and invariant requirements. We start with the special subclass of timed automata models, for which the algorithmic reachability analysis is exactly solvable. At the other end, we encounter general nonlinear HA for which no algorithm can answer the question exactly and one has to resort to approximations. On the way, we will encounter and examine a famous proof for the undecidability of reachability of rectangular hybrid automata (RHA). The chapter concludes with a discussion of several data structures—ellipsoids, hyperrectangles, polytopes, and zonotopes—that facilitate reachability analysis with approximations.

Chapter 10 can be seen as the complement of Chapter 7, in that it gives a collection of techniques for verifying progress requirements. Starting with termination proofs for automata with ranking functions, we study self-stabilization proofs as an advanced application of the technique in distributed systems. We discuss a general class of topological convergence proof techniques for asynchronous iterative processes. Finally, we close with stability verification approaches for hybrid systems with common Lyapunov functions or multiple Lyapunov functions, and under slow switching conditions.

Chapter 11 covers a promising recent development in the verification of CPS—namely, data-driven verification. Chapters 7–10 rely heavily on the availability of complete models. Data-driven verification utilizes execution data together with models and is often the only available verification approach for complex, nonlinear cyber-physical systems. The approach relies on a notion of sensitivity called the discrepancy function. In the discussion, we define discrepancy and discuss methods for computing this quantity for linear and nonlinear models. We will see how simulation data are combined with discrepancy computation in sound and relatively complete verification algorithms for nonlinear hybrid models. Often, complete mathematical models are not available for cyber-physical systems, but we have access to black-box executables. In such cases, we will see that discrepancy functions with statistical guarantees can be computed by sampling the executions of the black box. Once again, we see how execution data are combined with discrepancy to verify systems with black-box modules. Finally, we discuss examples illustrating data-driven verification in autonomous vehicles, spacecraft control, and engine control systems.

1.7  Learning and teaching using this book

The book is designed for a semester-long early graduate or advanced undergraduate course. The dependencies among the chapters are shown in Figure 1.3. For a semester-long course, the following perspectives may help instructors choose the best order in which to present the chapters:

Computer science   The recommended ordering of topics for computer science students is the following:

Part I (25 percent). Discrete models and verification: Automata (Chapter 2); computability and complexity (Appendix B); inductive invariants (Sections 7.1–7.3 of Chapter 7); progress (Chapter 10, Sections 10.1–10.4); and composition (Chapter 5, Sections 5.1–5.3.3).

Part II (25 percent). Dynamic and hybrid models: Chapter 3 and Chapter 4, with background material from Appendix A as needed.

Part III (50 percent). Verification: Requirements (Chapter 6); invariants (Chapter 7); progress (Chapter 10, from Section 10.5 to the end); abstraction and compositional reasoning (Chapter 8); and data-driven verification (Chapter 11).

Figure 1.3
Dependency graph of the book chapters.

Control theory   The recommended ordering of topics for other engineering students, or for students specializing in decision and control, is the same as the computer science perspective outlined above but with Parts I and II swapped.

Hybrid perspective   The recommended ordering of topics for general engineering students, or a class with an equal mix of computer science and other engineering students, is to follow the sequence of chapters as they appear in the book. The level at which this book is written is somewhere between an advanced undergraduate introduction and a graduate textbook. All of this material can be covered in a semester-long course, although the instructor will probably need to skip some of the more advanced topics and assign them as supplementary reading. The book can serve as an introduction to the main research issues and results on verification of hybrid systems for researchers working in various areas of formal methods and control theory. In addition, the book can serve as a reference for experts in the field of hybrid systems.

Online supporting materials for teaching, such as typical lecture schedules, additional exercises, slides, models, tools, and code, can be found at the book’s website, https://sayanmitracode.github.io/cpsbooksite/. For self-paced learning, there is no substitute for doing exercises, many of which are provided in the book and online.

2

Modeling Computation

Overview

In this chapter, we introduce a mathematical model for computation called an automaton. The term automaton is derived from the nineteenth-century word used to describe mechanical dolls that imitated human movements through intricate clockwork mechanisms. Automata in math, abstracts away the mechanics and describe the rules of state change of any computational process. In this discussion, we introduce the syntax and semantics of a language for defining automata, and conclude with a sample automaton model of a distributed algorithm. We will also see an example of how automaton models can be applied to reason about impossibility of certain distributed computations.

2.1  Quick introduction to automata

2.1.1  Example: JK flip-flop

Consider the clocked JK flip-flop shown in Figure 2.1. It gets as input a sequence of clock ticks, and at every other tick, it sets a new value for the output Q. This corresponds to the setting of the value of Q by the falling edge of the clock signal. The value of Q depends on the values of the other two inputs, J and K: when J and K are 0, Q is held to its previous value; when J is 0 and K is 1, Q is reset to 0; when J is 1 and K is 0, Q is set to 1; and finally, when J and K are 1, Q is toggled. From that description, we see that Q’s future depends on the inputs J and K, the clock, and its own previous value. In our automaton model for the flip-flop, those quantities will correspond to the state variables and their evolution at every tick will be described by changes or transitions in the state variables.

Figure 2.1
JK flip-flop timing diagram of variables. Initially, J = K = 1, and Q toggles at every falling clk edge. At the sixth clock tick, the input signal K is set to 0, and later J also becomes 0.

2.1.2  Language for specifying automata

In this book, we will use a stylized language for specifying automata. The specification of a JK flip-flop in this language is shown in Figure 2.2. We will not get too caught up in the syntax of this language, but the meaning or semantics of the resulting automaton will be important. Several verification tools use similar specification languages, and getting used to this will be beneficial if you want to use them.

Figure 2.2
A specification of a JK flip-flop.

The flip-flop specification begins with the name of the automaton: FlipFlop. The body of the specification has three parts: (1) the actions section lists the various types of rules or actions for state change; (2) the variables section lists the state variables; and (3) the transitions section lists the state change rules for each of the actions.

The automaton FlipFlop has a single action called tick, which models every clock tick—both the positive and the negative clock edges. The variables section declares and initializes the state variables of the automaton. Each variable declaration consists of the variable name, its type, and, optionally, its initial value. For example, clk is declared as a Boolean variable with initial value 0. That choice, as we shall see shortly, implies that the clock signal is initially 0 and that the first tick is a positive edge.

The transitions section of FlipFlop lists rules for state changes corresponding to each action. For each action, it gives a precondition and an effect preceded by the keywords pre and eff, respectively. The precondition specifies states in which the action can occur. The precondition is also known as the guard condition or the enabling condition of the action. The effect (also known as the command) specifies how the state changes when the action does occur. The tick has a precondition of true, which implies that this action can occur in any state. It is always enabled; it cannot be blocked. The effect of a tick transition is to instantaneously toggle clk; if the new value of clk is 0 (i.e., the tick corresponds to a falling clock signal), then the value of Q is updated according to the values of J and K described earlier. The operators and the syntax of the effect statements are similar to those in standard programming languages; Appendix C gives more details about the syntax and the semantics of this language. The statements in the eff block are executed sequentially. For instance, in Figure 2.2, the value of clk checked in line 14 is the value obtained after clk was flipped in line 13.

That was an informal description of the FlipFlop automaton, as specified by the code in Figure 2.2. Next, we will relate it to the mathematical object defined by the specification.

2.2  Specifying automata

The mathematical object we will use to model computations is an automaton (also called a discrete-time transition system or a state machine). To specify an automaton, we must first introduce the notions of variables and states, which we will do next.

2.2.1  State variables and valuations

The state represents the information necessary for predicting the future of an automaton. We will model states using valuations of state variables.

A variable is a named quantity. To be more precise, a variable is a name and an associated type over which it takes values. For a variable v, the type is denoted by type(v). In FlipFlop, the set of state variables is VFlipFlop = {J, K, Q, clk}, and type(J) = type(K) = type(Q) = {0, 1} = Bool. In general, a variable can have other types used in mathematics and programming languages, such as integers (Int), real numbers (Real), floats (float), doubles (double), natural numbers (Nat), and enumerated sets. Type constructors like arrays, lists, tuples, and records can be used to construct user-defined types from these basic types.

A valuation for a set of variables V maps each variable name v ∈ V to a value in type(v). For example, a valuation for VFlipFlop is the mapping

We will adopt the convention of using boldfaced letters (v, x, and so on) to denote valuations. Given a set of variables V, val(V) denotes the set of all possible valuations of the variables in V. This set is also called the state space of the model. The set val(VFlipFlop) is the set of all possible combinations of values that J, K, Q, and clk can take. That state space is isomorphic with the set {0, 1}⁴ [i.e., for every point in {0, 1}⁴, there is a corresponding point in val(V), and vice versa]. However, to be absolutely precise, these two sets are not equal—in fact, they have different types: each point in val(V) maps each of the four variable names to a Boolean, whereas a point in {0, 1}⁴ is simply a vector of four Booleans.

Given a valuation v in val(VFlipFlop), we can refer to the values of an individual variable (say clk), using the restriction operator v ⌈ clk. The operation ⌈ restricts the mapping v to a subset of its domain. More generally, for any subset of variables X ⊆ V, v ⌈ X maps each x ∈ X to the corresponding point in type(x).

2.2.2  Predicates

Given a set of variables V, instead of enumerating individual valuations as in Equation (2.1), we can succinctly specify subsets of valuations by using formulas or predicates. A predicate over V is a Boolean-valued formula involving the variables in V. For example, J = 0 ∨ K = 1 and J = K are predicates on the state variables VFlipFlop of FlipFlop. When the need arises, we will have to be more precise about the syntax of predicates. For now, though, assume that all standard arithmetic, logical, comparison, and relational operators may be employed as usual.

We say that a state v ∈ val(V) satisfies a predicate ϕ over V if ϕ evaluates to true when all the variables that appear in ϕ have been replaced with their corresponding values in v. For example, the state

satisfies the formula ϕ₁:= (J = 0 ∨ K = 1) because

The statement that “the state v satisfies the predicate ϕ” is written briefly as v ϕ. The same state v does not satisfy the formula ϕ₂:= (J = K). We say that v violates ϕ₂ and write this as v ⁄ ϕ₂. A predicate ϕ on a set of variables V defines a subset [[ϕ]] ⊆ val(V) as follows:

That is, [[ϕ]] is the set of valuations of V or states that satisfy the predicate ϕ. The set [[ϕ]]c, and equivalently [[¬ϕ]], is the set of valuations that violate ϕ. The predicate ϕ is sometimes used synonymously with the set of states [[ϕ]] that satisfy it.

2.2.3  Transitions

To specify the rules for state change in a computation, we need to relate pairs of states: a prestate, which is the state just before the change occurs, and a poststate, the state after the change. Transition relations, or simply transitions, specify such state change relations. Formally, a transition relation over a set of variables V is the relation R ⊆ val(V) × val(V ).

If the clock variable is singled out as Vclk = {clk}, then the toggling relation Rtog ⊆ val(Vclk) × val(Vclk) can be defined as follows:

Writing out transition relations by enumerating prestates and poststates can quickly become tedious. Hence, transition relations are specified as predicates on the prestates and poststates. For example, the precondition and effect statements

define a transition relation R ⊆ val(Vclk) × val(Vclk) with (v, v′) ∈ R, if and only if v ∈ [[true]] = val(Vclk) and v′⌈ clk = ¬(v ⌈ clk). In general, the predicate following the precondition defines the set of states in which this transition rule can be applied, and the (possibly nondeterministic) program following the effect relates the prestate and the poststate. The effect statements may involve all kinds of common operators, like arithmetic, logical, and conditional operators, and they may involve assignments that involve a nondeterministic choice (e.g., clk:= choose {0, 1}). The variables that are not mentioned in the effect statements are assumed to remain unchanged by the transition.

2.2.4  Automata

Now we have all the elements we need to define an automaton.

Definition 2.1.   An automaton 𝒜 is a tuple (V, Θ, A, 𝒟), where

1. V is a set of variables called the state variables. The set val(V) of valuations of V is the set of states.

2. Θ ⊆ val(V) is a nonempty set of start states.

3. A is a set of actions or transition labels.

4. 𝒟⊆ val(V) × A × val(V ) is called the set of transitions.

The set of initial states Θ is specified by initializing the variables or by a predicate on V. For example, for the FlipFlop automaton, the set of start states Θ is the singleton set with the state given by Equation (2.1). The set of actions A can be useful for labeling the state transitions, and also for synchronizing across automata (see Definition 5.3 in Chapter 5).

For FlipFlop, A = {tick}. A triple (v, a, v′) is a valid transition of an automaton if there is a transition definition for the action a in the program, such that

1. v Prea, that is, v satisfies the predicate Prea, and

2. (v, v′) Eff a, that is, (v, v′) satisfies the predicate defined by the Eff a program.

Because the precondition of the tick action is true, the set of transitions 𝒟 for FlipFlop is defined as (v, tick, v′) ∈𝒟 if and only if:

A transition (v, a, v′) ∈𝒟 is written in short as , or as when the name of the automaton 𝒜 is clear from the context. If , we say that action a is enabled at the state v. Given a transition (v, a, v′), its prestate is v and its poststate is v′. The set of states at which the action a is enabled is denoted by Enabled(a), and is also the set of states that satisfy the precondition predicate of the action a in the specification. Given a state v and an action a, Post(v, a) is the set of poststates of v after performing action a, i.e., . This definition is extended to a set of states S ⊆ val(V) and a set of actions B ⊆ A and states as:

Post(S, B) is written as Post𝒟(S) or simply as Post(S) when the transition relation 𝒟 is clear from context.

If there are multiple automata in the mix 𝒜, ℬ, and so on, then we will distinguish their components by the corresponding subscripts, (V𝒜, Θ𝒜, A𝒜, 𝒟𝒜) and (Vℬ, Θℬ, Aℬ, 𝒟ℬ).

2.3  Special automata classes

2.3.1  Finite and discrete automata

If the cardinality of the state space val(V) is finite, then 𝒜 is called a finite automaton or finite state machine (FSM). Otherwise, 𝒜 is an infinite state automaton. Even if the state space of 𝒜 is uncountable, the state changes only according to the discrete transitions; therefore, another name for an automaton model of Definition 2.1 is a discrete transition system.

2.3.2  Nondeterminism

In general, an automaton 𝒜 is nondeterministic. It is impossible to predict its state with certainty. There may be multiple initial states in Θ, and from a given state v, there may be multiple enabled actions (a, b ∈ A, such that , and v₂ ≠ v₁). Indeed, for a given state v and a fixed action a ∈ A, there may be multiple poststates (, with v₂ ≠ v₁). The choice over enabled actions is called external nondeterminism, and it captures the uncertainty about the scheduling of possible actions that is controlled by an environment external to the automaton. The choice of poststate for a given action is called internal nondeterminism, and it captures the uncertainty of the outcome of performing an action such as a coin flip.

For the FlipFlop automaton, we can predict the state exactly after k transitions. We can see that with an inductive argument: FlipFlop has a single start state; there is a single action tick; and from each state, there is a uniquely defined poststate that occurs after the tick transition. This property makes the FlipFlop a deterministic automaton. For any deterministic automaton, given an initial state, its state after k transitions is uniquely defined, provided, of course, that the automaton can take k transitions.

2.3.3  Discrete sequences and sampled time

An automaton models the ordering of events or states. A sequence like captures the behavior that starts from state v₀, after which action a₁ occurs and the state changes to v₁, after which action a₂ occurs, and so on. This sequence does not say anything about the time that elapses between v₀ and v₁. The action a₁ could model the simple tick of a clock or the complex protocol that results in the election of a new leader. Because the transitions do not say anything about timing, the automaton models of this chapter are called time-abstract.

It is possible to attach additional timing-related meaning to the transitions of an automaton 𝒜. For example, we can choose a sampling period δ > 0 and assume that each transition corresponds exactly to the passage of δ seconds. That implicitly defines a time axis t = 0, δ, 2δ, 3δ, …, and the sequence is then interpreted to mean that the state of 𝒜 is v₀ at time 0, v₁ at time δ s, v₂ at 2δ s, and so on. This interpretation is a natural timing model for FlipFlop, with δ assigned to be the clock period of the computer. Models of this type are called discrete- or sampled-time models. A word of caution: although FlipFlop is deterministic, the state of the automaton at time kδ is not uniquely defined, and to be precise, we must refer to the prestate and poststate of the kth tick.

2.4  Semantics: Executions, reachable states, and invariants

An execution fragment of an automaton 𝒜 describes a particular behavior or run of the model. Formally, an execution fragment is an alternating, possibly infinite, sequence of states and actions v₀, a₁, v₁, a₂, …, where (1) each vi is a state val(V); (2) each ai is an action in A; and (3) each consecutive triple (vi, ai+1, vi+1) is a valid transition in 𝒟. An execution fragment is an execution if, in addition, the first state v₀ is in the initial set Θ. The first state of an execution fragment α is denoted by α.fstate. If the fragment is finite α = v₀, a₁, …, vk, then the last state vk is denoted by α.lstate.

The set of all executions of 𝒜 from Θ is denoted by Execs𝒜(Θ). Execs𝒜(Θ, k) is the set of executions of a maximum length of k. A graph of an execution of the FlipFlop automaton is shown in Figure 2.1 earlier in this chapter. A state v ∈ val(V) is said to be reachable from Θ, or simply a reachable state (when Θ is clear from the context), if there exists a finite execution that ends at v. The set of all the reachable states of 𝒜 is called the reach set or reachable set of 𝒜, which is denoted by Reach𝒜(Θ), or by Reach𝒜 when the initial set Θ is clear from the context. The set of states reachable in at most k steps is denoted by Reach𝒜(Θ, k). That is, for the FlipFlop automaton we can write ReachFlipFlop(Θ) = [[(J = 1 ∧ K = 1)]].

An invariant for an automaton 𝒜 is a set of states S that contains all of 𝒜’s reachable states (i.e., Reach𝒜(Θ) ⊆ S). Starting from the given initial set Θ, the automaton 𝒜 never goes to any state outside an invariant S. Invariants are often expressed as predicates on the state variables of the automaton. In that view, an invariant is a predicate or a property of the system that always remains true. We will discuss automatic verification of invariants of automata in Section 9.2.1 in Chapter 9.

2.5  Example: Dijkstra’s token ring algorithm

As the next example, we study a model of a distributed algorithm in a ring of n-processes. Edsger Dijkstra proposed this algorithm as the first example illustrating self-stabilizing behavior (Dijkstra, 1974). There are n processes arranged in a unidirectional ring as in Figure 2.3. Each process i ∈{0, …, n − 1} has a single variable x[i] that takes as values a set K = {0, …, n}. Process i has a token if and only if

Figure 2.3
Legal (left) and illegal (right) token ring configurations. The gray processes have tokens.

Whenever a process i has a token, it may update its state x[i]. Process 0 updates by incrementing x[0] by 1 modulo n; each other process (i ≠ 0) updates by copying the value x[i− 1] of its predecessor. A state of the system is legal if only one process has a token; otherwise, it is illegal.

The automaton template DijkstraTR, which models this algorithm, is shown in Figure 2.4. The specification has a formal parameter n, which is similar to function arguments in C or Java. Formal parameters are not the state variables of the automaton. Fixing a specific value of the parameter n (say n = 7) gives us an instance (DijkstraTR(7)) of the template with that number of processes (7 in this case). We may also want to prove properties about all instances of DijkstraTR without fixing n.

Figure 2.4
An asynchronous model of Dijkstra’s unidirectional token ring algorithm.

Prior to defining the states and transitions of DijkstraTR, we define two dependent enumeration types, ID and K. The automaton has a collection of n actions A = {update(0), …, update(n − 1)}. It has an array type variable x that maps ID to K. The ith component of the array, x[i], will be the value of the ith process. Because no initial state is specified, Θ = val(x) (i.e., the set of all the Kn possible valuations of x). An update(i) action is enabled as defined by Equation (2.4). When an update(i) action occurs, process i will read the value x[(i − 1)] of i’s predecessor in the ring and update x[i]. Each transition definition has two parts. The precondition defines the enabling condition, or the set of states in which the transition may occur, and the effect part, as mentioned earlier, defines how x[i] is updated by reading x[(i − 1)] when the transition does occur.

Multiple transition definitions for the same action   Because the update rules for process 0 are distinct from those of other processes, the definition of the update(i) transitions is split into two separate definitions that have disjoint preconditions. In general, the same action a ∈ A may have multiple preconditions and effects, and it is not necessary for these preconditions to be mutually disjoint. In this model, we have assumed that process i can read the state of its predecessor.

2.5.1  Legal states and invariants

The legal states of the system can be specified by the predicate ϕlegal as follows:

where ⊻ is the exclusive or (xor) operator, which requires that exactly one of the conditions in parentheses hold (i.e., exactly one process has a token). The ϕatleast1 predicate specifies the set of states that have at least one token:

Exercise 2.1.   Show that val(x) = [[ϕatleast1]]. That is, ϕatleast1 is an invariant of the automaton DijkstraTR(n) and it is impossible for all the tokens to disappear.

Exercise 2.2.   Write two finite executions of DijkstraTR(7): one that starts from an initial state with a single token, and another that starts with multiple tokens. What do you observe?

Executions of DijkstraTR have a remarkable property: they always eventually end up in legal states with a single token! This is an example of a self-stabilizing property, and we will revisit this property later in this book in Chapter 10.

2.5.2  Asynchronous and synchronous models

For any choice of n, DijkstraTR(n) is a nondeterministic automaton with several possible executions. There are many starting states. Further, from a state in which multiple processes have tokens, any of those processes could perform the update(i) action. It is possible that in a given execution of DijkstraTR, the update(5) action will occur many times before update(n − 1) occurs even once. In other words, the computations at the various processes may proceed at different, independent rates. Such models of distributed systems are called asynchronous. In contrast, in a synchronous model, the computation advances in rounds. In each round, all the n processes have to perform their computations or update(i)s before the next round can begin.

DijkstraTR(n) implicitly assumes that the state vector x is a shared variable across processes because each process i can read the state x[i − 1] of its predecessor process and write only to its own state x[i]. Shared memory systems constitute a common programming model for distributed systems. An alternative model is the so-called message passing system, in which each process would have to explicitly send messages to update the state of other processes.

2.6  Example: Reasoning about impossibility

The idea of specification templates can go well beyond the scalar parameters seen in DijkstraTR. The automaton BiDiLeader of Figure 2.5 models the behavior of any deterministic synchronous algorithm running on a bidirectional ring. It is parameterized by a natural number n, a (possibly infinite) type K that will correspond to the state space of each process, and a function F that maps K³ to K and will correspond to the state transition rule.

Figure 2.5
A generic leader election algorithm on a bidirectional ring.

With BiDiLeader, we can reason about not just a single system or different instances of an algorithm, but a whole class of algorithms. For example, Invariant 2.1 asserts that if BiDiLeader starts from a state in which all processes have identical values, they will forever continue to be identical. The implication is that it is impossible for any synchronous algorithm on a bidirectional ring ever to break a tie. Therefore, it is also impossible for any algorithm modeled by BiDiLeader to elect a leader.

In more detail, the state variable x is the array of the states for all the processes. It is assumed that all the processes start out in the same state (line 8). BiDiLeader has a single action, step, which models the computation performed synchronously at each process at each round; each process i atomically updates its state by computing F on its own state and the states of its two neighboring processes from the preceding round. To apply F to the processes’ states from the preceding round, the second state variable, y, is used to record x before the process states are updated.

BiDiLeader describes a whole family of synchronous algorithms. as K can be any type and F can be any function. We can use BiDiLeader to prove properties for the entire family. For example, Invariant 2.1 asserts that all the processes have identical states.

Invariant 2.1.   For all i, j ∈ [n], x[i] = x[j].

Proof. First, notice that for a fixed starting state, BiDiLeader has a single infinite execution α = v₀ step v₁ step …, as defined by the transition function: for each k ∈ ℕ, i ∈ [n]:

From the definition of the initially clause, it follows that v₀ satisfies the invariant. Assuming that vk satisfies the invariant, for each i, j ∈ [n] vk ⌈ x[i] = vk ⌈ x[j], and therefore vk+1 ⌈ y[i] = vk+1 ⌈ y[j], and since F is a function, we have vk+1 ⌈ x[i] = vk+1 ⌈ x[j].

Invariant 2.1 shows that starting from a state in which all the processes have identical values, it is impossible for any synchronous algorithm on a bidirectional ring to break the symmetry and reach a state in which any process has a state different from the other processes’ states. This is an example of the use of modeling and analysis to establish a negative result. In this case, the invariant establishes the limits of the class of synchronous algorithms.

In this chapter, we have seen how computing processes are mathematically modeled as state transition systems or automata. We have introduced a language for specifying automata by using state variables, predicates, actions, and transitions. We defined the semantics of automata, executions, reachable states, and invariants. In the next chapter, we will see how physical processes are mathematically modeled using differential equations, and we will relate those models to automata.

2.7  Exercises

Exercise 2.3.   Model the following leader election algorithm in a unidirectional ring. Each process sends its identifier to its successor around the ring. When a process receives an incoming identifier, it compares that identifier to its own. If the incoming identifier is greater than its own, it keeps passing the identifier; if it is less than its own, it discards the incoming identifier; and if it is equal to its own, the process declares itself the leader.

(a) Write a model of the system with n processes in the ring, using the language introduced in this chapter. The two variables are (1) send, which stores the identifier to send or null; and (2) status, which takes values in {unknown, leader} to indicate whether the leader has been elected.

(b) Write an execution of the system in which a leader is eventually elected.

(c) Write two candidate invariants.

Exercise 2.4.   Show that the algorithm of Figure 9.1 in Chapter 9 computes whether a set of target states T can be reached from a set of initial states S of a given automaton. Review from Section B.2.1 of Appendix B the accepting condition for a nondeterministic Turing machine.

Exercise 2.5.   Write the components of the automaton 𝒜RippleCounter for the specification RippleCounter in Figure 2.6 as we discussed in Section 2.2.4. Is the automaton 𝒜RippleCounter deterministic? Plot one of its executions. Define the reachable states of RippleCounter.

Figure 2.6
3-bit ripple counter.

Exercise 2.6.   Write an automaton model of John Conway’s Game of Life (Gardner, 1970). The game evolves in an infinite two-dimensional (2D) array of cells that are either live or dead. You can model the state as a binary-valued, infinite matrix (ℕ×ℕ → Bool). The four rules updating the state of every cell are as follows: (1) any live cell (with value = 1) with fewer than two live neighbors dies; (2) any live cell with two or three live neighbors continues to live; (3) any live cell with more than three live neighbors dies (value set to 0); and (4) any dead cell with three live neighbors becomes a live cell.

Exercise 2.7.   Model a 1-dimensional (1D) vehicle’s position, velocity, and acceleration moving in a single lane. The vehicle could be in one of three “modes”: cruising with zero acceleration, speeding with acceleration amax, or braking with acceleration − amax. The transitions among these modes are brought about nondeterministically.

Exercise 2.8.   Write a synchronous specification of Dijkstra’s token ring algorithm in which every process with a token updates its state in every round simultaneously. Is this model deterministic?

Exercise 2.9.   Consider an automaton 𝒜 and a set of states F ⊆ val(V) such that (1) there are no outgoing transitions from the states in F and (2) every execution of 𝒜 eventually reaches a state in F. Show that all executions of 𝒜 are finite.

Exercise 2.10.   Consider automaton 𝒜 and the set F ⊆ val(V) as defined in Exercise 2.9. (a) Build an automaton 𝒜′ that reverses 𝒜. That is, for every α = v₀, a₁, …, vk ∈ Execs𝒜, vk, ak, …, a₁, v₀ ∈ Execs𝒜′. (b) Suppose that 𝒜 is deterministic; is 𝒜′ necessarily also deterministic?

Exercise 2.11.   Create a model of a leader election algorithm running on an unidirectional ring as follows: Each process sends its identifier to its successor around the ring. When a process receives an incoming identifier, it compares that identifier to its own. If the incoming identifier is greater than its own, it keeps passing the identifier; if it is less than its own, it discards the incoming identifier; and if it is equal to its own, the process declares itself as the leader. To get you started, the set of variables is: 1. send: The identifier to send or null; and 2. status: Takes values in {unknown, leader} to indicate whether the leader has been elected or not. Write an execution of the system in which the status of at least one process is eventually set to leader. Write two candidate invariants.

3

Modeling Physics

Overview

In this chapter, we will introduce ordinary differential equations (ODEs), the language for specifying physical processes. An ODE describes the instantaneous rules that govern the change of state of a physical process. We will discuss the syntax and semantics for specifying ODEs, as well as various notions of solutions. We will introduce and cover models for vehicle speed control, a pendulum, a helicopter, and others that reappear later in the book. Finally, we will explore special classes of ODEs and conclude with basic techniques for stability analysis.

3.1  Quick introduction to differential equations

3.1.1  Example: Vehicle speed control

Consider modeling a car driving in a single lane starting from a position on the x-axis p₀. Suppose that the car has to arrive and stop at another point p₁, as soon as possible. We assume that p₁ > p₀. The position, the speed, and the acceleration of the car are x, v, and a, respectively. The speed limit is vmax; the maximum acceleration and brake are amax and amin; and that acceleration can be changed instantaneously. The quickest way to get from p₀ to p₁ is shown in Figure 3.1; starting from p₀, there is a period of maximum acceleration to reach vmax, then the car cruises at vmax, and at some point, the driver applies the maximum brake amin to come to a halt precisely at p₁. In our model, the relationship among x, v, a, and time will be specified by differential equations, as discussed next.

Figure 3.1
Trajectory of position (x), velocity (v), and input acceleration (a) for the simple car model of Equations (3.1) and (3.2). To reach and stop at the target position of x = 30, the car applies a maximum acceleration (amax = 1) to reach the maximum speed, then cruises (a = 0) for a while, and finally applies maximum braking force (amin = −2).

3.1.2  Language for specifying differential equations

In the standard notation for describing differential equations, the single-lane car would be modeled by

A lot of information is packed into those two lines. To start with, x, v, and a are the real-valued variables corresponding to position, velocity, and acceleration. A fourth implicit variable in this system is time, which here is denoted by t. Time is also real-valued. The notation is shorthand for , the time derivative of position x. Equation (3.1) relates the rate of change of position to velocity. Similarly, Equation (3.2) relates the rate of change of velocity to acceleration. The acceleration is not specified; we treat it as an input to the model.

We will extend the language of Chapter 2 to the specification of differential equations. Figure 3.2 shows the specification of the single-lane car. It has two parts: (1) the variables section lists the state variables, and (2) the trajectories section lists differential equations, equating the time derivative of each variable to functions of other variables. The variables section declares and possibly initializes the variables. Each variable declaration consists of the variable name, its type, and, optionally, its initial value. The variable types here are a bit redundant, as we will assume that all variables involved with differential equations are real-valued. Specific values of these variables define the state of the vehicle at a given time instant. The trajectories section specifies how the values of the variable can change over time. The evolve clause of LineCar gives differential equations for x and v. Some variables, such as the acceleration a in LineCar, may not have a corresponding differential equation. Fixing the time evolution of a to be as shown in Figure 3.1, we can see that v and x evolve as depicted. In general, for a variable y, an equation of the form is written as d(y):= f(y). The syntax for writing f is similar to that of standard programming languages. It is not obvious whether every such specification and every possible behavior of the unspecified variables (like a) defines a meaningful behavior for the other variables. In Section 3.2.3, we will discuss conditions under which the differential equations do specify meaningful behavior.

Figure 3.2
A vehicle traveling in a single lane.

3.2  Specifying ordinary differential equations

The standard language for describing physical processes is the language of ODEs. We introduce the elements of ODEs in the next few sections.

3.2.1  State variables and valuations

ODEs describe how a system state changes with time, and the state is captured by valuations of a set of state variables. As discussed in Chapter 2, a variable is a name of a modeled quantity, and it is associated with a type, or the set of values that it can take. In this chapter, variables will typically model physical quantities, and they will be of type Real. For LineCar, the set of variables VLineCar = {x, v, a}, and type(x) = type(v) = type(a) = ℝ. A valuation is a mapping from variable names to their types. For the set VLineCar, for instance, a sample valuation v is this mapping:

The set of all valuations is denoted by val(V) and corresponds to the state space of the model. The state space val(VLineCar) of LineCar is isomorphic with the set ℝ³. Given a state v for LineCar, we refer to the acceleration a of the vehicle at v as v ⌈ a = 6.5. Similarly, we refer to the position and the velocity at v by v ⌈ x and v ⌈ v. The operation ⌈ restricts the function v to a subset of its domain.

A variable x with type(x) = ℝn takes values that are vectors in ℝn. That is, val(x) is isomorphic to the vector space ℝn. A valuation x maps x to a vector in ℝn. We will use the usual vector notations on x. For example, |x| and ||x|| will denote, respectively, the 1-norm and the 2-norm of x. For any δ > 0, Bδ(x) {x′∈ val(x) | ||x − x′||≤ δ} is the closed δ-ball around x.

3.2.2  Dense time and trajectories

A trajectory models how the variable valuations change over time. In this chapter, we will adopt the real line ℝ as the time axis. This is called the dense time model. Dense time is a natural view of time for modeling physical processes. Of course, we could alternatively take a discretized or sampled view of these processes and model time as integers.

For T ∈ ℝ≥0 and a set of variables V, a trajectory τ of duration T for V maps each point in the interval [0, T] to val(V). For example, the trajectory τ in Figure 3.1 corresponds to a situation in which the acceleration remains constant at amax for 0.4 seconds, is then 0 for another 0.3 seconds, and finally becomes amin for 0.2 seconds. The trajectory for velocity (v) is obtained by integrating the trajectory for acceleration (a) over time, and the trajectory for position (x) is obtained by integrating velocity. We refer to those components of τ with τ ↓ a, τ ↓ v, and τ ↓ x, respectively. Specifically, τ ↓ a is a mapping [0, T] → type(a) and is defined as (τ ↓ a)(t) = τ(t) ⌈ a for any t ∈ [0, T]. τ.dom is used to denote the domain of any trajectory τ.

These trajectories are of finite duration and are closed at the right end points. An open trajectory τ: [0, T) → val(V) maps an open interval to valuations. An infinite trajectory is an open trajectory that maps [0, ∞) to val(V). If T = 0, then τ is a point trajectory that maps the point [0, 0] to val(V). A point trajectory mapping to the valuation v is denoted by ℘(v).

Trajectories can be explicitly defined as functions of time. For example, a trajectory τ for VLineCar is explicitly defined as follows: for each t ∈ τ.dom, and any initial position p₀, velocity v₀, and acceleration a₀,

Often, it will be too cumbersome (or even impossible) to write out explicit functions for the trajectories, and we will have to specify the trajectories as solutions of differential equations.

3.2.3  Trajectories as solutions

An ODE is conventionally written as

where t ∈ ℝ is the independent time variable, x is the state with type(x) = ℝn, and u is the input with type(u) = ℝm for some n, m ∈ ℕ. The shorthand denotes the (component-wise) derivative of x with respect to time t. The time-varying function f: val(x) × val(u) × ℝ → val(x) specifies the time derivative of the state components as a function of the state and the input.

Read as a constraint on variable valuations, Equation (3.7) can be confusing. If x is a variable, what is x(t)? Why is even well defined? Actually, Equation (3.7) is a constraint on the trajectories of the variables involved (namely, x and u). A trajectory that satisfies these constraints—provided one exists—is called a solution of the ODE. There are different notions of solutions and corresponding results on existence and uniqueness of solutions. We begin with a simple and natural definition of a solution.

Definition 3.1.   For any trajectory η: [0, T] val(u) of the input variable u, and an initial valuation x₀ ∈ val(x), a trajectory ξ: [0, T] val(x) is a solution of Equation (3.7) if

That definition of solution is rather restrictive, as it requires ξ to be not only continuous, but also differentiable with respect to t. If the input signal η is not continuous—for example, as in Figure 3.1—then ξ may not be differentiable at the points of discontinuity, and is not well defined. Discontinuous inputs are the norm rather than the exception. In a cyber-physical system, the input u is typically computed by software, possibly by solving an optimization problem, and it is free to change discontinuously over time. We will begin to generalize this notion of solution by defining a class of functions that are suitable for modeling input trajectories.

Definition 3.2.   A trajectory η: [0, ∞) → val(u) is piecewise continuous with a set of discontinuity points DCη ⊆ η.dom if

1. For all td ∈ DCη, left- and right-side limits of η exist at td—that is,

2. It is continuous from the right—that is, .

3. Over any finite interval there are only finitely many discontinuities—that is, for any t₀ < t₁, [t₀, t₁] ∩ DCη is finite.

Exercise 3.1.  Show that piecewise continuous functions are closed under composition and linear combinations.

For the remainder of this chapter, we will assume that f: val(x)×val(u)× ℝ → val(x) is continuous with respect to the second and the third arguments. If we fix a piecewise continuous input η and define p: val(x) × ℝ → val(x) as p(x, t) f(x, η(t), t), observe that this function is piecewise continuous with respect to t, with points of discontinuity DCp = DCη.

Definition 3.3.   For any piecewise continuous input trajectory η: [0, T] val(u), and an initial valuation x₀ ∈ val(x), a trajectory ξ: [0, T] val(x) is a solution of Equation (3.7) if

This definition says what it means for a trajectory ξ to be a solution of an ODE.

Exercise 3.2.  Find an initial state for which the following differential equation (without inputs) does not have any infinite trajectories:

The sign function (sgn) is defined as follows:

Exercise 3.3.  Show that from certain initial states, the following differential equation does not define any infinite trajectories:

Those examples show that solutions of ODEs may not always exist (e.g., if f is discontinuous in x or if it grows too rapidly with respect to x). In order to ensure that a solution exists and is uniquely defined, we need to impose some additional requirements on f.

Definition 3.4.   A function f: ℝn → ℝn is Lipschitz continuous if there is a constant L > 0 such that for any x₁, x₂ ∈ ℝn, ||f(x₁) − f(x₂)|| < L||x₁ − x₂||. L is called a Lipschitz constant of f.

All differentiable functions with bounded derivatives are Lipschitz continuous.

Exercise 3.4.  Show each of the following:

(a) sin(x) and cos(x) are Lipschitz.

(b) |x| is not differentiable but Lipschitz.

(c) x² is not globally Lipschitz, but it is locally Lipschitz (i.e., over any bounded domain).

(d) is neither globally Lipschitz nor locally Lipschitz.

This definition of Lipschitz continuity can be naturally extended to mappings between arbitrary metric spaces. Theorem 3.1 gives a sufficient condition for an ODE to define unique solutions or trajectories (Hespanha, 2009).

Theorem 3.1.   If f of Equation (3.7) is Lipschitz continuous in the first argument, then for any piecewise continuous input trajectory η, the differential equation has a unique solution.

If the function f is Lipschitz continuous, then for each initial state x₀ and input η, according to Theorem 3.1, there is a unique solution or state trajectory ξ: [0, T] → val(x). That makes the ODE deterministic. Unless stated otherwise, all ODEs considered in this book will satisfy these conditions and thus will be guaranteed to have unique solutions. But knowing that solutions exist is only the beginning. Finding closed-form or analytical solutions for nonlinear ODEs is, in general, hard. In Section 3.8, we will discuss how numerical approximations of trajectories are computed.

3.3  Special classes of ODEs

3.3.1  Time-invariant and autonomous systems

If the function f on the right side of the ODE [Equation (3.7)] is independent of time, then the system described by the ODE is said to be a time-invariant system. However, time-invariant can be a confusing adjective. Consider a time-invariant clock model and an initial value of clk = 0 at t = 0. The solution of this ODE is the trajectory ξ, with (ξ ↓ clk)(t) = t for all t ≥ 0, and ξ obviously depends on time. Thus, time invariance really means that the trajectory from time point t depends only on the current state and the current inputs, not on the value of the independent variable t.

An autonomous system is an ODE without inputs; it is described by

and if it is also time-invariant, then by

3.3.2  Linear systems

If the function f on the right side of the ODE [Equation (3.7)] is a linear function of the state x and the input u, then the system is said to be linear. As any linear f can be represented by matrix-vector products, the standard representation for a linear (time-varying) system takes the form

where x(t) and u(t) are the state and input vectors, and A(t) and B(t) are matrix-valued functions of t. Linear systems are by far the most popular models for physical processes, in part because their solutions are linear. Our presentation of the following well-known theorem characterizing solutions of linear systems is based on Hespanha (2009).

Theorem 3.2.   Let ξ(x₀, t, η) denote the trajectory of Equation (3.14) evaluated at time t, for any initial state x₀ ∈ val(x) and with any piecewise continuous input η: [0, ∞) → val(u).

(a) (Continuity with time) ξ(x, ·, η): ℝ → val(x) is continuous and differentiable everywhere except DCη.

(b) (Continuity with initial state) ξ(·, t, η): val(x) → val(x) is continuous with respect to the initial state x₀.

(c) (Linear space of solutions) For any pair of initial states x₀, and inputs η, η′: [0, ∞) → val(u), and real constants a₁, a₂ ∈ ℝ,

(d) (Decomposition of effects of initial state and inputs) For any initial state x₀ ∈ val(x) and input η: [0, ∞) → val(u),

Part (c) of Theorem 3.2 gives the critical characterization that the space of solutions of Equation (3.14) forms a linear vector space. Then part (d) gives a useful decomposition of the effects of the initial conditions and the inputs.

If A(t) and B(t) are independent of t, then the system is called a linear time-invariant (LTI) system. One important property of LTI systems is that their solution for the initial value problem can be written in terms of elementary functions. For any initial state x₀ ∈ val(x) and input η, the unique trajectory ξ of the LTI system is given by

See lecture 5 of Hespanha (2009) for a proof. Recall that the matrix exponential eAt is defined as the infinite sum

Although it can be shown that the series converges for any square matrix A, it is usually not easy to compute precisely (Moler and Van Loan, 2003). One case in which computation of eAt is straightforward is when A is diagonalizable (i.e., we know a nonsingular matrix P such that P⁻¹AP is a diagonal matrix D with the eigenvalues {λi} of A as the diagonal entries). In that case, the diagonal entries of eAt = PeDtP⁻¹, and eDt is a diagonal matrix with the diagonal entries eλit. For general matrices, eAt is computed using the Jordan canonical form of A or using Laplace transforms.

3.4  Semantics: Reachable states, invariants, and stability

We will discuss the semantics of an autonomous ODE [Equation (3.12)] for a given set of initial states Θ ⊆ val(x). For every x₀ ∈ Θ, Equation (3.12) defines a (possibly infinite) trajectory or solution ξ: [0, T] → val(x) such that τ(0) = x₀. Each trajectory defines the evolution of the state vector x with respect to time. A state x is reachable if there exists a trajectory ξ and t ∈ τ.dom such that ξ(t) = x. The set of all reachable states is called the reach set or reachable set and is denoted by Reach(Θ). The set of states reachable in a maximum of T time is Reach(Θ, T). An invariant S is a set that contains Reach(Θ). That is, states outside of S are not reached by any solution from Θ.

For the system defined by Equation (3.13), an equilibrium point is a state x* ∈ val(x) at which the right side of the differential equation vanishes [i.e., . Without loss of generality, we assume that x* is the origin of the coordinate system. In other words, is a fixed point of the function f. We will define stability of the system in terms of the Euclidean norm or the 2-norm.

Definition 3.5.   Consider the autonomous dynamical system described by Equation (3.12).

1. The origin is a stable equilibrium point in the sense of Lyapunov, if for every ε > 0, there is δ₁ = δ₁(ε) > 0, such that for every closed trajectory ξ,

In this case, we say that the system is Lyapunov stable, or simply stable.

2. The system is asymptotically stable if it is stable and there is δ₂ > 0 such that for any execution fragment |ξ(0)|≤ δ₂,

If the above condition for asymptotic stability holds for all δ₂, then the system is globally asymptotically stable.

3. The system is exponentially stable if there are positive constants δ₃, c, and λ such that for all closed execution fragments ξ with |ξ(0)|≤ δ₃, and for all times t,

If the above condition for exponential stability holds for all δ₃, then the system is globally exponentially stable.

For a stable system, one can bound the state in an arbitrarily small ball of radius ε by starting it from an initial state within a suitably chosen, smaller ball of radius δ₁. A stable system is also asymptotically stable if we can choose a ball of radius δ₂ such that starting from any initial state within it, the state converges to the equilibrium state as time goes to infinity. Global asymptotic stability implies convergence of executions starting from any state. For general nonlinear dynamical systems, local asymptotic stability alone does not imply stability in the sense of Lyapunov. Exponential stability means not only convergence, but convergence at an exponential rate.

It is worth noting that the constants in these definitions are quantified prior to the quantification over the executions, meaning that these notions of stability are uniform over all executions. We will explicitly use uniform stability, uniform asymptotic stability, and so on to describe uniformity with respect to the initial time of observation.

Exercise 3.5.  Show that for any Lyapunov-stable ODE and ε > 0, one can choose an initial set Θ that makes Bε(0) an invariant.

3.4.1  Example: Pendulum

The differential equation describing the motion of a simple harmonic pendulum is

where θ is the angular position with respect to the vertical passing through the pivot, is the angular velocity, l is the length of the massless rod, g is the acceleration due to gravity, and k is a friction coefficient. This is a nonlinear, time-invariant, autonomous ODE. By defining two real-valued state variables x₁ = θ and , we can describe the template model Pendulum in our language (Figure 3.3).

Figure 3.3
A pendulum.

In Pendulum, k, l, and g are constant parameters: different values of these parameters give different instances. Initial states for x₁ and x₂ are not specified in Pendulum. Figure 3.4 shows several numerical simulations of the system trajectories from different initial states with friction, k ≠ 0 (top), and without friction, k = 0 (bottom). It is easy to check that both instances have equilibria at and . (There are other equilibria at multiples of π.) The simulations suggest that is a stable equilibrium and that is unstable, and, in addition, that the former is locally asymptotically stable for instances with friction.

Figure 3.4
Trajectories of the pendulum systems with friction (top) and without friction (bottom). Both systems have a stable equilibrium point at (0, 0) and an unstable equilibrium at (π, 0). The system with friction is asymptotically stable, and without friction, it is only Lyapunov stable.

3.4.2  Example: Kinematic vehicle model

Models for ground or aerial vehicles are widely used in motion-planning algorithms to approximate a vehicle’s behavior under control. High-fidelity models, such as the ones used in commercial simulators like CarSim (Kinjawadekar et al., 2009), may have hundreds of state variables modeling engine torque, tire friction, wheel slip, chassis dynamics, and so on. These models may accurately predict the response of the vehicle, but their formal analysis may be intractable. Here, we present a basic kinematic model of a vehicle also called the bicycle model or the single-track vehicle model. Creating this type of a model from first principles would be a nontrivial exercise in an undergraduate-level mechanics course. Here, we present a swift derivation. The survey article by Paden et al. (2016) discusses several other models, as well as their relative merits, in designing motion-control algorithms for self-driving vehicles.

Our model assumes that the vehicle has two wheels connected by a rigid link, wheels do not slip, and the front wheel can be turned for steering. The key state variables are as follows: pf = (xf, yf) and pr = (xr, yr) are the positions of the front and rear wheels on the plane in a stationary coordinate system with unit vectors ex and ey. The front- and rear-wheel velocity vectors are and , and the heading angle θ is the angle between the x-axis and (pf −pr). The steering angle of the front wheel, which is a controlled input variable, is δ.

The main assumption for this model is the no slip assumption, which states that the wheels move only in the direction of the plane they reside in. To state this, first we express the velocities and in local coordinates that are aligned with the wheels. For the rear wheel,

is the rotation matrix. Next, we equate the second component of , which is the component perpendicular to the plane in which the wheel lives, to be 0. This leads to:

We denote the first component of , which is the positive or negative speed of the rear wheel along the direction pf − pr, by vr. That is, . Similarly, the no-slip condition for the front wheel in its local coordinate can be derived. The front wheel moves with a speed vf at an angle θ + δ with respect to the stationary coordinate system. The component-wise evolution for the wheel positions can be written as follows:

The ODE for θ is based on deriving the rate of rotation of the vector (pf − pr) when the steering angle is δ (see Figure 3.5). The rear- and front-wheel velocities are related as vr = vf cos(δ). The dynamics of the heading angle θ is sometimes simplified and written as , in terms of a new controlled input variable ω, with the additional constraint ω ∈ [(vr/ℓ)tan (δmin), (vr/ℓ)tan (δmax)]. Here, [δmin, δmax] is the constant range limit of the steering input (δ). The second controlled input variable, which is also range-limited, is the forward speed vr ∈ [vmin, vmax].

Figure 3.5
Kinematic (bicycle) model of a vehicle. Left: Stationary coordinates. Right: The rear-wheel no-slip condition in local coordinates rotated by θ.

In this setting, the model is sometimes referred to as the unicycle model as evolution of all the state variables can be derived by considering only the motion of a single wheel. Figure 3.6 shows this kinematic model explicitly written out in our language. Note that we cannot yet simulate this model without specifying the behavior of the control input variables vr and δ. Figure 3.7 shows a typical trajectory of the Vehicle following a path using the inputs generated by the controller described in Exercise 3.7.

Figure 3.6
Specification of the open-loop kinematic vehicle model.

Figure 3.7
Path following the trajectory of kinematic Vehicle model.

3.5  Lyapunov’s direct method for proving stability

Proving stability can be challenging. Numerical simulations cannot cover all possible initial conditions, cannot be extended to infinite time, and are prone to accumulation of errors. Lyapunov’s direct method bypasses explicit computation of trajectories altogether! It gives a sufficient condition for proving stability in terms of a special type of function called a Lyapunov function. These sufficient conditions can be checked by computing derivatives of the candidate Lyapunov function.

Theorem 3.3 (Lyapunov stability).   Consider the system of Equation (3.7) with state space val(x), and suppose there exists a positive definite, continuous function V: val(X) ℝ. The system works as follows:

1. Lyapunov stable if

2. Asymptotically stable if, for all x ≠ 0,

It is globally asymptotically stable if V is also radially unbounded.

The function V is called a Lyapunov function of Equation (3.7) if it satisfies the strict inequality. Otherwise, it is called a weak Lyapunov function. For general nonlinear models, finding a Lyapunov function can be difficult, but for LTI systems, one can find them by solving an optimization problem (see Theorem 3.5).

3.5.1  Stability of linear dynamical systems

For an autonomous LTI system

we can check stability or instability by computing certain characteristic properties of the matrix A without actually computing the trajectories of the system or finding a Lyapunov function. Theorem 3.4 is well known, and it characterizes stability of an LTI in terms of the eigenvalues and the Jordan decomposition of the matrix A. A brief overview of these concepts is given in Appendix A.

Theorem 3.4.   The system described by Equation (3.22) is as follows:

1. Lyapunov stable iff all the eigenvalues of A have real parts that are either zero or negative and the Jordan blocks corresponding to the eigenvalues with zero real parts are of size 1.

2. Asymptotically stable iff all the eigenvalues of A have strictly negative real parts. Such a matrix is called Hurwitz.

3. Unstable iff at least one eigenvalue of A has a positive real part or zero real part, but the size of the corresponding Jordan block is larger than 1.

The second condition in Theorem 3.4 implies that ξ(t) = eAt converges to zero exponentially fast, and it follows that asymptotic and exponential stability are equivalent for LTI systems.

We can apply Lyapunov’s method to LTI systems as well, and in this case, we can compute a Lyapunov function by solving a special type of an optimization problem called a semidefinite program.

Theorem 3.5.   The system [Equation (3.22)] is asymptotically stable iff for every positive definite matrix Q, there exists a unique symmetric positive definite matrix P that solves the Lyapunov equation:

To apply this theorem, we choose a positive definite Q, such as the identity matrix, and solve for P. If a positive definite P is then found, the quadratic Lyapunov function derived is V(x) xT Px. We can see that , which can be written as xT(ATP + PA)x = −xQx. Since Q is positive definite, V satisfies Equation (3.21).

In summary, Lyapunov’s method for proving stability of ODEs does not require explicit solutions, but it does require one to find a Lyapunov function. In general, for nonlinear systems, it may not be easy to find such a function, but for linear systems, we can use Theorem 3.5. Does a stable system necessarily always have a Lyapunov function? That is, does the converse of Theorem 3.4 also hold? Indeed, under some additional assumptions, such converse Lyapunov theorems do hold. In particular, stable linear systems always have a quadratic Lyapunov function.

3.6  Differential equations as automata

In this section, we relate ODEs to the automata models of Chapter 2. By choosing a sampling time δ > 0, we can construct an automaton 𝒜(δ) (see Definition 2.1 in Chapter 2) whose every transition models an advance of time by δ amount in the ODE model. Consider, for example, an automaton 𝒜(δ) = (V, Θ, A, 𝒟) that corresponds to the system in Equation (3.13). Because x ∈ ℝn, we can define V = {x} with type(x) = ℝn. An alternative choice would be to define V′ = {x₁, …, xn}, with type(xi) = ℝ for each i ∈{1, …, n}. The state space val(V) is the set of all possible valuations of x, which is isomorphic to ℝn. A set of initial states Θ could be defined as a predicate on x. The set of action names is immaterial here; we choose A = {a}. Finally, we define the set 𝒟 of transitions as iff there is a solution ξ: [0, δ] val(V) of Equation (3.13) from x to x′, that is, that ξ(0) = x and ξ(δ) = x′. This sampled time model is akin to the automaton model described in Section 2.3.3 of Chapter 2. Instead of working with a sampled version of the solutions of an ODE, one often finds it convenient to work with discrete-time dynamical systems described in terms of difference equations that take the general form

For an in-depth treatment of verification (and synthesis) for discrete-time models, see Belta et al. (2017).

3.7  Example: Simple economy

A simple linear model of a country’s economy is given by

where x is the national income; y is the rate of consumer spending; g is the rate of government expenditure, which is related to the national income by the algebraic rule g = g₀ + kx; and α, β, and k are positive constants (α, β > 1). If we set the right side to zero, we find that the valuation x* with is an equilibrium point of the system. Note that the income-independent part of the government expenditure g₀ influences the equilibrium. If we shift the coordinates to x*, then the dynamics in the new coordinate system is expressed in the following LTI model:

For α = 3, β = 1, and k = 0, the eigenvalues of matrix A are (−0.25 + i1.714) and (−0.25 −i1.714), and because the real parts of both are negative, by Theorem 3.4, it follows that the system is asymptotically stable and that the national income and consumer spending stabilize to x*⌈ x = 1.764 and to x*⌈ y = 5.294, respectively. By choosing a positive definite matrix Q, such as , we can solve the Lyapunov equation [Equation (3.23)] to obtain . By Theorem 3.5, the resulting Lyapunov function is the quadratic function V(x) = (x − x*)P(x − x*)T, and this function decays along all trajectories of Equation (3.25). Figure 3.8 shows (on the right side) how the valuation of the Lyapunov function decays over time, and the left side shows some of its sublevel sets. It can be shown that any sublevel set containing the initial set of the system is an invariant (see Exercise 3.10 at the end of this chapter).

Figure 3.8
Trajectories of the simple economy model. Left: Phase portrait for the model of Equation (3.24) for α = 3, β = 1.5, k =.1, and g₀ = 3. The sublevel sets of the Lyapunov function are shown in dotted lines. Right: Evolution of the solutions over time.

3.8  Numerical simulations for ordinary differential equations

In general, finding or computing exact solutions to nonlinear differential equations is difficult. Numerical ODE solvers provide numerical approximations of solutions from particular initial states and for a bounded time (Nedialkov, 2006; CAPD Group, 2016). In fact, there are two types of numerical simulation problems. Initial value problems are what was just described: given an initial state x₀, we have to compute the valuations of state variables along a trajectory ξ(t) at a finite discrete sequence of time points (e.g., t = 0, δ, 2δ, …, nδ). In general, the time points need not be evenly spaced. In a boundary value problem, the boundary conditions on ξ are specified at more than one point. In what follows, we discuss approaches for solving the initial value problem for ODEs.

A numerical solution or simulation is a finite sequence of state-time pairs (x₀, t₀), (x₁, t₁), …(xn, tn), such that for each pair (xi, ti), the error |xi − ξ(ti)| between the actual trajectory ξ starting from x₀ at ti and the numerically computed state xi is small. An alternative set-valued definition of numerical solutions is covered in Section 11.1 in Chapter 11.

For computing numerical solutions, the basic idea is to convert the differential equation to an algebraic update rule for the dependent variables for finite changes in the independent variable t. Consider the autonomous differential equation [Equation (3.12)]. If we designate the step size of the independent variable (time) to be h > 0, then a simple update rule starting from the initial state x₀ is the Euler method:

Obviously, that is inaccurate, as it updates the state by advancing time by h units but uses the stale derivative value only from the beginning of the interval. If we instead use the derivative value from the midpoint of the interval, then the resulting symmetrization cancels the first-order error term and gives a second-order Runge-Kutta method, which is also called the midpoint method:

It can be shown by power series expansion that the error |xk −ξ(tk)| introduced in each step is O(h³). This method uses one additional intermediate evaluation of the right side between tk and tk+1. Going further in that direction, we arrive at the commonly used, fourth-order Runge-Kutta method:

This method requires four evaluations of the right side, and the error in each step is O(h⁵). The fourth-order method is usually more accurate than the midpoint method, but higher order generally does not necessarily imply higher accuracy. For faster and more accurate algorithms for generating simulations of differential equations, some of which use variable or adaptive step sizes, we refer the reader to the book by Press et al. (1992).

Consider a nonlinear ODE model of a tabletop helicopter system:

which describes the dynamic relationship between the pitch angle (θ) and the input rotor thrust (u). Here, Ω is a constant: the moment of inertia of the helicopter. Numerical solutions of the system with various methods are shown in Figure 3.9.

Figure 3.9
Simulated trajectories for the helicopter system of Equation (3.28). Here, the midpoint method and the fourth-order Runge–Kutta method give almost indistinguishable simulated points, while the results from the Euler method differ significantly.

3.9  Closing the loop and control synthesis

The semantics of open ODEs or open-loop systems with inputs, as in Equation (3.7), is defined in the same way as for autonomous (or closed) systems (see Section 3.4). From Theorem 3.1, we know that for any initial state x₀ ∈ Θ and any piecewise continuous input trajectory η, Equation (3.7) has a unique state trajectory or solution. Let ξx₀, η: [0, T] → val(x) denote that solution. The set of all such trajectories, from all initial states and with all possible inputs, defines the set of possible open-loop behaviors of the system. A state x is reachable if there is initial state x₀, input η, and time t, such that ξx₀, η(t) = x. Open-loop reachable sets and bounded reachable sets are defined in an analogous fashion.

Given an open-loop system or a plant, a natural problem is to design a controller for closing the loop such that the resulting closed-loop control system meets the desired requirements. Figure 3.10 shows the archetype of a closed-loop system. The plant dynamics follows Equation (3.7), but with an additional disturbance input d(t). In general, the plant state x(t) is not available to the controller; instead, an observation y(t) = h(x(t)) of the state is. Here, h(·) is the observation function that models the mapping from actual states to sensed outputs, possibly including quantization and other effects. The desired output yd(t) is called the set point, and the actual input to the controller is the error between y(t) and yd(t). Finally, g(·) is the controller function that decides the input u(t) to the plant based on the current observation y(t) or the current error e(t).

Figure 3.10
A closed-loop control system.

Controller design encompasses various approaches for constructing the controller function g(·) such that all resulting trajectories of the closed-loop system meet the desired design requirements. Requirements could be formally stated in terms of stability, invariants, performance relative to disturbances, minimization of certain gains, and other properties of the trajectories. We will discuss requirements in more detail in Chapter 6. In the next section, we discuss the proportional-integral-derivative (PID) controller, which is one of the predominant types of controllers used in the industry.

3.9.1  Proportional-integral-derivative controller

The PID controller is by far the industry’s most common way of designing a practical controller. According to a survey of over 11,000 controllers in the refining, chemical, and pulp and paper industries, 97 percent of controllers utilize PID. The form of the PID control function is

where KP, KI, and KD are the proportional (P), integral (I), and differential (D) gains for the controller. Roughly speaking, KPe(t) is proportional to the magnitude of the error, and by itself may not be able to eliminate steady-state error in the face of disturbances. The integral term is proportional to both the magnitude and the duration of the error and eliminates steady-state errors. However, as this term responds to accumulated errors from the past, it can cause the system to overshoot the set point value. predicts the error change and improves the settling time and stability. Tuning the gain terms KP, KI, and KD involves trading off various performance criteria of the control system.

As a simple illustration, consider a plant with single-integrator dynamics:

that is, d(t) is an unknown disturbance and u(t) is the control input. Using the proportional control u(t) = −KPe(t) = −KP(y(t) − yd(t)), the closed-loop-system equation becomes

The negative proportional gain ( − KP) ensures that the output y(t) is stable. Assuming the steady-state disturbance value of dss and a constant set point ydss, the steady-state output is and the steady-state error is . The transient solution is

where the time constant T = 1/KP. Thus, to make the steady-state error small, we can increase the proportional gain KP at the expense of longer settling times and higher risk of instability.

We refer interested readers to Ogata (2009) and Astrom and Murray (2008) for detailed discussions of PID gain tuning methods such as the Ziegler-Nichols method, the relay method, and the Cohen-Coon method.

3.9.2  Controller synthesis problem

Beyond PID controllers, there are many other approaches for designing controllers, and this is an active area of research both within control theory and in computer science.

Definition 3.6.   Given the dynamical system of Equation (3.7) and a set of requirements R, the control design or controller synthesis problem is that of computing inputs η (if possible) such that every trajectory meets the requirement R. If no such controller exists, then this fact should be established.

There are several connections between the synthesis problem and verification problem. First, if the number of possible controllers is finite, then each of these finitely many possibilities can be verified against the requirement until we either find a satisfying controller or establish that none of the controllers meets the requirement. Second, the requirements are a common input to both problems. We will see in Chapter 6 that many types of requirements beyond stability and invariance can be specified (e.g., using temporal logics) for both verification and synthesis. The broad categories of synthesis approaches for temporal logic specification are outlined in Section 6.6.2 in Chapter 6. Finally, many verification and synthesis algorithms utilize common concepts that we will encounter in this book, such as discrete abstractions, Lyapunov analysis, and satisfiability modulo theory encodings.

Summary and outlook   We have seen how physical processes can be mathematically modeled using ODEs. We added a new feature to the language of Chapter 2 to include ODEs. We defined the semantics of ODEs in terms of solutions and discussed sufficient conditions for their existence and uniqueness. We also discussed reachable states, stability, their relationship, and Lyapunov’s method for proving stability. In the next chapter, we will unify the concepts from Chapter 2 and this chapter and see cyber-physical systems mathematically modeled using automata and differential equations.

3.10  Exercises

Exercise 3.6.  Consider the kinematic car model Vehicle described in Section 3.4.2 and fix the rear-wheel speed at a constant vr > 0. Design a controller function that takes as input the current state x of the Vehicle automaton and a target heading direction θ* and produces as output the steering ω, so that the vehicle eventually heads in the direction θ*. Write a program implementing this closed-loop system. (Hint: Use a proportional controller.)

Exercise 3.7.  Define and simulate a waypoint-following controller for the Vehicle automaton. Given a target state x* and gain constants k₁, k₂, k₃ > 0, define the control inputs at state x as follows:

where the “error” vector [xe ye θe] at state x relative to the target state x* is defined as:

Complete the code in Figure 3.6 to create a model of a controlled vehicle. Write a program implementing this closed-loop system.

Exercise 3.8.  Give an example of an unstable linear time-varying dynamical system , such that for every t ≥ 0, A(t) is Hurwitz (i.e., each eigenvalue has negative real parts).

Exercise 3.9.  For a linear autonomous system , show that if the set of initial states is convex, then the set of reachable states at any time t > 0 is also convex. If the set of initial set Θ is a bounded polyhedron, then Reach(Θ, t) is the convex hull of the points reached from the vertices of Θ.

Exercise 3.10.  Consider an autonomous dynamical system , with an initial set Θ ⊆ val(x) and a Lyapunov function V: val(x) ℝ. Show that any sublevel set of V containing Θ is an invariant of the system.

Exercise 3.11.  Consider the Vehicle model with the controller defined in Exercise 3.7. Show that the following is a Lyapunov function for the closed-loop system:

4

Modeling Cyber-Physical Systems

Overview

The mathematics for describing computation and for describing physics evolved largely in isolation in the latter half of the twentieth century. That was probably clear from the previous chapters: automata look nothing like ordinary differential equations (ODEs). On the other hand, from the early days of computer-based guidance and navigation for missiles and spacecraft, computation has played an increasingly important role in sensing, planning, controlling, and monitoring of the physical processes that are central to modern transportation, infrastructure, medical, and manufacturing systems. In this chapter, we will unify the automata of Chapter 2 and the ODEs of Chapter 3 and introduce models for cyber-physical systems. The result is the hybrid automaton (HA) modeling framework. The state of an HA can change both through instantaneous transitions and over time intervals, through trajectories. Strange behavior and seemingly paradoxical behavior patterns can emerge when these two types of evolution are brought together. For example, it is possible for an HA to perform infinitely many transitions in finite time; and it is possible for an HA to become unstable even though its constituent ODEs are stable. In this chapter, we will introduce those hazards and present several examples of hybrid models.

4.1  Quick introduction to hybrid automata

4.1.1  Example: Rimless wheel

Consider a rimless wheel rolling down a slope such that the motion is punctuated by the impacts of the spokes (see Figure 4.1). During every impact, mechanical energy gets transferred from the impacting spoke to the incline surface and back to the spoke in such a way that after the impact, the wheel is rotating around the point of the impact. In between the impacts, the spoke in contact with the surface rotates like an inverted pendulum, and the rest of the wheel rotates with it. This is a starting point for understanding the impactful motion of what are called compass-gait walkers and more complicated bipedal robots (Byl and Tedrake, 2009).

Figure 4.1
Motion of a rimless wheel down an inclined plane. Swinging around (left) and impact ( right).

In modeling the rimless walker, we will actually capture the state of just one spoke that is in contact with the surface. This completely defines the state of the system. Specifically, pivot is the spoke number currently in contact; θ is the angular position of the pivot spoke relative to the normal at the point of contact; and ω is its angular speed. The moment when the impact happens—that is, the next spoke lands on the incline (Figure 4.1, right)—the next spoke becomes the pivot. The energy transfer during the impact happens much faster than the rotation of the wheel and the time between successive impacts. Therefore, we choose to model the impacts with instantaneous discrete transitions and the evolution of pivot between impacts with ODEs.

4.1.2  Language for specifying hybrid systems

We will extend the language of Chapter 2 to describe hybrid systems. The RimlessWheel automaton model of Figure 4.2 describes the rimless wheel. The RimlessWheel automaton has three parameters: (1) α is the slope of the inclined surface; (2) n is the number of spokes in the wheel; and (3) μ is a coefficient of restitution for the loss of angular speed with impact. The constant β is defined for convenience as the interspoke angle. We assume that n ≥ 6, and it follows that β ≤ π/3. We define a new type called Spokes as the set of integers {1, …, n} that will be used to record the identity of pivot. The main body of the automaton specification has four sections—namely, actions, variables, transitions (as in Chapter 2), and a new section called trajectories.

Figure 4.2
HA model of RimlessWheel.

The actions section lists the actions of the automaton (only impact, in this case). The automaton has three variables declared in the variables section: pivot is the identity of the pivoting spoke, θ is the angle of the pivot spoke with the normal, and ω is the angular speed of the wheel. The variables are initialized to the constants 1, 0, and 0, respectively. Valuations of these three variables define the states of RimlessWheel.

The state of RimlessWheel can change in two ways: either instantaneously during an impact or continuously over an interval of time between impacts. The first type is specified in the transitions section, and the second type in the trajectories section. The transitions section lists the preconditions and the effects of each of the actions. The precondition of impact specifies that an impact action may occur in states where the angle θ exceeds . The effect specifies that when this action does occur, then pivot is incremented by 1 modulo n, θ is reset to , and ω is decremented by a factor of μ. These assignments define the poststate of an impact transition.

The trajectories section lists a set of modes, each of which specifies the valid trajectories for the variables of RimlessWheel (namely, θ, ω, and pivot). Each mode definition starts with the name of the mode, the evolve keyword followed by a set of algebraic or differential equations, and, optionally, a mode invariant. RimlessWheel has a single mode, swing, which specifies the motion of the pivot spoke between impacts. The ODEs are written in the same way as in Chapter 3: the time-derivative of a continuous variable x is written as d(x), and the variables not mentioned are assumed to remain constant over the trajectories. The mode invariant specified after the keyword invariant is a predicate involving the state variables. A trajectory τ: [0, T] val({θ, ω, pivot}) is a valid trajectory if it is a solution of the specified ODE, and every state τ(t), for each t ∈ τ.dom, satisfies the mode invariant.

Why do we need mode invariants? If we dropped the mode invariant θ ≤ β/2, then nothing would prevent θ from growing beyond β/2, and the pivot + 1 spoke from piercing the incline. In all trajectories of RimlessWheel, ω is increased at the rate sin(θ + α), which is positive for small slope angles. The invariant θ ≤ β/2 ensures that at any point in time, θ can be at most β/2. If θ becomes equal to β/2, then that state also satisfies the precondition of impact. Because time cannot advance any further any trajectory of swing without violating the invariant, the only way that RimlessWheel can evolve beyond this point is through the occurrence of an impact transition. This style of matching invariants and preconditions is a common modeling idiom. In this case, the invariant forces the impact transition to occur as soon as it becomes enabled. These types of transitions are called urgent transitions.

4.2  Specifying hybrid automata

The mathematical object that we will use to model cyber-physical systems is a hybrid automaton (HA). The state of an HA is defined by a set of variables, and changes in their valuations are described by transitions and trajectories. Thus, an HA unites the transitions of an automaton (Chapter 2) with the trajectories defined by an ODE (Chapter 3).

4.2.1  State variables and transitions

Variables of HA are similar to the variables in Chapters 2 and 3. For a set of variables V, each v ∈ V is associated with a type denoted by type(v). A valuation v of V maps each v ∈ V to a value in type(v). The set of all valuations val(V) is the state space of the model.

Once the values of the parameters α, μ, and n are fixed to constant values, the HA RimlessWheel(α, μ, n) defines a set of variables VRimlessWheel = {θ, ω, pivot}, with type(θ) = type(ω) = ℝ and type(pivot) = [n]. The set val(VRimlessWheel) is isomorphic to ℝ² × [n], and the initial state is the valuation v = (θ 0, ω 0, pivot 1). As before, restrictions of valuations to particular variables or sets of variables are denoted by ⌈ (i.e., v ⌈ θ = 0).

Predicates on variables and transition relations are defined in the same way as discussed in Section 2.2.3 of Chapter 2. In particular, for any v, v′∈ val(VRimlessWheel), (v, impact, v′) is a valid transition if and only if

Let V be a set of variables with X ⊆ V as the real-valued subset. For any valuation v of V, we use ||v|| to denote the Euclidean norm ||v ⌈ X|| of v restricted to X. For any δ > 0 and v ∈ val(V), the closed δ-ball around v is the set Bδ(v) {v′∈ val(V) | ||(v ⌈ X) − (v′⌈ X)||≤ δ}.

4.2.2  Trajectories and closures

Trajectories define how the valuations of variables change over time. Variables that remain constant along trajectories are called discrete variables; all other variables are continuous variables. In RimlessWheel, pivot is a discrete variable, as it changes only when an impact occurs and remains constant otherwise; θ and ω are continuous variables.

Trajectories of HA are specified by algebraic equations and ODEs, as discussed in Chapter 3. A (closed) trajectory for a set of variables V is a function τ: [0, T] → val(V). An open trajectory τ: [0, T) → val(V) maps an open interval to valuations. An infinite trajectory is an open trajectory that maps [0, ∞) to val(V). The domain of τ is denoted by τ.dom. The first state of a trajectory τ.fstate = τ(0). If the τ is finite, then its limit time is denoted by τ.ltime sup(τ.dom). If τ is closed, then its last state is τ.lstate τ(τ.ltime). If T = 0, then τ is a point trajectory that maps the point [0, 0] to val(V). For any variable v ∈ V and a trajectory τ of V, the component of τ restricted to v is the function (τ ↓ v): [0, T] → val(v), defined as follows: for each t ∈ τ.dom, (τ ↓ v)(t) = τ(t) ⌈ v.

A trajectory τ: [0, T] → val(VRimlessWheel) is a valid trajectory of RimlessWheel if and only if it is a solution of the differential equation that follows the evolve keyword, and at every time point, it satisfies the mode invariant. That is, at any time s in the interval [0, T], the following conditions hold:

Equations (4.2) and (4.3) correspond to the constraint that the trajectories of the continuous variables θ and ω are solutions of the nonlinear autonomous differential equations in lines 22–23 of Figure 4.2. Compare this definition with the definition of what it means for a function τ to be a solution of the general differential equation given in Equation (3.9). Equation (4.4) asserts that the discrete variable pivot remains constant over τ. Finally, Equation (4.5) asserts that the invariant for the mode swing must be satisfied at every point in time over the trajectory.

Now we will define several useful operations on trajectories. Given a trajectory τ: [0, T] → val(V) for a set of variables V and a time t > 0, the time shift τ + t is the function obtained by shifting τ by t. That is, (τ + t): [t, t + T] → val(V) is defined as ∀ s ∈ [t, t + T], (τ + t)(s) = τ(s − t). Strictly speaking, for t > 0, τ + t is not a trajectory.

The t-prefix of a trajectory τ, with t ∈ τ.dom, is a shorter trajectory τ′ that is identical to τ up to t. That is, τ′.dom = [0, t] and ∀ s ∈ τ′.dom, τ′(s) = τ(s). The t-suffix of a trajectory τ, with t ∈ τ.dom, is a shorter trajectory τ′ that is identical to τ from t onward, and is shifted to start from 0. That is, τ′ (τ ⌈ [t, τ.ltime]) − t. Finally, we define the concatenation of two trajectories τ₁ ⌢ τ₂ (τ₁ has to be closed) as the new trajectory τ, in which τ₁ is followed by τ₂. That is, (τ₁ ⌢ τ₂).dom = τ₁.dom ∪ (τ₂ + τ₁.ltime).dom, and for each t ∈ (τ₁ ⌢ τ₂).dom,

A set of trajectories 𝒯 is closed under the prefix if for every τ ∈ 𝒯, any prefix τ′ of τ is also in 𝒯. Closure under the suffix is defined similarly. 𝒯 is closed under concatenation for any τ₁, τ₂ ∈ 𝒯 with τ₁.lstate = τ₂.fstate, τ₁ ⌢ τ₂ ∈ 𝒯.

Exercise 4.1.   Check that the set of trajectories 𝒯RimlessWheel defined here for RimlessWheel is closed under the prefix, suffix, and concatenation.

Exercise 4.2.   Show that the set of trajectories 𝒯 defined by any nonlinear autonomous ODE system is closed under the prefix, suffix, and concatenation.

4.2.3  Hybrid automata

Now we are ready to define an HA.

Definition 4.1.   An HA 𝒜 is a tuple (V, Θ, A, 𝒟, 𝒯 ) where

1. V is a set of variables called the state variables. The set val(V) of valuations of V is the set of states.

2. Θ ⊆ val(V) is a nonempty set of start states.

3. A is a set of actions or transition labels.

4. 𝒟⊆ val(V) × A × val(V ) is called the set of transitions.

5. 𝒯 is a set of trajectories for the variables in V that is closed under the prefix, suffix, and concatenation.

We have purposefully made this definition short and minimally restrictive. For instance, it does not stipulate that the set of trajectories 𝒯 is specified by ODEs. As in RimlessWheel, though, indeed 𝒯 typically will be defined by ODEs.

As in the case of discrete automata (see Definition 2.1 in Chapter 2), the set of initial states Θ is specified by initializing the state variables or by writing a predicate on V. The actions are useful for labeling the transitions. A transition (v, a, v′) ∈ 𝒟 is written in short as or as when 𝒜 is clear from the context. For RimlessWheel, if and only if v and v′ satisfy Equation (4.1). If , we say that action a is enabled at the state v. The set of states at which a is enabled is denoted by enabled(a). That is also the set of states that satisfy the preconditions of the action a in the specification. The set of trajectories 𝒯 is defined by Equations (4.2)–(4.5), as discussed in Section 4.2.2. Notice that continuous variables like θ and ω may change values because of discrete transitions.

When we have to talk about multiple automata in the same context, then we will refer to the components of HA 𝒜 by V𝒜, Θ𝒜, A𝒜, 𝒟𝒜, and 𝒯𝒜, and similarly, the components of HA 𝒜i by Vi, Θi, and so on.

4.2.4  A guide for hybrid modeling

Creating a model of a cyber-physical system involves some choices: Which quantities to include in the model and which to ignore? What variable types to use? Which changes can be considered fast and be modeled as instantaneous transitions (instead of trajectories)? Should the system be represented as a single automaton or a composition of pieces? There is no one-size-fits-all resolution of these choices. Instead, here we give a road map for navigating them.

1. Identify the automaton components for the system (Chapter 5 discusses composition).

2. For each component, identify the state variables, types, and dependencies.

3. Decide which variable changes are to be modeled as transitions (fast) and which as trajectories (slow).

4. Identify the modes for the trajectories and write down the corresponding differential equations. Write the evolve clause and any necessary mode invariant for each mode.

5. Identify and write the actions that bring about transitions between modes and discrete variable updates.

6. Write the preconditions and effects defining the discrete transitions.

7. For each mode, add mode invariant and stop when condition to ensure that the trajectories and transitions interact properly.

4.3  Special classes of hybrid automata

4.3.1  Deterministic hybrid automata

A deterministic hybrid automaton is an HA 𝒜 for which Θ is a singleton set and for every state v ∈ val(V), at most one of the following is possible: (1) there is an action a ∈ A and a state v′∈ val(V) such that , or (2) there is a single trajectory τ ∈ 𝒯 of nonzero duration with τ.fstate = v. Therefore, in a deterministic hybrid automaton, all transitions are necessarily urgent. RimlessWheel is deterministic. An HA that is not deterministic is called a nondeterministic hybrid automaton. For a nondeterministic hybrid automaton at a given state, there may be multiple enabled actions, multiple poststates for the same action, and multiple trajectories of nonzero duration. In particular, it is possible to ignore an enabled action and allow time to elapse. For example, if we drop the model invariant θ ≤ β/2 in RimlessWheel, then enabled impact transitions may be ignored.

4.3.2  Switched systems

The switched system modeling framework is an alternative formalism for describing cyber-physical systems (Liberzon, 2003b). It generalizes ODEs by allowing the system to be described by a set of ODEs—one for each mode—and a piecewise constant switching signal that defines the operating mode. The mathematical specification of an n-dimensional switched system consists of a finite number p ∈ ℕ of modes, a set of n-dimensional ODEs:

and a piecewise constant switching signal σ: ℝ≥0 → [p]. The notation denotes the derivative of x with respect to time (see Section 3.1.2). The points of discontinuity in σ are called the switching times. The evolution of the overall system is given by the following time-varying ODE:

See Liberzon (2003b) for an exposition of the switched-system modeling framework, which includes a discussion of the existence of solutions.

A switched-system model can be seen as an HA in which the switching signal defines the transitions. Figure 4.3 specifies a generic switched system. The parameter p is the number of modes; for each i ∈ [p], the function f(i, ·) defines the right side of the ODE of mode i; and σ is a (possibly infinite) sequence of pairs that defines the switching times. That is, σ(i) = (t, j) implies that the ith switch must occur at time t and the signal switches to mode j. The SwitchedSys model has a single parameterize action switch(j), which models a transition to mode j. It has four variables: x is the n-dimensional, real-valued state vector, loc is the mode, now is a timer, and index counts the number of mode switches. Suppose that the kth pair in the σ sequence is (t, j). Then switch(j) can be performed when now = t, and as a result of this switch, loc is set to j and index is incremented. The trajectories of x are defined by Equation (4.6) when loc = i. That is, the state x evolves according to the differential equation and the timer now grows at a rate of 1 per unit time, which is the same as real-time. Finally, the mode invariant prevents now from going beyond the next switching time, thereby ensuring that the next switch indeed occurs whenever it is enabled.

Figure 4.3
HA specification of a generic switched system.

4.3.3  Linear hybrid automata

Without loss of generality, we restrict the discrete state of the HA to a single discrete variable. A simple hybrid automaton is an HA with a single discrete variable that has a countable type and a set of real-valued, continuous variables.

Definition 4.2.   A simple hybrid automaton 𝒜 is an HA ⟨V, Θ, A, 𝒟, 𝒯⟩ where V = loc ∪ X, loc is a single discrete variable type(loc) = L, and for each x ∈ X, type(x) = ℝ. The elements of L are called locations (also known as modes or control states). A transition is called a mode switch if the discrete variable loc changes value (i.e., v ⌈ loc ≠ v′⌈ loc).

A linear hybrid automaton is a simple hybrid automaton in which (1) all the trajectories are solutions of linear differential equations over V [see Equation (3.15)]; (2) all the preconditions and the set of initial states are linear predicates over V; and (3) all the effects are linear functions of V. RimlessWheel in Figure 4.2 is a nonlinear hybrid automaton, although the initial set, the precondition, the effect, and the mode invariant are all linear. Linear hybrid automata models are important because they can be used to approximate a rich class of realistic systems, and they are amenable to algorithmic analysis, as they inherit some of the nice properties of linear ODEs (see, e.g., Theorem 3.2 in Chapter 3) and the theory of linear real arithmetic.

4.3.4  Example: Thermostat

Figure 4.4 shows a linear hybrid automaton model of a simple thermostat-heater system for a house. The automaton has two actions, turnOn and turnOff, which correspond to turning the heater on and off; and two variables, temperature (x) and the heater status (loc). When the heater is off (loc = off ), the temperature drop is modeled by a linear ODE , where K is a heat-loss coefficient of the house. When the heater is on (loc = on), the temperature rise is modeled by the linear ODE , where h is a constant related to the thermal output of the furnace. The turnOn action is enabled when x falls to l, and turnOff is enabled when x reaches u. In Thermostat, the intersection of the invariant loc = on ∧ x ≤ u for modeOn and the guard for turnOff is a singleton point loc = off , x = u, which ensures that turnOff indeed occurs as soon as it is enabled. The same reasoning applies to turnOn. Therefore, Thermostat is deterministic. If the invariant is relaxed to loc = on ∧ x ≤ u + c for some c > 0, then turnOff could be deferred in an execution until x = u + c, and the automaton would thus be nondeterministic.

Figure 4.4
Thermostat-heater system.

HA with only a handful of locations, such as the Thermostat, can be quickly communicated via a graphical representation, as shown in Figure 4.5. Each location (mode) is represented as a vertex, and the edges show the possible mode switches. The vertices are labeled with the corresponding differential equations and mode invariants, and the edges are labeled with the guards and resets.

Figure 4.5
Graphical representation of the Thermostat HA.

4.3.5  Rectangular hybrid automata

A rectangular subset or a rectangle in ℝn is a Cartesian product of (possibly open) intervals. A rectangular inclusion for a real-valued variable x is specified as

where the constants lm, um ∈ ℝ ∪{−∞, ∞}. A trajectory τ: [0, T] → val(x) satisfies the differential inclusion [Equation (4.8)] if and only if at every point in time t ∈ τ.dom, d((τ ↓ x)(t)) ∈ [lm, um]. A rectangular hybrid automaton (RHA) is a simple hybrid automaton in which (1) the evolution of each continuous variable x in each mode m is specified by differential inclusions; (2) the preconditions and the set of initial states are rectangles; and (3) the effects are either identity maps or assignments to rectangles. RHAs can approximate physical quantities that grow or shrink monotonically with time, such as accumulation of fluids under constant flow, motion under constant speed, and clocks with bounded drift.

4.3.6  Timed automata

A timed automaton is an RHA in which all the continuous variables are stopwatches. That is, the evolution of each continuous variable x in each mode m is either

all the preconditions and the set of initial states are rectangles with rational end points; and all the effects either reset the variables to 0 or leave them unaltered. Timed automaton models can capture real-time protocols that use timing.

4.4  Semantics: Hybrid executions

An execution fragment of an HA 𝒜 describes a particular behavior or a run. Formally, an execution fragment is an alternating, possibly infinite sequence of actions and trajectories α = τ₀a₁τ₁a₂…, where each τi is a trajectory in 𝒯𝒜; and if τi is not the last trajectory in the sequence, then . The trajectories capture the continuous change in the variable values over intervals of time, and the transitions capture the instantaneous changes in the state. An execution fragment is an execution if it starts from one of the start states in Θ (i.e., τ₀.fstate ∈ Θ𝒜). The set of all execution fragments and the set of all executions from Θ are denoted by Frags𝒜 and Execs𝒜(Θ), respectively. The first state of an execution fragment α is α.fstate τ₀.fstate.

An execution fragment is finite if it is a finite sequence; otherwise, it is infinite. An execution fragment is closed if it is finite and the last trajectory τn is right-closed. The last state of a closed execution α = τ₀a₁τ₁a₂…τn, α.lstate τn.lstate. Closed executions end at a finite time and after a finite number of discrete transitions, so we can define the limit time or the duration of such an execution fragment as .

Definition 4.3.   A state v ∈ val(V) is reachable if it is the last state of some execution of 𝒜. The set of all states reachable from Θ is denoted by Reach𝒜(Θ), or by Reach𝒜 when the initial set is clear from context. The set of states reachable from Θ in a maximum of k steps and in a maximum of T time is denoted by Reach𝒜(Θ, T, k). An invariant S of 𝒜 is a set of states that contains Reach𝒜.

4.4.1  Numerical simulation of hybrid executions

We can compute hybrid simulations or numerical simulations of executions of an HA 𝒜 up to a given time bound T > 0, through the following procedure:

1. Pick a sampling period δ > 0 and an initial state v₀ ∈ Θ. Suppose that the mode corresponding to v₀ is ℓ₀.

2. Compute the numerical solution of the trajectory τ₀: [0, δ] → val(V) starting from v₀ by solving the ODE that corresponds to ℓ₀ (as described in Section 3.8 in Chapter 3).

3. If at any time t, (t) satisfies the mode invariant, then we move to step 4; otherwise, we decrement δ and find a prefix of τ that completely satisfies the mode invariant.

4. If, at any time t, (t) satisfies the precondition (guard) for some action a ∈ A, then there is a possible transition at t. Choose a new state v from the (possibly singleton) set of states obtained by applying the reset function of a to (t).

5. Repeat steps 2 to 4 with v taking the place of v₀, until the total simulation time exceeds T.

Figure 4.6 shows the graph of an execution fragment of RimlessWheel with six spokes (n = 6). The unbroken lines show the change in the angle (θ) of the pivoting spoke and its angular speed (ω), and the dashed lines show the instantaneous change in state brought about by the impact transitions.

Figure 4.6
An execution of RimlessWheel with six spokes. The discrete transitions punctuate the continuously evolving trajectories, bringing about instantaneous changes in the angular position θ and the angular speed ω.

In general, generation of hybrid simulations can be tricky. As discussed in Section 3.8, generation of a precise approximation of τ can be challenging. Independent of the precision of the approximation, it is generally hard to perform the checks in steps 3 and 4. In a situation where the trajectory τ is almost tangential to a hyperplane I that defines the mode invariant (or the guard), it may be impossible to tell whether τ touches I. Consequently, there may be both false positives and false negatives in the detection of mode switches. This is called the mode switch detection problem. Moreover, it may be impossible to distinguish a trajectory that is tangential to a guard G at a single point from another trajectory that gets arbitrarily close but never satisfies G. Finally, if the guard is enabled but not urgent, then step 4 has to resolve nondeterminism and choose (possibly from an infinite set of possibilities) the timing of the next transition. Sliding mode phenomena, wherein a trajectory grazes the boundary of a guard (or invariant), is a special case of such nondeterminism.

None of those complications arise in RimlessWheel. Each trajectory intersects the guard hyperplane at a particular time, and the corresponding transition is taken, resetting the angle to − β/2. Stated in more detail, there is a discrete transition at t = 3.75, which resets the angle from v ⌈ θ = 0.523 to v′⌈ θ = 0.523.

4.4.2  Reachable states, invariants, and stability

Owing to the instantaneous changes, it does not make sense to talk about the state of the system at t = 3.75, or, for that matter, at any time when there is a transition. Instead, it makes sense to talk about the prestate v and the poststate v′ of a specific transition in an execution. Nevertheless, it is convenient to refer to “the” state of the system at a given time along an execution. Thus, with this caveat, we define the notation α(t) α′.lstate, where α′ is the longest prefix of α with α′.ltime = t. That is, α(0.523) will correspond to the poststate of the transition with θ = −0.523.

Recall that for a state or valuation v ∈ val(V), the 2-norm ||v|| refers to the norm of v restricted to the real-valued, continuous variables. Extending that convention, ||α(t)|| refers to the 2-norm of the valuations of the real-valued variables of V, at time t, and along the execution α. With those conventions, Definition 3.5 in Chapter 3 can be imported to execution fragments of HA to define Lyapunov, asymptotic, and exponential stabilities.

Definition 4.4.   An HA is globally uniformly asymptotically stable if for any ε > 0 and any state v₀, there is a time Tε, v₀ such that for any execution fragment α starting from v₀, for all t ≥ Tε, q₀, |α(t)|≤ ε.

Consider two interesting questions related to stability. First, suppose that each individual mode of a simple hybrid automaton is asymptotically stable; does that necessarily imply that the overall HA is also stable? If that claim were true, then stability verification of HA would reduce to stability verification of ODEs, and the techniques developed over centuries for the latter would be adequate for analyzing this important property of cyber-physical systems. The counterexample of Figure 4.8 shows that the claim is false, and therefore that new techniques are needed for stability verification of HA; we will study some of these instances in Chapter 10.

The HA shown on the left side of Figure 4.7 has two variables, x and y, and two modes, mode0 and mode1. If we look at the dynamics in each of the modes separately, we observe that each is a linear time invariant (LTI) system; using Theorem 3.4, we can easily check that each is asymptotically stable. Although the trajectories of the two individual modes converge asymptotically to the origin, they have different shapes as shown in two different shades on the right side of Figure 4.7. The HA switches between those two LTI subsystems. Specifically, the transitions and the invariants ensure that the dynamics of mode0 is followed in the first and third quadrants (xy ≥ 0), and mode1 is followed in the second and fourth quadrants (xy < 0). The resulting executions spiral out to infinity as shown on the left side of Figure 4.8.

Figure 4.7
An LTI HA with two stable modes and the trajectories of the individual modes. Left: HA. Right: Converging trajectories for the stable LTI modes (with mode0 in gray and mode1 in black).

Figure 4.8
Unstable (left) and stable (right) executions of HA that combine two individually stable linear systems.

The second question is: with the same stable LTI subsystems, is it possible to change the transitions (and invariants) to make the resulting HA stable? We will study these types of questions systematically in Chapter 10. For now, we will just remark that indeed it is possible. For example, by switching the quadrants in which the modes are active, one can make the resulting HA asymptotically stable (as shown on the right side of Figure 4.8). In summary, we see that stability-related questions for HA pose interesting problems, and they cannot be completely reduced to the analysis of the subsystems (or modes). We will revisit this topic in Chapter 10.

4.4.3  Time-abstract semantics

Given an HA 𝒜, we can define an infinite state discrete automaton (Definition 2.1 in Chapter 2) that corresponds with the executions of 𝒜. Such a discrete automaton is called a time-abstract automaton and is written as Untimed(𝒜). Untimed(𝒜) has a new action ε that is not an action of 𝒜. The transitions of Untimed(𝒜) include all the transitions of 𝒜 labeled with actions in A, and new transitions labeled with ε that take τ.fstate to τ.lstate for each trajectory τ of 𝒜.

Definition 4.5.   Given an HA 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩, we define the corresponding time-abstract automaton denoted by Untimed(𝒜) as the discrete automaton Untimed(𝒜) = ⟨V′, Θ′, A′, 𝒟′⟩, where

1. V′ = V,

2. Θ′ = Θ,

3. A′ = A ∪{ε}, ε A, and

4. 𝒟′ is defined as follows: for any v, v′∈ val(V′) and a ∈ A′, iff

  (i) a ≠ ε and , and

(ii) a = ε and ∃τ ∈ 𝒯 such that v = τ.fstate and v′ = τ.lstate.

In other words, a transition labeled with action a of 𝒜 will be modeled by an identical transition in Untimed(𝒜), and the trajectories of 𝒜 will be captured by ε-transitions in Untimed(𝒜). The following proposition establishes the correspondence between the two automata more precisely.

Proposition 4.1.   For any HA 𝒜, Reach𝒜 = ReachUntimed(𝒜).

Proof. First, we show Reach𝒜 ⊆ ReachUntimed(𝒜). Consider any reachable state v ∈ Reach𝒜. From the definition of reachability, there is a finite execution α = τ₀, a₁, τ₁, a₂, …, τn in Execs𝒜 such that τn.lstate = v. From α, we inductively construct a new sequence β = v₀, ε, , a₁, v₁, ε, v₁′, a₂, …, vn, ε, vn′, where vi = τi.fstate and vi′ = τi.lstate. We claim that β ∈ExecsUntimed(𝒜). That follows from the definition of the discrete automaton Untimed(𝒜): (1) v₀ = τ₀.fstate ∈ Θ𝒜 = ΘUntimed(𝒜) [from Definition 4.5 (c)]; (2) for each ai, vi, and therefore [by Definition 4.5 (d)(i)]; and (3) for each i, vi vi′, because by Definition 4.5 (d)(ii), there is τi with vi = τi.fstate and vi′ = τi.lstate. Because β ∈ExecsUntimed(𝒜) and β.lstate = τn.lstate = v, it follows that v is a reachable state of Untimed(𝒜).

The proof for ReachUntimed(𝒜) ⊆Reach𝒜 follows a similar argument.

From Proposition 4.1, it follows that an invariant for 𝒜 is also an invariant for the automaton Untimed(𝒜), and vice versa. Because Untimed(𝒜) does not preserve information about the time at which a state is reached along an execution, it is obvious that bounded time reachability and invariance properties do not carry across to 𝒜.

Exercise 4.3.   Define Timed(𝒜) as a discrete automaton similar to that in Definition 4.5, but one that preserves the timing information of the trajectories. Show that for any k ∈ ℕ, T ∈ ℝ≥0, Reach𝒜(Θ, T, k) = ReachTimed(𝒜)(Θ, 2k).

4.4.4  Execution zoo

Alternation of transitions and trajectories gives rise to interesting kinds of executions that are absent from purely discrete and purely dynamical models. Recall that an execution α = τ₀a₁τ₁a₂… is finite if it is a finite sequence, and that it is closed if it is finite and for every trajectory in the sequence τi.ltime < ∞. Executions that are not closed are open. Open executions can be finite or infinite. A finite execution is open if and only if the final trajectory is open—that is, τ.dom is either a bounded open interval [0, T) or an unbounded open interval [0, ∞). An infinite execution is always open. An execution that allows time to diverge (i.e., α.ltime = ∞) is called admissible. An execution that is neither finite nor admissible is a Zeno execution. It is named after the Zeno of Elea (490-435 BCE), who demonstrated in one of his famous paradoxes related to motion, how Achilles is defeated in a race by a tortoise.

It is unnatural for system models to block time from progressing. For models to be nonblocking, every execution should be a prefix of some admissible execution. An admissible execution may be finite or infinite. In the former case, a finite number of transitions is followed by an open, unbounded trajectory. In the latter case, there are infinitely many closed trajectories and intermediate transitions, which add up to an infinite amount of time. An HA is admissible if every execution is a prefix of an admissible execution.

Exercise 4.4.   Show that every execution of RimlessWheel is a prefix of an infinite execution. Does it have any Zeno executions? In other words, is it admissible?

Admissibility can get compromised in various ways. First, finite and inadmissible executions arise when the ODEs describing the dynamics of the system do not admit solutions beyond a certain point. Also, solutions might exist that do not satisfy the mode invariants beyond a certain point. Infinite and inadmissible Zeno executions can arise when an action remains enabled in its own poststate. That leads to the occurrence of infinitely many transitions in 0 time. A more interesting Zeno execution is one in which τ₀.ltime = 1 and , and the duration of this execution is 2. In general, it is difficult to check automatically whether a given HA is admissible. Sufficient conditions for checking for the existence of Zeno executions have been proposed by Ames et al. (2005) and Or and Ames (2010).

4.5  Example: Spacecraft docking

A software-based control enables autonomous operation of spacecraft for docking, assembly, and maintenance (Jewison and Erwin, 2016). Here, we consider a scenario with two spacecraft in orbit: an active spacecraft that starts from an initial orbit and then docks with a passive or target spacecraft in a different orbit by moving along an intermediate transfer orbit (see Figure 4.9).

Figure 4.9
Orbits for spacecraft docking. Initial orbit of active spacecraft (solid black), transfer orbit (dashed), and the orbit of the passive spacecraft (solid gray).

Modeling assumptions   The motion of an object in orbit around Earth is described by Kepler’s laws. We assume that the two spacecraft are restricted to the same orbital plane, resulting in two-dimensional (2D), planar motion. To change the orbit, a spacecraft fires up its thrusters in a particular configuration for a carefully calculated duration of time. In this model, we assume that this duration of thrusting is instantaneous and the change of orbits is brought about by transitions.

SpaceRndz model   Derived from Kepler’s laws, the dynamics of the angular position (ν) of a satellite in orbit is given by this nonlinear ODE:

where ν is measured with respect to the major axis from the main focus, ec is the eccentricity of the orbit, the parameter p = a(1 − ec²) is called the semilatus rectum, a is the semimajor axis of the orbit, and μ is the geocentric gravitational parameter. To jump to a new orbit, the active satellite uses its thrusters. The durations of the burns are small compared to the time of flight in orbit; therefore, the burns are modeled as discrete transitions that instantaneously change the orbital parameters ν, p, and ec.

In the SpaceRndz automaton of Figure 4.10, the orbital motion of the two satellites is captured by the state variables (ν₁, p₁, ec₁) and (ν₂, p₂, ec₂), respectively. The guards G₁ and G₂ define the conditions (based on the relative angular positions) for starting the two orbital transfer burns, and the functions R₁ and R₂ define the reinitialization of the orbital parameters that results from the burns. In all the orbits, the motion of the motions of the satellites are governed by Equation (4.9); thus, for the sake of brevity, we write a single Orbit mode for the model. The stop when condition is similar to a mode invariant. A trajectory τ satisfies stop when P if and only if for any t ∈ τ.dom, if τ(t) ∈ P, then t = τ.ltime. That is, at any point in time t, if τ satisfies P, then that t must be the last point of τ. In SpaceRndz, the stop when condition implies that a trajectory must stop (and that the corresponding burn transition must occur) when either (1) the active satellite is in the initial orbit and G₁ is satisfied, or (2) it is in the transfer orbit and G₂ is satisfied.

Figure 4.10
Satellite rendezvous system.

4.6  Example: Small aircraft traffic management system

The Small Aircraft Transportation System (SATS) was developed at the National Aeronautics and Space Administration (NASA) for small airports in North America to coordinate landing sequences of aircraft with a lightweight ground infrastructure (Holmes et al., 2004). This type of distributed landing protocol might play an important role in achieving urban air taxis.

Modeling assumptions   The airspace around the airport is divided into several holding and approach zones along the left and right sides of the runway. The left side of Figure 4.11 shows these zones in three dimensions (3D) from a pilot’s point of view. The SATS protocol defines the conditions under which an aircraft participating in the protocol can move from one zone to the next zone. For the purpose of analyzing the correctness of the distributed protocol, the model used by scientists and researchers abstracts away the complicated motion of each aircraft in 3D space with a 1-dimensional (1D) point (Umeno and Lynch, 2006, 2007). Further, the time taken for an aircraft to move from one zone to another is much smaller than the time spent in each zone, and therefore, in the HA model of SATS, transitions are used for the former and trajectories for the latter. This abstraction captures the distributed coordination across aircraft and the time that it takes for aircraft to clear certain separation requirements, which are key to arguing the safety of the protocol. Here, we further simplify and present a one-sided version of the protocol in Figure 4.12.

Figure 4.11
SATS airspace. Left: SATS airspace zones from a pilot’s perspective. The left and right zones are named from the perspective of the control tower. Right: Abstract model of the zones for the SATS automaton.

Figure 4.12
Small Aircraft Transportation System.

SATS model   An aircraft approaching to land starts out flying (status = Fly), and then enters the left holding zone (HL); then it goes through the base zone (BaseL) and the final zone (Final); and then it finally lands (Runway). In off-nominal behavior, it may miss the runway, in which case it enters the missed approach zone (MAL) and retries the approach.

The SATS model captures the evolution of n participating aircraft. In addition to the location (status[i]), each aircraft i keeps track of the preceding aircraft in the landing queue (next[i]) and its own position (x[i]). Further, the ground infrastructure maintains the identity of the final (last) aircraft to enter the airspace. The variables next[i] and last are set when aircraft i enters HL. If next[i] becomes 0, this indicates the absence of a predecessor for i; similarly, last = 0 indicates that there is no aircraft in the landing queue. Aircraft i is allowed to enter BaseL only when there is no predecessor, when the predecessor next[i] is not in BaseL, or when next[i] is more than a safe distance (LSafe) ahead of i. This set of conditions is the critical guard that ensures safe separation of the aircraft. In BaseL, Final, and MAL, aircraft i’s position x[i] is modeled as a point moving along a linear airspace with speed in the range [vmin, vmax]. The stop when condition ensures that the transitions occur when x[i] reaches the length of the respective airspace. In the other modes, the position of the aircraft is immaterial.

Warning about floats and reals.   Real numbers and their operations, such as derivatives and integrals, are convenient for describing physical processes. However, precisely representing even a single real number in a computer can require infinitely many bits. Computers use a finite number of bits, and therefore they have to quantize real numbers with finite precision and bounded-valued data types like float. Floating-point standards like the IEEE 754 codify the behavior of these data types (e.g., with regard to rounding, overflow, and underflow), but our models often gloss over these quirks. This quantization gap can be catastrophic and was behind the unfortunate Ariane 5 rocket explosion (Jézéquel and Meyer, 1997).

One way to avoid such problems is to model quantization explicitly in the HA. We refer the interested reader to the literature on quantized control, starting with Liberzon (2003a) and Bicchi et al. (2002). An alternative two-phase verification approach by Anta et al. (2010) proceeds by first analyzing the real-valued model of the controller to derive bounds on the implementation errors that can be tolerated while preserving stability, and then checking that the software implementation of the controller indeed meets those tolerances.

4.7  Exercises

Exercise 4.5.   Suppose that all the orbits of SpaceRendz are circular (i.e., eci = 0). Under what additional assumptions is SpaceRendz an RHA?

Exercise 4.6.   Consider a deterministic hybrid automaton 𝒜 = (V, Θ, A, 𝒟, 𝒯 ). For every action a ∈ A, the transition is specified by a guard enabled(a) ⊆ val(V) and a reset function reset(a): val(V) → val(V ). Let α(θ, t) be the state reached by the execution of 𝒜 from initial state θ ∈ Θ at time t. Assuming that all the reset functions are continuous, show that α(θ, t) is a continuous function of θ.

Exercise 4.7.   Consider a linear hybrid automaton 𝒜. Assuming that the initial set Θ is a convex set, show that the set of states reached at time T is also a convex set.

Exercise 4.8.   Consider an idealized billiard table of length a and width b. The table has no pockets, its surface has no friction, and its boundary bounces the balls perfectly. Write an HA model of the position of two balls of equal mass on this table. The balls have some initial velocities. A ball bounces off a wall when its position is at the boundary. Balls collide whenever |x₁ − x₂|≤ ε and |y₁ − y₂|≤ ε, and their velocity vectors are pointing toward each other. Here, ε is some constant. Whenever a bounce occurs, the appropriate velocity changes sign. Whenever a collision occurs, the balls exchange their velocity vectors. Make all the variables internal. Wall bounces are modeled by an output action called bounce, and each collision is modeled by an output action collision.

Exercise 4.9.   For the model in Exercise 4.8, state the conservation of speed along each coordinate axis as an invariant property of the automaton.

Exercise 4.10.   Model the following hysteresis-based switching system as an HA. The automaton has at least n continuous variables x₁, …, xn, and a discrete variable called m, which takes the values in the set mode₁, …, moden. We say that the system is in mode i when m = modei. There are n × (n − 1) actions switch(i, j), where i, j ∈ [n] and j ≠ i. When the system is in mode i, , where ai > 0 is a positive constant and for all j ≠ i. Further, when the system is in mode i, for any j ≠ i, if xi becomes > (1 + h)xj, then the automaton switches to mode j; otherwise, it continues in mode i. Here, h > 0 is a parameter of the model. Is your model deterministic?

Exercise 4.11.   Consider two satellites orbiting Earth in circular orbits with constant angular speeds ω₁ and ω₂. Write an HA model of the position of the satellite pair in the [0, 2π]² space. When one of the satellites hits 0 or 2π, its position has to be reset. Model that using an output action called jump.

Exercise 4.12.   Consider a linear dynamical system with these inputs:

where x ∈ ℝn is the state vector, u ∈ U ⊆ ℝm is an input vector that is chosen from a finite family U of inputs, A is an n × n matrix, and B is an m × n input matrix. Define a transition system that corresponds to a discrete-time version of this dynamical system. That is, let 𝒜δ = ⟨Q, Q₀, Act, T⟩ be the discrete transition system for a given sampling parameter δ. The set of states Q corresponds to the vector space ℝn; the set of actions Act = U; and the set of transitions should correspond to the trajectories or solutions of Equation (4.10) of length δ. Define the transition relation precisely. (Hint: One method would be to define each transition to be parameterized by an input u ∈ U.)

Exercise 4.13.   Suppose that the set of initial states Q₀ of 𝒜 is a convex polytope—that is, a set described by a set of linear inequalities (or, equivalently, by a set of extremal vertices). Show that for any time k ≥ 0, and for any fixed u ∈ U, the set of states reached by 𝒜 at time kδ from Q₀, Reach(kδ, Q₀), is also a polytope.

5

Composing Models

Overview

For any large project, it makes sense to start with smaller modules and then put the modules together to create increasingly big pieces until we complete the project itself. The benefits of that modular approach are that repeated modules can be reused and concurrency exploited; further, different modules can be built by different teams, and smaller modules are easier to debug when something goes awry. Similarly, we can build large mathematical models from smaller modules, and the key operation is called composition. In this chapter, we will define composition for discrete and hybrid automata and develop some of the main properties of this operation.

5.1  Composing automata

Recall the definition of automata from Chapter 2 (Definition 2.1), and now consider composing two automata (𝒜₁ and 𝒜₂) to create a new automaton 𝒜, which models the simultaneous execution of both. If 𝒜₁ and 𝒜₂ are completely decoupled (i.e., they operate on independent state variables and evolve according to disjoint sets of actions), then 𝒜 is simply the union of the two. More interesting scenarios arise when the evolution of one automaton influences that of the other. At the very least, we would like 𝒜 to be an automaton of the same type as 𝒜₁ and 𝒜₂, so that the composition operation can be applied repeatedly to create bigger models. This property is called closure under composition.

Different formalisms achieve closure under different assumptions. Here, we follow the input/output automaton (IOA) formalism (Lynch and Tuttle, 1989; Kaynar et al., 2005). An IOA partitions its actions (and variables) into input, output, and internal actions. Input and output actions are used for interautomata synchronization and for state updates, while internal actions are used exclusively for state updates. The key assumption that ensures composition closure for IOA is that input cannot be blocked. This principle of input enabledness implies that for every possible input action of an automaton 𝒜, there is a well-defined behavior of 𝒜 from any state. In the rest of this section, we develop these ideas formally.

5.2  Composing input/output automata

For a pair of automata 𝒜₁ and 𝒜₂, a shared action a ∈ A₁ ∩ A₂ enables the two component automata to share information instantaneously. Specifically, for each automaton 𝒜i, i ∈{1, 2}, the set of actions Ai is partitioned into three categories:

1. Internal actions (Hi) only bring about state changes of 𝒜i and are not involved in any interactions.

2. Output actions (Oi) are controlled by (i.e., triggered by) 𝒜i and read by other automata.

3. Input actions (Ii) are controlled by other automata and read by 𝒜i.

5.2.1  Input/output automata

This categorization of actions leads to the following extension of Definition 2.1 of automaton from Chapter 2:

Definition 5.1.   An IOA 𝒜 = ⟨V, Θ, A, 𝒟⟩ is an automaton (as in Definition 2.1) for which the set of actions A is partitioned into sets of input (I), output (O), and internal (H) actions. In addition, 𝒜 satisfies the following input action-enabling condition: E1 (input action enabled) at every state v, every input action a ∈ I is enabled. That is, there is a poststate v′ such that v .

E1 ensures that 𝒜₁ has well-defined transitions for every input action at any state. This makes it impossible for an IOA to block input actions. An automaton without inputs is said to be closed; otherwise, it is open. Executions, reachable states, and invariants of IOA are defined in exactly the same way as in Section 2.4.

5.2.2  Compatibility and composition of input/output automata

It only makes sense to define compositions of IOA that have compatible sets of actions. For example, the internal actions of one automaton should not be triggered by any action of another automaton. Similarly, each output action should be controlled by only one automaton, and the output action of one automaton should not trigger the internal transitions of another one. By contrast, more than one automaton may have the same input action. These considerations have led to the following definition of compatibility:

Definition 5.2.   A pair of IOA, 𝒜₁ and 𝒜₂, are compatible if (1) Hi ∩ Aj = ∅, (2) Oi ∩ Oj = ∅, and (3) Vi ∩ V j = ∅, for i ≠ j.

For a compatible pair of automata 𝒜₁ and 𝒜₂, their parallel composition (or simply composition) defines a new automaton in which the occurrence of a shared action a ∈ (O₁ ∩ I₂) ∪ (O₂ ∩ I₁) simultaneously updates the states of both.

Definition 5.3.   If 𝒜₁ and 𝒜₂ are compatible, then their composition 𝒜 = 𝒜₁||𝒜₂ is defined to be 𝒜 ⟨V, Θ, A, 𝒟, 𝒯⟩, where

1. V = V ₁ ∪ V ₂.

2. Θ = {v ∈ val(V) | ∀ i ∈{1, 2}, v ⌈ V i ∈ Θi}.

3. The overall set of actions A = H ∪ O ∪ I = A₁ ∪ A₂, where

  (i) the set of internal actions H = H₁ ∪ H₂;

 (ii) the set of output actions O = O₁ ∪ O₂; and

(iii) the set of input actions I = I₁ ∪ I₂ ∖ O.

4. For each v, v′∈ val(V) and each a ∈ A, if and only if for i ∈{1, 2}, either

  (i) a ∈ Ai and , or

 (ii) a Ai and v ⌈ Vi = v′⌈ V i.

Theorem 5.1 states that the class of IOA is closed under composition. Thus, we can build up larger automata models by inductively composing pairs of smaller components.

Theorem 5.1.   For any pair of compatible IOA 𝒜₁ and 𝒜₂, their composition 𝒜 = 𝒜₁∥𝒜₂ is also an IOA.

Proof. The only interesting thing to show is that the composed automaton 𝒜 satisfies E1. Consider an arbitrary input action a and an arbitrary state v of 𝒜. We will construct a v′ such that . From Definition 5.3(c), a ∈ I₁ ∪ I₂ ∖ O, and we assume without loss of generality that a ∈ I₁. From E1 of 𝒜₁ it follows that there is such that v ⌈ V₁ . We define v′ as v′⌈ V₁ = v₁′, v′⌈ V₂ = v ⌈ V ₂. Because a I₂ ∪ H₂ ∪ O₂, it follows that v .

5.3  Example: Channels, logical clocks, and distributed systems

We will develop an IOA model of a distributed system of n processes that maintain logical clocks by communicating over first-in, first-out (FIFO) channels. We first define the channel and the process automata individually, and then define their compositions.

5.3.1  First-in, first-out channels

To begin, consider the model of a single channel, FifoCh, in Figure 5.1. The automaton takes a type parameter MC, which is the type of messages that can be sent over the channel. It also takes two constant parameters i, j ∈ ID, which define the source and the destination process identifiers. Here, ID is a fixed set of identifiers. It is conventional to write process IDs as subscripts. Thus, if ID is fixed to be the set {1, 2, 3}, FifoCh(M, 1, 2), or equivalently FifoCh₁₂(M), delivers messages of type M sent by process 1 to process 2.

Figure 5.1
IOA model of an untimed FIFO channel.

FifoChij(M) has two input actions, sendij and dropij, and a single output action, recvij. It has a single state variable, queueij, which is a queue of elements of type MC. Initially, queueij is empty. A sendij(m) action, for any m ∈ MC, appends m to the end of queue. This sendij, being an input action, is always enabled (E1). The absence of any precondition is interpreted as a precondition that is true. A recvij(m) action can occur only if m is at the head of the queueij, which makes the channel FIFO. The result of that action is that the message m is removed from the head of queueij. Because recvij is an output action, any other IOA that synchronizes on this action can react to the received message m. The input action dropij models the loss of a message from the head of queueij. The following exercises can be performed to practice this style of modeling.

Exercise 5.1.   Modify FifoChij so that no message is ever dropped. In this modified automaton, is it guaranteed that every message will be delivered? Can queueij grow unbounded?

Exercise 5.2.   Modify FifoChij so that the channel is always of bounded length. That is, old, undelivered messages are dropped when the queueij reaches this bound and new messages are sent.

Notice that there is no local way for FifoChij to force a recvij to occur. We can force actions to occur by adding fairness assumptions on top of the automaton specification and then restricting our attention to only the fair executions of the automaton. We saw in Section 4.5 of Chapter 4 that with timed and hybrid automata models, actions can be forced to occur using stop when predicates. A timed automaton can force one of its actions to occur by blocking time from advancing. Later in this chapter we will see an example of that construct with the TimedChannel model in Section 5.6, which ensures that every sent message is delivered within a time bound.

5.3.2  Logical time in distributed systems: Lamport clocks

In a distributed system, synchronization of clocks across various processes is a challenging (and often impossible) problem. For many applications, it is adequate to have a notion of a logical clock for ordering events in a distributed system. Formally, any such logical clock should assign a value to every event such that the assignment satisfies the natural properties given in Definition 5.4:

Definition 5.4.   A logical clock should assign a value to every event such that:

1. No two events get assigned the same logical clock value.

2. The logical times assigned to events at each process are strictly increasing according to the order of their occurrence along any execution.

3. The logical time assigned to any send event is strictly less than the corresponding recv.

4. For any particular value, there are only finitely many events that get assigned logical times less than that.

In a famous paper (Lamport, 1978), Leslie Lamport proposed a simple algorithm for assigning logical timestamps to events in a distributed system. The IOA model of this algorithm, Lamport, is shown in Figure 5.2. The automaton takes one constant parameter i ∈ ID, which specifies the process identifier; and a second type parameter, Msg, which specifies the type of the messages used by the underlying algorithm. For notational convenience, we will write Lamport(i, M) as Lamporti(M). That is, Lamport₂(M) is the instance of Lamport’s algorithm with messages of type M running at process 2.

Figure 5.2
The Lamport clock protocol.

Lamporti(M) has one type of input action, recvji, for any j ∈ ID, j ≠ i; one type of output action, sendij, for any j ∈ ID, j ≠ i; and one internal action, eventi. It has a single state variable, clocki, which keeps track of the logical time of process i.

The eventi action models any local computation performed by process i. It increments clocki by 1. In our model, it is the catchall action for all noncommunicating events, and therefore it can occur anytime. Adding a precondition to that action will not affect the correctness of the rest of the algorithm. The sendij(⟨m, c⟩) action models process i’s sending of message m to j. The payload of the message m is tagged with the timestamp c = clocki + 1, and clocki is advanced to clocki + 1. Again, send could have additional preconditions without affecting the correctness of the algorithm. The recvji(⟨m, c⟩) action models process i’s receiving of m from j with timestamp c over channel FifoChji. The effect is for clocki to be advanced to max(clocki, c) + 1. Action recvji, being an input action, is always enabled.

5.3.3  Composed system: A network of processes communicating over channels

We proceed to specify a system LTF(M: type, n: Nat), with n processes and n(n− 1) channels, with ID = [n] and message type M. The component IOA involved are Lamporti(M), i ∈ ID and FifoChij(M), i, j ∈ ID. One can check that those automata are pairwise compatible according to Definition 5.2, and therefore that their composition LTF(M, n) is well defined. The composition can be written explicitly as

The interconnection of the IOA through send and recv interfaces is shown in Figure 5.3.

Figure 5.3
Interconnection of the Lamport process and FifoCh channel automata: LTF(M, 3). The arrows go from output to input.

Equation (5.1) and the definition of IOA composition (Definition 5.3) completely define LTF(M, n). For the sake of concreteness, the explicit definition of the composed automaton is given in Figure 5.4. Notice that sendij and recvji are classified as output, while dropij remains input. Also, observe how the precondition for each action a comes from the automaton for which a is an output, while the effect is the union of all the effects.

Figure 5.4
Composed IOA LTF(M, n).

Behaviors of the composed system   Executions of LTF(M, n) are defined as in Section 2.4 in Chapter 2. An example run of the system is shown in Figure 5.5. The occurrence of eventi actions are marked by black dots; dots connected by arrows correspond to sendij and recvij actions. The numbers on the dots give the value of the clocki variable after the action updates the state. This type of representation is commonly used in distributed computing textbooks. An execution corresponding to that run could be

Figure 5.5
A sample run of LTF(M, 3). The occurrences of eventi’s are marked by black dots; arrows correspond to sendij and recvij actions. The numbers on the dots give the value of the clocki variable after the action updates the state.

where vk are states of LTF(M, 3).

Exercise 5.3.   Show that for all n ∈ ℕ, and any message type M, LTF(M, n) satisfies the requirements of Definition 5.4. Is reliable delivery of messages necessary for this to hold? Do the channels have to be FIFO?

5.3.4  Traces and projections

The restriction operator (⌈ (·, ·)) on executions is useful for filtering out information about certain variables and actions.

Definition 5.5.   Let α be an execution fragment of IOA 𝒜 with sets of variables and actions V and A. Let A′⊆ A be a subset of actions, and V′⊆ V be a subset of variables. Then, the restriction of α to (A′, V′), written as α ⌈ (A′, V′), is a sequence defined inductively as

In essence, α ⌈ (A′, V′) is the alternating sequence of valuations and actions obtained by removing all occurrences of actions in A ∖ A′ and their following valuations, and then discarding from all remaining valuations the information about the variables in V∖ V ′.

Definition 5.6.   For an IOA 𝒜 with set of variables V and actions A = H ∪O∪I, the trace of an execution α is the sequence trace(α) = α ⌈ (I ∪O, V). The set of all the traces of 𝒜 is denoted by Traces𝒜.

The trace of automaton Lamport₁ that corresponds to the execution α written in Equation (5.2) is send₁₂, send₁₃, recv₃₁. Lemma 5.2 states that an execution fragment α of a composed IOA 𝒜 = 𝒜₁∥𝒜₂, when restricted to the variables and actions of its components, gives execution fragments of the components:

Lemma 5.2.   Let 𝒜 = 𝒜₁||𝒜₂ and let α be a finite execution fragment of 𝒜. Then α ⌈ (A₁, V₁) and α ⌈ (A₂, V₂) are execution fragments of 𝒜₁ and 𝒜₂, respectively.

Proof. Without loss of generality, we will show by induction on the length of α that α ⌈ (A₁, V₁) ∈ Execs𝒜₁. Let α = v₀, a₁, v₁, a₂, …, vk. For the initial state, α.fstate ⌈ (A₁, V₁) = v₀ ↓ V ₁ ∈ Θ₁, where the last containment follows from Definition 5.3(b). Let α′ = v₀, a₁, v₁, a₂, …, vn, n ≤ k, and α′ ⌈ (A₁, V₁) ∈ Execs𝒜₁. We extend α′ to get α = α′, an+1, vn+1. There are two cases to consider: First, if an+1 ∈ A₁, then from Definition 5.3, it follows that . Therefore, α ⌈ (A₁, V₁) ∈ Execs𝒜₁. Otherwise, an+1 A₁, and in this case, α ⌈ (A₁, V₁) = α′⌈ (A₁, V ₁).

Exercise 5.4.   Consider a pair of compatible IOA 𝒜₁, 𝒜₂, their composition 𝒜 = 𝒜₁∥𝒜₂, and an execution α ∈Execs𝒜. Show that α is finite if and only if α ⌈ (𝒜₁, V₁) and α ⌈ (𝒜₂, V₂) are also finite.

Exercise 5.5.   Consider a pair of IOA 𝒜₁ and 𝒜₂. Suppose that 𝒜₁ has a single final state vfinal, in which all executions end, and that 𝒜₂ has a single initial state Θ₂ = {vinit}. A sequential composition of 𝒜₁ and 𝒜₂ will be a new automaton that first behaves like 𝒜₁ up to vfinal, and then behaves like 𝒜₂. Show that it is possible to model the sequential composition as a parallel composition 𝒜₁′∥𝒜₂′ of two slightly modified automata.

5.4  Composing hybrid input/output automata

A hybrid automaton models both discrete and continuous evolution of cyber-physical systems. For modular model building, component hybrid automata should be able to interact both via shared actions and via shared variables. Therefore, in a hybrid input/output automaton (HIOA), which refines the hybrid automaton model of Definition 4.1, both the set of actions and the set of variables are partitioned into input, output, and internal subsets. Input/output (I/O) actions are used for interautomata synchronization through discrete transitions, as in the case of IOA. In contrast, I/O variables are used for continuous interactions across automata.

In more detail, consider a pair of HIOA 𝒜₁ and 𝒜₂. The set of actions for each automaton Ai, i ∈{1, 2} is partitioned into three categories, as described in the text just before Definition 5.1 earlier in this chapter. The set of variables for each automaton Vi, i ∈{1, 2} is also partitioned into:

1. Internal variables (Xi), which are the state variables of 𝒜i and are not involved in any interactions;

2. Output variables (Yi), which are controlled by 𝒜i and read by other automata; and

3. Input variables (Ui), which are controlled by other automata and read by 𝒜i.

5.4.1  Hybrid input/output automata

Categorization of actions and variables as input, output, and internal leads to the following definition of HIOA (Lynch et al., 1995; Mitra, 2007):

Definition 5.7.   An HIOA 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩ is a hybrid automaton (as in Definition 4.1).

1. The set of variables V is partitioned into input (U), output (Y), and internal (X) variables; val(X) is the state space.

2. Θ ⊆ val(X) is the set of start states.

3. The set of actions A is partitioned into input (I), output (O), and internal (H) actions.

4. 𝒟⊆ val(X) × A × val(X) is the set of discrete transitions.

5. 𝒯 is a prefix, suffix, and concatenation closed set of trajectories for V.

In addition, 𝒜 satisfies the following input-enabling conditions:

E1

(Input action enabled) At every state x, every input action a ∈ I is enabled. That is, there is a poststate x′ such that .

E2

(Input trajectory enabled) From every state x, the automaton should be able to react to any trajectory υ of the input variables in U. That is, there is a trajectory τ ∈ 𝒯 starting from x such that τ ↓ U is a prefix of υ, and either (a) τ ↓ U = υ, or (b) τ is closed and some internal or output transition is enabled at τ.lstate.

First, notice that discrete transitions 𝒟 affect only the internal or state variables in X. Second, the E1 and E2 conditions capture the principle of input enabledness or nonblocking. From any state x, for every input action, there is a well-defined transition (E1), as in the case of IOA. In addition, for every input trajectory υ, there is a well-defined state trajectory or a partial state trajectory, followed by an internal or output transition (E2). A hybrid automaton that has I/O actions and I/O variables, but that does not necessarily satisfy E1 and E2, is called a pre-HIOA.

Executions, execution fragments, and reachable states of HIOA (and pre-HIOA) are defined in the same way as they are defined for hybrid automata in Section 4.4 in Chapter 4. An execution fragment is a (possibly infinite) sequence α = τ₀ a₁ τ₁ ⋯, such that (1) each τi ∈𝒯, and (2) if τi is not the last trajectory in α, then τi.lstate X. Even though the discrete transitions do not explicitly change the I/O variables, we cannot assume that τi.lstate ⌈ v = τi+1.fstate ⌈ for any v ∈ Y∪ U. The reason is that the changes in the state variables may indirectly change v in the trajectories.

5.4.2  Compatibility and composition of hybrid input/output automata

Sets of HIOA are compatible if their actions and variables do not interfere with each other. In addition to the compatibility conditions for IOA (given in Definition 5.3), the internal and output variables of one automaton should be disjoint from the variables of other automata.

Definition 5.8.   A pair of HIOA, 𝒜₁ and 𝒜₂, are compatible if (1) Hi ∩ Aj = ∅, (2) Oi ∩ Oj = ∅, (3) Xi ∩ Vj = ∅, and (4) Yi ∩ Y j = ∅, for i ≠ j.

For a compatible pair of HIOA 𝒜₁ and 𝒜₂, their composition defines a new hybrid automaton as given in Definition 5.9.

Definition 5.9.   If 𝒜₁ and 𝒜₂ are compatible, then their composition 𝒜 = 𝒜₁||𝒜₂ is defined to be 𝒜 ⟨V, Θ, A, 𝒟, 𝒯⟩, where

1. The overall set of variables V = X ∪ Y ∪ U, where (i) the set of internal variables X = X₁ ∪ X₂, (ii) the set of output variables Y = Y ₁ ∪ Y ₂, and (iii) the set of input variables U = U₁ ∪ U₂ ∖ Y.

2. Θ = {x ∈ val(X) | ∀ i ∈{1, 2}, x ⌈ Xi ∈ Θi}.

3. The overall set of actions A = H ∪ O ∪ I = A₁ ∪ A₂, where (i) the set of internal actions H = H₁ ∪H₂, (ii) the set of output actions O = O₁ ∪O₂, and (iii) the set of input actions I = I₁ ∪ I₂ ∖ O.

4. For each x, x′∈ val(X) and each a ∈ A, iff for i ∈{1, 2}, either a ∈ Ai and x ⌈ Xi , or a Ai and x ⌈ Xi = x′⌈ Xi.

5. A trajectory τ of V is in 𝒯 iff for each i ∈{1, 2}, τ ↓ Vi ∈𝒯i.

It is straightforward to check that the composition 𝒜 of a pair of compatible HIOAs is almost an HIOA, in that 𝒜 satisfies all the conditions except possibly the input trajectory enabled condition E2.

Theorem 5.3.   If 𝒜₁ and 𝒜₂ are compatible HIOAs, then 𝒜₁||𝒜₂ is a pre-HIOA.

Exercise 5.6.   Give an example of a pair of compatible HIOAs whose composition is a pre-HIOA and not an HIOA.

Exercise 5.7.   Consider two compatible HIOAs 𝒜₁ and 𝒜₂, with Xi = {xi}, Yi = {yi}, and for each i ∈{1, 2}, U₁ = {y₂} and U₂ = {y₁}. Consider the case in which 𝒯i is defined by the differential and algebraic equations and yi = gi(xi), where j ≠ i. Develop sufficient conditions on the sets of trajectories 𝒯₁ and 𝒯₂ in terms of the functions fi, gi such that the composition 𝒜₁∥𝒜₂ is guaranteed to be an HIOA.

5.5  Example: Interconnecting flip-flops

Often, after developing a component model, we will find it useful to copy and paste this component several times to create a bigger model. For example, Figure 5.6 shows the interconnection of two FlipFlops from Section 2.1.1 in Chapter 2. In this example, we will express this model as the composition of two automata. First, the original FlipFlop automaton defined a single flip-flop. To make copies, we introduce a formal parameter i: {1, 2} in the automaton definition and subscript the variables Ji, Ki, Qi (but not clk).

Figure 5.6
Composing modified FlipFlops to create a leader-follower circuit.

To interconnect these flip-flops, we have to define their external interfaces first. Instead of introducing new I/O actions for modeling the interactions, we introduce Bool input variables Ui−1, and output variables Ui, . Being variables of an HIOA, now all these variables will have well-defined trajectories with constant dynamics. That is, d(Ji) = d(Ki) = d(Qi) = d(clki) = 0; therefore, they are not written out explicitly in the resulting FlipFlopIO automaton of Figure 5.7. Instead, the trajectories are defined by copying the inputs to the states Ji = Ui−1; , for i ≥ 0, and copying the states to the outputs Ui = Qi; , i > 0.

Figure 5.7
Hybrid input/output model of FlipFlop from Chapter 2.

The common input action tick toggles both clk₁ and clk₂; Q₁ is updated only when clk₁ is reset to 0, and Q₂ is updated only when clk₂ = 1. We assume that this input action tick is periodically triggered by another automaton, not included in this model. The final composed system is:

Exercise 5.8.   (a) Check that FlipFlopIO(2) and FlipFlopIO(1) are indeed compatible HIOA. What are the inputs of the composed system? (b) Let us define a tick action as positive if it changes the value of clk₁ from 0 to 1. In digital circuits, this corresponds to a positive clock edge; analogously, we define negative ticks. Consider constant initial input values of J₁ and K₁. Suppose that these values change in between two ticks. Show that whatever FlipFlopIO(1) produces as the output U₁ on a positive tick, FlipFlopIO(2) replicates that in the next negative tick.

5.6  Example: Timed channels

We will develop an HIOA version of the FIFO channel of Section 5.3, with bounded delivery guaranteed. The automaton TimedChannel is shown in Figure 5.8. As in the case of FifoCh, it takes a type parameter Msg, which is the type of message that can be sent over the channel, and two constant parameters i, j ∈ ID, which define the source and the destination processes. In addition, it takes a positive real parameter b that defines the delivery time bound. Thus, TimedChannel₁₂(M, 0.1) delivers messages of type M sent by process 1 to process 2 within 0.1 seconds.

Figure 5.8
An HIOA model of a timed channel.

TimedChannelij(M, b) has one input action sendij and one output action recvji. It has a state variable queueij, which is a queue of ⟨M, ℝ⟩ pairs and is initialized to be empty. In addition, it has a clock variable called nowij.

A sendij(m) action, for any m ∈ MC, appends the pair ⟨m, nowij + b⟩ to the end of queueij. The second item nowij + b serves as the deadline by which the message m has to be delivered or received. As usual, the absence of any precondition for send is interpreted to mean that the precondition is true, and therefore, the action is always enabled. A recvji(m) action can occur only if the head of the queueij has a message m (with any deadline). The result of that action is that the message m is removed from the head of queueij. Because it is an output action, any other IOA that synchronizes with this action can react to the received message m.

As discussed in the context of the FIFO channel (Section 5.3), the preconditions of the recv action do not force the actions to occur. However, with the clock variable nowij, it is possible to accomplish that with appropriate invariants. The trajectories section of TimedChannelij specifies the behavior of the continuous variable nowij: there is a single mode called timePassage with a differential equation d(nowij) = 1, which specifies that along every trajectory τ, τ(t) ⌈ now = τ(0) ⌈ now + t. Further, the mode invariant specifies that a trajectory τ is valid so long as for any t ∈ τ.dom, the deadline of the message at the head of τ(t) ⌈ queueij does not exceed the current time, as measured by τ(t) ⌈ nowij. Thus, along any execution of TimedChannelij, in order for time to advance beyond the point where head(queueij).d = nowij, the only option is for recvji(m) to occur. In summary, the clock variable nowij and the associated invariants can force enabled actions to occur in HIOA execution. In particular, sent messages are guaranteed to be delivered within a deadline in the TimedChannel.

Exercise 5.9.   Consider a distributed system model LTT(n), obtained by composing copies of the TimedChannel automata with the Lamport automata (Figure 5.2). LTT(n) is analogous to LTF(n). Write the complete composed specification of LTT(n). Can LTT(n) have Zeno executions? Is each queueij always bounded?

Exercise 5.10.   Write HIOA models of the following two automata that communicate over a TimedChannel(M, b): (1) Sender periodically sends a message every Δ > 0 time units unless a failed bit is set. An input action Fail sets the failed bit. (2) Detector triggers an output action Flag if Δ + b time elapses without its receiving a message. That action sets to true a flag Boolean variable, which was initialized to f alse. The time since the last message is measured by a stopwatch variable, timer.

Exercise 5.11.   Show that the three automata of Exercise 5.10 (TimedChannel, Sender, and Detector) are compatible. Define their composition as the hybrid automaton FD (failure detector). Show that FD is an HIOA. Prove that the following are invariant properties of FD:

1. flag failed.

2. failed ∧ (timer > Δ + b) flag.

5.7  Example: Pulse generator and oscillator

Models of excitable cells like neurons and cardiac cells can help us gain insight into the mechanisms that underlie electrical dynamics in the brain and heart. Broadly speaking, a mathematical model describes the electrical phenomena at the cellular level that give rise to oscillations called action potentials. They capture transmembrane ionic currents, concentrations, and voltages. The Nobel Prize–winning work of Alan Hodgkin and Andrew Huxley (1952) on giant squid axon models (Hodgkin and Huxley, 1952) pioneered this area of research. Subsequently, several other models have been developed, including hybrid automaton models and models that involve compositions of networks of HIOA (Grosu et al., 2007, 2011; Huang et al., 2014).

Next, we present the FitzHugh–Nagumo model of an excitable cell (FitzHugh, 1961; Nagumo et al., 1962) composed with a simple pulse generator. This is a generic two-dimensional (2D) model for excitable media, and it can be applied to a variety of systems. It is related to the van der Pol oscillator and can be seen as a simplification of the Hodgkin–Huxley equations. Oscillator, shown in Figure 5.9 (right), gives the differential equations for this model. They define the behavior of the continuous variables voltage (x₁) and current (x₂) as driven by input u. This ordinary differential equation (ODE) model can be seen as a simple HIOA, with a single mode and input variable u.

Figure 5.9
PulseGen automaton (left) and the Oscillator (right).

The PulseGen HIOA generates a square pulse wave output with width Ton and period of Ton + Toff . Figure 5.9 shows how it does this. PulseGen is a simple HIOA with two modes, On and Off, and a single output variable u. It stays in On mode for a duration of exactly Ton, and during that time, u = 1. Similarly, it stays in Off mode for Toff duration, and during that time, u is set to 0. The behavior of the timer now is shown on the left subfigure of Figure 5.10.

Figure 5.10
Sample execution of cardiac Oscillator composed with a PulseGen. Trajectories in On mode are shown in black, and those in Off mode are in gray.

Exercise 5.12.   Write the HIOA specification for Oscillator, and write the HIOA specification for PulseGen. In addition to the output variable u, your HIOA will require at least a loc variable and a timer, now. Check that Oscillator and PulseGen are compatible and write the composed automaton. Is the composed automaton an HIOA?

Exercise 5.13.   Write a program to simulate Oscillator composed with different pulse generators that produce square waves (PulseGen), saw-tooth waves, sigmoid waves, and other possible shapes. A sample execution of Oscillator∥PulseGen is shown on the right of Figure 5.10.

5.8  Traces, untiming, and properties of compositions

Our modeling framework provides convenient features for inferring the properties of a composed automaton from the properties of its parts. To state those properties precisely, we have to extend to executions the restriction operation defined earlier for trajectories.

Definition 5.10.   Let α be an execution fragment of a hybrid automaton with a set of variables V and a set of actions A. Let A′ be a subset of actions and V′ be a subset of variables. Then, the restriction of α to (A′, V′), written as α ⌈ (A′, V′), is the sequence defined inductively as

Here, τ₁ ⌢ τ₂ denotes a new trajectory obtained by concatenating τ₂ after τ₁.

In essence, α, restricted to (A′, V′), is the alternating sequence of actions and trajectories obtained by discarding all the information from α about the actions in A ∖ A′ and the variables in V∖ V ′.

The restriction operator (⌈ (·, ·)) on executions is useful for filtering out information about variables and actions (e.g., those that are invisible). Typically, the input and output actions and variables are considered to be visible, and α ⌈ (I ∪ O, Y∪ U) is called the trace of α.

In the tricky corner case when V′ = ∅, the trajectories in α ⌈ (A′, V′) have useful information about their duration only, as they map intervals of time to valuations of the empty set of variables. For example, if we restrict an execution of the RimlessWheel automaton to the set ({impact, ∅}), we will obtain an alternating sequence τ₀, impact, τ₁, impact…, where each τi is a trajectory that maps an interval of time to a vacuous map (mapping empty sets of variables to their valuations). Going a step further, we can drop all the timing information from an execution to obtain its untimed version. Formally, the untimed version of an execution α = τ₀, a₁, τ₁, a₂, … is the sequence

where ε A is a special action (label) denoting the lapse of some time. The set of all the untimed executions of 𝒜 is denoted by Untimexecs𝒜. Traces can be untimed in a similar manner.

Definition 5.11.   For a hybrid automaton 𝒜 with variables V = X ∪ Y ∪ U and actions A = H ∪ O ∪ I, the trace of an execution α is the sequence trace(α) = α ⌈ (I ∪ O, Y∪ U). The set of all the traces of 𝒜 is denoted by Traces𝒜; the set of finite traces is FinTraces𝒜.

Theorem 5.4 relates the set of traces of a composed HIOA 𝒜 to the sets of traces of its components. In one direction, the set inclusion says that the traces of the components 𝒜₁ and 𝒜₂ can be pasted together to get the traces of 𝒜. In the other direction, it captures the idea that a trace of the composition 𝒜 that is restricted to the component interfaces gives the traces of the components.

Theorem 5.4.   Let 𝒜 = 𝒜₁∥𝒜₂. Then, Traces𝒜 is exactly the set of (I ∪ O, U ∪ Y)-sequences whose restrictions to 𝒜₁ and 𝒜₂ are finite traces of 𝒜₁ and 𝒜₂, respectively. That is,

Lemma 5.5 states that an execution fragment α of a composed HIOA 𝒜 = 𝒜₁∥𝒜₂, when restricted to the variables and actions of its components, gives execution fragments of the components. The restriction operator ⌈ can be seen as the projection of α on the variables of the component automata. Moreover, the fragments of the composition 𝒜 have certain characteristics if and only if the component fragments also have similar characteristics.

Lemma 5.5.   Let 𝒜 = 𝒜₁||𝒜₂, and let α be an execution fragment of 𝒜. Then, α ⌈ (A₁, V₁) and α ⌈ (A₂, V₂) are execution fragments of 𝒜₁ and 𝒜₂, respectively. Furthermore,

1. α is time bounded iff both α ⌈ (A₁, V₁) and α ⌈ (A₂, V₂) are time bounded.

2. If α is closed, then both α ⌈ (A₁, V₁) and α ⌈ (A₂, V₂) are closed.

3. If α is non-Zeno, then both α ⌈ (A₁, V₁) and α ⌈ (A₂, V₂) are non-Zeno.

5.9  Example: Emergency braking on highways

More than 25 percent of all reported traffic accidents are rear-end crashes (Kodaka et al., 2003), of which around 85 percent happen on straight roads. Emergency braking and forward collision warning systems are designed to intervene automatically and prevent this type of accident if, for example, the driver is distracted or the leading vehicle is not visible. Testing the safety of such an advanced driver-assistance system (ADAS) can be nontrivial. Consider a scenario in which n cars are driving in the same lane of a highway (Figure 5.11). The safety of Car2 depends on the initial separation of the cars, initial speeds, the throttle/braking inputs given by the drivers in Car1 and Car3, the vehicle dynamics, the reaction times of the drivers, the road surface, and braking profiles, among other factors. Here, we will develop hybrid models for verifying the safety of these types of ADAS features. Following the approach presented in Fabris (2012) for the risk analysis required by the ISO 26262 safety standard (see Section 6.2.2 in Chapter 6), our model accounts for the initial conditions of the vehicles, the reaction times of the drivers, and the braking profiles to be analyzed.

Figure 5.11
Sequence of n (=3) cars driving in the same lane, with automatic emergency braking (AEB). The safe-braking profile of Car₂ depends on the initial conditions and the behavior of the other drivers.

The SingleLaneCar HIOA shown in Figure 5.12 is parameterized by the vehicle identifier i ∈ ID (e.g., ID = {1, …, n}), and it models the ith vehicle in a sequence in a single lane of a highway. SingleLaneCari is also parameterized by its driver’s reaction time RT, the initial separation from the leading car d₀, the safety distance threshold ds, and the braking profile a. The braking profile gives the effective deceleration as a function of time. The automaton has three modes (braking, cruising, and reacting) and three internal actions that trigger the transitions among these modes. The state variables xi and vi model the position and velocity of the vehicle in the single lane. Initially, car i starts d₀ distance behind car i − 1. The discrete variable loci is the usual mode variable, and timeri is a stopwatch. The initial values of some of those variables are left unspecified. The output variable yi is essentially a copy of i’s position xi, and therefore, yi−1 is the position of its predecessor. Thus, SingleLaneCari has access to the position of SingleLaneCari−1 through the input variable.

Figure 5.12
Composition of HIOA modeling AEB on single-lane highways. The parameters d₁₂ and d₂₃ are set to be equal to d.

The SingleLaneCari models a simple driving behavior governed by the following rules:

1. The driver starts to react when the distance to the leading car yi−1 − yi drops below the threshold ds (triggeri).

2. At the end of the reaction time RT, the brakes are engaged, and the vehicle decelerates according to a (brakei).

3. During braking, if the distance to the leading car becomes greater than 2ds, then the vehicle goes back to cruising at the current speed.

Those rules are modeled by the actions specified by the contents of the parentheses. In the cruising and reacting modes, SingleLaneCari moves at a constant speed of vi (CruiseReact). In the braking mode, the vehicle slows according to the braking profile a (line 40 of Figure 5.12).

Observe that the hybrid automata described here are pairwise compatible. The overall platoon of n cars (with identical reaction times, safety thresholds, and braking profiles) is defined by the composition:

In Chapter 11, we will revisit this example and see how verification techniques and statistical information about the parameters can be combined to infer the risk levels of different braking profiles.

Exercise 5.14.

Show how a pre-HIOA can be made input enabled through the possible addition of appropriate transitions and dynamics.

Exercise 5.15.   The software that implements the type of controller described in this section has to monitor the current state (g₀, g₁) continuously. Modify the model slightly so that those checks are performed periodically.

5.10  Exercises

Exercise 5.16.   Assuming that the initial conditions of all the vehicles are fixed exactly, is SLPlatoon(RT, D, a) deterministic?

Exercise 5.17.   Develop a new version of the SingleLaneCari hybrid automaton in which the driver may have one of two possible reaction times, with RT₁ < RT₂.

Exercise 5.18.   Prove Lemma 5.5.

Exercise 5.19.   Prove Theorem 5.3.

Exercise 5.20.   Consider a composed hybrid automaton 𝒜 = 𝒜₁∥𝒜₂ and a sequence of actions and trajectories α, such that α ⌈ (Ai, Vi) is an execution of 𝒜i for i = 1 and i = 2. Show that α is an execution of 𝒜.

Exercise 5.21.   Give an example of a composed hybrid automaton 𝒜 = 𝒜₁∥𝒜₂ and an execution α of 𝒜, such that α ⌈ (A₁, V₁) is closed but α is not.

Exercise 5.22.   Let HIOA 𝒜 = 𝒜₁∥𝒜₂, and let α be an execution fragment of 𝒜. Then, show that for i ∈ {1, 2}, α ⌈ (Oi ∪ Ii, Ui ∪ Yi) = trace(α ⌈ (Ai, V i))—that is, restricting an execution α to the external interface of a component 𝒜i has the same result as the trace of the execution projected on 𝒜i.

Exercise 5.23.   Given a collection of HIOA 𝒜₁, …, 𝒜k, one can construct a directed dependency graph with vertices V = {1, …, k} and an edge from i to j if and only if Uj ∩Yi ≠ ∅. Show that if the graph is acyclic, then the composed automaton 𝒜 = 𝒜₁∥…∥𝒜k is an HIOA.

Exercise 5.24.   Create a composed model of a feedback controller for the Vehicle model discussed in Section 3.4.2 (in Chapter 3) that periodically samples the state of the vehicle to set the control inputs. You can use the idea of the controller described in Exercise 3.7.

6

Specifying Requirements

Overview

In the previous chapters, we have introduced models for cyber-physical systems that define their behaviors. The rest of this book is about techniques for verifying whether those behaviors are correct. To proceed with verification, one has to first define what it means for a behavior to be “correct.” This is the subject of this chapter. The definition of correct behavior usually comes from what are called the design requirement documents for the system or the product. These documents describe what the system does—capabilities, functions, operations—and may also contain information on how the system works, how it should interact with users, and how it should be maintained. We begin by introducing requirements analysis, which is the human process of pinning down these requirements. In the first part of this chapter, we discuss the existing safety standards that are used for testing and certification of the safety-critical cyber-physical systems. These standards are written informally. In the second part, we present formal requirements in terms of safety, liveness, and more general temporal logic statements. In between, we discuss the roles of human and computational resources in the formal verification process.

6.1  Requirements analysis

Requirements analysis for a product or a component consists of a set of tasks that ultimately lead to the determination and documentation of the design requirements that the product must meet. Requirements are sometimes referred to as technical specifications, specifications, or functional attributes. For example, “0 to 60 mph in 2.8 seconds” is an example of a high-level specification for an electric vehicle. For a more realistic example, the software requirements for the A-7 E aircraft by Alspaugh et al. (1992) will be instructive.

Products have many stakeholders—users, designers, regulators, and maintainers—that often have conflicting needs and incentives. Therefore, requirements analysis is an iterative human process for eliciting input from stakeholders, analyzing use cases, cross-validating possibly conflicting requirements, and then documenting the requirements in a contract. Beyond the core hardware and software functionalities (aka behavioral requirements), requirements can cover aspects such as performance, user interfaces, energy efficiency, environmental impact (such as emissions), and cost-effectiveness. Here, we will not discuss this topic in any detail, but we note some of the common challenges in using informal requirements for the purpose of verification.

First, requirements are typically written using a combination of natural language, tables, state diagrams, flowcharts, and pseudocode. As a result, requirements are ambiguous and underconstrained. There are requirement specification languages (RSLs) that reduce some of those ambiguities. For example, variants of temporal logics (see Sections 6.4.2 and 6.5) have been proposed for mathematically defining the requirements of cyber-physical systems. Another alternative for avoiding ambiguity is to use natural language-processing (NLP) tools that convert the requirements to a machine-readable, and therefore consistent and unambiguous, form (Kof, 2004). Adoption of RSLs and NLP tools has been limited in part because they involve a learning curve and thus are often seen as impractical.

6.2  Safety standards

Safety standards provide guidelines and processes for developing safety-critical systems. For example, the Federal Aviation Administration (FAA) of the United States uses the DO-178C standard (RTCA, 2011) as guidance for determining and certifying the airworthiness of aviation software, and it is enforced as part of the Federal Aviation Regulations. ISO 26262 (ISO, 2011) is the relevant standard governing the functional safety of electronic and software components in road vehicles, but in contrast to the situation for aviation systems, its adoption is voluntary. Other safety standards include MIL-STD-882E, the Department of Defense Standard Practice for System Safety; the Federal Motor Vehicle Safety Standard (FMVSS); AUTOSAR (AUTomotive Open System ARchitecture); EN 50126, on Reliability, Availability, Maintainability and Safety of Railway Applications (RAMS); MISRA C, the Guidelines for the Use of the C Language in Critical Systems; the IEC 62304 standard for medical devices; and the Safety of the Intended Functionality (SOTIF) standard.

Most safety standards classify system components or functions into certain integrity levels and give guidelines for developing and testing components in each integrity level. The classification of a component into an integrity level is typically based on analysis of the consequences of the component’s failure or malfunction. It is important to remember that most of these standards are descriptive but not prescriptive, and they leave a lot to the discretion of the suppliers and system builders.

6.2.1  DO-178C

One example of this is DO-178C, which has five assurance levels for software modules, also known as Design Assurance Levels (DALs) (see Table 6.1). A component’s level is determined from the safety assessment process and hazard analysis via examination of the effects of a failure condition in the system. The failure conditions are categorized by their effects on the aircraft, crew, and passengers. For example, at the two extremes, Level A is “Catastrophic Outcome,” and Level E is “No Safety Effect.”

Table 6.1
Design Assurance Levels (DALs) and Automotive Safety Integrity Levels (ASILs).

DAL

Failure condition

Code coverage requirements

ASIL

A

Catastrophic

MC/DC unit tests with independence, branch, functional, call, and statement coverage

N/A

B

Hazardous

Branch and statement coverage with independence, MC/DC highly recommended

ASIL D

C

Major

Statement coverage, MC/DC unit tests, branch coverage recommended

ASIL B/C

D

Minor

Statement coverage, Branch coverage recommended

ASIL A

E

No safety effect

N/A

The DAL classification then establishes the rigor necessary to demonstrate compliance with DO-178C. For example, components that command, control, or monitor safety-critical functions are classified as Level A. The standard requires any Level A software to be tested to cover every statement, branch, and function call, as well as to pass the so-called Modified Condition/Decision Coverage (MC/DC) tests. Roughly, an MC/DC test suite requires that (1) each entry and exit point in the code be invoked, (2) each decision take every possible value, and (3) each condition in a decision take every possible value. For certain levels, DO-178C requires that the testing, verification, and validation be performed by a team that is independent of the software development team.

Dozens of commercial tools (e.g., MATLAB, Esterel, Cantata, VectorCAST, Rapita Systems, and CodeSonar) can support DO-178C certification in different ways, such as by applying formal verification. The DO-333 supplement of DO-178C identifies aspects of the airworthiness certification process that pertain to the production of software using formal methods. For example, DO-333 requires that the soundness of each formal analysis method be documented. The implementation of tool soundness issues is addressed separately as part of the tool qualification process described in DO-330. Use cases for classical theorem proving, model checking, and abstract interpretation in DO-178C certification, in accordance with DO-333, are described in Cofer and Miller (2014); however, applications of hybrid system verification techniques are currently nonexistent.

6.2.2  ISO 26262

Much like DO-178C, the ISO 26262 standard classifies components into levels; in this case, these are four Automotive Safety Integrity Levels (ASILs), which are based on exposure to issues that affect the controllability of the vehicle. Roughly, an ASIL captures a more general notion of risk, and it is expressed as follows:

The standard divides probabilities of exposure into five classes, ranging from “Very low probability” (E1) to “High probability” (E4). To rate severity, it has four classes, ranging from “No injuries” to “Fatal injuries.” To rate controllability (by the driver), it has four classes, from “Controllable” to “Difficult to control.” The standard shows how these variables must be combined to determine the required ASIL for an electronic subsystem or component in the vehicle. For example, a component that must be relied upon in a situation that has a medium probability of occurrence, and is considered normally controllable but can result in life-threatening injuries, requires an ASIL of B.

It would be a misconception to think that an ASIL can be attributed to a device; rather, an ASIL can be attributed only to a functionality or a property. For example, it would not make sense to talk about “ASIL B LIDAR.” In contrast, a valid requirement might take the form “With ASIL B, it is assured that in 99 percent of the cases in which there is an object of a specified dimension in a specified range in front of the sensor, then the sensor will report it in the object list.”

The ASIL level classification establishes the rigor necessary to demonstrate compliance with ISO 26262, again in a manner similar to that of DO-178C. Although the two standards are similar in spirit, the requirements for meeting ASIL and DAL levels are not precisely comparable. ISO 26262 specifies testing requirements both at the unit level and at the architectural level, and there is no requirement for independence. Also, although MC/DC testing is highly recommended at the highest level (ASIL D), the requirement for how that is achieved is different from the requirements in DO-178C. Table 6.1 provides a rough alignment between DALs and ASILs.

Several case studies have been published that show how testing and formal verification can be applied for ISO 26262 compliance and risk analysis (Altinger et al., 2014; Rana et al., 2013). A simulation-based analysis method for automatic emergency braking (AEB) systems is proposed by Fabris (2012). More recently, that analysis has been re-created more efficiently using data-driven verification (Fan et al., 2018).

The broad idea is as follows: The question of whether the automatic braking profile of a sequence of cars on the highway is safe depends on several parameters, including initial separation, initial speeds of the vehicles, vehicle dynamics, reaction times, and road surface. The analysis determines (through simulation or formal analysis) whether a given braking profile is safe for a set of scenarios characterized by these parameters. That determination is then combined with statistical information about the distributions of the parameters (e.g., from road-traffic camera data) to calculate the probability of accidents. In the case of unsafe scenarios, the worst-case relative velocity of the collision is computed; it serves as a proxy for the severity of an accident. By combining probability and severity, one determines the overall risk associated with the braking profile. That type of analysis can be used as a design tool for tuning the braking profiles for different highway speeds, road conditions, and other factors.

6.2.3  Beyond current safety standards and requirements

Safety standards and requirements are useful for dealing with many potential design and implementation defects. However, many areas of autonomous systems are not appropriately covered by existing standards (Koopman and Wagner, 2016). This realization is driving research activities and the creation of new standards and specifications that go beyond ISO 26262 and DO-178C. One such emerging standard for highly automated driving is SOTIF (ISO/TC 22/SC 32, 2019), which incorporates the statistical correctness of functionality, such as in image-based object detection, and covers unsafe situations that arise other than hardware failures.

Responsibility-Sensitive Safety (RSS) is another emerging model for safety, introduced by Shalev-Shwartz et al. (2017). RSS formalizes what it means for an autonomous vehicle to drive safely on its own and how it should exercise reasonable caution to protect against the unsafe driving behavior of others. It aims to satisfy the need for sound, useful (i.e., not overly conservative), and verifiable driving policies.

Autonomous systems that use test-driving data to train machine learning (ML) functions, such as deep neural networks (DNNs), are also beyond the current safety standards. There is intense ongoing research on topics related to the specification and verification of ML algorithms, as well as autonomous systems built with those ML algorithms. We briefly point to some of the ongoing activities in Section 11.8.5 in Chapter 11, but because of the unsettled nature of the research, we have decided not to explore these topics further in this book.

6.3  From requirements to verification

Formally, a requirement defines a predicate over the set of system behaviors. It defines which behaviors are allowed and which are forbidden. More generally (e.g., for stochastic models), it makes sense to have quantitative requirements that define metrics over probability distributions of behaviors. For example, a requirement could stipulate that the expected fuel efficiency of a vehicle model be within some range, for a given set of driving conditions. In this book, we will stick to the simpler binary requirements.

In the rest of this chapter, we will discuss formal, or mathematically precise, requirements. Automatic tools need the requirements to be represented in a formal and machine-readable format. There are many such formats, which cater to different modeling formalisms, application domains, and analysis approaches. Instead of getting into tool-specific formats, in this section, we will discuss the dominant mathematical notions that define allowed system behaviors. Unless otherwise stated, our model of the system in question could be a discrete, continuous, or hybrid automaton. The rest of the book is about verification techniques. At this point, we make a few remarks about algorithms and the roles they play in the overall verification and validation enterprise.

6.3.1  Formal verification algorithms

First and foremost, the goal of a verification process is to check whether a given cyber-physical system meets a given requirement (Figure 6.1). Second, as users and developers of verification techniques, we would prefer that the verification process use resources optimally. More about resources and optimality will be covered in Section 6.3.2, but first let us define what it means for a verification process to be correct.

Figure 6.1
A verification algorithm takes as input an automaton 𝒜 from a class of models and a requirement R from a class of requirements, and it either gives a proof establishing that all behaviors of 𝒜 meet R or gives a particular behavior of 𝒜 that violates R.

Recall that for an automaton 𝒜, the set of all possible behaviors or executions is denoted by Execs𝒜 (see Sections 2.4, 3.4, and 4.4). A requirement R, therefore, can be seen as a subset of Execs𝒜. An execution α ∈ Execs𝒜 meets the requirement R if α ∈ R; otherwise, it is said to violate the requirement. An execution α ∈ Execs𝒜 that violates a requirement R is called a counterexample to R.

In an ideal world, verification would be a fully automatic process carried out by an algorithm executing on a computer. Such a verification algorithm Alg would come with a warranty to work for a class of models and a class of requirements. Given an input model 𝒜 from that model class and a requirement R from that class of requirements, Alg would decide whether all executions of 𝒜 meet the requirement R. Indeed, this is a decision problem (defined in Appendix B). That is, Alg would produce one of two kinds of outputs: (1) if 𝒜 violates R, then Alg finds a counterexample execution α ∈ Execs𝒜∖ R that witnesses the violation; or (2) Alg gives a proof establishing that ∀ α ∈ Execs𝒜, α ∈ R. Counterexamples can help designers fix design bugs, help product managers revise operating conditions and usage models, and help customers redefine the requirement R. A proof establishing that 𝒜 meets the requirement R can be used in the certification process (e.g., for DO-178C); proofs can also be useful for explaining the correctness of the design of 𝒜.

For model and requirement classes with such warrantied verification algorithms, we can happily shift our attention to investigating the optimality of the algorithm in terms of computational resource usage. For example, the task of checking invariant requirements for the class of integer-timed automata presents one such ideal situation, as we shall see in Chapter 9.

However, for general cyber-physical system mode classes, the situation is known to be grimmer. There is no perfect algorithm that always works. We will see an example of this in Section 9.5 in Chapter 9. The verification enterprise has to rely on imperfect algorithms that may be wrong—missing bugs or giving false alarms, failing to terminate on other inputs, or worse. In such situations, the verification team has to navigate the complex trade-offs between the expressive power of the model class and the precision and computational efficacy of the available imperfect verification algorithm (or tool) for that class.

A verification algorithm Alg is said to be sound if it answers the verification query correctly. That is, when it gives a proof, that proof is valid, and indeed all behaviors of 𝒜 meet the requirement R; and when it gives a counterexample behavior, then the counterexample is indeed an actual behavior of 𝒜 that violates R. An algorithm is said to be complete if it is guaranteed to terminate for all 𝒜, R inputs. Most of the verification algorithms and techniques discussed in the later chapters are sound. While some of them, like the reachability analysis algorithms of Chapter 9 and the data-driven verification algorithms of Chapter 11, are fully automatic, others, like the invariance and termination verification techniques of Chapters 7 and 10, can be partially automated with manual input.

6.3.2  Resources for verification and computational complexity

Even with perfect algorithms, the verification and validation enterprise requires human effort for (1) encoding the requirements and models in a verification tool; (2) validating the models, which means checking that the models indeed correspond to the real system that has been designed or prototyped; and (3) interpreting the output results of the verification tool. The models and requirements have to be manually refined several times, in a closed-loop iterative process, before the desired results are achieved. As it happens, there is no agreed-upon definition for precisely accounting for these human efforts.

For algorithms, on the other hand, the resources concerned are memory usage, computing cycles, bits needed for communication, and other things that can be measured. For any given algorithm Alg, the amount of resources [e.g., number of central processing unit (CPU) cycles] used will obviously depend on its inputs, 𝒜 and R. Alg will require more cycles to verify a bigger 𝒜 than a smaller one. Therefore, to study the efficiency of Alg, it makes sense to evaluate how the number of cycles used by Alg scales with the size of the inputs, rather than fixate on the actual number of cycles used by a particular input.

The computer science view of measuring resource usage is to count resources (number of computational steps, bits of memory, bits sent, random bits drawn, and so on) used by a Turing machine representation of Alg. Turing machines and computational complexity concepts are reviewed in Appendix B. Owing to the complexity theoretic Church-Turing thesis, the actual resources used by Alg (running on any real computer and operating system and implemented with any programming language) is proportional to the resources used by this Turing machine representation. Because we are mainly interested in how the resource usage scales with the size of the input, we can rigorously derive the worst-case resource usage of Alg—up to a constant factor—from any representation (e.g., the pseudocode used in this book) without writing out a Turing machine.

It is worth noting that representing a real-valued output, even from a small input, may require an infinite number of bits. Real-valued calculations abound in verification algorithms for cyber-physical systems. This can complicate the Turing machine–based discipline of measuring complexity. One practical workaround is to use finite precision representations of real numbers, but this requires careful analysis of the propagation of errors. A branch of complexity theory using more powerful machines that can represent real numbers has been developed by Blum et al. (1988, 1997). These developments are theoretical, and the connections with verification are yet to be drawn.

In contrast, control theorists take a more abstract mathematical view of resource usage without worrying too much about how the objects being computed are represented in a computer. For example, the resource usage of two algorithms would be compared in terms of the number and dimension of the mathematical operations (e.g., matrix multiplication, constraint solving, optimization, and so on) that each of them invokes.

Finally, we remark that what can be called an “efficient” algorithm depends on the context. The commonly held interpretation that a problem is efficiently solvable if there is a polynomial time algorithm for solving it does not make sense in some contexts. For example, in the context of data science problems, the inputs are huge and polynomial time algorithms would be uselessly inefficient. A logarithmic time algorithm, or at least a sublinear time algorithm, would be considered efficient. In contrast, many important verification problems are known to be undecidable, and for such problems, even an exponential time algorithm for a relaxation of the problem might be considered a good start.

6.3.3  Invariants and safety requirements

By far, the most common requirements are invariants, or safety requirements (also known as safety properties). The idea of invariance for cyber-physical systems or programs comes from the generalization of fundamental conserved quantities, like energy or momentum in physics—quantities that do not vary in a closed system. Roughly, an invariant asserts requirements that must always hold. They capture the idea that “some things always hold,” or equivalently, that “bad things never happen.”

For an automaton 𝒜 with a set of variables V and state space val(V), a candidate invariant I is a subset of val(V). A candidate invariant can be equivalently expressed as a predicate over V. A candidate invariant I is an invariant if all states along all executions of 𝒜 satisfy I:

More generally, a safety requirement is defined by Alpern and Schneider (1987) as a set S ⊆ Execs𝒜, such that for any α ∈ Execs𝒜, α ∈ S ⇔∀ β ∈ Frags𝒜: β ≤ α ⇒ β ∈ S. That is, a safety requirement S is a requirement such that if α satisfies S, then so does any prefix of α. Invariant requirements are a popular subclass of safety requirements. Invariant requirements can be alternatively defined as a set I ⊆ val(V), such that the reachable states of 𝒜 [from a given set of initial states Θ ⊆ val(V)] are contained in I (i.e., Reach𝒜 ⊆ I).

For Dijkstra’s token ring algorithm of Section 2.5, the statement “The system always has a single token” represents a candidate invariant that is the set of all the states in which the system has a single token. This set can be equivalently written as the predicate ϕlegal (Section 2.5.1 in Chapter 2). As we saw in Section 2.5, the candidate invariant ϕlegal is indeed an invariant if all initial states of DijkstraTR have a single token. The driving safety requirement “Unless a turn signal is given, a car always stays inside lanes” can be expressed by the predicate

where x is the lateral position of the car and leftLane and rightLane are positions of the left- and right-lane markers.

Invariant properties can also be specified negatively, in terms of a bad thing or an unsafe thing that should never happen. An example of such a requirement in a traffic intersection would be “The lights on intersecting lanes should never be green simultaneously.” The invariant requirement in that case is indirectly specified by the set of bad states or unsafe states that should not be reached.

Exercise 6.1.   Write five traffic safety rules as invariants. Give the English statement and the corresponding predicate over the involved state variables.

Exercise 6.2.   If I₁, I₂ ⊆ val(V) are invariants of 𝒜, then show that I₁ ∪ I₂ and I₁ ∩ I₂ are also invariants.

Proposition 6.1.   For any candidate invariant (or safety) requirement I, if 𝒜 violates I, then there is a finite witnessing counterexample.

Proof. Suppose that 𝒜 violates the candidate invariant I. Then, there is a reachable state v ∈ Reach𝒜 such that v I. That is, there is a finite execution α that ends in v. This α is a finite witnessing counterexample.

A natural weakening of an invariant requirement is a bounded invariant or a bounded safety requirement. A candidate invariant I ⊆ val(V) is a bounded invariant up to time T, for some time bound T ≥ 0, provided that the states reachable within time T are contained in I. In other words, Reach𝒜(Θ, T) ⊆ I. The unbounded time invariant verification problem is usually hard (if not impossible) to solve exactly for most classes of models. That is the reason why recent research has concentrated around the more practical bounded time verification problem. We will discuss techniques for invariant verification in Chapters 7, 9, and 11.

6.3.4  Progress requirements

After the invariant, the second most common type of requirement is the progress requirement. Roughly, a progress requirement captures the idea that “something good eventually happens.” Achievement of safety requirements can be trivial unless the system also has to meet progress requirements.

Progress requirements come in several flavors. For an automaton 𝒜 with a set of variables V and state space val(V), a simple type of progress property can be specified by a subset P ⊆ val(V). Automaton 𝒜 is then said to meet this progress requirement [from a given set of initial states Θ ⊆ val(V)] if every execution of 𝒜 eventually reaches P. That is,

The condition in Equation (6.3) is akin to the termination of programs. More generally, a liveness requirement is defined in Alpern and Schneider (1987) as a set L ⊆Execs𝒜, such that ∀ β ∈Frags𝒜, ∃β′∈Frags𝒜, β ⌢ β′∈ L. That is, every finite execution can be extended (possibly by an infinite suffix) to meet such a requirement. Termination is a particularly familiar liveness requirement.

A stronger progress requirement would be to stipulate that every execution fragment of 𝒜 eventually must reach P, regardless of the starting state. The stabilization property is an example of the following type of requirement: after failure, the system can end up in any state, but then it recovers within finite time (i.e., it comes back to a legal state). In Dijkstra’s token ring algorithm, the stabilization requirement says that “the system eventually comes back to a state with a single token,” and the predicate ϕlegal defines this set (see Section 2.5 of Chapter 2). For automata on metric spaces, a more meaningful version of progress is captured by asymptotic stability, which requires all executions of 𝒜 to converge to P as time goes to infinity. For a vehicle control system, for instance, it makes more sense to converge toward a waypoint than to hit the waypoint precisely. The reader may find it helpful at this point to revisit Sections 3.4 and 4.4.2, in Chapters 3 and 4, respectively, for the related definitions of global and local stability.

These requirements say nothing about how soon progress to P is achieved. A stronger version of progress bounds the time within which P must be achieved:

where TP is a uniform upper bound within which P is achieved. Other versions of bounded progress allow TP to be a function of the initial state of α. Bounded progress is actually an invariant in disguise. To make that clear, rewrite Equation (6.5) as

where 𝒜′ is an augmented version of automaton 𝒜 with a timer variable. The invariant predicate here says that either timer ≤ TP or the state of 𝒜′ (without timer) is in P.

Exercise 6.3.   Write five traffic rules that are progress requirements. Give the English statement and the corresponding predicate over the involved state variables.

Exercise 6.4.   Construct a finite automaton 𝒜 and two progress predicates P₁ and P₂, such that 𝒜 meets the progress requirements P₁ and P₂, but not P₁ ∧ P₂.

A counterexample for a progress requirement P is an infinite execution α, such that ∀ t, α(t) P. Alternatively, a pair of finite execution fragments α₁, α₂ can represent an infinite counterexample. For this counterexample, we require that (1) α₁.fstate ∈ Θ, (2) α₁.lstate = α₂.fstate = α₂.lstate, and (3) for all t ∈ α₁.dom, α₁(t) P, and for all t ∈ α₂.dom, α₂(t) P. Then we define α = α₁ ⌢ α₂ ⌢ α₂ ⌢ …. The process for checking that α is a valid execution of 𝒜 and violates the requirement P is straightforward. That type of counterexample, which has a finite initial execution followed by an infinitely repeating fragment, is called a lasso. We will discuss techniques for verification of progress properties in Chapter 10.

6.4  Linear temporal logic

Temporal logics are a family of formal languages for succinctly specifying complex requirements. For example, temporal logic formulas can express requirements such as “After the walk button is pressed, the red light and the walk sign eventually turn on” and “After a failure, the system may exit the safety envelope S, but it eventually reenters and remains in S.” The term temporal can be misleading here, as these requirements have nothing to do with time—at least, not in the sense of real time in timed and hybrid automaton models.¹ Temporal refers to the sequential ordering of certain actions or predicates in the execution of the automaton in question. At the top level, there are two classes of temporal logics: (1) branching logics, which allow quantification over executions; and (2) linear logics, which do not. We will introduce computational tree logic (CTL) and linear temporal logic (LTL) as prominent members of these two classes. Temporal logics can be discussed in the context of various types of automata—that is, discrete state, timed, and hybrid. In this discussion, we focus on discrete models.

6.4.1  Background definitions

Recall Definition 2.1 in Chapter 2: An automaton is defined as a tuple 𝒜 = (V, Θ, A, 𝒟), where V is the set of variables, Θ is the set of initial states, A is the set of actions or transition labels, and 𝒟 is the set of labeled transitions. In the discussion of temporal logics, it is usual to label states instead of transitions.

Atomic propositions   Let AP be a set of atomic propositions. Each p ∈ AP is a basic (i.e., atomic) property or requirement that we care about. Examples of atomic propositions for the mutual exclusion protocol of Section 2.5 include p₁ (“Only one process has a token”), p₂ (“Process 2 does not have a token”), and p₃ (“Process 2 has value k”). A labeling function AP assigns to each state v ∈ val(V) a set of atomic propositions that hold in v. The labels for each state can be enumerated explicitly in the case of a finite state system, or else they have to be defined symbolically. For example, for any state of the mutual exclusion protocol v ∈ val(V), p₃ ∈ Lab(v) if and only if v.x[2] = k.

Automaton with state labels   If we replace the transition labels with state labels in Definition 2.1, we get the variant of the discrete automaton model given in Definition 6.1.

Definition 6.1.   A labeled transition system (LTS) 𝒜 is a tuple (V, Θ, Lab, 𝒟), where

1. V is the set of state variables.

2. Θ ⊆ val(V) is a nonempty set of start states.

3. Lab: val(V) → 2AP is a labeling function that assigns each state a set of atomic propositions.

4. 𝒟⊆ val(V) × val(V ) is the set of transitions.

This type of automaton is also called a Kripke structure. A finite state example is shown in Figure 6.2.

Figure 6.2
The states q₀, q₁, and q₂ have labels {a}, {b, c}, and {c}, respectively.

Because an LTS does not have transition labels, we define an execution of 𝒜 to be a sequence of states. An execution fragment or run of 𝒜 is a finite or infinite sequence α = v₀, v₁, …, such that for all i, (vi, vi+1) ∈𝒟. Given an execution α, we will use the notation α[k] to denote the kth state vk in the sequence. An execution fragment for which α[0] ∈ Θ₀ is called an execution. The set of all executions (fragments) of 𝒜 is denoted by Execs𝒜 (Frags𝒜). The set of executions (fragments) starting from a given state v ∈ val(V) is denoted by Execs𝒜(v) (Frags𝒜(v)).

6.4.2  LTL syntax

An LTL formula is an expression built from atomic propositions, Boolean connectives, and special temporal operators. There are five temporal operators: Next (X), Eventually (F), Always (G), Until (U), and Release (R). The syntax of an LTL formula f is given as follows:

where p ∈ AP is an atomic proposition and f₁, f₂ are LTL subformulas. Other logical operators, like ⇒, ⇔, and xor, though not included in this grammar, can be expressed in terms of ¬ and ∧, and therefore they can be used to connect LTL subformulas. Some authors use □ and ◊ to denote the Always and Eventually operators, respectively. Some examples of syntactically correct LTL formulas include F p₁ (“Eventually, only one process has a token”), FG p₁ (“Eventually, always p₁”), p₁ ⇒ X p₁ (“If p₁, then the next step satisfies p₁”), and p₂ ⇒ ◊¬p₂ (“If process 2 holds the token, then eventually it does not”).

6.4.3  LTL semantics

Broadly, any temporal logic formula or requirement R defines a set [[R]] of signals or sequences that satisfy R. The semantics of LTL is defined in terms of sequences labeled with atomic propositions. Here, we will define the semantics of LTL as sets of executions of an automaton 𝒜. Given a state v and an LTL formula f, we write v 𝒜f if and only if all executions of 𝒜 starting from state v satisfy f. When the underlying automaton 𝒜 is clear from context, we write v 𝒜f as v f. Because f is necessarily constructed from one or two LTL subformulas that use the previous grammar, the definition of the relation 𝒜 () will be inductive on the structure of the LTL formula f:

A few remarks about the definitions in this box are needed. First, although in this case, α is quantified over execution fragments of 𝒜 starting from v, a more general interpretation, independent of an automaton, is given in terms of infinite sequences of subsets of AP (α: ω → 2AP). In Section 6.5.1, we will see how branching temporal logics allow us to talk about some, but not all, executions starting from a state. A state v is defined to satisfy the LTL formula X f when all possible next states v′ from v satisfy f—that is, for all v′ such that (v, v′) ∈𝒟 is a valid transition, v′ f. A state v satisfies f₁ U f₂ if for every execution fragment α starting from v, f₂ eventually becomes true, and until then, f₁ holds. The U is also called the strong until operator, in order to highlight the interpretation that f₂ does indeed hold sometime in the future. In contrast, a weak until (W) operator does not require f₂ to occur. A state v satisfies f₁ R f₂ iff f₁ has to be true until and including the point in time when f₂ first becomes true; if f₂ never becomes true, then f₁ must remain true forever. An automaton 𝒜 satisfies an LTL formula f if every execution, α ∈ Execs𝒜, satisfies f. Thus, [[f]] = {α ∈ Execs𝒜 | αf}.

There is redundancy in this set of temporal operators. It turns out that any LTL formula f can be translated into a semantically equivalent formula f′ that uses only X and U operators. Semantic equivalence means that for any state v, v f iff v f′ and f′ uses only the temporal operators X and U. For example, you can easily check the following:

A common LTL idiom is to write “Always, eventually f,” or □◊ f. It means that from any point in an execution, there is always a future point when f holds. That is equivalent to saying that f holds infinitely often. Another common idiom is ◊□f, which says that eventually f holds and remains true. That is equivalent to the stabilization property mentioned in Section 2.5.

Exercise 6.5.   Write LTL formulas that capture the following traffic light properties. Use the atomic propositions r, y, and g, which correspond to the red, yellow, and green lights’ being on:

(a) Exactly one light is on at any given time step.

(b) Eventually, the green light turns on.

(c) Always, the green light eventually turns on.

(d) After red, there are at least three time steps of yellow, and then the light turns green.

Exercise 6.6.   Prove the following identities:

(a) ◊◊ f ≡ ◊ f.

(b) □□ f ≡ □ f.

(c) ¬X f ≡ X ¬f.

(d) ¬◊ f ≡ □ ¬f.

(e) ¬□ f ≡ ◊ ¬f.

(f) f₁Uf₂ ≡ f₂ ∨ (f₁ ∧ X(f₁Uf₂)).

(g) ◊f₁ ≡ ◊f₁ ∨ X ◊f₁.

(h) X(f₁Uf₂) ≡ (X f₁)U(X f₂).

(i) ◊(f₁ ∨ f₂) ≡ ◊f₁ ∨◊f₂.

(j) □(f₁ ∧ f₂) ≡ □f₁ ∧□f₂.

Exercise 6.7.   Give counterexample automata for the following identities:

(a) ◊(f₁ ∧ f₂) ⁄ ≡ ◊f₁ ∧◊f₂.

(b) □(f₁ ∨ f₂) ⁄ ≡ □f₁ ∨□f₂.

Semantics of LTL for discrete and hybrid automata   A given automaton 𝒜 satisfies an LTL formula if all execution fragments starting from every starting state Θ of 𝒜 match the properties prescribed by the formula. That is, 𝒜 f iff ∀ v₀ ∈ Θ, v₀ f. For the automaton in Figure 6.2, for f₁:= ◊□c, 𝒜 f₁, and for f₂:= ◊□b, 𝒜 f₂. In general, 𝒜 f is not equivalent to 𝒜 ¬f, because it is possible that some executions of 𝒜 satisfy f and others do not.

This definition of the semantics of LTL can be applied, with a couple of modifications, to hybrid automata. First, the role of atomic propositions is taken by state predicates. Given a hybrid automaton 𝒜 = (V, Θ, A, 𝒟, 𝒯 ), let P₁, …, Pk ⊆ val(V) be a set of predicates. Then, a state v ∈ val(V) is labeled Pi if v ∈ Pi. Second, an execution α of 𝒜 evolves over dense time, and there is no notion of a next step or ith step, as is needed in the previous definition of LTL semantics. The workaround is to sample α (Plaku et al., 2009; Cimatti et al., 2014). Given an infinite, diverging, and sampling time sequence t₀, t₁, … and an open execution α, we can define α[i] = α(ti). Using that sampled version of α, we can define α f much as it is defined for discrete automata.

6.5  Computational tree logic

LTL gives us a way to talk about linear or sequential requirements that must hold in every execution of a system. In contrast, CTL allows us to describe the requirements of computational trees. For example, we can state properties like “There is an execution along which the aircraft returns to the safe holding zone.”

6.5.1  Computational tree logic syntax

CTL has five temporal operators: Next (X), Eventually (F), Always (G), Until (U), and Release (R). In addition, it has two path quantifiers: the Existential quantifier (E) and the Universal quantifier (A). There are two types of formulas in CTL: state formulas are evaluated at a state, and path formulas are evaluated along state sequences (executions or paths). The syntax for state and path formulas is given as follows:

where p ∈ AP is an atomic proposition, f₁, f₂ are state formulas, and ϕ, ϕ₁ are path formulas. Additional logical operators, like ⇒, ⇔, and xor, can be expressed in terms of ¬ and ∧ to connect CTL state formulas. The depth of a CTL formula is the number of production rules used in creating it. Some examples of valid CTL formulas and their depths include EX p (depth 3), AX(EX p) (depth 5), and (AX(EX p))Uq (depth 6). Note that AXXf, AEX f, and (pU q)Up are not CTL formulas. The temporal operators must alternate with the path quantifiers in valid formulas. In other words, any occurrence of operators U and X is associated with E or A, and vice versa.

6.5.2  Computational tree logic semantics

As in the case of LTL, the semantics of CTL is defined in the context of sequences of labeled states, such as executions of an automaton 𝒜. Given a state v and a CTL state formula f, we write v f if and only if v satisfies f. Similarly, given a sequence of states α and a CTL path formula ϕ, we write α ϕ if and only if α satisfies ϕ. The satisfaction relation for state formulas is defined inductively as follows:

The satisfaction relation for path formulas is defined as follows:

As in the case of LTL, there is a minimal set of operators that is adequate for expressing any CTL formula. Specifically, any CTL formula f can be translated into a semantically equivalent formula f′ that uses only the E quantifier and the temporal operators X and U.

Exercise 6.8.   Convert the following CTL formulas to equivalent formulas that use only E, X, and U: AX f₁, AF f₁, AG f₁, Af₁ U f₂, EF f₁, EG f₁.

Exercise 6.9.   Define the finite state machine (i.e., Kripke structure) that satisfies each of these CTL formulas: AG f₁, AF f₁, EG f₁, and EF f₁.

6.5.3  Expressiveness of linear temporal logic and computational tree logic

Both CTL and LTL are languages for specifying the ordering of actions and predicates. It is natural to ask: Which is more expressive? For any LTL formula f₁, does there exist a corresponding CTL formula that defines the same set of executions? Similarly, can any CTL formula be expressed as an LTL formula? It is easy to see that the answer to the last question is no. There is no LTL counterpart to the CTL formula EF f₁ because LTL does not allow path quantifiers. Exercise 6.10 shows that there are LTL formulas that cannot be expressed in CTL.

Exercise 6.10.   Consider the finite state labeled transition system 𝒜 defined as follows: (a) val(V) = {q₀, q₁, q₂}, (b) Θ = {q₀}, (c) Lab(q₀) = Lab(q₂) = p, Lab(q₁) = ¬p, (d) 𝒟 = {(q₀, q₀), (q₀, q₁), (q₁, q₂), (q₂, q₂)}. Show that the LTL formula FG p is satisfied by all executions of 𝒜. Is there a corresponding CTL formula that is satisfied by executions of 𝒜? Note that AFG p is not a CTL formula; how about AFAG p?

From this discussion, it follows that the expressive powers of LTL and CTL are incomparable. There is a temporal logic called CTL* that freely combines temporal operators and path quantifiers, and therefore has as much expressive power as both CTL and LTL.

6.6  Further reading

6.6.1  Checking temporal logic models

Given an LTL formula f, checking whether [[f]] = ∅ is called the LTL satisfiability problem. It is PSPACE-complete in the size of the formula f. Given an automaton 𝒜 and an LTL formula f, we would like to check whether 𝒜 f. That is the LTL model-checking problem. To answer it, we check whether there is an execution α ∈ Execs𝒜 that satisfies ¬f. Thus, it suffices to be able to search for a path or execution that satisfies the negation of an LTL formula g. The original LTL model-checking algorithm of Lichtenstein and Pnueli (2000) uses the so-called tableau construction. The problem is PSPACE-complete (the proof is quite technical), but one can easily show NP-hardness by reducing the Hamiltonian path problem to an LTL formula. Although the complexity is exponential in the size of the formula |g|, it is linear in |𝒟|, the size of the transition system. For detailed exploration of those ideas, see Clarke et al. (1999) and Baier and Katoen (2008). Checking of temporal logic models is now part of several academic and commercial tools, such as NuSMV (Cimatti et al., 1999), SPIN (Holzmann, 1997), and LTSmin (Kant et al., 2015). These tools have been used successfully to verify a range of significant practical applications, from high-level descriptions of distributed algorithms and cache coherence protocols to detailed code used for telephone exchanges, railway interlocking systems, and aircraft collision avoidance systems.

6.6.2  Planning and synthesis with temporal logics

LTL and CTL have been extensively used to specify requirements for the controller synthesis problem for cyber-physical and robotic systems (recall Definition 3.6 in Chapter 3). The problem, as formulated by Kress-Gazit et al. (2009), is as follows: given (1) an LTL specification for the tasks of an agent (ψs), (2) a model of the agent’s movements and actions, and (3) a temporal logic specification of how the environment reacts to the agent’s actions (ψe), construct (if possible) a controller so that the agent’s resulting trajectories and actions satisfy the specification (ψs) in any environment that satisfies ψe from any possible initial state. A standard synthesis approach for this problem is based on first discretizing the environment of the agent.

Constructing a discrete controller or an automaton that meets an LTL specification is a well-studied problem in computer science; Pnueli and Rosner (1989) show that generally the problem is doubly exponential in the size of the formula. However, by restricting the specification to a special subclass of LTL called generalized reactivity GR(1), one can use the algorithm of Piterman et al. (2006), which is polynomial in the size of the state space. Kress-Gazit et al. (2009) take this approach to this synthesis problem and use low-level, continuous state space controllers to implement the discrete transitions coming from Piterman et al. (2006). To gain computational tractability, variants of this approach exploiting specific properties of the environment, such as planarity, restricted types of dynamics, and restricted types of specifications, have been developed by a number of researchers, including Kloetzer and Belta (2008); Tabuada (2008); Sadraddini and Belta (2019); Wongpiromsarn et al. (2011); and Raman et al. (2015).

6.6.3  Dense time, signal, and stochastic temporal logics

There are several variants of temporal logics and corresponding verification algorithms. Timed CTL (TCTL) adds a timed until operator, clock variables, and clock constraints in formulas, thus enabling reasoning about clocks and dense time in timed automata. TCTL is the logic of choice for the UPPAAL model-checking tool (Bengtsson et al., 1996). Metric temporal logic (MTL) is a linear logic in which the modalities of LTL are augmented with timing constraints (Koymans, 1990). For example, in MTL, □(walkButton (◊(0, 10)lightRed)) means that lightRed will become true sometime in the next 10 time units when walkButton holds. The verification problem for timed automata with respect to MTL requirements has been shown to be undecidable (Alur et al., 1996). That led to the creation of metric interval temporal logic (MITL) (Alur et al., 1996); it forbids singleton or punctual intervals (e.g., ◊{10}), which are allowed in MTL.

Signal temporal logic (STL), introduced by Maler and Nickovic (2004), extends MTL further to include real-valued constraints. For example, the STL formula

allows the numerical predicate x[t] < 5.5 to play the role of atomic propositions. That generalization of the syntax has led several researchers to consider more continuous or quantitative semantics for temporal logics (Donzé and Maler, 2010; Fainekos and Pappas, 2009). That is, instead of interpreting formulas to be merely true or false, we can consider how far a formula is from being true. For example, the Boolean satisfaction of the inequality x[t] ≤ 5.5 does not distinguish between x = 5.5 + ε and x ≫ 5.5; both are classified as false. Similarly, we cannot distinguish between marginal satisfaction by x = c−ε and a more robust satisfaction by x ≪ c.

The broad idea is to associate a real number, often called the robustness degree, with a requirement-behavior pair (R, α) that measures the distance between α and the set [[R]] of all behaviors that satisfy R. The robustness degree is positive when α is deeper inside [[R]], and more negative the farther α is from [[R]]. Donzé and Maler (2010) present an efficient dense-time algorithm for computing these measures for piecewise-linear signals and for computing the sensitivity of the measures to parameter variations.

Along a different axis, probabilistic CTL (PCTL) (Hansson and Jonsson, 1994) and continuous stochastic logic (CSL) (Aziz et al., 2000) add probabilistic operators on top of temporal logics; both have been used for analyzing the performance and reliability of systems. For example, the PCTL formula P≥0.5(walkButton (◊(0, 10)lightRed)) means that with a probability of at least 0.5, lightRed turns on within 10 time units of walkButton. The time domain for PCTL is ℕ, and that for CSL is ℝ≥0. The stochastic analog of the verification problem has to decide, given a PCTL (or CSL) formula f that describes the requirement and a probabilistic model 𝒜 (such as a Markov chain or a Markov decision process), whether the model 𝒜 satisfies the property f.

There are two main approaches to solving the problem: numerical and statistical. In the numerical approach, symbolic and numerical methods are used to check the formal model 𝒜 for correctness with respect to f. The statistical approach is based on Monte Carlo simulation of the model and performance of sequential hypothesis testing on the generated samples (Younes and Simmons, 2002; Sen et al., 2005a). Each of those approaches has been implemented in several tools (Hermanns et al., 2000; Hinton et al., 2006; Sen et al., 2005b).

6.6.4  Runtime verification and monitoring

Verification algorithms may also be used for monitoring cyber-physical systems (Bartocci and Falcone, 2018; Sistla et al., 2011; Duggirala et al., 2014). The problem setup here is for the monitoring algorithm to execute concurrently with the actual implementation of the cyber-physical system: it takes as input estimates of the current state of the system, and has to detect or raise an alarm some time before the requirement is violated. This online version of the verification problem is referred to as runtime verification or monitoring.

For this use case, the verification algorithm runs periodically (such as every δ seconds) on the system being analyzed. At time t, the algorithm takes as input the system model 𝒜 and the current state estimate Θt ⊆ val(V), and decides whether the requirements will be violated by any of the executions starting from Θt in the future until some lookahead time bound of T seconds. For the analysis to be actionable, δ must be much smaller than T. For an automotive application, the lookahead time bound T may be 6 seconds, and the period of computation δ may be 10 to 100 milliseconds. For nondeterministic models with large errors in state estimation (Θt), the verification algorithms may have to check large sets of executions in a short amount of time. A survey of requirements-based monitoring techniques is presented by Bartocci et al. (2018).

6.7  Exercises

Exercise 6.11.   Consider the SLPlatoon automaton of Section 5.9 in Chapter 5, modeling a platoon of three vehicles on the highway. Define appropriate atomic propositions using the variables of SLPlatoon and express the following requirements in CTL:

(a) “All vehicles always maintain a separation of at least dmin, and at most dmax.”

(b) “If Car1 brakes, then the other cars also eventually brake.”

(c) “If any car goes from cruising to braking, then it must pass through reacting mode in between.”

Exercise 6.12.   Five philosophers are sitting around a table, taking turns thinking and eating. Let us assume that the system has the following atomic propositions: ei, philosopher i is currently eating, and fi, philosopher i just finished eating. Express the following properties of the system in CTL using only the EU, EX, and EF operators. Start by using any operator to write the property, and then convert.

(a) “Philosophers 1 and 4 never eat at the same time.”

(b) “If philosopher 4 has finished eating, she cannot eat again until philosopher 3 has begun eating.”

(c) “Philosopher 2 will be the first to eat.”

¹Real-time extensions of temporal logics, such as metric temporal logic (Koymans, 1990), are not covered in this book.

7

Verifying Invariants

Overview

Invariants capture some of the most fundamental and commonly occurring requirements for cyber-physical systems. Roughly, an invariant I for a system 𝒜 is a requirement that always holds (i.e., I is never violated in any execution of 𝒜). In this chapter, we will discuss powerful techniques for verifying the invariant properties of general hybrid automata. These proof techniques can be used for manual proofs, partially mechanized proofs, or fully automatic verification, depending on how the individual steps are implemented. We will discuss the relationship between invariance, composition, and barrier certificates and study example applications (namely, the analysis of mutual exclusion in Fischer’s timing-based distributed protocol and the safety analysis of a rotorcraft). Next, we will present a brief introduction to the propositional satisfiability (SAT) problem and discuss how reachability and inductive invariance checking can be automated using satisfiability modulo theory (SMT) solvers. All these approaches rely on knowing an invariant with the desired inductive structure. We conclude the chapter by discussing methods for automatically finding such invariants from template-based search and execution data.

7.1  Quick introduction to proving invariants

Recall from Section 6.3.3 in Chapter 6 that for a hybrid automaton 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩ with a set of variables V and state space val(V), an invariant I is a subset of val(V) such that all the reachable states of 𝒜 are contained in I. That is, no execution of 𝒜 can violate I. That can be written as Reach𝒜 ⊆ I. An invariant is typically expressed as a predicate over V. How can we prove that a given predicate I is truly an invariant for 𝒜? That is the invariant verification problem.

One direct approach is to compute the set of reachable states Reach𝒜 and check that it is contained in I. Indeed, Reach𝒜 can be computed—or at least we can overapproximate a bounded-time reachable set Reach𝒜(Θ, T) for certain classes of hybrid automata 𝒜—and therefore this strategy can be used for automatically proving invariants or bounded-time invariants for those classes. We will explore this approach in Chapters 9 and 11.

In the case that direct computation of Reach𝒜 is impossible or impractical, how can we verify that I is an invariant of 𝒜? Obviously, the starting states of Θ should be contained in I. But that alone is not enough, because starting from Θ ⊆ I, 𝒜 can visit states outside I through discrete transitions and trajectories. What if we can find a set I′⊆ I such that starting from I′, every transition and trajectory of 𝒜 stays within I′? (That is, I′ is closed under 𝒟 and 𝒯.) It can be shown easily that if such an I′ also contains the initial states, then I′ is an invariant of 𝒜. Furthermore, because I′⊆ I, it is a stronger invariant than I and implies invariance of I. We will now state these arguments more precisely in terms of general hybrid I/O automata (HIOA).

Definition 7.1.   Let 𝒜 be an HIOA with the set of internal variables X. A predicate I on X is an inductive property of 𝒜 if (a) for any transition in 𝒟, if x ∈ I then x′∈ I; and (b) for any trajectory τ ∈𝒯, if τ.fstate ∈ I then τ.lstate ∈ I.

It can be shown by induction on the length of an execution of 𝒜 that any execution that starts from I stays in I. An inductive property that is satisfied by all starting states of 𝒜 is an invariant called an inductive invariant.

Theorem 7.1.   Given an HIOA 𝒜, if a set of states I ⊆ val(X) satisfies the following:

(a) (Start condition) For any starting state x ∈ Θ, x ∈ I, and

(b) (Transition closure) for any action a ∈ A, if and x ∈ I then x′∈ I, and

(c) (Trajectory closure) for any trajectory τ ∈ 𝒯, if τ.fstate ∈ I then τ.lstate ∈ I,

then I is an inductive invariant of 𝒜.

Proof. It suffices to show that Reach𝒜 ⊆ I. Consider any reachable state x ∈Reach𝒜. By the definition of a reachable state, there is an execution α of 𝒜 such that α.lstate = x. We proceed by induction on the length of the execution α. For the base case, α consists of a single starting state x ∈ Θ, and, by the start condition, x ∈ I. For the inductive step, we consider two subcases:

Case 1: α = α′a x, where a is an action of 𝒜. By the induction hypothesis, we know that α′.lstate ∈ I. By invoking the transition closure, we obtain x ∈ I.

Case 2: α = α′τ, where τ is a trajectory of 𝒜 and τ.lstate = x. By the induction hypothesis, α′.lstate ∈ I, and by invoking the trajectory closure, we deduce that τ.lstate = x ∈ I.

The transition and trajectory closure conditions of Theorem 7.1 together imply that I is an inductive property or set for 𝒜. Inductive invariants are powerful because they allow us to prove a global property about executions of 𝒜 by checking the local trajectory and transition conditions. To apply Theorem 7.1, these conditions are typically checked on a case-by-case basis through consideration of the types of actions and modes of the hybrid automaton 𝒜. For models with uncountably many transitions and trajectories, those checks can often be performed symbolically on a finite set to cover all of 𝒟 and 𝒯.

To summarize the overall approach for proving an invariant I for an automaton 𝒜, the first step will be to find an inductive invariant I′ for 𝒜, and the second step will be to show that I′⇒ I. For models that involve nonlinearities, hybrid switches, delays, or parameters, finding an inductive invariant I′ completely automatically can be challenging. In practice, this step involves trial and error based on insights about the system’s behavior. For restricted classes of models, the search can be automated, and we will mention some techniques in Section 7.6.1. Once a candidate inductive invariant I′ has been found, we can use Theorem 7.1 to verify it.

Exercise 7.1.   Show that Theorem 7.1 without the trajectory closure condition gives a corollary for proving inductive invariants for automata or labeled transition systems (Definition 2.1 in Chapter 2). Use this corollary to show that ϕlegal is an invariant for DijkstraTR of Section 2.5.

Floyd-Hoare logic   The core idea of inductive invariants dates to the classical program analysis technique called Floyd-Hoare style verification (Floyd, 1967; Hoare, 1969). Hoare logic, also known as Floyd-Hoare logic or Hoare rules, provides a set of logical rules for rigorously deducing the correctness of automata, labeled transition systems, or programs. The logic is built on the notion of a Hoare triple, which describes how the execution of a statement (or line of code) changes the state of the automaton. A Hoare triple takes the form {P}c{Q}, where {P} and {Q} are predicates on the program variables and are called the precondition and postcondition; c is a statement describing program variable change. Overall, the triple implies that when the precondition P is met, execution of c establishes the postcondition Q. Hoare logic and its many successors provide axioms and inference rules that various programming language constructs can use to infer properties from the triples. The preconditions and effects in our automaton specification language can be seen as the pre-post conditions for a single transition.

7.2  Reasoning with inductive invariants

In this section, we discuss several aspects of invariants and inductive invariants.

Proposition 7.2.   Not all invariants are inductive invariants.

Consider the familiar hybrid automaton Ball, modeling a bouncing ball (shown in Figure 7.1). The ball drops under gravity (g) from an initial height of x = h, and bounces on the floor (x = 0) with coefficient of restitution c < 1. Suppose that we are interested in proving the obvious property of the ball—namely, that its height stays within the interval [0, h]. Clearly,

Figure 7.1
A bouncing ball.

is an invariant of Ball, but I₁ is not an inductive invariant. To see that, consider any trajectory τ starting from I₁. Although τ.fstate ∈ I₁ (i.e., 0 ≤ τ.fstate ⌈ x ≤ h), this does not imply that τ.lstate ⌈ x ≤ h because the initial velocity of the ball at τ.fstate is unconstrained and may be positive.

In contrast, we can easily check that the predicate

is an inductive invariant, but doing so is not that useful. To prove I₁, we have to find an inductive invariant that captures adequate velocity information. With some calculation using Newton’s laws of motion and by introducing an auxiliary variable k that counts the number of bounces, we can find a more complicated invariant that relates the velocity to the height and the number of bounces:

Exercise 7.2.   Use Theorem 7.1 to show that I₂ is an inductive invariant for Ball. Next, show that I₁ ∧ I₂ is also an inductive invariant.

This example illustrates the general principle of adding constraints to a candidate invariant until it becomes inductive. That is called strengthening. We started with I₁, which was not inductive; then, we found an inductive invariant I₂, and finally proved the strengthened invariant I₁ ∧ I₂, which implies I₂.

Exercise 7.3.   For the RimlessWheel hybrid automaton of Figure 4.2 in Chapter 4, show that − β/2 ≤ θ ≤ β/2 is an inductive invariant.

Exercise 7.4.   Consider a simple version of the SLPlatoon(RT, d₀, ds, a) automaton from Section 5.9 in Chapter 5. Fix the number of vehicles n, and take the braking profile a of each vehicle to be a constant negative acceleration a₀ < 0. Derive conditions on n, a₀, RT, d₀, and ds under which we can prove that the vehicles never collide. The collision-free property can be stated as the candidate invariant I = ∀ i ∈ ID, xi−1 − xi > 0. To use Theorem 7.1, you will have to find stronger inductive invariants that imply I.

7.2.1  Invariance and composition

The result of Lemma 7.3 states that the invariant of a component automaton 𝒜₁ carries over to any larger model of which it is a part, and therefore enables us to infer invariant properties of larger systems by analyzing the system’s components.

Lemma 7.3.   Suppose that 𝒜₁ and 𝒜₂ are compatible HIOAs. If I is an invariant for 𝒜₁, then I × val(X₂) is an invariant for 𝒜₁||𝒜₂.

Proof. First, we show that Reach𝒜₁||𝒜₂ ⌈ X₁ ⊆ Reach𝒜₁. Fix a state x ∈ Reach𝒜₁||𝒜₂ ⌈ X₁. We know that there is a closed execution α of 𝒜₁||𝒜₂ such that α.lstate = x. From Lemma 5.5 (in Chapter 5), α ⌈ (A₁, V₁) is an execution of 𝒜₁. Further, α.lstate ⌈ X₁ = (α ⌈ (A₁, V₁)).lstate, which is a reachable state of 𝒜₁. Thus, Reach𝒜₁||𝒜₂ ⌈ X₁ ⊆ Reach𝒜₁. Because I is an invariant for 𝒜₁, Reach𝒜₁ ⊆ I, and therefore, Reach𝒜₁||𝒜₂ ⌈ X₁ ⊆ I. As I is independent of the variables of 𝒜₂, it follows that Reach𝒜₁||𝒜₂ ⊆ I × Q₂. That is, I × Q₂ is an invariant of the composed automaton 𝒜₁||𝒜₂.

7.3  Proving timing-based mutual exclusion

In this section, we will study a detailed application of inductive reasoning to establish the correctness of a distributed mutual exclusion algorithm.

7.3.1  Example: Fischer’s mutual exclusion

Mutual exclusion is one of the basic primitives in distributed computing. It allows n processes to coordinate and access a critical resource exclusively. That is, no two processes have simultaneous access, and all requesting processes eventually gain access.

Fischer’s timing-based protocol (Peterson and Fischer, 1977) for solving the mutual exclusion problem is shown in Figure 7.2. Each process i participating in this protocol has an internal stopwatch (timeri), and the processes use a single shared memory g. The stopwatches may be inaccurate and drifting. The shared variable g is an atomic read/write memory in which process identifiers can be stored. The detailed specification is given in Figure 7.3. The participating processes go through a sequence of phases—sleeping, trying, waiting, and finally critical—to access the resource. The system model here is a composition of a collection of hybrid automata, Fischeri, i ∈{1, …, n}, and the discrete variable g is of type {⊥, 1, 2, …, n}.

Figure 7.2
Fischer’s timing-based mutual exclusion protocol.

Figure 7.3
A hybrid automaton model of a process participating in Fischer’s mutual exclusion protocol.

Next, we will highlight some of the key points of Fischeri. The parameter ρ ∈ (0, 1) is the maximum drift rate of the clocks of the individual processes; parameters a and b play a crucial role in ensuring mutual exclusion, as we shall see in Section 7.3.2. There are two internal variables: pci is the program counter, which keeps track of the phase that the i is in, and timeri is the stopwatch. The pci variable is analogous to the loc variable in simple hybrid automata, and the phases of Fischer correspond to the modes or locations. The Fischeri has four internal actions—wakei, tryi, enteri, and exiti—that define the rules for moving from one phase to the next. For example, i moves from sleeping to trying only if the global variable g is ⊥, and when it does so, timeri is reset; otherwise, a wakei transition does not alter the state of the system. Within a time units (as measured by timeri) of entering trying, Fischeri may perform a tryi transition to move to waiting, and then it sets g to i and timeri to zero. Notice that Fischeri is only allowed to read from or write to g atomically, and therefore, we cannot model both in a single transition. Fischeri can move from waiting to critical anytime after time has elapsed, and only if g = i; otherwise, it heads back to sleeping and resets the timer. Once the critical resource has been accessed, Fischeri performs exiti to leave the critical phase and resets g to ⊥ and the timer to 0.

When Fischeri is sleeping, the timeri is stopped; in all other phases, it inaccurately tracks time. That is described by the differential inclusions

This dynamics means that for any trajectory ξ of Fischeri, (ξ ↓ timeri) is a continuous function, and at any time t,

Compare that with Equation (3.15) in Chapter 3, which defined trajectories as solutions of differential equations. Going forward, we will fix the parameters n, ρ, a, and b. Let 𝒜 = Fischer₁∥…∥Fischern be the composed hybrid automaton. Thus, 𝒜 describes a distributed cyber-physical system that has n concurrent processes, each with its own drifting clock, and that communicate through shared memory. Observe that 𝒜 has nondeterminism arising from the choices both in discrete transitions and in the trajectories of the drifting clocks. In the next section, we will use the approach of inductive invariants (Theorem 7.1) and inductive strengthening to establish the key safety property of 𝒜.

7.3.2  Analysis of Fischer’s mutual exclusion

Recall that for a state x ∈ val(X) of 𝒜 and an index i ∈ [n], x ⌈ pci denotes the valuation of the program counter for process i at x, x ⌈ timeri denotes the valuation of process i’s timer, and x ⌈ g is the valuation of the shared variable.

Our ultimate goal is to establish the safety requirement for 𝒜 that no two processes enter the critical section simultaneously. That can be stated as follows:

That invariant is not inductive and cannot be proved directly using Theorem 7.1. Therefore, we will proceed by establishing a sequence of simpler invariants that are inductive. We begin stating an assumption about the parameters of the algorithm and the accuracy of the timer.

Assumption 7.1.   We assume that b > a and ρ ∈ (0, 1).

This first invariant simply states that for any process i, the timer is always nonnegative and stays at 0 when the process is sleeping.

Invariant 7.1.   For all i ∈ [n], if pci = sleeping, then timeri = 0; otherwise timeri ≥ 0.

Proof. We easily check the invariant by applying Theorem 7.1. We fix the process i as follows:

(Start condition) For any start state x of 𝒜, notice that timeri is initialized to 0 in the Fischer automaton of Figure 7.3. Therefore, x ⌈ timeri = 0.

(Transition condition) Consider any transition of the automaton 𝒜. From the specification of the transition relation (the eff part of each transition), we see that for any action a, timeri is either reset to 0 or left unchanged. In either case, x′⌈ timeri ≥ 0. For the case a = exiti, which is the only action that makes x′⌈ pci = sleeping, timeri is reset to 0, and therefore the invariant is preserved.

(Trajectory condition) Consider any closed trajectory τ of automaton 𝒜 with τ.ltime = t. There are two cases to consider:

Case τ.fstate ⌈ pc ≠ sleeping. Because pci remains constant, τ.lstate ⌈ pci ≠ sleeping. Finally, from the differential inequality, it follows that

Because τ.fstate ⌈ timeri ≥ 0, the invariant holds at τ.lstate.

Case τ.fstate ⌈ pc = sleeping. The invariant of this mode implies that τ.fstate ⌈ pci = τ.lstate ⌈ pci = sleeping. From the differential equation d(timeri) = 0, it follows that τ.lstate ⌈ timeri = τ.fstate ⌈ timeri = 0.

The next invariant asserts a precise relationship regarding the gap between the timer values of two processes i and j that are attempting to access the critical section, where i is waiting and j is trying. We complete the proof by using Theorem 7.1 on the specification of Fischer, but now we can use the additional fact that Invariant 7.1 is satisfied by all reachable states of 𝒜.

Invariant 7.2.   For all i, j ∈ [n], pci = waiting ∧ pcj = trying ∧ g = i implies

Proof. We fix processes i and j as follows:

(Start condition) Because pci = pcj = sleeping in all initial states, the start condition holds vacuously.

(Transition condition) Consider any transition such that x is reachable. If we fix the prestate x and the poststate x′ of the transition and assume that x satisfies Invariant 7.2, we can perform a case analysis on the action a. The only nontrivial actions are tryi and wakej:

Case x x′. From the reset map (eff) of tryi, we know that x′⌈ timeri = 0. Because x′ is a reachable state, it must satisfy 7.1. Instantiating i in Invariant 7.1 with j, we have x′ ⌈ timerj ≥ 0. Thus, . The inequality is strict, as b > a.

Case x x′. From the precondition (pre) of wakej, we know that x ⌈ timerj = sleeping. Because x is a reachable state, it satisfies Invariant 7.1, and it follows that x ⌈ timerj = 0. Because x satisfies Invariant 7.2 and timeri does not change its value, it follows that x′ also satisfies Invariant 7.2.

(Trajectory condition) We fix a closed trajectory τ of 𝒜. Let the first state and the last state of τ be x and x′ and τ.ltime be t. We get to assume that x satisfies the invariant, and consider different modes and valuations of discrete variables to establish that x′ also satisfies the invariant. The only nontrivial scenario is when neither process is in sleeping mode, and pcj = trying and pci = waiting. From the differential inequalities we have:

We can bound the difference in the timer values at x′ as:

The second strict inequality is obtained by applying Invariant 7.2 to the first state x of the trajectory τ. The last inequality is obtained by rewriting t with the upper bound given by Equation (7.3).

The next invariant brings us near to our goal. It asserts that if process i is already in the critical section, then g = i, and no other process could be trying. Following the same pattern, we complete the proof by using Theorem 7.1 and the previously proved invariants.

Invariant 7.3.   For all i, j ∈ [n], pci = critical implies pcj ≠ trying ∧ g = i.

Proof. We prove the invariant using Theorem 7.1. We fix processes i and j.

(Start condition) Because pci = pcj = sleeping in all initial states, the start condition holds vacuously.

(Transition condition) The only interesting transition is x x′ because for all other actions, x′⌈ pci ≠ critical and x′ satisfies Invariant 7.3 vacuously. We consider the transition x x′, for which x is a reachable state of 𝒜 and x satisfies the precondition of enteri. From the eff of enteri, it follows that x ⌈ g = i, and therefore, x′ ⌈ g = i. Also, x ⌈ pci = waiting. We suppose that x′⌈ pcj = trying, and we will show that x ⌈ timeri is strictly less than , which contradicts our assumption that enteri is enabled at x.

Because x is a reachable state, from Invariant 7.2, it follows that

From the invariant of the timing mode, we know that x ⌈ timerj ≤ a. Thus, this inequality becomes

(Trajectory condition) This holds trivially because all the variables involved in the invariant remain constant over trajectories.

Finally, with the benefit of Invariants 7.1–7.3, we are ready to prove the target safety property using Theorem 7.1:

Invariant 7.4.   For all i, j ∈ [n], i ≠ j ∧ pci = critical implies that pcj ≠ critical.

Proof. We fix processes i and j as follows:

(Start condition) This holds vacuously.

(Transition condition) Consider any transition , such that x is reachable and x ⌈ pci = critical. Because x is reachable, it satisfies Invariant 7.3, and therefore, x ⌈ pcj ≠ trying and x ⌈ g = i. The only possible transition that can violate the invariant is . However, because x ⌈ g = i, from the eff of enterj, it follows that x′⌈ pcj = sleeping.

(Trajectory condition) This holds trivially.

To summarize, this case study shows (1) how a distributed cyber-physical system with drifting clocks and shared memory can be modeled using composition, and (2) how inductive invariants and Theorem 7.1 can be effective in proving nontrivial safety properties. The proof steps (namely, checking of the start condition, transition condition, and trajectory condition) given here can be mechanized and automated using theorem provers (Lim et al., 2005; Mitra and Chandy, 2008; Owre et al., 1996). One barrier to completely automatic application of Theorem 7.1 is the strengthening step, which required us to develop some understanding of how the protocol works and encode that into increasingly strong inductive invariants. Another barrier is the need for explicit trajectories for checking the trajectory condition in Theorem 7.1. In the next section, we will present techniques for overcoming that second barrier. In Section 7.6, we will discuss the approaches available for automatic strengthening.

7.4  Proving inductive invariants without solving ordinary differential equations

The applicability of Theorem 7.1 is limited by the fact that the trajectory condition can be checked only if we have an explicit, closed-form analytical description of the trajectory. Specifically, we need an expression for τ.lstate in terms of τ.fstate and τ.dur. If the trajectories are implicitly defined using differential equations, then that may not be possible. A common theme in the analysis of dynamical and hybrid systems is avoidance of this difficult step: whenever possible, we will seek analysis methods that can be applied without requiring explicit, closed-form solutions of differential equations.

A natural idea is to look at the boundary of the invariant set I (or some set contained in I) and prove that the trajectories cannot escape or penetrate the boundary. This condition can be stated in terms of the relationship between the boundary and the dynamic function (i.e., the vector field) at the boundary without relying on solutions of the vector field. Lemma 7.4 gives a sufficient condition for checking the trajectory condition of Theorem 7.1 without requiring explicit solutions.

Lemma 7.4.   Consider the ordinary differential equation (ODE) for state variable x. Let I ⊆ val(x) be a compact set containing the initial set Θ. Then, I is an inductive invariant of this ODE if at every state x on the boundary of I, the vector f(x) is pointing inward from the boundary.

If the boundary is given as a curve F(x) = 0, then the “pointing-inward” requirement, called the subtangential condition, can be written as . This boundary is also called a barrier. Applying this condition requires us to compute the partial derivative of the boundary curve F, and the dot product of the resulting vector with the vector field defined by f. It does not involve solutions of the ODE.

7.4.1  Example: Checking subtangential conditions

Lemma 7.4 was used to verify several complex cyber-physical systems, including a tabletop helicopter arm, in Mitra et al. (2003). Here, we present an excerpt of that analysis to illustrate the method. The pitch dynamics of the helicopter system is given by the following differential equations:

where θ is the pitch angle, ω is the pitch velocity, and u is the control thrust input given to the helicopter. The key safety requirement for this system is that the pitch angle θ does not cross certain hard limits: namely, − θmin ≤ θ ≤ θmax, where are the hard limits. To prove that invariant, first a boundary F is constructed as shown in Figure 7.4. Notice that the region defined by F implies the given safety requirement. Also, the initial state (θ = 0, ω = 0) is inside the region defined by F. Here, the boundary has four pieces defined by four functions F₁, …, F₄, and we have to check the subtangential condition relative to each of them.

Figure 7.4
An invariant set for the helicopter model. The tangent (gray), the normal (dashed gray) and the subtangential vector field (gray arrow) are shown for a particular point p on the boundary of the invariant.

To check the trajectory condition, we check that Equation (7.7) meets the subtangential condition of Lemma 7.4. First, consider any state x on the F₁ boundary with x ⌈ ω > 0. Clearly, the right side of the differential equation for θ is positive, and therefore the vector field at x points inward. Similarly, for any state x on the F₃ boundary with x ⌈ ω < 0, is negative, and the vector field points inward. Assuming that the control input u > Ω² and u < −Ω² at the pitch values θ = −θmin and θ = θmax, respectively, it follows that the vector field points up and down at (−θmin, 0) and (θmax, 0), respectively. Thus, all points on F₁ and F₃ meet the subtangential condition. Next, to check the subtangential condition at F₂, we write the boundary as a vector-valued parameterized curve:

The tangent vector at x is obtained by computing , and the inner normal vector is . The subtangential condition then amounts to checking that the scalar product of the normal and the vector field is positive along the boundary:

Again assuming u > Ω², and because ω > 0 and θmax > θ, the right side is positive, and the subtangential condition is met. The check for the F₄ boundary can be done in a similar way.

For a hybrid automaton model, the subtangential condition has to be checked relative to all the modes of the system. In the next section, we state a general condition for checking safety relative to an unsafe set, for hybrid systems in which each mode comes with its own barrier certificate (Prajna and Jadbabaie, 2004).

7.4.2  Barrier certificates

Barrier certificates can be used to construct safety proofs relative to an unsafe set U. They can be seen as a potent combination of the inductive proof strategy of Theorem 7.1 and the solution-free trajectory condition–checking of Lemma 7.4. The key idea is to find a barrier function B: val(X) → ℝ whose 0-level set separates the unsafe set U from the reachset (from an initial set Θ).

Recall that a simple hybrid system 𝒜 = (V, Θ, A, 𝒟, 𝒯 ) has a set of variables V = X ∪{loc}, where loc is the special mode (or location) variable with type(loc) = L, and L is the set of locations or modes. Any state v ∈ val(V) has two parts v ⌈ X and v ⌈ loc, which we write as (x, ℓ). Here, we assume that the trajectories in mode ℓ are defined by the differential equation .

The following theorem from Prajna and Jadbabaie (2004) gives the conditions for proving the safety of a hybrid automaton 𝒜 with respect to an unsafe set U. The barrier function is positive over U, nonpositive over Θ, and subtangential to the vector field fℓ of each mode at the boundary. Each mode ℓ ∈ L of a hybrid automaton can have its own piece of the barrier Bℓ. Note that Θℓ {x ∈ Θ | x ⌈ loc = ℓ} is the part of the initial set restricted to mode ℓ.

Observe the similarity between the start and transition conditions in Theorem 7.5 and those in Theorem 7.1. The unsafe condition is new. The trajectory condition is a generalization of Lemma 7.4.

Theorem 7.5.   Let 𝒜 = (V, Θ, A, 𝒟, 𝒯 ) be a simple hybrid automaton with V = X ∪ loc, set of locations L = type(loc), and unsafe set U ⊆ val(V). Suppose that there is a collection {Bℓ(x)} of functions Bℓ: val(X) → ℝ such that for all ℓ ∈ L, Bℓ is differentiable with respect to its argument, and it satisfies:

(a) (Start condition) For any starting state v ∈ Θℓ, Bℓ(x) ≤ 0.

(b) (Unsafe condition) For any unsafe state v ∈ Uℓ, Bℓ(x) > 0.

(c) (Transition condition) For any transition .

(d) (Flow condition) For any state x ∈ Iℓ, on the boundary with Bℓ(x) = 0, .

Then 𝒜 is safe with respect to U (i.e., Reach𝒜∩ U = ∅).

Proof. Fix {Bℓ} to satisfy the conditions given here. It suffices to show inductively that at any reachable state (x, ℓ), Bℓ(x) ≤ 0. Any start state satisfies that by the start condition. Consider any trajectory τ starting from (x, ℓ) with Bℓ(x) ≤ 0, and consider the evolution of Bℓ(τ(t) ⌈ X) along this trajectory. The flow condition implies that Bℓ(τ(t) ⌈ X) cannot become positive. Finally, the transition condition implies that starting from any reachable state (x, ℓ), with Bℓ(x) ≤ 0, no transition of 𝒜 can cross the Bℓ′(x′) = 0 barrier. Thus, the safety of 𝒜 is preserved.

7.5  Satisfiability and satisfiability modulo theories

Satisfiability (SAT) and satisfiability modulo theory (SMT) solvers are powerful engines for building verification tools. In this section, we provide a brief overview and discuss how Theorem 7.1 can be used for automatic invariant checking with these solvers.

7.5.1  Satisfiability

The Boolean SAT problem asks:

SAT. Given a propositional logic formula ϕ over a set of variables X, decide if there is a valuation that satisfies ϕ.

For example, the propositional formula (predicate),

is over the set of variables X = {x₁, x₂, x₃}, and it is constructed with the propositional operators ∨ (or), ∧ (and), and ¬ (not). As usual, a valuation x of X maps each of the variable names to {0, 1}. A valuation satisfies ϕ if x ϕ. (Recall the definition of satisfaction from Section 2.2.2 in Chapter 2.) For ϕ, (x₁ = 0, x₂ = 0, x₃ = 1) is a satisfying solution. In summary, the SAT problem decides whether

The subformulas (x₁ ∨x₂ ∨ ¬x₃) and (¬x₂ ∨x₁) of ϕ are called clauses of ϕ. As in the previous example, the standard version of the SAT problem requires the formula to be represented in the conjunctive normal form (CNF)—that is, as a conjunction of disjunctive clauses. Any propositional formula can be converted to CNF. 3SAT is a subclass of SAT problem, in which each clause has no more than three variables.

A brute-force method for solving the SAT problem is to check ϕ for each possible valuation x ∈ val(X) of X. For a set of n variables, |val(X)| = 2n, and thus, this method requires O(2n) operations. The Cook-Levin theorem (Cook, 1971; Levin, 1973) shows that 3SAT is an NP-complete problem (see Definition B.6 in Appendix B), which means that in theory, we do not know if there is any way of solving SAT that is better than the brute-force method.

Despite the worst-case exponential run time, SAT solvers are now routinely used in verification and design applications. At present, the fastest solvers, like Chaff (Moskewicz et al., 2001), MiniSat (Eén and Sörensson, 2003), and BerkMin (Goldberg and Novikov, 2007), can solve SAT instances with millions of variables and clauses. Most solvers build on the resolution-backtracking algorithm called Davis Putnam Logemann and Loveland (DPLL) (Davis et al., 1962), by including better data structures and improving strategies for backtracking and clause-learning. We will not discuss them further in this book.

7.5.2  Satisfiability modulo theory

An SMT problem is a generalization of SAT in which some of the binary variables are replaced by predicates over a suitable set of nonbinary variables. For example, consider the following:

Here, ϕ₁ is an example of a predicate in difference logic (DL) in which the variables are real-valued and the clauses are constructed with standard comparison operations (>, ≥, =) and −. Further, ϕ₂ is a predicate in real arithmetic. More generally, the predicates may include linear inequalities, equalities involving uninterpreted function symbols, polynomials, arrays, bit-vectors, and sentences from other theories. The satisfaction of predicates is defined in terms of the appropriate theories. For instance, linear inequalities over real variables are evaluated using the rules of the theory of linear real arithmetic; predicates involving uninterpreted function symbols are evaluated using the rules of the theory of uninterpreted functions with equality. Those theories are called background theories for SMT. As in the case of SAT, an SMT solver has to decide if there exists a valuation of the variables that satisfies the given formula.

An SMT solver uses theory solvers together with DPLL (see Figure 7.5). A theory solver (also called a decision procedure) for theory T takes a CNF formula ϕ in theory T and decides whether ϕ is satisfiable in T.

Figure 7.5
Architecture of an SMT solver.

For example, a theory solver for convex linear arithmetic could use the simplex method for linear programming (Dantzig and Thapa, 1997); a theory solver for uninterpreted functions simply needs to reason about the equivalence of terms in the formula (see Exercise 7.7 at the end of the chapter); and a solver for DL has to check cycles in a graph (Exercise 7.8).

We can use a number of strategies to combine theory solvers with DPLL to build an SMT solver. Here, we briefly discuss one of them, called the lazy approach. The key idea is to repeatedly perform the following operations (see Figure 7.5).

1. Construct a Boolean abstraction abs(ϕ) of the given formula ϕ.

2. Use a SAT solver to find a satisfying solution x for abs(ϕ); if the SAT solver returns “unsatisfiable,” then conclude that ϕ is unsatisfiable; otherwise, go to step 3.

3. Use a theory solver to check the satisfiability of abs⁻¹(x) obtained from step 2.

4. If the theory solver returns “unsatisfiable,” then a new constraint is added to abs(ϕ), and steps 1–4 are repeated.

Consider the following predicate from the theory of uninterpreted functions (UF):

In constructing a Boolean abstraction of ϕ, we introduce four Boolean variables, x₁:= g(a) = c; x₂:= f(g(a)) = f(c); x₃:= g(a) = d; and x₄:= c = d. Then the Boolean abstraction of ϕ is

Suppose that checking the satisfiability of abs(ϕ) with a SAT solver returns the satisfying solution x = (x₁ = 1, x₂ = 0, x₄ = 0). The concretized version of x is the formula

which is found by the UF theory solver to be “unsatisfiable.” Therefore, at least one of the clauses in abs⁻¹(x) must be false, and this is added as a new constraint to abs(ϕ). That is, in the next iteration, the Boolean formula to be checked is

Suppose that the SAT solver returns the satisfying solution x′ = (x₁ = 1, x₃ = 1, x₄ = 0) for abs(ϕ₁). The concretized version of x′ is the formula

which is found to be unsatisfiable by the UF solver. Once again, this fact about unsatisfiability is added to the Boolean formula to be checked in the next iteration:

The SAT solver will find the Boolean formula abs(ϕ₂) to be unsatisfiable, and therefore, the algorithm will terminate by (correctly) concluding that ϕ is also unsatisfiable.

We refer readers who are interested in learning more about modern SMT solvers to the Handbook of Satisfiability (Biere et al., 2009), as well as Kroening and Strichman (2008), on decision procedures. For more hands-on learning, download and use an open-source solver, like Z3 (de Moura and Bjørner, 2008), Yices (Dutertre, 2014), or CVC4 (Barrett et al., 2011), all of which are actively maintained and come with detailed tutorials and examples.

7.5.3  Modeling for satisfiability and satisfiability modulo theory

The expressive power of propositional logic and other theories can be marshaled to succinctly represent automata, transitions, reachable states, and inductive invariants. For example, consider an automaton 𝒜 = ⟨V, Θ, 𝒟⟩ with Boolean variables. That is, V = {x₁, …, xm}, and type(xi) = 𝔹 for each i. The set of initial states Θ ⊆ val(V) can be represented by a propositional formula FΘ(V) over V. To describe the set of transitions 𝒟⊆ val(V) × val(V ), we introduce a second set of variables V′ = {x₁′, …, xm′}, corresponding to the values of x₁, …, xm in the state after the transition. Then, the set of transitions can be represented by a propositional formula F𝒟(V, V′) over V∪ V ′.

For the following simple automaton:

the transition relation can be written with the primed variables as follows:

Notice that the variables that do not appear on the right side of an assignment in the eff are assumed to remain constant, and in F𝒟, this constancy has to be captured explicitly as x₁′ = x₁ or x₂′ = x₂. Now consider a candidate inductive invariant I(V), also expressed as a predicate over V. With those predicates in place, the relevant part of the hypothesis of Page 141Theorem 7.1 for automaton 𝒜 and candidate invariant I can be written as

Then, checking the satisfiability of the negation of ϕ𝒜, I gives us a method for deciding whether I is indeed an invariant for 𝒜. Note that negation of ϕ𝒜, I,

has the familiar form of the SAT problem with a single existential quantifier. If the formula is determined to be unsatisfiable, then we conclude that I is an invariant; otherwise, the satisfying solution gives either an initial state that violates I or a transition that violates I.

That modeling approach, together with SMT solvers, has been adapted to check invariants for a variety of automata with other types of variables. The IronFleet project (Hawblitzel et al., 2015), for instance, demonstrates how practical consensus protocols can be modeled and verified using the SMT-based program verification system called Dafny (Leino, 2010). Tuttle and Goel (2012) have also shown how an SMT-based checker can be used to verify a consensus protocol. The Ivy project (Padon et al., 2016) uses another decidable fragment of first-order logic to model and verify infinite state transition systems.

7.6  Further reading

A variety of interesting cyber-physical systems have been verified using the approaches presented in this chapter, with different degrees of automation. See, for example, analyses of air-traffic control systems (Livadas et al., 1999), platooning and vehicle control systems (Lynch, 1996; Weinberg and Lynch, 1996; Weinberg et al., 1995), a tabletop helicopter system (Mitra et al., 2003), and a key part of Caltech’s autonomous vehicle developed for the DARPA Urban Challenge (Wongpiromsarn et al., 2009). The verification techniques for convergence and stability discussed in Chapter 10 also have parallels with the proof techniques presented in this chapter. For further reading on applications of the Floyd-Hoare method for verifying cyber-physical systems, see Feron (2010), which shows how control-theoretic domain knowledge, such as Lyapunov-style proofs of stability, can be used for verification of control software implementations.

7.6.1  Finding and learning invariants

The key input needed for applying Theorem 7.1 is the inductive invariant I for automaton 𝒜. For the invariant I to be useful for proving a safety property S, it should be strong enough (i.e., I ⇒ S). The problem of finding adequately strong inductive invariants for hybrid automata is a challenging one that has received significant attention, yet so far, no single method dominates. In this section, we briefly note some of the approaches that have been applied successfully. It turns out that the problem has certain parallels with the problem of finding the Lyapunov functions and ranking functions that are used in progress verification. See Chapter 10 for more on that topic.

Invariant generation with templates   The basic idea here is to choose a template form of the invariant I(p) and then solve constraints imposed by Theorem 7.1 to find the unknown coefficients p. For example, Tiwari (2008) uses the template shape of boxes (or hyperrectangles) defined by parameters l, u ∈ ℝn:

To find an instance of this template Box(l, u) that is an inductive invariant, we have to solve a constraint satisfaction problem of the following form:

Introduction of both ∀ and ∃ quantifiers makes this a quantified formula in the first-order theory of reals. If the template and the predicate Post𝒜(v) can be expressed in propositional logic, then the problem becomes a Quantified SAT (QSAT) problem; QSAT is a generalization of SAT that is PSPACE-complete. To control the complexity of the problem, several approaches, including that of Tiwari (2008), have been developed that are based on special techniques for special classes of hybrid systems, for which the universal quantifiers can be eliminated so that the problem can be effectively solved with a constraint-solving engine. For example, Colón et al. (2003) generate linear inequality invariants for linear systems; Rodríguez-Carbonell and Tiwari (2005) generate polynomial invariants of hybrid systems with linear dynamics; and Sankaranarayanan et al. (2008) generate polynomial invariants for more general polynomial hybrid systems. The approach of template instantiation can also be used to generate polynomial Lyapunov functions for proving stability (Forsman, 1991). Platzer and Clarke (2008) present another approach for iteratively refining and generating invariants in the differential dynamic logic framework.

Learning invariants by using execution data   A second approach aims to construct invariants (and Lyapunov functions) from execution data from the system 𝒜. There is a long history of research on learning invariants for programs. See, for example, the publications related to the Daikon project (Perkins and Ernst, 2004). An unsupervised approach using reinforcement learning (RL) has been presented in Si et al. (2018). For dynamical and hybrid systems, Kozarev et al. (2016) show how support vector machines (SVMs) and RL can be used to classify whether states satisfy an invariant based on execution data. For nonlinear hybrid systems, Kapinski et al. (2014) propose a method that uses execution data to create a sequence of candidate Lyapunov functions by solving linear programs, which are subsequently improved using a global optimizer guided by Equation (3.21) in Chapter 3 and an SMT solver.

7.7  Exercises

Exercise 7.5.   Consider the autonomous dynamical system , with initial set Θ ⊆ val(X). Suppose that V: val(X) → ℝ is a Lyapunov function for the system. Show that for any sublevel set S of V, if Θ ⊆ S, then S is an inductive invariant of the system.

Exercise 7.6.   Consider the idealized, pocket-free, friction-free billiard system described in Exercise 4.8 in Chapter 4. Prove conservation of momentum as an inductive invariant property of this system.

Exercise 7.7.   Consider a formula in the UF theory:

where F is an uninterpreted unary function symbol. Develop a decision procedure for UF by applying the following process to ϕ: Initially, construct a set of equivalence classes—one for each variable and function instance. Iteratively, merge classes if (a) ti = tj appears in ϕ and ti and tj are in different classes, and (b) merge F(ti) and F(tj) if ti and tj are in the same class. When should this algorithm stop with a decision?

Exercise 7.8.   Consider the DL formula ϕ₁ in (7.10) interpreted over integers. Develop a decision procedure for DL by applying the following process to ϕ₁:

First, convert all the literals to the form x − y ≤ c. Next, construct a graph with the variables as vertices and an edge labeled c from x to y for each inequality x−y ≤ c. Finally, characterize the satisfiability of DL in terms of cycles in this graph.

Exercise 7.9.   Write a program implementing the decision procedure for DL.

Exercise 7.10.   Model the time-abstract version of the automaton of Exercise 7.6 and verify the conservation of momentum invariant by using an SMT solver.

Exercise 7.11.   Consider an automaton 𝒜 = (V, Θ, 𝒟) with Boolean variables as in Section 7.5.3, and an unsafe set U ⊆ val(V) specified by a predicate F𝒰 over V. How can a SAT solver be used to check whether Reach𝒜(Θ, k) ∩ U = ∅ for any positive integer k? This is called bounded model checking.

8

Abstractions and Compositional Reasoning

Overview

Suppose that we want to verify that a system 𝒜 meets a requirement. If 𝒜 is a complicated model, it is standard practice to verify a simpler model, 𝒜′, and then to transfer the results to 𝒜. For the transfer to work, 𝒜′ should be related to 𝒜 so that establishing the requirement for 𝒜′ is sufficient to enable inference of the same for 𝒜. The notion of abstraction formalizes such relationships among automata and enables that type of reasoning. In this chapter, we introduce several notions of abstractions—timing abstraction, hybridization, input/output (I/O) abstraction, and trace inclusion. Then, we discuss techniques for proving abstraction relations that include forward and backward simulations, bisimulations, and time-abstract bisimulations. We cover substitutivity theorems that allow algebraic reasoning with compositions and abstractions of hybrid automata. Finally, we give an overview of counterexample-guided abstraction refinement (CEGAR) algorithms for hybrid systems.

8.1  Quick introduction to abstractions: Timing abstraction

Recall the simple Thermostat(u, l, K, h) automaton from Figure 4.4 (see p. 64). A single, continuous variable x models the temperature of a room, and a location variable loc models whether the room heater is on or off. The temperature rises when loc = on according to the linear ordinary differential equation (ODE) , and it drops according to when loc = off. The heater turns on whenever x drops below l, and it turns off whenever x goes above u.

The trajectories and executions of Thermostat involve solving the linear differential equations; however, if we are only interested in the timing-related requirements of the heater, then we can work with an abstract timed automaton model. For this example, the solutions of the differential equations are known, and we will use them to create the abstract timed automaton. The solution τ of is a trajectory of the form τ(t) ⌈ x = (τ(0) ⌈ x)e−Kt. Thus, the time taken for x to drop from u to l is . Similarly, the time for x to rise from l to u in the on mode is . Because those time intervals are independent of the actual state x of Thermostat, a stopwatch with the appropriate timings is adequate. Figure 8.1 shows the abstract timed automaton TTh.

Figure 8.1
Timed automaton abstraction of the automaton Thermostat of Figure 4.4.

In the example in Figure 8.1, it’s easy to see that for every execution α of Thermostat, there is an execution β of TTh such that the timings of the actions A = {turnOn, turnOff} in the two executions match exactly. Using the restriction operator (described in Section 5.3.4 in Chapter 5), we can write

Recall that α ⌈ (A, ∅) represents the trace of α restricted to the set of actions A and the empty set of variables (i.e., the resulting trace only has information about the timing of the actions). TTh is called the abstract model, and Thermostat is called the concrete model. The abstract model contains the behaviors of the concrete model, but has more behaviors. The abstract TTh is also simpler because it has fewer modes and constant dynamics.

Following Equation (8.1), TTh is a timing abstraction of Thermostat; it preserves the timing behavior, but not the detailed dynamics. In fact, TTh is a timed automaton, and in Chapter 9, we will see that it can be verified automatically. Equation (8.1) implies that the verified timing requirements of TTh transfer to Thermostat.

Note that the converse is not true; there are executions of TTh for which there is no corresponding execution of Thermostat. For example, an execution in which turnOn never occurs has no counterpart in ExecsThermostat. Thus, verified requirements of Thermostat would not transfer to TTh. Timing abstraction, and more generally, any abstraction relation on automata, defines a preorder on automata.

How can we prove this abstraction relation? Executions are infinite sequences of states and trajectories. Reasoning about sets of executions quickly becomes complicated. The key idea is to reason about states instead. Because two automata are involved, we have to reason about a pair of states. Mathematically, we have to work with a predicate R on VThermostat ∪ V TTh or, equivalently, a relation R ⊆ val(VThermostat) × val(V TTh). Further, we would want the relationship between the automata to hold for arbitrarily long executions, and therefore, the relation R should be inductive. Consider the relation over the states of the two automata given in Definition 8.1.

Definition 8.1.   For any pair of states x₁ ∈ val(VThermostat), x₂ ∈ val(V TTh), (x₁, x₂) ∈ R if and only if

1. x₁ ⌈ loc = x₂ ⌈ loc, and

2. x₁ ⌈ loc = on then .

The relation R satisfies the property given in Proposition 8.1.

Proposition 8.1.   Relation R of Definition 8.1 satisfies the following:

(a) (Start condition) For every x₁ ∈ ΘThermostat, there exists x₂ ∈ ΘTTh such that (x₁, x₂) ∈ R.

(b) (Transition condition) For every transition (x₁, a, ) ∈ 𝒟Thermostat and every x₂ such that (x₁, x₂) ∈ R, there exists such that (x₂, a, ) ∈ 𝒟TTh and (, ) ∈ R.

(c) (Trajectory condition) For every trajectory τ₁ ∈ 𝒯Thermostat from τ.fstate = x₁ and every x₂ with (x₁, x₂) ∈ R, there exists τ₂ ∈ 𝒯TTh with τ₂.fstate = x₂ such that τ₁.ltime = τ₂.ltime and (τ₁.lstate, τ₂.lstate) ∈ R.

The start condition holds trivially. The transition and the trajectory conditions are also local checks (i.e., they require application of the transition and trajectory evolution conditions on state pairs). Observe the parallel between Proposition 8.1 and Theorem 7.1.

From a given finite execution α ∈ ExecsThermostat, Proposition 8.1 allows us to inductively construct a corresponding execution β ∈ ExecsTTh step by step, such that α and β satisfy Equation (8.1). The construction goes as follows:

1. Let us fix an α = τ₁₀, a₁₁, τ₁₁, a₁₂, …, τ1n. Using the start condition, we know that there is a start state of TTh, x₂₀ ∈ ΘTTh such that (τ₁₀.fstate, x₂₀) ∈ R.

2. Starting from that initial state, for the first trajectory τ₁₀, we have (τ₁₀.fstate, x₂₀) ∈ R. That is, the initial state pair (x₁₀, x₂₀) satisfies the hypothesis in the trajectory condition, and therefore it follows that there is a trajectory τ₂₀ ∈ 𝒯TTh with the same duration as τ₁₀, and with τ₁₀.lstate related to τ₂₀.lstate by R. Thus, we have a prefix τ₂₀ of β that simulates the prefix τ₁₀ of α, and preserves the relation R.

3. Continuing forward, we extend the prefix τ₂₀ with a transition , where a₂₁ is chosen to be the same action as a₁₁. We can do so because τ₁₀.lstate and τ₂₀.lstate satisfy the hypothesis of the transition condition, and the transition condition of Proposition 8.1 ensures the existence of such a transition. Further, the transition condition also ensures that τ₁₂.fstate is related to x₂ by R. Thus, these two states satisfy the trajectory conditions, and we are at the beginning of step 2.

We can repeat the alternating application of trajectory and transition conditions to construct β. In each trajectory step, the τ2i has the same duration as the corresponding τ1i, and in each transition step, a2j = a1j. Therefore, α ⌈ (A, ∅) = β ⌈ (A, ∅).

The relation R is an example of a forward simulation relation, and Proposition 8.1 is a special case of a general result for proving abstraction using simulation relations. In the rest of this chapter, we will study more general types of abstractions and the corresponding proof techniques that use simulation relations. We will also present results that relate abstractions and simulation relations with the composition operation of Chapter 5.

8.2  Abstraction definitions

First, we consider a notion of abstraction that requires every execution of the concrete automaton 𝒜₁ to be exactly equal to some execution of the abstract automaton 𝒜₂. Because executions contain information about the values of all the variables and their time evolution, this notion of abstraction makes sense only for automata with matching sets of variables and actions. Such automata are called comparable.

Definition 8.2.   A pair of hybrid input/output automata (HIOA), 𝒜₁ and 𝒜₂, is strongly comparable if A₁ = A₂ and V₁ = V ₂. For a pair of strongly comparable HIOA, we say that 𝒜₂ is an abstraction of 𝒜₁ if Execs𝒜₁ ⊆ Execs𝒜₂, and we write this relationship as 𝒜₁ ≤𝒜₂.

In that expression, ≤ captures the intuition that 𝒜₁ has “fewer” behaviors than 𝒜₂. This definition applies to hybrid automata (without inputs and outputs) as well as to IOA (without trajectories). Strong compatibility of 𝒜₁ and 𝒜₂ does not imply the equality of the corresponding sets of transitions and trajectories.

The second notion of abstraction relies on comparison of the traces or the externally visible behaviors of automata. This relationship allows the comparison of automata that have matching external interfaces, but it may have different internal actions and variables. Recall that the trace of an execution α is obtained by dropping all the information about the internal variables and actions (see Definition 5.11).

Definition 8.3.   A pair of HIOA 𝒜₁ and 𝒜₂ is comparable if they have identical sets of input and output variables and actions. That is, U₁ = U₂, Y₁ = Y ₂, I₁ = I₂, and O₁ = O₂. Given a pair of comparable HIOAs, 𝒜₂ is said to be an I/O abstraction of 𝒜₁ if Traces𝒜₁ ⊆ Traces𝒜₂, and this relationship is written as 𝒜₁ ≤T𝒜₂. In this case, 𝒜₁ is said to implement 𝒜₂.

I/O abstraction is more useful than Definition 8.2, as it allows one to compare models while ignoring internal details that are implemented with different internal variables and actions. The terminology around various types of abstractions can get confusing. An I/O abstraction is also sometimes called an abstraction or a trace abstraction.

I/O abstraction can be used to relate a specification or a requirement and its implementation. In this use case, the abstract automaton 𝒜₂ captures the requirements of the system in terms of I/O actions and variables. For example, a requirement for a collision alerting protocol may state, “Any occurrence of a collision action must be preceded by at least 4 seconds by an occurrence of an alarm action.” That requirement can be written as a simple abstract hybrid automaton with a clock. The corresponding concrete implementation will use sensor measurements and specific algorithms to implement a mechanism for raising a timely alarm. Such mechanisms will be modeled in the concrete automaton 𝒜₁. The problem of verifying that the mechanism meets the requirement is the same as checking whether 𝒜₁ ≤T𝒜₂.

Proposition 8.2.   I/O abstraction ≤T and abstraction ≤ are preorders [i.e., reflexive and transitive relations over (strongly) comparable automata].

Exercise 8.1.   Prove Proposition 8.2.

In reasoning about complex models, we will often need to go through several levels of abstractions by using Proposition 8.2.

8.3  Proving abstractions: Simulation relations

Executions and traces are complicated objects, and checking the containment Traces𝒜₁ ⊆ Traces𝒜₂ in Definition 8.3 is generally hard to do. Theorem 8.3 gives a sufficient condition in terms of the existence of a forward simulation relation. A forward simulation relation R relates the states of the concrete automaton 𝒜₁ to those of the abstract automaton 𝒜₂, such that for every concrete starting state, there is a related abstract starting state that can “simulate” the concrete state. That is, every transition or trajectory of the concrete automaton can be mimicked by a corresponding transition, trajectory, or, more generally, execution fragment of the abstract automaton, with the same visible behavior or trace. This condition is depicted in Figure 8.2. If such a forward simulation relation exists, then for every execution α of 𝒜₁, it is possible to inductively construct an execution of 𝒜₂ such that the two executions have the same trace. This argument is formalized in the proof of Theorem 8.3.

Figure 8.2
Forward simulation relation for an HIOA. The three conditions in Definition 8.4 are depicted from left to right. The second and third conditions complete the boxes with the dashed lines: an execution fragment β of 𝒜₂ preserves the relation R between and β.lstate.

Definition 8.4.   Consider a pair of comparable HIOA, 𝒜₁ and 𝒜₂. A relation R ⊆ val(X₁) × val(X₂) is a forward simulation relation from 𝒜₁ to 𝒜₂ if:

(a) (Start condition) For each x₁ ∈ Θ₁, there is an x₂ ∈ Θ₂ such that x₁R x₂.

(b) (Transition condition) For each , x₂ ∈ val(X₂) with x₁R x₂, there is an execution fragment β of 𝒜₂ such that (1) β.fstate = x₂, (2) R β.lstate, and (3) trace(β) = trace(a).

(c) (Trajectory condition) For each τ ∈ 𝒯₁, x₂ ∈ val(X₂) with τ.fstate R x₂, there is an execution fragment β of 𝒜₂ such that (1) β.fstate = x₂, (2) R β.lstate, and (3) trace(β) = trace(τ).

Theorem 8.3.   For a pair of comparable HIOAs, 𝒜₁ and 𝒜₂, if there is a forward simulation relation from 𝒜₁ to 𝒜₂, then 𝒜₂ is an I/O abstraction for 𝒜₁. That is, 𝒜₁ ≤T𝒜₂.

Proof. Fix the automata 𝒜₁, 𝒜₂ and the forward simulation relation R from 𝒜₁ to 𝒜₂. For any trace γ ∈ Traces𝒜₁, we have to show that γ ∈ Traces𝒜₂. We know that there is an execution α ∈ Execs𝒜₁ such that trace(α) = γ. Let α = τ₀a₁τ₁a₁… be an infinite sequence. The proof is similar for the case when α is finite. We will inductively construct an execution α′ = β₀β₁… ∈ Execs𝒜₂ such that trace(α′) = γ. For the inductive construction, we will require that for each index i in the sequence, τi.fstate R β2i.fstate, τi.lstate R β2i.lstate, ai.prestate R β2i−1.fstate, and ai.poststate R β2i−1.fstate.

(Base case condition) Consider the case where i = 0 and τ₀ is a point trajectory. Because τ₀.fstate ∈ Θ₁, by condition 1 of Definition 8.4, we know that there exists a state x₂ ∈ Θ₂ such that τ₀.fstate R x₂. We choose β₀ to be the point trajectory at x₂.

(Inductive case for ai) From the inductive hypothesis, we have already constructed an execution α′′ = β₀, β₁, …, β2(i−1) of 𝒜₂ that simulates the prefix of α up to the trajectory τi−1 that precedes ai. That simulating execution gives τi−1.lstate R β2(i−1).lstate and trace(α′′) = trace(τ₀a₁…τi−1). Now we extend the prefix to include ai and construct the simulating execution in a manner that preserves these requirements. Because ai.prestate = τi−1.lstate, we instantiate condition 2 of Definition 8.4 with x₁ = ai.prestate, = ai.poststate, and x₂ = α′′.lstate, and we use the resulting execution fragment of 𝒜₂ as β2i−1. Because β2i−1.fstate = α′′.lstate, α′′⌢ β2i−1 is an execution of 𝒜₂. Also, trace(α′′⌢ β2i−1) = trace(τ₀a₁…ai℘(ai.poststate)), and the simulation relation is maintained at the endpoints.

(Inductive case for τi) From the inductive hypothesis, we have an execution α′′ = β₀, β₁, …, β2i−1 of 𝒜₂ that simulates a prefix of α up to the transition ai, such that ai.poststate R β2i−1.lstate and trace(α′′) = trace(τ₀…ai℘(ai.poststate)). Now we extend that prefix to include τi and simultaneously extend the simulating execution in a manner that preserves the trajectory requirements. Because τi.fstate = ai.poststate, we instantiate condition 3 of Definition 8.4 with x₁ = τi.fstate, = τi.lstate, and x₂ = α′′.lstate, and we use the resulting execution fragment of 𝒜₂ as β2i. Because β2i.fstate = α′′.lstate, α′′⌢ β2i is an execution of 𝒜₂. By construction, trace(α′′⌢β2i) = trace(τ₀a₁…τi), and the simulation relation is maintained.

In special cases, the forward simulation relation R may be replaced with a simulation function f: val(X₁) → val(X₂), and the result still holds. This notion of forward simulation allows the abstract and concrete automata to have different variables and actions so long as the I/O interfaces match. Further, a single action a of the concrete automaton could be simulated by an execution fragment β that has several alternating internal actions and point trajectories so long as trace(a) = trace(β).

Exercise 8.2.   Consider three comparable HIOA, 𝒜₁, 𝒜₂, and 𝒜₃. Suppose that R₁₂ is a forward simulation relation from 𝒜₁ to 𝒜₂, and R₂₃ is a forward simulation relation from 𝒜₂ to 𝒜₃, then R₁₂ ° R₂₃ is a forward simulation from 𝒜₁ to 𝒜₃.

Next, we define a more restrictive version of forward simulation that requires each step of the concrete automaton to be matched by an identical step of the abstract automaton and gives a sufficient condition for showing that for every execution of the concrete automaton, there is a corresponding execution of the abstract automaton.

Definition 8.5.   Consider a pair of comparable HIOAs, 𝒜₁ and 𝒜₂. A relation R ⊆ val(X₁) × val(X₂) is a strong forward simulation relation from 𝒜₁ to 𝒜₂ if:

(a) (Start condition) For each x₁ ∈ Θ₁, there exists x₂ ∈ Θ₂ such that x₁R x₂.

(b) (Transition condition) For each , x₂ ∈ val(X₂) with x₁R x₂, there exists val(X₂) such that (1) x₂ x₂′ and (2) R .

(c) (Trajectory condition) For each τ ∈ 𝒯₁, x₂ ∈ val(X₂) with τ.fstate R x₂, there exists τ′∈ 𝒯₂ such that (1) τ′.fstate = x₂ and (2) τ′.dom = τ.dom, and for each t ∈ τ.dom, τ(t) R τ′(t).

The proof of the following theorem is analogous to that of Theorem 8.3.

Theorem 8.4.   For a pair of comparable HIOAs, 𝒜₁ and 𝒜₂, if there exists a strong forward simulation relation from 𝒜₁ to 𝒜₂, then for every execution α of 𝒜₁ there exists a corresponding execution α′ of 𝒜₂. That is, α and α′ have identical sequences of actions and identical domains of trajectories, and the states along the trajectories are related.

Forward simulation (Definition 8.4) subsumes strong forward simulation (Definition 8.5).

Corollary 8.5.   For a pair of strongly comparable HIOAs, 𝒜₁ and 𝒜₂, if there exists a strong forward simulation relation from 𝒜₁ to 𝒜₂, then Execs𝒜₁ ⊆ Execs𝒜₂.

The next two exercises explore the types of requirements that are and are not preserved by abstractions. Invariants are preserved but stability requirements are not, as was first shown by Prabhakar et al. (2012).

Exercise 8.3.   If R is a forward simulation relation from 𝒜₁ to 𝒜₂ and I is an invariant of 𝒜₂, then show that R⁻¹(I) is an invariant of 𝒜₁.

Exercise 8.4.   Give an example of a pair of comparable hybrid automata, 𝒜₁ and 𝒜₂, such that 𝒜₁ ≤ 𝒜₂ and 𝒜₂ is Lyapunov stable but 𝒜₁ is not. Hint: Consider the automata to be purely dynamical systems.

8.4  Bisimulations and time-abstract bisimulations

In comparing behaviors of two automata, if we decide to ignore the timing of the various actions and the trajectories, we get notions of abstraction that only require each step of one automaton to be matched by a corresponding step of the other automaton with the same label, where a step could be an action or a trajectory of any duration.

For a pair of discrete automata or untimed hybrid automata 𝒜₁, 𝒜₂, it is sometimes useful to relate the state pairs that have exactly the same behaviors or traces. That is captured by the notion of bisimulation.

Definition 8.6.   Consider discrete automata 𝒜₁ = ⟨X₁, Θ₁, A, 𝒟₁⟩ and 𝒜₂ = ⟨X₂, Θ₂, A, 𝒟₂⟩ with the common set of actions A. A relation R ⊆ val(X₁) × val(X₂) is a bisimulation relation:

(a) For every initial state x₁ ∈ Θ₁, there exists x₂ ∈ Θ₂ such that x₁ R x₂,

(b) For every initial state x₂ ∈ Θ₂, there exists x₁ ∈ Θ₁ such that x₁ R x₂.

(c) If x₁ R x₂ and , there exists such that (1) and (2) R ; and

(d) If x₁ R x₂ and , there exists such that (1) and (2) R .

The automata 𝒜₁ and 𝒜₂ are bisimilar if there exists a bisimulation relation R on their states.

In other words, the discrete automata are bisimilar if there is a forward simulation relation from 𝒜₁ to 𝒜₂ and from 𝒜₂ to 𝒜₁. Bisimilarity induces an equivalence relation on the space of comparable automata.

For a pair of automata with a shared set of actions A, if all the actions are enabled in all the states of the automata, then a trivial bisimulation relation can be defined as Rall val(X₁) × val(X₂). This coarse relation Rall captures little information about how the actions alter the states of 𝒜₁ and 𝒜₂, and therefore is unlikely to be very useful in analysis. To attain useful relations, we will strive to find the smallest (or, as it is called, the finest) bisimulation relation that satisfies Definition 8.6.

The definitions of simulation and bisimulation relations in this chapter are based on transition labels because we are focused on reasoning about automata in terms of trace inclusions. Alternative definitions of bisimulation relations based on state labels are used in reasoning about automata satisfying temporal logics such as the linear tree logic (LTL) and computational tree logic (CTL) requirements introduced in Chapter 6. We refer the interested reader to Chapter 7 of Baier and Katoen (2008) for further readings on these alternative definitions and their relationships with different temporal logics.

8.4.1  Untiming and bisimulations

The untiming operation on hybrid automata is given in Definition 4.5 in Chapter 4. Recall that the untime abstraction Untimed(𝒜) of a hybrid automaton 𝒜 gives a discrete automaton that simulates every transition and every trajectory of 𝒜 with a transition.

Definition 8.7.   A pair of hybrid automata 𝒜₁ and 𝒜₂ are said to be time-abstract bisimilar if Untimed(𝒜₁) and Untimed(𝒜₂) are bisimilar.

In this definition, the automaton 𝒜₂ could also be a discrete automaton, in which case Untimed(𝒜₂) = 𝒜₂. Bisimilar and time-abstract bisimilar automata have strongly related properties. Roughly, bisimilarity of 𝒜₁ and 𝒜₂ implies that for every untimed execution of 𝒜₁, there is a corresponding execution of 𝒜₂, and vice versa. One can construct the corresponding executions inductively by using the bisimulation relation. Specifically, from the inductive invariant of one automaton, we can infer an inductive invariant for the other. For any set S ⊆ S₁ and a relation R ⊆ S₁ × S₂, the image of S under R is defined as the set

Proposition 8.6.   Suppose that 𝒜₁ and 𝒜₂ are bisimilar with bisimulation relation R, and suppose that I₁ is an inductive invariant of 𝒜₁; then R(I₁) is an inductive invariant of 𝒜₂.

Proof. We use Theorem 7.1 in Chapter 7 to check that I₂ is an inductive invariant of 𝒜₂.

(Start condition) Consider any state x₂ ∈ Θ₂. From the definition of bisimilarity, we know that there exists x₁ ∈ Θ₁ and x₁ R x₂. Thus, by the definition of R(I₁), it follows that x₂ ∈ R(I₁).

(Transition condition) Consider such that x₂ ∈ I₂; we have to show that R(I₁). From the definition of bisimilarity, it follows that there exists x₁ ∈ I₁ such that x₁ R x₂. Further, from the bisimulation relation, it also follows that there exists , a with and R . From the invariance of I₁ for 𝒜₁, it follows that ∈ I₁, and therefore R(I₁).

Proposition 8.6 carries over to time-abstract bisimilar hybrid automata. While bisimilarity preserves inductive invariants, there are other types of properties that are not preserved. For example, it may be tempting to claim that Reach𝒜₂ = R(Reach𝒜₁). While Reach𝒜₂ is contained in R(Reach𝒜₁), the automaton shown on the right side of Figure 8.3 gives a counterexample to the putative claim. Consider the following relation:

Figure 8.3
Trace equivalence and bisimilarity. Left: Trace-equivalent finite automata 𝒜 and ℬ. 𝒜 forward-simulates ℬ, but ℬ does not forward-simulate 𝒜. Instead, a backward-simulation relation relates the two automata. Right: Trace-equivalent and bisimilar finite automata 𝒜 and ℬ, showing that bisimilarity does not preserve reachability.

You can check that Rbisim is a bisimulation relation between 𝒜 and ℬ; however, states {7, 8} are not reachable in ℬ. Another property that is not preserved by bisimilarity is Lyapunov stability (Prabhakar et al., 2012).

8.4.2  Example: Simulation and trace inclusion

Consider the comparable automata 𝒜 and ℬ shown on the left side of Figure 8.3. They have identical sets of actions a, b, and c and are trace-equivalent (i.e., Traces𝒜 = Tracesℬ = {∅, a, ab, ac}). Are the two automata bisimilar? A natural candidate forward simulation relation from ℬ to 𝒜 is

The relation R satisfies the start condition and the transition condition for strong forward simulation from ℬ to 𝒜 (Definition 8.5). However, observe that R does not serve as a strong forward simulation relation from 𝒜 to ℬ. To illustrate that, observe that (2, 7) ∈ R, but 2 cannot forward-simulate 7. The reason is that 7 9, but from the related state 2 of ℬ, only a b transition is enabled. In fact, we can check that there is no forward simulation relation from 𝒜 to ℬ because the transition 6 7 has to be matched with either 1 2 or 1 4, which prematurely forces ℬ to commit to a b or a c transition. This example shows that trace inclusion (i.e., equality) is a more general relationship among automata than forward simulations and bisimulations.

8.4.3  Backward simulations

A forward simulation relation from 𝒜 to ℬ enables us to inductively construct an execution of ℬ that simulates an execution of 𝒜, starting from related initial states. It is also possible to perform that construction backward.

Definition 8.8.   Consider a pair of comparable HIOAs, 𝒜₁ and 𝒜₂. A relation on their states R ⊆ val(X₁) × val(X₂) is a backward-simulation relation from 𝒜₁ to 𝒜₂ if:

(a) (Start condition) For each x₁ ∈ Θ₁ and x₁R x₂, x₂ ∈ Θ₂.

(b) (Transition condition) If x₁R x₂ and , then there exists an execution fragment β of 𝒜₂ such that (1) β.lstate = x₂, (2) R β.fstate, and (3) trace(β) = trace(a).

(c) (Trajectory condition) If x₁R x₂, and there exists a trajectory τ ∈ 𝒯₁ with τ.lstate = x₁, then ℬ has a closed execution fragment β of 𝒜₂ such that (1) β.lstate = x₂, (2) R β.fstate, and (3) trace(β) = trace(τ).

Theorem 8.7.   For a pair of comparable HIOA, 𝒜₁ and 𝒜₂, if R is a backward simulation from 𝒜₁ to 𝒜₂, then every closed trace of 𝒜₁ is also a closed trace of 𝒜₂.

Exercise 8.5.   Show that the relation R defined in Equation (8.3) is a backward-simulation relation from 𝒜 to ℬ and from ℬ to 𝒜.

Exercise 8.6.   Prove Theorem 8.7.

Exercise 8.7.   Consider three comparable HIOAs, 𝒜₁, 𝒜₂, and 𝒜₃. Suppose that R₁₂ is a backward-simulation relation from 𝒜₁ to 𝒜₂ and that R₂₃ is a backward-simulation relation from 𝒜₂ to 𝒜₃; then R₁₂ ° R₂₃ is a backward simulation from 𝒜₁ to 𝒜₃.

8.5  Hybridization

Hybridization is a general technique for constructing a simpler, possibly nondeterministic hybrid automaton model from a more complex hybrid or dynamical system model (Asarin et al., 2007; Dang et al., 2010). A common use case is to hybridize a nonlinear dynamical system 𝒜₁ to an abstract linear or rectangular hybrid system 𝒜₂, so that the safety analysis of 𝒜₂ carries over to 𝒜₁. The basic idea is to partition the state space of 𝒜₁ into small neighborhoods, and then to overapproximate the nonlinear dynamics of 𝒜₁ over each neighborhood with linear or rectangular inclusions.

Consider two simple hybrid automata 𝒜₁ and 𝒜₂. 𝒜₁ has a single mode and a state variable x that evolves as , where f is a bounded continuous function, and type(x) is a compact subset Q in ℝn. 𝒜₂ uses a cover , where each Bi ⊆ Q is a compact region and . The mode variable loc of 𝒜 can take values in {1, …, m}. In mode loc = i, i ∈{1, …, m}, the dynamics is the differential inclusion:

The transitions are defined as follows: if loc = i and x ∈ Bi ∩ Bj, a mode transition may occur that sets loc:= j.

Exercise 8.8.   Show that 𝒜₂ is an abstraction of 𝒜₁ (i.e., Reach𝒜₁ ≤ Reach𝒜₂). 𝒜₂ is called a hybridization of 𝒜₁.

Figure 8.4 shows the reachable states of a pair of satellites from Section 4.5 in Chapter 4. Recall that the key variables of interest are the angular positions (ν₁ and ν₂) of the two orbiting satellites. The range of each variable is [0, 360], and the dynamics of each is given by the nonlinear differential equation [Equation (4.9)]. The model described thus far defines the concrete nonlinear model 𝒜₁ for this example. If we partition the angular state space into uniform intervals and find the extremal values of the dynamic function over each interval, we obtain the rectangular abstract automaton 𝒜₂. The hybridized rectangular automaton 𝒜₂ is amenable to automatic safety verification through reachability analysis, as discussed in Chapter 9. From the assertion in Exercise 8.8, it follows that Reach𝒜₁ ⊆ Reach𝒜₂, and therefore if Reach𝒜₂ is disjoint from a safety property U, that is adequate to support the inference of the safety of 𝒜₁ relative to U.

Figure 8.4
Reach set of a pair of satellites computed for a hybridized automaton. Both axes measure the angular position of the two satellites in degrees.

8.6  Substituting with abstractions

Substitutivity refers to a class of results that enable us to substitute one automaton for another in a composed system, while preserving trace inclusion. Substitution has applications in both design and verification. For the purpose of design (e.g., design of a controller for a plant), substitutivity allows us to refine abstract component models (e.g., a linear hybridized plant model refined to a nonlinear model) without violating the correctness of the whole system. The abstract components can also be seen as specifications or requirements. For verification, substitutivity enables us to prove that a composite system satisfies its requirements by proving that each component satisfies its requirement. This breaks the verification task into more manageable pieces.

Theorem 8.8 is a basic substitutivity result. It states that if 𝒜₂ is an I/O abstraction of 𝒜₁ (i.e., 𝒜₁ ≤T𝒜₂) without any assumptions about their environment, then 𝒜₂ is also an I/O abstraction of 𝒜₁ in the context of a compatible, more restrictive environment automaton ℬ. That is, 𝒜₁∥ℬ≤T𝒜₂∥ℬ. Thus, the addition of a complex environment ℬ preserves I/O abstraction between the automata 𝒜₁ and 𝒜₂.

Theorem 8.8.   Suppose that 𝒜₁, 𝒜₂, and ℬ are HIOA; 𝒜₁ and 𝒜₂ are comparable; and 𝒜₁ and 𝒜₂ are each compatible with ℬ. If 𝒜₁ ≤ T𝒜₂, then 𝒜₁∥ℬ≤T𝒜₂∥ℬ.

Proof. Consider a trace β of 𝒜₁∥ℬ. We will have to show that β is also a trace of 𝒜₂∥ℬ. If we use Theorem 5.4 (in Chapter 5) in one direction (namely, the restriction of β to the external interfaces of 𝒜₁ and ℬ), we get traces of 𝒜₁ and ℬ. That is, β ⌈ (O𝒜₁ ∪ I𝒜₁, U𝒜₁ ∪ Y𝒜₁) ∈ Traces𝒜₁ and β ⌈ (Oℬ∪ Iℬ, Uℬ∪ Yℬ) ∈ Tracesℬ. Because 𝒜₁ ≤ T𝒜₂, it follows that β ⌈ (O𝒜₁ ∪ I𝒜₁, U𝒜₁ ∪ Y𝒜₁) ⊆ Traces𝒜₂. Finally, if we use the other direction of Theorem 5.4, it follows that β ∈Traces𝒜₂∥ℬ.

As an example, suppose that 𝒜₁ is a concrete HIOA model of a vehicle with inputs and outputs that allow it to be composed with certain controllers. 𝒜₂ is an I/O-abstract model of the vehicle with a comparable interface. To be specific, 𝒜₂ could be a hybridized linear model of the nonlinear vehicle 𝒜₁. Because 𝒜₁ ≤T𝒜₂, Theorem 8.8 says that for any compatible controller ℬ, the composed abstract system 𝒜₂∥ℬ is an I/O abstraction of 𝒜₁∥ℬ. Thus, if we design a controller ℬ so that it restricts the behaviors of abstract vehicle 𝒜₂ such that 𝒜₂∥ℬ meets the desired requirements, then we can immediately conclude that 𝒜₁∥ℬ also meets the requirements.

In addition to abstracting and refining the vehicle model, we may want to do the same for the controller model. Commutativity of composition, together with repeated application of Theorem 8.8, gives Corollary 8.9.

Corollary 8.9.   Suppose that 𝒜₁, 𝒜₂, ℬ₁, and ℬ₂ are HIOA; 𝒜₁ and 𝒜₂ are comparable; ℬ₁ and ℬ₂ are comparable; and 𝒜₁ and 𝒜₂ are each compatible with each of ℬ₁ and ℬ₂. If 𝒜₁ ≤T𝒜₂ and ℬ₁ ≤Tℬ₂, then 𝒜₁∥ℬ₁ ≤T𝒜₂∥ℬ₂.

Proof. Because 𝒜₁ ≤ T𝒜₂, by Theorem 8.8, 𝒜₁∥ℬ₁ ≤ T𝒜₂∥ℬ₁ = ℬ₁∥𝒜₂, as composition is commutative. Similarly, because ℬ₁ ≤ Tℬ₂, by Theorem 8.8, ℬ₁∥𝒜₂ ≤Tℬ₂∥𝒜₂. Thus, we have 𝒜₁∥ℬ₁ ≤T𝒜₂∥ℬ₂.

We can further strengthen Corollary 8.9 by weakening the assumption that 𝒜₁ implements 𝒜₂ (i.e., the assumption 𝒜₁ ≤T𝒜₂, to the assumption that 𝒜₁∥ℬ₂ implements 𝒜₂∥ℬ₂).

Corollary 8.10.   Suppose that 𝒜₁, 𝒜₂, ℬ₁, and ℬ₂ are HIOA; 𝒜₁ and 𝒜₂ are comparable; ℬ₁ and ℬ₂ are comparable; and 𝒜₁ and 𝒜₂ are each compatible with each of ℬ₁ and ℬ₂. If 𝒜₁∥ℬ₂ ≤T𝒜₂∥ℬ₂ and ℬ₁ ≤Tℬ₂, then 𝒜₁∥ℬ₁ ≤T𝒜₂∥ℬ₂.

Going one step further, it may be tempting to prove an even stronger substitutivity theorem that can conclude 𝒜₁∥ℬ₁ ≤T𝒜₂∥ℬ₂ from a still weaker assumption: that 𝒜₁ implements 𝒜₂ in the context of ℬ₂ and ℬ₁ implements ℬ₂ in the context for 𝒜₂. That is, 𝒜₁∥ℬ₂ ≤T𝒜₂∥ℬ₂ and ℬ₁∥𝒜₂ ≤Tℬ₂∥𝒜₂. Kaynar et al. (2005) showed by means of a counterexample that it is impossible to prove this theorem. A slightly weaker version of the theorem can be proved with the additional assumption that the sets of traces of 𝒜₂ and ℬ₂ are closed under limits and time extensions.¹

8.7  Designing a CEGAR-based cyber-physical verification system

Counterexample-guided abstraction refinement (CEGAR) (Clarke et al., 2000) is a general algorithmic framework for automatically constructing and verifying property-specific abstractions. CEGAR has been applied to discrete automata and software (Holzmann and Smith, 2000; Ball and Rajamani, 2001; Corbett et al., 2000; Hsu et al., 2018), as well as timed and hybrid systems (Alur et al., 2006; Clarke et al., 2003; Fehnker et al., 2005; Prabhakar et al., 2015; Roohi et al., 2017a). In this section, we will discuss the basic idea of the CEGAR framework, its key design choices, and their implications.

The rough idea of CEGAR is shown in the flowchart in Figure 8.5. The goal is to verify a requirement S for a system or an automaton 𝒜. CEGAR begins with a coarse initial abstraction ℬ₀ of 𝒜, that is, 𝒜≤ℬ₀. In the ith iteration of the CEGAR loop, one of three possible decisions is made:

1. 𝒜 is verified to be safe with respect to the requirement S because the current abstraction ℬi is safe with respect to S.

2. A counterexample execution β for 𝒜 that violates S is found.

3. ℬi is refined to a more precise abstraction ℬi+1 that eliminates some behaviors of ℬi (i.e., 𝒜≤ℬi+1 ≤ℬi).

Figure 8.5
Basic CEGAR loop for verifying a requirement S for a system 𝒜.

Described in more detail, first, the abstraction ℬi of 𝒜 is checked against the requirement S. That step is implemented using a verification subroutine for ℬi. If ℬi is determined to satisfy S, then we can infer that 𝒜 also satisfies S, as 𝒜≤ℬi, and the algorithm terminates with the output “safe” (case 1). If ℬi is determined to violate S, then the verification subroutine produces a counterexample execution β of ℬi that violates S. There are two possibilities for β. If β is a valid execution of 𝒜, then 𝒜 violates S, and the algorithm terminates with the output “unsafe” (case 2). This step about checking validity of β is called validation. On the other hand, if β is not a valid execution of 𝒜, then it is a spurious counterexample, in that it violates S, but only because ℬi is a coarse abstraction of 𝒜 (case 3). In that case, ℬi is refined to create a new abstraction ℬi+1 of 𝒜, such that some behaviors of ℬi (possibly including β) are removed in ℬi+1.

Depending on the type of automaton, abstraction, model checker, validation, and refinement strategy implemented, the CEGAR loop can be shown to terminate. Moreover, as the algorithm iteratively refines abstractions based on counterexamples to a specific property S, it often discovers an abstraction that is just right for proving S, and therefore, the algorithm is more efficient than verification of the concrete system.

In implementing CEGAR for cyber-physical systems, we have to make the choices described in the next section, and these choices in turn influence the performance and the correctness guarantees. (Let us assume that the concrete system model 𝒜 is an HIOA and that the requirement S is an invariant property.)

8.7.1  Space of abstractions

The first choice is the space of the abstract automata, the ℬis, used in the algorithm. The abstract automata should be such that the model-checking problem is decidable for the requirement S. For example, the abstractions could be finite automata, timed automata, linear hybrid automata, rectangular hybrid automata (RHAs), and other types of automata. For each of those choices, we must further decide how the abstractions are constructed. For example, in creating the initial RHA abstraction ℬ₀ of 𝒜, (1) some variables of 𝒜 could be dropped in ℬ₀, (2) multiple locations of 𝒜 could be merged into a single location for ℬ₀, and (3) edges between locations could also be merged.

Consider the dynamical system 𝒜 = ⟨V, Θ, 𝒟, 𝒯⟩ with elliptical orbits shown in Figure 8.6. The system evolves on the plane and has the set of variables V = {x, y}. The set of initial states Θ ⊆ val(V) is shown by the small rectangle on the left of each part of the figure. The unsafe set Unsafe ⊆ val(V) corresponds to y ≥ 7. The system does not have any discrete transitions 𝒟 = ∅, and the trajectories are elliptical orbits around the origin; therefore, the exact reachable states of the system Reach𝒜 are the gray ring. Because Reach𝒜 is disjoint from Unsafe, 𝒜 is safe.

Figure 8.6
Discrete abstraction of an elliptical dynamical system. The actual reachset from the rectangular initial set Θ is shown by the gray ellipse. The reachset of the discrete abstraction covers the entire state space, and therefore, the abstraction is judged to be unsafe with the counterexample q₀, q₁, …, q₅. Part of the reachset of this discrete abstraction from q₀ is shown by the shaded grid squares. The validation computation is shown by the light gray arc. Because this arc is disjoint from q₁, the counterexample is spurious.

Now, consider a discrete abstraction ℬ = ⟨Vℬ, Θℬ, 𝒟ℬ⟩ of 𝒜 that is obtained by quantizing the state space of 𝒜. That is, val(Vℬ) is the finite set of grid squares in Figure 8.6. It is convenient to define this abstraction function R: val(V) → val(V ℬ) such that it maps states of 𝒜 to the corresponding grid box. Further, Θℬ = R(Θ) = {q₀} is the grid square containing Θ, and the set of transitions 𝒟ℬ is defined as follows: for a pair of grid squares q, q′, (q, q′) ∈𝒟ℬ if and only if ∃ v ∈ R⁻¹(q), v′∈ R⁻¹(q′), such that there is a trajectory of 𝒜 from v to v′. Thus, from q₀, there are transitions to the three grid boxes to its north, northeast, and east. Here, R⁻¹: val(Vℬ) → val(V ) is the inverse of the abstraction function R and is also called concretization.

8.7.2  Model checker

The model checker takes as input an abstract automaton ℬ (of the chosen class) and decides whether ℬ meets the requirement S. If ℬ violates S, then the model checker has to produce a counterexample, β. The type of requirement S and the choice of the type of abstract automaton determine the type of model checker that we can employ and the efficiency of the check. For example, if ℬ is a timed automaton, then, as we shall see in Chapter 9, model checking against an invariant property S is decidable and the decision procedure can be implemented using UPPAAL (Bengtsson et al., 1996), and this procedure has a worst-case complexity that scales exponentially with the number of clock variables. Alternatively, if the abstraction ℬ is an RHA, then the model-checking problem is technically undecidable, but we can use tools like HyTech (Henzinger et al., 1997) and PHAVer (Frehse, 2005) without the guarantee of termination.

Continuing with the example in Figure 8.6, we see from the definition of the transitions 𝒟ℬ that from q₀, all five numbered gray boxes are reachable, and the Unsafe set is also reachable. Any number of finite state model checkers can be used to compute Reachℬ and infer that ℬ is unsafe.

8.7.3  Counterexample validation

The validation step in the CEGAR loop takes as input an abstract counterexample β of ℬ and checks whether there is a corresponding execution α of the concrete automaton 𝒜. For the example in Figure 8.6, suppose that the counterexample for the discrete automaton ℬ discovered by the discrete model checker is the execution β = q₀, q₁, q₂, q₃, q₄, q₅. In the validation step, we have to check whether there is an execution of the concrete automaton 𝒜 that traverses those regions. One way to implement that is to compute the set of states that are backward-reachable from R⁻¹(q₅) and that touch states in β, and check whether this set intersects with q₀. Described in more detail, we start with S₅ = R⁻¹(q₅) and define S₄ = Pre𝒜(S₅) ∩ R⁻¹(q₄), which is the set of states that can reach R⁻¹(q₅) from R⁻¹(q₄) by following the dynamics of 𝒜. This set S₄ is the dark fragment on q₄ on the right side of Figure 8.6. Because S₄ is not empty, we continue backward:

Following that sequence, S₁ = ∅, and we conclude that there is no execution of 𝒜 that reaches Unsafe along β, and therefore β is a spurious counterexample.

On the other hand, if S₁ were not empty, then the CEGAR loop would have terminated with the conclusion that 𝒜 is unsafe. We note that computing pre𝒜(·) is akin to computing one step of Reach𝒜(T), and that the computation may be as hard as the full verification problem for a nonlinear hybrid 𝒜. In practice, computing one step of pre𝒜 along one transition is often simpler than general reachability analysis.

Exercise 8.9.   Show that the counterexample validation strategy outlined here is sound. That is, if the sequence of states Si = Pre𝒜(Si+1) ∩ R⁻¹(qi) leads to an empty state, then the counterexample is spurious; otherwise, it is genuine.

8.7.4  Refinement strategy

The final step of the CEGAR loop refines an abstract automaton ℬi to a new finer abstraction ℬi+1 based on the counterexample β. The informal intuition is that the refined abstraction Bi+1 ≤ℬi should ideally eliminate the spurious counterexample β. In practice, even if β is not eliminated from Execsℬi+1, so long as some set of spurious counterexamples of ℬi is removed by the refinement process, overall progress and termination of CEGAR can be achieved. Strategies for refinement include the splitting of a single location into multiple locations, the addition of variables, the splitting of transitions, and the addition of higher-order terms in approximating nonlinear dynamics.

For the example in Figure 8.6, an obvious refinement strategy would be to make the quantization grid finer in ℬi+1 around the counterexample β. Axis-aligned grids, however fine, may not eliminate counterexamples like β. By partitioning val(V) using lines (hyperplanes) with different slopes, such as lines tangential to the orbits, we could eliminate β.

8.8  Further reading

CEGAR-type algorithms for different classes of hybrid automata with finite automata abstractions have been developed by Alur et al. (2006); Clarke et al. (2003); and Fehnker et al. (2005). Prabhakar et al. (2015) present a verification algorithm for RHAs that uses them as the space of abstractions. This algorithm uses several types of abstractions (and refinements) in a compositional fashion. Roohi et al. (2017a) present the Hybrid Abstraction-Refinement Engine (HARE) tool for CEGAR-based verification of nonlinear hybrid automata.

8.9  Exercises

Exercise 8.10.   If 𝒜₁ and 𝒜₂ are discrete bisimilar automata with a bisimulation relation R ⊆ val(X₁)×val(X₂), show that Reach𝒜₂ ⊆ R(Reach𝒜₁).

Exercise 8.11.   Consider the billiard system 𝒜 with a single ball (Exercise 4.8) and the satellite system ℬ (Exercise 4.11 in Chapter 4). Show that under appropriate assumptions about the model parameters and variable and action renaming, ℬ is an I/O abstraction for 𝒜. There is some flexibility in how you set up the calculation. To make it interesting, you should assume that both velocity components of the billiard ball are nonzero (vx, vy ≠ 0).

Exercise 8.12.   Prove Corollary 8.10.

¹See Theorem 7.7 in Kaynar et al. (2005).

9

Reachability Analysis

Overview

Is it possible for any behavior of a system 𝒜 to reach any state in the set U? In the quest to answer such safety or invariance verification questions automatically, we will study algorithms and impossibilities. The hardness of automatic safety verification varies depending on the type of the automaton 𝒜 in question (i.e., discrete, continuous, or hybrid, and their various subclasses). We will give a tour of this landscape in this chapter. We start with timed automata, where the question can be answered algorithmically and exactly, even for unbounded time. We will travel all the way to nonlinear hybrid automata, where it is well known that no algorithm can answer the question exactly, and one must resort to approximations even for the bounded time version of the question. On the way, we will encounter the undecidability proof for rectangular hybrid automata (RHAs), and then, to combat undecidability with practical approximations, we will briefly introduce several handy data structures.

9.1  Quick introduction to reachability analysis

Recall that for any automaton 𝒜, a state x is reachable from the set of initial states Θ if there is an execution of 𝒜 that ends at x. Deciding whether a given set of states U is reachable for 𝒜 is the most common type of verification problem. It is called the invariant verification problem or the safety verification problem. Here are some examples:

(Section 2.5 of Chapter 2) Starting from a state with a single token, is it possible for Dijkstra’s token ring algorithm to reach a state with three tokens?

(Section 4.5 in Chapter 4) Is it possible for the two satellites to collide?

(Section 4.6) Could any pair of aircraft on the runway get closer than the required safety separation?

Testing can partially answer such verification questions. That is, one can generate a finite number of executions of 𝒜 from Θ (e.g., by using numerical simulations) and then check whether these executions reach U. If any of the test executions do reach U, then we can answer the verification question: if U represents an undesirable or bad behavior of the system, as in these examples, then such a test execution can be used to debug the system design. But because 𝒜 generally has infinitely many executions, even if a finite number of tests do not reach U, then we cannot say for sure that every execution of 𝒜 does not enter U.

An alternative approach is to compute the set of reachable states Reach𝒜(Θ) of 𝒜. Then, 𝒜 can reach U if and only if the intersection Reach𝒜(Θ) ∩ U is empty. Computation of Reach𝒜(Θ) is called reachability analysis. In general, reachability analysis of hybrid automaton models is a harder problem because it involves infinitely many states and continuous dynamics. The size of the reachable set depends exponentially on the dimension of the model. It also depends on the time horizon and the degree of uncertainty in the model. As the time horizon becomes longer, the diameter of the reachable set typically blows up exponentially. That is an instance of what is popularly called the state-space explosion problem. Progress over the last several decades in addressing this problem has made it possible to apply reachability analysis to practical cyber-physical models. New data structures have been invented for representing the reachable sets succinctly, and algorithms have been developed to exploit them. At the same time, we now have a more nuanced understanding of the classes of models for which reachability analysis is possible.

9.2  Finite automata

Given a finite automaton 𝒜 = ⟨V, Θ, A, 𝒟⟩ and a state v ∈ val(V), the safety verification question is concerned with deciding whether v is reachable. From the definition of invariance, we know that a predicate ϕ over V is an invariant of 𝒜 if and only if Reach𝒜 ⊆ [ [ϕ] ]—that is, none of the states reachable from Θ are in [ [ϕc] ], Reach𝒜∩ [ [ϕc] ] = ∅. This is the invariant verification problem. For Dijkstra’s token ring algorithm, for example, we may want to check ReachDijkstraTR(Θ) ⊆ [ [ϕexactly1] ].

9.2.1  Finite state reachability

For automata with finite state spaces, |val(V)| < ∞, we can explicitly use breadth-first search (BFS) on a graph to check whether there is a path from any state in Θ to some state in [ [ϕc] ]. This problem of checking whether there is a path from a source set S to a target set T in a graph G is called ST-connectivity, and it is a well-studied problem in complexity theory. For the invariant verification problem, the directed graph G = (V, E) is simply defined as V = val(V ) and (v, v′) ∈ E if and only if for some action a ∈ A. The time complexity of the elementary BFS algorithm on automaton 𝒜 is O(|val(V)| + |𝒟|), and the size of the transition relation 𝒟 may vary between O(1) and O(|val(V)|). The space complexity is O(|val(V)|).

Given two sets of vertices S, T ⊆ V, in what follows, we discuss an alternative nondeterministic algorithm for checking whether a path exists from S to T in the graph (Figure 9.1). Recall that a nondeterministic algorithm (formally, a nondeterministic Turing machine) makes choices in its transitions, and that it accepts an input if and only if any of its branches accepts the input; otherwise, it rejects the input.

Figure 9.1
Nondeterministic ST-connectivity algorithm.

The nondeterministic ST-connectivity algorithm STConn takes as input a graph G = ⟨V, E⟩ and a pair of sets of vertices S, T ⊆ V, and it is supposed to accept this input, provided that there is a path (with a maximum length of n = |V|) from some vertex in S to a vertex in T. It nondeterministically constructs paths from S as follows: At first, it chooses a vertex vcurrent in the set S. If the chosen vertex vcurrent is also in T, then the algorithm immediately returns “yes” in line 5. Otherwise, the algorithm iteratively chooses an arbitrary sequence of n vertices vnext one at a time. It rejects this choice of vnext and breaks out of the loop if there is no edge from vcurrent to vnext. If there is an edge (vcurrent, vnext), and if vnext is in T, then it accepts and returns. Otherwise, (vcurrent, vnext) ∈ E but vnext T, in which case the algorithm extends the path by setting vcurrent to vnext, and then moves to the next iteration by choosing another vertex. If none of the initial choices in S and the choices of paths lead to T, then STConn returns “no.”

Proposition 9.1 states that the algorithm is correct and it requires only O(log n) bits of memory for a graph with n vertices. Using a construction developed by Savitch (1970), we get a deterministic version of the algorithm that uses O(log ²n) space. The remarkable result of Reingold (2008) shows that ST-connectivity for undirected graphs can in fact be solved in O(log n) space.

Proposition 9.1.   Algorithm STConn in Figure 9.1 accepts the inputs if and only if there is a path from S to T in the input graph G. In addition, it uses O(log n) bits of memory and O(n) time steps, where n is the size of the set of vertices V.

Exercise 9.1 (Same as Exercise 2.4 in Chapter 2).   Prove Proposition 9.1. Recall that a nondeterministic Turing machine accepts an input if any of the computing branches halt in an accepting state (see Appendix B).

Exercise 9.2.   Given an automaton model 𝒜 = ⟨V, Θ, A, 𝒟⟩ with finite state space val(V) and a candidate invariant property ϕ over V, show that STConn can be employed to check whether ϕ is an invariant of 𝒜.

9.3  Timed automata

One can generalize finite automata in different directions by adding variables of different infinite types. In this section, we add real-valued clocks and study the reachability analysis of the resulting timed automata. Because timed automata have uncountably infinite state spaces, the BFS-based approach, which relies on explicit state enumeration, is not directly applicable. A key observation changes the situation: many states of a timed automaton behave identically. In fact, all the infinitely many states of a timed automaton can be lumped into finitely many state regions in such a way that all the states in a region behave identically. Once those regions are identified, we can again apply the BFS strategy to the resulting finite state machine (FSM)—a region automaton. This algorithmic analysis of timed automata was proposed by Alur and Dill (1994). The lumping or aggregation of similarly behaving states into regions is a general strategy that has currency beyond the reachability analysis of timed automaton models.

In Section 4.3.6 of Chapter 4, we introduced timed automata as a special class of hybrid automata. In the remainder of this section, we present a reachability analysis of timed automata, beginning with a more detailed discussion of the model.

9.3.1  Syntax for timed automata

Recall that a clock variable, or simply a clock, x is a real-valued variable for which the dynamics is always given by d(x) = 1. That is, along any trajectory τ of x, for any t ∈ τ.dom, τ(t) = τ(0) + t.

Definition 9.1.   For a set of clock variables X, an integral clock constraint is a predicate built up using the following syntax:

where x is a clock variable in X, q is an integer constant, and C, C₁, and C₂ are clock constraint expressions.

For example, the expression x ≤ 10 ∧ y ≥ 6 is a clock constraint with clock variables x and y. A valuation x of X satisfies a clock constraint C over X, written as xC, if for every clock x ∈ X, x ⌈ x meets the constraints in C. More precisely,

The semantics of clock constraints over X is given in terms of subsets of val(X) that satisfy the constraints. For a clock constraint C, the corresponding set of valuations in val(X) is denoted by [ [C] ] and is defined as [ [C] ] = {x ∈ val(X) | xC}.

Exercise 9.3.   Show that the following sets involving clock variables x and y can be rewritten as semantically equivalent integral clock constraints: (a) x = 5; (b) x > 5 ∨ y ≤ 5; (c) x ∈ [3, 5).

An integral timed automaton (ITA) is a simple hybrid automaton with only clock variables (recall Definition 4.2). That is, it has a single discrete variable loc of finite type, and all the continuous variables are clocks. In addition, the transition guards and invariants are defined by integral clock constraints and propositional assertions on the location, and the reset functions either set the clocks to 0 or leave them unaltered.

Definition 9.2.   An ITA 𝒜 is a tuple 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩, where:

(a) V = X ∪{loc} is a set of variables, X is a set of n clock variables, and loc is a single discrete variable with finite type L; the elements of L are called locations.

(b) Θ ⊆ val(V) is a nonempty set of start states specified by values of loc and clock constraints.

(c) A is a finite set of actions.

(d) 𝒟⊆ val(V) × A × val(V ) is a set of transitions such that

For each a ∈ A, there exists an integral clock constraint C on X, such that Enabled(a) = [ [C] ].

For any transition v v′, v′⌈ x = 0 or v′⌈ x = v ⌈ x.

(e) 𝒯 is a set of trajectories for the variables in V. For each x ∈ X, the trajectory is specified by d(x) = 1 and mode invariants that are integral clock constraints. That is, for each τ ∈𝒯, (τ ↓ x)(t) = τ(0) ⌈ x + t.

ITAs have limited expressive power in capturing dynamics precisely. They have been used to model and analyze timing aspects of cyber-physical systems (CPS), clock-based network protocols, real-time systems, distributed algorithms, and models for which dynamics is abstracted to timing of events (Havelund et al., 1997; Lim et al., 2005; Behrmann et al., 2004; Fehnker et al., 2007; Bérard et al., 2004).

9.3.2  Example: Timed light switch

The ITA Switch shown in Figures 9.2 and 9.3 specifies a motion-sensing light switch with two clocks. The two clock variables are x and y, and the set of locations L = {on, off}. If the switch is on (i.e., loc = on) for more than 10 seconds as measured by the clock y, and no turnOn action occurs in the meantime, then the turnOff action must occur. The effect of this action is to turn the switch off and reset the timer x to 0. The turnOn action may occur once every 2 seconds, as measured by the clock x. When it does occur, it sets the switch on and resets both clocks to 0. The onoff mode specifies the trajectories of the automaton. The turnOn transitions are not urgent (i.e., they may be ignored even when the precondition holds). In contrast, the turnOff transitions are urgent because of the mode invariant for onoff.

Figure 9.2
ITA model of motion-sensing timed switch.

Figure 9.3
Circle arrow diagram for the light switch automaton Switch from Figure 9.2.

A sample execution of the Switch automaton is as follows:

9.3.3  Clock equivalence relation on states

One of the remarkable properties of ITAs is that they can be faithfully abstracted by FSMs that preserve many interesting properties. Although the clocks make the state space of ITAs uncountably infinite, it turns out that many states of an ITA behave identically. This notion of identically behaving states is formalized by the clock equivalence relation, defined next. Here, int(v ⌈ x) and float(v ⌈ x) denote the integral and fractional parts of the valuation of the clock variable x at state v, respectively.

Definition 9.3.   Consider an ITA 𝒜 with set of variables V = X ∪{loc}. We define the clock equivalence relation R ⊆ val(V) × val(V ) as v R v′ if and only if

(a) v ⌈ loc = v′ ⌈ loc.

(b) For each clock x ∈ X, either int(v ⌈ x) = int(v′ ⌈ x) or both int(v ⌈ x), int(v′ ⌈ x) > c𝒜x, where c𝒜x is the largest integer constant with which x is compared in the clock constraints that appear in the specification of 𝒜.

(c) For each clock x ∈ X with v ⌈ x ≤ c𝒜x, float(v ⌈ x) = 0 iff float(v′ ⌈ x) = 0.

(d) For any two clocks x, y ∈ X with v ⌈ x ≤ c𝒜x and v ⌈ y ≤ c𝒜y, float(v ⌈ x) ≤ float(v ⌈ y) iff float(v′ ⌈ x) ≤ float(v′ ⌈ y).

The first two parts of this definition are straightforward, and they state that two states are equivalent provided that (1) they have the same location, and (2) the integral parts of each clock match up to the maximum value that matters in 𝒜. That makes sense because if the integral parts did not match, then the states could satisfy different clock constraints in 𝒜 and thus could behave differently. Further, clock values beyond the maximum constant c𝒜* are irrelevant to determining the behavior of 𝒜, and therefore it makes sense to restrict (b) to values below c𝒜*. The last two conditions ensure that the same sequence of transitions can occur from equivalent states, even if the exact timings of those transitions are slightly different. Condition (c) states that for each clock, the fractional parts are either both zero or both nonzero. The last condition states that for each pair of clocks, the orderings of the fractional parts are identical. Thus, two states v and v′ are equivalent even if the fractional parts of the various clock values are not identical but satisfy identical nonzero and ordering conditions. This ordering condition ensures that as time elapses from v and v′, the order in which the clocks x and y hit the next integral values will be the same, and that ensures that the ordering of transitions will be the same. Thus, states related by R behave identically with respect to transitions and trajectories. That is stated in Proposition 9.2.

Proposition 9.2.   Consider two equivalent states v₁ and v₂ of ITA 𝒜 such that v₁ R v₂:

(a) If 𝒜 has a valid transition , then there exists a corresponding transition and .

(b) If 𝒜 has a trajectory τ ∈ 𝒯 with v₁ = τ.fstate, then there exists a corresponding trajectory τ′ (possibly of different duration) such that v₂ = τ′.fstate and τ.lstate R τ′.lstate.

The proof of this proposition uses the definition of the clock equivalence relation R and is left to Exercise 9.4.

Exercise 9.4.   Prove Proposition 9.2.

If we use Proposition 9.2, the proof of Theorem 9.3, which implies that equivalent states reach the same locations, is straightforward.

Theorem 9.3.   Consider two equivalent states v₁ and v₂ of ITA 𝒜 such that v₁ R v₂ and an execution fragment α starting from the first α.fstate = v₁. Then there exists an execution fragment α′, with α′.fstate = v₂ with α.lstate R α′.lstate.

Proof. We fix two states v₁, v₂ ∈ val(V) such that v₁ R v₂ and an execution α with α.fstate = v₁. We construct the execution α′ by induction on the length of α, and show that it has the desired property. For the base case, α is an execution with a point trajectory at α.fstate. We construct α′ also as a point trajectory, with α′.fstate = v₂. Because v₁ R v₂, the result follows trivially.

For the inductive case, we have the hypothesis that for an execution α of a certain length, there is another execution α′ such that α.lstate R α′.lstate. There are two types of extensions of α to consider. Case 1: α₁ = αaτ, where a ∈ A and τ is a point trajectory such that . Using Proposition 9.2(a), we extend such that α₁.lstate R . Case 2: α₁ = ατ, where τ is concatenated with the last trajectory in α to extend its duration. Using Proposition 9.2(b), we extend such that R α₁′.lstate.

The clock equivalence relation defines a partition of the state space val(V) with sets of different characteristic shapes. These equivalence classes are called clock regions. For a clock region r, the corresponding set of states of 𝒜 is denoted by [r]. For an automaton with two clocks, the clock regions are singleton sets (points corresponding to integer clock valuations), axis-parallel open intervals, diagonal lines corresponding to states where the fractional parts of the clocks are equal, and open triangles. The clock regions for the Switch automaton are shown in Figure 9.4.

Figure 9.4
The equivalence classes (clock regions) of the clock equivalence relation for ITA Switch for loc = on.

Exercise 9.5.   Write parameterized definitions for each clock region for the Switch automaton. For example, for the singleton clock regions, Pi, j {v | v ⌈ x = i, v ⌈ y = j}, where i, j ∈ ℕ, i ≤ 2, j ≤ 10. Calculate the number of clock regions of each type.

Exercise 9.6.   For a general ITA with n clocks and |L| locations, show that the number of clock regions is upper-bounded by |L|n!2nΠi≤n(2ci + 2), where ci > 0 is the largest constant that appears in clock constraints for the ith clock.

For a clock region r, its time successors are all the clock regions that can be reached from [r] if time is allowed to advance. In Figure 9.4, the successive time successors, starting from the open segment clock region x = 0, 0 < y < 1, are shown shaded.

9.3.4  Control state reachability and region automata

Given an ITA 𝒜 and a location ℓ of A, the control state reachability (CSR) requires us to decide whether ℓ is reachable in 𝒜. That is, CSR aims to answer the question of whether ℓ ∈ Reach𝒜 ⌈ loc. Is the CSR problem a shift from the reachability problem at the beginning of this chapter? It turns out that a solution to CSR is sufficient to answer questions related to reachability and safety that are specified using clock constraints.

Exercise 9.7.   Consider the safety verification problem. Is it possible for an ITA 𝒜 to reach an unsafe set U, where U is specified by integral clock constraints? Show how an algorithm for deciding CSR can be used to solve safety verification.

In the remainder of this section, we develop an algorithm for solving CSR by using Theorem 9.3 in two steps. Recall that the clock regions define a finite partition of the state space of the ITA 𝒜. First, we define a finite automaton R(𝒜) with those regions as states. We shall see that the region automaton R(𝒜) behaves identically to 𝒜 with respect to CSR (Theorem 9.4). Then, in the second step, we solve the reachability of R(𝒜) using the BFS of Section 9.2.

Definition 9.4.   Given an ITA 𝒜 = ⟨(X ∪ loc), Θ, A, 𝒟, 𝒯⟩, the corresponding region automaton is a finite state automaton R(𝒜) = ⟨V′, Θ′, A′, 𝒟′⟩, where:

(a) V′ = {q, loc′} is a set of state variables with type(q) equal to the set of clock regions of 𝒜 and type(loc′) = type(loc). A single valuation v′ ∈ val(V) corresponds to a single clock region, and thus to a set of valuations of the clocks in X that meet the corresponding clock constraints. We state that

(b) Θ′ = {v′ ∈ val(V′) | ∃ v ∈ Θ, v ∈ [v′]} corresponds to a set of clock regions that satisfy Θ.

(c) A′ = A ∪{τ} is the set of actions that includes a special action named τ A.

(d) 𝒟′⊆ val(V′) × A′ × val(V′) is the set of transitions defined as follows. A transition is in 𝒟′ iff one of the following conditions holds:

a′∈ A, and there exists such that , or

a′ = τ A, and the clock region is a time successor of .

The region automaton construction for a simple ITA is shown in Figure 9.5. The ITA SimpleTimer has a single location l₁ and a single clock x initialized to 0. After 2 seconds, the reset action is enabled. When the action occurs, it resets the clock to 0 and thus disables the action for the next 2 seconds. The largest integral constant to which the clock x is compared in SimpleTimer is c𝒜x = 2. The six finite states of the region automaton R(SimpleTimer) that correspond to the clock regions of SimpleTimer are x = 0, x ∈ (0, 1), x = 1, x ∈ (1, 2), x = 2, and x > 2. Those states are shown in Figure 9.5, with the corresponding regions as the labels. From each state, there is a transition to the state that corresponds to its time successor. The transitions are labeled with τ. In addition, there are two transitions that correspond to the reset action from the states x = 2 and x > 2 to the state corresponding to x = 0.

Figure 9.5
The SimpleTimer automaton. Top: The timer automaton. Bottom: The corresponding region automaton.

Theorem 9.4 relates the infinite ITA 𝒜 to its corresponding region automaton R(𝒜). Specifically, the relation R₁₂ that relates a state of 𝒜 to a state (clock region) of R(𝒜) is a time-abstraction bisimulation relation from 𝒜 to R(𝒜) (see Definition 8.7). That relation says that each transition and trajectory of 𝒜 can be simulated by some transition of R(𝒜), and vice versa. Described in more detail, from every pair of R₁₂-related states, v₁ of 𝒜 and v₂ of R(𝒜), if 𝒜 can perform an action, then so can R(𝒜), and the resulting states are related by R₁₂. Similarly, if 𝒜 can evolve according to a trajectory, then R(𝒜) can do a τ-transition and the resulting states will be related. Conversely, if v₂ can make a τ-transition, then v₁ can evolve according to a corresponding trajectory; and if v₂ can make an a-transition, then so can v₁. In both cases, the resulting states are related by R₁₂. The proof of the theorem involves checking that this relation R₁₂ meets all the conditions given in Definition 8.7, or alternatively, directly using Proposition 9.2.

Theorem 9.4.   Given an ITA 𝒜₁ and the region automaton 𝒜₂ = R(𝒜₁), the relation R₁₂ ⊆ val(V₁) × val(V ₂) defined as (v₁, v₂) ∈ R₁₂⇐⇒v₁ ∈ [v₂] is a time-abstract bisimulation relation.

This theorem is surprising because it establishes that, at least with respect to the decidability of time-abstract analysis, ITAs are no more powerful than good old FSMs. That said, ITAs can be a more natural modeling framework for certain types of CPS. Also, there is an exponential blowup in the size of the region automaton when the ITA is translated into an FSM. Corollary 9.5 follows immediately from Theorem 9.4, and, together with the reachability algorithms for finite automata (from Section 9.2), it gives an algorithm for solving the CSR problem for ITA.

Corollary 9.5.   Given an ITA 𝒜 and its region automaton R(𝒜₁), a particular location ℓ ∈ L is reachable in 𝒜 iff it is reachable in R(𝒜).

9.4  Integral timed automata to rectangular hybrid automata

In this section, we will peel away the constraints on ITA in small steps and study the reachability for increasingly more general classes of automata models.

9.4.1  Rational timed automata

A rational clock constraint is a predicate on clock variables that is defined exactly in the same way as integral clock constraints are (Definition 9.1), except that the clock variables are allowed to be compared with rational constraints. A rational timed automaton (RTA) is defined in exactly the same way as an ITA (Definition 9.2), except that the guards and mode invariants can be rational clock constraints. For example, if we replace the constants 2 and 10 in the automaton Switch (Figure 9.2) with 2.25 and 10.5, respectively, the resulting automaton will be an RTA.

Exercise 9.8.   For a RTA 𝒜₁, construct an ITA 𝒜₂ that makes them time-abstract bisimilar.

The construction developed in Exercise 9.8 tells us that CSR for an RTA can be solved by first converting it to an ITA.

9.4.2  Multirate automata

A multirate automaton is a simple hybrid automaton in which each continuous variable x ∈ X evolves at a constant rate kx across all modes. For example, each continuous variable can model a clock, a drifting clock, or a motion at a constant speed.

Definition 9.5.   A multirate automaton is a simple hybrid automaton 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩ for which:

  (i) All guards and mode invariants are rational clock constraints over X (recall V = X ∪{loc}).

 (ii) For a transition , either v′ ⌈ x = qa, for some qa ∈ ℚ, or v′ ⌈ x = v ⌈ x.

(iii) For each x ∈ X, there exists a constant kx ∈ ℚ such that in each mode, trajectories are defined by d(x) = kx [i.e., for each τ ∈ 𝒯, (τ ↓ x)(t) = τ(0) ⌈ x + kxt].

An RTA is a special type of multirate automaton in which kx = 1 for every variable x ∈ X, and qa = 0 for every action a ∈ A.

Exercise 9.9.   Given a multirate automaton 𝒜₁, construct an RTA 𝒜₂ such that the two are time-abstract bisimilar.

From the construction created in Exercise 9.9, it follows that CSR for a multirate automaton can be solved by first converting it into an RTA, converting the resulting RTA to an ITA, and then using STConn on the resulting ITA. Thus, the CSR problem continues to be decidable for multirate automata.

9.4.3  Rectangular hybrid automata

The class of rectangular hybrid automata (RHA) generalizes multirate automata by allowing nondeterministic trajectories and resets. In Section 4.3.5 of Chapter 4, this class was introduced informally. Here is the precise definition.

Definition 9.6.   An RHA is a simple hybrid automaton 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩, where:

(i) All guards and mode invariants are rectangles over X.

(ii) For a transition , there exist either la, ua ∈ ℚ and v′ ⌈ x ∈ [la, ua], or v′ ⌈ x = v ⌈ x.

(iii) For each x ∈ X and each location ℓ ∈ L, there exist lx, ux ∈ ℚ such that trajectories are defined by d(x) ∈ [lx, ux] [i.e., for each τ ∈ 𝒯, τ(0) ⌈ x + lxt ≤ (τ ↓ x)(t) ≤ τ(0) ⌈ x + uxt].

Can we transform an RHA into a time-abstract bisimilar multirate or timed automaton? More generally, does the CSR problem continue to be decidable for this class? It turns out that it is not. That is, there is no algorithm for answering CSR queries for an RHA accurately. We will see the proof of this in Section 9.5.

Example: Air traffic management

The Small Aircraft Transportation System (SATS) model introduced in Section 4.6 of Chapter 4 is an RHA after we make a few syntactic adjustments. Consider an instance of the SATS template in Figure 4.12 in Chapter 4 for a fixed number of aircraft (e.g., n = 3). First, we note that this is a simple hybrid automaton. The type ID is a finite type, and thus the automaton has three finite-valued discrete variables (status, next, and last) and a single ℝn-valued continuous variable x. Although the SATS model, as written, does not have a single finite-valued discrete variable called loc, it would be simple (but tedious) to rewrite the model to fit that structure with 6n+1 × (n + 1)n+1 × n + 1 locations. Further, the trajectory specifications for the various locations are lumped into two modes, Traverse and Hold, that specify the dynamics of each x[i] based on the valuation of status[i].

Let us check the three parts of Definition 9.6.

1. Observe that for every action, the guard compares the x[i] only with constants like LBase, LFinal, and LMAL. Therefore, the guards are rectangular. The mode invariants and stopping conditions also compare x[i] only with constants.

2. For each transition, x[i] is either left unchanged or reset to 0.

3. For each variable x[i] and each location, the variable’s evolution is given by either d(x[i]) ∈ [vmin, vmax] or d(x[i]) = 0.

9.5  Undecidability of control state reachability for rectangular hybrid automata

In this section, we will find that the CSR problem for RHAs is undecidable. The implication is that automatic verification of invariants and safety properties is also impossible for this class of models. The result was shown by Henzinger et al. (1998) through a reduction from the halting problem of two-counter machines (2CMs).

9.5.1  Two-counter machines

An n-counter machine is an elementary computer with n-unbounded counters and a finite program written in a minimalistic assembly language. A more precise description is given in Definition 9.7.

Definition 9.7.   A 2CM is a discrete transition system with the following components:

(a) Two nonnegative integer counters C and D, both initialized to 0.

(b) A finite program with one of these instructions at each location (or line):

INCC, INCD: increments counter C (or D).

DECC, DECD: decrements counter C (or D), provided that it is not 0.

JNZC, JNZD ⟨label⟩: moves the program control to line label, provided that counter C (or D) is not zero.

A 2CM for multiplying 2 × 3 is shown below. What else can 2CMs do?

Exercise 9.10.   Show that any k-counter machine can be simulated by a 2CM.

Exercise 9.10 suggests that having two counters is as good as having any finite number of counters. It turns out that 2CMs can decide everything that a Turing machine can! The argument is a sequence of reductions. First, for any k-counter machine, there is a 2CM that can simulate its computations. The idea is to have counter C of the 2CM encode all the k counters, and to use D for performing the increments and decrements on these counters. Next, a four-counter machine (4CM) can simulate a machine with two stacks, and, finally, a two-stack machine can simulate a Turing machine. That computing power of 2CMs implies that the Halting problem for 2CMs is undecidable. To state that precisely, we first define executions of 2CMs.

A configuration of a 2CM M is a triple ⟨pc, C, D⟩, where pc is the program counter that stores the next line to be executed by M, and C and D are the valuations of the two counters. A sequence of configurations ⟨pc₀, D₀, C₀⟩, ⟨pc₁, D₁, C₁⟩… is an execution of M if the ith configuration goes to the (i + 1)st configuration in the sequence after M executes the instruction in line pci. For example, the sequence ⟨1, 0, 0⟩, ⟨2, 1, 0⟩, ⟨3, 2, 0⟩, ⟨4, 2, 1⟩, ⟨5, 2, 2⟩, ⟨6, 2, 3⟩, ⟨7, 1, 3⟩, … ⟨7, 0, 6⟩, ⟨8, 0, 6⟩ is an execution of the machine depicted in Figure 9.6.

Figure 9.6
A 2CM’s program for computing 2 × 3.

Given a 2CM M and a special halting location ℓ, the halting problem requires us to decide whether all executions of M reach the halting location ℓ. For example, the execution given here is also a halting execution. Minsky (1967) established that the halting problem for 2CM is undecidable.

Theorem 9.6.   The halting problem for 2CMs is undecidable.

9.5.2  Reduction of control state reachability of rectangular hybrid automata to the halting problem of two-counter machines

In Henzinger et al. (1998), the CSR problem for RHAs is reduced to the halting problem of 2CMs, which, together with Theorem 9.6, establishes the undecidability of the former. Here, we will sketch the reduction. Given a 2CM M and a halting location ℓ, the reduction carefully constructs an RHA 𝒜M such that 𝒜M reaches the special halting location if and only if M also reaches ℓ. M evolves through discrete transitions, and 𝒜M evolves over continuous time, so in what way does 𝒜M simulate M? It turns out that at specific discrete points in time, the state 𝒜M will be related in a precise manner to the state of M, along any execution.

Let L be the set of locations (line numbers) of the 2CM M. The automaton 𝒜M will use three real constants, W > k₁ > k₂ > 0. The RHA 𝒜M = ⟨V, Θ, A, 𝒟, 𝒯⟩ has a single discrete variable loc of type L. The set of variables V contains two real-valued variables, c and d, that correspond to the counters C and D of M. Specifically, the relationship

will hold at certain crucial points in time. Each location of M will correspond to a single location or a sequence of locations in 𝒜M. An instruction of INCC at a location of M will correspond to a sequence of locations in 𝒜M that effectively multiply c by . A DECC instruction will correspond to first checking if c < k₁, and if it is, multiplying it by . The INCD and DECD instructions are similarly handled. Next, we define two automaton fragments that will carry out each of the abovementioned tasks. Through the stitching together of instances of the fragments, the RHA 𝒜M is constructed.

In all the automata fragments, the execution of the automaton starts when the entry transition (on the left of the diagrams) is performed, and it ends when the exit transition (on the right) is performed. In between, there may be other transitions. The statements enclosed in square brackets [] are the preconditions for the transitions, and those enclosed in curly brackets {} are effects. The continuous variable a acts like an ordinary clock: it is set to 0 when the execution of the automaton starts, and when it reaches the value W, the exit transition occurs.

The automaton fragment on the left side of Figure 9.7 is useful for understanding the other automata. Suppose that the value of the variable c = x for some x > 0 when the entry transition occurs. At time after entry, the top transition occurs, setting c to 0. At time after that, the exit transition occurs with the value of the clock . Those transitions are called wrapping as they keep the value of W, k₁W, and the other continuous quantities within range. Thus, from entry to exit, a total of W time units elapse and a top transition occurs, but the value of c remains unaltered, at x.

Figure 9.7
Automaton fragments for reducing an RHA to a 2CM. Left: Simple rectangular hybrid automaton (SRHA) demonstrating wrapping and value preservation. Right: SRHA implementing JNZC.

The automaton fragment on the right side of Figure 9.7 leaves the values of c and d unaltered but exits through the upper outgoing transition if c < k₁; otherwise, (c = k₁) exits through the lower outgoing transition. Thus, this fragment implements JNZC.

The automaton fragment in Figure 9.8 multiplies the initial value of c by and leaves the value of d unaltered. To see that, let c = x and d = y at the entry transition. Note that d = y at the time of the intermediate and exit transitions. The top transition in the first location occurs W − x time units after entry and sets c and z to 0. The intermediate transition occurs x time units after that, when a = W and z = k₂x. The top transition in the second location occurs time units after entering it. It again sets c and z to 0. Finally, the exit transition occurs after another time units when . One can construct a similar automaton fragment for DECC by prepending this above fragment with a check c > k₁ and switching the rates of z in the two locations.

Figure 9.8
SRHA implementing counter increment C + +; that is, .

Given a 2CM M, we create instances of RHA fragments that perform each of the instructions in M and connect the entry and exit transitions of these fragments appropriately. We identify the location of 𝒜M that corresponds to the special halting location ℓ of M. It follows from this construction that 𝒜M reaches the halting location if and only if M halts at ℓ.

Theorem 9.7.   The CSR problem for RHAs is undecidable.

9.5.3  Initialized rectangular hybrid automata

In the previous sections of this chapter, we saw that ITAs can be generalized to RTAs and then to multirate automata, all the while preserving the decidability of CSR. Theorem 9.7 shows that the extension to RHAs breaks decidability, and therefore also makes algorithmic verification of invariants and safety properties impossible. Where is the boundary for decidability? In other words, what restricted class of RHA can make CSR decidable? It turns out that if the continuous variables are forced to be initialized every time their dynamics changes, that is adequate to make the problem decidable again. The resulting class of hybrid automata is called initialized rectangular hybrid automata (IRHA).

Definition 9.8.   An IRHA is an RHA 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩ satisfying conditions (i)–(iii) of Definition 9.6 with the following additional property:

(iv) For any transition with ℓ ≠ ℓ′, if for any x ∈ X, the dynamics of x in ℓ is different from that in ℓ′, then x′ ⌈ x ∈ Ia, x for a fixed reset interval Ia, x.

Example: IRHA

The automaton of Figure 9.9 is a simple hybrid automaton. The set of variables V = {loc, x, y} with type(loc) = L = {l₁, …, l₄}, type(x) = type(y) = ℝ. The circles correspond to the four locations, and the arrows correspond to the transitions. For each transition, the precondition (guard) is the predicate in [], and the effect is written in {}. Because the dynamics of both x and y are rectangular in every location and all the guards and resets are rectangles, this is an RHA.

Figure 9.9
An IRHA.

Next, we need to check whether this is an IRHA. Observe that the dynamics of x in l₁ is different from that in l₃, and therefore, to satisfy (iv) of Definition 9.8, the transition from l₁ to l₃ must reset x. That is indeed the case for the automaton of Figure 9.9. On the other hand, the dynamics of y does not change going from l₁ to l₃; it is not necessary for y to be reset, and it isn’t. After checking all the other transitions similarly, we conclude that this automaton is an IRHA.

With the initialization restriction in place, it turns out that the CSR problem becomes decidable for IRHA. The key idea is to convert the given IRHA 𝒜 = (X ∪{loc}, Θ, A, 𝒟, 𝒯 ) into a multirate automaton 𝒜′ = (X′∪{loc}, Θ′, A′, 𝒟′, 𝒯′) by introducing for every variable x ∈ X, two continuous variables xl, xu in X′ such that they track the lower and the upper bounds of x, respectively.

Exercise 9.11.   Show that the CSR problem is decidable for IRHA.

Other decidable hybrid automata classes   Several other classes of hybrid automata have been identified in the literature for which the CSR problem is decidable. The decidability in all these cases is proved by demonstrating the existence of a finite, computable partition of the state space that is bisimilar to the original automaton. Of particular note are the order-minimal (or o-minimal) hybrid automata of Lafferriere et al. (2000) and the STORMED hybrid automata of Vladimerou et al. (2008). Roughly, an order-minimal theory in mathematical logic is a theory in which every definable subset of ℝ is a finite union of points and possibly unbounded intervals. Lafferriere et al. (2000) define o-minimal hybrid automata as initialized automata whose guards, invariants, resets, and initial sets are all definable in an o-minimal theory, and show that such automata admit a finite bisimulation. A STORMED hybrid automaton also requires the guard, invariant, and other sets to be definable in an o-minimal theory, but it allows noninitialized continuous variables with additional requirements on the guards to be separated and the flows to be monotonic.

9.6  Relaxing the verification problem

CSR is a lofty formulation of the safety verification problem, which can be used to check the safety of an automaton 𝒜 with respect to an unsafe set U, exactly and forever. In the previous sections, we have seen that CSR is a difficult problem even for RHA—that is, solving CSR or computing reachable states Reach𝒜 exactly and for unbounded time is impossible for large classes of hybrid automata. For automata from these larger classes, therefore, it makes sense to aim to solve a more relaxed safety verification problem. The relaxation comes in two ways. First, instead of unbounded time, we will be satisfied if we can verify the safety of 𝒜 up to a given time bound T. Second, instead of insisting on an exact answer, we will tolerate some false positives. That is, the verification algorithm may say that the system is unsafe when it isn’t.

To solve that relaxed safety verification problem, it suffices to compute overapproximations of Reach𝒜(Θ, T)—that is, the set of reachable states of 𝒜 from the initial set Θ up to time T. To see that, suppose that R ⊇ Reach𝒜(Θ, T) is such an overapproximation and U is an unsafe set. If R ∩ U = ∅, then we can infer that Reach𝒜(Θ, T) ∩ U is also empty, and 𝒜 is safe up to T. On the other hand, if R ∩ U ≠ ∅, then we cannot conclusively say that A is unsafe because the states in R ∩ U may not be in Reach𝒜(Θ, T), and this may contribute to spurious reachable states and false alarms.

9.6.1  Bounded reachability analysis

The basic algorithm for computing overapproximations of the reachset Reach𝒜(Θ, T) of a hybrid automaton 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩ is shown in Figure 9.10. It takes as input the automaton 𝒜 and a positive parameter d, and it outputs the computed reachset. Abstractly, in the ith iteration, the algorithm computes (i.e., overapproximates) the states that can be reached from the initial set via execution fragments of length i, where each individual trajectory has a maximum length of d. The program variable Rt stores the set of states discovered to be reachable in the current iteration, and Reach accumulates all the reachable states. Those variables are initialized to Θ and ∅, respectively. The While-loop (line 6) terminates at an iteration in which no new reachable states are discovered. In each iteration of the While-loop, new reachable states are computed from Rt through computation of the set of states that are reachable by a single discrete transition:

Figure 9.10
Basic reachability algorithm.

followed by computation of the states that are reachable by a single trajectory with a maximum length of d:

Proposition 9.8.   If the BasicReach terminates and all the sets and functions are computed exactly, then the output set Reach is equivalent to the set Reach𝒜 of reachable states of the automaton 𝒜.

Exercise 9.12.   Prove Proposition 9.8.

Exercise 9.13.   Suppose that we force the While-loop in the algorithm to terminate after k iterations. What can we say about the corresponding output set Reachk?

Exercise 9.14.   Name two classes of hybrid automata, such that BasicReach is guaranteed to terminate for each member 𝒜 of those classes. That is, the individual steps of the algorithm can compute exact quantities and terminate.

Exercise 9.15.   Show that if we replace Θ, Post𝒟, and Post𝒯 (d) with their overapproximations , and in BasicReach, and if the BasicReach algorithm terminates, then the output Reach is an overapproximation of Reach𝒜(Θ).

There are two reasons for working with overapproximations. First, as mentioned earlier, the functions Post𝒟 and Post𝒯 (d) could be impossible to compute exactly. Second, Equations (9.2) and (9.3) define sets and functions mathematically. Because all those objects are infinite, explicit representations of them (as in Section 9.2.1) cannot be used to implement them on a computer, and therefore the objects have to be represented and manipulated using finite data structures. Sets of states, such as the set Θ, have to be represented by data structures, such as a finite list of vertices of a polyhedron, and the Post𝒟 function has to take this list as the input and produce as output another list (polyhedron) corresponding to Post𝒟(Θ). That introduces a second source of error. Therefore, the choice of the right representation (i.e., the data structures) critically influences both the accuracy and the running time of BasicReach.

9.7  Data structures for reachability analysis

A big driver of the improvement of reachability analysis has been new data structures for representing sets of states—such as hyperrectangles, ellipsoids (Kurzhanski and Varaiya, 2000), polytopes (Halbwachs et al., 1994), zonotopes (Girard, 2005; Girard and Le Guernic, 2008), support functions (Le Guernic and Girard, 2009), and generalized star sets (Duggirala and Viswanathan, 2016)—and algorithms for operating on them. In this section, we will briefly examine how the BasicReach algorithm can be instantiated with specific data structures to compute the reachset overapproximations.

Let us consider the Generic hybrid automaton shown in Figure 9.12, which is parameterized by several quantities: n, Ga, Gb, Ra, Rb, f₁, and f₂. The automaton has a single continuous variable x that takes values in ℝn and two locations {loc₁, loc₂}. For i ∈{1, 2}, the system evolves according to the differential equation , while loc = loci; here, fi: ℝn → ℝn is a continuous function. A transition from loc₁ to loc₂ may occur when x ∈ Ga, and when it does occur, then loc is set to loc₂ and the continuous state is reset to Ra(x). Transitions from loc₂ to loc₁ are defined similarly, by the parameters Gb and Rb. Here, the parameter types are as follows: Ra, Rb: ℝn → ℝn are reset functions, and Ga, Gb: ℝn → 𝔹 are guard or precondition predicates. Notice that this automaton may ignore the guards and resets, as there are no invariants (or stopping conditions) that force the transitions to occur. Extension of the reachability algorithm to handle invariants, as well as models with many more transitions and modes, will be straightforward.

In the rest of this section, we will discuss several data structures for representing sets in ℝn for implementing BasicReach. Figure 9.11 shows some of the common data structures and their operations.

Figure 9.11
Data structures and operations. From top: hyperrectangles, ellipsoids, zonotopes, and polytopes. The Minkowski sum (⊕) of the dark gray and the black sets is shown in the second column. Propagation under dynamics is shown in the third column. Ellipsoids are not closed under ⊕. Polytopes are closed, but computation of the result can be exponential.

Figure 9.12
A generic model of a hybrid automaton.

9.7.1  Rectangles

A hyperrectangle is the n-dimensional generalization of an interval [a, b]. Hyperrectangles are simple to represent and manipulate and have been used in several verification tools, including d/dt (Asarin et al., 2000) and C2E2 (Duggirala et al., 2013). A hyperrectangle R in ℝn can be represented by two vectors, g₁, g₂ ∈ ℝn, which define its diagonally opposite corners:

The vectors g₁ and g₂ are called the generators of the rectangle R. An equivalent alternative representation would be a Cartesian product of a sequence of n-intervals [g1i, g2i] in ℝ.

Representing RHA with rectangles   Rectangular sets can naturally represent RHAs. Consider a concrete instance of the Generic hybrid automaton 𝒜 portrayed in Figure 9.12, for which the guards, invariants, and other elements are represented by hyperrectangular sets and functions. The guards (Ga, Gb) and resets (Ra, Rb) are defined by corresponding n-dimensional generator vectors. The dynamics in each mode is rectangular (i.e., for generators g₁ and g₂).

Reachability analysis with rectangles   Consider implementing the BasicReach algorithm for the RHA 𝒜 represented (as described previously) with hyperrectangles. All the sets computed by the algorithm—Reach and Rt—will be represented by sets of hyperrectangles. Let us examine the cost of performing each of the steps in BasicReach with that representation. The steps involve the following operations: (1) containment check ( ⊆), (2) union (∪), (3) intersection (∩),¹ and (4) Post𝒯 (d) and Post𝒟. For a pair of rectangles, containment checking, union, and intersection can be performed in O(n) time units. Two other operations will be useful for Post𝒯 (d) and Post𝒟: rectangular hull (RHull) and Minkowski sum (⊕). The Minkowski sum of two rectangles is defined as follows:

For hyperrectangles, that simplifies to

Rectangular hull, or the bounding box operation, overapproximates any set A by its smallest enclosing rectangle:

Finite collections of rectangles are closed under union (i.e., the union of two finite collections of rectangles is another finite collection of rectangles). Similarly, finite collections of rectangles are closed under intersection and Minkowski sum. Union, intersection, Minkowski sum, and other set operations (e.g., checking for membership, containment, emptiness, and intersection) can be computed in polynomial time. Proposition 9.9 shows a simple example of how Minkowski sums can be used to represent Post𝒯 (d)(.) succinctly.

Proposition 9.9.   Suppose that the dynamics of an RHA is given by in some mode. For any set [ [a, b] ] and any time bound d ≥ 0,

This representation of PostT(d)([ [a, b] ]), and in general any nontrivial PostT(d)(.) computation, requires an infinite union of rectangles; and in fact, PostT(d)([ [a, b] ]) itself is not a hyperrectangle. That illustrates the prototypical trade-off involved in choosing data structures for implementing BasicReach: data structures that are efficient for some of the operations are not efficient for others or are not expressive enough to represent the reachable sets accurately. Thus, to implement BasicReach for general hybrid automata, we have to choose a data structure and then resort to approximations when needed. For example, a rectangular hull of PostT(d)(.) can be computed to approximate the reachable set with a hyperrectangle.

Exercise 9.16.   Prove Proposition 9.9. Show that RHull(PostT(d)([ [a, b] ])) can be computed in O(n) time.

Figure 9.13 shows the implementation of the discrete and continuous Post functions that are used in BasicReach. For this instantiation, all the inputs—namely, the set of states Sin, the transitions 𝒟 (actions, guards, and resets), and the trajectories 𝒯 (the dynamics of each location)—are represented by finite collections of hyperrectangles. For Post𝒯 (d), the set from Proposition 9.9 is approximated to a finite number of rectangles by the Approx function. For example, we could use RHull(P) or partition P into a finite number of sets and then compute their rectangular hulls individually. As a result of that approximation, the output Reach from BasicReach may not be the actual reachset of the input automaton 𝒜, but Reach is guaranteed to contain the reachset. PostD and Post𝒯 (d), instantiated for different data structures, give instances for BasicReach with different properties. In the remainder of this section, we give an overview of other popular data structures and their implementation of the Post functions.

Figure 9.13
Discrete and continuous Post computation functions. Here, gga1 and gga2 are the generators for the guards, ggr1 and ggr2 are the generators for the resets for action a, and gℓ1 and gℓ2 are the generators for the rectangular dynamics of location ℓ.

9.7.2  Polytopes

Polytopes generalize hyperrectangles by representing sets as intersections of arbitrary—not necessarily orthogonal—half-spaces. Polytopes are used extensively in verification algorithms and tools. See the documentation of the Parma Polyhedral Library for a detailed discussion and implementation of polytope operations (Bagnara et al., 2008).

A linear inequality is an expression that takes the form ax ≤ b, where a ∈ ℝn and b ∈ ℝ are constants and x ∈ ℝn is a variable. A linear inequality defines a set in ℝn called a half-space, which is the set of values of x that satisfy it:

A polyhedron is an intersection of a finite number of half-spaces that is specified by a finite collection of linear inequalities. A polytope is a bounded convex polyhedron that can be represented in two ways. First, it can be represented by a matrix (A ∈ ℝm×n) and a vector (b ∈ m) encoding m linear inequalities. The n-dimensional polytope is the following set of points that satisfy all the inequalities:

Second, a polytope can be represented as the convex combination or convex hull of a set of extreme points or vertices. The convex combination of a set of points v₁, …, vk ∈ ℝn is defined as

A set of vertices v₁, …, vk ∈ ℝn specifies the following polytope:

Each representation has its merits. To convert the first to the second, we have to solve the vertex enumeration problem (which, going in the other direction, is called facet enumeration), for which there are algorithms that are worst-case exponential in the dimension (Avis and Fukuda, 1992).

Linear hybrid automata   Consider linear instances of the Generic hybrid automaton 𝒜 of Figure 9.12. These are automata for which the guards Ga, Gb are represented by polytopes, the resets Ra, Rb are linear or affine functions, and the dynamics in each mode is given by the linear differential equations or the affine differential equations .

Polytope operations   A single polytope can accurately represent the set PostT(d)([ [a, b] ]), defined in Proposition 9.9 for the rectangular initial set [ [a, b] ]. In general, a polytopic approximation (namely, the ConvexHull of a complex shape) will be more accurate than its rectangular approximation. However, implementation of some of the basic operations used in BasicReach will require more sophisticated procedures with polytopes.

Checking the containment of a point x₀ in a polytope [ [A, b] ] is accomplished by checking the inequality Ax ≤ b at x₀. The intersection of two polytopes—[ [A₁, b₁] ] and [ [A₂, b₂] ]—is obtained by syntactically collecting all the inequalities into a single set: [ [[A₁; A₂], [b₁; b₂]] ]. Polytopes are not necessarily closed under union, and therefore the union of a pair of polytopes has to be represented by a collection of polytopes in some canonical form. The vertex representation more readily allows the checking for the emptiness of a polytope, as the ConvexHull of any nonempty set is nonempty. Those operations enable us to check whether two sets of states represented as polytopes intersect (e.g., in checking guard conditions in PostD). Checking of the intersection and emptiness of polytopes is often carried out effectively using the Farkas lemma, expressed in Theorem 9.10.

Theorem 9.10.   {x | Ax = b, x ≥ 0} = ∅ if and only if {y | yTA ≥ 0, yTb < 0} = ∅.

An important property of polytopes is that they are closed under linear and affine operators. One can conveniently carry out the computation of the affine transformation of a polytope (in the vertex representation) by applying the operator to the vertices. Proposition 9.11 exploits that property to compute the PostT(d) of affine hybrid automata.

Proposition 9.11.   Suppose that the dynamics of a Generic hybrid automaton in some location is given by the affine differential equation , with an invertible matrix A. For any polytope [ [v₁, …, vk] ] represented by k vertices, PostT(d)([ [v₁, …, vk] ]) = ⋃ t≤d[ [ξ(v₁, t), …, ξ(vk, t)] ], where ξ(vi, t) is the solution of the differential equation from vi at time t.

Proof. We will show that for any time t ≤ d, the set of states reachable from [ [v₁, …, vk] ] exactly at t is contained in the set [ [ξ(v₁, t), …, ξ(vk, t)] ]. Then, by taking the union over t ≤ d, we get the required result. The solution for affine dynamical systems is given by the function ξ(vi, t) = (vi + A⁻¹b)eAt − A⁻¹b. Notice that this is an affine function of the initial state vi.

We check the closure property as follows. Consider any point x ∈ [ [v₁, …, vk] ], which is the same as selecting a point x ∈ ConvexHull(v₁, …, vk). From the definition of ConvexHull, we know that there are k coefficients {λi} such that and . Then we can write

That is, the system trajectory from x after time t ξ(x, t) is in the set ConvexHull(v₁, …, vk) = [ [v₁, …, vk] ].

Thus, by computing the solution of the system from the k vertices, we can immediately compute the set of reachable states at a given time. To compute Post𝒯 (d) over an interval of time, we have to overapproximate the infinite union of Proposition 9.11. One strategy is to take the union of a finite sequence of polytopes [ [ξ(v₁, mδ), …, ξ(vk, mδ)] ], where . As the time step δ approaches 0, this union approaches Post𝒯 (d). To guarantee an overapproximation, a standard approach is to compute a finite union and then bloat it by an appropriate error factor.

9.7.3  Zonotopes

Zonotopes are a special class of polytopes that are more general than hyperrectangles and have been found to be particularly useful in the analysis of hybrid systems (Girard, 2005). A zonotope is specified by a center, c ∈ ℝn, and a collection of generator vectors, g₁, …, gk ∈ ℝn, as follows: Each vector gi defines a line segment centered at c: {x | ∃λi ∈ [−1, 1], (x − c) = λigi}. The zonotope generated by c and g₁, …, gk is the Minkowski sum of all these segments:

The number of vertices of a zonotope can be quadratic in relation to the number of generators.

Zonotopic operations   Zonotopes have polynomial-time algorithms for most common operations, like membership testing, finding the Minkowski sum, and linear transformation. For example, consider the membership test. A point x ∈ ℝn is in a zonotope [ [c, ⟨g₁, …, gk⟩] ] if there is λ₁, …, λk ∈ [−1, 1], such that . This test is equivalent to checking the feasibility of a linear program (Bertsimas and Tsitsiklis, 1997) and can be solved efficiently using the Simplex algorithm (Dantzig, 1998). The Minkowski sum of two zonotopes can be computed in time that is linear in the number of generators, as follows:

Like polytopes, zonotopes are closed under linear transformations, and one can effectively compute a transformed zonotope by applying the transformation to the generators. That is, for any matrix A, the transformation of all the points in [ [c, ⟨g₁, …, gk⟩] ] is the set [ [Ac, ⟨Ag₁, …, Agk⟩] ]. Importantly, zonotopes are not closed under intersection, and algorithms have been developed to compute overapproximations of such intersections (Girard and Le Guernic, 2008).

9.7.4  Ellipsoids

Ellipsoids generalize spheres in ℝn. See the publications related to the Ellipsoidal toolbox for a detailed discussion of this topic (Kurzhanski and Varaiya, 2000; Kurzhanskiy and Varaiya, 2006). We will use a · b to denote the scalar product (or the inner product) of the pair of vectors a, b ∈ ℝn. That is, . Given a center c ∈ ℝn and a shape matrix Q ∈ ℝn×n, the ellipsoid is defined as the set

The shape matrix Q has to be positive definite (i.e., it is symmetric), and for any nonzero x ∈ ℝn, xTQx > 0. There are several equivalent representations of ellipsoids in terms of related matrices (Kurzhanski and Varaiya, 2000). Computationally, it is efficient to use the Cholesky representation:

Ellipsoidal operations   Several operations on ellipsoidal sets can be defined in terms of their distance to points and other ellipsoids. The distance of an ellipsoid [ [c, Q] ] to a point x ∈ ℝn is defined as

If dist(x, [ [c, Q] ]) > 0, then x [ [c, Q] ]; if dist(x, [ [c, Q] ]) < 0, then x ∈ [ [c, Q] ]; otherwise, x is on the boundary of the ellipsoid. The distance between two ellipsoids,

can be used to check the emptiness of the intersection of two sets. Like polytopes and zonotopes, ellipsoids are closed under affine transformations, and the transformed ellipsoid can be computed syntactically. Application of the affine transformation Ax + b to every point x in the set [ [c, Q] ] results in the ellipsoidal set [ [Ac + b, AQAT] ]. Ellipsoids are not closed under intersection, convex hull, and Minkowski sums, and algorithms have been developed for computing both overapproximations and underapproximations of these operations (Kurzhanski and Varaiya, 2000).

Exploring further   We introduced several data structures and their operations that can be used for implementing the BasicReach algorithm. There is an ever-increasing number of libraries that implement those data structures in various programming languages. For example, interval arithmetic libraries can be used to implement the hyperrectangles data structure and operations. The IEEE standard for interval arithmetic (1788-2015) has freely available reference implementations. The hybrid system verification tool d/dt (Asarin et al., 2000) uses hyperrectangles. The Parma Polyhedral Library (Bagnara et al., 2008) provides implementations of polytopes and has been used in the well-known HyTech tool (Henzinger et al., 1997). The Multi-Parametric Toolbox (Kvasnica et al., 2004) provides polyhedral operations in MATLAB. The Ellipsoidal toolbox (Kurzhanskiy and Varaiya, 2006) provides an implementation of the ellipsoids. The CORA toolbox of Althoff and Grebenyuk (2016) provides implementations of various data structures, such as zonotopes, intervals, and interval matrices.

There are other data structures that we have not mentioned here. Of particular note are the support functions of Le Guernic and Girard (2009), which are used in the SpaceEx tool for linear hybrid systems (Frehse et al., 2011), and the star set data structure of Duggirala and Viswanathan (2016), which allows efficient linear transformations and exact intersections with hyperplanes in higher dimensions, and which is used in the HyLAA toolbox (Bak and Duggirala, 2017; Bak et al., 2019).

9.8  Exercises

Exercise 9.17.   Using BasicReach as a template, design an algorithm for computing the backward-reachable set from a given set of unsafe states U of a hybrid automaton.

Exercise 9.18.   Prove Proposition 9.9 with the Post𝒯 (d) operator of RHAs.

Exercise 9.19.   (a) Convert the IRHA illustrated here to a timed automaton. Clocks may be initialized to constant intervals. For each arrow, a label of the form [A][B] corresponds to a set of transitions, where [A] is a precondition/guard and [B] is the corresponding effect or the reset function. No reset [] implies that the state variables are not reset in the poststate of the transition.

(b) Plot an execution of the original hybrid automaton and the corresponding execution of the timed automaton.

Exercise 9.20.   Show that for any rectangular initial set and rectangular dynamics, Post𝒯 (d) can be computed as a finite polytope.

Exercise 9.21.   Generalize the Post computation procedure for affine dynamics in order to make it work for nondeterministic affine dynamics.

Exercise 9.22.   Construct the region automaton corresponding to the timed automaton illustrated here. Assume that mode1 with x = 0 is the starting state.

¹Intersection does not appear in the code, but it is useful for containment check and for checking safety.

10

Progress Analysis

Overview

Is it guaranteed that every behavior of a system 𝒜 will eventually make progress and reach a goal G? First, notice that overapproximating the reachable states of 𝒜 will not be adequate for answering this question. If 𝒜 is a Turing machine and the set of goal states G is a halting state, then this is the famously undecidable halting problem, and it is hopeless to look for fully automatic approaches to answering the question. In this chapter, we will discuss verification techniques that use additional inputs about 𝒜—namely, ranking functions and Lyapunov functions—to prove progress properties of this type for discrete, continuous, and hybrid systems. Our journey will start with methods for termination proofs of automata. We will look at self-stabilization properties of distributed systems as an interesting application of progress analysis. Next we will turn to convergence and stability requirements, introduced in Chapters 3 and 4, as special types of progress properties. While our earlier definitions of stability and convergence required the state space of the automata to be a metric space, here we will present the elegant verification condition for nondeterministic automata operating on general topological spaces proposed by Tsitsiklis (1987). Finally, we will turn to the topic of stability of hybrid systems and discuss prominent verification approaches based on Lyapunov functions and slow switching criteria.

10.1  Quick introduction to progress

After invariance, progress is possibly the most basic type of requirement for a program or a system. Progress requirements say that the system eventually does something good, reaches a goal, or converges toward a target. Some progress properties related to the examples we have seen earlier are as follows:

(Section 2.5 of Chapter 2) Starting from any state, possibly with multiple tokens, do all executions of Dijkstra’s token ring algorithm eventually stabilize to a state with a single token?

(Section 4.5 of Chapter 4) Does the active satellite’s position converge close to the passive satellite from all initial conditions?

(Section 4.6) Does every aircraft eventually get an opportunity to land?

The fundamentally different natures of invariance and progress verification are illustrated by the following quantified formulas:

Disproving an invariant S gives us a counterexample ∃α ∈ Execs𝒜, ∃t ∈ α.dom such that α(t) ¬S, but it does not help prove that every execution eventually satisfies something, which is the structure of a progress property. Thus, for example, bounded time analyses, using simulations and bounded reachability, will not be adequate for proving progress. The time bound used for analysis may fall short of the time at which the system actually meets the progress requirements.

The key idea in progress verification is to come up with an additional certificate that proves progress. A certificate can take the form of a ranking function or a Lyapunov function, depending on the type of the system 𝒜 and the specific progress property in question. A basic ranking function f for proving termination of a program 𝒜 maps the finite-valued program variables X to natural numbers (i.e., f: val(X) → ℕ), and the verification task boils down to proving that for every program transition,

We can see this through a simple argument. Suppose, for the sake of contradiction, that there is a nonterminating (infinite, in other words) execution α of 𝒜 starting from some finite initial state x₀. Because α is infinite, and in each transition the value of f(x₀) decreases by at least 1 according to Equation (10.1), there must eventually be a state x in α at which f(x) < 0. This contradicts the definition of the ranking function f as nonnegative.

In this chapter, we will introduce other, more general, types of certificates for proving the termination, stabilization, and stability of discrete and hybrid systems. All the approaches, at their core, will rely on checking a condition like the one in Equation (10.1).

10.2  Termination of discrete-time automata

An automaton 𝒜 = ⟨V, Θ, A, 𝒟⟩ is said to terminate if it has no infinite executions. That is, every execution ends in a state from which there are no further enabled actions. Throughout this section, the action names of the transitions play no significant role, and it will be convenient to define the label-free transition relation of 𝒜 as

The generalization of ranking functions for automata is based on well-founded relations.

10.2.1  Termination with well-founded relations

A well-founded relation < on a set S is a binary relation <⊆ S × S, such that every subset of S has a least element. In other words, there are no infinite decreasing chains of elements s₀, s₁, … in S satisfying si+1 < si for every index i. Theorem 10.1 gives a necessary and sufficient condition for the termination of an automaton 𝒜 = ⟨V, Θ, A, 𝒟⟩ in terms of the existence of a well-founded relation R that contains the reachable part of the transition relation .

Theorem 10.1.   An automaton 𝒜 = ⟨V, Θ, A, 𝒟⟩ terminates if and only if there exists a well-founded relation R such that

Proof. (If direction) Suppose, for the sake of contradiction, that there exists a well-founded relation R such that and that 𝒜 is not terminating. Because 𝒜 is not terminating, it must have an infinite execution α = v₀, a₁, v₁, … For each i, (vi, vi+1) ∈ R because and vi, vi+1 ∈ Reach𝒜. Thus v₀, v₁, … is an infinite chain in R, which contradicts the assumption that R is well-founded; therefore, 𝒜 must be terminating.

(Only if direction) Assume that 𝒜 is terminating. We define as being restricted to the reachable states, R . Suppose, for the sake of contradiction, that R is not well founded. Then there is an infinite sequence of states β = v₀, v₁, … such that for each index i, (vi, vi+1) ∈ R = . It follows that there is an infinite execution fragment from v₀, which contradicts the assumption that 𝒜 terminates; therefore, R must be well founded.

The second part of this proof seems to produce a well-founded relation R from the transition relation of the automaton 𝒜. Then why can’t we always use that trick to prove the termination of programs? The problem, of course, is that the “construction” of the well-founded R relies on the assumption that 𝒜 terminates, and the argument would break down when it is unknown whether 𝒜 terminates.

Recall that we observed in Chapter 7 that it is usually easier to check the conditions for inductive invariance than to find inductive invariants. We shall see in the following discussion that the procedure for checking the sufficient condition for termination given by Theorem 10.1 has a similar inductive style to Theorem 7.1 once a candidate well-founded relation has been chosen. Furthermore, analogously, it is usually easier to check the sufficient condition for termination than to find the well-founded relations.

A convenient method for defining a well-founded relation on the states is to define a ranking function f: val(V) → W that maps the states to a well-ordered set W. A totally ordered well-founded relation is called a well-ordered relation or well-ordering relation. For example, the natural numbers ℕ with the usual ordering < and strings with the lexicographic ordering are well-ordered sets. The set of pairs ℕ × ℕ with the ordering (x₁, y₁) < (x₂, y₂) iff x₁ < x₂ and y₁ < y₂ is a well-founded relation but it is not well ordered.

Corollary 10.2.   An automaton 𝒜 = ⟨V, Θ, A, 𝒟⟩ terminates if there exists a function f: val(V) → W that maps states to a well-ordered set W with the ordering relation <, such that f(v) < f(v′) whenever v v′.

To prove termination from a specific set of initial states Θ, one can weaken the sufficient condition of Corollary 10.2 for termination by requiring f to be defined and well ordered only over the set of reachable states of 𝒜 from Θ.

10.2.2  Example: UpDown counter

Consider the example automaton in Figure 10.1. So long as both x and y are positive, the up(d) action decrements x by 1 and increments y by d (for now, we consider d = 1), and the down action decrements y by 1. To prove termination, we first define a function f: val(V) ℕ as 2x + y—that is, for any v ∈ val(V), f(v) = 2v ⌈ x + v ⌈ y. Next, we check the order condition for Theorem 10.1 for both actions. If , then f(v′) = 2v′⌈ x + v′⌈ y = 2(v ⌈ x− 1) + v ⌈ y + 1 < f(v). If , then f(v′) = 2v′⌈ x + v′⌈ y = 2v ⌈ x + v ⌈ y − 1 < f(v). Because f strictly decreases by every action and it has a lower bound of 0, it follows that the UpDown automaton has no infinite executions.

Figure 10.1
An up and down counting automaton.

Notice that in this argument, we did not rely on the initial state (Θ) or the reachable states of the automaton. Indeed, the argument proves the stronger result that UpDown is terminating from all possible initial states. Unlike reachability analysis and invariant proofs, it is common to prove progress properties like termination and stability from arbitrary initial states or with respect to arbitrary inputs.

10.2.3  Termination with disjunctive well-founded relations

In this section, we describe another sufficient condition for proving termination by using what are called disjunctive well-founded relations. This technique is from Podelski and Rybalchenko (2004) and allows the use of multiple well-founded relations for proving termination instead of a single one. One immediate generalization of Theorem 10.1, obtained by allowing 𝒟 to be contained in a finite union of well-founded relations, is not sound for proving termination, as Exercise 10.1 shows.

Exercise 10.1.   Define a modified automaton UpDown2 from the UpDown automaton in Figure 10.1, and propose a pair of well-founded relations Rup, Rdown such that UpDown2 does not terminate, and yet .

The correct sufficient condition (Theorem 10.4) requires that the transitive closure of the transition relation restricted to the reachable states of the system be contained in the finite union on well-founded relations. Recall the definition of the transitive closure of a relation.

Definition 10.1.   For any relation R ⊆ S ×S, its transitive closure tclosure(R) is the minimal transitive relation that contains R.

For a label-free transition relation of an automaton ⊆ val(V) × val(V ), (v, v′) ∈tclosure() if and only if there exists an execution fragment (with some sequence of actions) that starts from v and ends at v′. Thus, the sufficient condition of Theorem 10.4 requires that any such pair of states be contained in one of the finitely many well-founded relations. The proof of the theorem uses a fundamental result from combinatorics by Ramsey (1930), which we state without proof as Theorem 10.3.

Theorem 10.3 (Ramsey, 1930).   Let k be a constant number and X be any countably infinite set, and let X(n) denote the set of all subsets of X of size n. In any partitioning of X(n) into k components, there exists an infinite subset M ⊆ X such that all the members of M(n) are in the same component.

Theorem 10.4.   An automaton 𝒜 = ⟨V, Θ, A, 𝒟⟩ terminates if and only if there exists a finite collection of well-founded relations R₁, …, Rk ⊆ val(V) × val(V ) such that

Proof. (If direction) Suppose, for the sake of contradiction, that there exists a finite collection of disjunctive well-founded relations R₁, …, Rk such that tclosure() ∩ Reach𝒜 × Reach𝒜 ⊆ ∪i=1kRi and 𝒜 is not terminating. Let α = v₀a₁v₁… be an infinite execution of 𝒜. For each pair of states vj, vl in the execution α, we assign a specific relation Rm such that (vj, vl) ∈ Rm. There exists such a relation Rm because (vj, vl) ∈tclosure() ∩ Reach𝒜× Reach𝒜 ⊆ ∪i=1kRi. If there are multiple relations that contain (vj, vl), we choose one of them arbitrarily. Thus, this assignment to relations partitions the infinite set of state pairs in α into no more than k groups or components.

Now, if we apply Ramsey’s theorem with n = 2, the infinite set X as the set of states in the sequence α, and the number of components as the number of disjunctively well-founded relations, then we determine that there is an infinite subset (i.e., sequence) of states M ⊆ X in which all the pairs of states in M belong to the same component. That is, all the pairs of states in the infinite set M belong to the same well-founded transition relation, such as Rℓ. Because there is an infinite sequence of related states in Rℓ, the relation Rℓ is not well founded, which is a contradiction.

(Only if direction) Assume that the automaton is terminating. We define the transitive closure of 𝒟 restricted to the reachable states as R tclosure() ∩ Reach𝒜 × Reach𝒜. In other words, (v, v′) ∈ R if and only if there is an execution fragment from v to v′ and v itself is reachable from Θ. The relation R alone meets the requirement that tclosure() ∩ Reach𝒜 × Reach𝒜 ⊆ R. Suppose, for the sake of contradiction, that R is not well founded. Then there is an infinite sequence of states β = v₀, v₁, … such that (vi, vi+1) ∈ R for each i. But v₀ ∈ Reach𝒜, and for every pair (vi, vi+1) ∈ R, there is an execution fragment from vi to vi+1; therefore, there is an infinite execution that goes through the states in β, which is a contradiction.

10.2.4  Example: UpDown revisited

Consider the UpDown automaton with the following modification: the where clause in line 9 is dropped. In the resulting modified automaton, UpDown3, an up(d) action increments y by d (where d is any natural number) and decrements x by 1, and a down decrements y by 1 as before. Clearly, the previously used ranking function 2x + y does not work for the up action. In fact, there is no simple proof of termination of UpDown3 that uses a ranking function that maps to natural numbers. A termination proof for UpDown3 that uses Theorem 10.4 can be given as follows: We define two ranking functions—namely, fx(v):= v ⌈ x and fy(v):= v ⌈ y—and show that for any execution fragment v, a₁, v₁, …, v′, either fx decreases or fy decreases. There are two cases to consider. First, if there is any up action in the execution fragment, then fx decreases. Otherwise, there is no up action in the execution fragment and fy decreases.

10.3  Self-stabilization

Self-stabilization is a special progress property that is particularly relevant for fault tolerance in distributed systems (Dolev, 2000). The model of failure is that of a one-shot corruption of memory or the state of the system, whereupon the program continues to execute as usual from the corrupted state. The system is self-stabilizing if it automatically returns to a good state eventually. For example, space radiation could corrupt the state of the onboard computers of a spacecraft, and it would be desirable for the critical functionalities to return to normal without manual intervention.

Definition 10.2.   An automaton 𝒜 = ⟨V, Θ, A, 𝒟⟩ is said to self-stabilize to a set of good or legal states S ⊆ val(V) if

 (i) (convergence) for any infinite execution fragment, starting from any state, v₀, a₁, v₁, …, there exists an index k such that vk ∈ S (i.e., the automaton eventually reaches S), and

(ii) (closure) any execution starting from S remains within S.

The model of the automaton 𝒜 here captures the correct behavior of the distributed system. Failures and memory corruptions need not be modeled explicitly, but it is assumed that they cause the system to move to an arbitrary state in val(V). Thus, Definition 10.2(i) captures the requirement that after failures, the system must eventually reach a good state. This property is sometimes (misleadingly) called convergence (Ghosh, 2014). It is related to termination in the sense that it requires the executions of the automaton 𝒜 restricted to Sc to terminate. That connection has been used to apply termination verification techniques to self-stabilization (Duggirala and Mitra, 2011). The property in Definition 10.2(ii) requires S to be closed under the fault-free transitions of 𝒜. In other words, Post𝒜(S) ⊆ S. With Θ ⊆ S, that is equivalent to saying that S is invariant.

Exercise 10.2.   State the self-stabilization property of 𝒜 to a set S using linear temporal logic (LTL) and computational tree logic (CTL). How is self-stabilization related to Lyapunov and asymptotic stability?

With the token-based mutual exclusion algorithm (see Section 2.5 in Chapter 2), Dijkstra initiated the investigation of self-stabilizing distributed algorithms, which continues to be an active research area with a dedicated conference—Stabilization, Safety, and Security of Distributed Systems (SSS) (Izumi and Kuznetsov, 2018). Self-stabilizing algorithms and lower bounds for routing, mutual exclusion, leader election, graph coloring, and many other problems have been established. Dolev (2000) provides a review of the key techniques and many examples.

Exercise 10.3.   Give the necessary and sufficient conditions in the style of Theorem 10.1 (or Corollary 10.2) for proving that every execution fragment of an automaton 𝒜 even-tually reaches S for a given subset S.

10.3.1  Example: Distributed minimum spanning tree algorithm

In this section, we will investigate the self-stabilization of a shared-memory, minimum spanning tree (MST) algorithm given in Figure 10.2. This automaton, MST, models the composed behavior of n processes participating in an MST algorithm over a network. The underlying communication network defines, for each process i, the set of other processes [i.e., the neighbors Nbr(i)], whose shared variables i can read. The goal of the distributed algorithm is to stabilize in a state where the parent pointer of each process points to a neighbor, and all these pointers together define an MST of the network. Furthermore, the algorithm is self-stabilizing, and therefore this MST is achieved from any (possibly corrupted) state of the processes, with the exception of process 0. Process 0 always has both its level and parent values set to 0.

Figure 10.2
A shared-memory MST algorithm.

The MST automaton uses two formal parameters: the number of participating processes n, and the set of neighbors of each process, Nbrs. Recall that [n] is shorthand for the set {0, …, n − 1}, and that the type constructor powerset A gives the power set of A. That means that the second argument of MST is a function that maps each process identifier in [n] to a set of neighboring process identifiers.

The type L is going to serve as the set of different levels that each process can be at. With n processes, we know a priori that there can be at most n + 1 levels: from 0 to n. That fact is also used in the design of the algorithm. Each process has two shared variables: level is the current level, and parent is the current parent pointer. In the automaton model, those variables are aggregated into two arrays with the same name. The initial values of the variables are not specified except for process 0, as we are interested in analyzing the self-stabilization property. The initially clause is used to define the initial state of the automaton in terms of predicates.

The algorithm has three actions that each process i, i ≠ 0, can perform. For any process i > 0, each of the actions involves reading the shared variables of its parent or another neighbor and updating its own shared variables. Roughly speaking, level[i] = n indicates that something is awry at process i because no process should be at level n. Similarly, level[i] ≠ level[parent[i]] + 1 suggests that either process i or its parent has to change its level. The levelup(i) action is enabled when both i and its parent are not at level n and i’s level is not 1 + its parent’s level. When that action occurs, i sets its level to be 1 + its parent’s level. The levelmax(i) action occurs when i is not at level n, but its parent is. As the effect of this action, i sets its level to n. The leveldown(i) action can occur after i sets its level to n and finds a neighboring process k with a level lower than n − 1. In that case, leveldown(i) sets k as i’s parent and level[k] + 1 as i’s new level.

10.3.2  Stabilization of the minimum spanning tree algorithm

The ranking function for proving stabilization to an MST, not surprisingly, is defined in terms of good tree parts or forests. At a given state v, the edge from process i to its parent parent[i], with i ∈ [n], parent[i] ∈ Nbr(i), is said to be a good edge if the variable valuations at v satisfy the following expression:

At a given state v, the set of good edges defines a spanning forest denoted by F(v). Some trees in the forest may have a single node. We define T(v) to be an n-tuple of disjoint sets of trees in F(v), where the ith element Ti(v) is the set of trees that have their lowest-level process at level i. In other words, for each tree C in Ti(v) and each node k ∈ C, the path k, parent[k], parent[parent[k]], … ends at a node with level i. The ranking function f: val(V) → [n]n maps states of MST to n-tuples of natural numbers in [n] as follows:

In other words, the ith element in the tuple is the number of trees in the forest F(v) with their lowest-level process at level i. The following lexicographical ordering on the n-tuples is defined: f(v) < f(vv′) if there is j ≥ 0 such that for all i < j, card(Ti(v)) = card(Ti(v′)) and card(Tj(v)) < card(Tj(v′)).

Independent of the MST algorithm, the minimum value of this ranking function f, according to this ordering, is ⟨0, 0, …, 0⟩. However, the MST algorithm imposes restrictions on the values of f that can be reached. The following invariants of MST state that every process is in some tree Ti(v), and process 0 is not affected by failure and never changes its state (this is our assumption).

Invariant 10.1.   (1) level[0] = parent[0] = 0, and (2) for each i ∈ [n], there exists a unique j ∈ [n] such that j ∈ Tj(v).

It follows that restricted to the reachable states of the automaton, the minimum value of the ranking function f is ⟨1, 0, …, 0⟩ and the maximum value is ⟨1, n − 1, …, 0⟩. In any state where the MST has been formed, the parent[i] ∈ Nbr(i) and all the parent pointers together define a single MST over [n]. This single tree defined by the parent pointers must be rooted at process 0. That is, T₀(v) = [n], and for each i > 0, Ti(v) = {}. Therefore, the value of the ranking function f at a state where the spanning tree has been formed is the minimal value. Next, in Proposition 10.5, we show that each of the actions of MST decreases the ranking function according to the ordering defined.

Proposition 10.5.   Consider any transition of MST, f(v′) < f(v).

Proof. We fix the prestates and the poststates, v and v′. There are three cases to consider:

Case a = levelup(i). Let ℓ = v ⌈ level[i] be the level of i at v. In v, both i and parent[i] are at levels less than n, but the edge from i to parent[i] is not good because ℓ ≠ level[parent[i]] + 1. Therefore, either i is a singleton tree in F(v) or it is a root of a tree at level ℓ in v. In either case, in v′, the edge from i to parent[i] becomes a good edge and i becomes a part of its parent’s tree. As a result, card(Tℓ(v′)) = card(Tℓ(v)) − 1. Because for all levels j < ℓ, the number of trees at that level remains unchanged, card(Tj(v′)) = card(Tj(v)), and it follows that f(v′) < f(v).

Case a = levelmax(i). In v, either i is a singleton tree in F(v) at some level ℓ < n, or it is a root of a tree at level ℓ. In either case, in v′, it becomes a singleton tree at level n. Therefore, card(Tℓ(v′)) = card(Tℓ(v)) − 1, but card(Tn(v′)) = card(Tn(v)) + 1. From the definition of the order relation <, it follows that f(v′) < f(v).

Case a = leveldown(i). In v, i is a singleton tree in F(v) at some level n, and in v′, it merges with another tree at a level k < n − 1. Therefore, card(Tn(v′)) = card(Tn(v)) − 1, and for all other j < n, including j = k, card(Tj(v′)) = card(Tj(v)); and it follows that f(v′) < f(v).

From Proposition 10.5 and Corollary 10.2, we infer that the MST automaton self-stabilizes to a spanning tree rooted at process 0.

10.4  Convergence and stability of asynchronous systems without metrics

In earlier chapters of this book, we defined stability and convergence only for automata 𝒜 = ⟨V, Θ, A, 𝒟⟩ endowed with a metric on the state space val(V), while the definition of termination imposed no such requirement. It turns out that the notions of convergence and stability can also be generalized to work with nonmetric state spaces. However, we will instead require the automaton to be endowed with a weaker neighborhood system¹ around the equilibrium state. In this section, we present these more general notions and the corresponding proof techniques as developed in Tsitsiklis (1987).

For simplicity, we assume that each action a ∈ A is deterministic (i.e., for any and , v₁ = v₂), and that any action can be executed to update the state asynchronously. Thus, we can define, for each a ∈ A, a state transition function fa: val(V) val(V ) that defines the poststate fa(v) of action a that occurs in state v. A state v*∈ val(V) is said to be an equilibrium state of 𝒜 if it is a fixed point for all state transition functions [i.e., for all a ∈ A, fa(v*) = v*].

Definition 10.3.   A collection 𝒱 of subsets of val(V) is a neighborhood system around v* if (i) for each V∈𝒱, v*∈ V; (ii) for each v ∈ val(V), v ≠ v*, ∃ V∈𝒱, such that v V; and (iii) 𝒱 is closed under finite intersections and arbitrary unions.

If val(V) is a metric space, then the collection {Bδ(v*)}δ≥0 indeed defines a neighborhood system. In the remainder of this section, we will be interested in fair executions of 𝒜 (i.e., infinite executions in which every action a ∈ A occurs infinitely often). In terms of the given neighborhood system 𝒱, then, we can define an infinite fair execution α = v₀, v₁, … of 𝒜 to converge to v* if for every V ∈ 𝒱, there exists a positive integer k > 0 such that α[k] = vk ∈ V. Further, 𝒜 is (Lyapunov) stable if for every V ∈ 𝒱, there exists U ∈ 𝒱 such that if for any execution fragment α with α[0] ∈ U, for all k > 0, α[k] ∈ V.

10.4.1  Convergence for finite state systems

We consider 𝒜 = ⟨V, Θ, A, 𝒟⟩ to be a finite state system and develop necessary and sufficient conditions for stability in terms of the neighborhood systems. When val(V) is finite, any neighborhood system 𝒱 must include the singleton set {v*}. In that case, convergence and stabilization (or termination to v*) are equivalent notions. Further, by defining the set U = {v*}, we can see that 𝒜 is always Lyapunov stable.

Theorem 10.6.   The following three statements are equivalent:

  (i) All fair execution fragments of 𝒜 converge to v* for the neighborhood system 𝒱.

 (ii) There is no cyclic execution fragment of 𝒜 that uses every action a ∈ A but does not visit v*.

(iii) There exists a finite, totally ordered index set J and a collection {Xj}j∈J of subsets of val(V) with the following properties:

(a) j₁ < j₂ ⇒ Xj₂ ⊂ Xj₁

(b) ∩j∈JXj = {v*}.

(c) ∪j∈JXj = val(V).

(d) ∀ a ∈ A, j ∈ J, fa(Xj) ⊆ Xj.

(e) For any j ∈ J with Xj ≠ {v*}, there exists some a(j) ∈ A and j < j′ such that fa(j)(Xj) ⊆ Xj′.

Proof. This is essentially the proof of Theorem 4.1 from Tsitsiklis (1987).

    (i) ⇒ (ii) Suppose, for the sake of contradiction, that there is a cyclic execution fragment αc that does not visit v*. Then we can construct an infinite fair execution fragment αcαc… by concatenating αc infinitely, such that it does not converge to v*.

    (ii) ⇒ (i) Suppose that (ii) holds and also, for the sake of contradiction, that there is an infinite fair execution fragment α starting from v₀ that does not reach v*. Because val(V) is finite, some state in α must be visited multiple times. This contradicts (ii).

    (iii) ⇒ (i) Consider any fair execution α. By condition (d), it is clear that every Xj is closed under every action a of 𝒜, and thus, once α[k] ∈ Xj, for each k′ > k, α[k′] ∈ Xj. Second, by condition (e), α enters smaller and smaller Xjs until it reaches {v*}.

    (i) ⇒ (iii) Let J be a finite subset {0, …, N} with large enough N, X₀ = {v*}. Xj+1 is defined inductively as the smallest set that satisfies the following:

It can be determined that the resulting collection of sets satisfies (a)–(e).

Let us make a few remarks about these conditions. First, condition (b) can be checked in for a given automaton 𝒜 through the use of a depth-first search in time that is polynomial in |val(V)|. Second, the Xjs in condition (c) essentially encode the sublevel sets of a Lyapunov function. If we define V(v) = min v∈X jj, we see that condition (b) captures positive-definiteness, (c) is radial-unboundedness, (d) is the nonincreasing property, and (e) is the decreasing property.

Stability and convergence conditions for infinite state automata can be developed along the lines of Theorem 10.6. In Theorems 10.7 and 10.8, we state the conditions and leave the proofs as exercises at the end of the chapter.

Theorem 10.7.   The following two statements are equivalent:

 (i) All fair execution fragments of 𝒜 are stable with respect to 𝒱.

(ii) There is an invariant neighborhood system 𝒱′ of 𝒜 that is equivalent to 𝒱.

Theorem 10.8.   The following two statements are equivalent:

 (i) All fair execution fragments of 𝒜 converge to v*.

(ii) There is a totally ordered index set J and a collection {Xj}j∈J of distinct nonempty subsets of val(V) that satisfy exactly the conditions (a)–(e) in part (iii) of Theorem 10.6. In addition, every nonempty subset of J that is bounded below has a smallest element.

10.5  Stability proofs for dynamical systems

Chapter 3 introduced continuous-time models of dynamical systems, their progress properties (Definition 3.5), and Lyapunov’s method for proving them (Theorem 3.3). Here, we give a proof of Lyapunov’s important method for proving stability.

Theorem 10.9 (Lyapunov stability 3.3).   Consider the system with state space val(x) and suppose there is a positive definite continuous function V: val(X) ℝ. The system is:

1. Lyapunov stable if

2. asymptotically stable if, for all x ≠ 0,

It is globally asymptotically stable if V is also radially unbounded.

Proof. Part 1 (Lyapunov stability). We fix an ε > 0. Pick a positive a > 0 such that the a-sublevel set of V is contained in B(, ε)—that is, La = {x ∈ val(X) | V(x) ≤ a}⊆ B(, ε). Then pick δε > 0 such that B(, δε) ⊊ La. Now consider any trajectory of the system ξ: [0, T] → val(X) with |ξ(0)|≤ δε—that is, ξ(0) ∈ B(, δε) ⊆ La. For any t ≤ T, it follows from Equation (10.3) that V(ξ(t)) ≤ V (ξ(0)) ≤ a—that is, ξ(t) ∈ La ⊆ B(, ε).

Part 2 (Asymptotic stability). Consider any infinite trajectory of the system ξ, with |ξ(0)| ≤ δε as defined previously. As V is positive and decreasing along ξ(t), there is a limit c ≥ 0 such that . If c = 0, then from the positive-definiteness of V and Lyapunov stability, it follows that —that is, the system is asymptotically stable. Otherwise, suppose that c > 0. We see that the system evolves in a compact set C = B(, ε) ∖ B(, r) for some sufficiently small r, and this set does not contain . Because C is compact and is continuous, we define the negative constant as the maximum value of over C. Thus, for any t > 0, V(ξ(t)) ≤ V (ξ(0)) + dt. Therefore, for any d < 0, there exists some t such that V(ξ(t)) < c, which contradicts our assumption.

Theorem 3.4 gives sufficient conditions for stability and asymptotic stability, in contrast to the theorems in the previous section that gave both the necessary and sufficient conditions. A converse Lyapunov theorem gives the necessary conditions for the existence of Lyapunov functions. For example, Theorem 10.10 is a converse Lyapunov theorem for global exponential stability.

Theorem 10.10.   Suppose that there exists β, M > 0 such that each trajectory ξ of the dynamical system satisfies, for all t ≥ 0, ||ξ(t)||≤ Me−βt||ξ(0)||. Then, there is a Lyapunov function V: val(X) → ℝ that proves the system is globally exponentially stable—that is, there is a constant α > 0 such that , for all t.

Proof. (Sketch). The proofs of converse Lyapunov theorems are existential (i.e., not constructive) and require knowledge of the solutions. To prove Theorem 10.10, we define V(z) = ∫ ₀∞||ξ(t)||²dt, where z = ξ(0). Because ||ξ(t)||≤ Me−βt||z||, we can check that V(z) is finite and positive definite, and in fact equal to . Then we find

with α = 2β/M².

Another converse theorem states that for a linear asymptotically stable system, there is a quadratic Lyapunov function that proves its stability.

10.6  Stability of hybrid automata

Chapter 4 introduced hybrid automata and their stability properties (Definition 4.4). We also observed, with an example in Figure 4.8 in Chapter 4, that it is possible to switch between two asymptotically stable dynamical systems in a way that makes the combined hybrid system unstable. Thus, we need to develop new sufficient conditions for the stability of hybrid systems. In the remainder of this section, we present a sequence of Lyapunov-type sufficient conditions for stability of hybrid and switched systems with increasingly weak assumptions.

Throughout this discussion, we will consider the simple hybrid automaton model of Definition 4.2. Recall that a simple hybrid automaton 𝒜 = ⟨V, Θ, A, 𝒟, 𝒯⟩ has a set of variables V = loc ∪ X, where type(loc) = L is the set of locations or modes and type(x) = ℝ for each x ∈ X. A state v is a valuation of all the variables in V, a continuous state x is a valuation of the continuous variables X, and a discrete state or mode ℓ is a valuation of loc. In addition, we will make the following assumptions about the simple hybrid automaton 𝒜:

  (i) For each mode ℓ ∈ L, the trajectories of the continuous variables are given by a differential equation , and furthermore, x* is the equilibrium point for each of these subsystems.

 (ii) All transitions are mode switches. That is, for each transition , v′.loc ≠ v.loc.

(iii) There are no resets. That is, for each transition , v′.X = v.X.

10.6.1  Common Lyapunov functions

Definition 10.4.   A positive definite continuously differentiable function V: val(X) → ℝ≥0 is called a common Lyapunov function (CLF) for 𝒜 if there is a positive definite function W: val(X) → ℝ≥0 such that

Theorem 10.11 gives a sufficient condition for the global asymptotic stability (GAS) of a hybrid system and can be derived following the same argument used in the proof of Theorem 3.4.

Theorem 10.11.   𝒜 is globally asymptotically stable if there is a CLF.

The existence of a CLF actually gives a much stronger result—namely, that any switch system with the same dynamics as the modes of 𝒜 is GAS. That is, stability is guaranteed independent of the transitions in 𝒟. If the condition in Equation (10.4) is replaced by the weaker condition , then the global asymptotic stability of 𝒜 is no longer guaranteed. If the set of modes L is compact (e.g., finite) then the proof goes through, but for general L, the result does not hold under arbitrary switchings. Consider, as a counterexample, the switched system , with the exponential switching signal σ(s) = e−s and the candidate CLF . We refer the reader to the book by Liberzon (2003b) for detailed discussion of stability of switched systems.

Exercise 10.4.   Consider the two-dimensional (2D) linear modes of the simple hybrid automaton 𝒜 described by

Consider the candidate function V(x) = x₁² + x₂² and show that it is indeed a CLF, and therefore, the resulting hybrid system is GAS independent of the mode transitions. (Hint: Express the derivative as a sum of squares.)

If we follow Theorem 3.23, the search for a quadratic CLF V(x) = xTPx for a collection of linear modes Aℓ, ℓ ∈ L can be cast as a feasibility check for a linear matrix inequality (LMI):

However, if a set of linear subsystems are GAS under arbitrary switching, that does not necessarily imply the existence of a quadratic CLF. There is no such converse Lyapunov theorem, and one can easily construct two modes of a simple hybrid automaton that would make this LMI infeasible.

10.6.2  Multiple Lyapunov functions

In the absence of a CLF, sufficient conditions for stability have been derived in terms of Lyapunov functions {Vℓ}ℓ∈L for the individual modes and additional conditions that relate the changes in the valuations of those functions across mode switches. Theorem 10.12, from Branicky (1998), imposes the additional condition that the Lyapunov function Vℓ value for each mode ℓ must decrease at consecutive entry points to mode ℓ.

Theorem 10.12.   Let L be the finite set of stable modes for a simple hybrid automaton 𝒜. For each location ℓ ∈ L let Vℓ: val(X) → ℝ≥0 be a corresponding radially unbounded Lyapunov function. Suppose that there exists a collection of positive definite functions Wℓ: val(X) → ℝ≥0 such that for any execution α, and any mode ℓ ∈ L, at any two consecutive entry times t₁ and t₂ ∈ α.dom to mode ℓ, the following holds:

Then, 𝒜 is globally asymptotically stable.

Exercise 10.5.   Prove Theorem 10.12.

Exercise 10.6.   Show that Theorem 10.12 holds if condition of Equation (10.5) is imposed on the mode exit times instead of mode entry times.

Application of Theorem 10.12 requires careful analysis of the entry or exit times along all executions of a hybrid system. That can be challenging, particularly for nondeterministic hybrid automata. The results given in the next section avoid this problem by assuming that the mode switches are relatively slow.

10.6.3  Stability under slow switching: Average dwell time

The speed of transitions, mode switches, or, more generally, events is characterized by the notion of dwell time. Roughly, an execution α has a dwell time of τa > 0, if α has no more than one transition every τa time units. That is, the execution dwells in each mode for at least τa before jumping to a new mode. Average dwell time (ADT) relaxes the concept of dwell time by allowing a constant number of extra jumps.

A hybrid automaton 𝒜 is said to have an ADT of τa, if every execution of 𝒜 has the ADT property. Let us use α.switches to denote the number of mode switches in an execution α.

Definition 10.5.   A hybrid automaton 𝒜 has an ADT τa > 0 if there is a constant N₀ > 0 such that for every execution α ∈Execs𝒜,

Exercise 10.7.   Can a hybrid automaton with a positive ADT have any Zeno executions?

Theorem 10.13, from Hespanha and Morse (1999), gives a sufficient condition for stability of hybrid systems with individually stable modes, as in Theorem 10.12, but with the additional requirement of slow switching, stated in terms of a minimal ADT.

Theorem 10.13.   Let L be the finite set of stable modes for a simple hybrid automaton 𝒜. Suppose that there are two constants λ₀, μ > 0 such that:

  (i) for each mode ℓ ∈ L, the corresponding radially unbounded Lyapunov function satisfies ,

 (ii) for any mode-switching transition , Vv′.loc(v′.X) ≤ μV v.loc(v.X), and

(iii) the ADT of 𝒜 is at least

Then, 𝒜 is globally asymptotically stable.

Before discussing the proof, we will make a few remarks about the assumptions being made in Theorem 10.13. First, if the dynamics of each mode fℓ is asymptotically stable, then it can be shown that there is a Lyapunov function Vℓ with a constant λℓ > 0 decay rate such that . Further, if the set of modes is finite or compact, then we can choose λ₀ independent of ℓ. Thus, condition (i) holds without any loss of generality. Condition (ii) states that whenever there is a mode switch , the new Lyapunov function value Vℓ′(x′) may increase from the old Lyapunov function value Vℓ(x), but by a factor of μ at most. That is a restrictive assumption; for example, if Vℓ and Vℓ′ are polynomial Lyapunov functions of different orders, then condition (ii) will generally not hold.

Theorem 10.13 captures this intuition that each mode switch raises the “energy” of the system by a factor of μ, while if the system stayed in the same mode, the energy would be dissipated at a rate of at least 2λ₀. So long as the system does not switch too frequently—as stipulated by the lower bound on ADT—it dissipates overall, and therefore it is globally asymptotically stable. Now we construct that argument as a proof of the theorem.

Proof. Let us fix an admissible execution α of 𝒜 and an arbitrary time point T > 0. The prefix of α up to time T will be denoted by αT, which can be written as αT = τ₀a₁τ₁a₂τ₂…τα T.switches, where αT.switches is the number of mode switches in αT and τα T.switches is a point trajectory after the last switch. The switching times in αT are denoted by t₀(= 0), t₁, …, tα T.switches, that is, . We define the function W: [0, T] → ℝ as

At each of the switching times ti, α(ti).loc changes instantaneously—possibly multiple times. With some abuse of notation, W(ti⁻) is used to denote the value of W before the first switch that occurs at ti, and W(ti) is used to denote the value of W after the last switch at time ti. W is piecewise differentiable along each trajectory in α between the switches. Thus,

W is nonincreasing along the trajectories between the switches. That is, for each i, W(ti+1⁻) ≤ W(ti). Using condition (ii), it follows that W(ti+1⁻) ≤ μW(ti+1) ≤ μW(ti). If we iterate through αT.switches, we get W(T) ≤ μαT.switchesW(0). That is,

If the execution α has an ADT of τa, then , and we can rewrite this expression as

where C₀ is a constant. As a final step, observe that if the ADT τa is greater than , then the right side goes to 0 as T → ∞.

Mitra et al. (2008) show that the problem of checking whether all executions of a given hybrid automaton 𝒜 satisfy a given ADT condition τa can be cast as either an invariant problem or an optimization problem.

10.7  Exercises

Exercise 10.8.   Automaton 𝒜 models a distributed graph coloring algorithm running on N processes, with identifiers 0, …, N − 1 communicating over a given graph G. Each process i corresponds to a vertex of G and the set of neighbors of i is denoted by Nbrs(i). The maximum degree of G is D (i.e., maxi∈[N]Nbrs(i) ≤ D). Each process i has a single state variable color[i], which can take values from the set {0, …, D}. Initially, color[i] is set arbitrarily. 𝒜 has a set of actions recolor(i: [N]), and the corresponding transitions are defined as follows:

Show that an equilibrium state for 𝒜 is an assignment of the color[i] variables, such that each process has a color that is distinct from its neighbors. Show that all fair executions of 𝒜 converge to this equilibrium.

Exercise 10.9.   (Line formation) Consider an automaton 𝒜 that models a set of N processes with identifiers 0, 1, …, N − 1. Each process i ∈ [N] has a single real-valued variable x[i]. The automaton has a set of actions, move(i: [N]). The move(0) and move(N − 1) keep x[0] and x[N − 1], respectively, unchanged. For each process i ∈{1, N − 2}, move(i) updates the state as follows:

Write the complete specification for automaton 𝒜. What is the equilibrium state x* of 𝒜? Show that all fair executions of 𝒜 converge to x*.

Exercise 10.10.   Show that the checking of a bound on the ADT of a hybrid automaton 𝒜 can be stated as an invariant property. Consider adding new variables and counters to 𝒜 for the purpose of writing this invariant.

Exercise 10.11.   In the following hybrid automaton, 𝒜, a₁, a₂, c₁ ∈ ℝ+ and b₁, b₂ ∈ ℝ are constant parameters of the model:

(a) Assuming that c₂ ∈ ℝ+ is a constant, show that 𝒜 is globally asymptotically (exponentially) stable under arbitrary switching.

(b) For any arbitrary, possibly negative c₂, show that 𝒜 is globally asymptotically (and exponentially) stable under an additional assumption about the switching speed (dwell time or ADT).

¹A point-separating topology around the equilibrium.

11

Data-Driven Verification

Overview

The verification approaches reviewed in Chapters 9 and 10 rely entirely on the statically available information about the model 𝒜. They do not execute the model 𝒜. Hence, those approaches fall under the broad term static analysis and are also sometimes called model-based analysis. The dynamic information generated from executions of 𝒜 can also be useful for verification. For a nonlinear dynamical system 𝒜, for instance, computation of analytical solutions may be impossible, but data about the actual runs of the system or numerically computed solutions can be used to estimate the reachable states. The terms data-driven verification and dynamic analysis refer to approaches that utilize execution data together with models to verify the requirements. Dynamic approaches are often the only applicable approach for realistic, complex, and nonlinear models of cyber-physical systems (CPS). In this chapter, we begin by introducing the basic idea of data-driven safety verification. This approach relies on a notion of sensitivity that is formally called a discrepancy function. We define discrepancy and discuss methods for computing this quantity for linear and nonlinear models. Automatic discrepancy computation leads to the first data-driven verification algorithm for nonlinear hybrid models. Often, complete mathematical models are not available for CPS, and in that case, we can rely on statistical approaches for computing discrepancy. That leads to a second verification approach that is applicable to systems with incomplete or black-box executable models. Then we present examples showing how data-driven verification can be serviceable for autonomous vehicles, advanced driver-assistance systems (ADAS), satellite control, and engine control systems. We conclude the chapter with brief discussions about limitations and open problems related to the data-driven verification approach, the related data-driven problems of falsification and statistical model checking, and the emerging area of verification of machine learning (ML) systems.

11.1  Quick introduction to data-driven safety verification

We now present one of the most effective methods for verifying nonlinear CPS models. To simplify this discussion, we will start with the verification of dynamical systems. Given an n-dimensional dynamical system , with a state vector x as in Equation (3.13) in Chapter 3, a compact initial set Θ ⊂ val(x), an unsafe set U ⊆ val(x), and a time bound of T > 0, the bounded safety verification problem (Section 6.3.3 in Chapter 6) involves deciding whether Reach(Θ, T) ∩ U = ∅. Data-driven verification algorithms make that decision by using numerical solutions of the ordinary differential equation (ODE) system and sensitivity analysis of f. Figure 11.1 shows how simulations from different parts of the initial set Θ are used to compute increasingly precise overapproximations of Reach(Θ, T).

Figure 11.1
Conceptual demonstration of BasicSimReach. The dark gray region on the left is the unsafe set U; the hollow box is the initial set Θ with successive refinements. A set of simulations is shown with black lines at the top left. The black region at the top right shows a reachtube overapproximation computed using sensitivity analysis with a piecewise discrepancy function. This overapproximation intersects with U; therefore, it is inconclusive. The light gray region (in the lower left) is the reachtube overapproximation from a part of the initial set that is proved to be safe. A counterexample unsafe simulation is shown in the lower right.

Before presenting the basic algorithm, we must carefully define numerical solutions and sensitivity.

11.1.1  Discrepancy functions

Numerical solutions, or simulations, can be computed by validated integration algorithms (Nedialkov, 2006; CAPD Group, 2016). A simulation from an initial state x₀ is a sequence of time-stamped hypercubes whose convex hulls contain the solution ξ(x₀, t) of the system from x₀.

Definition 11.1.   For any initial state x₀ ∈ val(x), maximum sampling period τ > 0, error bound ε > 0, and time period T > 0, an (x₀, τ, ε, T)-simulation of the system described in Equation (3.13) in Chapter 3 is a sequence of time-stamped sets {(Ri, ti)ki=0} that satisfy the following:

  (i) For each i, 0 < ti − ti−1 ≤ τ, t₀ = 0, and tk = T.

 (ii) Each Ri ⊆ val(x) has a diameter smaller than ε.

(iii) ξ(x₀, ti) ∈ Ri, for each i, and ∀t ∈ (ti−1, ti), ξ(x₀, t) ∈ Hull(Ri−1, Ri).

Reachtubes are also sequences of time-stamped hypercubes, but unlike simulations, they contain Reach(Θ, T).

Definition 11.2.   For any initial set Θ ⊂ val(x) and time period T > 0, a (Θ, T)-reachtube is a sequence of time-stamped compact sets {(Oi, ti)ki=0}, such that for each i in the sequence, Reach(Θ, [ti−1, ti]) ⊆ Oi, where Reach(Θ, [t₁, t₂]) denotes the set of states reachable from Θ at any t ∈ [t₁, t₂].

The sensitivity of the solution ξ(x₀, t) to changes in the initial state x₀ is formalized by discrepancy functions that bound the distance between two solutions as a function of initial state and time (Duggirala et al., 2013).

Definition 11.3.   A continuous function β: ℝ≥0 × ℝ≥0 → ℝ≥0 is a discrepancy function of Equation (3.13) with initial set Θ if

 (i) for any x₁, x₂ ∈ Θ and any time t ≥ 0, ∥ξ(x₁, t) − ξ(x₂, t)∥ ≤ β(∥x₁ − x₂∥, t), and

(ii) for any t, lim ∥x₁−x₂∥ → 0⁺β(∥x₁ − x₂∥, t) = 0.

11.1.2  BasicSimReach algorithm

From these definitions, we can observe that at any time t ≤ T, the ball centered at ξ(x₀, t) with radius β(δ, t) contains every solution of Equation (3.13) starting from Bδ(x₀). Therefore, by using the corresponding discrepancy function to bloat the simulations, we can compute overapproximations of reachtubes and perform safety verification. That is the basic idea underlying the BasicSimReach algorithm (Figure 11.2). It has the following three main steps:

1. Simulate the system from a finite set of states that are chosen from the compact initial set Θ. The union of a set of balls of diameter δ centered at each of those states should cover Θ.

2. For each simulation {(Ri, ti)ki=0} from an initial state θ, bloat it using a discrepancy function β to compute the corresponding reachtubes (rtube) from Bδ(θ).

3. Check each of the reachtubes and decide whether the system is safe. If such a decision cannot be made, then replace Bδ(θ) with a finer cover by halving δ (as well as halving τ and ε).

Figure 11.2
Basic data-driven verification algorithm.

Figure 11.1 gives a conceptual demonstration of BasicSimReach.

Before diving deeper into BasicSimReach, we will describe the functions used. The Cover(Θ, δ, ε) function computes a δ-cover of the compact set Θ and tags each element in the cover with ε. The Simulate() function computes a simulation as per Definition 11.1. The Bloat() function takes as input the simulation sim starting from θ, the size of the initial cover δ, the simulation precision ε, a discrepancy function β, and a bloated set rtube that is obtained by expanding sim by the factor β(δ, ·). Thus, by Definition 11.3(i), this set rtube is guaranteed to contain Reach(Bδ(θ), T).

Initially, coverstack contains a singleton ⟨θ₀, δ₀ = dia(Θ), ε₀⟩, where Θ ⊆ Bδ₀(θ₀), and ε₀ is a small positive constant. As the algorithm executes, coverstack always contains a cover of a subset of the initial set Θ for which safety is still unverified. For each triple ⟨θ, δ, ε⟩∈ coverstack, the while-loop from line 5 checks the safety of the reachtube rtube from Bδ(θ), which is computed in lines 7–8. Further, sim is a (θ, T, ε, τ)-simulation that is guaranteed to contain the trajectory ξ(θ, T) (Definition 11.1). If we bloat sim by the discrepancy function β, we get rtube, which is a (Bδ(θ), T)-reachtube—in other words, an overapproximation of Reach(Bδ(θ), [0, T]). We will discuss the computation of β and Bloat() in more detail later in this chapter. If rtube is disjoint from U, then Reach(Bδ(θ), [0, T]) is safe and the triple ⟨θ, δ, ε⟩ is removed from coverstack. If for some j, Rj (one rectangle of sim) is contained in U, then sim is a counterexample. Otherwise, the safety of Reach(Bδ(θ), T) is inconclusive, and Bδ(θ) is refined with a finer cover added to coverstack. In addition, to reduce the size of the δ-balls in the cover, the refinement reduces the simulation error parameter ε and the sampling time τ. The correctness of BasicSimReach is summarized in Theorem 11.1.

Theorem 11.1.   BasicSimReach is sound. That is, if it returns Safe, then Reach(Θ, T) ∩ U = ∅; if it returns Unsafe, then the corresponding sim reaches U.

Proof. (Sketch). If the algorithm returns Safe, the implication is that the while-loop terminates and coverstack becomes empty. Observe that coverstack is initialized with a cover of Θ, and elements are removed from it (without replacements) only in line 10. Also, from Definition 11.3(i) and Bloat(), it follows that for any θ ∈ coverstack, Reach(Bδ(θ), T) ⊆ rtube. Thus, θ is removed from coverstack only if Reach(Bδ(θ), T) ∩ U = ∅. Taking the union over all initial states θ that are ever added to coverstack, it follows that Reach(Θ, T) ∩ U = ∅.

The safety verification problem is undecidable in general, and therefore, we cannot always expect the BasicSimReach procedure to terminate. If a solution ξ(x₀, ·) of 𝒜 from the initial state x₀ touches the boundary of the unsafe set U, the algorithm may run forever. Specifically, it will keep refining the coverstack with smaller-sized covers (i.e., smaller values of δ) and compute increasingly more precise overapproximations of Reach(Bδ(x₀), T), but the corresponding rtube will never be unsafe or safe. With an additional assumption that eliminates that type of boundary-grazing behavior, we can get a slightly weaker termination guarantee.

If there exists some ε > 0 such that Bε(Reach(Θ, T)) ∩ U = ∅, we say that the system is robustly safe. That is, all the states in some envelope around the reachable states of 𝒜 are safe. If there exists some ε, x₀ ∈ Θ, such that Bε(ξ(x₀, t)) ⊆ U over some interval [t₁, t₂], 0 ≤ t₁ < t₂ ≤ T, we say that the system is robustly unsafe. That is, not only is ξ(x₀, t) unsafe at a particular point, but ξ stays in the interior of U over an interval of a positive duration. If the system is robustly safe or robustly unsafe, then it can be shown that BasicSimReach is guaranteed to terminate. The proof is somewhat involved and uses the second property of discrepancy function β, which ensures that the overapproximation error converges to 0 [part (ii) of Definition 11.3]. The details are given in Duggirala et al. (2013). Alternatively, one could say that BasicSimReach is a semidecision procedure for robust safety verification.

11.1.3  Example: Moore-Greitzer jet engine

An axial gas compressor is a key component in gas turbines, aircraft jet engines, and small-scale power stations. A widely studied ODE model describing the airflow through the compression system in turbomachines is presented by Moore and Greitzer (1986). A version of the model from Krstić et al. (1995) is described by Equation (11.1):

Here, u and v represent the deviations of the average flow and pressure from their respective nominal values. We will use this model now to illustrate BasicSimReach.

One can check that for any dynamical system described by Equation (3.13), β(∥x₁ −x₂∥₂, t) = eLt∥x₁ −x₂∥₂ is a discrepancy function, in which L is a Lipschitz constant for f. For Equation (11.1), L = 2, and therefore e2t∥x₁ − x₂∥₂ is a valid discrepancy function. However, the function is exponentially growing, and thus it will be useless for most verification problems. A crucial and challenging aspect of the BasicSimReach algorithm is that of choosing an appropriate discrepancy function with which to implement the Bloat() function. In the next section, we introduce algorithms that implement Bloat(). We will see that the Jacobian of f plays an important role in these algorithms. The Jacobian for Equation (11.1) is:

11.2  Computing discrepancy

In this section, we discuss several approaches for computing discrepancy functions for dynamical systems. We start with the simplest case of stable linear systems, for which Lyapunov equations can be used for computing discrepancy functions. Then we move on to discuss nonlinear models and contraction metrics, and finally we describe locally optimal methods for general nonlinear systems.

11.2.1  Linear dynamical systems

This section builds on concepts and notations introduced in Section 3.3.2 in Chapter 3 and Appendix A. For a linear time-invariant (LTI) system that is asymptotically stable, we can find a discrepancy function by solving the Lyapunov equation. Here, denotes the M-norm of the state vector x under the transformation defined by the positive definite matrix M.

Theorem 11.2.   For an asymptotically stable linear system , given any positive definite matrix Q ∈ ℝn×n, β(∥x₁ − x₂∥M, t) = e−γt∥x₁ − x₂∥M is a discrepancy function, in which the positive definite matrix M ≻ 0 can be found by solving the Lyapunov equation ATM + MA + Q = 0 and .

Proof. Fix the initial states x₁, x₂ ∈ Θ. Let us define a time-varying function y(t):= ξ(x₁, t) − ξ(x₂, t). The time derivative of y can be written as = A(ξ(x₁, t) −ξ(x₂, t)) = Ay(t). The derivative of the square of the M-norm of y(t) can be written as

Recall Lyapunov’s equation [Equation (3.23) in Chapter 3], in which for any chosen positive definite matrix Q, ATM + MA = −Q is solved to find M. If we replace Q in Equation (11.3), we get . If we use the relationship between eigenvalues and norms twice (Proposition A.2 in Appendix A), we get . By applying Grönwall’s inequality, we obtain .

11.2.2  Nonlinear dynamical systems: Optimization approaches

Now we consider a general, n-dimensional, nonlinear dynamical system , as introduced in Equation (3.13). For the sake of simplifying notations, we consider the state space to be ℝn instead of val(x). Jf denotes the Jacobian of f. More precisely, Jf: n → ℝn × ℝn is a matrix-valued function of the state.

For nonlinear systems with trajectories that converge toward each other exponentially, contraction metrics can be used to prove this convergence (Lohmiller and Slotine, 1998), and discrepancy functions can be computed from such contraction metrics.

Definition 11.4.   A matrix-valued function of state and time M: ℝn × ℝ≥0 → ℝn×n is called a contraction metric for the system in Equation (3.13) if there is an exponential convergence rate γ ∈ ℝ≥0 such that

Theorem 11.3 (Theorem 2 from Lohmiller and Slotine (1998)).   For a system given by Equation (3.13) with a contraction metric M, the trajectories converge exponentially with time—that is, ∃k ≥ 1, γ > 0 such that ∀ x₁, x₂ ∈ ℝn, yT(t)y(t) ≤ kyT(0)y(0)e−γt, where y(t):= ξ(x₁, t) − ξ(x₂, t).

For this system [Equation (3.13)] with contraction metric M, it can be shown that is a discrepancy function, in which k and γ are given by Theorem 11.3. Thus, provided that we can find a contraction metric from which we can get a discrepancy function, we can use BasicSimReach for safety verification. There is no general method for automatically computing the contraction metric M(xk, t) for general nonlinear systems; however, a template-based search sometimes works. First, assume that M is time-independent and select the degree d of the polynomial for each term in the matrix M(x). For example, for a two-dimensional (2D) system with variables U and v, the template M(x) will be

Next, we define the constraints on aij, bij, and the other coefficients based on Equation (11.4). Specifically, we require that yTM(x)y and − yTR(x)y be sum-of-squares (SOS) polynomials, in which . If a feasible solution for the coefficients can be found by using SOS tools, then we have a solution for the contraction metric and the exponential convergence rate can be computed as γ, such that . Otherwise, if it turns out that it would be infeasible to meet these constraints, then a template polynomial with a higher degree d can be tried. For an arbitrary nonlinear ODE, a contraction metric that is an SOS polynomial is not guaranteed to exist, and hence this procedure for finding M may not terminate.

11.2.3  Nonlinear models: Local discrepancy

For general nonlinear dynamical systems, as in Equation (3.13), a global bound on the convergence (or divergence) rates across all trajectories is difficult to compute. Instead, we restrict the definition of discrepancy (Definition 11.3) to smaller parts of the state space. The resulting local or piecewise discrepancy function β is adequate to use in BasicSimReach for computing reachset overapproximations. Moreover, local discrepancy will be computable from simulation traces and some additional information about the dynamics f(·) (Fan and Mitra, 2015).

Let us assume that the dynamic function f(·) is continuously differentiable. Then, the Jacobian matrix Jf(·) is continuous, and therefore, over a compact subset S ⊆ ℝn, the elements of Jf(x) are upper- and lower-bounded. It follows that over S, the Jacobian Jf can be overapproximated by an interval matrix. Then we can show that the distance between two trajectories in S satisfies a differential equation from a set of differential equations described using the interval matrix. By bounding the matrix measure of the interval matrix, we can get a discrepancy function over S.

Lemma 11.4 (Fan et al., 2016b).   Consider a dynamical system described by Equation (3.13) with initial set Θ, starting from time t₁. Suppose that S ⊆ ℝn is a compact convex set and [t₁, t₂] is a time interval such that Reach(Θ, [t₁, t₂]) ⊆ S. If there is an interval matrix IntA(S) such that ∀x ∈ S, Jf(x) ∈ IntA(S), then for any x₁, x₂ ∈ Θ, and for any t ∈ [t₁, t₂], the distance y(t) = ξ(x₂, t)−ξ(x₁, t) satisfies , for some A ∈ IntA(S).

Exercise 11.1.   Prove Lemma 11.4.

For any positive definite matrix M ≻ 0, at any fixed t ∈ [t₁, t₂], we can rewrite the time derivative of ∥y(t)∥M² by using Equation (11.3) as follows:

where A ∈ IntA(S). If there is a constant such that ATM + MA ≼M, for all A ∈ IntA(S), then Equation (11.6) becomes . After we apply Grönwall’s inequality, for all t ∈ [t₁, t₂], we obtain

Thus, over a set of states S as introduced in Lemma 11.4, for any positive definite matrix M ≻ 0 and constant is a discrepancy function.

We would like to choose M in order to obtain the tightest exponential bound , and this problem can be written as

That optimization problem potentially has infinitely many constraints—one for each A ∈ IntA(S). One strategy for attacking this is to solve the equivalent problem obtained by replacing the infinite set IntA(S) with the finite set of matrices representing the vertices of the interval matrix IntA(S). For a fixed , the resulting semidefinite program (SDP) can be solved using an SDP solver to find a feasible M. We choose a range of γ ∈ [γmin, γmax], and use this strategy to perform a line search to find the smallest over this range. The vertices of IntA(S) still generate O(2n² ) matrices that appear in the SDP.

An alternative practical strategy is to use a center matrix in IntA(S) and then bound the error in contributed by the other matrices in IntA(S). That approach reduces the number of constraints in the SDP, at the expense of more conservative discrepancy exponents (Fan et al., 2016b).

From locally optimal discrepancy functions to precise reachsets   Equation (11.7) gives a method for computing optimal local discrepancy functions for nonlinear systems. It is local in the sense that it is a valid discrepancy function over an interval of time [t₁, t₂] for all trajectories starting from an initial set Bδ(x) ⊆ Θ, so far as they stay in the set S or the Jacobian stays within IntA. To use that approach for computing the reachset Reach(Bδ(x), T) of the system from Bδ(x) ⊆ Θ up to time T, the local discrepancy functions for the sequence of time intervals have to be patched together. Observe that in this method, with S = Reach(Bδ(x), [t₁, t₂]), we get the most precise discrepancy, but of course, we do not know Reach(Bδ(x), [t₁, t₂]). The bigger the size of S, the more conservative the quality of the discrepancy will be. One approach is to use the Lipschitz constant Lf of f(·) to compute S. An even better approach is to use the reachset estimate from interval [ti−1, ti] to estimate the set Si needed for the interval [ti, ti+1].

When making the discrepancy functions and reachsets precise, there is a second source of imprecision that we have to worry about while patching them together in sequence. Suppose that we use ellipsoids for representing the reachset estimates in BasicSimReach. The shape matrix M₁ that is used for precisely overapproximating one ellipsoid (say, S₁) may not be that precise for another ellipsoid S₂. That is called a wrapping error; the name comes from the familiar problem of wrapping a gift of shape S₂ in a box of shape S₁; when doing this, we may need an unnecessarily big box. Thus, the shape matrix M₂ has to be recomputed precisely to overapproximate S₂ and not introduce too much error at the common time point. The algorithm implemented in the C2E2 tool (see Section 11.3.1) addresses those issues by combining the piecewise computation of local discrepancy functions and the shape matrices for the reachsets.

11.3  Hybrid system verification

The hybrid extension of BasicSimReach computes the set of reachable states for a hybrid system up to a given time bound T. The idea is to use the BasicReach algorithm from Chapter 9, with the Post𝒯(d) function implemented using the Bloat function.

To simplify this discussion, we will work with a simple hybrid automaton 𝒜 (Definition 4.2 in Chapter 4). Recall that a simple hybrid automaton 𝒜 = (V, Θ, A, 𝒟, 𝒯 ) has a set of variables V = X ∪{loc}, where X is a set of n real-valued variables and loc is a single discrete variable with type(loc) = Ł. The set of trajectories 𝒯 is described by a collection of differential equations , for each ℓ ∈ Ł.

The HybridSimReach algorithm (see Figure 11.3) performs breadth-first traversal on the control graph of 𝒜 to compute the hybrid reachset. It maintains a queue of triples with the following property: if ⟨init, ℓ, tRemain⟩∈ queue, that indicates that the reachset Reach(init, tRemain) for mode loc = ℓ is yet to be added to the output of the algorithm. The queue is initialized to ⟨Θ, ℓ₀, T⟩, where Θ is the initial set of valuations X and ℓ₀ is the initial mode. For any ⟨init, ℓ, tRemain⟩∈ queue, the steps of the algorithm are as follows:

1. A simulation of duration tRemain from the center of init is computed (line 6).

2. An overapproximation rtube[ℓ] of the reachset Reach(init, tRemain) for the mode loc = ℓ is computed up to time tRemain. This computation uses the Bloat function, which in turn computes a discrepancy function β using Jℓ (line 8).

3. The reachable set rtube[ℓ] is pruned by removing all the states that violate the mode invariant (line 9).

4. The resulting pruned reachset is used to check intersections with guards of any discrete transitions in 𝒟 in the discreteTransitions(·) function. If there are intersections, then for each possible next mode ℓ′, the corresponding set of initial values init′ and the tRemain′ are calculated, and the triple ⟨initℓ′, ℓ′, tRemainℓ′⟩ is added to queue.

Figure 11.3
Simulation-driven verification of hybrid models.

11.3.1  C2E2 verification tool

HybridSimReach is the core algorithm implemented in the hybrid system verification tool C2E2 (Duggirala et al., 2013; Fan et al., 2016a). In C2E2, the hybrid models and the requirements are specified in an Extensible Markup Language (XML) format that is similar to the language used in this book. The tool parses the XML to generate C++ libraries for computing numerical simulations and computes the other relevant quantities, like the Jacobian matrices for the various modes. The models and requirements can be edited and type-checked using the graphical user interface.

C2E2 can simply simulate hybrid automata, and, using HybridSimReach, it can check bounded invariant properties. The tool supports compositional modeling and has been used for analyzing mixed-signal circuits, ADAS systems, and models of pacemakers with cardiac oscillators. See, for example, the case studies described in Fan et al. (2018); Fan et al. (2018b); Huang et al. (2015); and Duggirala et al. (2015).

11.3.2  Example: Reachability analysis for PulseGen ∥ Oscillator with C2E2

Recall the hybrid I/O automaton model of the pulse generator and the FitzHugh–Nagumo oscillator from Section 5.7 in Chapter 5. The 2D Oscillator dynamics is given by nonlinear ODEs, and the pulse generator drives it with square wave inputs with specified duty cycles (see Figure 5.9 in Chapter 5). The hybrid automata models can be given as input to C2E2, and the tool computes the reachable states of the composed system from a set of initial states as shown in Figure 11.4.

Figure 11.4
Reachtubes of the PulseGen∥Oscillator model computed by C2E2 with the initial set t ∈ [0, 0]. The graph on the left is the reachtube for the variable U and right is for v.

11.4  Example: Powertrain control system

Among the most sophisticated control systems developed by automotive manufacturers are engine control systems. The demand for greater fuel efficiency and lower emissions constantly challenges engineers to improve this control software. Real engine control systems are obviously complicated and strongly protected intellectual property. Fortunately, a sanitized suite of powertrain benchmarks has been presented by Toyota (Jin et al., 2014). The suite consists of three Simulink models with different levels of complexity and sophistication. The most detailed model (model 1) involves delayed differential equations and lookup tables and has no closed-form mathematical description. Jin et al. (2014) used several heuristics to simplify model 1 to a second model (model 2) with periodic inputs to a set of ordinary differential equations. Model 2 was then further simplified to a hybrid system (model 3), which uses only polynomial ODEs. Here, we discuss model 3.

At a high level, the engine control system controls the thrust output from the engine, based on throttle inputs from the driver, by controlling the air–fuel ratio that is ignited in the internal combustion engine. The air-to-fuel ratio in turn influences the emissions, the fuel efficiency, and the torque generated. The hybrid automaton model Powertrain, shown in Figure 11.5, has four variables (intake manifold pressure p, air–fuel ratio lam, intake manifold pressure estimate pe, and integrator state iv) and two modes (Startup and Normal). The complete model of Jin et al. (2014) has two more modes (Power and sensorfail); Duggirala et al. (2015) and Fan et al. (2017) present verification results on the complete models. The verification problem is that of checking that the system meets certain properties under different throttle inputs from different driving profiles. The inputs can be seen as a switching signal bringing about the mode changes in Powertrain. (Recall the definition of switched systems from Section 4.3.2 in Chapter 4.) In Figure 11.5, a single driver profile is encoded by time-triggered transitions between the Startup and Normal modes based on the timer variable t. In the Powertrain model, those modes are named Startup and Normal, respectively; the transitions are called Cruise and Start.

Figure 11.5
Hybrid automaton model of a simple powertrain.

Jin et al. (2014) state the key requirement for the powertrain control system as “Within 4 seconds of entering the Normal mode, the air-fuel ratio lam should stabilize to be in the range [14.6, 14.8].” Observe that the requirement can be written as an invariant that uses the timer variable t. Thus, we can try to verify the requirement through reachability analysis; indeed, HybridSimReach can accomplish the task, overcoming the challenge of the nonlinear mode dynamics. Figure 11.6 shows a sample reachtube computed by C2E2. In fact, at the time of publication of Jin et al. (2014), reachability analysis of these models was beyond the existing tools, but within a year, the successful verification for the simplified powertrain models with C2E2 was reported in Duggirala et al. (2015).

Figure 11.6
Reachtube for lam versus time of the Powertrain model (model 1) produced by C2E2; light gray and black regions correspond to the Startup and Normal modes, respectively.

11.5  Verifying cyber-physical systems with incomplete models

For real-world CPS, complete and precise models are often unavailable. Toyota’s benchmark powertrain control system (Jin et al., 2014), for instance, has filter blocks, handcrafted lookup tables, and delayed differential equations. Some model blocks may be available only as executable code, without access to the internals, for intellectual property reasons. Extraction of clean mathematical models (e.g., ODEs) from those descriptions is usually infeasible. In this section, we present an approach for applying the data-driven verification to CPS with such black-box modules.

First, we describe a new formal model of CPS that can accommodate black-box components. After that, we will show how statistical methods can be used for estimating discrepancy functions for black boxes. Finally, we cover how statistical analysis of the black boxes can be combined with formal reasoning about the so-called white-box parts.

11.5.1  Hybrid automata with black-box modules

We view a CPS as a combination of a white-box control graph that defines the mode switches and a black box that generates the continuous trajectories. That is shown in line 1 of Figure 11.7. The resulting formal model is a simple hybrid automaton with a set of variables V = X ∪{loc} and set of modes Ł, where the mode switches across Ł are defined by a control graph (defined in Definition 11.5) and the trajectories over X are generated by black boxes. As usual, X is the set of n real-valued variables and loc is a single discrete variable with type(loc) = Ł. (Recall Definition 4.2 from Chapter 4.)

Figure 11.7
Hybrid automaton model with black-box and white-box components. The different modes are shown by shaded rectangles. The unknown (black-box) dynamics in each mode can be simulated (center). The known (white-box) control graph across the modes defines the mode switches. The combined black and white box model is shown on the right.

Definition 11.5.   Given a set of variables V = X ∪{loc} with type(loc) = Ł, a control graph is a labeled, directed graph G = ⟨V, E, elab⟩, where

(a) V⊆ Ł is the set of vertices,

(b) E ⊆ V× V is the set of edges, and

(c) elab labels each edge e ∈ E, with finitely many guards and reset maps on the variables in X.

The motivation for viewing the switching logic as a white box is that this logic is often implemented in a relatively clean piece of code, and standard program analysis can be used to infer the graph. This logical module is the control graph G in Definition 11.5. In contrast, the dynamics of a physical plant, with hundreds of parameters, is more naturally viewed as a black box. That is, it can be simulated or tested with various initial conditions and inputs, but it is hard to write a nice mathematical model.

The evolution of the continuous variables X over a given mode in Ł is described by labeled trajectories. A labeled trajectory is a pair (ξ, ℓ), where ξ: [0, T] → ℝn is a trajectory of X and ℓ ∈ Ł. The black box generates a set of labeled trajectories TL for each mode in Loc. We use TLinit, ℓ = {ξ.fstate | (ξ, ℓ) ∈ TL} to denote the set of initial states of trajectories in mode ℓ that could be generated by the simulator. Without loss of generality, we assume that TLinit, ℓ is a connected, compact subset of ℝn. We also assume that the black box can generate trajectories of any duration—that is, for each ℓ ∈ Ł, T > 0, and x ∈ TLinit, ℓ, there exists a (ξ, ℓ) ∈ TL, with ξ.fstate = x and ξ.ltime = T. The labeled trajectories generated by the black box are time-sampled simulations and are defined in the same way as in Definition 11.1, except that here, we may not have an underlying differential equation.

Definition 11.6.   A simulator for a deterministic and prefix-closed set TL of trajectories labeled by Ł is a function (or a program) sim, which takes as input a mode label ℓ ∈ Ł, an initial state x₀ ∈ TLinit, ℓ, and a finite sequence of time points t₁, …, tk, and returns a sequence of states sim(x₀, ℓ, t₁), …, sim(x₀, ℓ, tk) ∈ ℝn, such that there is (ξ, ℓ) ∈ TL with ξ.fstate = x₀, and for each i ∈{1, …, k}, sim(x₀, loc, ti) = ξ(ti).

For simplicity, we assume here that the simulations are perfect. Formal guarantees of soundness are not compromised even if we use simulations with error bounds, as in Definition 11.1. Our new definition of a hybrid automaton is analogous to Definition 4.1, except that TL is a set of deterministic trajectories labeled by Ł that can be simulated, but does not necessarily come from any known differential equations. Executions and reachable states are defined such that they are analogous to those in Chapter 4.

11.5.2  Learning discrepancy from simulations

The key subroutine Bloat, needed for computing the reachable states with the procedure HybridSimReach, has to compute a discrepancy function β that upper-bounds the distance between trajectories. Owing to the absence of ODE models, the approaches described in Section 11.2 are not applicable here. Instead, Fan et al. (2017) propose a probabilistic algorithm for estimating the discrepancy from the data generated by black-box simulators. The method is based on a well-known result in probably approximately correct (PAC) learning theory (Kearns and Vazirani, 1994). Roughly, a PAC learning algorithm receives positive and negative samples of a concept from a distribution D, and it must select a function h from a certain class of possible functions, such that h meets the required level of generalization error with the required probability. The specific concept that we will rely on for learning discrepancy functions concerns a linear separator.

Discrepancy as linear separator We will first review the main PAC learning result before proceeding to finding discrepancy functions. The object we will learn from data is called a linear separator.

Definition 11.7.   For a set of points Γ ⊆ ℝ × ℝ, a linear separator is a pair (a, b) ∈ ℝ² such that for all (x, y) ∈ Γ,

That is, the set Γ lies on one side of the line defined by (a, b). Let us fix the set Γ and consider the problem of finding a still-unknown linear separator (a*, b*). Our goal is to discover some (a, b) that is a linear separator for Γ by sampling points in Γ. The assumption is that elements of Γ can be drawn according to some unknown distribution D on ℝ × ℝ.

With respect to distribution D, the error of a linear separator (a, b) from satisfying Equation (11.8) is defined as

where D(X) is the measure of the set X ⊆ ℝ × ℝ under distribution D. Thus, the error is the measure of points (wrt D) for which (a, b) is not a linear separator. The following very simple (probabilistic) algorithm finds a pair (a, b) that is a linear separator for a large fraction of points in Γ:

The first step simply samples k points from Γ according to the distribution D. The second step involves checking the feasibility of a linear program, so it can be done efficiently. This algorithm finds a linear separator for a large fraction of points with high probability.

Proposition 11.5.   Let ε, δ ∈ ℝ≥0. If , then, with probability ≥ 1 − δ, the LinearSeparator algorithm finds (a, b) such that errD(a, b) < ε.

Proof. This result follows from the well-known result that concepts with low Vapnik-Chervonenkis dimension (VC-dimension) are efficiently PAC-learnable (Kearns and Vazirani, 1994). However, because the proof is very simple in this case, we reproduce it here for completeness. Let k be as in the statement of the proposition, and suppose that the pair (a, b) identified by the algorithm has error > ε. We will bound the probability of this event.

Let B = {(x, y)|x > ay + b}. We know that D(B) > ε. The algorithm chose (a, b) only because no element from B was sampled in the Sample step. The probability that no element from B was sampled is ≤ (1−ε)k. If we incorporate the observation that (1−s) ≤ e−s for any s, we get . That gives us the desired result.

Using this result, we can compute discrepancy functions from simulation data independently for each mode. Let us fix a mode ℓ ∈ Loc of the hybrid automaton, and a domain [0, T] for each trajectory. Let us also fix the shape of the discrepancy function to be learned such that it takes the exponential form. We call this the global exponential discrepancy (GED):

where K and γ are constants to be determined, and as before, x₁ and x₂ are a pair of initial states for two trajectories ξ₁(t) = ξ(x₁, t) and ξ₂(t) = ξ(x₂, t). Thus, using the definition of discrepancy functions (Definition 11.3 for any pair of trajectories ξ₁ and ξ₂ for mode ℓ), we have

If we take logs on both sides and rearrange the terms, we obtain

Now consider a set of sampled trajectories {ξk(ti)} for the black-box model. From these trajectory samples, we can construct set Γ, consisting of pairs as follows:

for every pair of trajectories ξ₁, ξ₂ and sampling time point ti. From Equation (11.10), it is clear that GED, as defined by K and γ, is nothing but a linear separator for this set of points in Γ.

Using LinearSeparator, we can construct a GED for mode ℓ, where the first step, sampling from Γ, reduces to using the simulator to generate traces from different states in TLinit, loc. Proposition 11.5 guarantees the correctness of the resulting discrepancy function, with high probability, for any separator discovered by LinearSeparator. However, for the discrepancy function to be accurate, we would like K and γ to be small. Thus, when checking the feasibility of the linear program in the second step of LinearSeparator, we minimize γT + lnK.

Learned discrepancy and guarantees in practice In theory, there is some probability that the learned discrepancy function β is incorrect. That is, some pair of trajectories ξ, ξ′∈ TL of the system, starting from the same initial state Θ, diverge more than the bound given by the computed β. However, experiments have shown that that is rare (Fan et al., 2017). In the reported experiments, for each mode, a set Strain of simulation traces that started from independently drawn random initial states in TLinit, ℓ was used to learn a discrepancy function. Then, another set Stest of 1,000 simulation traces were drawn to validate the computed discrepancy. For every pair of traces in Stest, and for every time point, the researchers checked whether the computed discrepancy satisfied Definition 11.3(i). The findings were that for |Strain| > 10, the computed discrepancy function was correct for 96 percent of the points in Stest, and for |Strain| > 20, it was correct for more than 99.9 percent of the points.

11.5.3  DryVR verification tool

The DryVR tool (Fan et al., 2017) implements the Bloat() function in the HybridSimReach algorithm with a subroutine for learning discrepancy from simulation data. As a result, DryVR can verify black-box hybrid models as defined in Section 11.5.1. The labeled control graph is specified in a JavaScript Object Notation (JSON) file, and the black-box simulators have to be provided as separate functions. DryVR supports other forms of discrepancy functions (e.g., piecewise exponential and polynomial) that also can be learned from simulation data with the same type of guarantees.

To use the DryVR approach on a system, we have to make some practical choices. First, we could treat the whole system as a black box with a single mode. At the other extreme, we could first identify the modes of the underlying dynamical system and the mode switching logic (e.g., by inspecting the model block diagrams or through program analysis), and then treat the individual modes as black boxes. Intermediate policies could, for example, aggregate sets of modes that start with different initial conditions and stabilize to common set points. Second, for the black-box modules, we need to choose the system variables that are to be considered for reachability analysis. The variable valuations have to be computable from the simulation traces; they should be adequate for inferring the safety properties; and they should be resettable (i.e., the simulation engine should be capable of changing the initial values of these variables to generate different simulation traces).

The models from the Toyota powertrain benchmark suite (Section 11.4) have been analyzed using DryVR. Parts of model 1 that involve lookup tables and delayed differential equations are beyond purely model-based verification approaches and have to be treated as black-box simulators. For the results reported in Fan et al. (2017), the complete system was treated as a system with initial uncertainty in four variables and four modes with separate black-box simulators. For the initial set p ∈ [0.61, 0.63], lam ∈ [14.6, 14.8], pe ∈ [0.55, 0.57], and iv ∈ [0, 0.01], DryVR proves that the system satisfies the safety requirements as stated in Jin et al. (2014). Figure 11.8 shows a sequence of reachtubes computed by DryVR for the air–fuel variable lam as the system goes through the sequence of modes Startup, Normal, Power, and again Normal.

Figure 11.8
Reachtubes for lam vs. time of the powertrain model (model 1) produced by DryVR. Left to right, reachtubes overapproximations (black set) are shown in successive refinements. The light gray region is the unsafe value of λ.

Observe the exponential overapproximation envelopes constructed by the tool using exponential discrepancy functions. In the initial iterations of BasicSimReach, the reachtube overapproximations intersect with the unsafe set (shown in light gray), but ultimately, safety is established with an appropriately tight overapproximation.

11.6  Example: Analyzing risk in automatic emergency braking systems

We will discuss the application of data-driven verification for risk analysis in automatic emergency braking (AEB) systems of the type discussed in Section 5.9 of Chapter 5. In the context of automotive safety standards like ISO 26262, risk is broadly defined as

Recall the scenario from Section 5.9, in which n cars driving on the highway (Figure 5.11 in Chapter 5) are described as a composed hybrid I/O automaton (HIOA) SLPlatoon. The key parameters of the automaton are the driver’s reaction time (RT), the initial intervehicle separation (d₀), the safety distance threshold used for braking (ds), and the braking profile (a). For this analysis, we will fix the safety threshold ds and the braking profile a, and analyze the risk arising from different values of separation d₀ and reaction times RT. This is the type of analysis that is performed for evaluating Automotive Safety Integrity Level (ASIL) values (see Section 6.2.2 in Chapter 6) for ISO 26262 (Fabris, 2012).

Our first step is to estimate the probability that certain scenarios will arise. In our setup, we can start certain distributions over reaction times RT and vehicle separation d₀. It turns out that the distributions can be estimated via such devices as overhead cameras on highways. Two such sample distributions from Fabris (2012) are shown at the top of Figure 11.9. Let p₁ be the probability that vehicle separation d₀ is in the range [d₀₁, d₀₂] and p₂ be the probability that the driver reaction time RT is in the range [RT₁, RT₂]. Then, assuming the independence of those parameters, we find that the SLPlatoon scenario with d₀ ∈ [d₀₁, d₀₂], RT ∈ [RT₁, RT₂] occurs with probability p₁p₂.

Figure 11.9
Risk analysis using data-driven reachability. Top: Empirical distribution of parameter values for initial separation and driver reaction times. Middle: Reachtubes computed by DryVR projected on the positions of the three vehicles. Bottom: Matrix of accident severity estimated from reachtube intersections.

Our second step is to estimate the severity of an accident for a given scenario, such as SLPlatoon, with d₀ ∈ [d₀₁, d₀₂], RT ∈ [RT₁, RT₂]. Let us assume that in the case of a collision, the severity is proportional to the relative velocity. The maximum relative velocity of collision for any behavior in this scenario can be approximated using reachability analysis. In Fan et al. (2018), this step is performed using DryVR. The detailed dynamics of each vehicle comes from a black-box simulator, and the higher-level decisions about the mode switches are triggered according to the rules specified in SingleLaneCar (Figure 5.12 in Chapter 5). The composed hybrid automaton graph is presented to DryVR as the input model. The reachtubes for two scenarios projected on the positions of three cars are shown in the center of Figure 11.9. It is clear from the plot that the reaction time of the driver in car 2 is slower in the upper scenario and leads to a collision with car 1. The reachtubes for velocities (not shown here) give upper bounds on the maximum relative velocity, and therefore the severity of accidents.

If we repeat this procedure for each possible range of values for reaction time RT and initial separation d₀, we can compute an accident severity matrix like the one illustrated at the bottom of Figure 11.9. From that matrix and the probability of each scenario as calculated here, we estimate the expected risk for the entire family of scenarios represented by SLPlatoon. The risk level is then used to ascertain the safety of the given braking profile under a given highway speed.

11.7  Example: Autonomous spacecraft rendezvous

The extreme cost of failure and the infeasibility of terrestrial testing have made formal methods singularly attractive for space systems. Reachability-based automatic safety verification for satellite control systems was first studied by Johnson et al. (2012). At the time of that study, hybrid verification tools were available only for linear hybrid systems, and those tools have restricted applicability because many satellite control problems involve nonlinear orbital dynamics and nonlinear constraints. Here, we present a case study based on the ARPOD problem introduced in Jewison and Erwin (2016). ARPOD stands for autonomous rendezvous proximity operations and docking. It describes an overarching mission for assembling a new space station that has been launched in separate modules. Our discussion is based on the models and results presented in Chan and Mitra (2017a) and Chan and Mitra (2017b).

A generic ARPOD scenario involves a passive module or target (launched separately into orbit) and a chaser spacecraft that must transport the passive module to an on-orbit assembly location. The chaser maintains a relative bearing measurement to the target, but initially, it is too far away to use its range sensors. Once range measurements become available, the chaser gets more accurate relative positioning data, and thus it can stage itself to dock with the target. Docking must happen with a specific angle of approach and closing velocity, in order to avoid collision and ensure that the docking mechanisms on each spacecraft will mate.

For simplicity, we discuss the planar (or 2D) version of the model. The variables of the hybrid model include position (relative to the target) x, y (in m), time t (in min), and horizontal and vertical velocity vx, vy. The modes of the hybrid automaton capture four phases of the docking maneuver. Each phase is defined by a separation distance between the chaser and target spacecraft, the closing of this distance from up to 10 km down to 0, and then the performance of a maneuver once the satellites are docked. As seen in Figure 11.10, the chaser spacecraft begins in Phase1, at which time the separation distance ρ is not available and the system is unobservable, but the angle of approach is available. When ρ gets small enough, the mission moves into Phase2, during which the chaser spacecraft has a ranging measurement to the target spacecraft and must position itself for the Phase3 docking. After the chaser has moved such that ρ ≤ 100, the docking phase, Phase3, is initiated, and additional docking port constraints become active. Once the spacecraft have docked (i.e., ρ = 0), both spacecraft move into Phase4, during which the joint assembly must move to the relocation position (not shown in Figure 11.10).

Figure 11.10
ARPOD system model for spacecraft. Top: Depiction of the overall mission phases (not to scale). Bottom: Hybrid system model of the autonomous spacecraft rendezvous mission.

The chaser must adhere to different sets of constraints in each discrete mode. In Chan and Mitra (2017a), a switched linear quadratic regulator (LQR) is designed to meet those constraints while maintaining liveness in navigating toward the target spacecraft. At the bottom of Figure 11.10 is the hybrid system model of interest. In addition to the existing mode, the model has a Passive mode in which the chaser has the thrusters shut down. The system may nondeterministically transition to the Passive mode as a result of a failure or loss of power from either Phase2 or Phase3. The nonlinear dynamic equations describing the motion of the chaser spacecraft relative to the target are given by

The parameters are μ = 3.986 × 10¹⁴ × 60² [m³ / min²], r = 4.2164 × 10⁷ [m], mc = 500 [kg], , and . The linear feedback controllers for the different modes are defined as [Ux, uy]T = K₁x for mode Phase1, and [Ux, uy]T = K₂x for mode Phase2, where x = [x, y, vx, vy]T is the vector of system states. The feedback matrices Ki were determined with an LQR approach applied to the linearized system dynamics; the details can be found in Chan and Mitra (2017a). In Passive mode, the system is uncontrolled and [Ux, uy]T = [0, 0]T. We consider a scenario in which the spacecraft starts from the initial set x ∈ [−925, − 875] [m], y ∈ [−425, − 375] [m], vx = 0 [m/min], and vy = 0 [m/min]. For the considered time horizon of t ∈ [0, 200] [min], the following specifications have to be satisfied:

Line of sight: In mode LmodePhase3, the spacecraft has to stay inside the line-of-sight cone {[x, y]T | (x ≥ −100) ∧ (y ≥ xtan (30°)) ∧ (−y ≥ xtan (30°))}.

Collision avoidance: In mode LmodePassive, the spacecraft has to avoid a collision with the target, which is modeled as a box B with a 0.2-m edge length and the center placed at the origin.

Velocity constraint: In mode LmodePhase3, the absolute velocity has to stay below 3.3 [m/min]: [m/min].

C2E2 was used to prove that the autonomous rendezvous system with the LQR controller satisfies these requirements. On the left side of Figure 11.11 is the reachtube of x (x-axis) versus y (y-axis) produced by C2E2. A different control strategy for ARPOD was proposed by Malladi et al. (2016), which characterizes the family of individual controllers and the required properties that they should induce in order for the closed-loop system to be able to meet the ARPOD constraints. Based on this characterization, Malladi et al. (2016) design a supervisor that robustly coordinates the individual controllers. By using those controlled subsystems as a black box, we were able to check the safety of the overall system using DryVR. On the right side of Figure 11.11 is the reachtube of x and y produced by DryVR.

Figure 11.11
Reachability analysis for a spacecraft system with C2E2 and DryVR. Left: Reachtube of x-y positions produced by C2E2 for the first three phases of the ARPOD system. Right: Reachtube of x versus time (above) and y versus time (below) produced by DryVR.

11.8  Further reading

11.8.1  Related approaches, software tools, and applications

Data-driven verification algorithms have been implemented in several other software tools, such as Breach (Donzé, 2010) and STRONG (Deng et al., 2013), and these tools have been used to verify benchmark problems in several application domains. Sensitivity analysis is a technique for systematically simulating arbitrary nonlinear systems with inputs (Donzé and Maler, 2007). The technique relies on computation of a sensitivity matrix—a matrix that captures the sensitivity of the system to its initial condition x₀. The sensitivity matrix is then used to give an upper bound on the distance between two system trajectories. Julius and Pappas (2009) provide a sound simulation-driven method to overapproximate the distance between trajectories for affine and polynomial systems. The work closest to the approaches presented in this chapter includes the approaches of Maidens and Arcak (2015), which use the property that the matrix measure of the Jacobian matrix can bound the distance between neighboring trajectories (Boichenko and Leonov, 1998; Sontag, 2010). The technique relies on user-provided, closed-form matrix measure functions, which are generally difficult to compute. In contrast, the on-the-fly algorithm of Section 11.2.3 automatically computes the bounds on matrix measures under 2-norm or coordinated transformed 2-norm.

The idea of computing the reachsets from trajectories is related to the notion of incremental Lyapunov functions (Angeli, 2002), although the bounded-time verification algorithms presented in this chapter do not require systems to be incrementally stable. Similar ideas also are considered for control synthesis by Zamani et al. (2012). Other successful application areas range from medical devices (Huang et al., 2014; Jiang et al., 2012) to automotive systems (Duggirala et al., 2015; Arechiga et al., 2015; Jin et al., 2015; Fainekos et al., 2012) to air-traffic management (Duggirala et al., 2014) to energy systems (El-Guindy et al., 2016).

11.8.2  Limitations and open problems

Limitations of the current data-driven verification theory suggest several open problems.

Sample complexity: How many sample executions of 𝒜 are needed for verifying a given requirement R? This is important because generating millions of samples—whether by simulation or real tests—can be prohibitively expensive. The algorithm of Fan et al. (2016b, 2018a) improves empirical sample complexity by creating locally optimal overapproximations, but it does not provide any upper bound on the number of samples needed by the algorithm. Conservative exponential upper bounds (in the dimensions of the state space) can be derived using the Lipschitz constant. The complementary question of finding lower bounds for the verification problem remains more or less open. The notion of estimation entropy developed by Liberzon and Mitra (2018) could provide some clues for cases where the model 𝒜 is known. For the fully model-free version of the problem, the literature on the multiarmed bandit problem (see, e.g., Lattimore and Szepesvári (2020); Munos (2014)) is likely to provide the necessary mathematical concepts and tools.

Unbounded time requirements: Could data-driven approaches verify progress and temporal logic requirements? Bounded time progress may be reduced to invariance by adding new state variables (recall the discussion in Section 6.3.4 of Chapter 6), and therefore, it can be found using BasicSimReach. However, this may not be sample efficient or necessary. Besides, this reduction would not work for unbounded time properties.

Equivalence checking, unbounded initial states, and dimensions: Could data-driven approaches be applied to models with unbounded initial states and for checking equivalence of models? Because the data-driven approach relies on finitely covering the initial set (or the space of uncertain parameters), verifying systems with unbounded initial sets (even with simple, known, linear models) is currently out of reach.

11.8.3  Falsification

A noteworthy related approach is simulation-driven falsification, which addresses the problem of finding bugs but does not aim to prove their absence (Abbas and Fainekos, 2011). The search for bugs is formulated as an optimization problem, and because such problems typically work out to be nonlinear and nonconvex, stochastic optimization tools are employed to guide the process. The preeminent tool implementing that approach is S-TaLiRo (Annapureddy et al., 2011); it has been effectively used to search for bugs in several practical applications, including automotive systems (Fainekos, 2015) and artificial pancreas control systems (Sankaranarayanan et al., 2017).

Although data-driven verification is a young field, the literature in this area is growing, and interesting results are published every year. For an alternative view of this topic from the perspective of modeling, testing, and verification of embedded control systems, see Kapinski et al. (2016).

11.8.4  Statistical model checking

Statistical model checking (SMC) is a data-driven approach for verifying the requirements of a stochastic system specified in a stochastic temporal logic such as probabilistic CTL (PCTL) or continuous stochastic logic (CSL) (Younes and Simmons, 2002). If SMC is to be applied to the underlying system, 𝒜 has to be stochastic (e.g., a discrete-time Markov chain, a continuous-time Markov chain, or a stochastic hybrid system). That is, there has to be a probability space on the executions Execs𝒜. A typical PCTL formula takes the form P≥θ(ψ), where ψ is a bounded-time CTL formula (see Section 6.5.1 in Chapter 6), and a state x satisfies this formula if the probability measure of all the executions starting from x and satisfying ψ is at least θ. In SMC, the system 𝒜 is executed repeatedly using a (possibly black-box) simulator, and the path formula ψ is checked on each generated finite execution. A checked execution provides an observation, or sample point, of a Bernoulli random variable X, which is 1 if ψ holds and 0 otherwise. Thus, SMC algorithms perform either hypothesis testing or probability estimation to verify the PCTL formula. Extensions of SMC to unbounded time requirements are presented in Sen et al. (2005a).

The commonality between SMC and the data-driven algorithms discussed in this chapter lies in the use of simulation data, but instead of computing reachable states, SMC uses simulations to estimate the parameters of probability distributions or test hypotheses. SMC has been applied to the analysis of stochastic hybrid systems (Meseguer and Sharykin, 2006), such as distributed power grid models (Martins et al., 2011). Several software tools, such as VESTA (Sen et al., 2005b), PRISM (Hinton et al., 2006), UPPAAL (Behrmann et al., 2011), and PLASMA-lab (Boyer et al., 2013), implement SMC algorithms. SMC is an active area of research, and for further information, see Agha and Palmskog (2018) and Legay and Viswanathan (2015).

11.8.5  Verification for machine learning modules

ML algorithms like deep neural networks (DNNs) and reinforcement learning (RL) have demonstrated astonishing success in pattern recognition tasks (Krizhevsky et al., 2012), two-player games (Silver et al., 2017), and robotics (Abbeel et al., 2006). These algorithms, often broadly termed ML modules, are being incorporated into autonomous systems and CPS for perception and control. For example, DNNs are used for perception and object recognition in autonomous vehicles. (Revisit the computational pipeline shown in Figure 1.1 in Chapter 1.) Incorporation of ML modules has given rise to an important variant of the verification question that is receiving significant attention:

How can one verify CPS that use ML modules?

Of the many challenges involved in addressing that question, first and foremost is the lack of requirements for ML modules. An ML module such as a DNN uses a data set (e.g., of images and video), say D, to train a function f: X → Y that serves as a classifier, recognizer, or controller. Roughly speaking, the pipeline works as follows: The complete data set D is split into a training set Dr and a test set Ds. First, the training set is used to train or optimize parameters in f. Then, the performance or the error of the resulting f is measured on the hitherto-unseen test set Dr. However, to interpret that error outside of D, we have to reason about the relationship between D and the real world that D is supposed to represent.

A simpler problem is to check a local robustness property of the trained function f: that is, at a given input point x ∈ X, for all x′∈ N(x) in a given neighborhood N(x) of x, f(x′) = f(x). Generally, the functions learned by DNNs are known to be discontinuous, and they do not possess this property even for small N(x) neighborhoods. The existence of adversarial inputs also points to this fact (Szegedy et al., 2013). Indeed, the sensitivity-based techniques discussed in this chapter can be useful in verifying this local robustness property. For further reading on this rapidly evolving subarea, see the works on Reluplex (Katz et al., 2017), Sherlock (Dutta et al., 2019), Verisig (Ivanov et al., 2019), VERIFAI (Dreossi et al., 2019), and VNN (Xiang et al., 2018a), and recent survey articles by Liu et al. (2019) and Xiang et al. (2018b).

11.9  Exercises

Exercise 11.2.   Use Theorem 11.2 to find a discrepancy function for the simple economy model of Equation (3.25) in Chapter 3, with fixed model parameters α = 3, β = 1, and k = 0.

Exercise 11.3.   Use Theorem 11.2 to find a discrepancy function for the simple economy of Equation (3.25), but this time for any α ∈ (0, 1), β ∈ (1, ∞), and k = 0. Show that V(x) = xTPx, with , is a Lyapunov function for the model.

Exercise 11.4.   Write a discrepancy function for the following 2D nonlinear system:

Show that the time-varying function y(t) = ξ(x′, t) − ξ(x′, t) satisfies

and then use Grönwall’s inequality to get the result.

Exercise 11.5.   We would like to estimate a global polynomial discrepancy function of the form from a set of sampled trajectories {ξ(x, tj)}x∈S, tj∈{0, …, T}, where S is a finite set of initial states, T is the time horizon of the trajectories, and k is the order of the polynomial. Show that the αi coefficients can be found by solving a linear program so that the solution β (if feasible) is a discrepancy function that works for the trajectory data set. The cost to be minimized could be the volume of the reachset at the final time step T.

Appendix A: Linear Algebra and Real Analysis

Overview

This appendix provides background definitions and results from linear algebra and real analysis that are used in this book. For a more detailed treatment, see Boyd and Vandenberghe (2004).

A.1  Sets and functions

The complement of a set A is denoted by Ac. The union of a collection {Ai}i∈I of pairwise disjoint sets indexed by a set I is written as ⊎ i∈IAi. For any function f, the domain and range of f are denoted by dom(f) and range(f). For a set S, we write f ⌈ S for the restriction of f to S, that is, f ⌈ S is equal to the function g with dom(g) = dom(f) ∩ S, such that g(c) = f(c) for each c ∈ dom(g). If f is a function whose range is a set of functions, then we write f ↓ S for the function g with dom(g) = dom(f), such that g(c) = f(c) ⌈ S for each c ∈ dom(g). For an indexed tuple or an array b with n elements, we use the special notation b[i] to refer to its ith element.

A.1.1  Vectors and norms

The absolute value of any real number x ∈ ℝ is denoted by |x|. The ith component of an n-dimensional vector x ∈ ℝn is denoted by xi. A real-valued function f: ℝn → ℝ is called a norm if it is (1) nonnegative, (2) definite [i.e., f(x) = 0 ⇔ x = 0], and (3) homogeneous [i.e., f(ax) = |a|f(x) for all x ∈ ℝn, a ∈ ℝ], and (4) it satisfies the triangle inequality [i.e., f(x + y) ≤ f(x) + f(y) for all x, y ∈ ℝn]. A norm measures the length of a vector. Unless stated otherwise, we use the notation f(x) = ∥x∥ to denote any norm of x. When we specify a particular norm, we use ∥x∥sym, where sym will identify the particular norm.

The ℓ₁-norm is ; the ℓ₂-norm is ; and, for any 1 ≤ p < ∞, the ℓp-norm is . The ℓ∞-norm is ||x||∞ = maxi|xi|. We define a quadratic norm by first transforming the vector. Given a positive definite n×n real-valued matrix M, the M-norm of a vector x ∈ ℝn is defined as

which is the norm of x under the transformation M. For any positive definite matrix M ≻ 0 (see Definition A.2), there is a nonsingular matrix C ∈ ℝn×n such that M = CTC, where is the matrix square root of M. Thus, . That is, ∥x∥M is the 2-norm of the linearly transformed vector Cx. When M = I is the identity matrix, ∥x∥I coincides with the 2-norm.

A basic result from analysis says that norms are equivalent up to a constant factor. That is, suppose that ∥·∥a and ∥·∥b are two norms on ℝn. Then, there are positive constants α, β such that for all x ∈ ℝn,

A.1.2  Continuity and derivatives

A function ℝn → ℝm is continuous at x ∈ dom(f) if for all ε > 0, there is a δ such that for all y ∈ dom(f), ∥y − x∥₂ ≤ δ ⇒∥f(y) − f(x)∥₂ ≤ ε. If f is continuous at every point, then it is said to be continuous. A function f: ℝn ℝm is Lipschitz continuous if there is a constant L ≥ 0, such that for any x₁, x₂ ∈ X, |f(x₁) − f(x₂)|≤ L|x₁ − x₂|. Any such constant is called a Lipschitz constant.

Definition A.1.   Consider a function f: ℝn → ℝm and a point x in the interior of dom(f). The function f is differentiable at x if there is a matrix J(x) ∈ ℝm×n such that

In that case, the unique matrix J(x) is called the Jacobian (or derivative) of f at x. The function f is differentiable if dom(f) is open and is differentiable at every point.

The Jacobian can be found from partial derivatives as follows:

The functions f(x) ex and f(x) = x² are continuous and differentiable with respect to x, but not Lipschitz continuous, while the function f(x) = |x| is Lipschitz continuous with the Lipschitz constant L = 1, but not differentiable at x = 0. A function f: ℝn ℝn is positive definite if f(0) = 0 and f(x) > 0 for all x ≠ 0. It is radially unbounded if f(x) ∞ as |x| ∞.

A.1.3  Covers and partitions

For any subset A of Euclidean space ℝn, A is compact if and only if it is closed and bounded. For example, the interval [a, b], a < b is compact, but neither [a, b) nor [a, ∞) is. A δ-cover of a compact set Θ ⊆ ℝn is a finite collection {Ci}, with each Ci ⊆ ℝn, such that ∪iCi ⊇ Θ. A δ-partition is a δ-cover in which each of the subsets in the collection is pairwise disjoint.

A.2  Linear functions

A matrix with n rows and m columns is called an n × m matrix. Linear functions from an n-dimensional space (e.g., ℝn) to an m-dimensional space can be represented by an n×m matrix. The jth element in the ith row of the matrix is denoted by aij, i ∈{1, …, n}, j ∈{1, …, m}. The set of all n×m matrices with real-valued elements is denoted by ℝn×m. The transpose of A, denoted by AT, is the m×n matrix obtained by making each row of A into a column of AT. The conjugate transpose of A is denoted by A*.

Each element aij in an n × n square matrix A is associated with a minor Mij, which is the determinant of the (n − 1) × (n − 1) matrix resulting from the deletion of the ith row and the jth column of A. The cofactor Cij of aij equals (−1)i+j ×Mij. The rank of A, rank(A), is the size of the largest nonzero determinant that can be formed from A. An n × n square matrix is called full rank if rank(A) = n. A matrix A is nonsingular (and also invertible) if there is a matrix B such that AB = BA = I, where I is the identity matrix of the appropriate size.

A.3  Eigenvalues and eigenvectors

Consider an n × n matrix A. The kernel or the nullspace of A is the set of vectors {x ∈ ℝn | Ax = 0}. The dimension of the nullspace is called the nullity.

If x is an n-dimensional vector such that there is a real or complex number λ satisfying

then λ is an eigenvalue of A and x is the corresponding eigenvector. If the eigenvalue λ = 0, then Ax = , and the corresponding eigenvectors are in the nullspace of A. An n × n matrix has n eigenvalues, which can be found by finding the roots of the characteristic polynomial—that is, det(A − λI). The sum of the eigenvalues equals the trace of the matrix. If the complex number a + bi is an eigenvalue of A, then so is its conjugate, a − bi.

For an eigenvalue λ, its algebraic multiplicity is the number of roots of the characteristic polynomial at λ, and its geometric multiplicity is the maximum number of linearly independent eigenvectors that correspond to λ. For example, for both of the following matrices,

the eigenvalue λ = 1 has an algebraic multiplicity of 2, but it has a geometric multiplicity of 1 for A₁ and 2 for A₂.

A real-valued matrix A ∈ ℝn×n is symmetric if A = AT. A complex-valued matrix A is Hermitian if it is equal to its own conjugate transpose. Theorem A.1 characterizes the eigenvalues of symmetric (and, more generally, Hermitian) matrices.

Theorem A.1.   If A is a Hermitian matrix, then there exists an orthonormal basis for the complex space consisting of eigenvectors of A, and each eigenvalue is real.

Any symmetric matrix A can be factored as A = QΛQT, where Q ∈ ℝn×n is orthogonal (i.e., QTQ = I), and Λ = diag(λ₁, …, λn) is a real-valued diagonal matrix for which the diagonal is the eigenvalues of A. That factorization is called the spectral decomposition or eigenvalue decomposition of A. In this case, the eigenvalues can be ordered λ₁ ≥ λ₂ ≥… ≥ λn. The ith eigenvalue of A is denoted by λi(A); the maximum and the minimum eigenvalues are denoted by λmax(A) and λmin(A), respectively.

A.3.1  Positive definite matrices

Definition A.2.   A matrix A is positive definite if for all x ≠ 0, xTAx > 0. Positive-definiteness of A is denoted by A ≻ 0. If − A is positive definite, then A is called negative definite, and we write A ≺ 0. If xTAx ≥ 0 for all x, then A is said to be positive semidefinite. If − A is positive semidefinite, then A is called negative semidefinite.

Proposition A.2.   For any positive definite matrix A ≻ 0 and any vector xT ∈ ℝn,

It follows that A ≻ 0 if and only if all its eigenvalues are positive [i.e., λmin(A) > 0]. Consider a positive semidefinite matrix A with the eigenvalue decomposition A = Q diag(λ₁, λ₂, …, λn) QT. The symmetric square root of A is defined as:

A.3.2  Jordan normal form

For every n × n matrix A, there is a nonsingular n × n matrix P, such that

where each Ji is a square matrix called a Jordan block, which takes the form

The upper triangular matrix J is called the Jordan normal form, and it is unique up to the order of the Jordan blocks. Some of the Jordan blocks may correspond to the same eigenvalue, λi. It can be shown that the number of Jordan blocks corresponding to λi is λi’s geometric multiplicity, and that the sum of the sizes of all Jordan blocks corresponding to λi is its algebraic multiplicity.

A.3.3  Matrix norms

For any matrix A ∈ ℝn×n and any vector norm ∥·∥ on ℝn, the corresponding induced matrix norm is defined as follows:

The induced matrix norm gives a measure of the maximum amount by which A can stretch a unit vector. For example, the induced p-norm of A is ∥A∥₁, ∥A∥₂, ∥A∥∞, and ∥A∥F denote the 1-, 2-, infinity, and Frobenius norms of A, respectively. In special cases, for p = 1, 2, ∞, the induced matrix norms can be computed from the elements of the matrix as follows:

Here, ∥A∥₁ is the maximum absolute column sum, ∥A∥∞ is the maximum absolute row sum, ∥A∥₂ is also called the spectral norm, and the Frobenius norm ∥A∥F serves as an upper bound for ∥A∥₂.

A.3.4  Interval matrices

For a pair of matrices B, C ∈ ℝn×n with the property that bij ≤ cij for all 1 ≤ i, j ≤ n, we define the set of matrices interval([B, C]) ≜{A ∈ ℝn×n|bqij ≤ aij ≤ cij, 1 ≤ i, j ≤ n}. Any such set of matrices is called an interval matrix. We can use interval matrices to linearly overapproximate behaviors of nonlinear models. Two useful related notions are the center matrix and the range matrix, defined as center([B, C]) = (B + C)/2 and range([B, C]) = (C − B)/2, respectively. Further, interval([B, C]) can also be written as interval([Ac − Ar, Ac + Ar]), where Ac = center([B, C]) and Ar = range([B, C]). A vertex matrix of an interval matrix interval([B, C]) is a matrix V whose every element is either bij or cij. Let vertex(interval([B, C])) be the set of all the vertex matrices of the interval matrix interval([B, C]). The cardinality of vertex(interval([B, C])) with B, C ∈ ℝn×n is 2n² .

A.4  Grönwall’s inequality

Grönwall’s inequality, as it first appeared in Gronwall (1919), bounds the distance between the solutions of a differential equation starting from two initial conditions, x₀ and x₀′. However, with no extra work, it can be generalized to Theorem A.3 to bound the solution of two differential equations, and . The original inequality is a special case of Theorem A.3, with g = f.

Theorem A.3.   Consider the continuous functions f, g: ℝn × [a, b] → ℝn. Suppose that g is Lipschitz continuous in the first argument with the Lipschitz constant Lg. Let ξ, ξ′: [a, b] × ℝn → ℝn be the solutions of and , and thus satisfy:

Suppose that there exists a continuous function φ: [a, b] → ℝ≥0, such that for all t ∈ [a, b]

Then, for any t ∈ [a, b]:

Proof. We begin with the inequality that holds for any continuously differentiable function y: [a, b] → ℝn, that is . Applying this to the function ξ(t) − ξ′(t), we get

Thus, we have

If we multiply both sides by e−Lgt, we get

Integrating from a to t, we get an inequality that is equivalent to the final form:

Inequality (A.3) may be difficult to use, as it involves the solution ξ(t), which may not be known. Inequality (A.3) can be replaced with a stronger global assumption over all x in the proof:

The more familiar form of Grönwall’s inequality for solutions of the same differential equation starting from different initial conditions follows from Theorem A.3 via replacing of g with f. The proof follows from setting φ(t) = 0 in the proof of Theorem A.3.

Corollary A.4.   Consider a continuous function f :ℝn × [a, b] → ℝn that is Lipschitz continuous in the first argument with constant Lf. Let ξ, ξ′: [a, b] × ℝn → ℝn be the solutions of with ξ(a) = x₀ and ξ′(a) = . Then, for any t ∈ [a, b]:

Note that in Theorem A.3, f is not assumed to satisfy a Lipschitz condition, and therefore the corresponding ODE may not have unique solutions. Nevertheless, Inequality (A.4) and Theorem A.3 can be combined to give a version of Grönwall’s inequality for ordinary differential equations (ODEs) that do not satisfy a Lipschitz condition in terms of the Lipschitz constant of an ODE that does and is nearby (as measured by φ).

Appendix B: Computability and Complexity

Overview

In discussing the hardness of verification problems and efficiency of algorithms, we will use standard notions from complexity theory in a technology-independent fashion. This appendix provides a brief overview of the basic definitions and results. For more detailed coverage of this topic, refer to Sipser (1996), Arora and Barak (2009), and Papadimitriou (2003).

Here, we will focus on decision problems, that is, problems for which we expect a “yes” or “no” answer to an input. An optimization problem, on the other hand, is a problem for which the expected answer is a value. For example, checking whether a set of states U is reachable from the set of initial states Θ of a finite automaton is an example of a decision problem. Finding the shortest path from Θ to U is an optimization problem.

B.1  Computability

Notations   For any finite set (alphabet) Σ, Σ* is the set of strings of zero or any finite length of Σ. The special symbol ε denotes the zero-length string or the empty string. For a string w ∈ Σ*, wi is the ith symbol in the string.

B.1.1  Turing machines

Turing machines model the computation of functions that take input strings and produce output strings. A Turing machine M has a finite state controller, a read-only input tape, a write-only output tape, and k read/write internal or work tapes. Each tape has a tape head that can read and write one symbol on the tape at a time and move left (L), move right (R), or stay in the same position (S). Initially, the finite controller is in an initial state (q₀), and the input tape contains the input string α written in an input alphabet Σ. All the other tapes are blank, with the tape heads pointing to the first cell. The machine M reads the input α one symbol at a time, updates its internal state, writes other intermediate strings on internal or work tape(s), and writes an output string on the output tape. More specifically, in a single step, M does the following things: (1) changes the state of the finite controller, (2) writes new symbols on the cells scanned by the heads on the output and work tapes, and (3) moves the heads left or right.

Definition B.1.   A deterministic Turing machine (DTM) with k work tapes is a tuple M = ⟨Q, Σ, Γ, δ, q₀, qacc, qrej ⟩ where

(a) Q is a finite set of control states,

(b) Σ is a finite set of input symbols,

(c) Γ ⊇ Σ is a finite set of tape symbols, including a special blank symbol ⊔∈ Γ ∖ Σ,

(d) q₀ ∈ Q is the initial state,

(e) qacc ∈ Q is the accepting state,

(f) qrej ∈ Q is the rejecting state, with qacc ≠ qrej , and

(g) δ: (Q ∖{qacc, qrej }) × Γk → Q ×{L, S, R}× (Γ ×{L, S, R})k × (Γ ∪{ε}) is the transition function.

The last three components of the transition function δ give the following components: the head movements on the input tape (left L, stay S, or right R); the symbols written and the head movements on the work tapes; and finally, the symbols written on the output tape. If something is written on the output tape, then its head moves right.

Exercise B.1.   Write a 1-work tape Turing machine with Σ = {0, 1} that accepts 0k1k. First, copy the input string onto the work tape. Then, repeatedly erase the first 0 and the last 1. Stop and accept the input if there is no remaining symbol, and otherwise reject it.

Exercise B.2.   Write a 1-tape Turing machine that will take a binary number on the input tape, subtract 1 from it, and write the result in the output. Assume that the input number is greater than 0, and that the input head is on the far-right digit of the number.

Exercise B.3.   Give an English description of a 1-work tape Turing machine that accepts w#w for any w ∈ Σ*.

B.1.2  Configurations and computations

A configuration of a Turing machine M contains all the information needed to capture the state of the machine during a computation. Thus, a configuration includes the finite control state, the contents of all the work tapes, and the positions of all the heads. Given an input string of length n, a configuration c ∈ Q ×{0, …, n − 1}× (Γ*{▿}ΓΓ*)k, where ▿ denotes the position of a work tape head. That is, the symbol after ▿ is being read by the head. The initial configuration of M is (q₀, 0, ▿⊔, …, ▿⊔). A configuration in which M stops is called a halting configuration, which can only be an accepting configuration of the form (qacc, …) or a rejecting configuration of the form (qrej , …).

A move or a transition of a Turing machine from configuration c₁ to c₂ is written as c₁ c₂. For example, for a 1-work tape Turing machine, if δ(q, a, b) = (q′, R, (c, L)) and the input string is w with wi = a, then

where α, β ∈ Σ* and a, b, c, d ∈ Σ. A sequence of zero or more transitions is written as c₁ *c₂. That is called an execution of the machine M on the given input.

Notice that in Definition B.1 of transition function δ, given the current state, input symbol, and work tape symbols, there is only one possibility for the next state, for the symbols to be written, and for the direction in which the tape heads will move. Thus, on any input string w, the Turing machine M has only one execution, and that is the reason why M of Definition B.1 is called a deterministic Turing machine (DTM).

Nondeterministic Turing machines   A nondeterministic Turing machine (NTM) is defined in the same way as a DTM (Definition B.1), except that it has a set of initial states, and the transition function δ is a transition relation. On any input string w, an NTM can have many possible executions.

B.1.3  Language recognition and decidable languages

An input string w is accepted by a DTM M if M reaches an accepting configuration from the initial configuration with input w. Thus, M rejects (i.e., does not accept) w if either M reaches a rejecting configuration or M never halts. The language accepted by M, denoted by L(M), is the set of all input strings w accepted by M.

An NTM M accepts an input string w if some computation of M reaches an accepting configuration. The following theorems give well-known results about the expressive powers of DTMs and NTMs.

Theorem B.1.   DTMs and NTMs have the same expressive power. That is, for any NTM N, there exists a DTM D, such that L(N) = L(D).

Theorem B.2.   One work tape is good enough. For any Turing machine M with k work tapes, there exists a 1-work tape Turing machine M′, such that L(M′) = L(M).

Definition B.2.   A language L is recursively enumerable (RE) or semidecidable if there exists a Turing machine M such that L = L(M). L is recursive (REC) or decidable if it is recursively enumerable and the Turing machine M halts on all inputs. L is undecidable if it is not decidable.

For an RE language L, if w L, then the Turing machine accepting L may not terminate on w.

Exercise B.4.   Show that the following language is not RE: Ld = {⟨M⟩ | ⟨M⟩ L(M)}. Here, ⟨M⟩ denotes a string representing the Turing machine M.

Exercise B.5.   Show that the following language is in RE ∖ REC: Lhalt = {⟨M⟩ | M halts on ε}.

Church-Turing thesis   According to the Church-Turing thesis, anything solvable using a mechanical procedure can be solved using a Turing machine. That is not a theorem, as the statement presupposes the meaning of the term mechanical procedure; however, it holds true for almost all relevant models of computation. That fact has two implications. First, the decision-making power of a program written in a regular programming language is no different from that of a Turing machine. Second, instead of writing out a Turing machine by following Definition B.1, for most purposes, one can use a program or pseudocode representation that would be adequate for analysis.

B.2  Complexity

Several metrics are relevant for measuring computing resources used by verification algorithms, such as running time (CPU cycles), memory, communication bandwidth usage, lines of code, data usage, and so forth. In this book, we are focusing on running time and memory. The resource needs of an algorithm typically depend on the size of the inputs. Seen through the lens of complexity theory, these resource needs are measured as functions of the size of the inputs, and in a technology-independent fashion. Finally, resource needs could be measured for the average input or the worst-case input of a given length. We will focus on the latter here.

We will use functions of the form t, s: ℕ → ℕ to measure the time/space resource needs of algorithms as a function of the length of the input. A function f(n) = O(g(n)) if there are constants c, n0 such that for n > n0, f(n) ≤ cg(n). That is, g(n) is an asymptotic upper bound for f(n). Further, f(n) = Ω(g(n)) if there are constants c, n0 such that for n > n₀, f(n) ≥ cg(n). In that case, g(n) is said to be an asymptotic lower bound.

Definition B.3.   For any function t, s: ℕ → ℕ, a Turing machine M is said to run in time t(n) if on any input string w, all computations of M on w halt in no more than t(|u|) steps. M is said to use a maximum of s(n) space if on any input w, all computations of M on w use a maximum of s(|u|) cells of the work tapes.

B.2.1  Common complexity classes

In this section, we define some of the standard complexity classes and observe their robustness.

Definition B.4.   Given a language L, L ∈ DTIME(t(n)) iff there is a DTM M that runs in time t(n) and L = L(M). L ∈ NTIME(t(n)) iff there is an NTM M that runs in time t(n) and L = L(M).

L ∈ DSPACE(s(n)) iff there is a DTM M that runs in space s(n) and L = L(M). L ∈ NSPACE(s(n)) iff there is an NTM M that runs in space s(n) and L = L(M).

Theorem B.3 states that constant factor speed-ups in running times and constant factor compression in memory usage do not change the complexity class of any algorithm.

Theorem B.3.   If L ∈ DTIME(t(n)) (or L ∈ NTIME(t(n))) and c > 0 is any constant, then L ∈ DTIME(ct(n) + n) (L ∈ NTIME(ct(n) + n), respectively).

If L ∈ DSPACE(s(n)) (or L ∈ NSPACE(s(n))) and c > 0 is any constant, then L ∈ DSPACE(cs(n)) (L ∈ NSPACE(cs(n)), respectively).

The complexity-theoretic Church-Turing thesis states that any effective, mechanistic procedure can be simulated on a Turing machine by using the same space (if space ≥ log n) and only a polynomial slowdown (time ≥ n). That then justifies the use of analysis based on pseudocode or Turing machines as a reliable indicator of the running time in any platform up to a polynomial factor.

Complexity class

Sample problems

L = DSPACE(log n)

Reachability in explicit undirected graphs, multiplication of numbers

NL = NSPACE(log n)

Reachability in explicit directed graphs

P = ∪kDTIME(nk)

Linear programming, convex programming

NP = ∪kNTIME(nk)

Satisfiability

PSPACE = ∪kDSPACE(nk)

Solving n × n extensions of games like chess and Go

EXP = ∪kDTIME(2nk )

Deciding whether a DTM halts in no more than k steps

Proofs of the following relationships among the complexity classes are straightforward.

Proposition B.4.   DTIME(t(n)) ⊆ NTIME(t(n)) and DSPACE(s(n)) ⊆ NSPACE(s(n)).

Proposition B.5.   DTIME(t(n)) ⊆ DSPACE(t(n)) and NTIME(t(n)) ⊆ NSPACE(t(n)).

Proposition B.6.   DSPACE(s(n)) ⊆ DTIME(n2O(s(n))) and NSPACE(s(n)) ⊆ NTIME(n2O(s(n))).

It is also simple to show that a DTM can simulate all the computations of an NTM with an exponential blowup in time.

Proposition B.7.   NTIME(t(n)) ⊆ DTIME(2t(n)).

Savitch’s theorem shows that simulation of an NTM on a DTM incurs only a quadratic blowup in the space needed (Savitch, 1970). The reason is that space, unlike time, can be reused.

Theorem B.8.   NSPACE(s(n)) ⊆ DSPACE(2s(n)), provided s(n) ≥ log n.

This list of relationships could be summarized as follows:

where indicates the containment of language classes, but whether the containment is strict remains unknown. In addition, from the time hierarchy theorem (Hennie and Stearns, 1966; Cook, 1972), it is known that P ≠ EXP, and from the space hierarchy theorem, we know that L ≠ PSPACE and NL ≠ PSPACE.

B.3  Reasoning about the optimality of algorithms

For the verification problems, ideally we would like to establish optimality bounds for the minimal time and space necessary for solving them. However, the complexity analysis setup allows us to reason only up to polynomial slowdown and compression. Also, the many unresolved relationships among the various classes suggest that the establishment of such lower bounds is going to be mathematically challenging. Thus, instead of optimality results, we aim to compare the computational resources needed for solving problems.

B.3.1  Reductions

This line of reasoning about “hardness” or resource needs for problems goes as follows: If an instance of problem A can be “easily rephrased” as an instance of problem B, the solution of which gives a solution of A, then A is “no harder to solve” than B. The mechanism for showing that A can be easily rephrased as an instance of B is through a reduction from A to B.

For example, it is no harder to check an invariant property for a program (with Boolean variables) than it is to solve the reachability problem on directed graphs. We established that in Section 9.2.1 of Chapter 9.

Definition B.5.   A reduction (Figure B.1) from A to B is a (resource-bounded) function f such that for any input w, solving A on w is the same as solving B on f(w) (with similar resource bounds).

Figure B.1
A reduction from problem A to problem B.

Specifically, f is a polynomial-time reduction from A to B if f is a polynomial-time function. In that case, A is said to be poly-time reducible to B, and this is written as A ≤PB. Similarly, f is a logspace reduction from A to B if f is a logspace computable function, and in that case, A is said to be logspace reducible to B, which is written as A ≤LB. The following propositions capture some of the basic properties of logspace reductions; similar properties hold for other types of reductions.

Proposition B.9.   If A ≤ LB and B ∈ C, then A ∈ C, where C is a complexity class in {L, NL, P, PSPACE, EXP}.

Proposition B.10.   If A ≤LB and A L, then B L.

Proposition B.11.   If A ≤LB and B ≤LC, then A ≤LC.

B.3.2  Completeness

For any complexity class C, the most difficult problem in C is the problem that is at least as difficult as every other problem in C. Such problems are called C-complete. That is, every other problem in C can be reduced to C-complete problems.

Definition B.6.   Let C ∈{L, NL, P, PSPACE, EXP}. A language L is C-hard iff for every L′∈ C, L′≤LL. L is C-complete if L is C-hard and L ∈ C.

Exercises B.6 and B.7 point out that the representation of a system can have a significant bearing on the hardness of verification problems.

Exercise B.6.   Given a finite automaton 𝒜 = ⟨X, Θ, A, 𝒟⟩ with a single variable {x} = X and predicate I, show that the problem of checking whether invariant I holds for 𝒜 is NL-complete. Hint: Reduce invariance checking to the ST-connectivity problem (see Section 9.2.1 in Chapter 9).

Exercise B.7.   Given a finite automaton 𝒜 = ⟨X, Θ, A, 𝒟⟩ with a set of binary variables and predicate I, show that the problem of checking whether invariant I holds for 𝒜 is PSPACE-complete.

Appendix C: Specification Language Reference

Overview

This appendix serves as a reference for the language used throughout this book for specifying discrete and hybrid automata. The language is derived from the hybrid I/O automata (HIOA) language used by Mitra (2007) and Kaynar et al. (2005), which in turn is based on the input/output automaton (IOA) framework of Lynch and Tuttle (1989) and the IOA language (Garland, 2003).

A hybrid automaton specification has five components: (1) type definitions, (2) an automaton declaration, (3) variable declarations, (4) transition definitions, and (5) trajectory definitions. Trajectory definitions are not required for discrete automata and discrete IOA. The definitions of these components are constructed using type definitions, formal arguments, and predicates.

C.1  Conventions

The font conventions used (listed in Table C.1) are as follows:

Table C.1
Font conventions for the IOA language.

Font

Usage

Example

bold

keywords

automaton, pre, output

sans serif

automata, actions, mode names

automaton Thermostat

typewriter

types

Real, Bool

italic

variables, formal parameters, expressions

x:= x + 1; d(x) = −2x

In formal representations of the language, items within angular brackets ⟨⟩ are to be filled in with language constructs of the appropriate type. Optional constructs are written with “?” at the end.

Identifiers   An identifier is an ASCII string used to name language elements like types, variables, actions, and automata. Identifiers have to begin with an uppercase or lowercase letter of the alphabet, but can include numerals and other special characters {, -, ˜ }. For example, vel, v1, and v-off are valid identifiers, but 9vel is not. The identifiers cannot be any of the reserved words of the language.

C.2  Types

Built-in types   The built-in types include Real, Bool, Nat, and String, and they correspond to the sets of real numbers ℝ, Booleans 𝔹, natural numbers ℕ, and ASCII strings.

Type constructors   New types can be defined from existing types by using the type keyword, followed by a type construction statement. An enumeration type is defined as

This statement defines a new type that is the given list of items and assigns it the name typeID. Here, list has to be a comma-separated list of integers or strings. A tuple of k elements is defined as

An (unbounded) queue of elements of type M is defined as

The powerset of a set M is defined as

An array of elements of type M indexed by an interval of integers ID is defined as

The keyword type and the typeID for in-place type declarations can be dropped without giving the type a name. For example,

declares x to be an array of elements of type M indexed by ID. The ith element of the array, i ∈ ID, is accessed as x[i].

C.3  Formal arguments

Formal arguments (or formal parameters) are constants used to define actions, trajectories, and automata. A single formal argument or parameter declaration looks like a variable declaration:

However, formal parameters appear alongside the definition of an automaton, action, or trajectory. For example, the action Update(i: Nat) has the formal argument i of type ℕ. A list of formal arguments (formalArgList) is a list of formal argument declarations separated by commas. Formal arguments that have the same type can be combined into a list that has a single type at the end without repeating the type name. That is, the formal parameter list i: Real, j: Real can be written in short as i, j: Real. A special kind of formal argument is a type argument that is declared as M: type.

C.4  Automaton declaration

The automaton declaration statement declares the name of a single automaton or a family of automata:

Optionally, a where predicate may be added to restrict the range of valid formal argument values. The predicate is any valid predicate over the variables and formal arguments in the current scope. See Section 2.2.2 in Chapter 2 for more information on predicates.

For example,

declares a set of 20 Channel automata. The type parameter here allows the automata to be polymorphic. An automaton instance from this set is obtained by assigning a particular value to each formal argument, such that the assignment satisfies the where predicate. Thus, Channel(Nat, 1, 2) is an instance of this automaton family with Nat type, while Channel(Nat, 5, 5) is not.

C.5  Action declarations

The actions section of an automaton specification starts with the keyword actions and is followed by a sequence of action declarations. Each action declaration takes the form

where actionID is an identifier and the optional accessType is one of the following keywords: input, output, or internal. The action declaration can be followed by an optional where predicate over the formal arguments of the action and the automaton.

An action declaration declares the name of an action for the automaton. A parameterized action declares a family of actions. All the action declarations together define the set of actions A for the automaton. All action names must be unique within an automaton. Thus, there may be multiple action declarations with the same actionID, but with disjoint where predicates:

The accessType element specifies the type of action or action family for HIOAs and IOAs. Thus, accessTypes define the input I, the output O, and the internal sets of actions H. For hybrid automata and regular discrete automata, access types are not specified, and all actions are internal. For example, these statements declare an infinite set of update(i) actions. For odd i, update(i) is an input; otherwise, it is an output. For a sequence of action declarations of the same access type, accessType need not be repeated.

C.6  Variables

The variables section of an automaton specification starts with the keyword variables and is followed by a sequence of variable declarations. Each variable declaration takes the form

where varID is the variable name, varType is the type of the variable, and the optional accessType is one of the following keywords: input, output, or internal. A variable declaration can be followed by an optional initial value assignment, which must be of the same type as varType.

A variable declaration declares a variable for the automaton. All the variable declarations together define the set of all the variables V. All the variable names must be unique within an automaton.

The accessType element specifies the type of the variable for HIOAs and IOAs. Thus, accessTypes define the input U, output Y, and internal X variables. Input and output variables are not part of the state, and therefore they cannot have initial assignments and, furthermore, cannot be part of the initially predicate. If no initial assignment is given for a state variable, then its initial value can be any value within its type. For hybrid automata and regular discrete automata, access types are not specified, and all variables are internal or state variables. For a sequence of variable declarations of the same access type, accessType need not be repeated for each.

Initial values and initial set   The optional initially predicate can be used to define the initial set Θ of states of the automaton. In the presence of both initial value assignments for individual variables and an initially predicate over multiple variables, set Θ is defined as the intersection of all the constraints:

In this code fragment, c is a formal argument for the automaton that takes values in the interval [5, 10]. Mode is an enumeration type with two elements, {on, off }. The input variables ux and uy and the output variable z are not initialized. That is, U = {ux, uy}, Y = {z}, X = {x1, x2, m}, and V = U ∪Y ∪X. That defines the state space of the automaton as val(V).

The set of initial states Θ is specified by a combination of initial assignments and predicates over the state variables x1, x2, and m. For automaton instance A(c) for a specific c ∈ [5, 10], the initial set Θ is the set of valuations in val(X):

C.7  Predicates and expressions

A term is a constant, the name of a variable, or the name of a formal parameter. An expression is constructed by combining terms with standard operators such as +, −, /, %, *, ˆ, ., >, <, >=, <=, =, ≠, ∧, and ∨.

A predicate is an expression that evaluates to either true or false. An assignment is an expression of the form

The assignment operator := is interpreted as follows. First, the expression on the right side is evaluated, and the valuation of the variable on the left side is updated with the resulting value. For that to be a valid assignment, the type of the expression on the right should match the declared type of the variable.

Constants   Constants can be defined using the keyword const. Constants can be of any defined type.

C.8  Transitions

The transitions section of an automaton specification starts with the keyword transitions, which is followed by a sequence of transition definitions. Each transition definition begins with the name of an action, followed by optional formal arguments, a precondition, and an effect:

The name of the action may include access types, arguments, and where predicates. For a single action declaration, it is possible to give multiple transition definitions.

Preconditions or guards   The precondition for the transition is specified by a predicate over the state variables, the formal arguments of the automata, or the formal arguments of the action. The precondition is interpreted to define a set of states at which the transition is enabled. If a precondition is omitted, then it is assumed to be true. Thus, as input actions are always enabled for IOAs and HIOAs, they are forbidden to have any preconditions.

Effect   The effect for the transition is specified by a sequence of assignments for the state and output variables of the automaton. If a variable does not appear on the left side of any assignment in the effect part of a transition definition, then the variable’s valuation remains unchanged.

C.9  Trajectories

The trajectories section of a hybrid automaton specification starts with the keyword trajectories, which is followed by a sequence of trajectory definitions. Each trajectory definition begins with the name of a mode, followed by an optional formal argument list, an evolve statement, an optional invariant predicate, and an optional stop when predicate:

Evolve   The evolve statement is specified by a sequence of differential algebraic equations or inequalities for the state and output variables of the automaton. It can take the form:

For the differential equations to have solutions, the function defined on the right side has to be Lipschitz continuous (see Section 3.2.3 in Chapter 3). The expression on the right side is over all the input and state variables of the automaton and the formal arguments of the automaton.

Invariant and stop when predicates   The optional invariant and stop when predicates are predicates over the state variables and the formal arguments of the automaton.

Semantics of the trajectory definition   Consider a trajectory definition for a set of variables V, with input variables U = {u1, u2, …}, output variables Y = {y1, y2, …}, and internal or state variables X = {x1, x2, …}:

That defines a set of trajectories 𝒯modeID for this mode. Given an input trajectory η: [0, T] → val(U), a trajectory for the output and state variables τ: [0, T] → val(X ∪ Y) is a valid trajectory in 𝒯modeID if it satisfies the following conditions:

1. (τ ↓ X) is a solution of the differential equation for the given input signal η.

2. For each t ∈ τ.dom, τ(t).y1 = [ [expr3] ]τ(t), η(t)—that is, at each point in time, the value of y1 matches the evaluation of expr3 with the values of X and U in τ(t), η(t). The evolutions of y2 and other output variables in Y are defined similarly.

3. For each t ∈ τ.dom, τ(t) ∈ [ [pred1] ](τ↓X)(t)—that is, τ(t) satisfies the invariant predicate pred1 at every point in time.

4. Finally, for each t ∈ τ.dom, if τ(t) ∈ [ [pred2] ](τ↓X)(t), then t = T—that is, if τ(t) satisfies the stop when predicate pred2 at time t, then t is the last time in the domain of τ.

If a variable does not appear on the left side of any assignment, then the variable’s valuation remains unchanged along the trajectories of the system. For an automaton with a set of modes, the complete set of trajectories is given by the union of the trajectories defined by each mode. It can be verified that 𝒯modeID satisfies the required prefix, suffix, and concatenation closure properties.

C.10  Urgency

An urgent transition is one that must occur as soon as it is enabled. That is, time cannot advance while an enabled urgent transition is being ignored. Our language does not provide any direct construct for specifying urgent transitions; however, the invariant and stop when predicates can be used to specify urgent transitions.

For example, consider the following transition trajectory pair:

If the dynamics of a variable d(x) = f(x) in flow mode is such that x is monotonically increasing along all trajectories, then the jump action is enabled at time t₁ when τ(t₁).x = b. However, as x ≥ b is merely an enabling condition, the jump transition can be ignored. For example, a valid execution of this automaton is α = τ, in which τ.ltime > t₁ and time elapses beyond t₁.

Now, if we add the invariant x ≤ b to the flow mode, then jump indirectly becomes urgent. For any time t > t₁, τ(t) would violate the invariant, and therefore τ.ltime ≤ t₁. As an indirect result, in any execution of duration longer than t₁, jump is forced to occur. The same effect could be accomplished in a different way by adding the stop when predicate x ≥ b. Notice that a stop when predicate imposes no requirements at every intermediate time point in τ.dom (unlike an invariant); it only says what conditions define the last state of a trajectory. Thus, the stop when conditions have to be identical to the pre of the action in order to make the action urgent.

C.11  Modeling with nondeterminism

There are many possible sources of nondeterminism in an HIOA model written using this language. For example, the initially predicate may specify a set of initial states instead of a single initial state; multiple actions may be enabled at the same state; and multiple trajectory definitions may be specifying the continuous evolution of the state.

Nondeterministic assignment   A common idiom for making nondeterministic assignments using transitions is as follows:

Here, at a given state, because jump(i) is enabled for all i ∈ ℕ, the occurrence of a particular jump(i) in an execution resolves the nondeterministic choice and assigns that particular value of i to x.

References

Abbas, Houssam, and Georgios Fainekos. 2011. Linear hybrid system falsification through local search. In Automated technology for verification and analysis, eds. T. Bultan and P. A. Hsiung. Vol. 6996 of Lecture notes in computer science, 503–510. Springer.

Abbeel, Pieter, Adam Coates, Morgan Quigley, and Andrew Y. Ng. 2006. An application of reinforcement learning to aerobatic helicopter flight. In NIPS’06: Proceedings of the 19th International Conference on Neural Information Processing Systems, 1–8. MIT Press.

Agha, Gul, and Karl Palmskog. 2018. A survey of statistical model checking. ACM Transactions on Modeling and Computer Simulation 28 (1): 1–39. doi:10.1145/3158668.

Alpern, Bowen, and Fred B. Schneider. 1987. Recognizing safety and liveness. Distributed Computing 2 (3): 117–126. doi:10.1007/BF01782772.

Alspaugh, Thomas A., Stuart R. Faulk, Kathryn H. Britton, R. Alan Parker, and David L. Parnas. 1992. Software requirements for the A-7E aircraft, Technical report, U.S. Naval Research Laboratory.

Althoff, M., and D. Grebenyuk. 2016. Implementation of interval arithmetic in CORA 2016. In ARCH’16: Proceedings of the 3rd International Workshop on Applied Verification for Continuous and Hybrid Systems, 91–105. EasyChair. doi:10.29007/W19B.

Althoff, Matthias, and John M. Dolan. 2014. Online verification of automated road vehicles using reachability analysis. IEEE Transactions on Robotics 30 (4): 903–918.

Althoff, Matthias, Stanley Bak, Xin Chen, Chuchu Fan, Marcelo Forets, Goran Frehse, Niklas Kochdumper, Yangge Li, Sayan Mitra, Rajarshi Ray, Christian Schilling, and Stefan Schupp. 2018. Arch-comp18 category report: Continuous and hybrid systems with linear continuous dynamics. In ARCH’18: Proceedings of the 5th International Workshop on Applied Verification of Continuous and Hybrid Systems, ed. Goran Frehse. Vol. 54 of Epic series in computing, 23–52. EasyChair. doi:10.29007/73mb.

Altinger, Harald, Franz Wotawa, and Markus Schurius. 2014. Testing methods used in the automotive industry: Results from a survey. In JAMAICA’14: Proceedings of the 2014 Workshop on Joining AcadeMiA and Industry Contributions to Test Automation and Model-Based Testing, 1–6. ACM Digital Library. doi:10.1145/2631890.2631891.

Alur, Rajeev, and David L. Dill. 1994. A theory of timed automata. Theoretical Computer Science 126 (2): 183–235.

Alur, Rajeev, Thao Dang, and Franjo Ivančić. 2006. Counterexample-guided predicate abstraction of hybrid systems. Theoretical Computer Science 354 (2): 250–271. doi:10.1016/j.tcs.2005.11.026.

Alur, Rajeev, Tomás Feder, and Thomas A. Henzinger. 1996. The benefits of relaxing punctuality. Journal of the ACM 43 (1): 116–146. doi:10.1145/227595.227602.

Alur, Rajeev, Costas Courcoubetis, Nicolas Halbwachs, Thomas A. Henzinger, P. H. Ho, Xavier Nicollin, Alfredo Olivero, Joseph Sifakis, and Sergio Yovine. 1995. The algorithmic analysis of hybrid systems. Theoretical Computer Science 138 (1): 3–34.

Ames, Aaron D., Alessandro Abate, and Shankar Sastry. 2005. Sufficient conditions for the existence of Zeno behavior. In CDC’14: Proceedings of the 44th IEEE Conference on Decision and Control, 696–701. IEEE.

Angeli, David. 2002. A Lyapunov approach to incremental stability properties. IEEE Transactions on Automatic Control 47 (3): 410–421.

Annapureddy, Yashwanth, Che Liu, Georgios Fainekos, and Sriram Sankaranarayanan. 2011. S-TaLiRo: A tool for temporal logic falsification for hybrid systems. In TACAS’11: Proceedings of the International Conference on Tools and Algorithms for the Construction and Analysis of Systems. Vol. 6605 of Lecture notes in computer science, 254–257. Springer.

Anta, Adolfo, Rupak Majumdar, Indranil Saha, and Paulo Tabuada. 2010. Automatic verification of control system implementations. In EMSOFT’10: Proceedings of the 10th ACM International Conference on Embedded Software, 9–18. ACM Digital Library. doi:10.1145/1879021.1879024.

Arechiga, Nikos, James Kapinski, Jyotirmoy V. Deshmukh, André Platzer, and Bruce H. Krogh. 2015. Numerically-aided deductive safety proof for a powertrain control system. Electronic Notes in Theoretical Computer Science 317: 19–25. doi:10.1016/j.entcs.2015.10.003.

Arora, Sanjeev, and Boaz Barak. 2009. Computational complexity: A modern approach. Cambridge University Press.

Asarin, E., O. Bournez, T. Dang, and O. Maler. 2000. Approximate reachability analysis of piecewise-linear dynamical systems. In HSCC’00: Proceedings of the International Workshop on Hybrid Systems: Computation and Control, eds. B. Krogh and N. Lynch. Vol. 1790 of Lecture notes in computer science, 20–31. Springer.

Asarin, Eugene, Thao Dang, and Antoine Girard. 2007. Hybridization methods for the analysis of nonlinear systems. Acta Informatica 43 (7): 451–476.

Astrom, Karl Johan, and Richard M. Murray. 2008. Feedback systems: An introduction for scientists and engineers. Princeton University Press.

Avis, David, and Komei Fukuda. 1992. A pivoting algorithm for convex hulls and vertex enumeration of arrangements and polyhedra. Discrete & Computational Geometry 8 (1): 295–313.

Aziz, Adnan, Kumud Sanwal, Vigyan Singhal, and Robert Brayton. 2000. Model-checking continuous-time Markov chains. ACM Transactions on Computational Logic 1 (1): 162–170. doi:10.1145/343369.343402.

Bagnara, Roberto, Patricia M. Hill, and Enea Zaffanella. 2008. The Parma Polyhedra Library: Toward a complete set of numerical abstractions for the analysis and verification of hardware and software systems. Science of Computer Programming 72 (1–2): 3–21. doi:10.1016/j.scico.2007.08.001.

Baier, Christel, and Joost-Pieter Katoen. 2008. Principles of model checking. MIT Press.

Bak, Stanley, and Parasara Sridhar Duggirala. 2017. HyLAA: A tool for computing simulation-equivalent reachability for linear systems. In HSCC’17: Proceedings of the 20th International Conference on Hybrid Systems: Computation and Control, 173–178. ACM.

Bak, Stanley, Sergiy Bogomolov, and Taylor T. Johnson. 2015. HyST: A source transformation and translation tool for hybrid automaton models. In HSCC’15: Proceedings of the 18th International Conference on Hybrid Systems: Computation and Control, 128–133. ACM.

Bak, Stanley, Hoang-Dung Tran, and Taylor T. Johnson. 2019. Numerical verification of affine systems with up to a billion dimensions. In HSCC’19: Proceedings of the 22nd ACM International Conference on Hybrid Systems: Computation and Control, 23–32. ACM. doi:10.1145/3302504.3311792.

Ball, Thomas, and Sriram K. Rajamani. 2001. Bebop: A path-sensitive interprocedural dataflow engine. In PASTE’01: Proceedings of the 2001 ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering, 97–103. ACM. doi:10.1145/379605.379690.

Barrett, Clark, Christopher L. Conway, Morgan Deters, Liana Hadarean, Dejan Jovanović, Tim King, Andrew Reynolds, and Cesare Tinelli. 2011. CVC4. In CAV’11: Proceedings of the 23rd International Conference on Computer Aided Verification. Vol. 6806 of Lecture notes in computer science, 171–177. Springer.

Bartocci, Ezio, and Yliès Falcone, eds. 2018. Lectures on runtime verification: Introductory and advanced topics. Vol. 10457 of Programming and software engineering. Springer.

Bartocci, Ezio, Jyotirmoy Deshmukh, Alexandre Donzé, Georgios Fainekos, Oded Maler, Dejan Ničković, and Sriram Sankaranarayanan. 2018. Specification-based monitoring of cyber-physical systems: A survey on theory, tools and applications. In Lectures on runtime verification: Introductory and advanced topics. Vol. 10457 of Lecture notes in computer science, 135–175. Springer.

Beg, Omar Ali, Houssam Abbas, Taylor T. Johnson, and Ali Davoudi. 2017. Model validation of PWM DC–DC converters. IEEE Transactions on Industrial Electronics 64 (9): 7049–7059.

Behrmann, Gerd, Alexandre David, and Kim G. Larsen. 2004. A tutorial on Uppaal. In SFM-RT: Formal Methods for the Design of Real-time Systems: International School on Formal Methods for the Design of Computer, Communication, and Software Systems. Vol. 3185 of Lecture notes in computer science, 200–236. Springer.

Behrmann, Gerd, Alexandre David, Kim Guldstrand Larsen, Paul Pettersson, and Wang Yi. 2011. Developing Uppaal over 15 years. Software—Practice and Experience 41 (2): 133–142.

Belta, Calin, Boyan Yordanov, and Aydin Gol Ebru. 2017. Formal methods for discrete-time dynamical systems. Studies in systems, decision and control. Springer.

Bengtsson, Johan, Kim Guldstrand Larsen, Fredrik Larsson, Paul Pettersson, and Wang Yi. 1996. Uppaal in 1995. In TACAS’96: Proceedings of the International Workshop on Tools and Algorithms for Construction and Analysis of Systems. Vol. 1055 of Lecture notes in computer science, 431–434. Springer.

Bérard, Béatrice, Patricia Bouyer, and Antoine Petit. 2004. Analysing the PGM protocol with Uppaal. International Journal of Production Research 42 (14): 2773–2791.

Bertsimas, Dimitris, and John Tsitsiklis. 1997. Introduction to linear optimization. Athena Scientific.

Bicchi, Antonio, Alessia Marigo, and Benedetto Piccoli. 2002. On the reachability of quantized control systems. IEEE Transactions on Automatic Control 47 (4): 546–563.

Biere, A., M. Heule, H. van Maaren, and T. Walsh. 2009. Handbook of satisfiability. Vol. 185 of Frontiers in artificial intelligence and applications. IOS Press.

Blum, L., M. Shub, F. Cucker, and S. Smale. 1997. Complexity and real computation. Springer.

Blum, Lenore, Mike Shub, and Steve Smale. 1988. On a theory of computation over the real numbers; NP completeness, recursive functions and universal machines (extended abstract). In SFCS’88: Proceedings of the 29th Annual Symposium on Foundations of Computer Science, 387–397. IEEE. doi:10.1109/SFCS.1988.21955.

Boichenko, V. A., and G. A. Leonov. 1998. Lyapunov’s direct method in estimates of topological entropy. Journal of Mathematical Sciences 91 (6): 3370–3379.

Boyd, Stephen, and Lieven Vandenberghe. 2004. Convex optimization. Cambridge University Press.

Boyer, Benoît, Kevin Corre, Axel Legay, and Sean Sedwards. 2013. PLASMA-lab: A flexible, distributable statistical model checking library. In QEST’13: Proceedings of the 10th International Conference on Quantitative Evaluation of Systems, 160–164. Springer.

Branicky, M. 1998. Multiple Lyapunov functions and other analysis tools for switched and hybrid systems. IEEE Transactions on Automatic Control 43 (4): 475–482.

Byl, Katie, and Russ Tedrake. 2009. Metastable walking machines. International Journal of Robotics Research 28 (8): 1040–1064.

CAPD Group. 2016. Computer assisted proofs in dynamics (CAPD), Technical Report http://capd.ii.uj.edu.pl/index.php, Division of Computational Mathematics. Jagiellonian University. http://capd.ii.uj.edu.pl/index.php.

Cattani, Stefano. 2005. Trace-based process algebras for real-time probabilistic systems. PhD dissertation, University of Birmingham.

Cattani, Stefano, Roberto Segala, Marta Z. Kwiatkowska, and Gethin Norman. 2005. Stochastic transition systems for continuous state spaces and non-determinism. In FoSSaCS’05: Proceedings of the International Conference on Foundations of Software Science and Computation Structures. Vol. 3441 of Lecture notes in computer science, 125–139. Springer.

Chan, Nicole, and Sayan Mitra. 2017a. Verified hybrid LQ control for autonomous spacecraft rendezvous. In CDC’17: Proceedings of the 2017 IEEE 56th Annual Conference on Decision and Control, 1427–1432. IEEE. doi:10.1109/CDC.2017.8263854.

Chan, Nicole, and Sayan Mitra. 2017b. Verifying safety of an autonomous spacecraft rendezvous mission. In ARCH’17: Proceedings of the 4th International Workshop on Applied Verification of Continuous and Hybrid Systems. Vol. 48 of EPiC series in computing, 20–32. EasyChair. doi:10.29007/thb4.

Chen, Xin, Erika Ábrahám, and Sriram Sankaranarayanan. 2013. Flow*: An analyzer for non-linear hybrid systems. In CAV’13: Proceedings of the International Conference on Computer Aided Verification. Vol. 8044 of Lecture notes in computer science, 258–263. Springer.

Chen, Xin, Souradeep Dutta, and Sriram Sankaranarayanan. 2017. Formal verification of a multi-basal insulin infusion control model. In ARCH’17: Proceedings of the 4th International Workshop on Applied Verification of Continuous and Hybrid Systems. Vol. 48 of EPiC series in computing, 75–91. EasyChair. doi:10.29007/kcrp.

Cimatti, A., Edmund M. Clarke, F. Giunchiglia, and M. Roveri. 1999. NuSMV: A new symbolic model verifier. In CAV’99: Proceedings of the 11th International Conference on Computer Aided Verification. Vol. 1633 of Lecture notes in computer science, 495–499. Springer.

Cimatti, Alessandro, Alberto Griggio, Sergio Mover, and Stefano Tonetta. 2014. Verifying LTL properties of hybrid systems with k-liveness. In CAV’14: Proceedings of the 26th International Conference on Computer Aided Verification. Vol. 8559 of Lecture notes in computer science, 424–440. Springer.

Clarke, Edmund M., Orna Grumberg, and Doron A. Peled. 1999. Model checking. MIT Press.

Clarke, Edmund M., Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith. 2000. Counterexample-guided abstraction refinement. In CAV’00: Proceedings of the 12th International Conference on Computer Aided Verification. Vol. 1855 of Lecture notes in computer science, 154–169. Springer.

Clarke, Edmund M., Ansgar Fehnker, Zhi Han, Bruce Krogh, Olaf Stursberg, and Michael Theobald. 2003. Verification of hybrid systems based on counterexample-guided abstraction refinement. In TACAS’03: Proceedings of the 9th International Conference on Tools and Algorithms for the Construction and Analysis of Systems. Vol. 2619 of Lecture notes in computer science, 192–207. Springer.

Cofer, Darren, and Steven Miller. 2014. DO-333 certification case studies. In NFM’14: Proceedings of the NASA Formal Methods Symposium. Vol. 8430 of Lecture notes in computer science, 1–15. Springer.

Colón, Michael A., Sriram Sankaranarayanan, and Henny B. Sipma. 2003. Linear invariant generation using non-linear constraint solving. In CAV’03: Proceedings of the International Conference on Computer Aided Verification. Vol. 2725 of Lecture notes in computer science, 420–432. Springer.

Cook, Stephen A. 1971. The complexity of theorem-proving procedures. In STOC’71: Proceedings of the 3rd Annual ACM Symposium on Theory of Computing, 151–158. ACM. doi:10.1145/800157.805047.

Cook, Stephen A. 1972. A hierarchy for nondeterministic time complexity. In STOC’72: Proceedings of the 4th Annual ACM Symposium on Theory of Computing, 187–192. ACM. doi:10.1145/800152.804913.

Corbett, James C., Matthew B. Dwyer, John Hatcliff, Shawn Laubach, Corina S. Pasareanu, Robby, and Hongjun Zheng. 2000. Bandera: Extracting finite-state models from Java source code. In ICSE’00: Proceedings of the 22nd International Conference on Software Engineering, 439–448. ACM. doi:10.1145/337180.337234.

Cyber-Physical Systems Virtual Organization (CPS-VO). 2019. List of verification tools. https://cps-vo.org/group/verification_tools/wiki.

Dang, Thao, Oded Maler, and Romain Testylier. 2010. Accurate hybridization of nonlinear systems. In HSCC’10: Proceedings of the 13th ACM International Conference on Hybrid Systems: Computation and Control, 11–20. ACM. doi:10.1145/1755952.1755956.

Dantzig, George B. 1998. Linear programming and extensions. Princeton University Press.

Dantzig, George B., and Mukund N. Thapa. 1997. Linear programming 1: Introduction. Springer.

David, Alexandre, and Wang Yi. 2000. Modelling and analysis of a commercial field bus protocol. In Euromicro RTS’00: Proceedings of the 12th Euromicro Conference on Real-Time Systems, 165—172. IEEE.

Davis, Martin, George Logemann, and Donald Loveland. 1962. A machine program for theorem-proving. Communications of the ACM 5 (7): 394–397. doi:10.1145/368273.368557.

de Moura, Leonardo, and Nikolaj Bjørner. 2008. Z3: An efficient SMT solver. In TACAS’08: Proceedings of the International Conference on Tools and Algorithms for the Construction and Analysis of Systems, Held as Part of the Joint European Conferences on Theory and Practice of Software. Vol. 4963 of Lecture notes in computer science, 337–340. Springer.

Deng, Yi, Akshay Rajhans, and A. Agung Julius. 2013. STRONG: A trajectory-based verification toolbox for hybrid systems. In QEST’13: Proceedings of the International Conference on Quantitative Evaluation of Systems. Vol. 8054 of Lecture notes in computer science, 165–168. Springer.

Dijkstra, Edsger W. 1974. Self-stabilizing systems in spite of distributed control. Communications of the ACM 17 (11): 643–644. doi:10.1145/361179.361202.

Dolev, Shlomi. 2000. Self-stabilization. MIT Press.

Donzé, Alexandre. 2010. Breach, a toolbox for verification and parameter synthesis of hybrid systems. In CAV’10: Proceedings of the International Conference on Computer Aided Verification. Vol. 6174 of Lecture notes in computer science, 167–170. Springer.

Donzé, Alexandre, and Oded Maler. 2007. Systematic simulation using sensitivity analysis. In HSCC’07: Proceedings of the International Workshop on Hybrid Systems: Computation and Control, 174–189. Springer.

Donzé, Alexandre, and Oded Maler. 2010. Robust satisfaction of temporal logic over real-valued signals. In FORMATS’10: Proceedings of the International Conference on Formal Modeling and Analysis of Timed Systems. Vol. 6246 of Lecture notes in computer science, 92–106. Springer.

Dreossi, Tommaso, Daniel J. Fremont, Shromona Ghosh, Edward Kim, Hadi Ravanbakhsh, Marcell Vazquez-Chanlatte, and Sanjit A. Seshia. 2019. VERIFAI: A toolkit for the design and analysis of artificial intelligence-based systems. CoRR abs/1902.04245. http://arxiv.org/abs/1902.04245.

Duggirala, Parasara Sridhar, and Sayan Mitra. 2011. Abstraction refinement for stability. In Proceedings of the IEEE/ACM 2nd International Conference on Cyber-Physical Systems (ICCPS’11), 22–31. IEEE.

Duggirala, Parasara Sridhar, and Mahesh Viswanathan. 2016. Parsimonious, simulation based verification of linear systems. In CAV’16: Proceedings of the 28th International Conference on Computer Aided Verification, Part I. Vol. 9779 of Lecture notes in computer science, 477–494. Springer. doi:10.1007/978-3-319-41528-4_26.

Duggirala, Parasara Sridhar, Sayan Mitra, and Mahesh Viswanathan. 2013. Verification of annotated models from executions. In EMSOFT’13: Proceedings of the 11th ACM International Conference on Embedded Software. ACM. doi:10.5555/2555754.2555780.

Duggirala, Parasara Sridhar, Le Wang, Sayan Mitra, Mahesh Viswanathan, and César A. Muñoz. 2014. Temporal precedence checking for switched models and its application to a parallel landing protocol. In FM’14: Proceedings of the 19th International Symposium on Formal Methods, 215–229. Springer. doi:10.1007/978-3-319-06410-9_16.

Duggirala, Parasara Sridhar, Chuchu Fan, Sayan Mitra, and Mahesh Viswanathan. 2015. Meeting a powertrain verification challenge. In CAV’15: Proceedings of the 27th International Conference on Computer Aided Verification, Part I, 536–543. Springer. doi:10.1007/978-3-319-21690-4_37.

Dutertre, Bruno. 2014. Yices 2.2. In CAV’14: Proceedings of the International Conference on Computer-Aided Verification, eds. Armin Biere and Roderick Bloem. Vol. 8559 of Lecture notes in computer science, 737–744. Springer.

Dutta, Souradeep, Taisa Kushner, and Sriram Sankaranarayanan. 2018. Robust data-driven control of artificial pancreas systems using neural networks. In CMSB’18: Proceedings of the 16th International Conference on Computational Methods in Systems Biology, 183–202. Springer. doi:10.1007/978-3-319-99429-1_11.

Dutta, Souradeep, Xin Chen, Susmit Jha, Sriram Sankaranarayanan, and Ashish Tiwari. 2019. Sherlock—A tool for verification of neural network feedback systems: Demo abstract. In HSCC’19: Proceedings of the 22nd ACM International Conference on Hybrid Systems: Computation and Control, 262–263. ACM. doi:10.1145/3302504.3313351.

El-Guindy, Ahmed, Dongkun Han, and Matthias Althoff. 2016. Formal analysis of drum-boiler units to maximize the load-following capabilities of power plants. IEEE Transactions on Power Systems 31 (6): 4691–4702.

Eén, Niklas, and Niklas Sörensson. 2003. An extensible SAT-solver. In SAT’03: Proceedings of the International Conference on Theory and Applications of Satisfiability Testing, eds. Enrico Giunchiglia and Armando Tacchella. Vol. 2919 of Lecture notes in computer science, 502–518. Springer.

Fabris, Simone. 2012. Method for hazard severity assessment for the case of undemanded deceleration, Technical report, TRW Automotive.

Fainekos, Georgios E. 2015. Automotive control design bug-finding with the S-TaLiRo tool. In ACC’15: Proceedings of the American Control Conference, 4096. IEEE. doi:10.1109/ACC.2015.7171969.

Fainekos, Georgios E., and George J. Pappas. 2009. Robustness of temporal logic specifications for continuous-time signals. Theoretical Computer Science 410 (42): 4262–4291. doi:10.1016/j.tcs.2009.06.021.

Fainekos, Georgios E., Sriram Sankaranarayanan, Koichi Ueda, and Hakan Yazarel. 2012. Verification of automotive control applications using S-TaLiRo. In ACC’12: Proceedings of the 2012 American Control Conference, 3567–3572. IEEE.

Fan, Chuchu, and Sayan Mitra. 2015. Bounded verification with on-the-fly discrepancy computation. In ATVA’15: Proceedings of the International Symposium on Automated Technology for Verification and Analysis. Vol. 9364 of Lecture notes in computer science, 446–463. Springer.

Fan, Chuchu, Bolun Qi, and Sayan Mitra. 2018. Data-driven formal reasoning and their applications in safety analysis of vehicle autonomy features. IEEE Design & Test 35 (3): 31–38. doi:10.1109/MDAT.2018.2799804.

Fan, Chuchu, Bolun Qi, Sayan Mitra, Mahesh Viswanathan, and Parasara Sridhar Duggirala. 2016a. Automatic reachability analysis for nonlinear hybrid models with C2E2. In CAV’16: Proceedings of the 28th International Conference on Computer Aided Verification, Part I, 531–538. Springer. doi:10.1007/978-3-319-41528-4_29.

Fan, Chuchu, James Kapinski, Xiaoqing Jin, and Sayan Mitra. 2016b. Locally optimal reach set over-approximation for nonlinear systems. In EMSOFT’16: Proceedings of the 2016 International Conference on Embedded Software, 1–10. IEEE.

Fan, Chuchu, Bolun Qi, Sayan Mitra, and Mahesh Viswanathan. 2017. DryVR: Data-driven verification and compositional reasoning for automotive systems. In CAV’17: Proceedings of the International Conference on Computer Aided Verification. Vol. 10426 of Lecture notes in computer science, 441–461. Springer.

Fan, Chuchu, James Kapinski, Xiaoqing Jin, and Sayan Mitra. 2018a. Simulation-driven reachability using matrix measures. ACM Transactions on Embedded Computing Systems 17 (1): 1–28. doi:10.1145/3126685.

Fan, Chuchu, Yu Meng, Jürgen Maier, Ezio Bartocci, Sayan Mitra, and Ulrich Schmid. 2018b. Verifying nonlinear analog and mixed-signal circuits with inputs. In ADHS’18: Proceedings of the 6th IFAC Conference on Analysis and Design of Hybrid Systems, 241–246. Elsevier. doi:10.1016/j.ifacol.2018.08.041.

Fehnker, Ansgar, Lodewijk van Hoesel, and Angelika Mader. 2007. Modelling and verification of the LMAC protocol for wireless sensor networks. In IFM’07: Proceedings of the International Conference on Integrated Formal Methods. Vol. 4591 of Lecture notes in computer science, 253–272. Springer.

Fehnker, Ansgar, Edmund M. Clarke, Sumit Kumar Jha, and Bruce Krogh. 2005. Refining abstractions of hybrid systems using counterexample fragments. In HSCC’05: Proceedings of the International Workshop on Hybrid Systems: Computation and Control. Vol. 3414 of Lecture notes in computer science, 242–257. Springer.

Feron, Eric. 2010. From control systems to control software. IEEE Control Systems Magazine 30 (6): 50–71. doi:10.1109/MCS.2010.938196.

FitzHugh, Richard. 1961. Impulses and physiological states in theoretical models of nerve membrane. Biophysical Journal 1 (6): 445–466.

Floyd, Robert. 1967. Assigning meanings to programs. In Mathematical Aspects of Computer Science. Vol. 19 of Proceedings of symposia in applied mathematics, 19–32. American Mathematical Society.

Forsman, Krister. 1991. Construction of Lyapunov functions using Grobner bases. In CDC’91: Proceedings of the 30th IEEE Conference on Decision and Control, 798–799. IEEE.

Frehse, G., A. Hamann, S. Quinton, and M. Woehrle. 2014. Formal analysis of timing effects on closed-loop properties of control software. In RTSS’14: Proceedings of the 2014 IEEE Real-Time Systems Symposium, 53–62. IEEE. doi:10.1109/RTSS.2014.28.

Frehse, Goran. 2005. PHAVer: Algorithmic verification of hybrid systems past HyTech. In HSCC’05: Proceedings of the International Workshop on Hybrid Systems: Computation and Control, eds. Manfred Morari and Lothar Thiele. Vol. 3414 of Lecture notes in computer science, 258–273. Springer.

Frehse, Goran, and Matthias Althoff. 2019. Applied Verification for Continuous and Hybrid Systems. [Website for the Workshop on Applied Verification for Continuous and Hybrid Systems (ARCH)]. https://cps-vo.org/group/ARCH?utm_source=researchbib.

Frehse, Goran, Colas Le Guernic, Alexandre Donzé, Scott Cotton, Rajarshi Ray, Olivier Lebeltel, Rodolfo Ripado, Antoine Girard, Thao Dang, and Oded Maler. 2011. SpaceEx: Scalable verification of hybrid systems. In CAV’11: Proceedings of the 23rd International Conference on Computer Aided Verification. Vol. 6806 of Lecture notes in computer science, 379–395. Springer.

Gardner, Martin. 1970. Mathematical games: The fantastic combinations of John Conway’s new solitaire game “life”. Scientific American 223 (4): 120––123.

Garland, Stephen J. 2003. The IOA language and toolkit, Technical report, Massachusetts Institute of Technology, https://groups.csail.mit.edu/tds/ioa/.

Ghosh, Sukumar. 2014. Distributed systems: An algorithmic approach. Chapman & Hall/CRC.

Girard, Antoine. 2005. Reachability of uncertain linear systems using zonotopes. In HSCC’05: Proceedings of the International Workshop on Hybrid Systems: Computation and Control, 291–305. Springer.

Girard, Antoine, and Colas Le Guernic. 2008. Zonotope/hyperplane intersection for hybrid systems reachability analysis. In HSCC’08: Proceedings of the International Workshop on Hybrid Systems: Computation and Control. Vol. 4981 of Lecture notes in computer science, 215–228. Springer.

Goebel, Rafal, Ricardo G. Sanfelice, and Andrew R. Teel. 2012. Hybrid dynamical systems: Modeling, stability, and robustness. Princeton University Press. http://www.jstor.org/stable/j.ctt7s02z.

Goldberg, Eugene, and Yakov Novikov. 2007. BerkMin: A fast and robust sat-solver. Discrete Applied Mathematics 155 (12): 1549–1561. doi:10.1016/j.dam.2006.10.007.

Gronwall, T. H. 1919. Note on the derivatives with respect to a parameter of the solutions of a system of differential equations. Annals of Mathematics 20 (4): 292–296.

Grosu, Radu, Sayan Mitra, Pei Ye, Emilia Entcheva, I. V. Ramakrishnan, and Scott A. Smolka. 2007. Learning cycle-linear hybrid automata for excitable cells. In HSCC’07: Proceedings of the International Workshop on Hybrid Systems: Computation and Control, eds. Alberto Bemporad, Antonio Bicchi, and Giorgio C. Buttazzo. Vol. 4416 of Lectures notes in computer science, 245–258. Springer.

Grosu, Radu, Gregory Batt, Flavio H. Fenton, James Glimm, Colas Le Guernic, Scott A. Smolka, and Ezio Bartocci. 2011. From cardiac cells to genetic regulatory networks. In CAV’11: Proceedings of the International Conference on Computer Aided Verification, 396–411. Springer.

Halbwachs, Nicolas, Yann-Eric Proy, and Pascal Raymond. 1994. Verification of linear hybrid systems by means of convex approximations. In SAS’94: Proceedings of the International Static Analysis Symposium, 223–237. Springer.

Hansson, Hans, and Bengt Jonsson. 1994. A logic for reasoning about time and reliability. Formal Aspects of Computing 6 (5): 512–535.

Havelund, Klaus, Arne Skou, Kim Guldstrand Larsen, and Kristian Lund. 1997. Formal modeling and analysis of an audio/video protocol: An industrial case study using Uppaal. In RTSS’97: Proceedings of the 18th IEEE Real-Time Systems Symposium, 2–13. IEEE.

Hawblitzel, Chris, Jon Howell, Manos Kapritsos, Jacob R. Lorch, Bryan Parno, Michael L. Roberts, Srinath Setty, and Brian Zill. 2015. IronFleet: Proving practical distributed systems correct. In SOSP’15: Proceedings of the 25th Symposium on Operating Systems Principles, 1–17. ACM.

Hennie, F. C., and R. E. Stearns. 1966. Two-tape simulation of multitape Turing machines. Journal of the ACM 13 (4): 533–546. doi:10.1145/321356.321362.

Henzinger, Thomas A., Pei-Hsin Ho, and Howard Wong-Toi. 1997. HyTech: A model checker for hybrid systems. In CAV’97: Proceedings of the International Conference on Computer Aided Verification. Vol. 1254 of Lecture notes in computer science, 460–463. Springer.

Henzinger, Thomas A., Peter W. Kopke, Anuj Puri, and Pravin Varaiya. 1998. What’s decidable about hybrid automata? Journal of Computer and System Sciences 57: 94–124.

Hermanns, Holger, Joost-Pieter Katoen, Joachim Meyer-Kayser, and Markus Siegle. 2000. A Markov chain model checker. In TACAS’00: Proceedings of the International Conference on Tools and Algorithms for the Construction and Analysis of Systems. Vol. 1785 of Lecture notes in computer science, 347–362. Springer.

Hespanha, João P. 2004. Stochastic hybrid systems: Application to communication networks. In HSCC’04: Proceedings of the 7th International Workshop on Hybrid Systems: Computation and Control, 387–401. Springer. doi:10.1007/978-3-540-24743-2_26.

Hespanha, João P. 2009. Linear systems theory. Princeton University Press.

Hespanha, J. P., and A. S. Morse. 1999. Stability of switched systems with average dwell-time. In CDC’99: Proceedings of the 38th IEEE Conference on Decision and Control, 2655–2660. IEEE.

Hessel, Anders, and Paul Pettersson. 2006. Model-based testing of a WAP gateway: An industrial case-study. In FMICS’06: Proceedings of the International Workshop on Formal Methods for Industrial Critical Systems, 116–131. Springer.

Hinton, Andrew, Marta Kwiatkowska, Gethin Norman, and David Parker. 2006. PRISM: A tool for automatic verification of probabilistic systems. In TACAS’06: Proceedings of the 12th International Conference on Tools and Algorithms for the Construction and Analysis of Systems, eds. H. Hermanns and J. Palsberg. Vol. 3920 of Lecture notes in computer science, 441–444. Springer.

Hoare, C. A. R. 1969. An axiomatic basis for computer programming. Communications of the ACM 12 (10): 576–580. doi:10.1145/363235.363259.

Hodgkin, A. L., and A. F. Huxley. 1952. A quantitative description of membrane current and its application to conduction and excitation in nerve. Journal of Physiology 117 (4): 500–544.

Holmes, Bruce J., Michael H. Durham, and Scott E. Tarry. 2004. Small aircraft transportation system concept and technologies. Journal of Aircraft 41 (1): 26–35.

Holzmann, Gerard J. 1997. The model checker SPIN. IEEE Transactions on Software Engineering 23 (5): 279–295. doi:10.1109/32.588521.

Holzmann, Gerard J., and Margaret H. Smith. 2000. Automating software feature verification. Bell Labs Technical Journal 5 (2): 72–87. doi:10.1002/bltj.2223.

Hsu, Kyle, Rupak Majumdar, Kaushik Mallik, and Anne-Kathrin Schmuck. 2018. Lazy abstraction-based control for safety specifications. In CDC’18: Proceedings of the 57th IEEE Conference on Decision and Control, 4902–4907. IEEE. doi:10.1109/CDC.2018.8619659.

Hu, Jianghai, John Lygeros, and Shankar Sastry. 2000. Towards a theory of stochastic hybrid systems. In HSCC’00: Proceedings of the 3rd International Workshop on Hybrid Systems: Computation and Control, eds. N. Lynch and B. H. Krogh. Vol. 1790 of Lecture notes in computer science, 160–173. Springer.

Huang, Zhenqi, Chuchu Fan, Alexandru Mereacre, Sayan Mitra, and Marta Z. Kwiatkowska. 2014. Invariant verification of nonlinear hybrid automata networks of cardiac cells. In CAV’14: Proceedings of the International Conference on Computer Aided Verification. Vol. 8559 of Lecture notes in computer science, 373–390. Springer.

Huang, Zhenqi, Chuchu Fan, Alexandru Mereacre, Sayan Mitra, and Marta Z. Kwiatkowska. 2015. Simulation-based verification of cardiac pacemakers with guaranteed coverage. IEEE Design & Test 32 (5): 27–34. doi:10.1109/MDAT.2015.2448543.

ISO. 2011. Road vehicles—functional safety, Technical Report ISO 26262, International Organization for Standardization (ISO).

ISO/TC 22/SC 32. 2019. Road vehicles—safety of the intended functionality (SOTIF), Technical report, International Organization for Standardization, Electrical and electronic components and general system aspects, PAS 21448. https://www.iso.org/standard/70939.html.

Ivanov, Radoslav, James Weimer, Rajeev Alur, George J. Pappas, and Insup Lee. 2019. Verisig: Verifying safety properties of hybrid systems with neural network controllers. In HSCC’19: Proceedings of the 22nd ACM International Conference on Hybrid Systems: Computation and Control, 169–178. ACM. doi:10.1145/3302504.3311806.

Izumi, Taisuke, and Petr Kuznetsov, eds. 2018. SSS’18: Proceedings of the 20th International Symposium on Stabilization, Safety, and Security of Distributed Systems. Vol. 11201 of Lecture notes in computer science. Springer. doi:10.1007/978-3-030-03232-6.

Jewison, Christopher, and R. Scott Erwin. 2016. A spacecraft benchmark problem for hybrid control and estimation. In CDC’16: Proceedings of the 2016 IEEE 55th Conference on Decision and Control, 3300–3305. IEEE.

Jézéquel, Jean-Marc, and Bertrand Meyer. 1997. Design by contract: The lessons of Ariane. Computer 30 (1): 129–130.

Jiang, Zhihao, Miroslav Pajic, and Rahul Mangharam. 2011. Cyber-physical modeling of implantable cardiac medical devices. Proceedings of the IEEE 100 (1): 122–137.

Jiang, Zhihao, Miroslav Pajic, Salar Moarref, Rajeev Alur, and Rahul Mangharam. 2012. Modeling and verification of a dual chamber implantable pacemaker. In TACAS’12: Proceedings of the International Conference on Tools and Algorithms for the Construction and Analysis of Systems. Vol. 7214 of Lecture notes in computer science, 188–203. Springer.

Jin, Xiaoqing, Jyotirmoy V. Deshmukh, James Kapinski, Koichi Ueda, and Ken Butts. 2014. Powertrain control verification benchmark. In HSCC’14: Proceedings of the 17th International Conference on Hybrid Systems: Computation and Control, 253–262. ACM. doi:10.1145/2562059.2562140.

Jin, Xiaoqing, Alexandre Donzé, Jyotirmoy V. Deshmukh, and Sanjit A. Seshia. 2015. Mining requirements from closed-loop control models. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 34 (11): 1704–1717.

Johnson, Taylor T., Jeremy Green, Sayan Mitra, Rachel Dudley, and Richard Scott Erwin. 2012. Satellite rendezvous and conjunction avoidance: Case studies in verification of nonlinear hybrid systems. In FM’12: Proceedings of the International Symposium on Formal Methods, eds. D. Giannakopoulou and D. Méry. Vol. 7436 of Lecture notes in computer science, 252–266. Springer.

Julius, A. Agung, and George J. Pappas. 2009. Trajectory based verification using local finite-time invariance. In HSCC’09: Proceedings of the International Workshop on Hybrid Systems: Computation and Control. Vol. 5469 of Lecture notes in computer science, 223–236. Springer.

Kant, Gijs, Alfons Laarman, Jeroen Meijer, Jaco van de Pol, Stefan Blom, and Tom van Dijk. 2015. LTSmin: High-performance language-independent model checking. In TACAS’15: Proceedings of the International Conference on Tools and Algorithms for the Construction and Analysis of Systems. Vol. 9035 of Lecture notes in computer science, 692–707. Springer.

Kapinski, J., J. V. Deshmukh, X. Jin, H. Ito, and K. Butts. 2016. Simulation-based approaches for verification of embedded control systems: An overview of traditional and advanced modeling, testing, and verification techniques. IEEE Control Systems 36 (6): 45–64. doi:10.1109/MCS.2016.2602089.

Kapinski, James, Jyotirmoy V. Deshmukh, Sriram Sankaranarayanan, and Nikos Arechiga. 2014. Simulation-guided Lyapunov analysis for hybrid dynamical systems. In HSCC’14: Proceedings of the 17th International Conference on Hybrid Systems: Computation and Control, 133–142. ACM. doi:10.1145/2562059.2562139.

Katz, Guy, Clark Barrett, David L. Dill, Kyle Julian, and Mykel J. Kochenderfer. 2017. Reluplex: An efficient SMT solver for verifying deep neural networks. In CAV’17: Proceedings of the 29th International Conference on Computer Aided Verification, Part I. Vol. 10426 of Lecture notes in computer science, 97–117. doi:10.1007/978-3-319-63387-9_5.

Kaynar, Dilsun K., Nancy A. Lynch, Roberto Segala, and Frits Vaandrager. 2005. The theory of timed I/O automata. Synthesis lectures on computer science. Morgan & Claypool. Also available as Technical Report MIT-LCS-TR-917, MIT.

Kearns, Michael J., and Umesh V. Vazirani. 1994. An introduction to computational learning theory. MIT Press.

Kinjawadekar, Tejas, Neha Dixit, Gary J. Heydinger, Dennis A. Guenther, and Mohamed Kamel Salaani. 2009. Vehicle dynamics modeling and validation of the 2003 Ford Expedition with ESC using CarSim, Technical Report 2009-01-0452, SAE International.

Kloetzer, Marius, and Calin Belta. 2008. A fully automated framework for control of linear systems from temporal logic specifications. IEEE Transactions on Automatic Control 53 (1): 287–297. doi:10.1109/TAC.2007.914952.

Kodaka, Kenji, Makoto Otabe, Yoshihiro Urai, and Hiroyuki Koike. 2003. Rear-end collision velocity reduction system, Technical Report 2003-01-0503, SAE International.

Kof, Leonid. 2004. Natural language processing for requirements engineering: Applicability to large requirements documents. Fakultät für Informatik, Technische Universität München.

Koopman, Philip, and Michael Wagner. 2016. Challenges in autonomous vehicle testing and validation. SAE International Journal of Transportation Safety 4 (2016-01-0128): 15–24.

Koymans, Ron. 1990. Specifying real-time properties with metric temporal logic. Real-Time Systems 2 (4): 255–299. doi:10.1007/BF01995674.

Kozarev, Alexandar, John Quindlen, Jonathan How, and Ufuk Topcu. 2016. Case studies in data-driven verification of dynamical systems. In HSCC’16: Proceedings of the 19th International Conference on Hybrid Systems: Computation and Control, 81–86. ACM. doi:10.1145/2883817.2883846.

Kress-Gazit, Hadas, Georgios E. Fainekos, and George J. Pappas. 2009. Temporal-logic-based reactive mission and motion planning. IEEE Transactions on Robotics 25 (6): 1370–1381.

Krizhevsky, Alex, Ilya Sutskever, and Geoffrey E. Hinton. 2012. ImageNet classification with deep convolutional neural networks. In NIPS’12: Advances in Neural Information Processing Systems 25, 1097–1105. Neural Information Processing Systems Foundation.

Kroening, Daniel, and Ofer Strichman. 2008. Decision procedures, an algorithmic point of view. Springer.

Krstić, Miroslav, Ioannis Kanellakopoulos, and Petar Kokotović. 1995. Nonlinear and adaptive control design. Wiley.

Kumar, P. R., and Pravin Varaiya. 2016. Stochastic systems: Estimation, identification, and adaptive control. SIAM.

Kurzhanski, Alexander B., and Pravin Varaiya. 2000. Ellipsoidal techniques for reachability analysis. In HSCC’00: Proceedings of the International Workshop on Hybrid Systems: Computation and Control, 202–214. Springer.

Kurzhanskiy, Alex A., and Pravin Varaiya. 2006. Ellipsoidal Toolbox (ET). In CDC’06: Proceedings of the 45th IEEE Conference on Decision and Control, 1498–1503. IEEE.

Kushner, Taisa, David Bortz, David M. Maahs, and Sriram Sankaranarayanan. 2018. A data-driven approach to artificial pancreas verification and synthesis. In ICCPS’18: Proceedings of the 2018 ACM/IEEE 9th International Conference on Cyber-Physical Systems, 242–252. IEEE. doi:10.1109/ICCPS.2018.00031.

Kushner, Taisa, B. Wayne Bequette, Faye Cameron, Gregory P. Forlenza, David M. Maahs, and Sriram Sankaranarayanan. 2019. Models, devices, properties, and verification of artificial pancreas systems. In Automated reasoning for systems biology and medicine, eds. Pietro Liò and Paolo Zuliani, 93–131. Springer. doi:10.1007/978-3-030-17297-8_4.

Kvasnica, Michal, Pascal Grieder, Mato Baotić, and Manfred Morari. 2004. Multi-Parametric Toolbox (MPT). In HSCC’04: Proceedings of the International Workshop on Hybrid Systems: Computation and Control. Vol. 2993 of Lecture notes in computer science, 448–462. Springer.

Lafferriere, Gerardo, George J. Pappas, and Shankar Sastry. 2000. O-minimal hybrid systems. Mathematics of Control, Signals and Systems 13 (1): 1–21.

Lamport, Leslie. 1978. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM 21 (7): 558–565.

Lattimore, Tor, and Csaba Szepesvári. 2020. Bandit algorithms. Cambridge University Press.

Le Guernic, Colas, and Antoine Girard. 2009. Reachability analysis of hybrid systems using support functions. In CAV’09: Proceedings of the International Conference on Computer Aided Verification, 540–554. Springer.

Legay, Axel, and Mahesh Viswanathan. 2015. Statistical model checking: Challenges and perspectives. International Journal on Software Tools for Technology Transfer 17 (4): 369–376. doi:10.1007/s10009-015-0384-z.

Leino, K. Rustan M. 2010. Dafny: An automatic program verifier for functional correctness. In LPAR’10: Proceedings of the International Conference on Logic for Programming Artificial Intelligence and Reasoning. Vol. 6355 of Lecture notes in computer science, 348–370. Springer.

Levin, Leonid. 1973. Universal search problems [in Russian]. Problems of Information Transmission 9 (3): 115–116. Translated into English by Trakhtenbrot, B. A. (1984), “A survey of Russian approaches to perebor (brute-force searches) algorithms,” Annals of the History of Computing 6 (4): 384–400.

Liberzon, Daniel. 2003a. Hybrid feedback stabilization of systems with quantized signals. Automatica 39 (9): 1543–1554.

Liberzon, Daniel. 2003b. Switching in systems and control. Systems & control: Foundations & applications. Birkhäuser.

Liberzon, Daniel, and Sayan Mitra. 2018. Entropy and minimal bit rates for state estimation and model detection. IEEE Transactions on Automatic Control 63 (10): 3330–3344. doi:10.1109/TAC.2017.2782478.

Lichtenstein, Orna, and Amir Pnueli. 2000. Propositional temporal logics: Decidability and completeness. Logic Journal of the IGPL 8 (1): 55–85. doi:10.1093/jigpal/8.1.55.

Lim, Hongping, Dilsun Kaynar, Nancy A. Lynch, and Sayan Mitra. 2005. Translating timed I/O automata specifications for theorem proving in PVS. In FORMATS’05: Proceedings of the International Conference on Formal Modeling and Analysis of Timed Systems. Lecture notes in computer science, 17–31. Springer.

Liu, Changliu, Tomer Arnon, Christopher Lazarus, Clark W. Barrett, and Mykel J. Kochenderfer. 2019. Algorithms for verifying deep neural networks. CoRR abs/1903.06758. http://arxiv.org/abs/1903.06758.

Livadas, Carolos, John Lygeros, and Nancy A. Lynch. 1999. High-level modeling and analysis of TCAS. In RTSS’99: Proceedings of the 20th IEEE Real-Time Systems Symposium, 115–125. IEEE.

Ljung, Lennart, ed. 1999. System identification: Theory for the user. Prentice Hall PTR.

Lohmiller, W., and J. J. E. Slotine. 1998. On contraction analysis for non-linear systems. Automatica 34 (6): 683–696.

Lygeros, John, Karl Henrik Johansson, Slobodan N. Simic, Jun Zhang, and Shankar S. Sastry. 2003. Dynamical properties of hybrid automata. IEEE Transactions on Automatic Control 48 (1): 2–17.

Lynch, Nancy A. 1996. A three-level analysis of a simple acceleration maneuver, with uncertainties. Real-Time Systems, Special Issue on Proceedings of the 3rd AMAST Workshop on Real-Time Systems.

Lynch, Nancy A., and Mark R. Tuttle. 1989. An introduction to input/output automata. CWI Quarterly 2 (3): 219–246.

Lynch, Nancy A., Roberto Segala, and Frits W. Vaandrager. 2001. Hybrid I/O automata revisited. In HSCC’01: Proceedings of the 4th International Workshop on Hybrid Systems: Computation and Control, eds. M. D. Di Benedetto and A. L. Sangiovanni-Vincentelli. Vol. 2034 of Lecture notes in computer science, 403–417. Springer.

Lynch, Nancy A., Roberto Segala, Frits Vaandrager, and H. B. Weinberg. 1995. Hybrid I/O automata. In Hybrid systems III, eds. R. Alur, T. A. Henzinger, and E. D. Sontag. Vol. 1066 of Lecture notes in computer science, 496–510. Springer.

Maidens, John, and Murat Arcak. 2015. Reachability analysis of nonlinear systems using matrix measures. IEEE Transactions on Automatic Control 60 (1): 265–270.

Maler, Oded, and Dejan Nickovic. 2004. Monitoring temporal properties of continuous signals. In Formal Techniques, Modelling and Analysis of Timed and Fault-Tolerant Systems: Proceedings of FORMATS 2004 and FTRTFT 2004: The Joint International Conferences on Formal Modelling and Analysis of Timed Systems, and Formal Techniques in Real-Time and Fault-Tolerant Systems. Vol. 3253 of Lecture notes in computer science, 152–166. Springer.

Malladi, Bharani P., Ricardo G. Sanfelice, Eric Butcher, and Jingwei Wang. 2016. Robust hybrid supervisory control for rendezvous and docking of a spacecraft. In CDC’16: Proceedings of the 2016 IEEE 55th Conference on Decision and Control, 3325–3330. IEEE.

Martins, João, André Platzer, and João Leite. 2011. Statistical model checking for distributed probabilistic-control hybrid automata with smart grid applications. In ICFEM’11: Proceedings of the 13th International Conference on Formal Methods and Software Engineering, 131–146. Springer.

Meseguer, José, and Raman Sharykin. 2006. Specification and analysis of distributed object-based stochastic hybrid systems. In HSCC’06: Proceedings of the 9th International Conference on Hybrid Systems: Computation and Control, 460–475. Springer.

Minsky, Marvin L. 1967. Computation: Finite and infinite machines. Prentice-Hall.

Mitra, Sayan. 2007. A verification framework for hybrid systems. PhD dissertation, Massachusetts Institute of Technology. http://people.csail.mit.edu/mitras/research/thesis.pdf.

Mitra, Sayan, and K. Mani Chandy. 2008. A formalized theory for verifying stability and convergence of automata in PVS. In TPHOLs’08: Proceedings of the International Conference on Theorem Proving in Higher Order Logics, eds. O. A. Mohamed, C. Muñoz, and S. Tahar. Vol. 5170 of Lecture notes in computer science, 230–245. Springer.

Mitra, Sayan, Daniel Liberzon, and Nancy A. Lynch. 2008. Verifying average dwell time of hybrid systems. ACM Transactions on Embedded Computing Systems 8 (1): 1–37. doi:10.1145/1457246.1457249.

Mitra, Sayan, Yong Wang, Nancy A. Lynch, and Eric Feron. 2003. Safety verification of model helicopter controller using hybrid input/output automata. In HSCC’03: Proceedings of the International Workshop on Hybrid Systems: Computation and Control, eds. Oded Maler and Amir Pnueli. Vol. 2623 of Lecture notes in computer science, 343–358. Springer.

Mitsch, Stefan, and André Platzer. 2016. Modelplex: Verified runtime validation of verified cyber-physical system models. Formal Methods in System Design 49 (1–2): 33–74.

Moler, Cleve, and Charles Van Loan. 2003. Nineteen dubious ways to compute the exponential of a matrix, twenty-five years later. SIAM Review 45 (1): 3–49.

Moore, F. K., and E. M. Greitzer. 1986. A theory of poststall transients in axial compressor systems: Part I—development of equations. Journal of Engineering for Gas Turbines and Power 108 (1): 68–76.

Moskewicz, Matthew W., Conor F. Madigan, Ying Zhao, Lintao Zhang, and Sharad Malik. 2001. Chaff: Engineering an efficient SAT solver. In DAC’01: Proceedings of the 38th Annual Design Automation Conference, 530–535. ACM. doi:10.1145/378239.379017.

Munos, Remi. 2014. From bandits to Monte-Carlo tree search: The optimistic principle applied to optimization and planning. Foundations and Trends in Machine Learning 7 (1): 1–129.

Nagumo, J., S. Arimoto, and S. Yoshizawa. 1962. An active pulse transmission line simulating nerve axon. Proceedings of the Institute of Radio Engineers 50 (10): 2061–2070.

Nedialkov, Ned. 2006. VNODE-LP: Validated Solutions for Initial Value Problem for ODEs, Technical report, McMaster University.

Nuzzo, Pierluigi, Alberto L. Sangiovanni-Vincentelli, Davide Bresolin, Luca Geretti, and Tiziano Villa. 2015. A platform-based design methodology with contracts and related tools for the design of cyber-physical systems. Proceedings of the IEEE 103 (11): 2104–2132. doi:10.1109/JPROC.2015.2453253.

Ogata, Katsuhiko. 2009. Modern control engineering. Prentice Hall.

Or, Yizhar, and Aaron D. Ames. 2010. Stability and completion of Zeno equilibria in Lagrangian hybrid systems. IEEE Transactions on Automatic Control 56 (6): 1322–1336.

Owre, S., S. Rajan, J. M. Rushby, N. Shankar, and M. Srivas. 1996. PVS: Combining specification, proof checking, and model checking. In CAV’96: Proceedings of the International Conference on Computer Aided Verification, eds. Rajeev Alur and Thomas A. Henzinger. Vol. 1102 of Lecture notes in computer science, 411–414. Springer.

Paden, Brian, Michal Cáp, Sze Zheng Yong, Dmitry S. Yershov, and Emilio Frazzoli. 2016. A survey of motion planning and control techniques for self-driving urban vehicles. IEEE Transactions on Intelligent Vehicles 1 (1): 33–55. doi:10.1109/TIV.2016.2578706.

Padon, Oded, Kenneth L. McMillan, Aurojit Panda, Mooly Sagiv, and Sharon Shoham. 2016. Ivy: Safety verification by interactive generalization. In PLDI’16: Proceedings of the 37th ACM SIGPLAN Conference on Programming Logic Language Design and Implementation, 614–630. ACM.

Papadimitriou, Christos H. 2003. Computational complexity. In Encyclopedia of computer science, 260–265. John Wiley and Sons.

Perkins, Jeff H., and Michael D. Ernst. 2004. Efficient incremental algorithms for dynamic detection of likely invariants. ACM SIGSOFT Software Engineering Notes 29 (6): 23–32. doi:10.1145/1041685.1029901.

Perry, Raleigh B., Michael M. Madden, Wilfredo Torres-Pomales, and Ricky W. Butler. 2013. The simplified aircraft-based paired approach with the ALAS alerting algorithm, Technical Report NASA/TM-2013-217804, NASA, Langley Research Center.

Peterson, Gary L., and Michael J. Fischer. 1977. Economical solutions for the critical section problem in a distributed system (extended abstract). In STOC’77: Proceedings of the 9th Annual ACM Symposium on Theory of Computing, 91–97. ACM. doi:10.1145/800105.803398.

Piterman, Nir, Amir Pnueli, and Yaniv Sa’ar. 2006. Synthesis of reactive(1) designs. In VMCAI’06: Proceedings of the 7th International Conference on Verification, Model Checking, and Abstract Interpretation, 364–380. Springer.

Plaku, Erion, Lydia E. Kavraki, and Moshe Y. Vardi. 2009. Falsification of LTL safety properties in hybrid systems. In TACAS’09: Proceedings of the 15th International Conference on Tools and Algorithms for the Construction and Analysis of Systems. Vol. 5505 of Lecture notes in computer science, 368–382. Springer.

Platzer, André. 2008. Differential dynamic logic for hybrid systems. Journal of Automated Reasoning 41 (2): 143–189.

Platzer, André. 2018. Logical foundations of cyber-physical systems. Springer.

Platzer, André, and Edmund M. Clarke. 2008. Computing differential invariants of hybrid systems as fixedpoints. In CAV’08: Proceedings of the International Conference on Computer Aided Verification. Vol. 5123 of Lecture notes in computer science, 176–189. Springer.

Platzer, André, and Jan-David Quesel. 2008. KeYmaera: A hybrid theorem prover for hybrid systems (system description). In Automated reasoning, eds. Alessandro Armando, Peter Baumgartner, and Gilles Dowek, 171–178. Springer.

Platzer, André, and Jan-David Quesel. 2009. European train control system: A case study in formal verification. In Formal Methods and Software Engineering: ICFEM: Proceedings of the International Conference on Formal Engineering Methods. Vol. 5885 of Lecture notes in computer science, 246–265. Springer. doi:10.1007/978-3-642-10373-5_13.

Pnueli, A., and R. Rosner. 1989. On the synthesis of a reactive module. In POPL’89: Proceedings of the 16th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 179–190. ACM. doi:10.1145/75277.75293.

Podelski, Andreas, and Andrey Rybalchenko. 2004. Transition invariants. In LICS’04: Proceedings of the 19th Annual IEEE Symposium on Logic in Computer Science, 32–41. IEEE Computer Society. doi:10.1109/LICS.2004.50.

Prabhakar, Pavithra, Geir Dullerud, and Mahesh Viswanathan. 2012. Pre-orders for reasoning about stability. In HSCC’12: Proceedings of the 15th ACM International Conference on Hybrid Systems: Computation and Control, 197–206. ACM.

Prabhakar, Pavithra, Parasara Sridhar Duggirala, Sayan Mitra, and Mahesh Viswanathan. 2015. Hybrid automata-based CEGAR for rectangular hybrid systems. Formal Methods in System Design 46 (2): 105–134. doi:10.1007/s10703-015-0225-4.

Prajna, Stephen, and Ali Jadbabaie. 2004. Safety verification of hybrid systems using barrier certificates. In HSCC’05: Proceedings of the International Workshop on Hybrid Systems: Computation and Control. Vol. 2993 of Lecture notes in computer science, 477–492. Springer.

Press, William H., Saul A. Teukolsky, William T. Vetterling, and Brian P. Flannery. 1992. Numerical recipes in C: The art of scientific computing, 2nd edn. Cambridge University Press.

Raman, Vasumathi, Alexandre Donzé, Dorsa Sadigh, Richard M. Murray, and Sanjit A. Seshia. 2015. Reactive synthesis from signal temporal logic specifications. In HSCC’15: Proceedings of the 18th International Conference on Hybrid Systems: Computation and Control, 239–248. ACM.

Ramsey, F. P. 1930. On a problem of formal logic. Proceedings of the London Mathematical Society 30 (1): 264–285.

Rana, Rakesh, Miroslaw Staron, Christian Berger, Jörgen Hansson, Martin Nilsson, and Fredrik Törner. 2013. Early verification and validation according to ISO 26262 by combining fault injection and mutation testing. In ICSOFT’13: Proceedings of the International Conference on Software Technologies. Vol. 457 of Communications in computer and information science, 164–179. Springer.

Reingold, Omer. 2008. Undirected connectivity in log-space. Journal of the ACM 55 (4): 17.

Rodríguez-Carbonell, Enric, and Ashish Tiwari. 2005. Generating polynomial invariants for hybrid systems. In HSCC’05: Proceedings of the 8th International Conference on Hybrid Systems: Computation and Control. Vol. 3414 of Lecture notes in computer science, 590–605. Springer.

Roohi, Nima, Pavithra Prabhakar, and Mahesh Viswanathan. 2017a. HARE: A hybrid abstraction refinement engine for verifying non-linear hybrid automata. In TACAS’17: Proceedings of the 23rd International Conference on Tools and Algorithms for the Construction and Analysis of Systems, Part I. Vol. 10205 of Lecture notes in computer science, 573–588. Springer. doi:10.1007/978-3-662-54577-5_33.

Roohi, Nima, Yu Wang, Matthew West, Geir Dullerud, and Mahesh Viswanathan. 2017b. Statistical verification of Toyota powertrain control verification benchmark. In HSCC’17: Proceedings of the 20th International Conference on Hybrid Systems: Computation and Control, 65–70. ACM.

RTCA, Inc. 2011. DO-178C, software considerations in airborne systems and equipment certification, Technical report, Special Committee 205 of RTCA.

Sadraddini, Sadra, and Calin Belta. 2019. Formal synthesis of control strategies for positive monotone systems. IEEE Transactions on Automatic Control 64 (2): 480–495.

Sankaranarayanan, Sriram, Henny B. Sipma, and Zohar Manna. 2008. Constructing invariants for hybrid systems. Formal Methods in System Design 32 (1): 25–55.

Sankaranarayanan, Sriram, Suhas Akshar Kumar, Faye Cameron, B. Wayne Bequette, Georgios E. Fainekos, and David M. Maahs. 2017. Model-based falsification of an artificial pancreas control system. SIGBED Review 14 (2): 24–33. doi:10.1145/3076125.3076128.

Savitch, Walter J. 1970. Relationships between nondeterministic and deterministic tape complexities. Journal of Computer and System Sciences 4 (2): 177–192.

Sen, Koushik, Mahesh Viswanathan, and Gul Agha. 2005a. On statistical model checking of stochastic systems. In CAV’05: Proceedings of the 17th International Conference on Computer Aided Verification. Vol. 3576 of Lecture notes in computer science, 266–280. Springer.

Sen, Koushik, Mahesh Viswanathan, and Gul A. Agha. 2005b. VESTA: A statistical model-checker and analyzer for probabilistic systems. In QEST’05: Proceedings of the 2nd International Conference on the Quantitative Evaluation of Systems, 251–252. IEEE.

Shalev-Shwartz, Shai, Shaked Shammah, and Amnon Shashua. 2017. On a formal model of safe and scalable self-driving cars. arXiv preprint:1708.06374. http://arxiv.org/abs/1708.06374.

Si, Xujie, Hanjun Dai, Mukund Raghothaman, Mayur Naik, and Le Song. 2018. Learning loop invariants for program verification. In NIPS’18: Advances in Neural Information Processing Systems 31, eds. S. Bengio, H. Wallach, H. Larochelle, K. Grauman, N. Cesa-Bianchi, and R. Garnett, 7751–7762. Curran Associates.

Silver, David, Julian Schrittwieser, Karen Simonyan, Ioannis Antonoglou, Aja Huang, Arthur Guez, Thomas Hubert, Lucas Baker, Matthew Lai, Adrian Bolton, Yutian Chen, Timothy Lillicrap, Fan Hui, Laurent Sifre, George van den Driessche, Thore Graepel, and Demis Hassabis. 2017. Mastering the game of Go without human knowledge. Nature 550 (7676): 354–359.

Sipser, Michael. 1996. Introduction to the theory of computation. International Thomson Publishing.

Sistla, A. Prasad, Miloš Žefran, and Yao Feng. 2011. Runtime monitoring of stochastic cyber-physical systems with hybrid state. In RV’11: Proceedings of the International Conference on Runtime Verification. Vol. 7186 of Lecture notes in computer science, 276–293. Springer.

Sontag, Eduardo D. 2010. Contractive systems with inputs. In Perspectives in mathematical system theory, control, and signal processing, 217–228. Springer.

Szegedy, Christian, Wojciech Zaremba, Ilya Sutskever, Joan Bruna, Dumitru Erhan, Ian Goodfellow, and Rob Fergus. 2013. Intriguing properties of neural networks. arXiv preprint arXiv:1312.6199.

Tabuada, Paulo. 2008. Controller synthesis for bisimulation equivalence. Systems & Control Letters 57 (6): 443–452.

Tabuada, Paulo. 2009. Verification and control of hybrid systems: A symbolic approach. Springer.

Teel, Andrew R., and João P. Hespanha. 2015. Stochastic hybrid systems: A modeling and stability theory tutorial. In CDC’15: Proceedings of the 54th IEEE Conference on Decision and Control, 3116–3136. IEEE. doi:10.1109/CDC.2015.7402688.

Tiwari, Ashish. 2008. Generating box invariants. In HSCC’08: Proceedings of the International Workshop on Hybrid Systems: Computation and Control. Vol. 4981 of Lecture notes in computer science, 658–661. Springer.

Tsitsiklis, John N. 1987. On the stability of asynchronous iterative processes. Theory of Computing Systems 20 (1): 137–153.

Tuttle, Mark R., and Amit Goel. 2012. Protocol proof checking simplified with SMT. In NCA’12: Proceedings of the 2012 IEEE 11th International Symposium on Network Computing and Applications, 195–202. IEEE.

Umeno, Shinya, and Nancy A. Lynch. 2006. Proving safety properties of an aircraft landing protocol using I/O automata and the PVS theorem prover: A case study. In FM’06: Proceedings of the 14th International Symposium on Formal Methods. Vol. 4085 of Lecture notes in computer science, 64–80. Springer. doi:10.1007/11813040_5.

Umeno, Shinya, and Nancy A. Lynch. 2007. Safety verification of an aircraft landing protocol: A refinement approach. In HSCC’07: Proceedings of the International Workshop on Hybrid Systems: Computation and Control. Vol. 4416 of Lecture notes in computer science, 557–572. Springer.

Vladimerou, Vladimeros, Pavithra Prabhakar, Mahesh Viswanathan, and Geir E. Dullerud. 2008. STORMED hybrid systems. In ICALP’08: Proceedings of the International Colloquium on Automata, Languages and Programming. Vol. 5126 of Lecture notes in computer science, 136–147. Springer.

Weinberg, H. B., and Nancy A. Lynch. 1996. Correctness of vehicle control systems—a case study. In RTSS’96: Proceedings of the 17th IEEE Real-Time Systems Symposium, 62–72. IEEE.

Weinberg, H. B., Nancy A. Lynch, and Norman Delisle. 1995. Verification of automated vehicle protection systems. In HS’95: Proceedings of the International Hybrid Systems Workshop, eds. R. Alur, T. A. Henzinger, and E. D. Sontag. Vol. 1066 of Lecture notes in computer science, 101–113. Springer.

Wongpiromsarn, Tichakorn, Sayan Mitra, Richard M. Murray, and Andrew Lamperski. 2009. Periodically controlled hybrid systems: Verifying a controller for an autonomous vehicle. In HSCC’09: Proceedings of the International Workshop on Hybrid Systems: Computation and Control, eds. R. Majumdar and P. Tabuada. Vol. 5469 of Lecture notes in computer science, 396–410. Springer.

Wongpiromsarn, Tichakorn, Ufuk Topcu, Necmiye Ozay, Huan Xu, and Richard M Murray. 2011. TuLiP: A software toolbox for receding horizon temporal logic planning. In HSCC’11: Proceedings of the 14th International Conference on Hybrid Systems: Computation and Control, 313–314. ACM.

Xiang, Weiming, Hoang-Dung Tran, and Taylor T. Johnson. 2018a. Output reachable set estimation and verification for multilayer neural networks. IEEE Transactions on Neural Networks and Learning Systems 29 (11): 5777–5783.

Xiang, Weiming, Patrick Musau, Ayana A. Wild, Diego Manzanas Lopez, Nathaniel Hamilton, Xiaodong Yang, Joel A. Rosenfeld, and Taylor T. Johnson. 2018b. Verification for machine learning, autonomy, and neural networks survey. CoRR abs/1810.01989. http://arxiv.org/abs/1810.01989.

Younes, Hakan L. S., and Reid G. Simmons. 2002. Probabilistic verification of discrete event systems using acceptance sampling. In CAV’02: Proceedings of the International Conference on Computer Aided Verification. Vol. 2404 of Lecture notes in computer science, 223–235. Springer.

Zamani, Mahdi, Giordano Pola, Manuel Mazo, and Paulo Tabuada. 2012. Symbolic models for nonlinear control systems without stability assumptions. IEEE Transactions on Automatic Control 57 (7): 1804–1809.

Index

abstraction, 147

action, 19

input, 80

internal, 80

output, 80

ADAS, see advanced driver-assistance system

admissible execution, 71

advanced driver-assistance system, 3, 96, 236

ASIL, see Automotive Safety Integrity Level

asymptotic stability, see stability, asymptotic, 210

asynchronous system, 27, 206

atomic proposition, 112

automaton, 22

BiDiLeader, 27

closed, 80

composition, 80

DijkstraTR, 25

FifoCh, 81

finite, 23

FlipFlop, 17

FlipFlopIO, 90

invariant, 24, 123

Lamport, 83

LTF, 84

MST, 203

open, 80

reachability, 24

reachset, 24, 123

RippleCounter, 29

UpDown, 200

Vehicle, 42

Automotive Safety Integrity Level, 104

autonomous

ordinary differential equation, 37

autonomous rendezvous proximity operations and docking, 237

autonomous vehicle, 3

AUTOSAR, 102

average dwell time, 212

backward simulation, 154

barrier certificates, 136

bicycle model, 42

bisimilarity, 152

bisimulation, 152

black-box module, 229

bloat, 221

breadth first search, 167

cardiac oscillator, 93

CEGAR, see counterexample-guided abstraction refinement

clock, 168

clock constraints, 168

clock equivalence, 171

clock region, 172

common Lyapunov function, 210

comparable, 148

compass-gait, 55

compatibility, 80, 89

completeness, 107, 261

composition, 79, 80, 84, 89, 93, 127

compositional, see substitutivity

computational tree logic, 116

concatenation, 60

concretization, 160

configuration

Turing machine, 256

conjunctive normal form, 137

contraction metric, 223

control design, 51

control state, 63

control synthesis, 52

controller synthesis, 50, 118

convergence, 206

convex hull, 190, 191

counter, 29

counterexample, 106

counterexample-guided abstraction refinement, 158

cover, 221

CPS, see cyber-physical system

CTL, see computational tree logic

cyber-physical system, 1, 229

DAL, see Design Assurance Level

decision problem, 255

dense time, 34

Design Assurance Level, 102

deterministic

automaton, 23

hybrid automaton, 61

Turing machine, 257

difference equation, 47

differential equation, see ordinary differential equation

Dijkstra’s token ring, 25, 202

discrepancy function, 218, 222

learning, 232

local, 225

discrete transition system, see automaton

DO-178C, 102

DO-330, 103

DO-333, 103

dom, 34, 59

DPLL, 138

Dubin’s vehicle, 42

dwell time, 212

dynamical system, 31, 39

economy model, 47

effect, 19

eigenvalue, 249

ellipsoid, 193

emergency braking, 96

enabled, 22

equilibrium point, 39, 47

Euler method, 48

execution, 24, 65, 84, 113

admissible, 71

automaton, 24

closed, 71

finite, 65

fragment, 24, 65

hybrid automaton, 65

input/output automaton, 80

labeled transition system, 24

Zeno, 71

execution fragment, 24

exponential stability, see stability, exponential

failure detector, 92

fairness, 82, 207

falsification, 243

FIFO channels, 81, 91

finite automaton, 23, 208

finite state machine, 23

Fischer’s mutual exclusion, 127

fixed point, 39, 206

flip-flop, 17, 90

float, 74

formal parameters, 25, 204

forward simulation

hybrid automaton, 149

fragment, 24, 65

FSM, see finite state machine

fstate, 24, 59

Grönwall’s inequality, 223, 252

half-space, 190

hardness, 261

HIOA, see hybrid input/output automaton

Hoare logic, 125

hybrid automaton, 60

Ball, 126

comparable, 148

composition, 89

deterministic, 61

I/O abstraction, 148

initialized rectangular, 182

jet engine, 222

linear, 63, 191

LineCar, 33

Lyapunov function, 210

multirate, 176

Pendulum, 40

Powertrain, 228

PulseGen, 93, 228

rectangular, 64

RimlessWheel, 55

simple, 63

SingleLaneCar, 96

SATS, 74

SpaceRndz, 72

Switch, 170

SwitchedSys, 63

Thermostat, 63

timed, 65

TimedChannel, 91

trace, 95

TTh, 146

hybrid input/output automaton, 88

hybrid systems, 5

hybridization, 155

hyperrectangle, 186

I/O abstraction

hybrid automaton, 148

I/O automaton, see input/output automaton

implementation, 148

inductive invariant, 124

inductive property, 124

initial state, see start state

initial value problem, 48

initialized rectangular hybrid automaton, 182

input action, 80

input enabled, 88

input variable, 87

input/output automaton, 79

composition, 80

execution, 80

invariant, 80

reachable state, 80

integral timed automaton, 169

internal action, 80

internal variable, 87

interval matrix, 251

invariant, 24, 109, 154, 166

automaton, 24

bounded, 110

generation, 142

hybrid automaton, 65

proving inductively, 123

IOA, see input/output automaton

ISO 26262, 96, 104, 236

Jacobian, 222, 248

JK flip-flop, 17

Jordan normal form, 250

kinematic vehicle, 42

Kripke structure, 112

labeled transition system, 22, 112

Lamport clock, 83

lasso, 111

leader election, 27

leader-follower, 90

linear dynamical system, see linear system

linear hybrid automaton, 63

linear separator, 232

linear system, 38, 47, 223

linear temporal logic, 111, 113

linear time-invariant system, 38, 46, 47

Lipschitz constant, 248

Lipschitz continuity, 37, 248

local, 37

liveness, 110

local discrepancy, 225

location, 63

logical clock, 83

lstate, 24, 59

LTI system, see linear time-invariant system

LTL, see linear temporal logic

LTS, see labeled transition system

Lyapunov equation, 46

Lyapunov function, 44, 46, 47, 208

common, 210

multiple, 211

weak, 44, 46

Lyapunov stability, 39

machine learning, 244

matrix exponential, 39

matrix measure, 225, 242

metric interval temporal logic, 119

metric temporal logic, 119

minimal spanning stree, 203

Minkowski sum, 188

MITL, see metric interval temporal logic

ML, see machine learning

mode, 62, 63

monitoring, 120

MTL, see metric temporal logic

multiple Lyapunov function, 211

multirate automaton, 176

mutual exclusion, 25, 127

negative definite, 250

nondeterminism

external, 23

internal, 23

nondeterministic

automaton, 23

hybrid automaton, 61

Turing machine, 257

numerical simulation, 48

numerical solution, 48, 67, 218

ODE, see ordinary differential equation

open

execution, 71

open problem, 242

open-loop system, 49

optimization problem, 255

orbital dynamics, 72, 156

ordinary differential equation, 31

autonomous system, 37

linear, 38

linear time-invariant system, 38

reachability, 39

reachset, 39

solution, 37

time-invariant system, 37

output action, 80

output variable, 87

path quantifier, 116

pendulum, 40

PID controller, 51

piece-wise continuous function, 36

point trajectory, 34, 59

polyhedron, 190

polytope, 190

positive definite, 250

function, 248

matrix, 193

positive semidefinite, 250

Post, 184

poststate, 22, 24, 61

powertrain hybrid model

Powertrain, 228

pre-HIOA, 88

precondition, 19

predicate, 20, 21

prefix, 60

preorder, 146

prestate, 22, 24

progress, 110

progress property, see progress

QBF, see quantified Boolean formula

quantified Boolean formula, 142

quantization, 74

radially unbounded

function, 248

ranking function, 199, 205

rational timed automaton, 176

Reach, 24, 39

reachability, 165

bounded, 184, 218

control state, 173

data-driven, 219

hybrid automaton, 65

simulation-based, 219

reachable set, see reachset

reachable state, 24, 39

automaton, 24

hybrid automaton, 65

ordinary differential equation, 39

reachset, 24, 39, 165

automaton, 24

hybrid automaton, 65

input/output automaton, 80

ordinary differential equation, 39

reachtube, 218

rectangle, 186

rectangular hull, 188

rectangular hybrid automaton, 64, 186

refinement, 163

region automaton, 172

requirements, 1, 101

Responsibility Sensitive Safety, 105

restriction, 84, 85

execution, 93

RHull, 189

rimless walker, 55

rimless wheel, 56

ring network, 27

robust safety, 221

RSS, see Responsibility Sensitive Safety

Runge-Kutta, 49

runtime verification, 120

safety, 109

bounded, 110

Safety of the Intended Functionality, 105

safety property, see safety

sample complexity, 242

sampled time, 23

SAT, see satisfiability

satellite, 72, 237

satisfaction, 21, 114

satisfiability, 137

satisfiability modulo theory, 138

satisfies, see satisfaction

SATS, see Small Aircraft Transportation System

self-stabilization, 26, 202

semantics, 20

sensitivity analysis, 218, 241

SHA, see simple hybrid automaton

signal temporal logic, 119

simple hybrid automaton, 63

linear, 63

slow switching, 212

Small Aircraft Transportation System, 74

SMT, see satisfiability modulo theory

solution

numerical, 48

ordinary differential equation, 35, 37

SOTIF, see Safety of the Intended Functionality

soundness, 107

spacecraft docking, 72, 237

specification language, 17, 20

actions, 19

eff, 19, 25

formal parameters, 25

initially, 204

invariant, 58

mode, 58

pre, 19, 25

stop when, 82

trajectories, 33

transitions, 19

type, 25

variables, 19, 33

specifications, 101

ST-connectivity, 166, 167

stability, 39, 51, 68, 152, 154

asymptotic, 40, 44, 68

exponential, 40

global asymptotic, 40, 44

global exponential, 40

stable, 39, 44, 51

start state, 22

state, 20

state variable, 20, 87

statistical model checking, 243

steady-state error, 52

STL, see signal temporal logic

stop when, 72

strong forward simulation, 151

hybrid automaton, 151

strongly comparable, 148

sublevel set, 47, 208

substitutivity, 157

subtangential, 134

suffix, 60

switched system, 62

switching signal, 62

synchronous, see synchronous system

synchronous system, 27

synthesis, see controller synthesis

template, 142

invariant, 142

temporal logic, 111

termination, 198

theory solver, 138

thermostat, 63

time-abstract automaton, 69

timed automaton, 65, 169

rational, 176

timed channel, 91

topology, 206

trace, 84, 85

Traces, 85

trajectory, 34, 231

closed, 34

domain, 34

open, 34

point, 34, 59

transition, 19, 22

transition system, see automaton

transitive closure, 201

Turing machine, 256

deterministic, 257

nondeterministic, 257

two-counter machine, 178

type, 20, 25

untime, 85, 95

untiming, 153

urgency, 58, 82, 269

urgent, 269

transitions, 58

validation, 162

valuation, 20, 33, 168

variable, 19

verification, 2

algorithm, 106

runtime, 120

violates, see violation

violation, 21

well-founded relation, 199

well-ordering relation, 199

wrapping error, 226

Zeno behavior, 71

zonotope, 192