The Rare Glitch Project: Verifying Bus Protocols for Embedded Systems

1. The Rare Glitch Project:Verifying Bus Protocols for Embedded Systems Edmund Clarke, Daniel Kroening Carnegie Mellon University

2. Motivation TTP/C • Shorthand for Time-Triggered Protocol for SAE Class C Applications [SAE93] • Real-time communication protocol forfault-tolerant real-time systems • Defined by draft standard TTP/C version 0.5 from TTTech AG [TTPC99] • Designed for X-by-wire applications • steer-by-wire, break-by-wire, throttle-by-wire, ... • E.g., replace steering wheel by a joystick • Safety critical!

3. Introduction Drive-by-Wire • First used for military aircrafts (fly-by-wire) • Steer-by-Wire: replace steering wheel by joystick • Brake-by-Wire: replace hydraulic brake system • Throttle-by-Wire: replace mechanic throttle pedal

4. Introduction Drive-by-Wire

5. Drive by wire

6. Introduction Drive-by-Wire: Advantages • More safety by stabilizing algorithms • Passive safety: no steering column • Reduced weight • Reduced maintenance cost

7. Introduction Implementing Drive-by-Wire • Components are connected using a redundant bus

8. Introduction A TTP/C Bus

9. Introduction A TTP/C Bus Node • Also the smallestreplaceable unit(SRU) • Host Processor • Protocol Processor • Bus Guardian • Line Interfaces

10. Introduction TTP = Time Triggered Protocol • TTP/C is uses a cyclic time-division multiple access (TDMA) scheme Time slots are assigned statically One TDMA Round A B C A B C A …… time

11. Introduction Why verify? • Daimler Chrysler / BMW tested TTP/C and considered it to be too inflexible • They developed FlexRay, which provides more flexibility • The developers of TTP/C claim that FlexRay sacrifices safety for flexibility • GM has not decided yet which protocol to use

12. Introduction Why is verification hard? • Large state space per node(message area) • Many features besides message transmission (membership service, global time base, mode changes, reconfiguration, download) • Protocol provides clock synchronization • Must have large number of nodesVerifying with only 2 or 3 nodes is dangerous, protocol requires 4 minimum, 20-30 nodes realistic

13. Formalizing TTP/C Formalizing a Protocol Standard • The TTP/C standard is plain, informal English text • In a Drive-by-wire system, different implementations from different vendors are used • We do not verify a particular implementationbut the requirements for all implementations • Use non-determinism to cover all implementation details

14. Formalizing TTP/C Formalizing a Protocol Standard 1. Define set of states 4 10 5 1 7 9 3 6 2 8

15. Formalizing TTP/C Formalizing a Protocol Standard 1. Define set of states 2. Define set of valid initial states 4 10 5 1 1 7 9 3 3 6 2 8

16. Formalizing TTP/C Formalizing a Protocol Standard 1. Define set of states 2. Define set of valid initial states 3. Define transition relation 4 10 5 1 1 7 9 3 3 6 2 8

17. Formalizing TTP/C Formalizing a Protocol Standard 1. Define set of states 2. Define set of valid initial states 3. Define transition relation 4 10 5 1 1 7 9 3 3 6 2 8 Verification: Prove Properties on paths

18. Formalizing TTP/C Level of Abstraction • Abstraction... • permits concise specification of protocol properties • allows for automated, computer aided verification • Abstraction on time:Only consider specific points of time • E.g., end of TDMA round, end of message, etc.

19. MSGslot MSGslot MSGslot macro-ticks includes MFM …. …. micro-ticks macro-tick synchronization DPRAM access timing each SRU has own time base …. …. Formalizing TTP/C Abstraction Hierarchy TDMA round

20. Formalizing TTP/C Abstraction Hierarchy: Formalization • Each level is modeled by a mathematical machine • The machines share the same configuration set • The set of reachable states of a lower level is a refinement of the reachable states of a level above

21. Formalizing TTP/C Abstraction Hierarchy: Formalization 4 11 12 Msg Slot Level Macro Tick Level 4 5 6 7 11 8 9 12

22. Formalizing TTP/C Abstraction Hierarchy: Formalization Let rx denote the transition relation for level x Let a, b denote levels and let b<a hold. c ra d holds iff there is a set of states c1, …, cn with ci rb ci+1 for i=1 to n-1 and c1=c and cn=d n can be fixed depending on the level and on c1.

23. Verifying Protocol Properties Properties of Interest • Service Guarantee • Verify that protocol stack can transmit messages within a finite amount of time after enabling the controller • Verify a guarantee for hot standby nodes to become member in case of a failure • Membership service • Informs all nodes about the operational state of each node within one TDMA round • SRU is operational if the host sends a life sign and the controller is operational and synchronized • Claim: membership bit matches real status after one TDMA round

24. Verifying Protocol Properties Fault Model • Described in standard • System must tolerate any single hardware fault • System must tolerate malicious host software … assuming that all SRUs are implemented according to the standard

25. Verifying Protocol Properties Membership Service • Uses implicit acknowledgement scheme • Encoded in CRC that protects the frames • A node that sends no or false data looses membership • After sending a frame, a node watches the following frames to determine if it is still considered a member of the cluster

26. Project Status Done • Verification done using PVS • Abstraction hierarchy • Initial predicate • Transition relation • for message slot abstraction level and abstraction levels above; for MFM code level • includes membership service • without mode changes, download, and reconfiguration • Parts of the Verification of the Membership Service

27. Project Status Future Work • More Properties • Analysis of Problems of Membership Service • More abstraction levels (e.g., clock synchronization) • FlexRay (requires NDA) • Prove abstraction hierarchy using theorem prover,model-check the individual levels of the hierarchy • Common Framework: SyMP • Probabilistic Model Checking (J. Wing)

28. Outline • Introduction • Project Goals • Formalizing TTP/C • Verifying Protocol Properties • Project Status

29. Verifying Protocol Properties Problems with Membership Service • No data is accepted from a node without consistentmembership information • Membership service is therefore safety critical • Problem: Correctly working nodes may loose membership • One is maybe better off without Membership Service

30. Verifying Protocol Properties Example • Nodes: A, D, E, … from Vendor 1, B, C from Vendor 2 • A transmits message, correctly received by D, E… but not by B, C • A looses membership; can continue with next predecessor of B A B C D E F

31. Project Goals • Formalization of the requirements ofTTP/C and FlexRay • Formalization of service requirements ofhigher levels • Formalization of a fault model • Formal proof that the protocols satisfy the service requirements