160 likes | 306 Views
Software Reliability in Nuclear Systems. Arsen Papisyan Anthony 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
E N D
Software Reliability in Nuclear Systems Arsen Papisyan Anthony 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