Model-Based Safety Analysis

7/29/2019 Model-Based Safety Analysis

1/49

Advanced Technology Center Slide 1

Model-Based Safety AnalysisOverview

Dr. Steven P. Miller

Dr. Mats P. E. Heimdahl

Advanced Computing Systems

Rockwell Collins

400 Collins Road NE, MS 108-206

Cedar Rapids, Iowa 52498

[email protected]


2/49


Outline of Presentation

Motivation

Proposed Approach

Demonstration

Analysis

Whats Next


3/49


Motivation

Error in FCLSelection Logic

Active FGSSends Incorrect

Guidance Values

Inactive FGSSends IncorrectGuidance Values

Error Internalto AP

Error Internalto FD

Incorrect GuidanceValues Received

From FGS

Incorrect

Guidance

FCL Generates

Incorrect GuidanceValues

Error in FGSInputs

Error in FCLAlgorithm

Not Shown




Guidance Values


Guidance Values

Inactive FGSSends IncorrectGuidance Values

Error Internalto AP

Error Internalto AP

Error Internalto FD

Error Internalto FD


From FGS


From FGS

Incorrect

Guidance

Incorrect

Guidance

FCL Generates


Error in FGSInputs


FCL Generates


FCL Generates


Error in FGSInputs

Error in FGSInputs



Not Shown

Requirements andDesign DocumentsSafety

Analyst A

System Safety Analysis is

- Based on Informal Specifications

- Highly Dependent on Skill of the Analyst

Safety

Analyst B


4/49


Model-Based Development

Requirements

Modeling

Simulation

AutomatedAnalysis

Autocode

Autotest

Reuse

We Base the Entire

Development Cycle

Around the Model

Why Not the

Safety Analysis?


5/49


Model-Based Safety Analysis

Add Fault Model for Physical System

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

SystemA

Power B

Pedal 2 System

B

Plant

Model

AntiSkid

Command

Braking+

AntiSkid

Command

Green Pump Blue Pump

Isolation ValveIsolation Valve

Shut

Normal

SystemN

OR

MA

L

A

L

T

ER

N

A

T

E

AccumulatorPump

Meter

ValveMeterValve

MeterValve

Accumulator

Valve

Mechanical

Pedal

Selector Valve

Loss AllBraking

Normal SysLoss

Green PumpLoss

Meter ValveLoss

BSCU Lossof Command

PowerSupplies

Fail

BSCU SelectSignalInverted

Alt SysLoss

Acc/AS/MechMeter Fails

Both PumpsFail

Bl ue Fa il s A cc Fa il s

SelValveStuck

Model the Digital Controller Architecture

Automation Enables What-If Consideration of System Designs

and Digital Controller Architecture

Integrates System and Safety Engineering About a Common Model

and the Physical System


6/49


Advantages

Common Model for Both System and Safety Engineering

Safety Analysis Based on a Formal System Model

Facilitates Consistencyin Safety Analysis

Facilitates Completenessof Safety Analysis

Reduced Manual Effort in Error-prone Areas

Automated Support for Safety Analysis

Explore Various Failure Scenarios

Focus on Review on Assumptions in the Models Is the System Model Correct?

Is the Fault Model Complete?

Assume the (Automated) Analysis is Trustworthy


7/49Advanced Technology Center Slide 7


Motivation

Proposed Approach

Demonstration

Analysis

Whats Next



PSSAs SSAs

System Requirements and

Objectives

Aircraft FHA

System FHAs

System FTAs

Derived Safety

Requirements

Design

System FMEAs

Aircraft FTA

System FTAs

Certification

Aircraft Integration Cross-check

System Integration Cross-check

FC&C

FC&C

FE&P

FE&P

Verify that the implemented

system satisfies the safety

requirements and develop

certification documents

Safety analysis performed as anintegral part of theiterativesystem development process

(Requirements, Architecture,

Design)

Traditional Safety Analysis Process



PSSAs SSAs

System Requirements and

Objectives

Aircraft FHA

System FHAs

System FTAs

Derived Safety

Requirements

Design

System FMEAs

Aircraft FTA

System FTAs

Certification

Aircraft Integration Cross-check

System Integration Cross-check

FC&C

FC&C

FE&P

FE&P

Verify that the implemented

system satisfies the safety

requirements and develop

certification documents

Safety analysis performed as anintegral part of theiterativesystem development process

(Requirements, Architecture,

Design)


Incremental development

of the system model.

Support for automated

safety analysis.

Automated replay of

safety analysis as

the system is changed.



Creation of Nominal System Model

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

System

A

Power B

Pedal 2 System

B

Model of the Digital System Verify safetyproperties of thenominal digital

system

Library of Common

Mechanical Components

Verify safety

properties of the

nominal system

PlantModel

AntiSkidCommand

Braking+AntiSkid

Command



ShutNormalSystem

NORMA

L

ALTER

NATE

Accumulator

Pump

MeterValve

MeterValve

MeterValve

AccumulatorValve

MechanicalPedal

Selector Valve

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

Power B

Pedal 2 System

B

Model of the Digital System +

Model of the Mechanical System



Creation of the Fault Model

PlantModel

AntiSkidCommand

Braking+AntiSkid

Command



ShutNormalSystem

NORMAL

ALTERN

ATE

AccumulatorPump

MeterValve

MeterValve

Meter

Valve

AccumulatorValve

MechanicalPedal

Selector Valve

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

System

A

Power B

Pedal 2 System

B

Library of CommonFailure Modes

Fault Model

SystemArchitecture

Component (or

Component Type)

Failure Mode Type of

Failure

Additional constraints

Isolation Valve, Meter

Valve : Valve

Stuck at Open

or Closed

Permanent -

Power Supply Value not in

range

Transient Propagate to all

components connected to

the Power supply

Braking System

Control Unit

Inverted signal Transient Simultaneous failure on all

outputs of BSCU

Green Pump, BluePump :Pump

Pressure belowthreshold

Permanent -



Auto-generation of Fault Trees

Automated Safety Analysis

Formalized

Safety

Requirements+

PlantModel

AntiSkidCommand

Braking+AntiSkid

Command



ShutNormalSystem

NORMAL

ALTERN

ATE

AccumulatorPump

MeterValve

MeterValve

Meter

Valve

AccumulatorValve

MechanicalPedal

Selector Valve

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

System

A

Power B

Pedal 2 System

B

Proof Tree for P

P

A is ok

Components

A1, A

2, A

3all

work as

expected

Connections

c1,2

,c1,3

,c2,3

are all ok

E1

is

ok

E2

is

ok

E3

is

ok

E is ok

Proofs of Safety Properties

Simulation




Easy to Generate Two-Level Fault Trees

Minimal Cut Sets of Events that Can Cause a Hazard

Two Levels Deep and a Mile Wide

Harder to Generate Useful Fault Trees

Intermediate Levels Reflect System Architecture

Essential for Acceptance by Safety Engineers



Proof of Safety Properties

Mathematical Proof Avoids Mile Wide Problem

with Fault Trees

User Guides the ProofStructure to Reflect the

System Architecture

Used For Backward Search Proof will Expose All Minimal

Cut Sets of Events

Extend Fault Model to Rule

Out Acceptable Minimal CutSets

Repeat Until Proof isCompleted

Proof Tree for P

P

A is ok

Components

A1

, A2

, A3

all

work as

expected

Connections

c1,2

,c1,3

,c2,3

are all ok

E1

is

ok

E2

is

ok

E3

is

ok

E is ok

C d B t



Correspondence Between

Fault Trees and Proof Trees

A

A1

A2

A3

c2,3

c1,3E

1

E2

E3

Is Psatisfied?

c1,2

Fault Tree for !P

TLE for !P

A fails

E1

fails

E2

fails

E3

failsOne or more

Components

A1, A

2, A

3fail

One or more

Connections

c1,2

,c1,3

,c2,3

fail

E fails

Proof Tree for P

P

A is ok

Components

A1, A

2, A

3all

work as

expected

Connections

c1,2

,c1,3

,c2,3

are all ok

E1

is

ok

E2

is

ok

E3

is

ok

E is ok

Complements

w.r.t. each other



Summary Model-Based Safety Analysis

Integrates System and Safety Engineering About aCommon Model

Automated Analysis of System Safety Properties

Makes Safety Analysis More Systematic and Repeatable

Shifts Focus from Component to Architectural Models

Reduces the Workload of Safety Engineers

Automates More of the Safety Analysis

Eliminates the Need to Review the Analysis

Focus on Review of the System Model and the Fault Model



Challenges for Future Research

Fault Models What is a Fault Model? How Do We Represent It?

Merging the Fault Model and the Nominal Model Aspect Orientation and Aspect Weaving?

Stating Safety Properties Simple Safety Properties are Often Difficult to State Formally

Do We Need a New Language for Safety Properties?

Presentation of the Analysis Fault Trees Need to Reflect the System Architecture

Scalability Analysis of Complex, Asynchronous, System Models

Technology Transfer Need a Gradual Evolution from Existing Practices



Model-Based Safety AnalysisDemonstration

Dr. Mats P. E. Heimdahl

University of Minnesota

[email protected]

Dr. Steven P. Miller

Advanced Computing Systems

Rockwell Collins

[email protected]




Motivation

Proposed Approach

Demonstration

Analysis

Whats Next




Add Fault Model for Physical System

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

SystemA

Power B

Pedal 2 System

B

Plant

Model

AntiSkid

Command

Braking+

AntiSkid

Command



Shut

Normal

SystemN

OR

M

AL

A

L

T

E

R

N

A

T

E

AccumulatorPump

Meter

ValveMeterValve

MeterValve

Accumulator

Valve

Mechanical

Pedal

Selector Valve

Loss AllBraking

Normal SysLoss

Green PumpLoss

Meter ValveLoss

BSCU Lossof Command

PowerSupplies

Fail

BSCU SelectSignalInverted

Alt SysLoss

Acc/AS/MechMeter Fails

Both PumpsFail

Bl ue Fa il s A cc Fa il s

SelValveStuck

Model the Digital Controller Architecture

Automation Enables What-If Consideration of System Designs

and Digital Controller Architecture

Integrates System and Safety Engineering About a Common Model

and the Physical System




Automated Safety Analysis

Formalized

Safety

Requirements+

PlantModel

AntiSkid

Command

Braking+AntiSkid

Command



ShutNormalSystem

NORMAL

ALTERNATE

AccumulatorPump

MeterValve

MeterValve

Meter

Valve

AccumulatorValve

MechanicalPedal

Selector Valve

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

System

A

Power B

Pedal 2 System

B

Proof Tree for P

P

A is ok

Components

A1, A

2, A

3all

work as

expected

Connections

c1,2

,c1,3

,c2,3

are all ok

E1

is

ok

E2

is

ok

E3

is

ok

E is ok

Proofs of Safety Properties

Simulation

Wheel Brake System (WBS) Example


22/49


Wheel Brake System (WBS) Example

ARP 4761

Proof of Concept Concrete Demonstration of Main Ideas

Modeling and Analysis Using Existing Tools

Simulink for Modeling the System

NuSMV, Prover, and PVS for Analyzing the System

Why the Wheel Brake System?

ARP 4761 - Guidel ines and Methods for Cond uc t ing the Safety

As sessment Process on Civ il Airborne Systems and Equipment

Familiar Example to Safety Engineers

Benchmark our Results Against ARP-4761 Safety Analysis

Small but Complex Enough to Capture Interesting Behaviors


23/49


Wheel Brake System

WBS is Composed of Two Redundant Hydraulic Lines :

Normal & Alternate

Hydraulic Pumps

Number of Hydraulic Valves

Braking System Control Unit(BSCU)

BSCU is Composed of

Two Command Units Compute

Braking and Antiskid Commands

Two Monitors Check Validity of

the Associated Command Units

BSCU is Valid if One of the

Command Unit is ValidFigure borrowed from ARP 4761


24/49


Normal & Alternate Hydraulic Lines

Normal Hydraulic line Main System Supplying Braking Pressure to the Wheel

BSCU Provides Braking and Antiskid Commands

Alternate Hydraulic Line

Braking Achieved Manually Via Mechanical Pedal

BSCU Provides Antiskid Command

Switch-over from Normal to Alternate Line When

Green Pump or Any Component along Normal Line Fails or

BSCU Becomes Invalid

Selector and Isolation Valves Used for the Switch-over

Alternate Line Stays Active Until WBS System is Reset

Add WBS Failure Modes


25/49


Add WBS Failure Modes

to Nominal Model

Hydraulic Failure Modes

Pumps Pressu re Below Threshold (X)

Valves Stuck at Closed/Open (S)

Digital System Failure Modes

Monitor Unit Outpu t Inverted (I)

Command Unit Output Stuc k (O)

Power Failure Loss of Power (L)

I

X X

X

S S

S

S

S S

O O

I

LL

Manually Extended the Nominal Model with Failure Modes


26/49



Motivation

Proposed Approach

Demonstration

Analysis

Whats Next


27/49


WBS Model-Based Safety Analysis

Formal

Model

System FMEAsDerived Safety

Requirements

Automated Requirements

Verification

Fault

Model

Formal Model

with Failures

Automated Fault

Tolerance Verification

Loss of all

wheel braking

Nomin al Wheel Brake

System in Simul ink

Safety requirem ent

form alized and v er if ied in

NuSMV

Formalized basic

fai lure modes in

Simul ink

Extended Wheel Brake

System in Simul ink

Safety requirement in

presence of n faul ts

form alized and ver if ied in

NuSMV

NO Loss of all

wheel braking

Manual Model

Extens ion

System Hazard

Analysis

Verified Safety Properties


28/49


Verified Safety Properties

in Nominal Model

Safety Requirement from ARP 4761 Loss of All Wheel Braking (Unannunciated or Annunciated) During Landing

or RTO Shall Be Less Than 5*10-7 Per Flight

Revised Safety Requirement

When the Pedal Is Pressed, Then Either the Normal or the AlternatePressure Shall Be Above Threshold

Formalized in NuSMV asDEFINE Pedal_Pressed = (PedalPos > 0 & PedalPos < 5)

SPEC AG (Pedal_Pressed ->

(Normal_Pressure > 0 | Alternate_Pressure > 0))

Second Revised Safety Requirement

When the Pedal Is Pressed and There Is No Skidding, Then Either the

Normal or the Alternate Pressure Should Be Above Threshold Formalized in NuSMV as

DEFINE Pedal_Pressed = (PedalPos > 0 & PedalPos < 5)

SPEC AG ((Pedal_Pressed & !Skid) ->(Normal_Pressure > 0 | Alternate_Pressure > 0))

Verified on the Nominal Simulink Model Using NuSMV


29/49


Safety Properties

Example Safety PropertyIf There Is One Failure and the Pedal Is Pressed in Absence of

Skidding, Then Either the Normal Pressure or the Alternate

Pressure Shall Be Above the Threshold

Transient Failures Failures May Last an Arbitrary Time Before Recovery of the Component

Failures Triggers Are Non-deterministic Inputs and Inherently Transient

Permanent Failures

Failures Are Permanent, a Failed Component Never Recovers Latch Fault Trigger Inputs to Simulate Permanent Failure

Simultaneous Failures

Count the Number of Active Fault Triggers


30/49


Fault Tolerance Verification

Transient Failures If There Is One Failure and the Pedal Is Pressed in Absence of Skidding, Then Eitherthe Normal Pressure or the Alternate Pressure Shall Be Above the Threshold

SPEC AG((NumFails = 1 & Pedal_Pressed & !Skid) ->

(Normal_Pressure > 0 | Alternate_Pressure > 0))

Several Steps May be Needed to Detect and Respond to Some Failures

SPEC AG((NumFails = 1 & Pedal_Pressed & !Skid) >

AX((NumFails = 1 & Pedal_Pressed & ! Skid) >

AX ((NumFails = 1 & Pedal_Pressed & !Skid) ->

(Normal_Pressure > 0 | Alternate_Pressure > 0))))

Plant

Model

AntiSkidCommand

Braking+AntiSkid

Command



ShutNormalSystem

NORMAL

ALTERNATE

AccumulatorPump

MeterValve

MeterValve

MeterValve

AccumulatorValve

MechanicalPedal

Selector Valve

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

System

A

Power B

Pedal 2 System

B

X X


31/49


Fault Tolerance Verification

Permanent Failures Holds for One Permanent Failure

SPEC AG((NumFails = 1 & Pedal_Pressed & !Skid) >

AX((NumFails = 1 & Pedal_Pressed & ! Skid) >

AX ((NumFails = 1 & Pedal_Pressed & !Skid) ->

(Normal_Pressure > 0 | Alternate_Pressure > 0))))

Plant

Model

AntiSkid

Command

Braking +

AntiSkid

Command



Shut

Normal

SystemN

O

RM

A

L

A

L

TE

R

N

A

T

E

Accumulator

Pump

Meter

ValveMeter

Valve

Meter

Valve

Accumulator

Valve

Mechanical

Pedal

Selector Valve

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

System

A

Power B

Pedal 2 System

B


32/49


Fault Trees and Proof Trees Revisited

A

A1

A2

A3

c2,3

c1,3E

1

E2

E3

Is Psatisfied?

c1,2

Fault Tree for !P

TLE for !P

A fails

E1

fails

E2

fails

E3

failsOne or more

Components

A1, A

2, A

3fail

One or more

Connections

c1,2

,c1,3

,c2,3

fail

E fails

Proof Tree for P

P

A is ok

Components

A1, A

2, A

3all

work as

expected

Connections

c1,2

,c1,3

,c2,3

are all ok

E1

is

ok

E2

is

ok

E3

is

ok

E is ok

Complements

w.r.t. each other


33/49


WBS PVS Proof Tree

Prop.1.1 :

[-1] Alt_Meter_2_Fail(s!1)

[-2] Alt_Meter_2_Fail(s!1)

{-3} FM_WBS_Ext_BSCU_Node.Alternate_Pressure(s!1) = 0[-4] Nor_Meter_Fail(s!1)

[-5] FM_WBS_Ext_BSCU_Node.Normal_Pressure(s!1) = 0

[-6] 0 < PedalPos1(s!1)

|-------

[1] Alt_Meter_2_Stuck_Val(s!1)


[3] Nor_Meter_Stuck_Val(s!1)

[4] Skid(s!1)

[5] 0 < FM_WBS_Ext_BSCU_Node_Fault.Normal_Pressure(s!1)

[6] 0 < FM_WBS_Ext_BSCU_Node_Fault.Alternate_Pressure(s!1)

PlantMod

el

AntiSkidCommand

Braking+AntiSkid

Command



ShutNormalSystem

NORMAL

ALTERNATE

AccumulatorPump

MeterValve

MeterValve

MeterValve

AccumulatorValve

MechanicalPedal

Selector Valve

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

System

A

Power B

Pedal 2 System

B

X X

Prop :

{-1} 0 < PedalPos1(s!1)|-------

{1} Skid(s!1)

{2} 0 < FM_WBS_Ext_BSCU_Node_Fault.Normal_Pressure(s!1)

{3} 0 < FM_WBS_Ext_BSCU_Node_Fault.Alternate_Pressure(s!1)

S/ C


34/49


PVS/Fault Tree Challenges

Difficult Proofs Completing Proofs is Still a Time Consuming Process

Level of Detail in Proofs

Current Proofs are Low Level, Fault Trees Must beHigh Level Proofs Performed at Detailed Behavioral Level

Fault Trees Must be Presented at an Architectural Level

Proof Structure Proof Structure Appropriate for Fault Tree Generation

Must be Obtained May or May Not be the Most Natural Way to Pursue the Proof

D i /A l i S


35/49


Demonstration/Analysis Summary

Simulation and Visualization of Software, Digital, andAnalog Failures Simulink Models of Nominal System Coupled with Fault Models

Enable Flexible Simulation

Model Checking Techniques Enable Flexible Analysis Verification of Correctness Under Normal Conditions

Verification of Desirable Fault-tolerance Properties

Theorem Proving Holds Promise as Powerful Fault TreeGeneration Tool Open Issues Still Remain

O tli f P t ti


36/49



Motivation

Proposed Approach

Demonstration

Analysis

Whats Next

Wh t N t


37/49


Whats Next

Improving Modeling Process

Ease of Analysis

Presentation of Analysis Results

Scalability

I i th M d li P


38/49


Improving the Modeling Process

Nominal

System Model

Extended

System Model# of Inputs 7 27

# of Signals 45 65

Changed/Added Blocks 13

Building Extended Model is a Manual Process

Difficult to Keep Nominal & Extended Model in Sync.

Fault Triggers are Added as New Inputs

Handle Transient and Permanent Faults Differently

Fault Model Clutters Nominal Model


39/49

I i th M d li P


40/49



Modeling the Mechanical System Need Libraries of Common Components

Creating the Fault Model

What Exactly is a Fault Model? What is part of nominal system?

What goes in fault model?

Types of Faults, Interactions Between Faults, and Fault

Locations Auto generate the Extended System Model

Use Tools to Merge Nominal and Fault Model

I i th M d li P


41/49



Aspect-Oriented Model ing

Specify Faults as Aspectsof System Components

Automatically Weave Faults into Nominal Model

Nominal and Extended Model Always in Sync

Reduces Potential for Human Error

Hide Fault Trigger Inputs during Simulation

E f A l i


42/49


Ease of Analysis

Safety Properties Can be Awkward toSpecify:

Usually, Properties are Conceptually Simple

Complexity Comes From Mapping Simple

Conceptual Ideas to Formal Specification

Antecedent = ((pre (pre (pre ((NumFails = 1) and FailRec4Step))) and

pre (pre ((AllPedNoSkid and not (Changed)))) and

pre ((AllPedNoSkid and not (Changed))) and

(AllPedNoSkid and not (Changed)))) ;

Consequent = (pre (pre (SomePressure)) or pre (SomePressure) or SomePressure) ;

Prop_MultiStepSingleFail4 =fby( Implies(Antecedent, Consequent), 4, true);

E f A l i


43/49


Ease of Analysis

Many Safety Properties are Stylized

Given nfailures (or all failure combinations

whose combined probability is >10-k), is it

possible that the system will fail? Fai lure cond it ionis usually straightforward to specify

Property complexity arises when considering recovery t ime

and fault prop agat ion

Create a Property Builder to Assist

Specification of Safety Properties



44/49



Currently: Proof or Counterexample

We Want Something Acceptable To SafetyEngineers

TIMES 1 2 3 4 5

INPUTS

Chg_Coupled_Side 1 1 0 1 0

SYNC_Switch 1 1 0 1 0

GA_Switch 1 1 1 1 1LAPPR_Capture 1 0 1 1 0

HDG_Switch 1 1 1 1 0

VAPPR_Capture 1 1 1 0 1

SPD_Switch 1 1 1 1 1

OUTPUTS

LAT_Mode 1 1 3 3 1

LAT_Sync_Out 1 0 1 0 1VER_Mode 1 1 1 1 1

VER_Sync_Out 0 1 0 1 0

Fault Trees using Model Checker


45/49


Fault Trees using Model Checker

FSAP Defines Flat Fault Trees

We Can do Better by EncodingArchitecture of System Into Fault Tree

Formal System Model

Safety Requirements

Failure Modes

FSAP/

NuSMV-SAFault Tree

Proof Trees and Fault Trees


46/49


Proof Trees and Fault Trees

A

A1

A2

A3

c2,3

c1,3E

1

E2

E3

Is Psatisfied?

c1,2

Fault Tree for !P

TLE for !P

A fails

E1

fails

E2

fails

E3

failsOne of more

Components

A1, A

2, A

3fail

One or more

Connections

c1,2

,c1,3

,c2,3

fail

E fails

Proof Tree for P

P

A is ok

Components

A1, A

2, A

3all

work as

expected

Connections

c1,2

,c1,3

,c2,3

are all ok

E1

is

ok

E2

is

ok

E3

is

ok

E is ok

Complements

w.r.t. each other

PVS Proof Trees


47/49


PVS Proof Trees

Prop.1.1 :

[-1] Alt_Meter_2_Fail(s!1)[-2] Alt_Meter_2_Fail(s!1)

{-3} FM_WBS_Ext_BSCU_Node.Alternate_Pressure(s!1) = 0

[-4] Nor_Meter_Fail(s!1)

[-5] FM_WBS_Ext_BSCU_Node.Normal_Pressure(s!1) = 0

[-6] 0 < PedalPos1(s!1)

|-------



[3] Nor_Meter_Stuck_Val(s!1)

[4] Skid(s!1)

[5] 0 < FM_WBS_Ext_BSCU_Node_Fault.Normal_Pressure(s!1)

[6] 0 < FM_WBS_Ext_BSCU_Node_Fault.Alternate_Pressure(s!1)

PlantMod

el

AntiSkidCommand

Braking+AntiSkidCommand



ShutNormalSystem

NORMAL

ALTERNATE

AccumulatorPump

MeterValve

MeterValve

MeterValve

AccumulatorValve

MechanicalPedal

Selector Valve

Power A

Pedal 1

Feed back

Plant

Fault Tolerant

Control Unit

( BSCU )

Braking System

System

A

Power B

Pedal 2 System

B

X X

Prop :

{-1} 0 < PedalPos1(s!1)

|-------

{1} Skid(s!1){2} 0 < FM_WBS_Ext_BSCU_Node_Fault.Normal_Pressure(s!1)

{3} 0 < FM_WBS_Ext_BSCU_Node_Fault.Alternate_Pressure(s!1)



48/49



Difficult Proofs Completing Proofs is Still a Time Consuming Process

Level of Detail in Proofs

Current Proofs are Low Level, Fault Trees Must beHigh Level Proofs performed at detailed behavioral level

Fault trees must be presented at an architectural level

Proof Structure Proof Structure Appropriate for Fault Tree Generation

Must be Obtained May or may not be the most natural way to pursue the proof

Future Research Goals


49/49

Future Research Goals

Investigate Fault Models

Relationship between fault model and nominal system

What is a reasonable and flexible fault model?

Automate Fault Injection Into the Nominal Model Aspect orientation and aspect weaving?

Flexible Notation for Capturing Safety Properties Safety modeling language?

Automate Fault Tree Generation

Fault trees acceptable for safety-engineers and acceptable forcertification

Safety Analysis Methodology Who will build the fault model?

Who performs what analysis?