ML23264A021

Addressing Hazards from Common Causes in Engineering Di&C Systems Without Diverse Designs - State-of-the-Art

ML23264A021
Person / Time
Issue date:	09/28/2023
From:	Sushil Birla NRC/RES/DE
To:
Sushil Birla 301-415-2311
References
Download: ML23264A021 (17)

Text

Addressing hazards from common causes in engineering DI&C systems without diverse designs State-of-the-Art Presenter: Sushil Birla Office of Nuclear Regulatory Research Division of Engineering 1

Enlarged Halden HTO Programme Review Group (EHPRG) meeting September 25-28, 2023 The views expressed herein are those of the author and do not represent an official position of the U.S. NRC.

2 Introduction to Assured Software Engineering

© 2018 Carnegie Mellon University

[DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution.

Understanding the Cost of Correcting Defects McConnell, Steve. Software Quality at Top Speed. August 1996.

http://www.stevemcconnell.com/articles/art04.htm

Economics!

3 Engineering time Run time Monitor Detect Intervene Diverse redundancy Prevent hazard Prevent propagation Verify Reactive Preventative Cost increases Potential to decrease intrinsic cost

Prevention Mitigation Fault tolerance in Design Q

u a

l i

t y

o f

D e

s i

g n

Desired state Current state Changes needed to prevent CCF Objective evaluation criteria Paradigm State of practice Competence Culture 4

Evolve Assurance capability incrementally Time Capability Current state S

Goal state G

State S+1 State S+2 State S+3 Goal state G-1 Goal state G-2

5

Evolve Assurance capability: NPP Case Time Capability Current state S

S+1 S+2 S+3 Concept Requirements System architecture Software architecture S+4 Detailed design S+6 Implementation G

Application acceptance Design certification ITAAC

S+5 6

Object is certified Evaluate Accredited 3rd party Pre-certified Procedures Pre-certified Facilities Pre-certified People Accrediting, certifying authority International common core standards Country-specialized evaluation criteria Rework cycle accredit certify Learning cycle Object of evaluation One vision of the Assurance Process submit derive Evaluation-basis 7

Ob Object of pre-certification:

Object is certified Evaluate Accredited certifying authority People Rework cycle Learning cycle Envisioned pre-certification activities Tools Processes Procedures Methods & techniques Facilities Other reusable assets, e.g.:

• Libraries 8

Creating the appropriate standards: One vision Ob Technical basis for:

People Tools Processes Procedures Methods & techniques Facilities Other reusable assets, e.g.:

• Libraries R&D organization Other voices Standards body Standard Guideline develops Government 9

Research to reduce the uncertainty space Conditions to reduce associated uncertainties

• = all phases Conditions on methods and tools Logical integration of all the evidence Reducing inconsistencies in judgment

+

+

+

10 Deficiencies in:

Hazard identification*

Requirements specification Architectural specification Detailed design specification Implementation (coding)

Verification

Defect-prevention through Refinement Requirements Architecture Detailed design Implementation Abstraction Declarative (what)

Imperative (how)

Concretion R

E F

I N

E M

E N

T 11

Leverage domain engineering Development Phase Requirements Architecture Detailed design Implementation Constraints to enable refinement Domain-specific controlled natural language Domain-specific architecture modeling language Domain-specific design specification language Domain-specific coding/programming language Semantically compatible Semantically compatible Semantically compatible refinement refinement refinement Create pre-certified reusable assets Domain modeling Domain engineering (see NUREG/CR-6263; IEEE Std 1517:2010; ISO/IEC 26550) 12

Reasoning Model to support performance-based evaluation 13 Reasoning Assertion Premise / Evidence Influences on validity of proposition Rebuttals Qualifiers (Strength; Condition)

Inference rule Theoretical or causal model Basis for Used in (based on the Toulmin model1) 1Toulmin, S., The Uses of Argument, Cambridge, UK: Cambridge University Press, 1958 Doubts/Defeaters

Some known technical limitations Validating results of hazard analysis Did it really identify all causes that could degrade the safety function?

Validating assumptions about the environment of the safety system, e.g.:

Conditions of operation and maintenance Configuration control change impact analysis Qualifying suite of tools from different sources Libraries Underlying languages Infrastructure for independent V&V 14

Why holistic? Effects of Missing Elements of Change Vision Capable Workforce Capable Processes Organizational Culture Action Plan Resources Incentives Change Confusion Sporadic change Misaligned behaviors Barriers to change Reinventing the wheel Adapted by Dr. Palma Buttles-Valdez, SEI from: Delorise Ambrose, 1987 Anxiety &

frustration Slow or little progress Sanctions reinforcements Capable Workforce Capable Processes Organizational Culture Action Plan Resources Incentives Sanctions reinforcements Vision Capable Workforce Capable Processes Organizational Culture Action Plan Incentives Sanctions reinforcements Vision Capable Processes Organizational Culture Action Plan Resources Incentives Sanctions reinforcements Vision Capable Workforce Organizational Culture Action Plan Resources Incentives Sanctions reinforcements Vision Capable Workforce Capable Processes Action Plan Resources Incentives Sanctions reinforcements Vision Capable Workforce Capable Processes Organizational Culture Action Plan Resources Sanctions reinforcements Vision Capable Workforce Capable Processes Organizational Culture Action Plan Resources Incentives False starts Vision Capable Workforce Capable Processes Organizational Culture Resources Incentives Sanctions reinforcements 15

Acronyms & Abbreviations 1/2 AADL Architecture Analysis and Design Language CCF Common cause failure Dev Development Engrg Engineering DI&C Digital Instrumentation and Control EPRI Electrical Power Research Institute esp.

Especially FSM Finite state machine HAp Hazard analysis of plans HAr Hazard analysis of requirements HAa Hazard analysis of architecture HAdd Hazard analysis of detailed design HAi Hazard analysis of implementation HAt Hazard analysis of testing (including test specifications and oracles)

IAEA International Atomic Energy Agency I&C Instrumentation and Control IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers ISO International Standards Organization IV&V Independent Verification and Validation NPP Nuclear Power Plant NRC U.S. Nuclear Regulatory Commission OWL Web Ontology Language RIL Research Information Letter RPS Reactor Protection System RWI Review, Walkthrough, and Inspection 16

R&D Research and Development Reqmts Requirements RIL Research Information Letter RPS Reactor Protection System SCR Software Cost Reduction (set of techniques for designing software systems) spec specification SQuaRE Systems and Software Quality Requirements and Evaluation STPA System Theoretic Process Analysis (method of hazard analysis)

Std Standard V&V Verification and Validation Vp V&V of plans Vr V&V of requirements Va V&V of architecture Vdd V&V of detailed design Vi V&V of implementation Vt V&V of testing (including test specifications and oracles) 17 Acronyms & Abbreviations 2/2