1. PRA: Validation versus Participation in Risk Analysis PRA as a Risk Informed Decision Making Tool
Richard T. Banke– SAIC
Diana DeMott – SAIC

2. 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)

3. 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

4. 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

5. 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

6. 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?

7. 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

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

9. 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