Software Reliability in Nuclear Systems

Arsen PapisyanAnthony Gwyn

Introduction

• Therac-25 – delivery of high radiation to patients

• Slammer worm – disabled safety parameter system at nuclear power system

• Edwin I. Hatch nuclear power plant – computer resets the control system

• Stuxnet – worm in Iran nuclear power plants

Introduction Cont’d

• Not always feasible to ensure complete software verification

• Not possible to test for every possibility• Software testing only indicates the presence of

faults and not its absence• Goal: Estimate software reliability in critical

systems• Approach: Combines results of software

verification and mutation testing

Critical Systems

• Smaller and focused• Rugged and have fault tolerant features• Designed with defense in mind• Expected to have lower failure rates• Meant to fail in fail-safe mode• Not rely on human judgment or interaction to

initiate safety action• Written in stable programming languages

Software in Nuclear Reactors

• Safety critical: systems important to safety – ie safe shutdown and heat removal from core

• Safety related: systems which are required for the normal functioning of the safety systems

• Non-nuclear safety: no nuclear safety function• Safety Systems in Power plants are categorized

in levels from 1 to 4 – probability of failure– Level 1: 10^-2 – 10^-1– Level 4: 10^-5 – 10^-4

The Need for a New Approach

• Reliability depends on structure and runtime information – Simulation or executions of software provide the

runtime characteristics• Traditional models assume availability of

accurate and adequate software failure data– Difficult to collect

• Newly built plants with no failure history – Reliability estimation methods do not apply

Proposed Approach - Assumption

• 5 Modules

• Pure Software Failures• Single Threaded w/o Op System or safe and

certified Op System with assumed reliability 1

Assumptions Cont’d

• ROM to prevent malware modification• Output depends only on the current inputs

Prerequisites for approach

• Precise and Verified Test Cases

Prerequisites for approach cont’d

• Mutation testing: fault injection technique– First order mutants are single faults

• K = number of mutants killed by test cases• G = number of generated mutants• E = equivalent mutants• Test Adequacy Computation

Reliability estimation approach 1

• Randomly induced faults • 3 possible outcomes• Reliability =

• Simple but results could be biased– If mutation testing is not effective enough, the large

number of verified test cases may lead to higher reliability estimate

Reliability estimation approach 2

• Pseudo code - allows for integration of operational profile in the reliability estimate– Ensures that un-verified test cases fail during

mutation testing eliminating bias due to large number of verified test cases

Results

• Helps in choosing the combination of x and y values required to achieve target reliability

• x0, y0– Software requires rigorous verification

• x0, y1– Very high reusability, more software verification is +

• x1, y0– Nearly all generated paths verified, do not share much code

• x1, y1– Ideal scenario

Conclusion

• Need common ways to demonstrate safety of computer bases systems in nuclear plants

• Results suggest that test adequacy is major factor in determining software reliability– Systems must have a high test coverage and

mutation score

The End