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 DeMott – SAIC diana.l.demott@nasa.gov 281.335.2056

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)

Why Perform a PRA? Understand and 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

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

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 high-level 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

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?

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

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?”

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