Temporal-Logic Based Runtime Observer Pairs for System Health Management of Real-Time Systems⋆ Thomas Reinbacher1 , Kristin Y. Rozier2 , and Johann Schumann3 1
2
Vienna University of Technology, Austria,
[email protected] NASA Ames Research Center, Moffett Field, CA, USA,
[email protected] 3 SGT, Inc., NASA Ames, Moffett Field, CA, USA,
[email protected] Abstract. We propose a real-time, Realizable, Responsive, Unobtrusive Unit (rt-R2U2) to meet the emerging needs for System Health Management (SHM) of new safety-critical embedded systems like automated vehicles, Unmanned Aerial Systems (UAS), or small satellites. SHM for these systems must be able to handle unexpected situations and adapt specifications quickly during flight testing between closely-timed consecutive missions, not mid-mission, necessitating fast reconfiguration. They must enable more advanced probabilistic reasoning for diagnostics and prognostics while running aboard limited hardware without affecting the certified on-board software. We define and prove correct translations of two real-time projections of Linear Temporal Logic to two types of efficient observer algorithms to continuously assess the status of the system. A synchronous observer yields an instant abstraction of the satisfaction check, whereas an asynchronous observer concretizes this abstraction at a later, a priori known, time. By feeding the system’s real-time status into a statistical reasoning unit, e.g., based on Bayesian networks, we enable advanced health estimation and diagnosis. We experimentally demonstrate our novel framework on real flight data from NASA’s Swift UAS. By on-boarding rt-R2U2 aboard an existing FPGA already built into the standard UAS design and seamlessly intercepting sensor values through read-only observations of the system bus, we avoid system integration problems of software instrumentation or added hardware. The flexibility of our approach with regard to changes in the monitored specification is not due to the reconfigurability offered by FPGAs; it is a benefit of the modularity of our observers and would also be available on non-reconfigurable hardware platforms such as ASICs.
1
Introduction
Autonomous and automated systems, including Unmanned Aerial Systems (UAS), rovers, and satellites, have a large number of components, e.g., sensors, actuators, and software, that must function together reliably at mission time. System Health Management (SHM) [17] can detect, isolate, and diagnose faults and possibly initiate recovery activities on such real-time systems. Effective SHM requires assessing the status of the system with respect to its specifications and estimating system health during mission time. Johnson et al. [17, Ch.1] recently highlighted the need for new, formal-methods based capabilities for modeling complex relationships among different sensor data and reasoning about timing-related requirements; computational expense prevents the current best methods for SHM from meeting operational needs. ⋆
A full version with appendices containing full proofs of correctness for all observer algorithms is available at http://research.kristinrozier.com/TACAS14.html. This work was supported in part by the Austrian Research Agency FFG, grant 825891, and NASA grant NNX08AY50A.
We need a new SHM framework for real-time systems like the Swift [16] electric UAS (see Fig. 1), developed at NASA Ames. SHM for such systems requires: R ESPONSIVENESS : the SHM framework must continuously monitor the system. Deviations from the monitored specifications must be detected within a tight and a priori known time bound, enabling mitigation or rescue measures, e.g., a controlled emergency landing to avoid damage on the ground. Reporting intermediate status and satisfaction of timed requirements as early as possible is required for enabling responsive decision-making. U NOBTRUSIVENESS : the SHM framework must not alter crucial properties of the system including functionality (not change behavior), certifiability (avoid re-certification of flight software/hardware), timing (not interfere with timing guarantees), and tolerances (not violate size, weight, power, or telemetry bandwidth constraints). Utilizing commercialoff-the-shelf (COTS) and previously proven system components is absolutely required to meet today’s tight time and budget constraints; adding the SHM framework to the system must not alter these components as changes that require them to be re-certified cancel out the benefits of their use. Our goal is to create the most effective SHM capability with the limitation of read-only access to the data from COTS components. R EALIZABILITY: the SHM framework must be usable in a plug-and-play manner by providing a generic interface to connect to a wide variety of systems. The specification language must be easily understood and expressive enough to encode e.g. temporal relationships and flight rules. The framework must adapt to new specifications without a lengthy re-compilation. We must be able to efficiently monitor different requirements during different mission stages, like takeoff, approach, measurement, and return. 1.1
Related Work
Existing methods for Runtime Verification (RV) [4] assess system status by automatically generating, mainly software-based, observers to check the state of the system against a formal specification. Observations in RV are usually made accessible via software instrumentation [15]; they report only when a specification has passed or failed. Such instrumentation violates our requirements as it may make re-certification of the system onerous, alter the original timing behavior, or increase resource consumption [23]. Also, reporting only the outcomes of specifications violates our responsiveness requirement. Systems in our applications domain often need to adhere to timing-related rules like: after receiving the command ’takeoff’ reach an altitude of 600f t within five minutes. These flight rules can be easily expressed in temporal logics; often in some flavor of linear temporal logic (LTL), as studied in [7]. Mainly due to promising complexity results [6, 11], restrictions of LTL to its past-time fragment have most often been used for RV. Though specifications including past time operators may be natural for some other domains [19], flight rules require future-time reasoning. To enable more intuitive specifications, others have studied monitoring of future-time claims; see [22] for a survey and [5, 11, 14, 21, 27, 28] for algorithms and frameworks. Most of these observer algorithms, however, were designed with a software implementation in mind and require a powerful computer. There are many hardware alternatives, e.g. [12], however all either resynthesize monitors from scratch or exclude checking real-time properties [2]. Our unique approach runs the logic synthesis tool once to synthesize as many real-time observer blocks as we can fit on our platform, e.g., FPGA or ASIC; our Sec. 4.1 only interconnects these blocks. Others have proposed using Bayesian inference 2
techniques [10] to estimate the health of a system. However, modeling timing-related behavior with dynamic Bayesian networks is very complex and quickly renders practical implementations infeasible. 1.2
Approach and Contributions
We propose a new paired-observer SHM framework allowing systems like the Swift UAS to assess their status against a temporal logic specification while enabling advanced health estimation, e.g., via discrete Bayesian networks (BN) [10] based reasoning. This novel combination of two approaches, often seen as orthogonal to each other, enables us to check timing-related aspects with our paired observers while keeping BN health models free of timing information, and thus computationally attractive. Essentially, we can enable better real-time SHM by utilizing paired temporal observers to optimize BNbased decision making. Following our requirements, we call our new SHM framework for real-time systems a rt-R2U2 (real-time, Realizable, Responsive, Unobtrusive Unit). Our rt-R2U2 synthesizes a pair of observers for a real-time specification ϕ given in Metric Temporal Logic (MTL) [1] or a specialization of LTL for mission-time bounded characteristics, which we define in Sec. 2. To ensure R ESPONSIVENESS of our rt-R2U2, we design two kinds of observer algorithms in Sec. 3 that verify whether ϕ holds at a discrete time and run them in parallel. Synchronous observers have small hardware footprints (max. eleven two-input gates per operator; see Theorem 3 in Sec. 4) and return an instant, three-valued abstraction {true, false, maybe}) of the satisfaction check of ϕ with every new tick of the Real Time Clock (RTC) while their asynchronous counterparts concretize this abstraction at a later, a priori known time. This unique approach allows us to signal early failure and acceptance of every specification whenever possible via the asynchronous observer. Note that previous approaches to runtime monitoring signal only specification failures; signaling acceptance, and particularly early acceptance is unique to our approach and required for supporting other system components such as prognostics engines or decision making units. Meanwhile, our synchronous observer’s three-valued output gives intermediate information that a specification has not yet passed/failed, enabling probabilistic decision making via a Bayesian Network as described in [26]. We implement the rt-R2U2 in hardware as a self-contained unit, which runs externally to the system, to support U NOBTRUSIVENESS; see Sec. 4. Safety-critical embedded systems often use industrial, vehicle bus systems, such as CAN and PCI, interconnecting hardware and software components, see Fig 1. Our rt-R2U2 provides generic read-only interfaces to these bus systems supporting our U NOBTRUSIVENESS requirement and sidestepping instrumentation. Events collected on these interfaces are time stamped by a RTC; progress of time is derived from the observed clock signal, resulting in a discrete time base N0 . Events are then processed by our runtime observer pairs that check whether a specification holds on a sequence of collected events. Other RV approaches for on-the-fly observers exhibit high overhead [13, 20, 24] or use powerful database systems [3], thus, violate our requirements. To meet our R EALIZABILITY requirement, we design an efficient, highly parallel hardware architecture, yet keep it programmable to adapt to changes in the specification. Unlike existing approaches, our observers are designed with an efficient hardware implementation in mind, therefore, avoid recursion and expensive search through memory and aim at maximizing the benefits of the parallel nature of hardware. We synthesize 3
Swift UAS
Laser Altimeter
rtR2U2
Common Bus Interface
Health Model (BN) Specification (ϕ)
Higher Level Reasoning en ⊧ {ϕ1 , .., ϕn }
Runtime Observers
health estimation
...
system status
Flight Computer
event updates
Baro Altimeter
n
0
...
Radio Link
IMU & GPS
Event Capture & RTC
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
en ⊧ (alt ≥ 600f t) en ⊧ (pitch ≥ 5○ ) en ⊧ (cmd == takeoff ) Fig. 1. rt-R2U2: An instance of our SHM framework rt-R2U2 for the NASA Swift UAS. Swift subsystems (top): The laser altimeter maps terrain and determines elevation above ground by measuring the time for a laser pulse to echo back to the UAS. The barometric altimeter determines altitude above sea level via atmospheric pressure. The inertial measurement unit (IMU) reports velocity, orientation (yaw, pitch, and roll), and gravitational forces using accelerometers, gyroscopes, and magnetometers. Running example (bottom): predicates over Swift UAS sensor data on execution e; ranging over the readings of the barometric altimeter, the pitch sensor, and the takeoff command received from the ground station; n is the time stamp as issued by the Real-Time-Clock.
rt-R2U2 once and generate a configuration, similar to machine code, to interconnect and configure the static hardware observer blocks of rt-R2U2, adapting to new specifications without running CAD or compilation tools like previous approaches. UAS have very limited bandwidth constraints; transferring a lightweight configuration is preferable to transferring a new image for the whole hardware design. The checks computed by these runtime observers represent the system’s status and can be utilized by a higher level reasoner, such as a human operator, Bayesian network, or otherwise, to compute a health estimation, i.e., a conditional probability expressing the belief that a certain subsystem is healthy, given the status of the system. In this paper, we compute these health estimations by adapting the BN-based inference algorithms of [10] in hardware. Our contributions include synthesis and integration of the synchronous/asynchronous observer pairs, a modular hardware implementation, and execution of a proof-of-concept rt-R2U2 running on a self-contained Field Programmable Gate Array (FPGA) (Sec. 5).
2
Real-time projections of LTL
MTL replaces the temporal operators of LTL with operators that respect time bounds [1]. Definition 1 (Discrete-Time MTL). For atomic proposition σ ∈ Σ, σ is a formula. Let time bound J = [t, t′ ] with t, t′ ∈ N0 . If ϕ and ψ are formulas, then so are: ¬ϕ ∣ ϕ ∧ ψ ∣ ϕ ∨ ψ ∣ ϕ → ψ ∣ X ϕ ∣ ϕ UJ ψ ∣ ◻J ϕ ∣ ◇J ϕ. Time bounds are specified as intervals: for t, t′ ∈ N0 , we write [t, t′ ] for the set {i ∈ N0 ∣ t ≤ i ≤ t′ }. We use the functions min, max, dur, to extract the lower time bound (t), the 4
upper time bound (t′ ), and the duration (t′ − t) of J. We define the satisfaction relation of an MTL formula as follows: an execution e = (sn ) for n ≥ 0 is an infinite sequence of states. For an MTL formula ϕ, time n ∈ N0 and execution e, we define ϕ holds at time n of execution e, denoted en ⊧ ϕ, inductively as follows: en ⊧ true is true, en ⊧ σ iff σ holds in sn , en ⊧ ¬ϕ iff en ⊭ ϕ, n n n e ⊧ ϕ ∧ ψ iff e ⊧ ϕ and e ⊧ ψ, en ⊧ X ϕ iff en+1 ⊧ ϕ, en ⊧ ϕ UJ ψ iff ∃i(i ≥ n) ∶ (i − n ∈ J ∧ ei ⊧ ψ ∧ ∀j(n ≤ j < i) ∶ ej ⊧ ϕ). With the dualities ◇J ϕ ≡ true UJ ϕ and ¬ ◇J ¬ϕ ≡ ◻J ϕ we arrive at two additional operators: ◻J ϕ (ϕ is an invariant within the future interval J) and ◇J ϕ (ϕ holds eventually within the future interval J). In order to efficiently encode specifications in practice, we introduce two special cases of ◻J ϕ and ◇J ϕ: τ ϕ ≡ ◻[0,τ ] ϕ (ϕ is an invariant within the next τ time units) and τ ϕ ≡ ◇[0,τ ] ϕ (ϕ holds eventually within the next τ time units). For example, the flight rule from Sec. 1, “After receiving the takeoff command reach an altitude of 600f t within five minutes,” is efficiently captured in MTL by (cmd == takeoff) → 5 (alt ≥ 600f t), assuming a time-base of one minute and the atomic propositions (alt ≥ 600f t) and (cmd == takeoff) as in Fig. 1. Systems in our application domain are usually bounded to a certain mission time. For example, the Swift UAS has a limited air-time, depending on the available battery capacity and predefined waypoints. We capitalize on this property to intuitively monitor standard LTL requirements using a mission-time bounded projection of LTL. Definition 2 (Mission-Time LTL). For a given LTL formula ξ and a mission time tm ∈ N0 , we denote by ξm the mission-time bounded equivalent of ξ, where ξm is obtained by replacing every ◻ϕ, ◇ϕ, and ϕ U ψ operator in ξ by the τ ϕ, τ ϕ, and ϕ UJ ψ operators of MTL, where J = [0, tm ] and τ = tm . Inputs to rt-R2U2 are time-stamped events, collected incrementally from the system. Definition 3 (Execution Sequence). An execution sequence for an MTL formula ϕ, denoted by ⟨Tϕ ⟩, is a sequence of tuples Tϕ = (v, τe ) where τe ∈ N0 is a time stamp and v ∈ {true, false, maybe} is a verdict. We use a superscript integer to access a particular element in ⟨Tϕ ⟩, e.g., ⟨Tϕ0 ⟩ is the first element in execution sequence ⟨Tϕ ⟩. We write Tϕ .τe to access τe and Tϕ .v to access v of such an element. We say Tϕ holds if Tϕ .v is true and Tϕ does not hold if Tϕ .v is false. For a given execution sequence ⟨Tϕ ⟩ = ⟨Tϕ0 ⟩, ⟨Tϕ1 ⟩, ⟨Tϕ2 ⟩, ⟨Tϕ3 ⟩, . . . , the tuple accessed by ⟨Tϕi ⟩ corresponds to a section of an execution e as follows: for all times n ∈ [⟨Tϕi−1 ⟩.τe + 1, ⟨Tϕi ⟩.τe ], en ⊧ ϕ in case ⟨Tϕi ⟩.v is true and en ⊭ ϕ in case ⟨Tϕi ⟩.v is false. In case ⟨Tϕi ⟩ is maybe, neither en ⊧ ϕ nor en ⊭ ϕ is defined. In the remainder of this paper, we will frequently refer to execution sequences collected from the Swift UAS as shown in Fig. 1. The predicates shown are atomic propositions over sensor data in our specifications and are sampled with every new time stamp n issued by the RTC. For example, ⟨Tpitch≥5○ ⟩ = ((false, 0), (false, 1), (false, 2), (true, 3), . . . , (true, 17), (true, 18)) describes en ⊧ (pitch ≥ 5○ ) sampled over n ∈ [0, 18] and ⟨Tpitch≥5○ ⟩ holds 19 elements. 5
3
Asynchronous and Synchronous Observers
The problem of monitoring a real-time specification has been studied extensively in the past; see [8, 22] for an overview. Solutions include: (a) translating the temporal formula into a finite-state automaton that accepts all the models of the specification [11,12,14,28], (b) restricting MTL to its safety fragment and waiting until the operators’ time bounds have elapsed to decide the truth value afterwards [5, 21], and (c) restricting LTL to its past-time fragment [6, 11, 24]. Compiling new observers to automata as in (a) requires re-running the logic synthesis tool to yield a new hardware observer, in automaton or autogenerated VHDL code format as described in [12], which may take dozens of minutes to complete, violating the R EALIZABILITY requirement. Observers generated by (b) are in conflict with the R ESPONSIVENESS requirement and (c) do not natively support flight rules. Our observers provide U NOBTRUSIVENESS via a self-contained hardware implementation. To enable such an implementation, our design needs to refrain from dynamic memory, linked lists, and recursion – commonly used in existing software-based observers, however, not natively available in hardware. Our two types of runtime observers differ in the times when new outputs are generated and in the resource footprints required to implement them. A synchronous (timetriggered) observer is trimmed towards a minimalistic hardware footprint and computes a three-valued abstraction of the satisfaction check for the specification with each tick of the RTC, without considering events happening after the current time. An asynchronous (event-triggered) observer concretizes this abstraction at a later, a priori known, time and makes use of synchronization queues to take events into account that occur after the current time.1 Our novel parallel composition of these two observers updates the status of the system at every tick of the RTC, yielding great responsiveness. An inconclusive answer when we can’t yet know true/false is still beneficial as the higher-level reasoning part of our rt-R2U2 supports reasoning with inconclusive inputs. This allows us to derive an intermediate estimation of system health with the option to initiate fault mitigation actions even without explicitly knowing all inputs. If exact reasoning is required, we can re-evaluate system health when the asynchronous observer provides exact answers. In the remainder of this section, we discuss2 both asynchronous and synchronous observers for the operators ¬ ϕ, ϕ ∧ ψ, τ ϕ, ◻J ϕ, and ϕ UJ ψ. Informally, an MTL observer is an algorithm that takes execution sequences as input and produces another execution sequence as output. For a given unary operator ●, we say that an observer algorithm implements en ⊧ ● ϕ, iff for all execution sequences ⟨Tϕ ⟩ as input, it produces an execution sequence as output that evaluates en ⊧ ● ϕ (analogous for binary operators). 3.1 Asynchronous Observers The main characteristic of our asynchronous observers is that they are evaluated with every new input tuple and that for every generated output tuple T we have that T.v ∈ {true, false} and T.τe ∈ [0, n]. Since verdicts are exact evaluations of a future-time specification ϕ for each clock tick they may resolve ϕ for clock ticks prior to the current time n if the information required for this resolution was not available until n. 1
2
Similar terms have been used by others [9] to refer to monitoring with pairs of observers that do not update with the RTC, incur delays dangerous to a UAS, and require system interaction that violates our requirements (Sec. 1). Proofs of correctness for every observer algorithm appear in the Appendix.
6
Our observers distinguish two types of transitions of the signals described by execution sequences. We say transition of execution sequence ⟨Tϕ ⟩ occurs at time n = of ⟨Tϕi ⟩.τe + 1 iff (⟨Tϕi ⟩.v ⊕ ⟨Tϕi+1 ⟩.v) ∧ ⟨Tϕi+1 ⟩.v holds. Similarly, we say transition execution sequence ⟨Tϕ ⟩ occurs at time n = ⟨Tϕi ⟩.τe + 1 iff (⟨Tϕi ⟩.v ⊕ ⟨Tϕi+1 ⟩.v) ∧ ⟨Tϕi ⟩.v holds (⊕ denotes the Boolean exclusive-or). For example, transitions and of ⟨Tpitch≥5○ ⟩ in Fig. 1 occur at times 3 and 11, respectively. Negation (¬ ϕ) The observer for ¬ ϕ, as stated in Alg. 1, is straightforward: for every input Tϕ we negate the truth value of Tϕ .v. The observer generates (. . . , (true, 2), (false, 3), . . . ). Invariant within the Next τ Time Stamps ( τ ϕ) An observer for τ ϕ requires registers m↑ϕ and mτs with domain N0 : m↑ϕ holds the time stamp of the latest transition of ⟨Tϕ ⟩ whereas mτs holds the start time of the next tuple in ⟨Tϕ ⟩. For the observer in Alg. 2, the check m ≤ (Tϕ .τe − τ ) in line 8 tests whether ϕ held for at least the previous τ time stamps. To illustrate the algorithm, consider an observer for ○ 5 (pitch ≥ 5 ) and the execution in Fig. 1. At time n = 0, we have m↑ϕ = 0 and since 0 ⟨Tpitch≥5○ ⟩ does not hold the output is (false, 0). Similarly, the outputs for n ∈ [1, 2] are (false, 1) and (false, 2). At time n = 3, a transition of ⟨Tpitch≥5○ ⟩ occurs, thus m↑ϕ = 3. Since the check in line 8 does not hold, the algorithm does not generate a new output, i.e., returns ( , ) designating output is delayed until a later time, which repeats at times n ∈ [4, 7]. At n = 8, the check in line 8 holds and the algorithm returns (true, 3). 11 Likewise, the outputs for n ∈ [9, 10] are (true, 4) and (true, 5). At n = 11, ⟨Tpitch≥5 ○⟩ does not hold and the algorithm outputs (false, 11). We note the ability of the observer to re-synchronize its output with respect to its inputs and the RTC. For n ∈ [8, 10], outputs are given for a time prior to n, however, at n = 11 the observer re-synchronizes: the output (false, 11) signifies that en ⊭ 5 (pitch ≥ 5○ ) for n ∈ [6, 11]. By the equivalence τ ϕ ≡ ¬ τ ¬ϕ, we immediately arrive at an observer for τ ϕ from Alg. 2 by negating both the input and the output tuple. Invariant within Future Interval (◻J ϕ) The observer for ◻J ϕ, as stated in Alg. 4, builds on an observer for τ ϕ and makes use of the equivalence τ ϕ ≡ ◻[0,τ ] ϕ. Intuitively, the observer for τ ϕ returns true iff ϕ holds for at least the next τ time units. We can thus construct an observer for ◻J ϕ by reusing the algorithm for τ ϕ, assigning τ = dur(J) and shifting the obtained output by min(J) time stamps into the past. From the equivalence ◇J ϕ ≡ ¬ ◻J ¬ϕ, we can immediately derive an observer for ◇J ϕ from the observer for ◻J ϕ. To illustrate the algorithm, consider an observer for ◻5,10 (alt ≥ 600f t) over the execution in Fig. 1. For n ∈ [0, 4] the algorithm returns 0...4 ( , ), since (⟨Talt≥600f t ⟩.τe − 5) ≥ 0 (line 3 of Alg. 4) does not hold. At n = 5 the underlying observer for 5 (alt ≥ 600f t) returns (false, 5), which is transformed (by line 4) into the output (false, 0). For similar arguments, the outputs for n ∈ [6, 9] are (false, 1), (false, 2), (false, 3), and (false, 4). At n ∈ [10, 14], the observer for 5 (alt ≥ 600f t) returns ( , ). At n = 15, 5 (alt ≥ 600f t) yields (true, 10), which is transformed (by line 4) into the output is (true, 5). Note also that X ϕ ≡ ◻[1,1] ϕ. The remaining observers for the binary operators ϕ ∧ ψ and ϕ UJ ψ take tuples (Tϕ , Tψ ) as inputs, where Tϕ is from ⟨Tϕ ⟩ and Tψ is from ⟨Tψ ⟩. Since ⟨Tϕ ⟩ and ⟨Tψ ⟩ are execution sequences produced by two different observers, the two elements of the 7
input tuple (Tϕ , Tψ ) are not necessarily generated at the same time. Our observers for binary MTL operators thus use two FIFO-organized synchronization queues to buffer parts of ⟨Tϕ ⟩ and ⟨Tψ ⟩, respectively. For a synchronization queue q we denote by q =() its emptiness and by ∣q∣ its size.
Algorithm 1 Observer for ¬ ϕ. 1: At each new input Tϕ : 2: Tξ ← (¬ Tϕ .v, Tϕ .τe ) 3: return Tξ
Algorithm 2 Observer for mτs = 0. 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14:
τ
ϕ. Initially, m↑ϕ
At each new input Tϕ : Tξ ← Tϕ if transition of Tξ occurs then m↑ϕ ← mτs end if mτs ← Tϕ .τe + 1 if Tξ holds then if m↑ϕ ≤ (Tξ .τe − τ ) holds then Tξ .τe ← Tξ .τe − τ else Tξ ← ( , ) end if end if return Tξ
Algorithm 4 Observer for ◻J ϕ. 1: 2: 3: 4: = 5: 6: 7: 8:
At each new input Tϕ : Tξ ← dur(J) Tϕ if (Tξ .τe − min(J) ≥ 0) then Tξ .τe ← Tξ .τe − min(J) else Tξ ← ( , ) end if return Tξ
Algorithm 5 Observer for ϕ UJ ψ. Initially, mpre = m↑ϕ = 0, m↓ϕ = −∞, and p = false.
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: Algorithm 3 Observer for ϕ ∧ ψ. 12: 1: At each new input (Tϕ , Tψ ): 13: 2: if Tϕ holds and Tψ holds and qϕ ≠ () holds and 14: qψ ≠ () holds then 15: 3: Tξ ← (true, min(Tϕ .τe , Tψ .τe )) 16: 4: else if ¬Tϕ holds and ¬Tψ holds and qϕ ≠ () holds 17: and qψ ≠ () holds then 18: 5: Tξ ← (false, max(Tϕ .τe , Tψ .τe )) 19: 6: else if ¬Tϕ holds and qϕ ≠ () holds then 20: 7: Tξ ← (false, Tϕ .τe ) 21: 8: else if ¬Tψ holds and qψ ≠ () holds then 22: 9: Tξ ← (false, Tψ .τe ) 23: 10: else 24: 11: Tξ ← ( , ) 25: 12: end if 26: 13: dequeue(qϕ , qψ , Tξ .τe ) 27: 14: return Tξ 28:
At each new input (Tϕ , Tψ ) in lockstep mode: if transition of Tϕ occurs then m↑ϕ ← τe − 1 mpre ← −∞ end if if transition of Tϕ occurs and Tψ holds then Tϕ .v, p ← true, true m↓ϕ ← τe end if if Tϕ holds then if Tψ holds then if (m↑ϕ + min(J) < τe ) holds then mpre ← τe return (true, τe − min(J)) else if p holds then return (false, m↓ϕ ) end if else if (mpre + dur(J) ≤ τe ) holds then return (false, max(m↑ϕ , τe − max(J))) end if else p ← false if (min(J) = 0) holds then return (Tψ .v, τe ) end if return (false, τe ) end if return ( , )
Conjunction (ϕ ∧ ψ) The observer for ϕ ∧ ψ, as stated in Alg. 3, reads inputs (Tϕ , Tψ ) from two synchronization queues, qϕ and qψ . Intuitively, the algorithm follows the rules for conjunction in Boolean logic with additional emptiness checks on qϕ and qψ . The procedure dequeue(qϕ , qψ , Tξ .τe ) drops all entries Tϕ in qϕ for which the following holds: Tϕ .τe ≤ Tξ .τe (analogous for qψ ). To illustrate the algorithm, consider an observer for 5 (alt ≥ 600f t) ∧ (pitch ≥ 5○ ) and the execution in Fig. 1. 8
For n ∈ [0, 9] the two observers for the involved subformulas immediately output (false, n). For n ∈ [10, 14], the observer for 5 (alt ≥ 600f t) returns ( , ), while in the meantime, the atomic proposition (pitch ≥ 5○ ) toggles its truth value several times, i.e., (true, 10), (false, 11), (false, 12), (true, 13), (false, 14). These tuples need to be buffered in queue qpitch≥5○ until the observer for 5 (alt ≥ 600f t) generates its next output, i.e., (true, 10) at n = 15. We apply the function aggregate(⟨Tϕ ⟩), which repeatedly replaces two consecutive elements ⟨Tϕi ⟩, ⟨Tϕi+1 ⟩ in ⟨Tϕ ⟩ by ⟨Tϕi+1 ⟩ iff ⟨Tϕi ⟩.v = ⟨Tϕi+1 ⟩.v, to the content of qpitch≥5○ once every time an element is added to qpitch≥5○ . Therefore, at n = 15: qpitch≥5○ = ((true, 10), (false, 12), (true, 13), (false, 14), (true, 15)) and q 5 (alt≥600f t) = ((true, 10)). The observer returns (true, 10) (line 3) and dequeue(qϕ , qψ , 10) yields: qpitch≥5○ = ((false, 12), (true, 13), (false, 14), (true, 15)) and q 5 (alt≥600f t) = (). Until within Future Interval (ϕ UJ ψ) The observer for ϕ UJ ψ, as stated in Alg. 5, reads inputs (Tϕ , Tψ ) from two synchronization queues and makes use of a Boolean flag p and three registers m↑ϕ , m↓ϕ , and mpre with domain N0 ∪ {−∞}: m↑ϕ (m↓ϕ ) holds the time stamp of the latest transition ( transition) of ⟨Tϕ ⟩ and mpre holds the latest time stamp where the observer detected ϕ UJ ψ to hold. Input tuples (Tϕ , Tψ ) for the observer are read from synchronization queues in a lockstep mode: (Tϕ , Tψ ) is split into (Tϕ′ , Tψ′ ), where Tϕ′ .τe = Tψ′ .τe and the time stamp Tϕ′′ .τe of the next tuple (Tϕ′′ , Tψ′′ ) is Tϕ′ .τe + 1. This ensures that the observer outputs only a single tuple at each run and avoids output buffers, which would account for additional hardware resources (see correctness proof in the Appendix for a discussion). Intuitively, if Tϕ does not hold (lines 22-26) the observer is synchronous to its input and immediately outputs (false, Tϕ .τe ). If Tϕ holds (lines 11-20) the time stamp n′ of the output tuple is not necessarily synchronous to the time stamp Tϕ .τe of the input anymore, however, bounded by (Tϕ .τe − max(J)) ≤ n′ ≤ Tϕ .τe (see Lemma “unrolling” in the Appendix). To illustrate the algorithm, consider an observer for (pitch ≥ 5○ ) U[5,10] (alt ≥ 600f t) over the execution in Fig. 1. At time n = 0, we have mpre = 0, m↑ϕ = 0, and m↓ϕ = −∞ 0 and since ⟨Tpitch≥5 ○ ⟩ does not hold, the observer outputs (false, 0) in line 26. The outputs for n ∈ [1, 2] are (false, 1) and (false, 2). At time n = 3, a transition of ⟨Tpitch≥5○ ⟩ 3 occurs, thus we assign m↑ϕ = 2 and mpre = −∞ (lines 3 and 4). Since ⟨Tpitch≥5 ○ ⟩ holds 3 and ⟨Talt≥600f t ⟩ does not hold, the predicate in line 18 is evaluated, which holds and the algorithm returns ⟨false, max(2, 3−10)⟩ = (false, 2). Thus, the observer does not yield a new output in this case, which repeats for times n ∈ [4, 9]. At time n = 10, a transition of ⟨Talt≥600f t ⟩ occurs and the predicate in line 12 is evaluated. Since (2 + 5) < 10 holds, the algorithm returns (true, 5), revealing that en ⊧ (pitch ≥ 5○ ) U[5,10] (alt ≥ 600f t) 11 for n ∈ [3, 5]. At time n = 11, a transition of ⟨Tpitch≥5○ ⟩ occurs and since ⟨Talt≥600f t⟩ 11 holds, p and the truth value of the current input ⟨Tpitch≥5○ ⟩.v are set true and m↓ϕ = 11. Again, line 12 is evaluated and the algorithm returns (true, 6). At time n = 12, since 12 ⟨Tpitch≥5 ○ ⟩ does not hold, we clear p in line 22 and the algorithm returns (false, 12) in line 26, i.e., en ⊭ (pitch ≥ 5○ ) U[5,10] (alt ≥ 600f t) for n ∈ [7, 12]. At time n = 13, a transition of ⟨Tpitch≥5○ ⟩ occurs, thus m↑ϕ = 12 and mpre = −∞. The predicates in line 12 and 15 do not hold, the algorithm returns no new output in line 28. At time 14 n = 14, a transition of ⟨Tpitch≥5○ ⟩ occurs, thus p and ⟨Tpitch≥5 ○ ⟩.v are set true and 9
m↓ϕ = 14. The predicate in line 15 holds, and the algorithm outputs (false, 14), revealing that en ⊭ (pitch ≥ 5○ ) U[5,10] (alt ≥ 600f t) for n ∈ [13, 14]. 3.2
Synchronous Observers
The main characteristic of our synchronous observers is that they are evaluated at every tick of the RTC and that their output tuples T are guaranteed to be synchronous to the current time stamp n. Thus, for each time n, a synchronous observer outputs a tuple T with T.τe = n. This eliminates the need for synchronization queues. Inputs and outputs of these observers are execution sequences with three-valued verdicts. ̂ ∶ → {true, false, maybe}, where ∈ The underlying abstraction is given by eval ̂ (¬ ϕ) and eval ̂ (ϕ ∧ ψ) {¬ ϕ, ϕ ∧ ψ, τ ϕ, ◻J ϕ, ϕ UJ ψ}. The implementation of eval follows the rules for Kleene logic [18]. For the remaining operators we define the verdict Tξ .v of the output tuple (Tξ .v, n), generated for inputs (Tϕ .v, n) (respectively (Tψ .v, n) for ϕ UJ ψ), as: ⎧ true if Tϕ .v holds and τ = 0, ⎪ ⎪ ⎪ ̂ eval ( τ ϕ) = ⎨ false if Tϕ .v does not hold, ⎪ ⎪ ⎪ ⎩ maybe otherwise. ̂ (◻J ϕ) eval
=
maybe.
⎧ ⎪ ⎪ true if ⎪ ⎪ ⎪ ̂ eval (ϕ UJ ψ) = ⎨ false if ⎪ ⎪ ⎪ ⎪ ⎪ ⎩ maybe
Tϕ .v and Tψ .v holds and min(J) = 0, Tϕ .v does not hold, otherwise.
To illustrate our synchronous observer algorithms, consider the previously discussed formula 5 (alt ≥ 600f t) ∧ (pitch ≥ 5○ ), which we want to evaluate using the synchronous observer: ̂ (eval ̂ ( 5 (alt ≥ 600f t)) ∧ (pitch ≥ 5○ )) ξ = eval For n ∈ [0, 9], as in the case of the asynchronous observer, we can immediately output ̂ ( 5 (alt ≥ 600f t)) yields (maybe, n), thus, the observer is (false, n). At n = 10, eval inconclusive about the truth value of e10 ⊧ ξ. At n ∈ [11, 12] since (pitch ≥ 5○ ) does not hold, the outputs are (false, n). For analogous arguments, the output at n = 13 is (maybe, 13), at n = 14 (false, 14), and at n = 15 (maybe, 15). In this way, at times n ∈ {11, 12, 14} the synchronous observer completes early evaluation of ξ, producing output that would, without the abstraction, be guaranteed by the exact asynchronous observer with a delay of 5 time units, i.e., at times n ∈ {16, 17, 19}.
4
Mapping Observers into Efficient Hardware
We introduce a mapping of the observer pairs into efficient hardware blocks and a synthesis procedure to generate a configuration for these blocks from an arbitrary MTL specification. This configuration is loaded into the control unit of our rt-R2U2, where it changes the interconnections between a pool of (static) hardware observer blocks and assigns memory regions for synchronization queues. This approach enables us to quickly change the monitored specification (within resource limitations) without re-compiling the rt-R2U2’s hardware, supporting our R EALIZABILITY requirement. Asynchronous observers require arithmetic operations on time stamps. Registers and flags as required by the observer algorithm are mapped to circuits that can store 10
information, such as flip-flops. For the synchronization queues we turn to block RAMs (abundant on FPGAs), organized as ring buffers. Time stamps are internally stored in registers of width w = ⌈log2 (n)⌉ + 2, to indicate −∞ and to allow overflows when performing arithmetical operations on time stamps. Subtraction and relational operators as required by the observer for τ ϕ (Fig. 2) can be built around adders. For example, the check in line 8 of Alg. 2 is implemented using two w-bit wide adders: one for q = Tϕ .τe − τ and one to decide whether m↑ϕ ≥ q. A third adder runs in parallel and assigns a new value to mτs (line 6 of Alg. 2). Detecting a transition on ⟨Tϕ ⟩ maps to an XOR gate and an AND gate, implementing the circuit (Tϕi−1 .v ⊕ Tϕi .v) ∧ Tϕi .v, where Tϕi−1 .v is the truth value of the previous input, stored in a flip-flop. The multiplexer either writes a new output or sets a flag to indicate ( , ). Synchronous observers do not require calculations on time stamps and directly map ̂ ( τ ϕ) observer to basic digital logic gates. Fig. 2 shows a circuit representing an eval that accounts for one two-input AND gate, one two-input OR gate, and two Inverter gates. Inputs (i1 , i2 ) and outputs (y1 , y2 ) are encoded (to project the three-valued logic into Boolean logic) such as: true (0, 0), false (0, 1), and maybe (1, 0). Input j is set if τe = 0 and cleared otherwise. 4.1
Synthesizing a Configuration for the rt-R2U2
The synthesis procedure to translate an MTL specification ξ into a configuration such ̂ (ξ), works as follows: that the rt-R2U2 instantiates observers for both ξ and eval – Preprocessing. By the equivalences given in Sect. 2 rewrite ξ to ξ ′ , such that operators in ξ ′ are from {¬ ϕ, ϕ ∧ ψ, τ ϕ, ◻J ϕ, ϕ UJ ψ} (SA1). – Parsing. Parse ξ ′ to obtain an Abstract Syntax Tree (AST), denoted by AST(ξ ′ ). The leaves of this tree are the atomic propositions Σ of ξ ′ (SA2). – Allocating observers. For all nodes q in AST(ξ ′ ) allocate both the corresponding synchronous and the asynchronous hardware observer block (SA3). – Adding synchronization queues. ∀q ∈ AST(ξ ′ ): If q is of type ϕ ∧ ψ or ϕ UJ ψ add queues qϕ and qψ to the inputs of the respective asynchronous observer (MA1). – Interconnect and dimensioning. Connect observers and queues according to AST(ξ ′ ). Execute Alg. 6 (MA2). Let {σ1 , σ2 , σ3 } ∈ Σ and ξ = σ1 → ( 10 (σ2 ) ∨ 100 (σ3 )) be an MTL formula we want to synthesize a configuration for. SA1 yields ξ ′ = ¬(σ1 ∧ ¬(¬ 10 (¬σ2 )) ∧ ¬(¬ 100 (¬σ3 ))) which simplifies to ξ = ¬(σ1 ∧ 10 (¬σ2 ) ∧ 100 (¬σ3 )). SA2 yields AST(ξ ′ ). SA3 instantiates two ϕ ∧ ψ, three ¬ ϕ, one 10 Tϕ and one 100 Tϕ observers, both synchronous and asynchronous. MA1, introduces queues qσ1 , qξ2 , qξ3 , qξ4 and MA2 interconnects observers and queues and assigns ∣qσ1 ∣ = 100, ∣qξ2 ∣ = 100, ∣qξ3 ∣ = 10, and ∣qξ4 ∣ = 0, see Fig. 2. 4.2
Circuit Size and Depth Complexity Results
Having discussed how to determine the size of the synchronization queues for our asynchronous MTL observers, we are now in the position to prove space and time complexity bounds. 11
Algorithm 6 Assigning synchronization queue sizes for AST(ξ ′ ). Let S be a set of nodes;
Initially: w = 0, add all Σ nodes of AST(ξ ′ ) to S; The function wcd ∶ → N0 calculates the worst-case-delay an asynchronous observer may introduce by: wcd(¬ ϕ) = wcd(ϕ ∧ ψ) = 0, wcd( τ ϕ) = τ , wcd(◻J ϕ) = wcd(ϕ UJ ψ) = max(J). 1: while S is not empty do 2: s, w ← get next node from S, 0 3: if s is type ϕ UJ ψ or ϕ ∧ ψ then 4: w ← max(∣qϕ ∣, ∣qψ ∣) + wcd(s) 5: end if 6: while s is not a synchronization queue do 7: s, w ← get predecessor of s in AST(ξ ′ ), w + wcd(s) 8: end while 9: Set ∣q∣ = w; (q is opposite synchronization queue of s) 10: Add all ϕ UJ ψ and ϕ ∧ ψ nodes that have unassigned synchronization queue sizes to S 11: end while
Theorem 1 (Space Complexity of Asynchronous Observers). The respective asynchronous observer for a given MTL specification ϕ has a space complexity, in terms of memory bits, bounded by (2 + ⌈log2 (n)⌉) ⋅ (2 ⋅ m ⋅ p), where m is the number of binary observers (i.e., ϕ ∧ ψ or ϕ UJ ψ) in ϕ, p is the worst-case delay of a single predecessor chain in AST(ϕ), and n ∈ N0 is the time stamp it is executed. Theorem 2 (Time Complexity of Asynchronous Observers). The respective asynchronous observer for a given MTL specification ϕ has an asymptotic time complexity of O( log2 log2 max(p, n) ⋅ d), where p is the maximum worst-case-delay of any observer in AST(ϕ), d the depth of AST(ϕ), and n ∈ N0 the time stamp it is executed. For our synchronous observers, we prove upper bounds in terms of two-input gates on the size of resulting circuits. Actual implementations may yield significant better results on circuit size, depending on the performance of the logic synthesis tool. edge detection q= Tϕ .τe − τ Tϕ
′
asynchronous
mτs = Tϕ .τe + 1
σ1 ∧ ξ4
Tξ
̂ (¬ ξ5 ) eval
synchronous
outputs
̂ (σ1 ∧ ξ4 ) eval
qξ4
m↑ϕ ≥ q
ξ2 ∧ ξ3
multiplexer
q ξ2 10
i1 j i2
̂ (ξ) en ⊧ eval
en ⊧ ξ
¬ ξ5
ξ0
depth d of AST (ξ) = 5
q ξ3 100
ξ1
̂ (ξ2 ∧ ξ3 ) eval
̂( eval
10
̂( ξ0 ) eval
100
ξ1 )
q σ1
y1
¬ σ2
¬ σ3
̂ (¬ σ2 ) eval
̂ (¬ σ3 ) eval
inputs
σ1 σ2 σ3
y2
̂ ( τ ϕ) (bottom). Right: subforFig. 2. Left: hardware implementations for τ ϕ (top) and eval mulas of AST(ξ), observers, and queues synthesized for ξ. Mapping the observers to hardware yields two levels of parallelism: (i) asynchronous (left) and the synchronous observers (right) run in parallel and (ii) observers for subformulas run in parallel, e.g., 10 ξ0 and 100 ξ1 .
12
Theorem 3 (Circuit-Size Complexity of Synchronous Observers). For a given MTL ̂ (ϕ) has a circuit-size complexity bounded by formula ϕ, the circuit to monitor eval 11 ⋅ m, where m is the number of observers in AST(ϕ). Theorem 4 (Circuit-Depth Complexity of Synchronous Observers). For a given ̂ (ϕ) has a circuit-depth complexity of 4 ⋅ d. MTL formula ϕ, the circuit to monitor eval
5
Applying the rt-R2U2 to NASA’s Swift UAS
We implemented our rt-R2U2 as a register-transfer-level VHDL hardware design, which we simulated in M ENTOR G RAPHICS M ODEL S IM and synthesized for different FPGAs using the industrial logic synthesis tool A LTERA Q UARTUS II.3 With our rt-R2U2, we analyzed raw flight data from NASA’s Swift UAS collected during test flights. The higher-level reasoning is performed by a health model, modeled as a Bayesian network (BN) where the nodes correspond to discrete random variables. Fig. 3 shows the relevant excerpt for reasoning about altitude. Directed edges encode conditional dependencies between variables, e.g., the sensor reading SL depends on the health of the laser altimeter sensor HL . Conditional probability tables at each node define the local dependencies. During health estimation, verdicts computed by our observer algorithms are provided as virtual sensor values to the observable nodes SL , SB , SS ; e.g., the laser altimeter measuring an altitude increase would result in setting SL to state inc. Then, the posteriors of the multivariate probability distribution encoded in the BN are calculated [10]; for details of modeling and reasoning see [25]. Our temporal specifications are evaluated by our runtime observers and describe flight rules (ϕ1 , ϕ2 ) and virtual sensors: ϕ1 = (cmd == takeoff ) → 10 (altB ≥ 600f t) ϕ2 = (cmd == takeoff ) → ∗ (cmd == land) ϕ1 encodes our running example flight rule; ϕ2 is a mission-bounded LTL property requiring that the command land is received after takeoff, within the projected mission time, indicated by ∗. Fig. 3 shows the execution sequences produced by both the asyn̂ (ϕ1 )) observers for flight rule ϕ1 . chronous (en ⊧ ϕ1 ) and the synchronous (en ⊧ eval To keep the presentation accessible we scaled the timeline to just 24 time stamps; the actual implementation uses a resolution of 232 time stamps. The synchronous observer is able to prove the validity of ϕ1 immediately at all time stamps but one (n = 1), where the output is (maybe, 1), indicated by . The asynchronous observer will resolve this inconclusive output at time n = 11, by generating the tuple (false, 1), revealing a violation of ϕ at time n = 1. The verdicts of σSL↑ ,σSL↓ , σSB↑ , σSB↓ , ϕSS↑ , and ϕSS↓ are mapped to inputs SL , SB , SS of the health model: σSL↑ = (altL − alt′L ) > 0 σSL↓ = (altL − alt′L ) < 0 ′ σSB↑ = (altB − altB ) > 0 σSB↓ = (altB − alt′B ) < 0 σSB↑ observes if the first derivation of the barometric altimeter reading is positive, thus, holds if the sensors values indicate that the UAS is ascending. We set SB to inc if σSB↑ holds and to dec if σSB↓ holds. The specifications ϕSS↑ and ϕSS↓ subsume the pitch and the velocity readings to an additional, indirect altitude sensor. Due to sensor noise, 3
Simulation traces are available in the Appendix; tools can be downloaded at http://www.mentor.com and http://www.altera.com.
13
900 900
Swift data Swift UAS UAS flight flight data
600 600 300 300
H LaserAlt (HL )
Barometric altitude Barometric altitude(alt (altB )) / / fft t B
HL healthy bad
Laser altitude Laser altitude (alt(alt ) /Lf )t / f t L
ΘH L 0.7 0.3
ΘUA 0.5 0.5
S LaserAlt (SL )
m Vert. velocity (vel up) s /m Vertical velocity (vel/ up) s
Euler Euler pitchpitch angle (pitch) angle (pitch)//rad rad
UA
HL healthy
UAS healthn estimation (output of higher-level reasoning unit)
inc bad
Pr(HB = healthy ∣ e ⊧ {σSL , σSB , ϕSS }) Pr(HL = healthy ∣ en ⊧ {σSL , σSB , ϕSS })
healthy dec
UAS status assessment (output of runtime observers) 0
UA inc dec
bad
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 n
SL inc dec inc dec inc dec inc dec
ΘSL 1.0 0.0 0.5 0.5 0.0 1.0 0.5 0.5
U Altimeter (UA )
S Sensors (SS ) UA inc
dec
SS inc dec maybe inc dec maybe
ΘSS 0.7 0.1 0.2 0.1 0.7 0.2
H BaroAlt (HB ) HB healthy bad
ΘHB 0.9 0.1
S BaroAlt (SB ) UA
HB healthy
inc bad healthy dec bad
SB inc dec inc dec inc dec inc dec
ΘSB 1.0 0.0 0.5 0.5 0.0 1.0 0.5 0.5
n
e ⊧ altB ≥ 600f t en ⊧ (cmd == takeoff ) resolve by async. observer
̂ (ϕ1 ) en ⊧ eval en ⊧ ϕ1
0
v
Inputs to our rt-R2U2 are flight data, sampled in real time; a health model as BN, right; and an MTL specification ϕ. Outputs: health estimation (posterior marginals of HL and HB , quantifying the health of the laser and barometric altimeter) and the status of the UAS.
0 0 0 0 0 0 0 0 0 0 1 12 13 14 15 16 17 18 19 20 21 22 23 τe
Fig. 3. Adding SHM to the Swift UAS
simple threshold properties on the IMU signals would yield a large number of false positives. Instead ϕSS↑ and ϕSS↓ use τ ϕ observers as filters, by requiring that the pitch and the velocity signals exceed a threshold for multiple time steps. ϕSS↑ = ϕSS↓ =
(pitch ≥ 5○ ) ∧ ○ 10 (pitch < 2 ) ∧ 10
(vel up ≥ 2 m ) s m 5 (vel up ≤ −2 s ) 5
Our real-time SHM analysis matched post-flight analysis by test engineers, including successfully pinpointing a laser altimeter failure, see Fig 3: the barometric altimeter, pitch, and the velocity readings indicated an increase in altitude (σSB↑ and ϕSS↑ held) while the laser altimeter indicated a decrease (σSL↓ held). The posterior marginal Pr(HL = healthy ∣ en ⊧ {σSL , σSB , ϕSS }) of the node HL , inferred from the BN, dropped from 70% to 8%, indicating a low degree of trust in the laser altimeter reading during the outage; engineers attribute the failure to the UAS exceeding its operational altitude.
6
Conclusion
We presented a novel SHM technique that enables both real-time assessment of the system status of an embedded system with respect to temporal-logic-based specifications and also supports statistical reasoning to estimate its health at runtime. To ensure R EALIZABILITY, we observe specifications given in two real-time projections of LTL that naturally encode future-time requirements such as flight rules. Real-time health modeling, e.g., using Bayesian networks allows mitigative reactions inferred from complex relationships between observations. To ensure R ESPONSIVENESS, we run both an over-approximative, but synchronous to the real-time clock (RTC), and an exact, but asynchronous to the RTC, observer in parallel for every specification. To ensure U NOBTRUSIVENESS to flight-certified systems, we designed our observer algorithms with a light-weight, FPGA-based implementation in mind and showed how to map them into efficient, but reconfigurable circuits. Following on our success using rt-R2U2 to analyze real flight data recorded by NASA’s Swift UAS, we plan to analyze future missions of the Swift or small satellites with the goal of deploying rt-R2U2 onboard. 14
References 1. Alur, R., Henzinger, T.A.: Real-time Logics: Complexity and Expressiveness. In: LICS. pp. 390–401. IEEE (1990) 2. Backasch, R., Hochberger, C., Weiss, A., Leucker, M., Lasslop, R.: Runtime verification for multicore soc with high-quality trace data. ACM Trans. Des. Autom. Electron. Syst. 18(2), 18:1–18:26 (2013) 3. Barre, B., Klein, M., Soucy-Boivin, M., Ollivier, P.A., Hall´e, S.: MapReduce for parallel trace validation of LTL properties. In: RV. LNCS, vol. 7687, pp. 184–198. Springer (2012) 4. Barringer, H., Falcone, Y., Finkbeiner, B., Havelund, K., Lee, I., Pace, G.J., Rosu, G., Sokolsky, O., Tillmann, N. (eds.): Runtime Verification (RV), LNCS, vol. 6418. Springer (2010) 5. Basin, D., Klaedtke, F., M¨uller, S., Pfitzmann, B.: Runtime monitoring of metric first-order temporal properties. In: FSTTCS. pp. 49–60 (2008) 6. Basin, D., Klaedtke, F., Z˘alinescu, E.: Algorithms for monitoring real-time properties. In: RV. pp. 260–275. LNCS, Springer (2011) 7. Bauer, A., Leucker, M., Schallhart, C.: Comparing LTL semantics for runtime verification. J. Log. and Comp. 20, 651–674 (2010) 8. Bauer, A., Leucker, M., Schallhart, C.: Runtime verification for LTL and TLTL. ACM Trans. Softw. Eng. M. 20, 14:1–14:64 (2011) 9. Colombo, C., Pace, G., Abela, P.: Safer asynchronous runtime monitoring using compensations. FMSD 41, 269–294 (2012) 10. Darwiche, A.: Modeling and Reasoning with Bayesian Networks. Cambridge University Press, New York, NY, USA, 1st edn. (2009) 11. Divakaran, S., D’Souza, D., Mohan, M.R.: Conflict-tolerant real-time specifications in metric temporal logic. In: TIME. pp. 35–42 (2010) 12. Finkbeiner, B., Kuhtz, L.: Monitor circuits for LTL with bounded and unbounded future. In: RV, LNCS, vol. 5779, pp. 60–75. Springer (2009) 13. Fischmeister, S., Lam, P.: Time-aware instrumentation of embedded software. IEEE Trans. Ind. Informatics 6(4), 652–663 (2010) 14. Geilen, M.: An improved on-the-fly tableau construction for a real-time temporal logic. In: CAV. pp. 394–406 (2003) 15. Havelund, K.: Runtime verification of C programs. In: TestCom/FATES. LNCS, vol. 5047, pp. 7–22. Springer (2008) 16. Ippolito, C., Espinosa, P., Weston, A.: Swift UAS: An electric UAS research platform for green aviation at NASA Ames Research Center. In: CAFE EAS IV (April 2010) 17. Johnson, S., Gormley, T., Kessler, S., Mott, C., Patterson-Hine, A., Reichard, K., Philip Scandura, J.: System Health Management: with Aerospace Applications. Wiley & Sons (2011) 18. Kleene, S.C.: Introduction to Metamathematics. North Holland (1996) 19. Lichtenstein, O., Pnueli, A., Zuck, L.: The glory of the past. In: Logics of Programs, LNCS, vol. 193, pp. 196–218. Springer (1985) 20. Lu, H., Forin, A.: The design and implementation of P2V, an architecture for zero-overhead online verification of software programs. Tech. Rep. MSR-TR-2007-99 (2007) 21. Maler, O., Nickovic, D., Pnueli, A.: On synthesizing controllers from bounded-response properties. In: CAV. LNCS, vol. 4590, pp. 95–107. Springer (2007) 22. Maler, O., Nickovic, D., Pnueli, A.: Checking temporal properties of discrete, timed and continuous behaviors. In: Pillars of Comp. Science. pp. 475–505. Springer (2008) 23. Pike, L., Niller, S., Wegmann, N.: Runtime verification for ultra-critical systems. In: RV. pp. 310–324. LNCS, Springer (2011) 24. Reinbacher, T., F¨ugger, M., Brauer, J.: Real-time runtime verification on chip. In: RV. LNCS, vol. 7687, pp. 110–125. Springer (2012) 25. Schumann, J., Mbaya, T., Mengshoel, O., Pipatsrisawat, K., Srivastava, A., Choi, A., Darwiche, A.: Software health management with Bayesian Networks. Innovations in Systems and SW Engineering 9(4), 271–292 (2013) 26. Schumann, J., Rozier, K.Y., Reinbacher, T., Mengshoel, O.J., Mbaya, T., Ippolito, C.: Towards real-time, on-board, hardware-supported sensor and software health management for unmanned aerial systems. In: PHM (2013) 27. Tabakov, D., Rozier, K.Y., Vardi, M.Y.: Optimized temporal monitors for SystemC. Formal Methods in System Design 41(3), 236–268 (2012) 28. Thati, P., Ros¸u, G.: Monitoring Algorithms for Metric Temporal Logic specifications. ENTCS 113, 145–162 (2005)
15
