Design Verification of Instrumentation and Control Systems of Nuclear Power Plants

  • Published on
    03-Feb-2017

  • View
    213

  • Download
    1

Transcript

  • IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 61, NO. 2, APRIL 2014 921

    Design Verification of Instrumentation andControl Systems of Nuclear Power Plants

    Lalit Kumar Singh, Gopika Vinod, and A. K. Tripathi

    AbstractInstrumentation and Control systems are the nervoussystem of a nuclear power plant. They monitor all facets of theplants health and help respond with care and adjustments needed,thus ensuring goals of efficient power production and safety. Dueto safety significance of I&C, it becomes increasingly important tohave a design verificationmethodology which ensures I&C systemsfully functional. The strategy discussed the systemmodeling for de-sign verification using Petri Net, converting it into Markov Chainand solving the linear system mathematically. It also exploits thebest attribute of the createdMarkovmodel. The approach has beenvalidated on seven sets of operation profile data of reactor controlsystem of seven Nuclear Power Plants.

    Index TermsInstrumentation and Control, Markov chain, Nu-clear Power Plant, Petri Net.

    ACRONYMS

    MC Markov ChainCBS Computer Based SystemNPP Nuclear Power PlantDCC Digital Control ComputerRRS Reactor Regulating SystemACL Adjuster Control LogicChPU Channel Processing UnitDU Display UnitRTD Resistance Temperature DetectorAERB Atomic Energy Regulatory Board

    NOTATION

    Probability of transition from state i to jTransition rate from state i to state jProbability that a component is in state i

    Manuscript received December 01, 2013; revised February 07, 2014; ac-cepted February 07, 2014. Date of publication March 20, 2014; date of currentversion April 10, 2014.L. K. Singh is with the Department of Atomic Energy, NPCIL, R&D-Elec-

    tronics Systems, Government of India, Varanasi, Uttar Pradesh 221005, India(e-mail: lksingh@npcil.co.in).G. Vinod is with the Department of Atomic Energy, Reactor Safety Division,

    Bhabha Atomic Research Centre, Government of India, Maharashtra 400094,India (e-mail: vgopika@barc.gov.in).A. K. Tripathi is with the Deparment of Computer Engineering, IIT (BHU),

    Varanasi 221005, India (e-mail: aktripathi.cse@iitbhu.ac.in).Digital Object Identifier 10.1109/TNS.2014.2305656

    1The singular & plural of an acronym are always spelled the same.

    Estimated Reliability of ACL module using MC

    Actual Reliability of ACL module usingoperational profileEstimated Unreliability of ACL module using MC

    Actual Unreliability of ACL module usingoperational profile

    I. INTRODUCTION

    N PP contains at least a control system, whose functionsare performed by DCC that can adjust reactor power toproduce the desired amount of electricity [1][6]. Consideringthe importance of NPP control system, it must be designed tomeet high reliability requirements, as specified by the AERBguidelines of the respective country.The research work in this paper focuses on the improvement

    of the existing approach to give a reliable prediction of designmetrics of control system of NPP. Moreover, this can be appliedto all the kinds of systems, of all domains; provided it is possibleto design or model it. We have taken a small module of RRS,known as ACL as a case study.Section II discusses the existing approaches that can be im-

    proved for estimating the design metrics of safety related, safetycritical and information systems of NPP. Section III gives acomplete case study of RRS and its failure impact. We describeACL module of RRS in detail. Section IV, we describe ourgeneric framework for estimating the design metrics of a com-puter based system along with its application on ACL. In Sec-tion V, we validate our approach on the 7 sets of operationalprofile data of ACL, collected from 7 atomic power stations.Section VI concludes this paper.

    II. RELATED WORKReliability prediction approach for component based soft-

    ware architecture has been proposed by Reussner [9]. But thisapproach is like a black box approach and based on Markovchain and UML and can predict software reliability. Also, thetransition probabilities between the states of the Markov chainhave been assumed.Gokhale and Trivedi [10] also propose methodology for soft-

    ware reliability prediction based on MC by assuming the tran-sition probabilities in between the states of the MC.Another approach for reliability prediction has been proposed

    by Cheung [11], which is based on Hidden Markov Chain. Thisapproach uses five sources from system experts. This paper alsolacks themethod to compute the transition probabilities between

    0018-9499 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

  • 922 IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 61, NO. 2, APRIL 2014

    the states of the Markov chain. They state that the transitionprobabilities can be obtained by assembling and deploying thecomponents and executing the expected usage profile againstthem. However, for this software practitioners need to set up thewhole system during architecture design, which is often neitherdesired nor possible.Recent approaches by Sharma et al. [12] and Wang et al. [13]

    extend Cheungs work to support different architectural stylesand combined performance and reliability analysis. However,they rely on testing data or the software architectures intuitionto determine the transition probabilities.Sato and Trivedi [14] combine a system model and resource

    availability model but assume fixed transition probabilitiesamong services.F. Brosch et al. [15] devised an approach based on Palladio

    Component Model which automatically gets transformed intoa formal MC. They state that they compute ,the probability of success on condition that the system is instate , without giving any computational evidence. Moreovertheir basis to estimate the transition probabilities is MTTF andMTTR, which cannot be determined during architectural ordesign phase.Gokhale et al. [16] again tried to address this issue up to some

    extent using Bayesian approach but they define a posterior dis-tribution of the random variable to find the transition probabili-ties based on any priori knowledge, which is also an analyticalapproach.Goseva-Popstojanova et al. [17] proposed the method of mo-

    ments to calculate the sensitivity of a systems reliability to com-ponent reliabilities and transition probabilities analytically. In-dika et al. [18] proposed a method to evaluate reliability basedon the architecture. They try to compute the transition probabil-ities in the MC from the expected number of visits to a com-munication link. But the uncertainty that is associated with thisapproach is to quantize the parameters which are required tocompute the estimate of the number of visits.Some approaches [19] also quote that usage profile should be

    used to find the transition probabilities of the system but thisis not a generic solution as a same software may have differentusage profile in it is installed at different locations.All of the above methods have taken an analytical approach

    to quantify the sensitivity, where the applicability is limited toanalytically solvable models. However, these analytical sensi-tivity analysis methods are hard to generalize.

    III. A CASE STUDY

    A. Reactor Regulating System

    A nuclear chain reaction in the NPP is controlled by RRS,which is a CBS. RRS is a process system that is continuouslyactive in the normal control of reactor power. The reactor regu-lating system allows the reactor power to be reduced to about 60percent of full power and operation continued indefinitely at thatlevel or to be quickly reduced to zero power and then restartedwithin 35 minutes (which is the xenon override time)[5]. Tomaintain reactor power at the desired set point, RRS adjuststhe reactivity control devices. The reactivity devices include

    Fig. 1. Architecture of Reactor Regulating System.

    (i) liquid zones (ii) control absorbers (iii) adjusters. RRS mon-itors power level over the full operating range. RRS containsseveral modules, known as logic blocks. Each logic block is im-plemented as a program, some are shown only for convenienceand do not necessarily imply separate, self-contained programs.All the functions of RRS are achieved by these logic blocks.The functions of RRS are given in detail in [5]. The failure ofRRS increases the reactor power which is an indicator of un-controlled nuclear fission reaction which will invoke the safetysystems and there will be loss of one safety boundary. Subse-quently, the failure of the safety systems [5] may lead to coremelting (fuel failure), due to which the radioactivity may getreleased to the public. All the major nuclear disasters [20] ofLevel 7 on International Nuclear Scale Event has happened dueto the core melting. Hence the reliability requirements of RRSare very high, which is .

    B. Architecture of RRSThe architecture of RRS is two-tier as shown in Fig. 1. There

    are three triplicated ChPU; and two LANs and two DUs for re-dundancy purpose. The triplicated ChPU gets data from tripli-cated field sensors in the form of voltage or current or RTD.ChPU works on 3 by 2 logic, which means that if any parameterin one ChPU deviates by , from the rest of two, the deviatedvalue gets replaced by the value that is in the other two ChPUs.All ChPU communicates to both the DU, through dual redun-dant LANs for monitoring and actuation of reactivity devices.The field sensors are required to know the dynamics of the RRSparameters like position of reactivity devices. Monitoring is re-quired to know the status of the RRS parameters. Apart frommonitoring DU send commands to ChPU for alarm generation,in case of any critical parameter deviates from normal operatinglimit or to actuate the reactivity controlling devices.ChPU is a real time; the software has been developed on real

    time operating system VxWorks, using C language and burnedon EPROM -Motorola 80280, using RT-20. DU, a non-real timesystem, used for monitoring and sending commands (to ChPU)is developed on Linux and platform, using QT libraries.

    C. Adjuster control logic Module of RRSThis is one of the module/program/block of RRS. It incorpo-

    rates in drive, out drive, end stop logics for adjuster rods.The commands for drive in or drive out are initiated by thecontrol room operator. DU sends the command to ChPU to drive

  • SINGH et al.: DESIGN VERIFICATION OF INSTRUMENTATION AND CONTROL SYSTEMS OF NUCLEAR POWER PLANTS 923

    Fig. 2. Transition Probability prediction framework.

    the rod following which ChPU reconfirms with the DU. Aftergetting reconfirmation from DU, ChPU starts driving the rodby creating the logic and by opening the clutch. It also readsthe position of the rod along with the time stamping. All thestatus related messages are communicated to DU. Each com-mand, received from DU is executed by ChPU and in responseto it ChPU sends the acknowledgement back to the DU. If anyacknowledgement message gets miss, there is a communicationerror. Further, if there is a mismatch in between the given (com-mand) and actual position of the rod, DU generates alarm inthe alarm window of GUI as well annunciates the alarm in thecontrol room. The operators are required to take the necessaryaction on alarm annunciation. For communication in betweenChPU and DU, the following communication protocol has beenimplemented (Section III-c1).Protocol: The communication protocol between the commu-

    nication modules of ChPU and DU is given below:ChPU waits for an acknowledgement after a single transmis-

    sion of a message. The packet is retransmitted up to maximumnumber of 5 transmissions if the timer expires or a negative ac-knowledgement comes after some acknowledgement time valueof 2 seconds. For the retransmission mechanism, ChPU has aretry count which represents the number of transmissions for aspecific packet send. In DU there is a state variable sR whichstores sequence number of the packet to be received. This isused to detect duplicate packet to avoid duplicate status andalarm messages. After receive variable lifetime of 2 secondstimer expires, associated with receive lifetime value ( ), sR isdestroyed or reset. ChPU has a variable sS to store the sequencenumber of packet to be transmitted or outstanding transmission.sS is used to relate a received acknowledgement to outstandingtransmission and allow DU to detect duplicate frames. The mo-ment transmit variable life time timer expires, sS is reset. Thefollowing algorithm has been developed:1) Whenever ChPU sends a new packet, value of count is setto 1.

    2) ChPU waits for acknowledgement for T1, after sendingpacket.

    3) If ChPU receives acknowledgement before 2 seconds,packet send is successful and sS is set to 0/1(complement).

    4) If and acknowledgement is not being received,ChPU transmits packet and set , elseChPU terminates send process unsuccessfully, where sSwill not change.

    5) If 2 seconds elapsed after last data send, sS is destroyed.6) At initial stage , is source place, in which atoken can enter at any time. and are sink placesin which token exits immediately.

    TABLE IEU PLACES AND TRANSITIONS

    IV. THE PROPOSED METHOD FOR DESIGN VERIFICATIONWITH ITS APPLICATION

    We extend and improve the existing approaches to proposea framework to estimate the design metrics for its suitability tofulfill the requirements as specified in AERB. We use it for thevarious systems of NPP. We choose stochastic process becauseof the many abstractions like internal architecture of the oper-ating system, hardware, etc on which the system performancedepends. Our framework contains six phases as shown in Fig. 2.Each phase is described as follows.

    A. Phase 1: Petri net model creation

    Based on the communication protocol of ACL; we generatea Petri net model of EU and DU communication. The details ofplaces and transitions of EU are given in Table I. The methodsto create Petri net model can be found in many papers [21]. Thecreated Petri net model is shown in Fig. 3.

  • 924 IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 61, NO. 2, APRIL 2014

    Fig. 3. SPN of Embedded Unit.

    TABLE IICHPU TRANSITIONS WITH DELAY

    B. Phase 2: Model Parameter assignmentWe use a tool Time NET [22][23] for SPN creation. We keep

    a delay transitions as per the tolerant limit that is given in thespecification of the system, as given in Table II.

    , , , represent events that are supposedto occur within 1 millisecond, we set the value. As per the speci-fication of the system the waiting time of the acknowledgementmust not be more than 2 seconds, so we associate a delay of2 seconds for .The long-time behavior of this SPN can be studied by

    so-called stationary or steady-state evaluation, the method ofwhich has been described by many authors. Time NET givesthe throughput, as shown in Table III.

    C. Phase 3: Reachability Graph creationThe creation of reachability graph is explained in many pa-

    pers [21]. Table IV shows the marking of SPN of EU with theirtypes. The full reachability graph is shown in Fig. 4.

    TABLE IIITHROUGHPUT OF THE TRANSITIONS

    For the sake of convenience, w...

Recommended

View more >