page 1 analysis of asynchronous systems steven p. miller michael w. whalen {spmiller,...

Analysis of Asynchronous Systems

Steven P. MillerMichael W. Whalen

{spmiller, mwwhalen}@rockwellcollins.com

Advanced Computing SystemsRockwell Collins

05/20/2004

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

05/20/2004

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

05/20/2004

Macro Process

Ideal SystemSpecification

Ideal SystemImplementation

Implements

Implements

Implements

Fidelity Extension

Acceptable SystemSpecification

Acceptable SystemImplementation

Implements

De

sig

n R

efi

ne

me

nt

05/20/2004

Dual FGS Example

FGS

FMS 1

Air Data L

Nav Radio 1

AHRSL

FMS 2

Air Data R

Nav Radio 2

AHRSRFGSL

ModeLogic

ControlLaws

FGSR

ModeLogic

ControlLaws

FCP

YokesThrottles

PFDL PFDRDCPL DCPL

Autopilot

ControlSurfaces

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

05/20/2004

Dual FGS Example

Idealized Dual FGSArchitecture

Idealized FGS Model

Fidelity Extension

Dual FGS Architecture wirhAsynchronous

Communication

FGS Model 2

Dual FGS Architecture withAsynchronous

Communication and FGSFailures

FGS Model 3

Des

ign

Re

finem

ent

05/20/2004

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 ActiveSystem_Independent_Mode :=

Left_Independent_Mode & Right_Independent_Mode

Property3 := (System_Independent_Mode -> (Left_FGS_Active & Right_FGS_Active))

Property1 := (Left_FGS_Active | Right_FGS_Active)

Property2 := (Left_FGS_Pilot_Flying = !Right_FGS_Pilot_Flying)

05/20/2004

Ideal System Model

05/20/2004

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))

05/20/2004

Fidelity Extension: Adding Asynchrony

05/20/2004

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]))])

05/20/2004

Asynchrony and Properties

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]))]))

LEFT_INTERVAL(Property2)

RIGHT_INTERVAL(Property2)

Shorthand for Ease of Presentation – AG(LEFT_INTERVAL(Property2) | RIGHT_INTERVAL(Property2));

– Not Actually Supported in SMV

05/20/2004

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

05/20/2004

Left Side FGS Right Side FGS

Since the left FGS is no longerthe Pilot Flying side, itprocesses the transfer switch,and sets its Pilot Flying sideback to true.

Transfer SwitchPressed

PF = trueOther.PF = false

PF = falseOther.PF = true

PF = trueOther.PF = true

PF = true

PF = true


PF = true

PF = falseOther.PF = true

Transfer SwitchPressed

PF = false


PF = true

The right side FGS perceivesthe transfer switch so it sets itsPilot Flying to true andtransmits to the other side.

Initially, both sides agree thatthe left side FGS is the PilotFlying side.

The left FGS perceives that theright side has assumed thePilot Flying side, so it sets itsPilot Flying to false.

Now the system is in aincorrect state in which bothsides are the Pilot Flying side.The right FGS is waiting for arising edge on Pilot Flying,which cannot occur because ofthe missed signal (*).

The right FGS does not execute inthis interval due to its clock beinglow, and so misses any notificationthat the left side is not the PilotFlying side.

***

05/20/2004

Synchronization Logic: Synchronous Model vs. Asynchronous Model

05/20/2004

Dual FGS Example

Idealized Dual FGSArchitecture

Idealized FGS Model

Fidelity Extension

Dual FGS Architecture wirhAsynchronous

Communication

FGS Model 2

Dual FGS Architecture withAsynchronous

Communication and FGSFailures

FGS Model 3

Des

ign

Re

finem

ent

05/20/2004

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

05/20/2004

Calendar Automata

5

Clock_Dec

4

Right_FGS_Pilot_Flying

3

Left_FGS_Pilot_Flying

2

Right_FGS_Active

1

Left_FGS_Active

Lef t_FGS_Drif t

Lef t_FGS_Initial

Right_FGS_Drif t

Right_FGS_Initial

Lef t_FGS_Clock

LR_Channel_Clock

Right_FGS_Clock

RL_Channel_Clock

Clock_Dec

FGSCalendar

Transf er_Switch

Lef t_Independent_Mode

Right_Independent_Mode

Lef t_FGS_Clock

LR_Channel_Clock

Right_FGS_Clock

RL_Channel_Clock

Lef t_FGS_Activ e

Right_FGS_Activ e

Lef t_FGS_Pilot_Fly ing

Right_FGS_Pilot_Fly ing

FGSArchitecture7

Right_FGS_Initial

6

Right_FGS_Drift

5

Left_FGS_Initial

4

Left_FGS_Drift

3

Right_Independent_Mode

2

Left_Independent_Mode

1

Transfer_Switch

05/20/2004

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)

One Time Step = 20 MS

5

Clock_Dec

4

RL_Channel_Clock

3

Right_FGS_Clock

2

LR_Channel_Clock

1

Left_FGS_Clock

Rate

Drif t

Calendar_Decrement

Initial

Time_Remaining

Clock

Right_FGS_Calendar

Rate

Calendar_Decrement

Initial

Time_Remaining

Clock

RL_Channel_Calendar

1

1

2

2

5

5

min

Rate

Drif t

Calendar_Decrement

Initial

Time_Remaining

Clock

Left_FGS_Calendar

Rate

Calendar_Decrement

Initial

Time_Remaining

Clock

LR_Channel_Calendar

4

Right_FGS_Initial

3

Right_FGS_Drift

2

Left_FGS_Initial

1

Left_FGS_Drift

05/20/2004

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

05/20/2004

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

page 1 analysis of asynchronous systems steven p. miller michael w. whalen {spmiller,...

Documents