1 / 31

The Rare Glitch Project: Verifying Bus Protocols for Embedded Systems

The Rare Glitch Project: Verifying Bus Protocols for Embedded Systems. Edmund Clarke, Daniel Kroening Carnegie Mellon University. Motivation. TTP/C. Shorthand for Time-Triggered Protocol for SAE Class C Applications [SAE93]

arent
Télécharger la présentation

The Rare Glitch Project: Verifying Bus Protocols for Embedded Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related