田湾核电站反应堆保护系统多样化的研究

穆海洋，宋 雨，管运全

(中国核电江苏核电有限公司, 连云港 222042)

田湾核电站1-4号机组反应堆保护系统(RPS)由反应堆紧急停堆系统(RTS)和专设安全设施驱动系统(ESFAS)组成，用安全级的数字化仪控平台(Teleperm XS，简称TXS)实现，为避免可能发生的共因故障设置了两个多样性子系统(Diversity A和Diversity B)，两个子系统针对每个触发事件采用不同的触发参数、处理逻辑和不同型号的测量仪表，每个子系统均为四重冗余结构。

RPS触发信号由TXS计算机化软件对输入信号进行处理后输出。计算机软件包括系统软件和应用软件，在实际应用中，TXS执行逻辑处理的计算机采用了相同的系统软件，并且应用软件的“操作系统”和“软件功能模块”相同，如果出现软件共因故障，可能导致TXS完全失效。在上述情况下，RTS系统可以由控制室后备盘手动触发，由于手动停堆命令与TXS计算机化软件采用不同的路径，可以不受软件共因故障的影响，保证反应堆正常停堆，停堆功能手动触发原理如图1所示。

图1 停堆功能手动触发原理Fig.1 Principle of manual reactor trip

但是，ESFAS的控制室手动命令也需进入TXS计算机化软件进行逻辑处理，与自动保护系统采用相同的路径，不能起到防御软件共因故障的作用，ESFAS功能手动触发原理如图2所示。

图2 ESFAS功能手动触发原理Fig.2 Principle of manual ESFAS actuation

由于没有设置计算机软件之外的触发手段，软件共因故障将可能导致ESFAS无法输出自动和经软件处理的手动命令，反应堆可能无法进行余热导出、防止放射性物质外泄等操作，导致严重核安全事故。

为了防御软件共因故障，ESFAS必须提供旁通TXS计算机化软件的可靠触发手段。专设安全设施驱动多样性系统(或称为手动安全驱动系统，简称MASS)提供了一种软件以外的操作手段，在软件故障时，MASS可以不通过软件直接驱动ESFAS成组设备，保证核安全功能的完成。

1 背景

田湾一期工程1、2号机组和二期工程3、4号机组均采用俄罗斯VVER-1000改进型核电机组。1998年，田湾一期工程在国内首次引进数字化仪表控制系统(AREVA/SIEMENS TelepermXP + Teleperm XS)，进行安全审评时，在田湾1、2号机组仪控项目上，主要关注的问题包括：手动控制专设安全设施驱动系统问题；安全系统软件的共因故障问题；以及主控室的人因验证、隔离、防火等问题[1]。作为福岛事故后国内第一批开工的核电项目，田湾3、4号机组进行了一系列改进，其中反应堆保护系统方面的改进更是安全审评的焦点。

在反应堆紧急停堆系统(RTS)方面，在田湾1、2号机组的安全审评过程中，根据审评要求，在TXS中设置了针对未能停堆的预期瞬态(ATWS)下多样化注硼功能(AA21)，同时在运行仪控TXP中设置了ATWS下的多样化缓解功能(BE25)。在3、4号机组的审评过程中，审评单位提出，AA21依赖于保护信号触发是不合适的(考虑到在TXS系统故障情况下保护信号可能无法发出)。根据审评单位意见，二期运行仪控SPPA-T2000中增加了多样化的不依赖保护信号的应急注硼功能(AA22)。

在安全设施驱动系统(ESFAS)方面，在田湾1、2号机组的安全审评过程中，审评单位提出“安全设施触发系统序列级的手动触发均通过数字化系统来实现，当数字化系统发生共模失效时，该手动触发功能也将会丧失”。当时，TXS设备供方从系统结构(多样性A和B)、软件结构和报警信号等方面解释TXS的故障极低，TXS软件共因失效概率的经验数据值见表1[1]，并提交了德国核安全审评机构提供的分析报告。同时，反应堆设计方提供了报告证明采用部件级的手动控制可以满足超设计基准事故(BDBA)接受准则。

表1 TXS软件共因失效概率估算

考虑到1、2号机组的审评要求，以及近十年来，数字化保护系统防御软件共因故障越来越受到重视[1-7]，田湾3、4号机组改进ESFAS多样化驱动方案成为重要设计考虑。

2 相关法规和标准研究

ESFAS的多样化驱动方案在VVER机组上属首次使用，需要通过研究相关的法规标准并进行分析，明确设计需求，才能保证此方案最终成功应用于田湾3、4号机组。

2.1 多样性系统相关法规标准分析

10CFR50.62[8]规定在ATWS下，对于TRIP系统，必须设置多样化系统，执行控制棒以外的停堆功能、以及执行辅助(应急)给水和停机功能。

HAF102[9](IAEA NS-R-1)中6.1.4.2要求“停堆手段必须至少由两个不同的系统组成，以提供多样性”。

分析：对于以上要求，田湾核电站设置了手动停堆功能，以及多样化的功能AA21(ATWS注硼)、AA22(ATWS注硼的多样性功能)、BE25(多样性的停机和启动辅助给水)，达到了以上要求。

2.2 手动触发相关法规标准分析

HAD102/10[10](核电厂保护系统及有关设施)中7.3.1指出，大多数保护动作都要求具有手动触发手段。此外，对于快速停堆必须设有手动后备触发，而对其它重要的安全动作可以设有手动后备触发。在设有手动后备的地方，自动触发和手动触发共用的安全系统部件的数量应减至最少。这样的共用部件最好只限于安全驱动系统的驱动器。

IEEE603(GB 13284)[11](安全系统准则)中指出，应在控制室对自动触发的系统级保护动作提供手动触发方法，手动方法应使操纵员的离散操作次数减到最少。

IEEE279[12](核电厂保护系统准则)指出，保护系统应包括对每个保护动作的系统级的手动触发方式。手动触发依赖的设备数量应最少。

分析：田湾核电站系统级手操命令进入了TXS计算机，通过软件执行造成手动功能和自动功能之间共用的设备较多，对标准的符合性较差。

2.3 软件共因故障相关法规标准分析

HAF102[9]的5.3.1提出“必须考虑安全重要物项发生共因故障的可能性，以确定应该在哪些地方应用多样性、多重性和独立性原则来实现所需的可靠性”。

HAF102[9]的6.4.7.2指出，必须在实际可行的范围内采用各种设计，如可试验性、故障安全性能、功能多样性、部件设计或工作原理的多样性等以防止保护功能的丧失。

IAEA NS-G-1.3[13](核动力厂安全重要仪表和控制系统)的4.23-4.31节提出如下观点：应该考虑多样性的范围和级别，达到所希望的保守水平。同时，IAEA NS-G-1.3[13](核动力厂安全重要仪表和控制系统)中指出如果软件的多个版本是根据同一个软件需求规格说明开发的，故障模式的独立性可能是达不到的，一些独立开发的程序版本可能发生共因故障。

IEC 60880—2006[14]中也提出了预防软件CCF的要求，同时也指出，由于防止CCF的能力无法量化，可以基于软件能够达到的可量化的可靠性的评估进行判断。

美国核管会NRC也出版导则DI&C-ISG-02提到“软件中一个错误可能在所有冗余通道设置中是通用的”[15]。

分析：各个标准都对预防软件故障提出了要求，但是都没有要求完全排除CCF，而是要求把软件CCF限制在一个小的概率内即可。通过设置多样化的手动硬触发系统可旁通软件CCF，达到满足上述标准的要求。

3 方案实施总体思路

田湾3、4号机组以1、2号机组为参考，其RPS系统在测量和逻辑运算部分已经实现了多样性，没有必要再设置一套基于不同软件的冗余系统。但是，由于RPS采用了相同的软件，“操作系统”和“软件功能模块”仍然存在软件共因故障的可能，不能完全消除软件CCF，并且ESFAS功能手动驱动原理对手动触发标准的符合性较差。所以，综合考虑可设置一套基于硬件的手动旁通计算机软件的方案，即增加一套手动安全驱动系统(MASS)[16]。其总体思路为在主控室后备盘增加ESFAS功能的触发开关和复位开关等，每个功能的手动操作按钮由4个触点组成，分别传送到TXS系统4个通道，每个通道布置一个MASS机柜，MASS机柜可以接收操作信号、允许信号、复位信号、主辅控切换信号等，由全硬件的系统实现一定功能的逻辑处理。MASS的生成信号和计算机系统的信号经过“或”逻辑后传送到驱动控制装置。此方案既可防御软件共因故障，满足法规标准的要求，又可以独立地与原安全仪控系统集成。增加MASS后的ESFAS功能驱动原理如图3所示。

MASS应对的事故工况是RPS出现软件共因故障的情况下，一些危及核安全的事故衍生或叠加发生。MASS设计的始发事件见表2。

图3 ESFAS功能驱动原理图(含MASS)Fig.3 Principle of ESFAS actuation (including MASS)

表2 MASS始发事件Table 2 Initial events for MASS

此时，依靠软件逻辑运算的RPS系统已不再可靠，反应堆操纵员需要考虑进行手动干预。操纵员可以通过后备盘(SICS)上的报警和监视画面(OM)提供的信息，判断人工干预的必要性，确定是否操作MASS驱动必要的安全系统设备，MASS投入的程序如图4所示。

MASS对安全系统设备的驱动方式是系统级的，不需要操作多个部件即可完成必要的安全系统的驱动。MASS驱动的安全系统见表3。

表3 MASS驱动的ESFASTable 3 ESFAS actuated by MASS

续表

图4 MASS系统投运过程Fig.4 Process of MASS operation

4 结论

相比传统的模拟技术，数字化仪控系统具有结构模块化、系统精度高、自诊断能力强、人机接口界面友好、易于实现复杂的计算等优点，但是功能的高度集中以及软件的使用，也带来了一些新的问题，比如软件共因故障等[7]。针对这一现状，软件的安全性评价还需要大量的工作，另一方面，多样化的触发方案也是对运行机组改进方面较好的应对途径之一。