Simulation-Based Verification of Autonomous Controllers using Livingstone PathFinder, Schemes and Mind Maps of Architecture

Download Simulation-Based Verification of Autonomous Controllers using Livingstone PathFinder and more Schemes and Mind Maps Architecture in PDF only on Docsity! Simulation-Based Verification of Autonomous Controllers via Livingstone PathFinder A.E. Lindsey1 and Charles Pecheus ’ QSS Group, NASA Ames Research Center, Moffett Field, CA 94035, U.S.A. tlindseyQptolemy.arc.nasa.gov pecheur@ptolemy . arc. nasa . gov RIACS, NASA Ames Research Center, Moffett Field, CA 94035, U.S.A. Abstract. AI software is often used as a means for providing greater auton- omy to automated systems, capable of coping with harsh and unpredictable environments. Due in part to the enormous space of possible situations that they aim to addrs, autonomous systems pose a serious challenge to tradi- tional test-based verification approaches. Efficient verification approaches need to be perfected before these systems can reliably control critical applications. This publication describes Livingstone PathFinder (LPF), a verification tool for autonomous control software. LPF applies state space exploration algo- rithms to an instrumented testbed, consisting of the controller embedded in a simulated operating environment. Although LPF has focused on NASA’s Liv- ingstone model-based diagnosis system applications, the architecture is mod- ular and adaptable to other systems. This article presents different facets of LPF and experimental results from applying the software to a Livingstone model of the main propulsion feed subsystem for a prototype space vehicle. 1 Introduction Complex decision-making capabilities are increasingly embedded into controllers. Robots substitute for humans in hazardous environments such as distant planets, deep waters or battle fields. This trend is perhaps best exemplified by NASA’s need for autonomous spacecrafts, rovers, airplanes and submarines, capable of executing in harsh and unpredictable environments. Moreover, increased autonomy can be a significant cost saver, even in more accessible regions, by reducing the need for ex- pensive human monitoring. An important trend in autonomous control is model-based autonomy, where control is performed by a generic engine applying automated rea- soning techniques to a high-level model of the system being diagnosed. This is the case for the Livingstone diagnosis system on which the work presented here is based. The idea behind model-based solutions is that the system, in any situation, will be able to infer appropriate actions from the model. While autonomous systems offer promises of improved capabilities at reduced op- erational costs, a serious challenge to traditional test-based verification approaches occurs because of the enormous space of possible scenarios such systems aim to ad- dress. Several factors make testing advanced controllers particularly difficult. First, the range of situations to be tested is significantly larger because the controller itself is more complex and designed to operate over a broad range of unpredictable situ- ations during a prolonged time span. The program implicitly incorporates response scenarios to any combination of events that might occur, instead of relying on human experts to handle off-nominal casks. Second, autonomous systems close the control loops and feature concurrent interacting components. Thus, it becomes more difficult to plug in test harnesses and write test runs that drive the system through a desired behavior. Third, concurrency may introduce hard-bdetect, non-deterministic race conditions. This paper describes a flexible framework for simulating, analyzing and verify- ing autonomous controllers. The proposed approach applies state space exploration algorithms to an instrumented testbed, consisting of the actual control program be- ing analyzed embedded in a simulated operating environment. This framework forms the foundation of Livingstone PathFinder (LPF), a verification tool for autonomous diagnosis applications based on NASA’s Livingstone model-based diagnosis system. LPF accepts as input a Livingstone model of the physical system and a scenario script defining the class of commands and faults to be analyzed. The model is used to perform model-based diagnosis and will be used to simulate the system as well. The tool runs through all acecutions specified in the script, backtracking as necessary to explore alternate routes. At each step, LPF checks for error conditions, such as discrepancies between the actual simulated faults and those reported by diagnosis. If an error is detected, LPF reports the sequence of events that led to the current state. To avoid confusion in reading what follows, it is important to clearly distinguish two similar-sounding but very different notions, that we refer to as faults and errors: - Faults are physical events causing the controlled system to behave abnormally, such as a stuck valve or a sensor emitting erroneous measurements. They typically result from external degradation, and are handled by making the system fault- tolerant. Detecting and identifying faults is the goal of diagnosis systems such as Livingstone. - Errors are improper behaviors of the controller, such as inaccurately identifying the current state of the controlled system. They typically result from unintended flaws in design or configuration, and need to be eliminated before the system is deployed. Detecting and identifying errors is the goal of verification techniques and tools such as LPF. This article discusses Livingstone PathFinder on three different levels: - As a verification approach, LPF applies a combination of model checking and testing principles that we refer to as simulation-based verification. This is the subject of Section 2. - As a pmgram jkamework, LPF provides an infrastructure for applying simulation- based verification to autonomous controllers. This is referred to in Section 4.5. - As a concrete pmgmrn, LPF currently instantiates the framework to applications based on the Livingstone diagnosis system. This constitutes the central part of the paper, mainly discussed in Section 4. A preliminary account of this work was presented in [SI. The remainder of the paper is organized as follows: Section 2 presents the general simulation-based verifi- cation approach; Section 3 provides an overview of Livingstone; Section 4 describes As an example, the following Livingstone model fragments describe a valve com- ponent, extracted from the PITEX model that we used for our experiments (see Section 5). Note that Livingstone is supported by a graphical modeling environment, that generates part of this code automatically. claas ventBeliefValva ventline T U I ~ L M O I ~ ; thraaholdVduaa pnauuticLineIn; ventline'l~ratpre ventLim0ut ; // . . . mty attributes private anum Ilodaljpa inorinal. atuckOp.n, stuckQosad3; statavactor b d a ] ; privata loaeljpa lode; I if (valvaPosition = closad) { ventLina0ut .ambient. upperBound = balodbrashold t vanttinaOut.ubient.lowarBolmd = abovaThreshold k vanttineIn.flow.sign = zaro; 3 // ... more conatraints switch (modal { case nominal: if (pnauraticLineIn = abovaThrashold) valvaPosition = opan; if (pneuuticLinaIn = belod'hrsshold) valvaPosition = closed; ValvaPosition = open; valvePosition = closed; case stuc)lOp.n: case stuckclosed: 1 3 failure a t u c m ( * , stnckOp.n, 1asaLikely) I 1 failure stuckCloud(8, stuckQosod, likaly) I 1 Livingstone performs diagnosis by receiving observations (that is, values of com- mands and observables) and searching for mode values (possibly including faults) that are consistent with these observations. The result is a list of candidates (c1, . . . , c,,), where each candidate c assigns a value c ( m ) to every mode attribute m E M and has a rank p(c) resulting from the faults leading to that candidate. For verifica- tion purposes, we will say that a candidate c matches a state s, written c = s , if they have the same mode values, and that c subsumes s, written c 5 s, if faults of c are also faults of s. Formally, c M s if€ Vm E M c ( m ) = s(m), and c 5 s iff V m E M . c ( m ) E F, * c ( m ) = s(m). Livingstone's best-first search algorithm returns more likely, lower ranked candi- dates first ( p ( ~ ) 5 p(c++l)). In particular, when the nominal case is consistent with Livingstone's observations, the empty (Le. fault-free) candidate (of rank 0) is gener- ated. The search is not necessarily complete: to tune response time, Livingstone has configurable parameters that limit its search in various ways, such as the maximum number of rank of candidates returned. The first generation of Livingstone (in Lisp) flew in space as part of the Remote Agent Experiment (FLAX) demonstration on Deep Space 1 [7]. Livingstone 2 (or L2) has been rewritten in C++ and adds temporal trajectory tracking. A utility program, 12test, provides a command line interface to perform all L2 operations interactively. latest commands can be stored in L2 scenario files for batch replay. A third gener- ation supporting more general constraint types (hybrid discrete/continuous models) is under development. 4 Livingstone PathFinder The Livingstone PathFinder (LPF) program is a simulation-based verification tool for analyzing and verifying Livingstone-based diagnosis applications. LPF executes a Livingstone diagnosis engine, embedded into a simulated environment, and runs that assembly through all executions described by a user-provided scenario script, while checking for various selectable error conditions after each step. The architecture of the LPF tool is depicted in Figure 1. The testbed under analysis consists of the following three components: - Diagnosis: the diagnosis system being analyzed, based on the Livingstone diag- nosis engine, interpreting a model of the physical system. - Simulator: the simulator for the physical system on which diagnosis is performed. Currently this is a second Livingstone engine interpreting a model of the physical system. The models used in the Diagnosis and the Simulator are the same by default but can be different. - Driver: the simulation driver that generates commands and faults according to a user-provided scenario script. The scenario file is essentially a non-deterministic test case whose elementary steps are commands and faults. Search Engine Fig. 1. Livingstone PathFinder Architecture n o m a testing standpoint, the Diagnosis is the implementation under test (IUT), while the Driver and Simulator constitute the test harness. All three components are instrumented so that their execution can be single-stepped in both forward and backward directions. Together, these three elements constitute a non-deterministic state machine, where the non-determinism comes mainly from the scenario script interpreted by the D r i ~ e r . ~ The Search Engine controls the order in which the tree of possible executions of that state machine is explored. In each forward step, LPF performs the following cycle of operations: event := get next step from the Driver apply event to the Simulator if event is a command LPF can also deal with non-determinism in the Simulator. then notify event to the Diagnosis else do nothing (Faults are not directly visible to Diagnosis) obs := get updated observations from the Simulator notify obs to the Diagnosis ask Diagnosis to update its candidates This cycle is repeated dong all steps covered by the scenario, according to the cho- sen search strategy. Before each cycle, the current state is saved (using Livingstone’s built-in checkpointing capability) so it can be later restored to explore alternate routes. User-selectable error conditions, such as consistency between the diagnosis results and the actual state of the Simulator, axe checked at the end of each cycle, and a trace is reported if an error is detected. Since the cycle needs to be repeatedly rolled and unrolled by the backtracking search, it h o t simply be implemented as a program iteration, but instead needs to be simulated using non-trivial bookkeeping of the search trajectory. LPF bears some resemblance to conformance testing, in that it checks whether the Diagnosis, seen as an implementation, “conforms” to the Simulator, seen as a specification. The “conformance” relation, however, is quite dif€erent from classical conformance relations that require the implementation to behave similarly (in some specific precise sense) to the specification (see e.g. [2]). Here, the relation is one of observability, i.e. that the implementation (Diagnmis) can track the state of the spec- ification (Simulator). Even if Simulator and Diagnosis are “equivalent”, in the sense that they operate on identical models of the controlled system, Diagnosis may s t i l l fail to “conform” , because the observation it receives or its own computing limitations prevent accurate tracking. This is indeed the situation we consider by using the same model in both the Simulator and the Diagnosis. 4.1 Scenario Scripts The driver constrains the possible executions to a user-provided combination of cDm- mands and faults, defined in a scenario script. This is essential to reduce the state space to a tractable size: the state space of the PITEX Livingstone model, used in the experiments reported later in this paper, is on the order of states. Although model states do not necessarily map into simulator or diagnosis states, this still gives a fair estimate of the orders of magnitude. The scenario script is essentially a non-deterministic program whose elementary instructions are commands and faults. It can be viewed as an extended test case (or test suite) representing a tree of executions rather than a single sequence (or a set thereof). Scenarios are built from individual commands and faults using sequential, concurrent (interleaved) and choice statements, according to the following syntax: stmt ::= “ewent” ; I { stmt* 3 I mix s t m t (and stmt)* I choose stmt (or stmt)* These operators have their classical semantics from process algebras such as CSP [5], that we will not repeat here. For example, the following scenario defines a sequence of three commands, with one fault chosen among three occurring at some point in the sequence. LPF provides a way to automatically generate a scenario combining all commands and faults of a model following this sequence/choice pattern. More configurable ways to generate scenarios from models or other external sources is an interesting direction for further work. all three components of the testbed and implements the main simulation loop dis- cussed in Section 4 only uses the generic abstractions provided by these interfaces. This provides a flexible, extensible framework for simulation-based verification of di- agnosis applications beyond the purely Livingstone-based setup (both for diagnosis and simulation) shown in Figure 1. Both the Simulator and Diagnosis modules are replaceable by alternative implementations, not necessarily model-based, provided those implementations readily provide the corresponding generic interfaces. Livingstone PathFinder is not available for download but can be obtained free of charge under a NASA licensing agreement. Please contact the authors if interested. 5 Experimental Results The Livingstone diagnosis system is being considered for Integrated Vehicle Health Maintenance (IVHM) to be deployed on NASA’s next-generation space vehicles. In that context, the PITEX experiment has demonstrated the application of Livingstone based diagnosis to the main propulsion feed subsystem of the X-34 space vehicle [l , 81, and LPF has been successfully applied to the PITEX model of X-34. This particular Livingstone model consists of 535 components and 823 attributes, 250 transitions, compiling to 2022 propositional clauses. Two different scenarios have been used to analyze the X-34 model: - The PITEX baseline scenario combines one nominal and 29 failure scenarios, de- rived from those used by the PITEX team for testing Livingstone, as documented in [SI. This scenario covers 89 states. - The random scenario covers a set of commands and faults combined according to the sequence/choice pattern illustrated in Section 4.1. This scenario is an ab- breviated version of the one automatically generated by LPF, and covers 10216 states. We will first discuss scalability and compare different error conditions using depth- first search, then discuss the benefits of heuristic search and finally illustrate two different errors found during the experiments. 5.1 Depth-First Search Our initial experiments involved searching the entire state space, letting the search proceed normally after detecting an error, and reporting any additional errors. We used the depth-first algorithm in this case, since heuristic search offers no advantage when searching through all states of the scenario. Table 1 summarizes our depth-fist search statistics. It shows that LPF covered the PITEX baseline and random scenario at an average rate of 51 states per minute (on a 500MHz Sun workstation). When searching for candidate matching, LPF reported an excessive number of errors, most of which were triuid, in the following sense: when a fault produces no immediately observable effect, Livingstone diagnosis does not infer any abnormal behavior and reports the empty candidate. For example, although a valve may be stuck, the fault will stay unnoticed until a command to that valve fail to produce the desired change of position. While these errors are indeed missed diagnoses, experience Table 2. Comparison of Heuristic vs. depth-&st search strategy lmax. depthlcondition' 1 time ]stateslstates/min DFS 1 16 I CS 102:55:381 8648 I 49 cc 1 5 38 DFS I 16 I CM 100:00151 17 I 68 2o I BFS 2 00:00:13 4 l c c l 1 I /OO:OO:lll 4 I 4 See Table 1 5.3 Example Scenario 1 Our first example involves the PITEX baseline scenario, and was performed with an earlier version of L2 in which, as it turns out, the checkpointing functionality used by LPF was flawed. The scenario involves a double fault, where a valve sv31 (on a liquid oxygen venting line) gets stuck and a micro-switch sensing the position of that valve fails at the same time. The sequence of events is as follows: 1. A command open is issued to sv31. 2. A command close is issued to sv31. 3. The open microswitch of sv31 breaks. 4. sv31 fails in stuck-open position. The microswitch fault remains undetected (Livingstone still reports the empty candidate after event 3), however the stuck valve causes a fault diagnosis: after event 4, Livingstone reports the following candidates (the number before the X sign is the time of occurrence of the presumed fault): Cmdidata 0 ) Cmdidat. 1) Candidat. 2) Candidat. 3) 5tta.t .rrOl .rod~TraP.ition=stuckOpon:Z -tt~~t.rrOl.rod~Truuition=~tuckClo~~d:2 -~~~t.~v31.md~Tra~ition=stuckClo~~d:3 -tt.it.rrOl.mod.Truition=.tuc~:Z 3tt~st.rrOl.rod.Trmaition=~tuckClo**d:2 5ttt..t.forsrrdlo2.rpl.v.~d~Tra~.iti~=lmhrounFdt:5 -east .forsudln2.rplsr.rod.Truuition=unknounFdt: 5 3tLm.t. f orrrardI.02 .rpl.v.lod~Trm.itian=lmhrormfdt : 5 W t . ~ s t . s v 3 1 . r o d ~ T r u u i t i o n = ~ t u c ~ : 5 -tL..t..r03..v.rod.huuition=stuc~o.*d:3 31t.st..r03.op.nll..rod.Trr.n.ition~a~t~:3 -tL.mt ..~..v.mod.ha~.ition-.tuctClo..d:3 -ttt..t..r03.op.nna.lod*Truuition~a~t~:3 Candidat. 4) Candidat. 5) Candidate 6 ) Candidat. 7 ) Cmdidat. 8) Candidat. 9) At this point, LPF reports a candidate-matching error, indicating that none of the Livingstone candidates match the modes from the simulator. The fault is detected (otherwise no faulty candidates would be generated), but incorrectly diagnosed (note that candidate 7 subsumes, but does not match, the actual faults). At this point the data seems to suggest that Livingstone is not properly generating all valid candidates. To further interpret and confirm the results reported by LPF, we ran 12test on the L2 scenario associated with this error. The following list of candidates were generated, which differs from those obtained above via LPF: Candidate 0 ) Candidate 1) Candidate 2) Cmdidat. 3) Weat.rrOl.modeTransition=stnc~0p.n:2 ~~st.rrOl.aodeha~.ition=atnck~n:2 m a s t .f~rrdlo2.aodeTr~itionsunlmoPnf.ul+:5 31to.t .forrrrrdlo2.aode,Tnn.ition~o~a~t :5 4tteat.1~31 .~v.modeh.anaition=stuck0p.n:5 W e s t .f o r r r u d l o 2 . m o d s T r ~ i t i o n ~ o ~ n ~ t : 5 - ~ e a t . f ~ u ~ o 2 . a o d e h . a ~ . i t i o n - ~ o ~ a ~ t : 5 Weat.av31.av.rodsTraPaition=atnc~n:5 Cmdidate 4) Candidate 5 ) Candidate 6) Cmdidatm 7 ) Although none of these match the actual faults either (i.e. there is indeed a candidate-matching error in this state), the difference also shows that the results from LPF were flawed. Further analysis revealed that the discrepancy originated from a checkpointing bug. In particular, Livingstone did not properly restore its internal con- straint network when restoring checkpoints, resulting in a corrupted internal state and incorrect diagnosis results. With our assistance, the error was localized and resolved in a new release of the Livingstone program. 5.4 Example Scenario 2 The second example considers one of the five errors reported using Candidate sub- sumption on the Random scenario. It involves a solenoid valve, sv02, which sends pressurized helium into a propellant tank. A command close is issued to the valve, but the valve fails and remains open-in LPF terms, a fault is injected in the simu- lator. The following sample output lists the candidates reported by Livingstone after the fault occurs in sv02: Candidate 0 ) Candidata 1) Candidate 2) Cmdidat. 3) Candidatm 4) m e a t . arOZ.op.nlls.aodoh.ritian=i.ultJ:3 3.teat.ar02.op.~.aode~riti~~a~ty:3 m e a t . arOZ.op.nl(..rodoTruiti~~~~t~: 3 -tteat.~rO2.op.nlla.~eTrrition~a~ty:3 -tteat.arO2.rpiav.rodsTr.nsition~o~:4 The injected fault, test. svO2 .rplsv .mode=stuckOpen, is detected (otherwise no faulty candidates would be generated) but incorrectly diagnosed: none of these can- didates matches or subsumes the correct fault. The first four candidates consist of a faulty open microswitch sensor at different time steps (microswitches report the valve’s position). The last candidate consists of an unknown fault mode. The L2 scenario corresponding to this error was replayed in 12tes t and produced identical results, confirming the validity of the results from LPF. Further analysis by applica- tion specialists revealed that fault ranks in the X-34 model needed retuning, which resolved the problem.