核电厂保护系统软件危害分析辅助模型的构建方法研究

张杰颖 ,李 亮 ,张亚栋 ,杜乔瑞 ,张冬伟

(1.北京广利核系统工程有限公司，北京 100089；2.生态环境部核与辐射安全中心，北京 102400)

0 引言

核电厂基于计算机的保护系统(数字化保护系统)功能主要通过其软件实现相关设备安全功能必需的特点或特征。对执行安全功能的软件进行独立的验证与确认，是保证软件质量的必要手段之一[1]。危害分析是软件验证中的一项分析任务。识别危害是危害分析的第一步。基于数字化保护系统结构特点、软件关键特性和软件开发特点，从保护功能信号流逻辑路径上可能引入的不希望的信号变化入手，构建关于每个功能的、以识别潜在危害为目的的多维度软件质量度量模型。该思路奠定了建模方法的理论基础。基于采用该理论构建的软件质量度量模型已经过工程实践检验，可大大提高危害分析效率和作业质量，对辅助危害分析具有重要意义。

1 危害分析辅助模型的构建意义

1.1 软件与数字化保护系统的置信度

核电厂保护系统是监测反应堆运行，并根据接收到的异常工况信号自动触发动作，以防止发生不安全或潜在不安全工况的系统[2]。与单纯的硬件模拟系统相比，核电厂数字化保护系统是由软件和硬件组成的可编程系统，软件的实现更复杂，也更容易发生设计错误，软件对“小”错误更敏感[3]。系统在设计上采用了更大范围、更高程度的共享技术(除了更大程度上共享设备外，还共享代码和数据)，代码、数据共享使得软件有传播共因故障的可能，从而可能导致冗余硬件失效[4]。同时，由于系统分配给软件实现的功能组合在一个或多个处理单元中，致使一个处理单元中的组合功能可能出现非常难以分析的情况，且一个处理单元的故障会导致单元中多个功能同时失效。此外，一个功能也可能会通过不希望的交互影响另一个功能的执行。因此，软件的置信度会影响数字化保护系统的置信度。

1.2 危害分析与辅助模型

为了保证数字化保护系统软件设计质量与所需的安全功能相适应，提高软件置信度，必须在软件开发中应用软件验证与确认技术[2]。常规的软件验证与确认是根据核电厂设计基准要求，通过设计评审和测试评估不同失效组合及其对系统的影响，以确认系统是否满足设计需求[5]。而软件验证中危害分析的范围不仅包括电厂设计基准事件，还包括异常事件、工厂设备和系统降级运行[5]。分析人员将危害分析结论(含软件薄弱点)传递给软件设计人员，促进软件设计变更，并通过迭代分析确认针对危害的解决方案。

危害分析辅助模型又称危害导出模型，涵盖了识别危害的7个软件功能特性。7个软件功能特性包括功能性(functionality)、准确性(accuracy)、可靠性(reliability)和鲁棒性(robustness)、容量(capacity)、安全性(safety)和安保(security)，因此危害分析辅助模型可简称为FARCS度量模型。基于数字化保护系统模块化结构特点、软件关键特性和软件开发特点构建，以7个软件功能特性为维度度量软件质量，并在不同维度下基于多个考量标准(完备性、一致性、正确性、可追溯性、无歧义、可核实性、样式等)、针对功能信号可能的突变部位，构建软件设计过程中由系统环境、操作员/用户、软件组件、硬件组件及其连接可能引入的潜在危害度量模型，能够更全面、系统地识别危害,为后续的危害分析工作奠定良好基础。

2 建模理论基础

2.1 数字化保护系统结构特点

根据HAD102/16—2004[3]中的定义“计算机系统结构是计算机系统的硬件部件(处理器、存储器、输入输出设备)，它们的连接，通信系统以及软件功能在这些部件上的映像”，对于由软件和硬件组成的核电厂数字化保护系统，硬件是软件的载体，软件的各种进程、数据存储、逻辑通信路径、数据显示屏布局通过映射与硬件建立联系。软件不是独立存在的。软件组件的表现形式是系统组件。

核电厂保护系统应用软件中包含大量软件逻辑。每条软件逻辑路径对应一个功能回路，即对应一个系统功能。单个功能的触发往往需要一定数量的探测信号以达到阈值条件。探测信号由系统通过输入单元(输入设备)采集现场仪表信号获得，通过中央处理单元(处理器)进行阈值等算法处理。处理结果通过人机接口单元(输入输出设备)传输给系统操作员，并通过输出单元(输出设备)输出至现场对应设备。各系统组件间的信号传输通过通信单元和系统总线完成。

2.2 数字化保护系统软件开发特点

数字化保护系统软件开发遵循预定义的生命周期[6]，参考HAD102/16—2004，核电厂数字化保护系统软件开发生命周期始于系统需求阶段，历经系统设计、软件需求、软件设计、软件实现、系统集成、安装和调试、运行和交付后修改这几个阶段。因此，必须对计算机系统设计、软件需求、软件设计和软件实现阶段的产品实施验证[3]。软件验证中的危害分析与设计活动如图1所示。

图1 软件验证中的危害分析与设计活动

对基于计算机的系统的开发，HAD102/16—2004提出了自顶至底分解、抽象化层级和模块化结构的开发原则。在这种开发原则下，从概念提出到过程实现是设计不断深化、细化的过程。因此，随着设计的进展，危害分析的颗粒度会逐渐细化并与设计对象相匹配。

2.3 数字化保护系统软件关键特性

核电厂数字化保护系统是人机相结合的系统，包含软件、硬件和操作员。软件关键特性可分为功能特性和过程特性[7]。其中，功能特性直接与功能相关，包括功能性、准确性、可靠性、鲁棒性、时间、安全性和安保。软件功能特性如表1所示。过程特性是确保功能执行的软件开发过程特性，包括完备性、一致性、正确性、可追溯性、无歧义、可核实性和样式。软件过程特性如表2所示。为便于描述，将系统设计到软件实现各阶段的设计输出称为软件产品。软件产品包含软件文档、软件代码。

表1 软件功能特性

表2 软件过程特性

作为安全系统的核电厂数字化保护系统具有确定性的运行特性。系统的数据通信具有确定的传输时间，且在系统规格书范围内对于任何给定的输入信号序列将始终产生相同的输出和响应时间[8]。

3 建模方法

3.1 方法概述

依据HAD102/16—2004“应对计算机系统的结构和功能进行危害分析，以便确定可能危及安全功能的任何特定风险，并指出需要更改的结构或附加功能(例如自检)以减缓危害的影响”，危害分析是识别、评估危害并提供缓解或消除危害影响方法的一项分析。其目标是保证软件完成系统分配给软件的功能以及系统功能的实现不受任何潜在危害的影响。

功能实现是危害分析中的重点。核电厂数字化保护系统属于大型复杂系统。根据数字化保护系统承担的功能(总功能)将系统逐步分解为子系统，然后再将子系统分解为多个功能回路。每个回路承担特定子功能。系统分配给软件实现的功能由软件逻辑路径上不同的软件组件共同完成。这些软件组件以对应的硬件部件为载体。功能的实现不仅与其自身质量相关，还受其硬件载体及硬件载体间连接的影响。因此，可在每个开发阶段将关系系统功能实现的软件危害分析转化为与该功能实现相关的、影响软件/系统组件功能实现的潜在危害分析。

3.2 方法具体实施

对应系统设计阶段的FARCS度量模型如图2所示。

图2 对应系统设计阶段的FARCS度量模型

图2中，根据软件功能特性定义，软件/系统组件可能是信号输入单元、通信单元、处理单元、输出单元、人机接口单元或它们的任意组合。

将软件功能特性作为识别危害的质量度量指标，而将保证软件功能实现的过程特性在识别危害时作为判据使用。例如：可将识别到的系统规格书内容相关的“每种运行模式下的功能描述不全”(涉及软件功能特性的“功能性”，软件过程特性的“完备性”)作为软件“功能性”度量维度下关于“完备性”不足而引入的潜在危害。

在数字化保护系统中，输入信号在离散的时间点进行采集。采集的输入信号在系统组件间周期性地传输，并周期性地产生并输出信号。如果数字化保护系统的设计不正确，系统处理负载或通信负载的变化可能会影响信号传输速度和响应时间。由此可见，软件实现其特定目标的能力受到存储空间(负载率相关)的限制。因此，考虑将存储空间作为度量软件质量的一个指标，并将其与功能特性中的“时间”合并为一个质量度量指标“容量”。

综上所述，在从系统设计到软件实现的每个开发阶段，从功能性、准确性、可靠性、鲁棒性、容量、安全性和安保这7个功能特性维度度量软件产品；针对每个度量指标，又分别从完备性、一致性、正确性、可追溯性、无歧义、可核实性和样式这7个过程特性维度考察软件中是否存在使指标恶化的潜在危害。通过软件功能特性与过程特性的共同度量，形成一个关于软件潜在危害的度量矩阵，并通过FARCS度量模型展示。

被度量的每个开发阶段的软件产品是核电厂数字化保护系统总功能层层分解后得到的单个功能所对应的软件/系统组件，一般包含输入单元、通信单元、处理单元、输出单元、人机接口单元。

根据软件功能特性的含义(见表 1)，每个功能特性相关的软件/系统组件不同，如“功能性”涉及处理单元，“准确性”涉及输入单元、处理单元、输出单元、人机接口单元。由于电源是软件/系统组件工作的使能组件，电源故障、电压/频率波动能够影响软件/系统组件功能的实现，因此将电源质量也纳入相关软件质量度量维度下的考察指标。图2是对应于系统设计阶段的FARCS度量模型，只列出了每个软件/系统组件的功能特性以及不同功能特性下能够判断危害是否产生的软件过程特性，未列出软件/系统组件电源异常情况。对应于软件需求阶段、软件设计阶段和软件实现阶段的FARCS度量模型与此类似。

4 模型优势

FARCS度量模型以核电厂数字化保护系统模块化结构为基础。系统自顶至底分解、抽象化层级、模块化结构开发的特点使软件/系统组件与通过功能分解得到的单个功能间能够建立联系，从而可以将单个功能失效归因为相关软件/系统组件及其连接、所处环境引入到功能回路中的潜在危害。从系统设计到软件实现阶段，对于每个开发阶段中的软件/系统组件设计，设计深度不同则对应的设计对象或设计对象颗粒度不同。软件功能特性(结果)结合软件过程特性(过程)的软件质量度量方法能够统一危害识别思路，使危害识别覆盖率更高并且系统化。

5 模型实例及其应用方法

核岛一回路稳压器压力超过高3限值(阈值)触发紧急停堆，是保护系统适应核电厂工况完成的一项重要安全保护功能。国内某核电厂数字化保护系统采用基于FirmSys平台的安全级分布式控制系统(distributed control system,DCS)。FirmSys平台为安全级DCS软件开发人员提供了面向应用的语言编程环境。该开发环境决定了由系统设计文档和软件需求文档中的错误引入到系统中的潜在危害远比软件设计文档和代码中的错误本身对整个系统的危害大得多。因此，在安全级DCS软件验证的危害分析中，将危害识别的重点放在系统设计和软件需求阶段，而在软件设计和实现阶段主要关注因编程语言不合规而产生的相关危害。下面以对软件需求文档(软件需求阶段输出的软件产品)的危害分析引出FARCS模型实例并介绍模型应用方法。

软件需求逻辑如图3所示。图3中，一个输出信号、与输出信号具有逻辑相关性的采集信号及它们间的处理逻辑共同组成一个软件逻辑路径，对应一个系统功能。取决于信号源，采集信号可能由系统输入单元、系统间通信单元、人机接口单元获得，输出信号通过系统输出单元、系统间通信单元、人机接口单元输出到现场设备、其他系统或系统操作员，采集信号与输出信号间的功能逻辑在系统处理单元中计算处理。将软件逻辑路径映射到系统硬件组件及其连接，对应系统输入单元、通信单元、处理单元、输出单元、人机接口单元及存在输入输出关系的各系统组件间的连接。软件需求危害分析的范围是系统负责完成的保护功能(系统功能)、对应保护功能回路，与保护功能相关的辅助功能不作为分析的重点，其他功能(如单纯的显示、报警功能)则被排除在危害分析范围外。

图3 软件需求逻辑

以RPC1子组2反应堆停堆触发功能的软件需求逻辑为例。保护功能软件需求逻辑如图4所示。

对图4中的9个输出信号进行分析，只有HDO3信号为保护功能信号，是反应堆停堆功能回路的输出信号。分析与HDO3信号相关的采集信号，HAI1、HDI1信号来自于系统输入单元，分别为现场的稳压器压力仪表RCP005MP探测信号、压力仪表RCP005MP维护时使用的旁通信号；NDI1～NDI8 2组8个信号来自于系统间通信单元，分别与稳压器压力信号RCP006MP、RCP013MP相关，并分别从RPC2子组2、RPC3子组2通信传输进入RPC1子组2。上述信号及其相关逻辑共同完成反应堆停堆功能，是危害分析的主要对象，如图3所示。其余信号及相关逻辑(完成反应堆停堆功能相关的显示功能、系统间信号传输功能)为反应堆停堆功能的辅助功能。

图4 保护功能软件需求逻辑图

针对图3所示的软件需求逻辑，软件验证/分析人员可通过本文介绍的建模方法构建FARCS度量模型。建模时，分析并列出模型中每个度量维度下反应堆停堆功能软件逻辑路径上所有可能的潜在危害(异常的信号变化)，注意考虑系统运行环境以及可能的人员误操作、设计错误的影响，例如系统各种运行模式下功能的触发/执行/结束异常、数据处理异常、系统平台自诊断信息未及时上报给操作员/用户、违背行业设计准则等。

软件危害分析宜将输入信号作为分析的起点，以信号流向及传输路径为导向、以输出信号为终点开展分析。图3中，与反应堆停堆功能信号HDO3直接相关的2/3D1(3取2)算法模块称为主算法模块。3取2算法模块有6个输入信号，其中3个输入信号为其他算法模块的输出信号，因此3取2算法模块共涉及11个输入信号。对于3取2算法模块涉及的11个输入信号，在危害识别和判断时均要从数字化保护系统信号采集开始。

FARCS度量模型构建完成后，软件验证/分析人员在模型的引导下结合其他图纸，如接口信号所在的其他软件需求逻辑图、接口信号相关的硬件接口图、FirmSys硬件产品手册、系统设计规格书、FirmSys软件产品手册等，逐项、依次识别图3中软件需求逻辑中是否存在模型中列出的潜在危害。对于多个采集信号，根据其信号来源确定每个采集信号对应到FARCS模型中的系统单元(输入单元、通信单元、人机接口单元)。对于每个潜在危害，均在假定不存在其他潜在危害的条件下(即遵循单一故障准则)，展开分析和判断。逐项定性分析、判断每个度量维度下的每个软件/系统组件相关的潜在危害。如果软件需求逻辑中存在模型中列出的潜在危害，则需要软件验证/分析人员结合需求逻辑，评估所存在危害的影响后果，确定是否需要在软件中解决。如果潜在危害需要在软件中解决，则要对软件需求逻辑进一步分析，判断需要在软件中解决的潜在危害是否在软件中设计了预防或缓解措施，最后给出软件质量评估结果、提出软件改进建议。

6 结论

全面、准确地识别可能存在于核电厂数字化保护系统中的潜在危害是进行危害分析的必要条件，要求分析人员具备多方面的能力，如了解系统运行环境、熟悉整个系统结构及接口、清楚软件功能实现原理、理解并精通法规标准对系统的设计原则要求，并需具备丰富的功能安全、软件工程、系统设计和维护等方面的经验。在危害分析中使用FARCS度量模型辅助分析，可以避免由分析人员导致的对较重要的潜在危害的遗漏，识别软件设计中的每个薄弱点；同时，能够显著缩短危害分析所耗费的时间，提高分析效率。

软件验证与确认是系统工程的一门技术学科，能够帮助开发组织在软件生命周期内提高软件质量[9]。本文介绍的模型构建方法不仅有利于核电厂保护系统软件验证中的危险分析，而且为软件工程领域各行业软件的质量度量提供了思路，对相关研究具有借鉴和启示意义。