towards assessment of software reliability and its characteristics in safety systems of nuclear...

Towards Assessment of Software Reliability and itsCharacteristics in Safety Systems of Nuclear Reactors

P. Arun BabuIndira Gandhi Centre for AtomicResearch, Kalpakkam - 603102

Tamil Nadu, [email protected]

C. Senthil Kumar

Safety Research Institute, AERBKalpakkam - 603102Tamil Nadu, India.

[email protected]

N. MuraliIndira Gandhi Centre for AtomicResearch, Kalpakkam - 603102


T. JayakumarIndira Gandhi Centre for AtomicResearch, Kalpakkam - 603102


ABSTRACTAs software failures in critical systems could be life threateningand catastrophic, the increase in software-based controls for safetyoperations demand a systematic evaluation of software reliability.To understand the dynamics behind building reliable software,not only is it important to estimate software reliability with highconfidence, it is necessary to study the factors that are likely toaffect software reliability. This is especially important for systemsthat are yet to be certified to be used in the field, i.e. have nooperational history. Such systems are often difficult to analyze asno or little operational information is available.

This paper attempts to generalize the following relationships insafety-critical software: (i) software reliability versus number offaults in software, (ii) software reliability versus results of staticand dynamic analysis, and (iii) software reliability versus safety.The present study reports and discusses results observed in safety-critical software in nuclear reactors using mutation-based testing.

The results observed in the case studies indicate that (i) reliabilityestimates based on number of bugs present in software are likelyto be inaccurate for safety-critical software, (ii) the relationshipbetween reliability and errors observed during dynamic analysisindicates that the average warnings and errors decrease exponen-tially as the reliability increases. No conclusive relationship wasfound between software reliability and warnings observed duringstatic analysis; and (iii) for safety-critical software, the requiredsafety can be achieved by improving the reliability, however theconverse is not always true.

Categories and Subject DescriptorsD.2.5 [Software Engineering]: Testing and DebuggingTest-ing tools

General TermsExperimentation, Verification, Measurement

KeywordsSafety critical software, Test adequacy, Mutation testing, Soft-ware reliability, Software Safety

Corresponding author

1. INTRODUCTIONSafety-critical systems are, systems whose failure could result inloss of life, significant property damage, or damage to the environ-ment [1]. Software-based systems are replacing pure hardware-based systems for safety operations in areas such as aerospace,automotive, medical, nuclear, etc. due to the advantages software-based systems offer in terms of functionality, cost, flexibility, main-tainability, reusability, etc.

However, the increase in the use of software for critical operationshas increased the likelihood of failures occurring due to softwarefaults. For example, an analysis of failures in launch vehiclesworldwide shows such a trend [2, 3].

Software reliability is one of the main attributes of software qual-ity, and is popularly defined as: (i) The probability of failure-freesoftware operations for a specified period of time in a specified en-vironment [4], (ii) The reliability of a program P is the probabilityof its successful execution on a randomly selected element from itsinput domain [5].

Software reliability estimation is known to be a difficult issue, es-pecially for systems with little or no operational history. Thispaper attempts to generalize the following properties of softwarereliability in such safety-critical software: (i) software reliabilityversus number of faults in software, (ii) software reliability versusresults of static and dynamic analysis, and (iii) software reliabil-ity versus safety. The present study reports results observed insix case studies (Table 1) in safety-critical software in nuclear re-actors, using mutation-based testing [6]. The rest of the paperis structured as follows. Section 2 reviews related work; Section3 describes the approach followed; Section 4 presents the resultsobserved; and Section 5 summarises and concludes the currentstudy.

2. RELATEDWORKQuantification of software reliability has been a topic of researchfor a long time, and several methods have been proposed [7].However, it is considered an unresolved issue [7]; and existing ap-proaches and models have assumptions and limitations that arenot acceptable for safety applications. Hence, not much has beenreported on the properties of software reliability in safety-criticalapplications.

ACM SIGSOFT Software Engineering Notes Page 1 Sept 2014 Volume 39 Number 5

DOI: 10.1145/2659118.2659126 http://doi.acm.org/10.1145/2659118.2659126

Table 1: Case studies chosen in the present study

System Abbreviation Active inFresh Subassembly Handling System FSHS Fuel handling stateReactor Startup System RSU Reactor startup stateSteam Generator Tube Leak Detection system SGTLD All statesCore Temperature Monitoring System CTMS Reactor in operation stateRadioactive Gaseous Euent System GES All statesSafety Grade Decay Heat Removal system SGDHR Reactor in shutdown state

Reactor in operation

Fuel handling

Reactor startup

OO

Fuel handling startup

OO

Reactor shutdown

TT JJ

Figure 1: Various states of a nuclear reactor

Reliability estimates based on software testing have been reliedupon for decades. Repeated failure-free execution of software pro-vides a certain level of confidence in the reliability estimate. How-ever, it is well known that software testing can only indicate thepresence of faults and not their absence.

Some of the existing models predict the number of bugs presentin software based on the historical failure trend. However, theyfail to pinpoint the remaining defects. For real world safety ap-plications, predicting reliability alone is not sufficient; hence, anideal reliability-estimation approach must also provide a way toimprove the reliability. Hence, there is a need for a systematic androbust software reliability estimation method suitable for criticalapplications related to safety.

Some studies have reported analysis of factors affecting softwarereliability focusing mainly on process aspects of software devel-opment [16], but very little on the product metrics. In this re-gard, the authors previous work [17, 18] focused on determiningtest adequacy and estimating software reliability for safety-criticalsoftware based on product metrics.

3. APPROACHIn general, a nuclear reactor can be in any one of the followingstates (Figure 1): (i) Reactor start-up, (ii) Reactor in operation,(iii) Fuel handling start-up, (iv) Fuel handling, and (v) Reactorshutdown. To cover all the states of a nuclear reactor, six casestudies have been chosen for the present study (Table 1). Also,as a nuclear reactor spends most its time in the operation state,three case studies have been chosen to represent the reactor inthe operation state. The Reactor Startup Unit (RSU) and Fuelhandling Startup Unit (FSU) are similar in nature, hence amongthe two, the current study only presents the results of RSU. Thebackground information regarding the case studies is provided inAppendix A.

For the case studies chosen, test cases are generated (Figure 3),and test adequacy is calculated (Table 2) [17]. The test casesare then verified using a model written using the Drakon editor[23]. The Drakon notations were developed for the Buran spaceproject in Russia [24, 25, 26] to provide simple and clean graphicalnotations for program writing. The Drakon notations can alsobe used for requirements modeling, and the resultant model is asemi-formal specification of software.

(a) Crossing over (b) Double crossing over

(c) Single mutation (d) Multiple mutations

Figure 2: Genetic algorithms - inspired by the genetic evolution:crossovers and mutations.

Table 2: Test adequacy achieved in case studies

System No. of unique No. of unique Testunder test test cases execution path adequacy

test casesFSHS > 3 x 105 302174 0.9001RSU > 3 x 105 10772 0.8824

SGTLD > 3 x 105 378554 0.9806CTMS > 3 x 105 311002 0.9922GES > 3 x 105 95 0.8600

SGDHR > 3 x 105 98118 0.9655



Compile the program under testwith gcc using

-fprofile-arcs -ftest-coverage

Large numberof random test cases+ Black box test cases

Select unique executionpath test cases

Unique test cases

Use genetic algorithms togenerate new test cases

Repeat

Figure 3: Test case generation using coverage information and genetic algorithms. (The unique execution path test case selection -genetic algorithm cycle is repeated till the required code coverage is achieved).

The Drakon editor [27] can automatically convert the diagramsinto the Erlang [28] programming language; the Drakon-Erlangcombination is used to model requirements in the visual-functionalprogramming paradigm [29]. The generated Erlang program is theexecutable specification of software and is used as a test oracle.

After the requirements modeling, the semi-formal specificationundergoes basic checks by the Drakon editor and Erlang specificchecks by Dialyzer (Discrepancy Analyzer for Erlang programs)[31, 32]. Dialyzer checks are performed by enabling all warnings(i.e. -Wunmatched returns -Werror handling -Wrace conditions-Wunderspecs)1. Also, to ensure good coverage of the model gen-erated in the Erlang programming language, 100% Modified con-dition/Decision coverage (MC/DC) and statement coverage areensured.

To ensure the effectiveness of the test cases, the software undertest is subjected to mutation testing and the mutation score iscalculated after detecting equivalent mutants [17]. An interest-ing by-product of mutation testing is the identification of safety-critical functions in a program. That is, if a mutant for any ofthe test cases fails in an unsafe state, then the function in whichthe fault was induced is safety-critical in nature. Such functionsmust have high test coverage.

3.1 Assurance of Rigorous Testing Through TestAdequacy

As larger, complex, frequently called, and safety-critical functionsmust have higher test coverage, the test coverage of the programunder test is calculated as a weighted average [17]:

1http://www.erlang.org/doc/man/dialyzer.html

Test coverage =

ti wiwi

(1)

where ti is the conservative test coverage achieved in a functionduring the system testing defined as the minimum of MC/DC,Linear Code Sequence And Jump (LCSAJ), and statement cov-erage; and wi is the weight assigned to each function as [17] :

wi = No. of statements Cyclomatic complexity Frequency of the function call Safety-critical nature (2)

As an effective set of test cases must have good bug-catchingcapabilities as well as good test coverage, the rigor in softwaretesting expressed as the adequacy of testing, is estimated usingboth test coverage (Equation 1) and mutation score as:

Test adequacy = Test coverageMutation score (3)

3.2 Software Reliability EstimationThe computed test adequacy (Equation 3) is used as one of theinputs to determine software reliability. If the test adequacy ishigh (i.e. 1), then the test cases (i.e. the sample) is a goodrepresentation of the infinite input domain (i.e. the population).Using the test adequacy value, software reliability is estimated as[17, 18]:



Test adequacy No. of test cases verifiedTotal no. of test cases

(4)

The above approach assumes availability of a true oracle or pseudooracle [35]. For each case study (Table 1), software is modelledusing the graphical Drakon editor and is converted to the Erlangprogramming language, which acts as a test oracle.

4. RESULTS4.1 Software Reliability Versus Number of Faults

in SoftwareIn literature, different methods are proposed to estimate softwarereliability based on the prediction of number of faults or defectsthat remain in software [36, 37, 38, 39, 40]. This section reportsresults on whether the number of bugs or faults is a good indicatorof the software reliability of safety-critical systems.

For all mutants in all case studies, software reliability is estimatedusing the proposed approach in Section 3.2, and the relationshipsbetween the average estimated software reliability versus defect-density or the number of faults induced in software are plotted.The results (Figures 4 to 7) indicate a broad gap between limits of estimated reliability in the results of defect density versussoftware reliability, for all the case studies combined. Similarly,the results of number of bugs versus software reliability in 7500mutants indicate that even though on average software reliabilitydecreases exponentially with respect to the number of bugs orfaults in the software, it may not be a good indicator of softwarereliability. This is concluded by the large gap observed inall case studies at higher reliability. The gap reduced onlywhen the reliability 0, which is not expected from a real worldsafety-critical software.

As the standard deviation of estimated reliability in the presentstudy was found to be high (Figures 4 to 7), it indicates that relia-bility depends upon the severity of bugs rather than the number ofbugs. Hence, reliability estimates based only on the defect-densityor number of bugs present in software are likely to be inaccuratefor safety-critical software.

4.2 Software Reliability Versus Results of Staticand Dynamic Analysis

Static and dynamic analyses are important parts of verificationand validation (V&V) of software. Static analysis examines soft-ware without executing it, and reports warnings and errors; whereasdynamic analysis executes the program with code instrumentationor in a controlled environment, and reports errors and warningsduring the program execution.

To understand if there exists any relationships between static ordynamic analysis and estimated reliability, for all the 7500 mu-tants in each case study, the average of warnings during staticanalysis using splint [41], clang [42], and cppcheck [43]; and er-rors and warnings during dynamic analysis using Valgrind [44]and Electric-Fence [45] were analyzed.

The results (Figures 8, 9) indicate that the warnings and errorsfound during dynamic analysis decrease exponentially as the re-liability increases. However, no significant relationship could befound between static analysis and the estimated software reliabil-ity. This is due to false positives and limitations, as the staticanalysis technique is based on set of predefined rules.

4.3 Software Reliability Versus SafetySoftware safety can be defined as ensuring that software will ex-ecute within a system context without resulting in unacceptablerisk [46], and is the most important aspect of a safety-criticalsystem. However, the relationship between software reliabilityand safety has not been extensively studied in the literature. Toestablish a relationship between the two, for all mutants generatedin Section 4.1, a parameter called safety-indicator is calculated.

Safety indicator =|Tw||Ew| (5)

Tw is the weighted safety vector observed while testing, and Ew isthe weighted safety vector expected as per software requirementsusing the executable semi-formal model of the system written inthe Erlang programming language. A weighted safety vector (Sw)indicates the fraction of safety requirements met by the software,and is defined as:

Sw = (s1 w1, s2 w2, s3 w3 , .... , sn wn), where:

si is the number of times the ith output has led to

a safety action, and

wi is the weight associated with the safety-criticalnature of output i

(6)

For ideal safety-critical software, the safety indicator should be1. If the safety indicator is < 1, then system provides less safetythan specified in the software requirement, which is a potentiallydangerous situation. If the safety indicator is > 1, it indicatesthat the system often shows spurious failures and provides moresafety than required.

For all mutant in all case studies, the safety indicator using Equa-tion 5 and its corresponding estimated software reliability usingEquation 4 are estimated and plotted. To plot the relationshipbetween software reliability and safety, the software reliability isaveraged at every 0.2 intervals of safety (indicated by the blueline in Figure 10). Theoretically, an ideal safety-critical softwarebased system must have safety = 1 and reliability = 1 (indicatedby the yellow line in Figure 10). Also, as the magnitude alonecannot distinguish between the two vectors, the angle betweenTw and Ew defined as:

Angle between Tw and Ew = cos1

(Ti Ei)(Ti)

2

(Ei)2

(7)

is indicated for each mutant (Figure 10). The angle between thetwo vectors is in range [0, 90] and indicates the angular simi-larity between them (aka. the cosine similarity), where 0 indi-cates that both test output and expected output overlap with eachother, whereas 90 indicates that both are perpendicular to eachother. The results (Figure 10) indicate that as the software relia-bility increases the safety also increases till the reliability reaches1. This is due to the fact that for a safety-critical software, safetyis its system requirement; hence by improving reliability, safetycan be improved. However, as the spurious failures increase, the



0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 7.5 8 8.5 9 9.5 10

E st i m

a te d

r el i a

b il i t y

Defect density (Faults/KLOC)

min (1, Average + Standard deviation)Average reliability

max (0, Average - Standard deviation)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200

E st i m

a te d

r el i a

b il i t y

Defect density (Faults/KLOC)

min (1, Average + Standard deviation)Average reliability

max (0, Average - Standard deviation)

Figure 4: Estimated reliability versus the defect density (in KLOC) for all the case studies. As the software under test is 1 KLOC,the results for defect density < 1 Defects/KLOC cannot be plotted. (The upper and lower bounds indicate the 1 limit, and thesoftware reliability is in the range [0,1])



0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

E st i m

a te d

r el i a

b il i t y

Number of faults induced

min (1, Average + Standard deviation)Average reliability of 500 mutants

Exponential fit : f(x) = 1.00 * exp ( -x * 0.15 )max (0, Average - Standard deviation)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

E st i m

a te d

r el i a

b il i t y




Figure 5: Estimated reliability versus the number of induced faults for FSH and RSU (The upper and lower bounds indicate the 1limit, and the software reliability is in the range [0,1])



0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

E st i m

a te d

r el i a

b il i t y




0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

E st i m

a te d

r el i a

b il i t y




Figure 6: Estimated reliability versus the number of induced faults for SGTLD and CTMS (The upper and lower bounds indicate the 1 limit, and the software reliability is in the range [0,1])



0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

E st i m

a te d

r el i a

b il i t y




0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

E st i m

a te d

r el i a

b il i t y




Figure 7: Estimated reliability versus the number of induced faults for GES and SGDHR (The upper and lower bounds indicate the 1 limit, and the software reliability is in the range [0,1])



6.7

6.8

6.9

7

7.1

7.2

7.3

7.4

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

A ve r

a ge

n um

b er o

f wa r

n in g

s o b

s er v

e d d

u ri n

g s t

a ti c

a na l

y si s

Estimated reliability

Figure 8: Estimated reliability versus the number of warnings found during static analysis for all case studies

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

A ve r

a ge

n um

b er o

f wa r

n in g

s /e r

r or s

ob s

e rv e

d d u

r i ng

d yn a

mi c

a na l

y si s


Exponential fit : f(x) = 17652.21 * exp ( -x * 2.24 )Average warnings/errors observed during dynamic analysis

Figure 9: Estimated reliability versus the number of errors found at dynamic analysis for all case studies



0

0 . 1

0 . 2

0 . 3

0 . 4

0 . 5

0 . 6

0 . 7

0 . 8

0 . 9 1

0 0 . 1

0 . 2 0 . 3

0 . 4 0 . 5

0 . 6 0 . 7

0 . 8 0 . 9

1 1 . 1

1 . 2 1 . 3

1 . 4 1 . 5

1 . 6 1 . 7

1 . 8 1 . 9

2 2 . 1


S a f e t y i n d i c a t o r

T h e o r e t i c a l v a l u e ( r e l i a b i l i t y = 1 , s a f e t y = 1 )A v e r a g e o f e x p e r i m

e n t a l v a l u e s

0 1 0

2 0

3 0

4 0

5 0

6 0

7 0

8 0

9 0

Angle between expected output and test output

Fig

ure

10:

Estim

ated

reliability

versu

sth

esa

fetyin

dica

tor,

for

all

the

case

studies

reliability decreases. Hence, improvement in safety does not guar-antee improvement in reliability.

5. SUMMARY AND CONCLUSIONSoftware reliability is the most important aspect of safety-criticalsoftware. And to build reliable software, it is necessary to under-stand the factors that are likely to affect software reliability. Thecurrent study has attempted to assess the following propertiesof software reliability in safety-critical software using mutation-based testing: (i) software reliability versus number of faults insoftware, (ii) software reliability versus results of static and dy-namic analysis, and (iii) software reliability versus safety in safety-critical software in nuclear reactors.

The results obtained from six safety-critical case studies indicatethat: (i) reliability estimates based on number of bugs presentin software are likely to be inaccurate for safety-critical software,(ii) safety-critical software should not show any warnings or errorsduring dynamic analysis, (iii) the average warnings and errorsobserved during dynamic analysis decreased exponentially as thereliability increased, however no conclusive relationship was foundbetween software reliability and warnings observed during staticanalysis, and (iv) for safety-critical software, the required safetycan be achieved by improving the reliability, however the converseis not always true.

The current results help in understanding the dynamics behinddeveloping reliable software. Also, the results may be used tojustify reliability and safety claims to a regulator.

AcknowledgementsAuthors acknowledge the useful technical discussion and com-ments from engineers working on safety systems at the Electron-ics and Instrumentation Group, Indira Gandhi Centre for AtomicResearch (IGCAR), Kalpakkam.

Authors are also thankful to S. Kishore (FRTG, IGCAR) andBaldev Raj (Ex-Director, IGCAR) for permitting the use of theirpublished materials.

6. REFERENCES[1] J. C. Knight, Safety critical systems: challenges and

directions, in Software Engineering, 2002. ICSE 2002.Proceedings of the 24rd International Conference on,pp. 547550, IEEE, 2002.

[2] F. Corporation, Analysis of launch vehicle failure trends,tech. rep., Futron Corporation, August 2006.

[3] D. P. Murray and T. L. Hardy, Developing safety-criticalsoftware requirements for commercial reusable launchvehicles, tech. rep., Federal Aviation Administration,Washington, DC, 2009.

[4] ANSI/IEEE, Standard glossary of software engineeringterminology, 1991. STD-729-1991.

[5] A. P. Mathur, Foundations of Software Testing.Addison-Wesley Professional, 1st ed., 2008.

[6] Y. Jia and M. Harman, An analysis and survey of thedevelopment of mutation testing, IEEE Transactions onSoftware Engineering, vol. 37, pp. 649678, 2011.

[7] T.-L. Chu, M. Yue, G. Martinez-Guridi, and J. Lehner,Review of quantitative software reliability methods, 2010.Brookhaven National Laboratory Letter report, Digitalsystem software PRA, JCN N-6725.

[8] R. W. Butler and G. B. Finelli, The infeasibility ofquantifying the reliability of life-critical real-time software,



IEEE Transactions on Software Engineering, vol. 19,pp. 312, 1993.

[9] B. Littlewood, The problems of assessing softwarereliability ...when you really need to depend on it, in inProceedings of SCSS-2000, Springer-Verlag, 2000.

[10] B. Littlewood, Software reliability modelling: achievementsand limitations, in CompEuro91. Advanced ComputerTechnology, Reliable Systems and Applications. 5th AnnualEuropean Computer Conference. Proceedings., pp. 336344,IEEE, 1991.

[11] L. Chen and A. Avizienis, N-version programming: Afault-tolerance approach to reliability of softwareoperation, in Proc. 8th IEEE Int. Symp. on Fault-TolerantComputing (FTCS-8), pp. 39, 1978.

[12] S. Brilliant, J. Knight, and N. Leveson, Analysis of faultsin an n-version software experiment, Software Engineering,IEEE Transactions on, vol. 16, no. 2, pp. 238247, 1990.

[13] T.L.Chu, G. M. Guridi, M. Yue, J. Lehner, and P. Samanta,Traditional probabilistic risk assessment methods fordigital systems.www.nrc.gov/reading-rm/doc-collections/nuregs/contract/cr6962/cr6962.pdf, May2008.

[14] Courtois, A. Geens, M. Jarvinen, and P. Suvanto,Licensing of safety critical software for nuclear reactorscommon position of seven european nuclear regulators andauthorised technical support organisations, 2010. Revision2010.

[15] D. C. Stidolph and J. Whitehead, Managerial issues for theconsideration and use of formal methods, in In StefaniaGnesi, Keijiro Araki, and Dino Mandrioli (eds.), FME2003, International Symposium of Formal Methods Europe,pp. 814, 2003.

[16] X. Zhang and H. Pham, An analysis of factors affectingsoftware reliability, Journal of Systems and Software,vol. 50, no. 1, pp. 4356, 2000.

[17] P. A. Babu, C. S. Kumar, N. Murali, and T. Jayakumar,An intuitive approach to determine test adequacy insafety-critical software, ACM SIGSOFT SoftwareEngineering Notes, vol. 37, no. 5, pp. 110, 2012.

[18] P. Arun Babu, C. Senthil Kumar, and N. Murali, A hybridapproach to quantify software reliability in nuclear safetysystems, Annals of Nuclear Energy, vol. 50, pp. 133140,2012.

[19] K. Hayhurst, D. S. Veerhusen, J. J. Chilenski, and L. K.Rierson, A practical tutorial on modifiedcondition/decision coverage, 2001.

[20] M. A. Hennell, M. R. Woodward, and D. Hedley, Onprogram analysis, Inf. Process. Lett., pp. 136140, 1976.

[21] M. Woodward, D. Hedley, and M. Hennell, Experience withpath analysis and testing of programs, IEEE Transactionson Software Engineering, vol. 6, pp. 278286, 1980.

[22] M. Mitchell, An introduction to genetic algorithms,Cambridge, Massachusetts London, England, Fifth printing,1999.

[23] S. Mitkin, Drakon : The human revolution inunderstanding programs.http://drakon-editor.sourceforge.net/DRAKON.pdf,October 2011.

[24] B. Hendrickx and B. Vis, Energiya-Buran: the Soviet spaceshuttle. Praxis, 2007.

[25] G. Goebel, The Space Shuttle Program. March 2011.http://vectorsite.net/tashutl.html.

[26] A. Zak, Buran - the soviet space shuttle, November 2008.

http://news.bbc.co.uk/2/hi/science/nature/7738489.stm.

[27] S. Mitkin, DRAKON-Erlang: Visual functionalprogramming, 2012. http://drakon-editor.sourceforge.net/drakon-erlang/intro.html.

[28] F. Cesarini and S. Thompson, ERLANG Programming.OReilly Media, Inc., 1st ed., 2009.

[29] T. Addis and J. Addis, Drawing Programs: The Theory andPractice of Schematic Functional Programming. Springer,2010.

[30] U. Wiger, G. Ask, and K. Boortz, World-class productcertification using erlang, ACM SIGPLAN Notices, vol. 37,no. 12, pp. 2534, 2002.

[31] L. Tobias and S. Konstantinos, Detecting software defectsin telecom applications through lightweight static analysis:A war story, in Programming Languages and Systems:Proceedings of the Second Asian Symposium (APLAS04),volume 3302 of LNCS, pp. 91106, Springer, 2004.

[32] L. Tobias and S. Konstantinos, Practical type inferencebased on success typings, in Proceedings of the 8th ACMSIGPLAN Symposium on Principles and Practice ofDeclarative Programming, (New York, NY, USA),pp. 167178, ACM Press, 2006.

[33] R. DeMillo, R. Lipton, and F. Sayward, Hints on test dataselection: Help for the practicing programmer, Computer,vol. 11, no. 4, pp. 3441, 1978.

[34] R. Hamlet, Testing programs with the aid of a compiler,Software Engineering, IEEE Transactions on, no. 4,pp. 279290, 1977.

[35] D. Hoffman, A taxonomy for test oracles.http://www.softwarequalitymethods.com/Papers/OracleTax.pdf,March 1998.

[36] M. N. Li, Y. K. Malaiya, and J. Denton, Estimating thenumber of defects: a simple and intuitive approach, inProc. 7th Intl Symposium on Software ReliabilityEngineering (ISSRE), pp. 307315, 1998.

[37] N. Fenton, M. Neil, W. Marsh, P. Hearty, D. Marquez,P. Krause, and R. Mishra, Predicting software defects invarying development lifecycles using bayesian nets,Information and Software Technology, vol. 49, no. 1,pp. 3243, 2007.

[38] N. Nagappan and T. Ball, Use of relative code churnmeasures to predict system defect density, in SoftwareEngineering, 2005. ICSE 2005. Proceedings. 27thInternational Conference on, pp. 284292, IEEE, 2005.

[39] P. Knab, M. Pinzger, and A. Bernstein, Predicting defectdensities in source code files with decision tree learners, inProceedings of the 2006 international workshop on Miningsoftware repositories, pp. 119125, ACM, 2006.

[40] T. Zimmermann and N. Nagappan, Predicting defectsusing network analysis on dependency graphs, inProceedings of the 30th international conference on Softwareengineering, pp. 531540, ACM, 2008.

[41] D. Evans, Splint - secure programming lint, tech. rep.,2002. University of Virginia.

[42] C. Lattner and V. Adve, The LLVM Compiler Frameworkand Infrastructure Tutorial, pp. 1516, 2005.

[43] D. Marjamaki, Cppcheck 1.62.http://cppcheck.sourceforge.net/manual.pdf, 2013. TheCppCheck manual.

[44] N. Nethercote and J. Seward, Valgrind: a framework forheavyweight dynamic binary instrumentation, inProceedings of the 2007 ACM SIGPLAN conference onProgramming language design and implementation, PLDI07, (New York, NY, USA), pp. 89100, ACM, 2007.



[45] B. Perens, efence - Electric Fence Malloc Debugger.http://manned.org/libefence/a9c2c4da, 1993. efence(3)manpage.

[46] N. G. Leveson, Software safety, tech. rep., SEI JointProgram Office, July 1987. SEI-CM-6-1(Preliminary).

[47] S. Chetal, V. Balasubramaniyan, P. Chellapandi,P. Mohanakrishnan, P. Puthiyavinayagam, C. Pillai,S. Raghupathy, T. Shanmugham, and C. S. Pillai, Thedesign of the prototype fast breeder reactor, NuclearEngineering and Design, vol. 236, no. 7-8, pp. 852 860,2006.

[48] P. Swaminathan, Modeling of instrumentation and Controlsystem of prototype fast Breeder reactor. PhD thesis,Sathyabama university, December 2008.

[49] IGCAR, System requirement specification for FSIF, NFF,FSTC, TCC, FSEP, and FSPF, tech. rep., Indira GandhiCentre for Atomic Research, 2011. PFBR/63510/SP/1001Rev-B.

[50] IGCAR, System requirements specification for reactorstartup authorization logic, tech. rep., Indira GandhiCentre for Atomic Research, 2010.PFBR/66710/SP/1002/Rev.C.

[51] IGCAR, System requirements specifications for I&C ofsteam generator tube leak detection circuit, tech. rep.,Indira Gandhi Centre for Atomic Research, 2006.PFBR/63370/SP/1003 Rev-D.

[52] IGCAR, System requirement specification for RTC basedcore temperature monitoring system, tech. rep., IndiraGandhi Centre for Atomic Research, 2009.PFBR/63110/SP/1007/R-E.

[53] IGCAR, System requirement specifications for I&C ofRadioactive Gaseous Euent Circuit, tech. rep., IndiraGandhi Centre for Atomic Research, 2011.PFBR/63720/SP/1003/Rev-B.

[54] IGCAR, System requirement specifications for I&C ofcommon sodium purification circuits for safety grade decayheat removal system, tech. rep., Indira Gandhi Centre forAtomic Research, 2008. PFBR/63420/SP/1003/Rev.D.

[55] MISRA, Guidelines for the use of the C language in criticalsystems. http://www.misra-c.com, October 2004.

[56] D. Kirkland, Bogosec: Source code security qualitycalculator.http://public.dhe.ibm.com/software/dw/linux/l-bogosec.pdf,2006.

[57] D. A. Wheeler, FlawFinder man page.http://www.dwheeeler.com/flawfinder, may 2004.

[58] A. Lazur, rats - Rough Auditing Tool for Security.http://manned.org/rats/14f83195, 2001. rats(1) manpage.

[59] C. Schwarz, R. Braakman, S. Perry, and F. Lichtenheld,Lintian Users Manual.http://lintian.debian.org/manual/index.html, 2008.

Figure 11: A fission reaction

A. BACKGROUND INFORMATIONA.1 Instrumentation and Control in Nuclear Re-

actorsNuclear Power Plants (NPPs) are power stations that use fissilematerial such as Uranium-235 or Plutonium-239 as fuel (Figure11). NPPs use the heat produced during the fission reaction togenerate electricity. Nuclear reactors may be divided into thermalreactors and fast reactors. Thermal reactors employ slow movingneutrons for the fission reaction, whereas fast reactors use fastmoving neutrons. An example of a fast reactor is the PFBR [47],which is a 500MWe sodium cooled fast breeder reactor. Figure 12shows a schematic of a typical sodium-cooled fast reactor.

To ensure the smooth functioning of the plant during reactorstart-up, operation, fuel handling, shutdown, and maintenance;a lot of hardware and software-based systems are used to monitorand control various plant parameters. These instrumentation andcontrol systems are safety systems running on real-time comput-ers, with fault tolerant features such as redundant power supplies,redundant network connections, and switch-over logics [48].

Also, safety-critical systems usually use a Triple Modular Redun-dant (TMR) architecture; where as safety-related systems use adual hot standby architecture [48].

A.2 Case Studies Used in Present StudySix systems, which are representative of safety systems in nuclearreactors, are used as case studies in the present work. Below isthe brief description of each system.

A.2.1 Fresh subassembly handling systemIn nuclear reactors, fuel is replenished approximately once everyyear. The spent fuel sub-assemblies are replaced with fresh fuelsub-assemblies during the refuelling campaign of the reactor. Afresh fuel sub-assembly is received at the Fresh Sub-assembly Re-ceiving Facility (FSRF), and after initial inspections, it is sent to



Figure 12: A typical sodium-cooled, pool-type fast reactor

FSHS

Heater control and monitoring(software controlled)

Pre-heatingvessel

Fresh fuel subassembly

FSEP gate(software controlled)

Transfer arm Inclined fuel transfer machineTo the reactor core

Figure 13: The flow of fresh fuel subassembly handling system



the Fresh Sub-assembly Preheating Facility (FSPF) through theFresh Sub-assembly Entry Port (FSEP) gate. After pre-heating,the fresh fuel sub-assembly is sent to the reactor core using theInclined Fuel Transfer Machine (IFTM) and Transfer Arm (TA)(Figure 13).

The main purpose of the Fresh subassembly Handling System(FSHS) [49] software is to collect necessary plant information,generate interlocks, and to automate the process of fresh fuel han-dling.

A.2.2 Reactor start-up systemTo smoothly start a reactor from reactor shutdown to reactor inoperation state, several conditions have to be satisfied. RSU [50](Figure 14) checks all these conditions and gives authorizationfor starting up the reactor. To check the list of conditions, theRSU scans hard-wired inputs from different plant systems andthe process computer (which records soft inputs given by othersystems).

The RSU software takes all the conditions to be satisfied for thereactor startup as input (c1 cn in Figure 14), and sends alarmsfor conditions that could not be satisfied. Also, under certainconditions during reactor startup, few conditions may be inhibitedafter proper authorization. The RSU system also processes theinhibited conditions and sends suitable alarms to the operator.

A.2.3 Steam generator tube leak detection systemAs fast breeder reactors use liquid sodium as the coolant, a leak inthe steam generator tubes (Figure 15) will cause a violent sodium-water reaction, followed by hydrogen release. Hence, the SGTLD[51] is provided to detect leaks, send alarm signals to the opera-tor, and to isolate steam generators to prevent further leaks andreaction. The SGTLD software also indicates the leaks as small,medium, or large; and takes the appropriate safety action.

A.2.4 Core temperature monitoring systemThe software-based CTMS [52] (Figure 16) continuously keepstrack of nuclear reactors core temperature through thermocou-ples. The main purpose of the system is to detect anomalies suchas plugging of fuel sub-assemblies, error in core loading and un-controlled withdrawal of control and safety rods. Software scansreactor core inlet temperatures and sub-assembly outlet tempera-tures periodically, validates the inputs and calculates various pa-rameters required for generating alarms and SCRAM (emergencyreactor shutdown) signals [17].

These signals are generated when the computed parameters crosstheir respective threshold limits. The alarms generated are sent tothe control room for the operator, and the SCRAM signal is sentto Control and Safety Rod Drive Mechanism (CSRDM) and/orDiversified Safety Rod Drive Mechanism (DSRDM) to drop thecontrol rods into the reactor core, to stop the fission reaction.CTMS is classified as a safety-critical system, and has two mainfailure modes: (i) failure to initiate SCRAM signal when param-eters exceed their threshold value, which places demand on thehardware-based CTMS and other diversified shutdown systems;(ii) generation of spurious SCRAM signals, which affects the plantavailability [17].

A.2.5 Radioactive gaseous effluent systemRadioactive gas euents are collected from various sources ofthe reactor and are stored in delay tanks. After a certain de-lay, depending upon the radioactivity level of the euent, it is

Figure 15: Steam generator in a sodium cooled fast reactor

discharged to the environment after filtering through the stack(Figure 17).

GES [53] software processes the system signals and produces therequired control and alarm signals for achieving safe radioactiveeuent handling. The main control actions of this system arestart or stop of compressors and open or close of valves.

A.2.6 Safety grade decay heat removal systemAfter reactor shutdown, the heat produced by the fuel due toradioactive decay is called the decay heat. The SGDHR [54] isused to remove the decay heat from the reactor core (Figure 18).To ensure sufficient cooling, a reactor may have more than oneindependent and identical SGDHR.

The instrumentation and control (I&C) system of the SGDHRmonitors or controls sodium temperature, sodium flow, sodiumlevel, sodium leak, argon pressure, air pressure, and valve positionsignals. The control actions of the system include open or closeof valves, heater control, blower control, and pump trip control.Also, the system generates appropriate alarms.



s11

c1

cn

Allow reactor startup

snk

...

Processed

field

signals

Figure 14: Logic diagram of the reactor startup system (ci is one of the conditions to be satisfied for the reactor startup, and sij isthe jth sub-condition of ci)

Figure 16: Schematic of the software-based CTMS



t

t

t t

tt t

t

P

Figure 17: The schematic of the Radioactive Gaseous Euent System (GES) (Here the symbol ./ indicates a pneumatic valve, NRVindicates a non-return valve, FM indicates the flow meter, C1 and C2 are the compressors, and the items controlled by software areindicated by the blue color)



Figure 18: Schematic of one of the four independent and identical loops of safety grade decay heat removal system



towards assessment of software reliability and its characteristics in safety systems of nuclear...

Documents

software failures

software engineering

use of software

reliable software

softwarebased controls

main attributes of software

reliability increases

software reliability