Runtime Verification for Real-Time Automotive Embedded Software

Runtime Verification for Real-Time Automotive Embedded Software S. Cotard, S. Faucou, J.-L. Béchennec, A. Queudet, Y. Trinquet 10th school of Modelling and Verifying Parallel processes (MOVEP) Runtime Verification for Real-Time Automotive Embedded Software 1/18

Motivating example T 0 s 00 b 0 r 20 T 2 r 10 T 1 r 21 b s 1 11 Safety constraint: T 2 requires the data from b 1, but also reads b 0 in order to perform a plausibility check. T 2 has to read the same instance of data. Requirement: consistency checking Correctness property: when T 2 starts reading, the buffers are synchronized and stay synchronized until T 2 completes its execution Runtime Verification for Real-Time Automotive Embedded Software 2/18

A possible solution: diversification T 0 s 00 b 0 r 20 T 2 r 10 T 1 r 21 b s 1 11 Design and implementation 011001101 Runtime Verification for Real-Time Automotive Embedded Software 3/18

A possible solution: diversification T 0 s 00 b 0 r 20 T 2 r 10 T 1 r 21 b s 1 11 Errors Design and implementation 011001101 Runtime Verification for Real-Time Automotive Embedded Software 3/18

A possible solution: diversification T 0 s 00 b 0 r 20 T 2 r 10 T 1 r 21 b s 1 11 Errors Design and implementation Monitoring and recovery 011001101 101100111 Runtime Verification for Real-Time Automotive Embedded Software 3/18

A possible solution: diversification T 0 s 00 b 0 r 20 T 2 r 10 T 1 r 21 b s 1 11 Errors Design and implementation Monitoring and recovery 011001101 101100111 Runtime Verification for Real-Time Automotive Embedded Software 3/18

Context Objectives based on formal methods compatible with functional and industrial constraints small and deterministic detection latency small and deterministic overheads (execution time, memory footprint) compatible with multi-tiers system design process (the provided source code is not always modifiable) Proposed solution runtime verification injection of monitors in the kernel Runtime Verification for Real-Time Automotive Embedded Software 4/18

Formal methods Model M of a system S A ev4 ev2 C ev3 B ev1 Property φ Model checking: all runs of M satisfy φ? (design time) Tests: some runs of S satisfy φ? (design time) Runtime verification: does this run satisfy φ? (online analysis) generate a monitor from M and φ that outputs a verdict in {,,?} Runtime Verification for Real-Time Automotive Embedded Software 5/18

Our approach: runtime verification: step 1 [Bauer et al, 2011] solution φ A φ F φ Â φ Ã φ Input : LTL property φ LTL property Non deterministic Buchï automata Emptiness checking (per state) Non deterministic Finite Automata Deterministic Finite Automata M m Output : Monitor Finite State Machine φ A φ F φ Â φ Ã φ For φ and φ 1) Compute NBAs 2) Emptiness checking per state (derived F) 3) Compute NFAs using F 4) Compute DFAs 5) DFAs synchronization Runtime Verification for Real-Time Automotive Embedded Software 6/18

Our approach: runtime verification: step1 Property φ = G ((m t2.firstb0 m t2.firstb1) = (m sync.sync U m t2.begin)) 1) Computation of the NBAs true m t2.begin S 0 m t2.begin A φ m sync.sync S 1 m sync.sync S 1 m sync.sync S 0 S 2 A φ m sync.sync true Runtime Verification for Real-Time Automotive Embedded Software 7/18

Our approach: runtime verification: step1 Property φ = G ((m t2.firstb0 m t2.firstb1) = (m sync.sync U m t2.begin)) 1) Computation of the NBAs m t2.begin S 0 m t2.begin S 1 A φ m sync.sync m sync.sync 2) Emptiness checking per state S 1 m sync.sync true F φ = {S 0, S 1 } F φ = {S 0, S 1, S 2 } S 0 S 2 A φ m sync.sync true Runtime Verification for Real-Time Automotive Embedded Software 7/18

Our approach: runtime verification: step1 Property φ = G ((m t2.firstb0 m t2.firstb1) = (m sync.sync U m t2.begin)) 3) Computing NFAs using F and completes automata m t2.begin  φ true  φ S 0 m sync.sync m t2.begin true S 2 m sync.sync S 1 m sync.sync m sync.sync true m t2.begin S 3 S 0 S 1 S 2 m sync.sync m sync.sync true Runtime Verification for Real-Time Automotive Embedded Software 7/18

Our approach: runtime verification: step1 Property φ = G ((m t2.firstb0 m t2.firstb1) = (m sync.sync U m t2.begin)) 4) Determinization Composition Minimization m t2.begin m sync.sync init St2 m sync.sync m t2.begin m sync.sync m sync.sync bad true The intermediate monitor M m reacts to changes in the values of the atomic propositions used in φ Runtime Verification for Real-Time Automotive Embedded Software 7/18

Our approach: runtime verification: step1 Intermediate monitor (M m ) The intermediate monitor is the Moore machine given by M m = (Q m, i m, m, γ m ) over 2 AP, the set of intercepted events Q m is the finite set of states i m is the initial state m (Q m 2 AP ) Q m is the transition function γ m Q m B 3 = {,,?} is the output function Runtime Verification for Real-Time Automotive Embedded Software 7/18

Our approach: runtime verification: step2 Input: system model + properties s 11, r 10 T0 s00 b0 r20 T2 s 11 sync s 00 r10 T1 s11 b1 r21 r 20 firstb0 inprog s 00 nosync begin r 21 r 10 s 00, s 11 r 20 r 21 firstb1 m sync: buffers synchronization m t2: T 2 behavior G ((m t2.firstb0 m t2.firstb1) = (m sync.sync U m t2.begin)) Runtime Verification for Real-Time Automotive Embedded Software 8/18

Our approach: runtime verification: step2 Model of the system (A s ) The model of the system is given by A s = (Q s, i s, s ) over Σ s, the set of intercepted events Q s is the finite set of states i s Q s is the initial state s (Q s Σ s ) Q s is the transition function We denote λ s Q s 2 AP, the labeling function that maps each state of the DFA to the set of atomic proposition true in this state. Runtime Verification for Real-Time Automotive Embedded Software 9/18

Our approach: runtime verification: step2 Final monitor computation (M ) The final monitor is defined by M = (Q, i,, γ ) over Σ s Q = Q s Q m i = (i s, i m ) (Q Σ s ) Q where (q s, q m ) σ (r s, r m ) iff q s σ s r s and q m u m r m and u λ s (r s ) and γ m (q m ) =? γ Q B 3 where γ (q s, q m ) = γ m (q m ) Runtime Verification for Real-Time Automotive Embedded Software 10/18

Our approach: runtime verification: step2 Output: a monitor s 11, r 10 s 11, r 10? r 20 r 21? s 11 s 00, r 20 r 21 r 20 s 00 s 11, s 00 s 11, r 10 s 00, r 21? s 00?? r 10 r 20, r 21 r 20, r 21, r 10 Runtime Verification for Real-Time Automotive Embedded Software 11/18

Enforcer: A tool for monitor synthesis System model (transition system) A s Inconclusive state True state False state *.enf file Enforcer tool M Output sources Monitor (*.c *.h) (Transition table) Properties (LTL formulae) ltl rule ltl_rule = "Always (a Until b)" LTL } NBA Intermediate {{ Moore machine} } Monitor {{ } step 1 step 2 Runtime Verification for Real-Time Automotive Embedded Software 12/18

Injection of the monitors in the kernel The Trampoline compilation chain (open-source implementation of AUTOSAR OS) *.oil *.c *.h System configuration application configuration sources *.c *.h 0110 0101 RTOS and application sources Binary Code Enforcer *.enf *.c *.h monitor description monitor sources Runtime Verification for Real-Time Automotive Embedded Software 13/18

Architecture T 0 b 0 T 2 T 1 r 21 b 1 s 00 r 10 s 11 r 21 false Monitoring service true Event Event analysis Monitor update True occurs False occurs Event table Event Handler Monitor update Transition table Runtime Verification for Real-Time Automotive Embedded Software 14/18

Evaluation: computation overhead SendMessage SendMessage with ActivateTask SendMessage with SetEvent ReceiveMessage Monitoring of 1 monitor 3.4 10 15.4 18.5 24 0 10 20 30 Execution time (µs) target running at 60 MHz composition of the overhead 1µs to identify the event 2.4µs to react per monitor interested in the event Runtime Verification for Real-Time Automotive Embedded Software 15/18

Evaluation: memory footprint Transition table Monitor descriptor Code size ROM RAM ROM/RAM 152 bytes (monitor update) constant 30 bytes 15 bytes depends on the monitor constant per monitor 16 bytes (event handler) 3 optimizations depends on the number have been proposed of monitors per event Runtime Verification for Real-Time Automotive Embedded Software 16/18

Conclusion approach has been implemented in a tool: Enforcer freely available (see paper for URL) results show that runtime verification can be affordable for (static) industrial real-time embedded systems kernel instrumention allows to achieve (guaranteed) low detection latency static code and data generation allows to achieve low execution time overhead system designer can pay time for memory future works compute the theoretical bound on the size of the monitors (given the size of M and φ) multicore extension (not only a matter of implementation) Runtime Verification for Real-Time Automotive Embedded Software 17/18

Thank you for your attention Runtime Verification for Real-Time Automotive Embedded Software 18/18