核电厂RPS应用软件V&V危险分析的研究

★北京广利核系统工程有限公司 周良，张磊，杜乔瑞，梁中起

核电厂RPS应用软件V&V危险分析的研究

★北京广利核系统工程有限公司 周良，张磊，杜乔瑞，梁中起

在核电厂反应堆保护系统（RPS）仪表控制设备的数字化过程中，如何保证核安全级软件的安全性是一个重要问题。危险分析是识别系统潜在的危险，以及采取适当的手段来消除、防止或控制危险，提高安全性的一种有效方法。它在传统模拟技术仪表控制系统中已经广泛使用，但应用于针对数字化仪表控制系统的危险分析时，目前为止还没有可操作的指导标准与规范。本文提出一种适用于核电厂RPS应用软件V&V危险分析的方法，结合某堆型RPS具体论述了软件开发各阶段的V&V危险分析内容，可为相关组织制定可操作性较强的危险分析规范提供参考。

核电站；保护系统；验证与确认；危险分析

1 引言

基于计算机的系统已经在核动力厂日益广泛应用，它们对核动力厂安全的重要性也正在增加[1]。这类系统既用于安全有关级系统，也用于安全系统（例如反应堆保护或安全设施的驱动）。核电站反应堆保护系统属于核电厂1E级仪表控制设备，用以保护三大核安全屏障（即燃料包壳、一回路压力边界和安全壳）的完整性。

在核电站保护系统仪表控制设备的数字化过程中，一个必然要解决的重要问题是核安全软件的安全性。特别是福岛核电站事故发生后，国家安全监管当局根据核行业法规，对后续新建核电站数字化保护系统的安全性提出更高要求。从系统的观念出发，运用科学分析方法识别、评价、控制危险，使系统达到最佳安全。

识别系统潜在的危险，以及采取适当的需求、设计和其它制约因素来消除、防止或控制发现的危险的一个过程就是危险分析[2]，以达到预防事故、实现系统安全的目的。人们在实践中形成了多种与传统模拟仪表控制系统有关的危险分析技术，并形成了一些重要的与危险分析相关的标准或规范（例如IEEE Std 577TM-2004[3]，IEEE Std 352TM-1987[4]，IEEE Std1228TM-1994[5]和 MIL-Std-882B[6]）。而目前为止还没有可操作的软件危险分析的程序与规范，因此研究适合核电站数字化保护系统软件危险分析的程序与规范以及相关的各项技术意义重大。

2 软件危险性内涵

危险性多用于刻画具有能量、毒性或能够进行质量运动的物理设备或系统，与硬件设备不同，软件作为一种寄生性逻辑实体，软件自身不会直接对人造成伤害或对环境造成破坏。尽管作为系统重要组成要素的软件不会直接危及生命、财产和环境等安全，但由于软件设计存在缺陷，软件运行时控制设备运行不当或者软件未能控制设备运行，会形成危险。

目前标准没有明确给出软件危险性的定义，根据对软件危险性的理解，给出软件危险性的下述定义：

软件危险性是指特定软件对特定系统危险性的贡献，衡量的是在特定环境下和规定时间内因软件功能失效或需求缺陷等引发系统危险的能力。其中系统危险性受到软件（SW）、硬件（HW）、人员（Human）、外部环境（Env）的共同作用。外部环境泛指与该系统交互作用的外部系统或其他因素。比如，对于反应堆保护系统软件而言，其危险性研究涉及到保护系统软件内部组件之间的交互，保护软件与保护系统底层硬件之间的交互，保护软件与操纵员、非安全级系统等其它系统之间的交互。

保护系统中事故的发生是硬件（设备）部分、人员、外部环境和软件共同作用的结果。事件是事故的重要因素，包括引发事件、中间过程事件和后果事件。引发事件是事故过程中的第1个不希望事件，其发生标志着事故过程的开始；后果事件是造成某种恶性后果的不希望事件，它直接导致人员伤亡、财产损失、环境破坏等损失；事变事件是指在引发事件后可能发生的恶性事件，如果未得到缓减控制，这些事件将导向后果事件。引发事件、事变事件和后果事件都是事故场景过程中的一个环节，都是系统运行中的不期望事件。[7]软件之所以导致事故，就是因为软件中潜在的缺陷造成引发事件发生，或致使缓减控制措施失效。尽量避免上述情况的出现正是软件危险分析的目的。

3 软件危险分析框架

保护系统的软件危险分析应当与整个系统设计紧密结合，成为系统危险分析的一部分。系统软件危险分析的目的是精确地分析和评估系统软件引发的真实危险，并采取相应的措施，以确保把这种危险的发生概率降低到最低可接受的程度。

为了进行危险分析，必须建立相应的分析程序，以便系统、全面地规划危险分析工作。本文依据保护系统的特点以及工程经验，提出了一种适用于保护系统的软件V&V危险分析的策略和程序，如图1所示。

（1）分析策略

危险分析的成功很大程度取决于良好的方案，应使危险分析作为系统设计过程的一个组成部分，在框架下渗入各级组织的活动。在系统研制成功以后则把危险分析作为改进过程的组成部分，从而使危险分析成为生命周期的组成部分。制定“危险分析”方案帮助危险分析过程的顺利开展。

（2）分析程序

危险分析贯穿系统全生命周期。在不同的生命阶段，系统设计的详细程度不同，分析人员可利用的数据不同，因此危险性分析的过程及其详细程度也不一样，应该是一个不断深入、不断细化的迭代过程。软件危险分析人员不仅必须理解软件在系统运行中的各种作用，而且必须知道软件运行时对系统安全的影响。

图1所示的分析程序不仅给出了各项分析工作的关系，而且也给出了各项工作的角色。

下面，按分析程序论述各项分析工作。

4 RPS应用软件V&V危险分析过程

4.1 系统设计危险分析

（1）安全功能

反应堆保护系统危险的识别过程开始于对要求的安全功能、设计基准工况、选定的系统设计要素（如子系统、多样化系统等）和法规标准要求的理解。根据分析结果，可确定计算机系统的某些安全功能、设计条件、限制及未解决的危险。

反应堆保护系统指监测反应堆的运行，并根据接收到的异常工况信号，自动触发动作以防止发生不安全或潜在的不安全工况的系统。[8]反应堆保护系统主要包括反应堆事故停堆系统（RTS）和专设安全驱动系统（ESFAS）。其中运行的核安全级软件也必然要包括两部分，一部分用于执行反应堆停堆功能，当需要时产生控制动作触发反应堆停堆。另一部分用于执行专设安全设施驱动功能，安全设施包括驱动单元及适当的设备布置，根据驱动系统或者操作员发出的信号实现保护功能。

（2）功能危险分析

A. 分析对象：包括系统设计、专项功能设计、子系统设计等技术规格书。

B. 分析目标：由总体人员进行系统危险性分析，获得与软件相关的系统危险模式，确定影响系统运行的关键危险事件，及其应对措施。

C. 分析要点：

RPS系统设计危险分析应考虑安全功能的要求，进行功能危险分析，只是把重点放在硬件和软件的初步设计上。例如应把下述各项作为可能的危险：

· 硬件和软件之间的相互依赖性（例如中断和操作系统）；

· 可能使系统进入危险状态的动作序列，系统架构对可靠性指标分配的影响；

· 系统特有的可信危险，例如超前或滞后的输出、传感器输入处理故障、准确度和舍入问题、例外情况的不恰当处理、恢复动作、系统中断、输入电压或频率的波动、符合信号改变的最大可信数目、电磁干扰和超量程数值（如被零除或未初始化的指示）、CPU重启、程序下装。

系统功能危险分析，主要致力于RPS中相应软件的功能安全性分析。

RRS系统设计应规定为了阻止系统进入危险状态或者使系统从危险状态进入到非危险状态而需要由硬件或软件完成的那些功能，而且应识别和规定软件和计算机系统之间的接口。

RPS系统的危险识别由粗到细，逐步细化。危险的识别通过制定初步危险表（PHL）来完成，从而为初步危险分析（ PHA）确定了范围。在系统设计的早期进行PHA，可以确定构成系统中事故的潜在条件和可能的事故，但此时的分析是不详细的，不能准确地描述事故发展的过程，在系统设计阶段，分系统设计一旦确定，就需进行分系统危险分析。分系统危险分析深入到具体的分系统内部，通过选择具体的危险分析技术，FMEA、FTA等来确定造成潜在条件的原因和事故发展过程。

4.2 软件开发危险分析

（1）软件需求危险分析

A. 分析对象：软件需求规格书，内容包括软件顶层架构、软件接口设计、软件功能和性能需求。

B. 分析目标：在系统设计危险分析的基础上进行软件需求危险分析，确定系统不应做什么，即软件应满足哪些安全需求，同时提出软件确认测试计划中的安全要求。

C. 分析要点：

在软件需求的危险识别过程中评价软件和接口需求，并识别出可能成为危险产生原因的差错和缺陷。此阶段首先确定与安全功能相关的每一项软件需求，识别由于需求不满足可能导致的事故，并评估相应的风险。如果风险不可接受，则系统设计必须进行一定的更改，使得软件在所有的运行模式和条件下，其性能、功能和接口设计都能达到所要求的安全水平。

在进行软件需求危险识别时应将软件需求与硬件设计的相容性作为一个基本问题。例如包括下述活动：

· 分析I&C功能分站对可靠性指标的影响。

· 确信没有引入有害的“未预期功能”。例如无用的驻留功能、对外部或内部条件的不可预测响应、由于设计或实现错误产生的缺陷、未从软件中消除的研制辅助手段。

软件故障树（SFTA）、故障模式和影响分析（FMEA）等技术都可用来进行需求危险分析。需求危险分析结果是下一步设计危险分析的基础。

（2）软件设计危险分析

A. 分析对象：软件设计阶段工作一般分为概要设计和详细设计二个阶段。

B. 分析目标：检查软件设计是否体现了安全需求以及在设计过程中是否引入新的安全需求。

C. 分析要点：

一项软件需求可能由多个设计部分（如模块、文件等）来完成；每一个设计部分也可能与多项软件需求相关，需求部分和设计部分之间存在多对多的映射关系。如果设计部分风险不可接受，则需要考虑重新设计，以降低设计的风险，或采取其它措施以降低整个应用系统的风险。

某些系统的设计危险分析还涉及到软件所运行的计算机系统的硬件体系结构。此时还需要考虑硬件体系结构设计是否会引入复杂的功能，是否存在新的失效模式。这些新的失效模式在系统危险分析和需求危险分析时不能发现，但在设计分析阶段必须予以识别。

软件设计阶段的危险识别所包括的活动应确信没有引进新的危险。例如在这一阶段应进行下列活动：

· 应对可能存在的计算问题进行评价，这些问题包括错误的算法、不够的精度（错误的数据类型）、扫描速率和符号约定错误。

· 对控制逻辑中可能存在的问题进行评价，这些问题包括逻辑错误、遗漏的情况或步骤、重复逻辑、忽略的极端情况、不必要的功能、错误解释需求、遗漏条件测试、未检查变量和不正确的迭代循环等。

· 对数据结构和预期使用中的数据从属性进行评价，这种从属性损害隔离分区、数据别名使用和故障抑制问题，从而会影响安全和对危险的控制或缓解。

· 应对接口设计进行审查，包括内部接口以及同系统其他模块之间的外部接口，对接口关注的主要方面是适当规定的协议以及控制和数据链接。对外部接口应进行评价，以便核实设计中的通信协议同接口要求是相容的，接口的评价应支持冗余管理分区和危险抑制的要求，可能存在的接口和定时问题包括错误地处理接口、不正确的输入和输出时序，以及子程序/模块不匹配。

· 应确信设计符合已确定的系统限制。

· 应对非安全模块进行评价，以便确信它们不会对安全软件产生有害的影响。

本阶段主要的危险分析技术有SFTA、SHAZOP。设计危险分析的结果确定了软件实现危险分析的重点，为下一步的软件实现危险分析提供输入。

（3）软件实现危险分析

A. 分析对象：源代码和可执行代码。

B. 分析目标：软件实现危险分析主要检查在实现需求安全要求和设计安全要求以及软件实现过程中是否引入新的危险。

C. 分析要点：

软件实现工具、软件实现语言和软件实现技术是本阶段检查的重点，例如在这一阶段应进行下列活动：

· 对控制逻辑中可能存在的问题进行评价，这些问题包括逻辑错误、遗漏的情况或步骤、重复逻辑、忽略的极端情况、不必要的功能、错误解释需求、遗漏条件测试、未检查变量和不正确的迭代循环等。

· 确认算法的正确性，包括准确度、精确度，以及方程的不连续性、超量程条件、断点、错误的输入、扫描速率等。

· 评价代码中的数据结构和使用，以便确信对数据项已适当定义和使用。

· 确认软件模块与硬件和其它软件之间接口的兼容性。

· 确认软件在由需求、设计和目标计算机系统对软件提出的约束范围内运行，以便确保程序在这些约束范围内运行。

· 检查非关键代码，以便保证它不会对关键软件的功能产生有害影响，作为通用规定，安全软件与非安全软件相隔离，检查的目的是证明这种隔离是完整的。

· 核实良好的软件实践（例如代码量的限制、可重复使用代码的控制、代码初始化等）的使用。

总的来说，在软件实现阶段，软件开发人员更关心的是代码的正确性。只要需求危险分析和设计危险分析全面，所编写的代码正确且完全实现了设计要求，就能保证安全。

SFTA、SHAZOP也适用于软件实现危险分析，分析结果需形成文档，成为软件危险分析报告的一部分。代码必须经过安全验证和测试，才能投入实际使用。

4.3 危险性测试

危险性测试核实各种危险要求（禁止、俘获和联锁）已经正确实现，这种测试可验证软件在其规定的环境内正确工作。在危险性测试中应进行下述活动：

· 软件单元级测试，以检验安全软件各组成部分的正确执行。

· 接口测试，以检验安全软件各单元按预期要求运行。

· 计算机软件配置项测试，以检验软件作为一个单元的执行情况。

· 系统级测试，以检验软件在整个系统内的性能。

· 承受能力测试，以检验软件在异常情况下（例如未预期的输入值）不会引起危险。

· 验证测试工具是否引入新的危险。

5 结语

危险分析方法是传统模拟技术仪表控制系统中成功使用的一类方法，这类方法应用于数字化保护系统还处于初级阶段。核电站数字化保护系统软件开发过程中不仅要考虑软件的任务需求，也必须考虑安全需求，进行软件危险分析。本文提出了软件V&V危险分析的策略和程序，以软件开发过程常用的瀑布模型为基础，论述了软件开发各阶段的危险分析工作，为开发安全的保护系统软件提供了有益的思路。此方法应用到工程实践中，旨在为核电站数字化保护系统的设计与实现提供更加准确和全面的依据。该分析方法能够给出软件设计差错或缺陷，并通过相应措施，消除安全性隐患或将软件安全性危险控制在最低可接受的范围。

[1] AEA NS - G - 1.1, Software for Computer Based Systems Important to Safety in Nuclear Power Plants, 2000 [S].

[2] ANSI/IEEE Std 7 - 4.3.2 - 2010, IEEE Standard Criteria for Programmable Digital Devices in Safety Systems of Nuclear Power Generating Stations [S].

[3] ANSI/IEEE Std 577 - 2004, IEEE Standard Requirements for Reliability Analysis in the Design andOperation of Safety Systems for Nuclear Power Generating Stations [S].

[4] IEEE Std 352-1987 (Reaff 1999), IEEE Guide for General Principles of Reliability Analysis ofNuclear Power Generating Station Safety Systems [S].

[5] IEEE Std 1228-1994 (Reaff 2002), IEEE Standard for Software Safety Plans[S].

[6] MIL- STD - 882B, System Safety Program Requirements [S].

[7] 颜兆林, 龚时雨. 集成系统的软件安全分析 [J]. 计算机工程，2005, ( 6 ) ：141 - 142.

[8] HAF102 — 2004，核动力厂设计安全规定 [S].

Application Software Hazard Analysis of Reactor Protection System for the Nuclear Power Plant

During the digital process of the instrumentation and control equipment for the Nuclear power plant reactor protection system (RPS), how to ensure the safety of the nuclear safety class software is an important issue. The Hazard analysis is an effective way to improve the software’s safety by identifying potential hazards and taking appropriate measures to eliminate, prevent or control hazards. This technical method has widespread used in the traditional analog instrumentation control system, but for digital instrumentation and control system, there are no actionable guidance standards. This paper proposes a method of software V&V Hazard analysis which applies to RPS application software. And it discusses the software Hazard analysis during all phases of the software development for one type of Reactor’s RPS. This method provides a useful reference for relevant organizations to writing the actionable standard of software Hazard analysis.

NPP；Protection system；Verification and validation；Hazard analysis

周良（1981-），男，湖南湘乡人，工程师，硕士，现就职于北京广利核系统工程有限公司，主要从事核电站安全级DCS验证与确认工作。