Advanced Technology Center Slide 1 Model-Based Safety Analysis Overview Dr. Steven P. Miller Dr. Mats P. E. Heimdahl Advanced Computing Systems Rockwell.

Slides:



Advertisements
Similar presentations
Translation-Based Compositional Reasoning for Software Systems Fei Xie and James C. Browne Robert P. Kurshan Cadence Design Systems.
Advertisements

Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
SWEN 5130 Requirements EngineeringSlide 1 Software Prototyping u Animating and demonstrating system requirements.
EECE499 Computers and Nuclear Energy Electrical and Computer Eng Howard University Dr. Charles Kim Fall 2013 Webpage:
Model Checker In-The-Loop Flavio Lerda, Edmund M. Clarke Computer Science Department Jim Kapinski, Bruce H. Krogh Electrical & Computer Engineering MURI.
1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
Object-Oriented Software Development CS 3331 Fall 2009.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 24 Slide 1 Critical Systems Validation 2.
Dagstuhl Intro Mike Whalen. 2 Mike Whalen My main goal is to reduce software verification and validation (V&V) cost and increasing.
Alternate Software Development Methodologies
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development.
Presented by: Thabet Kacem Spring Outline Contributions Introduction Proposed Approach Related Work Reconception of ADLs XTEAM Tool Chain Discussion.
VIDE als voortzetting van Cocktail SET Seminar 11 september 2008 Dr. ir. Michael Franssen.
Advanced Technology Center Slide 1 Formal Verification of Flight Critical Software Dr. Steven P. Miller Advanced Computing Systems Elise A. Anderson Commercial.
Advanced Technology Center Slide 1 Formal Methods in Safety-Critical Systems Dr. Steven P. Miller Advanced Computing Systems Rockwell Collins 400 Collins.
B757 Review Questions.
Requirements Analysis Concepts & Principles
Software Engineering for Safety : A Roadmap Presentation by: Manu D Vij CS 599 Software Engineering for Embedded Systems.
Overview of Software Requirements
Chapter 1 Principles of Programming and Software Engineering.
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
End-to-End Design of Embedded Real-Time Systems Kang G. Shin Real-Time Computing Laboratory EECS Department The University of Michigan Ann Arbor, MI
AOSE-2003, Melbourne July 15 th 1 Agent Oriented modeling by interleaving formal and informal analysis Anna Perini 1, Marco Pistore 2,1, Marco Roveri 1,
[ §4 : 1 ] 4. Requirements Processes II Overview 4.1Fundamentals 4.2Elicitation 4.3Specification 4.4Verification 4.5Validation Software Requirements Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Critical Systems Specification 3 Formal Specification.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR ESM'2009, October 26-28, 2009, Holiday Inn Leicester, Leicester, United Kingdom.
Unit 3a Industrial Control Systems
1.Database plan 2.Information systems plan 3.Technology plan 4.Business strategy plan 5.Enterprise analysis Which of the following serves as a road map.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
1 EVALUATING INTELLIGENT FLUID AUTOMATION SYSTEMS USING A FLUID NETWORK SIMULATION ENVIRONMENT Ron Esmao - Sr. Applications Engineer, Flowmaster USA.
Advanced Technology Center Slide 1 Requirements-Based Testing Dr. Mats P. E. Heimdahl University of Minnesota Software Engineering Center Dr. Steven P.
Proof Carrying Code Zhiwei Lin. Outline Proof-Carrying Code The Design and Implementation of a Certifying Compiler A Proof – Carrying Code Architecture.
1 New Development Techniques: New Challenges for Verification and Validation Mats Heimdahl Critical Systems Research Group Department of Computer Science.
B. Fernández, D. Darvas, E. Blanco Formal methods appliedto PLC code verification Automation seminar CERN – IFAC (CEA) 02/06/2014.
FAULT TREE ANALYSIS (FTA). QUANTITATIVE RISK ANALYSIS Some of the commonly used quantitative risk assessment methods are; 1.Fault tree analysis (FTA)
Software Testing and Quality Assurance Software Quality Assurance 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
Page 1 Analysis of Asynchronous Systems Steven P. Miller Michael W. Whalen {spmiller, Advanced Computing Systems Rockwell.
Model Checking and Model-Based Design Bruce H. Krogh Carnegie Mellon University.
1 Qualitative Reasoning of Distributed Object Design Nima Kaveh & Wolfgang Emmerich Software Systems Engineering Dept. Computer Science University College.
Page 1 Advanced Technology Center HCSS 03 – April 2003 vFaat: von Neumann Formal Analysis and Annotation Tool David Greve Dr. Matthew Wilding Rockwell.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Safety-Critical Systems 7 Summary T V - Lifecycle model System Acceptance System Integration & Test Module Integration & Test Requirements Analysis.
Electrical and Computer Engineering University of Cyprus LAB 1: VHDL.
PROC-1 1. Software Development Process. PROC-2 A Process Software Development Process User’s Requirements Software System Unified Process: Component Based.
Toulouse, September 2003 Page 1 JOURNEE ALTARICA Airbus ESACS  ISAAC.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Verification of FT System Using Simulation Petr Grillinger.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
RLV Reliability Analysis Guidelines Terry Hardy AST-300/Systems Engineering and Training Division October 26, 2004.
1 Software Testing Strategies: Approaches, Issues, Testing Tools.
Modelling the Process and Life Cycle. The Meaning of Process A process: a series of steps involving activities, constrains, and resources that produce.
"... To design the control system that effectively matches the plant requires an understanding of the plant rivaling that of the plant's designers, operators,
Middleware for Fault Tolerant Applications Lihua Xu and Sheng Liu Jun, 05, 2003.
Lectures 2 & 3: Software Process Models Neelam Gupta.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
SENG521 (Fall SENG 521 Software Reliability & Testing Fault Tolerant Software Systems: Techniques (Part 4a) Department of Electrical.
Copyright 1999 G.v. Bochmann ELG 7186C ch.1 1 Course Notes ELG 7186C Formal Methods for the Development of Real-Time System Applications Gregor v. Bochmann.
Week#3 Software Quality Engineering.
Principles of Programming & Software Engineering
Group mambers: Maira Naseer (BCS ).
Principles of Programming and Software Engineering
Object oriented system development life cycle
Rigorous Development Of a Safety-Critical System Based on Coordinated Atomic Actions By Subash M S.
Baisc Of Software Testing
Department of Computer Science Abdul Wali Khan University Mardan
Software Engineering for Safety: a Roadmap
Human Computer Interaction Lecture 14 HCI in Software Process
Presentation transcript:

Advanced Technology Center Slide 1 Model-Based Safety Analysis Overview Dr. Steven P. Miller Dr. Mats P. E. Heimdahl Advanced Computing Systems Rockwell Collins 400 Collins Road NE, MS Cedar Rapids, Iowa

Advanced Technology Center Slide 2 Outline of Presentation Motivation Proposed Approach Demonstration Analysis What’s Next

Advanced Technology Center Slide 3Motivation Requirements and Design Documents Safety Analyst A System Safety Analysis is - Based on Informal Specifications - Highly Dependent on Skill of the Analyst Safety Analyst B

Advanced Technology Center Slide 4 Model-Based Development We Base the Entire Development Cycle Around the Model Why Not the Safety Analysis?

Advanced Technology Center Slide 5 Model-Based Safety Analysis  Add Fault Model for Physical System Power A Pedal 1 Feed back Plant Fault Tolerant Control Unit ( BSCU ) Braking System System A Power B Pedal 2 System B  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

Advanced Technology Center Slide 6Advantages  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

Advanced Technology Center Slide 7 Outline of Presentation Motivation Proposed Approach Demonstration Analysis What’s Next

Advanced Technology Center Slide 8 Verify that the implemented system satisfies the safety requirements and develop certification documents Safety analysis performed as an integral part of the iterative system development process (Requirements, Architecture, Design) Traditional Safety Analysis Process

Advanced Technology Center Slide 9 Verify that the implemented system satisfies the safety requirements and develop certification documents Safety analysis performed as an integral part of the iterative system development process (Requirements, Architecture, Design) Model-Based Safety Analysis Incremental development of the system model. Support for automated safety analysis. Automated replay of safety analysis as the system is changed.

Advanced Technology Center Slide 10 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 safety properties of the nominal digital system Library of Common Mechanical Components Verify safety properties of the nominal system Plant Model AntiSkid Command Braking+ AntiSkid Command Green PumpBlue Pump Isolation Valve Shut Normal System N O R M A L A L T E R N A T E Accumulator Pump Meter Valve Meter Valve Meter Valve Accumulator Valve Mechanical Pedal 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

Advanced Technology Center Slide 11 Creation of the Fault Model Plant Model AntiSkid Command Braking+ AntiSkid Command Green PumpBlue Pump Isolation Valve Shut Normal System N O R M A L A L T E R N A T E Accumulator Pump Meter Valve Meter 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 Library of Common Failure Modes Fault Model System Architecture Component (or Component Type) Failure ModeType of Failure Additional constraints Isolation Valve, Meter Valve : Valve Stuck at Open or Closed Permanent- Power SupplyValue not in range TransientPropagate to all components connected to the Power supply Braking System Control Unit Inverted signalTransientSimultaneous failure on all outputs of BSCU Green Pump, Blue Pump :Pump Pressure below threshold Permanent-

Advanced Technology Center Slide 12 Auto-generation of Fault Trees Automated Safety Analysis Formalized Safety Requirements + Plant Model AntiSkid Command Braking+ AntiSkid Command Green PumpBlue Pump Isolation Valve Shut Normal System N O R M A L A L T E R N A T E Accumulator Pump Meter Valve Meter 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 Proofs of Safety Properties Simulation

Advanced Technology Center Slide 13 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

Advanced Technology Center Slide 14 Proof of Safety Properties  Mathematical Proof – Avoids Mile Wide Problem with Fault Trees – User Guides the Proof Structure 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 Cut Sets – Repeat Until Proof is Completed

Advanced Technology Center Slide 15 Correspondence Between Fault Trees and Proof Trees Complements w.r.t. each other

Advanced Technology Center Slide 16 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

Advanced Technology Center Slide 17 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

Advanced Technology Center Slide 18 Model-Based Safety Analysis Demonstration Dr. Mats P. E. Heimdahl University of Minnesota Dr. Steven P. Miller Advanced Computing Systems Rockwell Collins

Advanced Technology Center Slide 19 Outline of Presentation Motivation Proposed Approach Demonstration Analysis What’s Next

Advanced Technology Center Slide 20 Model-Based Safety Analysis  Add Fault Model for Physical System Power A Pedal 1 Feed back Plant Fault Tolerant Control Unit ( BSCU ) Braking System System A Power B Pedal 2 System B  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

Advanced Technology Center Slide 21 Auto-generation of Fault Trees Automated Safety Analysis Formalized Safety Requirements + Plant Model AntiSkid Command Braking+ AntiSkid Command Green PumpBlue Pump Isolation Valve Shut Normal System N O R M A L A L T E R N A T E Accumulator Pump Meter Valve Meter 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 Proofs of Safety Properties Simulation

Advanced Technology Center Slide 22 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 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

Advanced Technology Center Slide 23 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 Figure borrowed from ARP 4761

Advanced Technology Center Slide 24 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

Advanced Technology Center Slide 25 Add WBS Failure Modes to Nominal Model  Hydraulic Failure Modes – Pumps Pressure Below Threshold (X) – Valves Stuck at Closed/Open (S)  Digital System Failure Modes – Monitor Unit Output Inverted (I) – Command Unit Output Stuck (O) – Power Failure Loss of Power (L) I XX X SS S S S S OO I L L Manually Extended the Nominal Model with Failure Modes

Advanced Technology Center Slide 26 Outline of Presentation Motivation Proposed Approach Demonstration Analysis What’s Next

Advanced Technology Center Slide 27 WBS Model-Based Safety Analysis

Advanced Technology Center Slide 28 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

Advanced Technology Center Slide 29 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

Advanced Technology Center Slide 30 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)))) Plant Model AntiSkid Command Braking+ AntiSkid Command Green PumpBlue Pump Isolation Valve Shut Normal System N O R M A L A L T E R N A T E Accumulator Pump Meter Valve Meter 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 XX

Advanced Technology Center Slide 31 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 Green PumpBlue Pump Isolation Valve Shut Normal System N O R M A L A L T E R N A T E Accumulator Pump Meter Valve Meter 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

Advanced Technology Center Slide 32 Fault Trees and Proof Trees Revisited Complements w.r.t. each other

Advanced Technology Center Slide 33 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) [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) Plant Mod el AntiSkid Command Braking+ AntiSkid Command Green PumpBlue Pump Isolation Valve Shut Normal System N O R M A L A L T E R N A T E Accumulator Pump Meter Valve Meter 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 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)

Advanced Technology Center Slide 34 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

Advanced Technology Center Slide 35 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

Advanced Technology Center Slide 36 Outline of Presentation Motivation Proposed Approach Demonstration Analysis What’s Next

Advanced Technology Center Slide 37 What’s Next  Improving Modeling Process  Ease of Analysis  Presentation of Analysis Results  Scalability

Advanced Technology Center Slide 38 Improving the Modeling Process Nominal System Model Extended System Model # of Inputs727 # of Signals4565 Changed/Added Blocks13  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

Advanced Technology Center Slide 39 Improving the Modeling Process Adding Faults Clutters the Nominal Model

Advanced Technology Center Slide 40 Improving the Modeling Process  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

Advanced Technology Center Slide 41 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

Advanced Technology Center Slide 42 Ease of Analysis  Safety Properties Can be Awkward to Specify:  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);

Advanced Technology Center Slide 43 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

Advanced Technology Center Slide 44 Presentation of Analysis Results  Currently: Proof or Counterexample  We Want Something Acceptable To Safety Engineers

Advanced Technology Center Slide 45 Fault Trees using Model Checker  FSAP Defines Flat Fault Trees  We Can do Better by Encoding Architecture of System Into Fault Tree

Advanced Technology Center Slide 46 Proof Trees and Fault Trees Complements w.r.t. each other

Advanced Technology Center Slide 47 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) | [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) Plant Mod el AntiSkid Command Braking+ AntiSkid Command Green PumpBlue Pump Isolation Valve Shut Normal System N O R M A L A L T E R N A T E Accumulator Pump Meter Valve Meter 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 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)

Advanced Technology Center Slide 48 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

Advanced Technology Center Slide 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 for certification – Safety Analysis Methodology Who will build the fault model? Who performs what analysis?