Fundamentals of Robotics Verification Dennis Meckel Technische Universitat¨ Kaiserslautern, Embedded Systems Group [email protected] Abstract Robots, especially commercial and autonomous ones, are usually complex cyber-physical systems oper- ating in safety-critical environments. Therefore it is important to prove that these systems do not cause harm. Field tests and simulations are not exhaustive and therefore not sufficient. Formal verification is exhaustive and can therefore prove that a given system satisfies its specification. The paper at hand gives a high-level introduction to formal verification and the tools BRAHMS,PROMELA, SPIN, and UPPAAL. Contents 1 Introduction 1 2 Structure 2 3 Model Checking 2 4 Temporal Logics 3 5 Brahms, Promela and SPIN 5 6 Uppaal 10 7 Conclusions 17 8 Glossary 18 1 Introduction Cyber-physical systems are ubiquitous. They are not only supporting safety-critical driver and pilot decision with alerting functions or fine-grained adaptions of human control actions but are also striving to conquer the world as fully autonomous mobile robots. [7] Robots are leaving their known environments to explore and work where no robot (or man) has gone before. Highly specialized robots like pavers, road rollers and lorries will team up to extend and maintain the infrastructure used for transportation. [6] Autonomous cars will supersede the need for human drivers. Service robots will assist the elderly and incapacitated in their homes and will also ensure that humans working in hazardous environments remain safe if the robots are not executing the dangerous tasks themselves. [17] 2 The previously mentioned robots are complex systems consisting of tremendous amounts of concur- rently running software modules and hardware components. They have to adapt to unforeseen situations while ensuring that “something bad will never happen”1 For instance, robots should not harm themselves, other robots and most importantly not humans. Field tests and simulations can increase the trust and con- fidence in robots but only verification can proof that robots follow their specifications by systematically and automatically exploring all possible actions. 2 Structure The adoption of formal verification is motivated by showing the limits of field tests and simulations in section 3. Afterwards, the concept of model checking is introduced as a solution. The later introduced tools and examples (see Table 1) utilize property checks formulated with the temporal logics CTL and LTL. Therefore a high-level introduction to temporal logics is given in section 4. section 5 presents the tools BRAHMS,PROMELA, and SPIN. BRAHMS is used in this section to model a service robot and additional agents including the house in which the robot operates and humans interacting with the robot. As BRAHMS is lacking a verification tool the model gets exported to PROMELA and then verified with SPIN. The tool UPPAAL and the behavior-based robot architecture IB2C are introduced in section 6. Subsequently, the section also shows how to model and verify IB2C networks with UPPAAL. The paper closes with the conclusions given in section 7 and a short glossary in section 8. Section Tools Verification Logics 5 BRAHMS,PROMELA and SPIN LTL 7 KEYMAERA,KEYMAERA X Differential Dynamic Logic (dL) 6 UPPAAL CTL Table 1: The verification tools BRAHMS,PROMELA, SPIN and UPPAAL are introduced in dedicated chapters. KEYMAERA and KEYMAERA X are referenced in the conclusion. 3 Model Checking Field tests and simulations can be used to reconstruct, analyze and show the presence of undesirable behaviors. Both techniques can also be used for testing specific use cases. The problem with these measures is that they do not scale well with respect to complexity and that they are too costly (time and budget wise, if possible at all) to explore all possible actions and consequences. Safety-critical systems can’t be trusted and shouldn’t be used without exhaustive checks due to the number of possible unforeseen and undesired consequences. Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. — Edsger W. Dijkstra 1This is a reference to section 4). 3 Exhaustive checks can be realized and automated with the help of formal verification. Model or property checking is such a technique for automatically testing whether a system model meets a given specification. The first step is to create a simplified system model which represents a real-world model, e.g. a microcontroller or a robot. Although the simplification is necessary to keep the model complexity low, the system model has to be as accurate as possible. It is common to reduce data types to binary types. One example is given in section 6 where integer signals representing the degree of behavior activations in [0;1] are reduced to binary signals f0;1g, either representing that a robot behavior is fully inactive or fully active. [3] Such a simplification can drastically reduce the resulting complexity. In the worst case, every possible value has to be checked. The system model is usually realized as an automaton or a collection of interconnected automata (see the IB2C example in section 6). It is also possible to create high-level models which have to be converted into another model for verification (see section 5 which utilizes BRAHMS models, that are automatically converted to SPIN for verification). The specification properties are modeled in the second step. Safety properties state that their property has to hold for all computations and times, e.g. a robot does not collide with a static obstacle. Liveness properties state that some desired state can eventually be reached, e.g. a robot behavior gets activated. Persistence properties are similar to safety properties except that the properties are allowed to not hold up to a point of time. After that point of time, the properties have to hold forever. Fairness (or recurrence) properties hold infinitely often, e.g. a robot behavior gets activated infinitely often. This does not imply that the behavior has to be active all the time. [3] [16] [18] The last step is to execute the verification tools and, depending on the complexity of the system model and the properties, return some hours later to inspect the results. As the number of states becomes easily prohibitively large, verification tools and users have to fight state-explosions by reducing the complexity of system models and by reducing the number of checked states per property. [10] for instance reduces a robot’s safety layer with more than 450 interconnected behaviors to 14 behaviors of interest (with at least 70 automata according to the automatically applied modeling, see section 6) to tackle state explosions and to check one specific property. Despite this huge reduction the verification still takes three hours and 75 GB of memory. [9] Verification tools like SPIN and UPPAAL provide traces for every failed check. This allows to analyze errors in the implementation and specification. It is important to note that the verification of a system does not guarantee that the system is free of errors. A formal verification only shows that the formal system model satisfies the given formal specification. [16, p. 8] Therefore it is crucial to assure that the specification is correct and the system model is representing the real-world system. As a consequence, formal verification should be complemented with simulation-based and real-world tests. [18] 4 Temporal Logics Temporal logics extend predicate logic with special temporal operators. With these operators they are able to describe the ordering of events in time without introducing time explicitly. [2] Additionally, tem- poral logics have been developed to support arbitrarily nested formulas. [16] Intuitive formula nesting allows to define specifications in a human readable structured way which improves the readability and understandability compared with mostly flat and unstructured w-automata transition diagrams. This is especially true when working with bigger automata (ten or more states are already enough to question transition diagrams). [16, Chap. 5] The paper at hand focuses only on the details which are necessary to understand the concepts of the later introduced practical verification techniques, tools and examples. 4 Therefore the following paragraphs contain only a superficial introduction to Linear Temporal Logic (LTL) and Computational Tree Logic (CTL). An in-depth introduction to formal verification and espe- cially temporal logics is given by [16]2. The introduced techniques are based on automata. These automata consist of states (or locations when working with UPPAAL) and connections between the states. Firing an edge (following a connection between two states), which is only possible when the edge is enabled (an edge specific propositional formula evaluates to true), can but does not have to consume time. These automata can be verified with temporal operators and path quantifiers by specifying properties which have to hold, e.g. a robot should never crash into an obstacle. [16, Chap. 5] Properties are checked by inspecting the automata. Path quantifiers quantify over computation paths starting from an initial state s. Given a formula j, the existential path quantifier Ej holds when there exists at least one path starting from s which satisfies j. The universal path quantifier Aj on the other hand holds only when all possible paths starting from s satisfy j. According to [16, p. 285] LTL does not support the existential operator E. Four (plus one without a path quantifier) graphical examples are depicted in Figure 1. [16, Chap. 5] CTL and LTL support several temporal operators. Some are syntactic sugar and can be represented by a combination of other operators. The work at hand introduces only the unary operators G, F and X used by [18] (see Table 2 and section 5). More operators, especially the expressive binary ones, are described in [16, Chap.