Model-Based Safety Analysis

Model-Based Safety Analysis
Overview
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 spmiller@rockwellcollins.com
Advanced Technology Center
Slide 1
Outline of Presentation
Motivation Proposed Approach
Demonstration
Analysis Whats Next
Advanced Technology Center Slide 2
Motivation
Requirements and Design Documents
Safety Analyst A
Safety Analyst B
System Safety Analysis is

- Based on Informal Specifications - Highly Dependent on Skill of the Analyst
Incorrect Guidance Error Internal to AP Incorrect Guidance Values Received From FGS Error Internal to FD
Active FGS Sends Incorrect Guidance Values
Inactive FGS Sends Incorrect Guidance Values
Not Shown Error in FCL Selection Logic FCL Generates Incorrect Guidance Values
Error in FGS Inputs
Error in FCL Algorithm
Slide 3
Model-Based Development
Reuse
Requirements
Autotest
Modeling
Why Not the Safety Analysis?
Autocode
Simulation
Automated Analysis
We Base the Entire Development Cycle Around the Model


Green Pump Blue Pump
Loss All Braking
Isolation Valve Isolation Valve Power A Pedal 1 Plant Feed back Pedal 2 Power B
System A
Shut Normal System
N O R M A L
Selector Valve A Accumulator L Valve T E Accumulator R Pump N Meter A Valve Mechanical T Pedal E Meter Valve
Meter Valve
Normal Sys Loss
Alt Sys Loss
SelValve Stuck
Green Pump Loss
Meter Valve Loss
BSCU Loss of Command
Acc/AS/Mech Meter Fails
Both Pumps Fail
System B
AntiSkid Command Fault Tolerant Braking System Control Unit ( BSCU ) Braking+ AntiSkid Command
Power Supplies Fail
BSCU Select Signal Inverted
Blue Fails
Acc Fails
Plant Model
Model the Digital Controller Architecture and the Physical System Add Fault Model for Physical System and Digital Controller Architecture Integrates System and Safety Engineering About a Common Model Automation Enables What-If Consideration of System Designs
Slide 5
Advantages
Common Model for Both System and Safety Engineering Safety Analysis Based on a Formal System Model Facilitates Consistency in Safety Analysis Facilitates Completeness of 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
Demonstration
Analysis Whats Next
Traditional Safety Analysis Process
System Requirements and Objectives
Certification
Aircraft FHA
FC&C
Aircraft Integration Cross-check

FE&P
System FHAs
FC&C
System Integration Cross-check
Aircraft FTA
FE&P
PSSAs
System FTAs
SSAs
System FTAs
Derived Safety Requirements
System FMEAs
Safety analysis performed as an integral part of the iterative system development process (Requirements, Architecture, Design)
Design
Verify that the implemented system satisfies the safety requirements and develop certification documents
Slide 8
System Requirements and Objectives
Certification
Aircraft FHA
FC&C
Aircraft Integration Cross-check

FE&P
System FHAs
FC&C
System Integration Cross-check
Aircraft FTA
FE&P
Incremental development of the system model. Support for automated safety analysis.
PSSAs
System FTAs
SSAs
System FTAs
Automated replay of safety analysis as the system is changed.
Derived Safety Requirements
System FMEAs
Safety analysis performed as an integral part of the iterative system development process (Requirements, Architecture, Design)
Design
Verify that the implemented system satisfies the safety requirements and develop certification documents
Slide 9
Creation of Nominal System Model

Model of the Digital System
Power A Pedal 1
System A
Verify safety properties of the nominal digital system
Library of Common Mechanical Components
Plant
Feed back Pedal 2 Power B
System B
Green Pump
Blue Pump
Isolation Valve Isolation Valve Fault Tolerant Braking System Control Unit ( BSCU )
Power A
Pedal 1 Selector Valve Shut Normal System
N O R M A L
Plant Feed back

Pedal 2 Power B
System B
AntiSkid Command
Braking + AntiSkid Command Meter Valve
A Accumulator L Valve T E Accumulator R Pump N Meter A Valve Mechanical T Pedal E

Meter Valve
Verify safety properties of the nominal system
Fault Tolerant Braking System Control Unit ( BSCU )
Plant Model
Model of the Digital System + Model of the Mechanical System

Creation of the Fault Model

System Architecture
Library of Common Failure Modes
System A
Selector Valve Shut Normal System

N O R M A L
System B
AntiSkid Command Braking + AntiSkid Command
Meter Valve
Meter Valve
Plant Model
Fault Model
Component (or Component Type)
Green Pump, Blue Pump :Pump
Failure Mode
Pressure below threshold
Type of Failure
Permanent
Additional constraints
-
Isolation Valve, Meter Valve : Valve Power Supply
Stuck at Open or Closed Value not in range
Permanent
Transient
Propagate to all components connected to the Power supply Simultaneous failure on all outputs of BSCU
Braking System Control Unit
Inverted signal
Transient
Slide 11
Automated Safety Analysis

System A

N O R M A L
System B
Simulation
Proof Tree for P P
Formalized Safety Requirements
Meter Valve
Meter Valve
Plant Model
A is ok
E is ok
Components A1, A2, A3 all work as expected
Connections c1,2,c1,3,c2,3 are all ok
E1 is ok
E3 is ok
E2 is ok
Proofs of Safety Properties

Auto-generation of Fault Trees
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 Proof Structure to Reflect the System Architecture
Proof Tree for P P
Used For Backward Search Proof will Expose All Minimal

Cut Sets of Events Extend Fault Model to Rule Out Acceptable Minimal Cut Sets Repeat Until Proof is Completed
A is ok
E is ok
E1 is ok
E3 is ok
E2 is ok
Slide 14
Correspondence Between Fault Trees and Proof Trees

A Is P satisfied?
E1
A1 c1,2
c1,3 A3 c2,3 E3
Fault Tree for !P TLE for !P
E2
A2
Proof Tree for P P
Complements w.r.t. each other
A fails
E fails
A is ok
E is ok
One or more Components A1, A2, A3 fail
One or more Connections c1,2,c1,3,c2,3 fail
E1 fails
E3 fails
E2 fails
E1 is ok
E3 is ok
E2 is ok
Slide 15
Summary Model-Based Safety Analysis
Integrates System and Safety Engineering About a Common 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
Slide 16
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

Demonstration
Dr. Mats P. E. Heimdahl
University of Minnesota heimdahl@cs.umn.edu Dr. Steven P. Miller
Advanced Computing Systems

Rockwell Collins spmiller@rockwellcollins.com
Slide 18
Demonstration
Analysis Whats Next

Loss All Braking
System A
Shut Normal System
N O R M A L
Selector Valve A Accumulator L Valve T E Accumulator R Pump N Meter A Valve Mechanical T Pedal E Meter Valve
Meter Valve
Normal Sys Loss
Alt Sys Loss
SelValve Stuck
Green Pump Loss
Meter Valve Loss
BSCU Loss of Command
Acc/AS/Mech Meter Fails
Both Pumps Fail
System B
AntiSkid Command Fault Tolerant Braking System Control Unit ( BSCU ) Braking+ AntiSkid Command
Power Supplies Fail
BSCU Select Signal Inverted
Blue Fails
Acc Fails
Plant Model
Model the Digital Controller Architecture and the Physical System Add Fault Model for Physical System and Digital Controller Architecture Integrates System and Safety Engineering About a Common Model Automation Enables What-If Consideration of System Designs
Slide 20
Automated Safety Analysis

System A

N O R M A L
System B
Simulation
Proof Tree for P P
Formalized Safety Requirements
Meter Valve
Meter Valve
Plant Model
A is ok
E is ok
E1 is ok
E3 is ok
E2 is ok
Proofs of Safety Properties

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 - Guidelines and Methods for Conducting the Safety
Assessment Process on Civil 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
Slide 22
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 Valid
Slide 23
Figure borrowed from ARP 4761
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 to Nominal Model

Manually Extended the Nominal Model with Failure Modes
Hydraulic Failure Modes

L I I L X S X S
Pumps Pressure Below Threshold (X) Valves Stuck at Closed/Open (S)

X
S O O S
Digital System Failure Modes
Monitor Unit Output Inverted (I) Command Unit Output Stuck (O)
Power Failure Loss of Power (L)
Slide 25
Demonstration
Analysis Whats Next
WBS Model-Based Safety Analysis
Loss of all wheel braking
System Hazard Analysis Derived Safety Requirements
NO Loss of all wheel braking
System FMEAs
Nominal Wheel Brake System in Simulink
Formal Model
Formal Model with Failures Manual Model Extension
Extended Wheel Brake System in Simulink
Automated Requirements Verification
Fault Model
Automated Fault Tolerance Verification Safety requirement in presence of n faults formalized and verified in NuSMV
Safety requirement Formalized basic formalized and verified in failure modes in NuSMV Simulink
Slide 27
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 Alternate
Pressure Shall Be Above Threshold
Formalized in NuSMV as
DEFINE 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

Slide 28
Safety Properties
Example Safety Property
If 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

Fault Tolerance Verification

Transient Failures
If 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
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))))
Isolation Valve Isolation Valve Power A Pedal 1 Plant Feed back
System A

N O R M A L
Pedal 2
Power B
System B
A Accumulator L Valve T E Accumulator R Pump N Meter A Valve Mechanical T Pedal E Meter Valve
X
Meter Valve
Plant Model
Slide 30
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))))
Isolation Valve Power A Pedal 1
Isolation Valve
System A
Shut Normal System
N O R M A L
Selector Valve
A L T E R N A T E
Plant
Feed back Pedal 2

Power B
Accumulator Valve
System B
AntiSkid Command Fault Tolerant Braking System Control Unit ( BSCU ) Braking + AntiSkid Command
Accumulator Pump
Meter Valve
Mechanical Pedal
Meter Valve
Meter Valve
Plant Model
Slide 31
Fault Trees and Proof Trees Revisited
Is P satisfied?
E1
A1 c1,2
c1,3 A3 c2,3 E3
E2
A2
Proof Tree for P P
A fails
E fails
A is ok
E is ok
One or more Components A1, A2, A3 fail
E1 fails
E3 fails
E2 fails
E1 is ok
E3 is ok
E2 is ok
Slide 32
WBS PVS Proof Tree

Prop : Isolation Valve Isolation Valve Power A Pedal 1 {-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)
System A
Selector Valve
Shut Normal System
N O R M A L
Plant Feed back

Pedal 2 Power B
System B
AntiSkid Command
Braking + AntiSkid Command
X Valve X Meter
AAccumulator L Valve T E Accumulator R Pump N Meter A Valve Mechanical T Pedal E

Meter Valve
Plant Mod el
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) [2] 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)
Slide 33
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 be
High 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
Slide 34
Demonstration/Analysis Summary
Simulation and Visualization of Software, Digital, and Analog 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 Tree Generation Tool Open Issues Still Remain
Slide 35
Motivation Proposed Approach Demonstration
Analysis
Whats Next
Whats Next
Improving Modeling Process
Ease of Analysis
Presentation of Analysis Results
Scalability
Slide 37
Improving the Modeling Process
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
Nominal System Model # of Inputs # of Signals Changed/Added Blocks 7 45 Extended System Model 27 65 13
Slide 38

Adding Faults Clutters the Nominal Model
[GP_Fail] [BP_Fail]
Green Pump [Green_P]
Blue Pump
Green Pump_Fail
Blue Pump_Fail
[Blue_P] [Alt_Active] NOT

[Green_Tag]
[Blue_Tag] [Alt_Active]
PipePressure PipePressure ValveShut ValveShut
NOT [GI_Val] [BI_Val]
Pressure_Out
Stuck_Flag
Stuck_at_Val
Valve_Shut
Pressure
Stuck_Flag
Stuck_at_Val
[GI_Fail]
[BI_Fail]
Green Pump Isolation_Stuck
Blue Pump Isolation_Stuck
Out1
ValidPower
Pwr1
[V_Fail] [Pwr1_Fail]
Pwr_Fail PwrOut Pwr1
Nor_Pressure
Sel_Alt
Alt_Pressure_Out
ValidPower
Pwr2
Nor_Pressure_Out
Alt_Pressure
Power_Fail
SelectorOff
SelectorValve 1 PedalPos1
Pedal1
[Acc_P]
[Pwr2_Fail]
Pwr_Fail PwrOut
Pwr2
Sel_Alt
Inverted
[S_Fail]
[S_Val]
Nor_In
Stuck_at_Val
Stuck_Flag
1 PedalPos1
Pedal1
Sel_Active
Alt_In
Power_Fail1
Out1
Valve_Shut
Pressure
Green Pump IsolationValve
Blue Pump IsolationValve
Pressure_Out
Nor_Out
Selector_Stuck
[Acc_Tag]
2 PedalPos2
Pedal2
PipePressure PipePressure_Out ResPressure AltActive
Pedal2
Alt_Out
[Acc_Meter_Fail]
Accumulator Pump [Alt_Active]
PedalPos2
[Alt_Active] [AP_Fail] [Acc_Stuck_Val]
4 AutoBrake
AutoBrakeOn
4 AutoBrake
AutoBrakeOn
PipePressure
ReservePressure
AccumulatorValve
Nor_Cmd
Nor_Cmd
[NorValveCmd] AccumulatorValve_Stuck
[NorValveCmd]
5 DecRate
DecRate
DecRate
AC_Speed
7 AC_Speed
AC_Speed
Unit Delay 1 z [NorP_Feedback] 1 z [AltValveCmd] [AltP_Feedback]
AC_Speed [NorP_Feedback] 6 Skid

Skid
1 z
Pressure_Out
DecRate
Stuck_Flag
Stuck_Val
Pump_Fail2
AltActive
1 z
[AltP_Feedback]
6 Skid
Skid
[AS_AM_Val] [NorP_Feedback]
Nor_Pressure Alt_Cmd
PipePressure_In
CmdPos
Nor_Pressure Alt_Cmd
[AltValveCmd]
AS MeterValve
[AltP_Feedback]
Alt_Pressure
AS Meter_Stuck [Green_Tag]
Green_Pressure
[NorValveCmd] [Green_P]
Green_Pressure
PipePressure_In PipePressure_In CmdPos CmdPos
Cmd
Pos
3 MechPedal
[Blue_Tag]
Blue_Pressure
[NM_Val]
[NorValveCmd]
MechanicalPedal
[NM_Fail] [AM2_Val]
Cmd Pos
Out1
[AltP_Feedback]
Alt_Pressure
Stuck_at_Val
Stuck_Flag
Pressure
Cmd
[NorP_Feedback]
PipePressure_Out
[AltValveCmd]
[AS_AM_Fail]
[AltValveCmd]
3 MechPedal
PipePressure_Out
PipePressure_Out
[Blue_P]
Blue_Pressure
CMD/AS MeterValve
Manual MeterValve
[Acc_Tag]
Acc_Pressure Sy stemMode
MechanicalPedal [AM2_Fail]
Stuck_Flag
[Acc_P]
Acc_Pressure
Sy stemMode
[Nor_Out]
Out_NorP
Alternate_Pressure 2 [Nor_Out]
Out_NorP
BSCU
CMD/AS Meter_Stuck
Stuck_at_Val
Meter_Stuck
Stuck_at_Val
Stuck_Flag
Pressure
Out1
Out1
Pressure
Cmd
Cmd
Normal_Pressure 1 BSCU 1 z 3 System_Mode
Alternate_Pressure 2 Normal_Pressure 1
[Nor_Out]
1 z [Nor_Out]
System_Mode 3
Slide 39

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
Improving the Modeling Process Aspect-Oriented Modeling

Specify Faults as Aspects of 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
Slide 41
Ease of Analysis
Safety Properties Can be Awkward to Specify:
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);
Usually, Properties are Conceptually Simple
Complexity Comes From Mapping Simple Conceptual Ideas to Formal Specification

Ease of Analysis
Many Safety Properties are Stylized Given n failures (or all failure combinations
whose combined probability is >10-k), is it possible that the system will fail?
Failure condition is usually straightforward to specify Property complexity arises when considering recovery time and fault propagation
Create a Property Builder to Assist Specification of Safety Properties
Slide 43
Presentation of Analysis Results

Currently: Proof or Counterexample
TIMES INPUTS Chg_Coupled_Side SYNC_Switch GA_Switch LAPPR_Capture HDG_Switch VAPPR_Capture SPD_Switch OUTPUTS LAT_Mode LAT_Sync_Out VER_Mode VER_Sync_Out 1 2 3 4 5
1 1 1 1 1 1 1
1 1 1 0 1 1 1
0 0 1 1 1 1 1
1 1 1 1 1 0 1
0 0 1 0 0 1 1
1 1 1 0
1 0 1 1
3 1 1 0
3 0 1 1
1 1 1 0
We Want Something Acceptable To Safety Engineers

Fault Trees using Model Checker
Formal System Model
Safety Requirements
FSAP/ NuSMV-SA
Fault Tree
Failure Modes
FSAP Defines Flat Fault Trees We Can do Better by Encoding Architecture of System Into Fault Tree
Slide 45
Proof Trees and Fault Trees

A Is P satisfied?
E1
A1 c1,2
c1,3 A3 c2,3 E3
E2
A2
Proof Tree for P P
A fails
E fails
A is ok
E is ok
One of more Components A1, A2, A3 fail
E1 fails
E3 fails
E2 fails
E1 is ok
E3 is ok
E2 is ok
Slide 46
PVS Proof Trees

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)
Isolation Valve Isolation Valve Power A Pedal 1
System A
Selector Valve
Shut Normal System
N O R M A L
Plant Feed back

Pedal 2 Power B
System B
AntiSkid Command
Braking + AntiSkid Command
X Valve X Meter
AAccumulator L Valve T E Accumulator R Pump N Meter A Valve Mechanical T Pedal E

Meter Valve
Plant Mod el
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) [2] 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)
Slide 47
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 be
High 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
Slide 48
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 for
certification
Safety Analysis Methodology Who will build the fault model? Who performs what analysis?

Model-Based Safety Analysis

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Model-Based Safety Analysis

Hochgeladen von

Copyright:

Verfügbare Formate

Model-Based Safety Analysis

Advanced Technology Center

Motivation Proposed Approach

System Safety Analysis is

Active FGS Sends Incorrect Guidance Values

Inactive FGS Sends Incorrect Guidance Values

Error in FGS Inputs

Error in FCL Algorithm

Advanced Technology Center

Why Not the Safety Analysis?

We Base the Entire Development Cycle Around the Model