ML24116A202
| ML24116A202 | |
| Person / Time | |
|---|---|
| Issue date: | 04/30/2024 |
| From: | Sushil Birla, Norbert Carte, Christopher Cook, Mauricio Gutierrez Office of Nuclear Reactor Regulation, NRC/RES/DE |
| To: | |
| Mauricio Gutierrez 3014151925 | |
| References | |
| Download: ML24116A202 (13) | |
Text
Lessons Learned in Applying Systems-Theoretic Process Analysis (STPA) to a Nuclear Facility Case Study April 30, 2024 INL Digital Engineering Conference 2024 Note: The information and conclusions presented herein are those of the authors only and do not necessarily represent the views or positions of the US Nuclear regulatory Commission. Neither the US Government nor any agency thereof, nor any employee, makes any warranty, expressed, or implied, or assumes any legal liability or responsibility for any third partys use of this information.
Mauricio Gutierrez & Christopher Cook Instrumentation, Controls, and Electrical Engineering Branch Office of Nuclear Regulatory Research Nuclear Regulatory Commission (NRC)
Email: Mauricio.Gutierrez@nrc.gov Email: Christopher.Cook@nrc.gov 1
Sushil Birla Instrumentation, Controls, and Electrical Engineering Branch Office of Nuclear Regulatory Research US Nuclear Regulatory Commission (NRC)
Email: Sushil.Birla@nrc.gov Norbert Carte Instrumentation and Controls Branch Office of Nuclear Regulatory Regulation US Nuclear Regulatory Commission (NRC)
Email: Norbert.Carte@nrc.gov
Introduction
- Current practice for the safety evaluation of digital systems is challenged by the increased interdependencies and interactions across systems and components.
- STPA is a hazard analysis technique that promises to fill gaps that often go uncaptured by traditional techniques. Specifically, it is claimed that STPA can better answer: What can go wrong? and What are the consequences?
- Industry has conveyed that applicants and licensees will increasingly employ System-Theoretic Process Analysis (STPA) to support safety related digital applications.
Presentation Outline
- This presentation will:
- Provide an overview of STPA.
- Provide an overview of the NRC staffs recent efforts to grow the capability to review an applicants STPA.
- Summarize lessons learned.
Why STPA?
- Some advantages identified by industry include:
- The ability to analyze integrated systems that could have interdependencies among hardware, software, and human systems and operations.
- The analysis is not limited to analyzing what we traditionally call failures. That is analysis of systems that dont produce a safe outcome despite everything working as designed are possible.
Foundations of STPA
- Safety is treated a dynamic problem.
Systems-Theoretic Process Analysis (STPA) to identify and address hazards throughout the development process Causal Analysis using Systems Theory (CAST) to learn from operating experience.
Applying STPA makes it easier to analyze a system using CAST later.
Controller(s)
Control Algorithm(s)
Process Model(s)
Controlled Process Control Actions Feedback Figure based on material presented by Nancy Leveson Figure from Wikipedia.org OR System Control Model Analysis
Overview of the STPA Steps DEFINE THE PURPOSE OF THE ANALYSIS Define System + Environment Identify losses & hazards IDENTIFY LOSS SCENARIOS Identify reasons why UCAs in step 3 could occur.
Capture functional relationships and interactions.
MODEL THE CONTROL STRUCTURE(s) 01 04 IDENTIFY UNSAFE CONTROL ACTIONS (UCAs)
Identify UCAs that could lead to losses and hazards identified in step 1.
02 03
Overview of NRC Staff Efforts
- Held seminars and workshops to learn the basics of STPA and CAST.
- 1 week seminar (lecture style), 1 week workshop (non-nuclear group exercises)
- See the Agencywide Documents Access and Management System (ADAMS) Accession Numbers:
ML22277A013, and ML22272A315
- Following success of seminars and workshops, NRC staff recommended following up with a case study to:
- Build up NRC staff capability to understand how STPA can be applied to a system that could be reviewed by the NRC (e.g., a reactor protection system design).
- Grow NRCs capability to review an STPA-based or STPA-informed submittal.
- Case study was performed in 2023 with materials similar to submittals that could be reviewed by the NRC.
NRCs Case Study
- Two teams participated.
- Team 1 - Interdisciplinary team performed the analysis using the synthetic case study materials. Included aid of a facilitator.
- Team 2 - Learned the basics of STPA at their own pace and observed the case study groups efforts.
- Team assignments were dependent on participant availability and previous knowledge of STPA.
- Case Study Execution
- Case study materials were primarily based on a subset of materials from a withdrawn nuclear reactor design.
- Case study focused the analysis on a digital reactor protection system.
- Project planned around weekly meetings over a 5-month period.
NRCs Case Study: Application of STPA Steps Example DEFINE THE PURPOSE OF THE ANALYSIS Define System + Environment Identify losses & hazards 01
- Example System: Case Study Reactor Protection System.
- Example losses:
- L-1: Loss of power generation
- L-2: Financial losses
- L-3: Loss of Reputation
- Example Hazards
- H-3: Plant is unable to generate sufficient power [L-3,L-4]
- H-5: Plant violates regulatory licensing basis [L-3, L-4, L-5]
NRCs Case Study: Application of STPA Steps Example Iterate to capture functional relationships and interactions.
MODEL THE CONTROL STRUCTURE(s) 02 Operators (MCR)
Protection System Reactor Trip Module Engineered Safety Features Module RTBs Contacts Trip Process Plant Parameters Operators (RSS)
Plant Parameters Sensors Rod status ARI Power level Neutron flux Trip Open breakers Open contacts Breaker position Contact position
NRCs Case Study: Application of STPA Steps Example IDENTIFY UNSAFE CONTROL ACTIONS (UCAs) 03 Identify UCAs that could lead to losses and hazards identified in step 1.
Team 1 Member Name Controller -
Control Action
- Controlled Not providing causes hazard Providing causes hazard Too early, too late, out of order Stopped too soon, applied too long Team Member Name Operator - Enable Operational Bypass1 - SR: RX Trip System (subset of Protection system)
Operator does not provide Operational Bypass when a trip function is not needed which could cause an unnecessary trip on normal startup.
Operator does provide Operational Bypass when a trip function is needed which could cause a protective function to be disabled when it is credited in the safety analysis; that is, therefore the facility is being operated in an unanalyzed condition Too Early: before operator has performed all required checks and tasks Too Late: Operator forget to perform all required checks and tasks Out of Order: Same as above Presumably, there is a hold point here where the operator makes certain system checks, before validating permissive and increasing power; however, these check and reasons for them have not yet been found in the documentation.
Results - Some Lessons Learned
- Short duration intensive interval worked better than a long interval approach for building STPA review capabilities.
- Team meetings highlighted the importance of interdisciplinary collaboration.
- Exposed subject matter experts to insights they might not capture without collaboration.
- Design documentation limitations for applying or reviewing an STPA
- Design documentation used to create the case-study was encumbered with voluminous materials but was missing key information appropriate for applying STPA.
- Information in the case study documentation (specifically concept of operations documentation) was not sufficient to accurately label and understand the reasoning for human actions in the control model(s) generated.
Conclusions
- Staff built up an understanding of how nuclear applicants and licensees could use STPA to perform a safety analysis in a nuclear application.
- Staff learned how to more effectively build the capability to review STPA-based or STPA-informed submittals.
Group work was more effective than individual work.
Concentrated capability-building intervals were more effective than efforts spread out over longer intervals.
- Staff learned that content needed to support a scaled up STPA review would be challenging.
Reviewing submittals containing STPA-based or STPA-informed content would be a new paradigm.
Information needed to support a scaled up STPA review would draw from numerous experts and sections of a licensee submittal.
Inclusion of material not currently provided in early stages of licensing reviews (e.g., concept of operations content) would be needed.
The staff has not sufficiently determined what information would be needed on the docket for an STPA-based/STPA-informed review nor what type of information could be audited or inspected.