《核工程+数字化仪控+核安全+核动力》@EnzoReventon

核电厂功能安全分类以及相关标准

1 根据核电厂安全功能的重要性进行分类

参考 IEC61226-2005，核电厂的安全功能按其重要性分为 A、B 和C三类。

– A类

在发生任何一个DBC-2到DBC-4内部事件后，将电厂带入可控状态的安全功能（包括支持功能）都定义为A类。此处DBC是指设计基准工况，按核电厂发生该工况的频率大小，分为4级。数字越大，工况越稀有但后果越严重。

– B类

在发生任何一个DBC-2到DBC-4内部事件，电厂达到可控状态后，用于确保电厂进入安全停堆状态的安全功能都定义为B类。
在电厂正常运行时故障可以导致DBC-3或DBC-4事件的控制功能（一回路隔离）也定义为B类。

– C类

在DEC-A事件序列后将确保电厂带到并维持在最终状态的安全功能定义为C类。

2 软件可靠性要求

“软件可靠性”是软件质量度量的六大属性之一。软件可靠性的定义是软件系统在规定的时间内及规定的环境条件下，完成规定功能的能力，表明一个由软件构建的仪控系统能够按照核电安全设计要求和目标，正确执行其功能的程度。

从软件可靠性工程的角度，核安全级软件的可靠性、性能以及安全性问题都需要通过软件周期模型各个阶段的设计工作予以解决。软件生命周期各阶段与软件可靠性相关的主要活动和任务如下图所示。

软件可靠性要求，除生命周期模型，还需要考虑业内相关法规、标准对安全级软件的可靠性要求。国际上，IEEE 软件可靠性标准主要涉及软件可靠性度量体系和软件可靠性评估两方面内容

IEEE 982.1-2005 为软件可靠性度量标准，主要定义了度量软件可靠性宜采用的12 个度量参数，包括失效率、平均失效间隔时间、缺陷密度、与需求的一致性、络可靠性等，借此可对软件质量、特别是软件可靠性进行预测评估。

IEEE 1633-2008（软件可靠性操作规程）重点规定了软件可靠性评估的实施
程和可采用的软件可靠性评估模型，该标准也是当前最新的、较为全面的有关软件可靠性评估的国际标准。

最后，聚焦核电领域，核电的法规标准近几年都在不断强调核电安全级软件的可靠性设计与评估要求，但是缺乏 IEEE 那样具备具体操作指导的内容：

HAD 102/16-2004基于“只有遵循系统化、文件化和可评审的工程步骤，才能够预计并证明软件可信性”的观点，对核动力厂基于计算机的安全重要系统软件的生命周期各个阶段应实施的活动、主要内容、质量保证、以及文件编制等方面提出详细要求，从而以为安全性设计审查论证提供证据。

IEEE 7-4.3.2-2011在 5.15 可靠性一节中要求在论证核安全级数字化系统的可靠性时应考虑软件。当采用分析、现场经验或测试相结合的方法论证系统可靠性时，也将软件错误记录和趋势纳入其中。

IEC 61513-2011在 6.2.4.2.2 可靠性评定一节中要求：“软件可能的设计缺陷对功能可靠性影响的评估宜基于定性评价，并考虑设计的复杂性、开发过程的质量以及运行经验的反馈。评价宜基于先前认可的方法，宜证明软件质量符合可靠性目标。”

刘真. 核电厂安全级软件可靠性设计审查、分析与测试方法研究[D].上海交通大学,2015.

3 软件可靠性避错设计审查

设计缺陷是软件失效的根源之一，为避免软件失效，软件开发过程中尽可能避免或减少缺陷。软件避错设计审查要依据具体的技术审查条款，检查是否将这些保障软件可靠性的技术要求在软件开发过程规范并加以实现。

以软件设计与实现活动为例，通过梳理归纳美国核管会 NRC 技术告NUREG/CR-6101、国际电工委员会核电标准 IEC60880、并结合核电工程建设经验，软件可靠性设计技术审查需重点关注以下可靠性要求。包括：

在软件需求书里面给出的每个需求能否追踪到一个或者多个具体的实现该需求的设计元素li>
每个设计元素能够被追踪到一个或者多个设计元素实现的具体需求li>
是否有足够的证据表明在设计中没有计划外的功能li>
设计是否完整、协调、正确、无歧义且简单li>
静态和动态结构是否简单，设计元素间有最小的联系li>
软件结构是否实质上层次分明li>
对于创建软件结构，每个层次的改进过程是否完整、自协调、以及与上一级协调（如果有）li>
设计是否将重要的安全功能与正常操作功能分离，且它们之间设有定义明确的交互li>
浮点算法比较
慎用递归算法
中断，处理周期计时器中断
单个处理器处理多过程
动态内存管理
过程间的事件驱动通信
如果有多于一个正式的设计方法，它们是否相互协调li>
是否确认重要安全数据条目，包括它们的类型、单位、范围和误差界li>
设计元素间控制连接的设计是否正确，相协调li>
是否已证明设计元素间经过的所有参数在种类、结构、物理单元和方向上都相协调li>
是否有令人信服的证据表明在初始化之前没有使用重要安全相关的数据条目li>
在设计过程中，需求规范中所列出的设计限制是否已遵循li>
已知的对设计的外部限制是否确认并包含进设计中括硬件限制、设备限制、保护系统设备的操作、物理规律和相似的内容
将代码调入或者调出存储器
无法保证终止的循环
某种方式存入数组，指数无法保证在数组指数范围内
无条件分支
分支进入循环或者模块
分支出循环，除了直到循环结束后的声明，或者知道错误程序
将“if”声明嵌套超过 3-4 层
在“case”结构中应用默认条件
在子程序中使用多个入口点
变量过载（使用同一个变量超过一个目的）
动态指令修正
变量隐式类型
在 FORTRAN 中使用“equivalence”声明
模块带有除了向执行器输出、终止或者入档外的侧放作用。
将程序以参数的形式输给子程序
测试浮点数是否真的相等。
代码的逻辑是否正确完成重要安全设计标准li>
设计的方程和算法是否在代码中正确实现
代码是否正确实现误差处理设计li>
代码是否正确实现非正常和紧急处理设计li>
是否存在令人信服的证据表明被认为不重要的代码能够对功能、时序和重要安全代码的可靠性产生不利影响。
是否存在令人信服的证据表明，程序中包含的任何中断都不会优先于或者组织重要安全代码模块的执行
代码中所定义和使用的数据条目是否与软件设计中一致li>
代码中的每个数据条目是否表示为显式类型li>
是否存在令人信服的论据表明，没有重要安全数据条目会以非计划的方式或者被一个非预料到的模块改变li>
是否存在令人信服的论据表明，没有中断可以毁掉重要安全数据条目li>
编码模块中参数的传输是否进行一致性分析，包括类型、结构、物理单位以及参数的数值和顺序li>

4 软件可靠性容错设计审查

软件避错设计体现了以预防为主的思想，该方法适用一切类型的软件，尤其是关键领域的软件。但对于复杂的高可靠性、高安全性软件，往往难以完全避免软件的设计错误。软件容错设计体现了对软件错误的包容思想。容错设计审查是避错设计审查的“纵深防御”措施，主要审查软件错误的检测、失效的避免，以及系统恢复等，下面主要从冗余设计审查、多样性设计审查、故障检测和自恢复等方面描述软件容错设计审查的要求。

5 软件多样性设计的审查

多样性审查主要考虑人员多样性、设计多样性、软件多样性、功能多样性、信多样性和设备多样性。

– 人员多样性： 审查设计人员独立性、维护人员分组，以减少同样错误的发生。
– 设计多样性： 审查硬件和软件的不同设计方法以及设计的独立性，以使设计拥有不同的失效模式。
– 软件多样性： 审查使用不同设计者和不同程序设计，以至同样错误不会反复。
– 功能多样性： 审查系统是否使用多个子系统来执行不同的功能。
– 信多样性： 审查是否使用不同测量参数来启动保护机制。
– 设备多样性： 审查是否采用不同的设备来执行相似的安全功能，以使受到失效影响的可能尽量减小。

6 软件故障检测与自恢复技术的设计审查

对软件故障检测与自恢复技术的设计审查应重点考虑如下内容：

系统中是否设置有看门狗定时器li>
看门狗定时器是否可以对每一个执行重要功能的进程的运行状态进行监控li>
系统故障检测和自恢复功能是否能及时捕捉到程序故障、中断相应保护功能子程序，并执行内部设定的、相应故障识别修复功能li>
系统故障检测和自恢复功能能否实现以下功能的检查，包括：
‐ 是否改写系统设置的 RAM 保护区r> ‐ 采样数据是否在合理范围内r> ‐ 能否重读控制输出的反馈状态值，并与系统设置的标准范围值进行一致性检查r> ‐ 系统故障检测和自恢复功能能否对检查出的错误进行危害严重性判断，
并执行预设的恢复功能、警功能或其他必要的功能li>