OSMA2003 Center for Reliability Engineering 1 Integrating Software into PRA Presented by C. Smidts Center for Reliability Engineering University of Maryland.

Slides:



Advertisements
Similar presentations
Model-Based Testing with Smartesting Jean-Pierre Schoch Sogetis Second Testing Academy 29 April 2009.
Advertisements

© Telelogic AB Modeling DoDAF Compliant Architectures Operational Systems Technical.
Test process essentials Riitta Viitamäki,
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Software Quality Assurance Plan
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Framework for comparing power system reliability criteria Evelyn Heylen Prof. Geert Deconinck Prof. Dirk Van Hertem Durham Risk and Reliability modelling.
©GoldSim Technology Group LLC., 2004 Probabilistic Simulation “Uncertainty is a sign of humility, and humility is just the ability or the willingness to.
Helicopter System Reliability Analysis Statistical Methods for Reliability Engineering Mark Andersen.
1 Software Testing and Quality Assurance Lecture 36 – Software Quality Assurance.
1 Software Testing and Quality Assurance Lecture 38 – Software Quality Assurance.
1 Software Testing and Quality Assurance Lecture 37 – Software Quality Assurance.
Design of Fault Tolerant Data Flow in Ptolemy II Mark McKelvin EE290 N, Fall 2004 Final Project.
APPLICATION OF A RISK-BASED DECISION SUPPORT TOOL FOR EVALUATING AVIATION TECHNOLOGY INTEGRATION TO A CONTROLLED-FLIGHT-INTO-TERRAIN ACCIDENT by Denise.
Requirements Engineering Processes
Overview of Software Requirements
CSC 402, Fall Requirements Analysis for Special Properties Systems Engineering (def?) –why? increasing complexity –ICBM’s (then TMI, Therac, Challenger...)
Chapter 2-Safety Analysis A Statistical Approach.
High Level: Generic Test Process (from chapter 6 of your text and earlier lesson) Test Planning & Preparation Test Execution Goals met? Analysis & Follow-up.
Annex I: Methods & Tools prepared by some members of the ICH Q9 EWG for example only; not an official policy/guidance July 2006, slide 1 ICH Q9 QUALITY.
Automation for System Safety Analysis: Executive Briefing Jane T. Malin, Principal Investigator Project: Automated Tool and Method for System Safety Analysis.
Basics of Fault Tree and Event Tree Analysis Supplement to Fire Hazard Assessment for Nuclear Engineering Professionals Icove and Ruggles (2011) Funded.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes 1.
Test Design Techniques
Software Project Management
Models for Software Reliability N. El Kadri SEG3202.
1 NASA OSMA SAS02 Software Reliability Modeling: Traditional and Non-Parametric Dolores R. Wallace Victor Laing SRS Information Services Software Assurance.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 24 Slide 1 Critical Systems Validation 1.
1 Reliability Engineering Program University of Maryland at College Park September 5, 2001 Integrating the Contribution of Software into Probabilistic.
SAS 03/ GSFC/SATC-ERAU-DoC Fault Tree Analysis Application for Safety and Reliability Massood Towhidnejad Embry-Riddle University Dolores Wallace & Al.
Isograph Reliability Software RiskVu V3. Isograph Reliability Software ESSM – The first risk monitor ? Essential Systems Status Monitor Installed at Heysham.
IV&V Facility 1 Software Reliability Corroboration Bojan Cukic, Erdogan Gunel, Harshinder Singh, Lan Guo West Virginia University Carol Smidts University.
Risk Assessment and Probabilistic Risk Assessment (PRA) Mario. H. Fontana PhD.,PE Research Professor Arthur E. Ruggles PhD Professor The University of.
1 Software Testing (Part-II) Lecture Software Testing Software Testing is the process of finding the bugs in a software. It helps in Verifying and.
University of Coimbra, DEI-CISUC
Chapter 5: Requirement Engineering Process Omar Meqdadi SE 2730 Lecture 5 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Chapter 6: Testing Overview Basic idea of testing - execute software and observe its behavior or outcome. If failure is observed, analyze execution record.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Overview of Software Testing 07/12/2013 WISTPC 2013 Peter Clarke.
IV&V Facility PI: Katerina Goseva – Popstojanova Students: Sunil Kamavaram & Olaolu Adekunle Lane Department of Computer Science and Electrical Engineering.
Protecting the Public, Astronauts and Pilots, the NASA Workforce, and High-Value Equipment and Property Mission Success Starts With Safety Believe it or.
1 Software Reliability Assurance for Real-time Systems Joel Henry, Ph.D. University of Montana NASA Software Assurance Symposium September 4, 2002.
FAULT TREE ANALYSIS (FTA). QUANTITATIVE RISK ANALYSIS Some of the commonly used quantitative risk assessment methods are; 1.Fault tree analysis (FTA)
1 6. Reliability computations Objectives Learn how to compute reliability of a component given the probability distributions on the stress,S, and the strength,
Dr. Tom WayCSC Testing and Test-Driven Development CSC 4700 Software Engineering Based on Sommerville slides.
Software Reliability in Nuclear Systems Arsen Papisyan Anthony Gwyn.
9 th Workshop on European Collaboration for Higher Education and Research in Nuclear Engineering & Radiological Protection Salamanca, Spain 5-7 June 2013.
Software Testing and Quality Assurance Software Quality Assurance 1.
Simulation of a Generic Cellular Manufacturing System Using Rockwell Arena Simulation Software This document provides a generic simulation model of a cellular.
Toulouse, September 2003 Page 1 JOURNEE ALTARICA Airbus ESACS  ISAAC.
Center for Reliability Engineering Integrating Software into PRA B. Li, M. Li, A. Sinha, Y. Wei, C. Smidts Presented by Bin Li Center for Reliability Engineering.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
RLV Reliability Analysis Guidelines Terry Hardy AST-300/Systems Engineering and Training Division October 26, 2004.
New Directions in Probabilistic Assessment Henk Roelant, LaRC Joanne Bechta Dugan, University of Virginia Kevin Sullivan, University of Virginia October.
WHAT IF ANALYSIS USED TO IDENTIFY HAZARDS HAZARDOUS EVENTS
Probabilistic Risk Assessment and Conceptual Design Bryan C Fuqua – SAIC Diana DeMott – SAIC
1 Software Testing and Quality Assurance Lecture 38 – Software Quality Assurance.
What is a software? Computer Software, or just Software, is the collection of computer programs and related data that provide the instructions telling.
Review on Test-Based Approach of Software Reliability November 22 nd, 2010 Nuclear I&C and Information Engineering LabKAIST Bo Gyung Kim.
SOFTWARE TESTING AND QUALITY ASSURANCE. Software Testing.
Testing Integral part of the software development process.
Software Defects Cmpe 550 Fall 2005
PRA: Validation versus Participation in Risk Analysis PRA as a Risk Informed Decision Making Tool Richard T. Banke– SAIC
CPM, PERT & Schedule Risk Analysis in Construction
Software Reliability Models.
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Measurement What is it and why do it? 2/23/2019
Test Design Techniques Software Testing: IN3240 / IN4240
Review and comparison of the modeling approaches and risk analysis methods for complex ship system. Author: Sunil Basnet.
Presentation transcript:

OSMA2003 Center for Reliability Engineering 1 Integrating Software into PRA Presented by C. Smidts Center for Reliability Engineering University of Maryland

Center for Reliability Engineering 2 Integrating Software into PRA Probabilistic Risk Assessment (PRA) is a technique to assess the probability of failure or success of a mission. Current PRA neglects the contributions of software to the risk of the mission. The objective of our research is to extend current PRA methodology to integrate software in the risk assessment process.

Center for Reliability Engineering 3 What We Have Done to Date Built a Software Failure Mode Taxonomy Failure Modes’ Quantification: generic high-level data -Public Literature -Expert Opinion Collaborated with JSC through Ms. Alice Lee -Validate Our Methodology -Collect Data Developed a Test-Based Methodology for Integrating Software Into PRA

Center for Reliability Engineering 4 What We Are Planning to Do in the Future Investigate Scalability Issues of the Test-based Approach Continue the validation of our methodology with JSC Apply the approach to JSC system Revise the methodology based on NASA system Develop an Analytical Approach Apply the Analytical Approach to JSC system Revise the Analytical Approach based on NASA system

OSMA2003 Center for Reliability Engineering 5 Integrating Software into PRA: A Test-based Approach Presented by C. Smidts C. Smidts, B. Li, M. Li Center for Reliability Engineering University of Maryland

Center for Reliability Engineering 6 Integrating Software into PRA - Approach We are working on an approach to integrate software into PRA. -Step 1: Identify events/components controlled/supported by software in MLD, accident scenarios, fault trees. -Step 2: Specify the functions involved -Step 3: Model software functions in ESDs/ETs and Fault Trees -Step 4: Construct the input tree -Step 5: Quantify the input tree -Step 6: Develop and perform software safety tests

Center for Reliability Engineering 7 Example System An exit system in a building is used as the example in this case study. The exit system includes an emergency exit system and the PACS system. The Emergency exit system includes an emergency exit door and a marked egress router. It provides an escape route for personnel located inside the building during emergency situations. The PACS system is a simplified version of an automated personal entry/exit access system used to provide privileged physical access to rooms /buildings, etc. Personal ID and PIN are needed to access this system.

Center for Reliability Engineering 8 Integrating software into PRA - Approach Step 1: Identify events/components Identify events/components controlled/supported by software in MLD, accident scenarios, fault trees. For all such events, create/expand contributors to account for software. Verify that no neglected “events” may now have become possible due to software.

Center for Reliability Engineering 9 MLD

Center for Reliability Engineering 10 MLD

Center for Reliability Engineering 11 Accident Description Fire is the initiating event Response systems: Emergency system and PACS system End State: Loss of life

Center for Reliability Engineering 12

Center for Reliability Engineering 13 Integrating software into PRA - Approach Step 2: Specify the functions involved Not all software functions are involved in accident scenarios, i.e, not all software functions are involved in particular scenarios/fault trees or even in the entire realm of possible scenarios/fault trees. To identify the specific functions involved in a scenario, determine the specific input to/output from the software – this will describe one function. A list of possible functions can be found in the requirements. Match the input/output combinations of these functions to the risk model

Center for Reliability Engineering 14 Integrating software into PRA – Approach PACS Functional Decomposition

Center for Reliability Engineering 15 Integrating software into PRA - Approach Actions and their inputs and outputs

Center for Reliability Engineering 16 Integrating software into PRA - Approach Step 3: Modeling software function in ESDs/ETs and Fault trees In the ESDs/ETs, the function of interest is modeled as

Center for Reliability Engineering 17 Integrating software into PRA - Approach Step 3: Modeling software function in ESDs/ETs and Fault trees In the fault tree, the function of interest is modeled as

Center for Reliability Engineering 18 Integrating software into PRA - ESD

Center for Reliability Engineering 19 Integrating software into PRA - Approach Step 4: Input Tree Build the input tree for the particular function involved The input tree is a decomposition of the space of possibilities The input tree is mostly generic for a function. But may VARY due to context.(i.e. probabilities of basic events may vary, certain events may conflict with the rest of the scenario conditions.)

Center for Reliability Engineering 20 Integrating software into PRA - Approach Step 4: Input Tree

Center for Reliability Engineering 21 Input Fault Tree Input Fault Tree for SW1

Center for Reliability Engineering 22 Input Fault Tree

Center for Reliability Engineering 23 Integrating software into PRA - Approach Step 5: Quantify the input tree

Center for Reliability Engineering 24 Integrating software into PRA - Approach Step 6: Develop and perform software safety tests These tests’ unique objective is to answer the questions contained in the model, i.e. in the MLD, accident scenarios and fault tree. The test is completely automated using Test Generation/test execution tools (TestMaster/WinRunner). The process is as follows: -Build a finite State Machine model of the software by following the software functional decomposition derived from the risk model and the software requirements. -Derive the test profile and output conditions to be quantified from the risk model -Define and run the test cases according to the following test strategy -Analysis consists in computing the probabilities of the different outcomes based on the test data.

Center for Reliability Engineering 25 TestMaster Model

Center for Reliability Engineering 26 Test Script Example win_activate ("mmount-76.umd.edu - CRT"); start_time1= get_time(); type ("1 "); Check_Message(Message_b,1); type ("0 "); Check_Message(Message_c,1); type (" "); Check_Message(Message_b,1); type ("0 "); Check_Message(Message_c,1); type("GayyardLupieN "); Check_Message(Message_b,1); type("1 "); end_time1=get_time(); report_msg("Cardtime is "&(end_time1-start_time1)"Seconds"); start_time2= get_time(); Check_Message(Message_d,1); wait( 9); type("4"); Check_Message(Message_e, 1); wait(3); type("5"); Check_Message(Message_f, 1); wait(1); type("1"); Check_Message(Message_g, 1); wait(3); type("9"); end_time2=get_time(); report_msg("PINtime is "&(end_time2-start_time2)"Seconds"); Case_Judge(Message_a,1);

Center for Reliability Engineering 27 Test Profile Test Profile for PACS

Center for Reliability Engineering 28 Failure modes application Test Case Selection 1.Sample from the profile/input tree to see whether we have a “Normal” or an “Abnormal Input”. 2.If it is a normal input, select randomly from the “Normal Input” domain. 3.If it is an abnormal input, randomly select the failure mode according to the profile/input tree. 4.Then randomly select the “base”value from the “Normal Input” domain and mutate this “base” value using the rules given below:

Center for Reliability Engineering 29 Testing Results 200 cases have been tested for SW1 and SW2. 19 cases failed. SW1 fails in only one case (58). Therefore, the point-estimate probability of Card failure is 1/200= cases failed for SW2. Therefore, the unsafe probability (gate closed) is 18/199 =0.09. Failed cases classification

Center for Reliability Engineering 30 Testing Results Card time and Probability

Center for Reliability Engineering 31 Testing Results PIN time and Probability

Center for Reliability Engineering 32 Test Cases Coverage Input Failure Modes Coverage (SW1) Input Failure Modes Coverage (SW2)

Center for Reliability Engineering 33 ESD

Center for Reliability Engineering 34 Future Work Represent hardware-related input failure modes in test model Quantification of input fault tree based on field data Output failure modes/Support failure modes Sensitivity Analysis Scalability -Test case generation -Test case execution -Number of test cases for each software component