1 / 21

Analysis of Asynchronous Systems

Analysis of Asynchronous Systems. Steven P. Miller Michael W. Whalen {spmiller, mwwhalen}@rockwellcollins.com Advanced Computing Systems Rockwell Collins. What Have We Done?. Developed Techniques for Modeling and Analyzing Asynchronous Architectures

ohio
Download Presentation

Analysis of Asynchronous 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. Analysis of Asynchronous Systems Steven P. Miller Michael W. Whalen {spmiller, mwwhalen}@rockwellcollins.com Advanced Computing Systems Rockwell Collins

  2. What Have We Done? • Developed Techniques for Modeling and Analyzing Asynchronous Architectures • Globally Asynchronous/Locally Synchronous (GALS) Architectures • Applied this to the Synchronization Logic of a Dual Flight Guidance System

  3. Why Is This Important? • Most System Architectures are Asynchronous • Distributed Systems • Fault Tolerant Systems • Flight Control, Avionics Displays, … • Asynchronous Behavior is Very Difficult to Get Right • Much More Difficult than Synchronous Behavior • Need to Consider All Possible Interleavings of Components • System Safety Analysis • Involves Both Digital Controller and System to be Controlled • Almost Always Involves Asynchronous Communication

  4. Macro Process

  5. Dual FGS Example • FCS Contains Two Redundant FGS • If A FGS is Active, Then It is Sending Commands to the Pilot or Autopilot • For Most Flight Phases, Only One FGS is Active. • Other Acts as Hot Spare • Passive FGS sets its state to Active FGS • Pilot Flying Side is the Active Side • Transfer Switch Toggles the Pilot Flying Side • If Active Side Fails, Other Side Takes Over • In Critical Phases Both Sides are Active • Final Approach and Go Around • If They Disagree, Both are Disengaged • Independent Mode Determines Whether Both FGS Should Be Active

  6. Dual FGS Example

  7. System Safety Properties • At Least One FGS Shall Always be Active • Exactly One Side Shall be the Pilot Flying Side • If the System is in Independent Mode, Both FGSs Shall be Active Property1 := (Left_FGS_Active | Right_FGS_Active) Property2 := (Left_FGS_Pilot_Flying = !Right_FGS_Pilot_Flying) System_Independent_Mode := Left_Independent_Mode & Right_Independent_Mode Property3 := (System_Independent_Mode -> (Left_FGS_Active & Right_FGS_Active))

  8. Ideal System Model

  9. Synchronization Properties: Ideal Model • At Least One FGS Shall Always be Active • AG(Property1) ; • Exactly One Side Shall be the Pilot Flying Side • AG(Property2) ; • If the System is in Independent Mode, Both FGSs Shall be Active • AG(Property3); • Reason: Channels Introduce a 1-Step Delay • One Side Does Not “Immediately” Know State of Other Side • Solution: Relax Properties Slightly • Allow Property Not To Hold For One Step • AG( !Property2 -> AX(Property2)) • AG( !Property3 -> AX(Property3))

  10. Fidelity Extension: Adding Asynchrony

  11. Asynchrony and Properties • Describe Maximum Interval that Property Can Fail to Hold • Duration (¬P) < T • Pattern: Use Temporal Logic UNTIL Operator to Describe T • Nest P Inside of UNTILs To Match Clock Delays • AG(!P & Sender_Clock -> A[ !Channel_Clock U (P | (AX A[ !Receiver_Clock U P]))])

  12. Asynchrony and Properties LEFT_INTERVAL(Property2) RIGHT_INTERVAL(Property2) • Shorthand for Ease of Presentation • AG(LEFT_INTERVAL(Property2) | RIGHT_INTERVAL(Property2)); • Not Actually Supported in SMV • Need Symmetric Properties for Left and Right Sides • Example: Exactly One Side Shall be the Pilot Flying Side • AG((!Property2 & Left_FGS_Clock -> A[ !LR_Channel_Clock U (Property2 | (AX A[ !Right_FGS_Clock U Property2]))]) | (!Property2 & Right_FGS_Clock -> A[!RL_Channel_Clock U (Property2 | (AX A[!Left_FGS_Clock U Property2]))]))

  13. Synchronization Properties: Asynchronous Model • At Least One FGS Shall Always be Active • AG(Property1) ; • Exactly One Side Shall be the Pilot Flying Side • AG(LEFT_INTERVAL(Property2) | RIGHT_INTERVAL(Property2)); • If the System is in Independent Mode, Both FGSs Shall be Active • AG(LEFT_INTERVAL(Property3) | RIGHT_INTERVAL(Property3)); • Reason for Non-Satisfaction: Synchronization Logic Error • Counterexample: Both Sides Believe That They are Pilot Flying Side • Explanation on Next Page • Solution: Fix Synchronization Logic • All Properties Hold in Corrected Logic • Significantly More Complex than Original Logic

  14. Synchronization Logic: Synchronous Model vs. Asynchronous Model

  15. Dual FGS Example

  16. Bounded Asynchrony • Difficult to Prove Anything About Completely Asynchronous Models • All Real Systems are Based on Bounded Asynchrony • Often Exploit Process Rates, Latencies, Drift • FCS System Architecture: • FGSs Run on 100 ms Cycle • FGS Clocks are Not Synchronized • Network Data Transfer Time is <10 ms • FGS Clocks May Drift up to 2 ms Per Cycle • Properties can be Greatly Simplified: • Informally • Duration(!Property) ≤ 300ms • Formally • Count Master Clock Ticks that a Property is False • Prove Count is Less Than Some Maximum

  17. Calendar Automata

  18. What Is A Calendar? • Describes the “Interesting” Instants In Time • Each Process has a Basic Rate +/- Drift • Each Process has a Counter Until Next Execution (Time_Remaining) • Advance Global Time to Next Instant That A Process Can Execute • If A Process Executes, Reset its Counter to (Rate +/- Drift) • Implementations • Real Time: Rates are Real Numbers (SAL/Prover) • Discrete Time: Define Basic Time Quanta (SMV)

  19. Observations • Asynchrony Makes Modeling Much More Difficult • More Difficult to Get the Models Correct • Subtle Errors are Easy to Make • Asynchrony Makes Analysis Much More Difficult • Properties Are Difficult to State • Require Complicated LTL Formulae • Difficult for Practicing Engineers • Synchronous Architectures are Easier To Analyze • TTA, Spider • Not Always Practical to Make Entire System Synchronous • Example: Mechanical System + Digital Controller • Bounded Asynchrony May Be a Useful Compromise • Calendar Automata Introduces Timing Constraints • Makes Analysis Feasible with Existing Tools • Simplifies Properties • Adds Some Complexity to the Model

  20. Benefits • Approach Is Sufficient For Many Critical Avionics Architectures • Synchronous Architectures: 777 Safebus, TTA, Spider • GALS Architectures: AFDX, Most Existing Federated Architectures • Our Model Is Built on Well-Understood Languages and Tools • Pairing of Synchronous Languages and Temporal Logic • Possible to Express Most Properties of Interest • We Can Analyze System Architectures for Critical Safety Properties • Finds Some of the Most Difficult Errors in System Designs • Possible to Perform Early in Software Lifecycle • Applying it Now to Critical Avionics Systems Under Development

More Related