PRA Validation versus Participation in Risk Analysis PRA

PRA: Validation versus Participation in Risk Analysis PRA as a Risk Informed Decision Making Tool Richard T. Banke– SAIC richard. t. banke@nasa. gov 281. 335. 2292 Diana De. Mott – SAIC diana. l. demott@nasa. gov 281. 335. 2056 1

Probabilistic Risk Assessment • Probabilistic Risk Assessment (PRA) is a comprehensive, structured, and logical analysis method aimed at identifying and assessing risks in complex technological systems for the purpose of cost-effectively improving their safety and performance. (PRA Procedures Guide for NASA Managers and Practitioners) • Combination of inductive (Event Tree) and deductive (Fault Tree) assessments of a system and its operations to determine the probability of some significant event occurring – Event Tree is a sequence of events starting with an initiator and leading to two or more end states • Often a time-based or a process-based sequence or could be a mixture • Initiator may be good (e. g. system start) or bad (e. g. accident start) – Fault Tree is a deductive logical determination of how the top event can occur • Based on system design and success or failure criteria – PRA may include results of other analyses (e. g. physics-based simulations) 2

Why Perform a PRA? • Understand quantify the risks associated with projects whose failure could be catastrophic (e. g. nuclear power plants, airliners, or space craft) • Validation Tool – assess whether a project meets its risk or safety requirements • Participation Tool– assess whether a planned design will likely meet its risk or safety requirements – Useful for trade studies – Can identify project or program design weaknesses and allow for correction while still in design – Feeds the Risk-Informed Decision Making process 3

Validation or Participation • Validation – PRA performed to determine if the program/project meets the customer’s risk expectations. – Understand risks associated with design/operations changes • Component upgrades • New ways of using the system • Participation – PRA performed to quantify the program/project expected risk – Can be used to establish risk requirements – Can be used to assess whether the project meets requirements – Helps determine the risks which need the most attention – Supports trade studies 4

What are the Differences? Validation Participation Generally late in the program life cycle Starts early in the program life cycle Post-Design, often after development and operations activities are well defined Concept or design phase Design detail – schematics, descriptive information, engineering detail, hazard assessments, Failure Modes and Effects Analysis is readily available Design detail may not exist or is highlevel at best. May be based on requirements documents/operations concepts. Failure data including failure modes may be readily available for the equipment in use Generally requires analogs to the planned components, requiring using generic data Operations are well-defined Operations may not be defined 5

Challenges to Validation • Access to the original system designers may be impossible • Difficult/Expensive to affect changes – What to do if the final system risk is greater than expected or required? 6

Challenges to Participation • Paucity of design information – Schematics may not be available or very high-level • Operations not well understood and/or documented • Access to engineers – they’re busy! – May be perceived as slowing the design process – PRA analyses take time – Design engineers don’t like to be told their design has a problem 7

Trade Studies vs. System Studies • Trade studies assess impacts on risk of a design to another – Often at the subsystem level – Could be physical design difference or operations differences – Risk can be traded with other design commodities such as cost, schedule, or mass – “Which design alternative is better? ” • System Studies – Can be used to establish requirements – Assess against requirements – Risk can be traded with other design commodities – “Did the project succeed? ” 8

Summary & Conclusion • In complex systems whose failure can cause significant damage (loss of life, major financial damage, etc. ), PRA is a useful tool to quantify the system risk • PRA can be performed at any point in the program/project life cycle, but best to include it from the start – More economical to make changes early in the design process – Quantifies risks of significant events and their causes • Valuable to designers to understand how their system can fail and what the probabilities are so risks can be removed or mitigated – Can be refined/matured as the system design matures – If started early and maintained throughout the lifecycle, won’t need to be re-done at maturity 9