Safety Analysis of Safety-Critical Software for Nuclear...

F. Saglietti and N. Oster (Eds.): SAFECOMP 2007, LNCS 4680, pp. 148–161, 2007. © Springer-Verlag Berlin Heidelberg 2007

Safety Analysis of Safety-Critical Software for Nuclear Digital Protection System

Gee-Yong Park1, Jang-Soo Lee1, Se-Woo Cheon1, Kee-Choon Kwon1, Eunkyoung Jee2, and Kwang Yong Koh2

1 Korea Atomic Energy Research Institute, 150 Deokjin, Yuseong, Daejeon, 305-353, Korea {gypark,jslee,swcheon,kckwon}@kaeri.re.kr

2 Korea Advanced Institute of Science and Technology, 373-1 Guseong, Yuseong, Daejeon, 305-701, Korea

[email protected], [email protected]

Abstract. A strategy and relating activities of a software safety analysis (SSA) are presented for the software of a digital reactor protection system where software modules in the design description are represented by function blocks (FBs). The SSA, as a part of the verification and validation activities, was activated at each phase of the software lifecycle. For the SSA of the FB modules, the software HAZOP was performed and then the SFTA (Software Fault Tree Analysis) was applied. Both methods are redundant and complementary because the software HAZOP is a forward broad-thinking analysis method and the SFTA is a backward step-by-step local analysis method. The software HAZOP with qualitative properties for a deviation evaluated all the software modules and identified various hazards. The SFTA with well-defined FB fault tree templates was applied to some critical modules selected from the software HAZOP analysis and it identified some hazards that had not been identified in the prior processes of the document evaluation and the formal verification.

Keywords: Software Safety Analysis, Software FTA, Software HAZOP, Function Block Diagram, Nuclear Reactor Protection System.

1 Introduction

A fully-digitalized reactor protection system (RPS), which is called the IDiPS, is being developed under the KNICS (Korea Nuclear Instrumentation & Control Systems) project in order to be used in newly-constructed nuclear power plants and also in the upgrade of existing analog-based RPSs [1]. The IDiPS has four channels which are located in electrically and physically isolated rooms. The IDiPS generates the reactor trip signals and the engineered safety features (ESF) actuation signals automatically whenever the monitored process variables reach their predefined setpoints. Fig.1 shows the overall architecture of a single channel of IDiPS. A single channel IDiPS is composed of bistable processors (BPs), coincidence processors (CPs), an automatic test and interface processor (ATIP), and a cabinet operator

Safety Analysis of Safety-Critical Software for Nuclear Digital Protection System 149

Fig. 1. Architecture of the KNICS reactor protection system, IDiPS

Note - RSR: Remote Shutdown Room, MCR: Main Control Room, OM: Operator Module, IPS: Information Processing System, CPC: Core Protection Calculator, QIAS: Qualified Information & Alarm System, WDT: Watchdog Timer.

module (COM). It contains three different networks such as the intra-channel network (ICN), safety data link (HR-SDL), and inter-channel data network (ICDN).

The BP determines the trip state and generates a trip signal by comparing the measured process variables with the predefined trip setpoints. The CP generates a final hardware-actuating trip signal by a two-out-of-four voting logic. The ATIP generates the test signals for a manual test and a manual initiated automatic test. Moreover, the ATIP performs IDiPS status indications and also performs integrity tests to verify the operational status of the BP and CP. The COM comprises of two parts: (a) a computer based part that provides and displays the status information regarding the overall IDiPS equipments, and (b) a hardware based part that performs protection-related controls such as a channel bypass and an initiation circuit reset.

In the IDiPS, the trip functions such as a signal comparison in the BP and a voting logic in the CP are implemented in the software. Hence, the software in the IDiPS is crucial to the safety of a nuclear power plant in that its malfunction may result in irreversible consequences. The software in the BP and CP of IDiPS is classified as a safety-critical class and it is mandatory that the software safety analysis be performed on all the safety-critical software. In the KNICS project, the software used in the IDiPS is being developed under a rigorous procedure [1]. Also, independent verification & validation (V&V) activities are being arranged [2][3]. The IDiPS is configured based on the POSAFE-Q PLC-based platform. The software of the IDiPS

150 G.-Y. Park et al.

is programmed by the use of a function block diagram (FBD) which is compliant with the standard of IEC 61131-3 [4]. And the software modules in the detailed design description are represented by the FBD. In order to follow the nuclear regulation and also to improve the software quality, the software safety analysis (SSA) is being performed as a part of the V&V activities. This paper describes the software safety analysis performed on the FBD modules.

2 Strategy of SSA

It is recommended in the code and standards that the SSA shall be performed during the development of the software used for a safety system of nuclear power plants [5], [6]. For the strategy for performing the SSA, various methods have been proposed in the literature and in the research reports. The report by LLNL (Lawrence Livermore National Laboratory) [7] suggested that the SSA start from the hazard analysis of the target system and a software hazard analysis be performed at each phase of a software lifecycle. For the software hazard analysis to be applied to the phases of a software lifecycle, the software HAZOP (Hazard and Operability) was proposed. The strategy proposed by Leveson [8] has a distinctive characteristic in the safety verification. It is suggested that the safety analysis at any phase is to check against the safety requirements and constraints, being independent of the software requirements and design specifications, rather than checking the consistency such that the current implementation is in compliance with the specifications concerning the safety at the previous phase.

For the KNICS project, Lee and his colleagues have proposed a proper software safety lifecycle [9] by investigating various standards including IEC and IEEE standards. This safety process was adopted by the KNICS project where not only a digital reactor protection system but a programmable logic controller (PLC), POSAFE-Q, with proprietary operating software is being developed. Fig.2 depicts the software safety lifecycle for the KNICS project. As can be seen in Fig.2, the SSA is activated at each software lifecycle, starting from the establishment of a software safety plan where the SSA is planned as a part of the system safety analysis. The software-contributable hazards necessary for the SSA are extracted from the system hazard analysis by FMEA (Failure Modes and Effects Analysis). For the SSA at the requirements phase, the software HAZOP is employed in the hazard analysis. Also the software HAZOP and SFTA techniques are used for the SSA at the design and implementation (code) phases.

3 Identification of Software-Contributable Hazards

For the SSA of the FBD modules for a detailed design description and also for a FBD program, the software HAZOP is performed at first and then SFTA is applied. For these two techniques to be applicable, the software-contributable system hazards and the interface points between the system hazard and the application software must be identified. Based on these hazards and interface points, the software HAZOP identifies a software hazard, which can affect a certain system hazard, by applying a qualitative deviation into a FBD module. Also the interface points provide the


necessary information about the top node event of the SFTA for the FBD modules that are found to be defective, resulting from the software HAZOP analysis.

The system hazards were identified from an FMEA for the IDiPS hazard analysis by a digital system safety engineer. The FMEA identified some failure modes due to the trip-functioning application software which can affect the system safety. The interface points between the trip-functioning safety-critical software and the system hazards were identified by examining the analysis results of the FMEA. Table 1 represents the software-contributable system hazards and their criticality level. The criticality level implies the severity of a hazard on the system and plant safety and it is divided into the four levels. Level 4 means the most critical hazard that can induce the severe plant accident resulting in a disaster. Level 3 implies a hazard that can induce a significant impact on the system operation but does not lead to an accident of a nuclear power plant, and level 2 means a hazard that can affect more or less the system operation. And finally, level 1 indicates an insignificant hazard.

System Hazards

SystemFMEA

Software Hazards

Hardware FTA

Software FTA

System, Hardware, Operator Faults

Software Causesof Hazards

Minimal Cut Set, Reliability Analysis

Recommendations,Reliability/Safety Analysis

Reports

System FTA

System Requirements

Definition

System Design

Software Requirements Specification

Software Design

Code, CT, IT, ST, and CM Reports

Software Design FTA

SoftwareCode FTA

Preliminary System Hazard Analysis

Software Design HAZOP

Software Code, Test, Change,

and COTS SW HAZOP

Software Requirements HAZOP

Software Safety Plan

Reliability Analysis Process

Safety Analysis Process

Design Process

Design Change

PDS, COTS Software

HAZOP: Hazard and Operability, FTA: Fault Tree AnalysisPDS: Pre-Developed Software, COTS: Commercial-Off-The-Shelf

Fig. 2. Software safety lifecycle for KNICS RPS and PLC systems

Table 1. Software-contributable system hazards and criticality level for IDiPS RPS

Item No.

Software Contributable Hazards Criticality Level

1 IDiPS cannot generate a trip signal when a trip condition for a process variable is satisfied.

4

2 IDiPS generates a trip signal when it should not generate a trip signal. 3

3 IDiPS cannot send qualified information of its operating status to the main control room for plant operators.

2


The first hazard item contradicts the purpose of the IDiPS which is to protect the nuclear reactor core at any situation and this hazard can drive a nuclear power plant into a fatal unsafe state. The second hazard item does not affect the overall plant safety but it influences adversely on the economic operation of the system. The third hazard item may be induced from an omission of some necessary information or a transfer of incorrect information during the execution of the application software. This hazard can also be generated from a malfunction of the communication software, but this is not the scope of the SSA for the IDiPS. Instead, the hazards related to the communication software are analyzed in the SSA of PLC operating software.

The software modules of the BP which is a safety-critical processor of IDiPS are presented in Table 2. The software modules in the Trip_Logic module are all the trip-functioning modules and hence, all the final output variables in these modules are the interface points that affect the system hazard items 1 and 2 in Table 1. Some software modules in no.1 and no.3 also affect the hazard items 1 and 2 through the Trip_Logic module. The software modules in no.5, no.8, and no.9 affect the hazard item 3. The rest of the software modules are insignificant because the failures from these modules can be accommodated by the fault-tolerant functions such as a watchdog timer.

Table 2. Software modules in BP

NO Module Description 1 Receive_Signal HW/SDL/ICN Receive Module 2 PAT_Scheduler Automatic Test Scheduler 3 Test_Selection Test Selection Module

PZR_PR_Hi Trip Pressurizer Hi Pressure Trip SG1_LVL_Lo_RPS Trip SG-1 Low Level Trip SG1_LVL_Lo_ESF Trip SG-1 Low Level Trip for ESF SG1_LVL_Hi Trip SG-1 Hi Level Trip SG1_PR_Lo Trip SG-1 Low Pressure Trip CMT_PR_Hi Trip Containment Hi Pressure Trip CMT_PR_HH Trip Containment Hi-Hi Pressure Trip SG1_FLW_Lo Trip SG-1 Low Coolant Flow Trip PZR_PR_Lo Trip Pressurizer Low Pressure Trip VA_OVR_PWR_Hi Trip Variable Over Power Hi Trip SG2_LVL_Lo_RPS Trip SG-2 Low Level Trip SG2_LVL_Lo_ESF Trip SG-2 Low Level Trip for ESF SG2_LVL_Hi Trip SG-2 Hi Level Trip SG2_PR_Lo Trip SG-2 Low Pressure Trip SG2_FLW_Lo Trip SG-2 Low Coolant Flow Trip LOG_PWR_Hi Trip Log Reactor Power Hi Trip DNBR_Lo Trip Low DNBR Trip LPD_Hi Trip Hi LPD Trip

4 Trip_ Logic

CPC_CWP Trip CPC CWP 5 Test_Results_Handler Test Results Handling Module 6 HB_MONITORING Heartbeat Monitoring Module 7 HB_Gen Heartbeat Generation Module 8 Ch_Bypass_Send_Receive Channel Bypass Transfer Module 9 Send_Signal HW/SDL/ICN Sending Module


4 Software Safety Analysis for the FBD Modules

4.1 Software HAZOP

A HAZOP study is for the identification of a hazard in a target system represented by a so-called P&ID (Pipes and Instrumentation Diagram) by investigating a plausible deviation of a quantity or attribute and then seeking out the cause that is capable of inducing this deviation and the consequences resulting from this deviation. For the deviation to be performed systematically, well-defined guide words are established and then some essential questions suitable for a specific application area are devised based on these guidewords. This hazard analysis has been applied successfully to processes such as chemical plants, nuclear power plants, and so forth. And, there have been a few applications on computers and software systems [10], [11]. For HAZOP studies on the software systems, there are few papers if any that describe a systematic procedure for a HAZOP to be applied to all the software lifecycles.

In the KNICS project, a software HAZOP was developed for use in all the phases of the software lifecycle. The software HAZOP has different aspects from the conventional HAZOP applied to power plants and even to software designs, in that the quantity or attribute to be deviated is not a quantitative quantity such as a temperature value or a input data value but a qualitative functional characteristic of the software, and, moreover, the guide phrases are established for a systematic deviation rather than a set of guidewords. Thus, the software HAZOP is performed to identify some software hazards or defects that can induce one of the system hazards when a certain deviation for each functional characteristic is applied to the software system. The software functional characteristics are those proposed in NUREG0800 BTP/HICB-14 [12] such as accuracy, capacity, functionality, reliability, robustness, security, and safety. The concept of using the guide phrases was originally proposed by the LLNL report [7]. The guide phrases suited for the safety-critical software of the KNICS RPS and PLC systems and applicable to the requirements, design, and implementation phases were devised carefully [13].

While the V&V activities are performed on all the software of the IDiPS, the software on which a safety analysis is performed is the safety-critical software of the BP and CP of IDiPS. The form of the software module representation is based on the FBD. Among all the guide phrases [13], the guide phrases useful for these software representations were selected. Table 3 represents the guide phrases for the FBD-based software module descriptions and the corresponding checklist.

In Table 3, the functional characteristics have the deviations whose causes are external faults except for the four items from the bottom of the table. For the analysis of the “functionality” characteristic, the function blocks and their logical connections are inspected over a FBD module. This procedure is similar to a walkthrough during tests, possibly combined with a prior individual desk checking, but this is carried out briefly. At the test phase, this type of test is facilitated in order to find an error in the code for satisfying a specified software behavior. Being different from the test phase, the purpose of the inspection of the functionality characteristic is to find an error or hazard that can ultimately lead to one of the system hazards defined in Table 1.


Table 3. Guide phrases and checklist for the FBD-based software modules of IDiPS

Characteristic Guide Phrase Deviation Checklist

Accuracy Below minimum range What is the consequence if the sensor value is below its minimum range?

Accuracy Above maximum range What is the consequence if the sensor value is above its maximum range?

Accuracy Within range, but wrong What is the consequence if the sensor value is within its physical range but incorrect?

Accuracy Incorrect physical units What is the consequence if the input has an incorrect physical unit?

Accuracy Wrong data type or data size What is the consequence if the input has a wrong data type or data size?

Accuracy Wrong physical address What is the consequence if the input variable is allocated to a wrong physical address?

Accuracy Correct physical address, but wrong variable

What is the consequence if a wrong input variable is allocated to a correct physical address?

Accuracy Wrong variable type or name What is the consequence if wrong type or name for an input /output/internal variable is used in the FBD module?

Accuracy Incorrect variable initialization What is the consequence if the input/output/ internal variables are initialized incorrectly?

Accuracy Wong constant value What is the consequence if the internal constant is given a wrong value?

Accuracy Incorrect update of history variables

What is the consequence if the variable is updated incorrectly?

Accuracy Wrong setpoint calculation What is the consequence if the procedure for calculating a setpoint is incorrect?

Capacity Erroneous communication data What is the consequence if there is an error in the ICN data?

Capacity Erroneous communication data What is the consequence if there is an error in the SDL data?

Capacity Unexpected input signal What is the consequence when an unexpected input signal is arrived?

Capacity Untimely operator action What is the consequence if the operator commences a setpoint reset or an operating bypass function untimely?

Functionality Function is not carried out as specified

What is the consequence if some portions in the FBD module have a defect or cannot perform the intended behavior?

Reliability Data is passed to incorrect process

What is the consequence if the data is passed to an incorrect process?

Robustness Incorrect selection of test mode What is the consequence if the test mode is selected or changed unexpectedly?

Robustness Incorrect input selection What is the consequence if the input selection is incorrect?

The software HAZARD analysis evaluates all the software design modules with

respect to all the hazards in Table 1 by applying iteratively all the items in the deviation checklist to each module, reflecting the system safety and availability. Hence this process requires a considerably large amount of time and efforts of the HAZOP members. It is very important to draw a good corporation of members to obtain a successful result from the software HAZOP. Through the software HAZOP with the checklist in Table 3, various hazards affecting the availability of the system were identified and also the software HAZOP was proven to be useful in identifying a software hazard affecting the system safety.

One of the software HAZOP analysis results is presented in Table 4 where a trip logic module, “SG1_FLW_Lo Trip” (which indicates the module of Steam Generator


Table 4. Software HAZOP analysis for SG1_FLW_Lo trip

#1 Low Coolant Flow Trip) was analyzed. Table 4 shows the deviations, the causes that induce these deviations, the hazards analyzed, the effects of hazards, the criticality levels, and the suggestions for their hazards.

4.2 SFTA

In the activities of the SSA for the IDiPS software module descriptions, the SFTA was employed after the software HAZOP was carried out in the hazard analysis. As Leveson and Shimeall [14] mentioned the procedure of the SFTA, it is hypothesized that the software has produced an unsafe output and it is shown that this could not happen because the hypothesis leads to a contradiction. The SFTA was applied to a part of the software module descriptions with some critical defects identified by the “functionality” of the software HAZOP. The top node of the SFTA was only related to the most safety-critical hazard. Thus, the SFTA was used in a detailed analysis for a specific area with the consideration of a software defect that can affect the most significant system hazard. The software defect identified by the SFTA was mainly a software logic error or a certain input condition for the occurrence of a hazard.

Both methods, the software HAZOP and the SFTA, are supposed to be redundant and, at the same time, complementary because the software HAZOP is a forward broad-thinking analysis method and the SFTA is a backward step-by-step local analysis method. This redundancy obviously requires an additional overlapping work on the SSA but this type of overlap is recommended by a regulatory agency and some standards because all of the safety analysis methods have their own advantages and disadvantages. For the complementariness, the HAZOP study is actually a bidirect-ional analysis method in that, at the point of a plausible deviation, the analysis is carried out backwardly from the deviation to find a cause or causes for this deviation and also it is searched to identify the consequence(s) and the effect on hazards due to this deviation. In the application of the software HAZOP to the BP/CP FBD modules


of IDiPS, searching for a consequence from a deviation was much more weighted than searching for a cause of a deviation. Hence, in this study, the software HAZOP was thought of as a forward analysis method. The SFTA is, needless to say, a backward analysis method. It begins from the top node which represents an unsafe state and searches for the causes of the top event through logical paths of a FBD module, up to its inputs and input conditions. Moreover, the SFTA is usually performed by an individual expert rather than through a meeting of analysis team members. Although a part of functional characteristics adopted the form of a code walkthrough, the analysis results of the software HAZOP in this study were brief with broad descriptions. But the SFTA could pinpoint a local defect or some logical error.

Because the software is based on the logistical constructs and its behavior is deterministic, the fault tree analysis for the software is slightly different from that for the process systems where fault trees are based on a probabilistic nature. The SFTA for a code has been constructed based on the fault tree templates [14], [15]. The fault tree templates for the function blocks (FBs) in the FBD program had been proposed in an earlier research [16], but those templates considering both the fault-oriented view and the cause-effect view were proven to be inefficient in a real implementation. In this study, the templates for the FBs were refined to be more fault-oriented in order for the templates to be implemented easily in the SFTA. The types of function blocks used for the FBD modules were divided into 5 classes: Logic Operation FB (AND/

(a) Page 1

(b) Page 2 (c) Page 3

Fig. 3. Fault tree template for the AND function block


Fig. 4. Fault tree template for the ADD function block

OR), Comparison FB (GE/GT/LE/LT/EQ), Selection FB (SEL), Algebraic Operation FB (ADD/SUB/MUL/DIV/ABS), and Timer FB (TON). Among the function blocks, for the limitation of this paper, the fault tree templates of the function blocks, AND and ADD are presented in Fig. 3 and Fig.4, respectively. Beside of the templates for the function blocks, the fault tree template at the final output port and also the templates for the input variables at a leaf node were devised. In Fig.3 and Fig.4, the box with a circle at the bottom of it means a basic event and one with a triangle represents an event that has more trees presented at another page. The box with a rectangle indicates that a further analysis could be progressed through this event by pasting a low-level fault tree template to this rectangle. That is, the fault tree for an FBD module is constructed by connecting the fault tree templates associated with each other through the event with a rectangle box.

The software modules selected from the results of the software HAZOP for the case of the BP FBD modules as in Table 2 are SG1_FLW_Lo Trip (Steam Generator #1 Low Coolant Flow Trip), PZR_PR_Lo Trip (Pressurizer Low Pressure Trip), VA_OVR_PWR_Hi Trip (Variable Over-Power High Trip), and DNBR_Lo Trip (Low DNBR Trip). The SFTA could systematically identify the software hazard that induced a critical system hazard. A simple example of the SFTA is shown in Fig.5 where the SFTA for the trip function of DNBR_Lo trip was pruned to leave meaningful trees. The trip logic module for a DNBR trip is depicted in Fig.6 where the function blocks related with the trip functions are “SEL1”, “AND1”, and “OR1”. The sequence of an execution is from left to right and then from top to bottom (i.e., SEL1 AND1 OR1 for the trip functions of a DNBR). In Fig.5, an event box with a diamond symbol represents that event is not analyzed further. An event box with a house symbol means that this event is natural.

The event in the top node of Fig.5(a) (Page 1) reflects the fact that the software cannot generate a trip signal when a trip condition is triggered and, for the case of DNBR_LO trip, it is described such that the final output value of _4_TRIP (at OR1) is 0 when an input trip variable, _4_TRIP, at the front input port (at SEL1) becomes 1. In this analysis, other trips induced from the external hardware and interface failures are precluded and thus, a fault-propagating path is progressed through an input TRIP_LOGIC at the IN4 port of OR1. This input variable is again the output variable


(a) Page 1 (c) Page 3 (d) Page 4

(b) Page 2

Fig. 5. SFTA for DNBR_LO trip

of AND1 and the SFTA is extended into the AND1 by lowering its tree level. The fault trees regarding the AND1 are depicted in the second picture (Page 2) of Fig.5.


SEL1

AND1

OR1

Fig. 6. FBD module of DNBR_LO trip

There are two possible failures: One is at the input variable TRIP_LOGIC and the other at the TEMP_TRIP. With the value of _4_BP_T_TRIP_VAL at SEL1 being 0, one failure mode concerning TEMP_TRIP, leading to the top event, is the wrong input selection during the real trip operation, that is, _4_BP_T_INI = 0 (but it must be 1) as in Fig.5(d). This input selection failure was not progressed further in this example because this is not the scope of the FBD module in Fig.6. For reasoning the failure modes about the TRIP_LOGIC in AND1, the tree logic is divided into two cases. One is the fault trees when an unsafe event at the top node occurs at the


execution immediately after the initial execution was finished and the other is the fault trees when the top event occurs at an arbitrary time instance. As can be seen in Fig.5(b), the event named “LP_S0_OG_AND1”, where the name starting with a prefix LP_ means there is a loop within the fault trees, indicates the events occurring immediately below this event are the same as those below an upper event named “S0_OG_AND1”. This means that the values of TRIP_LOGIC are toggling, which results in the coming-and-going trip signals between 0 and 1.

The logic error described above had not been detected even in the formal verifica-tion process where a file containing a FBD module was converted into the Verilog language format by the use of a conversion tool [17] developed proprietarily for the KNICS project and the model checking by a SMV mode checker was performed on the converted Verilog specification based on the specified computational temporal logic properties. Some results from the formal verification are presented in Table 5.

Table 5. Formal verification results for DNBR_LO trip

Label Attribute Attribute Description Result

_4_P3 if (!TRIP_LOGIC && (_4_BP_T_INI && _4_BP_T_TRIP_VAL)) assert _4_P3: TRIP_LOGIC_1 == 1

If the current state is non-trip, the test mode is activated, and the test value is 1, then the trip output variable is 1.

TRUE

_4_P4 if (DI_MDL_E || _4_TRIP_DI_E || ENFMS_T_TRIP || TRIP_LOGIC_1) assert _4_P2: _4_TRIP_out == 1

If there is any hardware error or a logical trip, then trip signal is generated.

TRUE

In fact, the hazard identified by the SFTA of Fig.5 may be found in the code

inspection or through a unit test at the implementation phase. Moreover, the software HAZOP is capable of identifying such a hazard in a small FBD module as in Fig.6. Regardless of this fact, the application of the SFTA is thought to be necessary to find a local defect. The SFTA for the other FBD modules had a tremendously complex and lengthy tree structure where the software HAZOP seemed to be impossible to draw out a logical defect. For the case of a testing, a good set of test cases or a paramount test scenario needs to be designed carefully.

5 Conclusions

For the SSA of a digital reactor protection system in the KNICS project, the strategy and methods are presented in this paper. As techniques, the software HAZOP and the SFTA are employed in the SSA for the design description represented by FBD modules (and they can also be used for the FBD program). Because of a different viewpoint from the V&V activities, the SSA could produce some valuable results that had not been identified through a previous rigorous V&V procedure including a tool-based formal verification. Acknowledgments. This work has been performed for the research entitled “Development of the Licensing Technology for Digital I&C” as part of the KNICS project which is under the auspices of the Ministry of Commerce, Industry and Energy in Korea.


References

1. Park, J.H., Lee, D.Y., Kim, C.H.: Development of KNICS RPS Prototype. In: Proceedings of ISOFIC (International Symposium on the Future I&C for NPPs) 2005, Session 6, Tongyeong, Korea, pp. 160–161 (2005)

2. Koo, S.R., Seong, P.H., Yoo, J., Cha, S.D., Youn, C., Han, H.-C.: NuSEE: An Integrated Environment of Software Specification and V&V for PLC based Safety-Critical Systems. Nuclear Engineering and Technology 38, 259–276 (2006)

3. Kwon, K.C., Lee, J.S., Cheon, S.W.: Software Qualification Strategy for the Digital Protection Safety Systems in KNICS. In: American Nuclear Society Winter Meeting, Albuquerque, NM, USA, November 12–16, 2006, pp. 109–110 (2006)

4. IEC 61131, Part 3, International Standard for Programmable Logic Controllers: Programming Languages, International Electrotechnical Commission (1993)

5. Regulatory Guide 1.168, Verification, Validation, Reviews and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants, U.S. Nuclear Regulatory Commission (2004)

6. IEEE Std-1228, Software Safety Plan (1994) 7. Lawrence, J.D.: Software Safety Hazard Analysis, UCRL-ID-122514, Lawrence

Livermore National Laboratory (1995) 8. Leveson, N.G.: Safeware: System Safety and Computers. Addison-Wesley Inc., Reading

(1995) 9. Lee, J.S., Lindner, A., Choi, J.G., Miedl, H., Kwon, K.C.: Software Safety Lifecycles and

the Methods of a Programmable Electronic Safety System for a Nuclear Power Plant. In: Górski, J. (ed.) SAFECOMP 2006. LNCS, vol. 4166, pp. 85–98. Springer, Heidelberg (2006)

10. Redmill, F., Chudleigh, M.F., Catmur, J.R.: Principles underlying a Guideline for Applying HAZOP to Programmable Electronic Systems. Reliability Engineering and System Safety 55, 283–293 (1997)

11. McDermid, J.A., Pumfrey, D.J.: A Development of HAZARD Analysis to Aid Software Design. In: Proceedings of the 9th Annual Conference on Computer Assurance, Gaithersburg, MD, USA, pp. 17–25 (1994)

12. NUREG-0800, Standard Review Plan: BTP HICB–14, Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems, U.S. Nuclear Regulatory Commission (1997)

13. Lee, J.S., et al.: HAZOP Method for Safety Analysis of Software Requirements Specification (in Korean). In: Proceedings of the Korean Nuclear Society Spring Meeting, Gyeongju, Korea, May 2003, vol. 87 (2003)

14. Leveson, N.G., Shimeall, T.J.: Safety Verification of Ada Programs using Software Fault Trees. IEEE Software, 48–59 (1991)

15. Cha, S.S., Leveson, N.G., Shimeall, T.J.: Safety Verification in MURPHY using Fault Tree Analysis. In: Proceedings of 10th International Conference on Software Engineering, Singapore, April 1988, pp. 377–386 (1988)

16. Oh, Y., Yoo, J., Cha, S., Son, H.S.: Software Safety Analysis of Function Block Diagrams using Fault Trees. Reliability Engineering and System Safety 88, 215–228 (2005)

17. Jeon, S.: Verification of Function Block Diagram through Verilog Translation, M.S. Thesis, Computer System Division, EECS Department, Korea Advanced Institute of Science and Technology, Korea (2007)

Safety Analysis of Safety-Critical Software for Nuclear...

Documents

Transcript of Safety Analysis of Safety-Critical Software for Nuclear...