《核动力厂安全重要仪控系统硬件验证和确认要求》（征求意见稿）

1T/XXXXXXX—XXXX核动力厂安全重要仪控系统硬件验证和确认要求本文件规定了应用于核动力厂安全重要仪控系统生命周期过程的硬件验证和确认要求。与遵循HAD102/10-2021生命周期模型的软件验证过程协同构成完整的仪控系统生命周期的验证和确认过程。本文件适用于核动力厂安全重要仪控系统。其他类似系统或设备硬件V&V活动可根据系统或设备的特点参考本文件执行。本文件的使用者在满足硬件验证和确认活动目标的前提下，可根据实际情况对验证和确认过程及任务实施裁剪。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T41142-2021核电厂安全重要数字仪表和控制系统硬件设计要求(IEC60987:2007,MOD)NB/T20448-2017核电厂系统和软件的验证和确认IEEEstd1012-2016IEEEStandardforSystem,Software,andHardwareVerificationandValidation3术语和定义NB/T20448界定的以及下列术语和定义适用于本文件。3.1硬件部件hardwarecomponent构成系统或模块的部分。系统工程中的硬件部件通常为工程上可更换的最小单元。[来源：本文定义]3.2概念文档conceptdocumentation通过明确的文字或图表，对系统的核心概念、架构、功能、性能、安全需求等进行全面的描述和定义的文档，通常是包含了系统需求的说明性文件、系统设计方案、系统设计说明书的统称。[来源：本文定义]3.3系统需求systemrequirement对系统功能和性能的具体要求，包括硬件、软件、信息、技术、设施、或其他支持构件，不特指某一份文件。系统设计方提出的用于设备设计的设计输入，概念文档中表征系统功能、性能的需求均可以称为系统需求。[来源：本文定义]4缩略语下列缩略语适用于本文件。HDD：硬件设计描述（hardwaredesigndescription）HRS:硬件需求规格书（hardwarerequirementsspecification）IDD:接口设计文件（interfacedesigndocument）IRS:接口需求规格书（interfacerequirementsspecification）2TRA:威胁和风险评估（threatandriskassessment）VVP:验证与确认计划（verificationandvalidationplan）V&V:验证和确认（verificationandvalidation）5V&V与生命周期过程的关系5.1仪控系统生命周期过程核动力厂安全重要仪控系统通常包含多个由软件和硬件组合而成的数字化系统或纯硬件设备或设备组合，每个系统或设备的生命周期均应从生成系统或设备的需求开始，到系统或设备不再被核动力厂所需要结束。其典型过程包含系统需求、系统设计、软硬件设计与实现、系统集成、安装与调试、系统运行与维护、系统退役。除上述典型过程外，还包含对已开发物项的适用性分析过程和仪控系统的采购过程，以及可能存在的新研产品开发过程、新物项的鉴定样机开发过程。图1是典型仪控系统生命周期，重点表述了单个系统生命周期过程和硬件过程。T/XXXXXXX—XXXX3注：软件实现过程不是本文件描述对象，其目的是表征生命周期过程的完整性。图1典型仪控系统生命周期过程45.2硬件V&V与生命周期过程的关系仪控系统硬件V&V的实施围绕着单个仪控系统生命周期的硬件过程开展，以确保硬件开发过程及产品质量为根本目标，从硬件本身出发，由系统到部件，验证每个涉及硬件的开发过程，包含仪控系统开发过程的系统设计、硬件需求、硬件设计、硬件实现以及系统集成和安装与调试。另外，对于仪控系统开发过程中可能涉及的新产品开发、新物项鉴定，以及贯穿硬件生命周期过程的采购也应在硬件V&V过程中进行相关需求的验证。图2是典型仪控系统硬件V&V过程与生命周期过程的关系，硬件V&V活动执行应符合图2要求。注：当具备以软硬件集成后的系统为验证对象时，执行系统V&V。图2硬件V&V过程与生命周期过程的关系硬件V&V过程应满足如下要求：——在仪控系统生命周期的任意阶段，若已开展以系统为验证对象的V&V活动，不必对相同的验证对象执行单独的硬件V&V活动，以避免由于重复工作造成的资源浪费。如，仪控系统的需求以系统为单位提出时，则概念V&V阶段以系统为单位执行V&V活动，不必单独执行硬件概念V&V活动。——需求V&V阶段应确保硬件需求与软件需求共同实现系统需求。——新研产品开发过程、新物项的鉴定样机实现过程以及可能存在的其他子系统过程，应根据子系统或产品开发的生命周期过程递归地执行本文件第8章所述的硬件V&V过程，关注每个独立生命周期过程需求生成的正确性。——对于典型生命周期过程，硬件实现V&V活动的完成代表着软件实现V&V完成，且软硬件集成完成，设备状态正常，满足转入测试V&V的条件。6完整性等级T/XXXXXXX—XXXX5完整性等级的确定基于系统或硬件设备对用户和需求方的重要性，硬件完整性等级量化了安全分级、关键性、通信安全性、结构复杂性及其他硬件独特特性。完整性等级通过关键性分析任务确定。完整性等级用于确定V&V活动最小任务集，及V&V活动执行的严格程度。随着完整性等级的降低，与V&V任务相关的执行范围、执行强度和严酷程度也会降低，详见NB/T20448。本文件主要适用于核安全级仪控系统硬件V&V活动，完整性等级划分的意义在于将主要资源和V&V重心放在重要程度高的硬件上。从系统角度看，在完整性等级分析过程中，完整性等级分配应递归地应用于每个系统元素的部件，不必对目标系统的所有子系统或元素使用相同的完整性等级方案。随着开发阶段将解决方案逐步分解细化，完整性等级方案也逐步细化，例如，概念阶段将完整性等级分配到系统或系统的主要功能，需求阶段将完整性等级分配到子系统或硬件需求，设计阶段将完整性等级分配到部件等。子系统或部件不能含有比其所属系统更高的完整性等级，系统的完整性等级应与该系统内任何独立元素的最高完整性等级一致，系统元素的最高完整性等级应与所属系统的完整性等级一致。硬件V&V工作的完整性等级方案和最小任务集的对应关系应记录在VVP中。若上游输入中存在已定义的硬件V&V工作的完整性等级，可直接使用，若给出了应用软件或嵌入式软件的完整性等级，对于承载应用软件或嵌入式软件的系统或硬件拥有与软件相同的完整性等级。若由开发人员定义完整性等级，则在关键性分析任务中验证其正确性。若尚未定义完整等级，则通过关键性分析任务确定完整性等级。本文件附录A给出了一个基于安全功能关键特性的完整性等级确立方案，用于规范硬件V&V工作中关键性分析任务。在硬件V&V活动中，应通过在整个生命周期中执行V&V关键性分析任务，持续地对分配的完整性等级进行评审和更新。当完整性等级发生变更时，应重新评审和更新V&V计划，以确保整个生命周期过程完整性等级是恰当的。如果要修改任何部件的完整性等级，则应评估这一修改对现有需求的影响，以确定在系统和硬件上需要执行的额外活动和任务，包括为修改完整性等级的系统或硬件选择V&V任务，并对之前的生命周期阶段执行这些V&V任务。7公共V&V过程公共V&V过程是可能贯穿整个生命周期的活动，包含管理V&V过程、获取V&V过程，以及配置管理V&V等过程。管理V&V过程从制定VVP开始，直至生成最终V&V报告结束，管理V&V过程注重V&V工作规划、V&V工作接口、V&V变更影响，以及V&V工作持续改进、V&V度量等。获取V&V过程从定义获取系统或产品的需求开始，直至系统或产品验收结束，获取V&V过程注重系统需求评审、明确获取过程中V&V工作范围、规划与供应方的接口，以及对获取产品验收或提供验收支持配置管理V&V过程注重配置管理流程及配置项的完整性和充分性。以上公共V&V过程的验证活动，与软件V&V过程协同一致，每个完整性等级的最小任务集、各任务要求及输入输出，以及V&V度量等应符合NB/T20448相关章节要求。对本文件第5章，图1和图2中所列出的，不属于典型生命周期阶段的活动，如以下所列活动，可在公共V&V过程中实施。——已开发物项的适用性分析；——新产品需求验证；——新增鉴定需求验证；——硬件采购需求验证。8硬件V&V过程8.1硬件V&V过程概述8.1.1总则硬件V&V过程是验证既定的产品开发活动是否符合该活动的要求，以及确认产品是否满足其预期用途和系统需求。这种验证和确认活动通常通过对产品和产品开发过程执行分析、评价、评审、检查、评估和测试等V&V任务来完成。本文件第7章“公共V&V过程”列出了本文件第5.2条“硬件V&V与生命周期过程的关系”所述的仪控系统硬件生命周期的公共V&V过程，如管理V&V、获取V&V、配置管理V&V等过程；6本章列出了5.2条所述的仪控系统硬件生命周期的硬件V&V过程，如概念V&V过程、硬件需求V&V过程、硬件设计V&V过程、硬件实现V&V过程、测试V&V过程及安装与检验V&V过程所需执行的V&V任务及各任务的输入和输出文件。在仪控系统生命周期中可能存在其他质量验证或分析活动，如HAF003规定的元器件采购加工过程工艺控制要求、物项采购过程的买方验证要求，设备加工制造工艺控制要求，这些质量控制要求是实现硬件产品质量控制的手段，与硬件V&V目标是一致的。测试作为一项质量验证活动，通常包括测试计划、测试设计、测试规程、测试用例以及测试执行等，在实施过程中可以由不同组织承担。完整性等级决定了测试工作的执行强度，应符合NB/T20448相关章节的要求。以上质量相关活动，应根据组织独立性原则与硬件V&V活动协同开展，在VVP中规定协同职责，对相同对象、相同目的活动不必重复开展，应遵循如下原则：——若执行以上类似活动的组织是独立于开发团队的组织，可使用其活动输出；——若执行以上类似活动的组织与开发团队属于同一组织，则硬件V&V工作中应至少对其过程计划及输出进行评审。8.1.2硬件V&V任务集核安全级仪控系统各阶段硬件V&V过程应执行的V&V任务详见表1~表6，其他系统根据其完整性等级确定所需执行的V&V任务。可以通过执行可选V&V任务来加强硬件V&V工作，可选V&V任务参考NB/T20448相关附录。8.2概念V&V过程概念V&V过程的目的是为了验证概念文档满足系统需求及合同要求。表1列出了以下概念V&V任务的内容以及要求的输入和输出。a)概念文档评价；b)需求分配分析；c)可追溯性分析；d)关键性分析；e)危害分析；f)信息安全防范分析；g)风险分析。以本文件图1“典型仪控系统生命周期过程”所列出的典型仪控系统生命周期为例，系统设计以软硬件组合而成的系统提出，概念V&V过程验证对象宜以系统为单位。表1概念V&V过程8.2.1概念文档评价a)验证概念文档是否满足系统需求并与合同技术要求一致。b)验证与接口系统的约束或局限性。c)分析概念文档，并验证以下内容需求：2)系统性能（例如，系统响应时间、系统精度、系统裕量、网络交换3)功能需求的可行性和可测试性。5)运行和维护要求（例如，部件设计寿命）、环境要求。6)来自现有系统的移植需求（如适用）。7)硬件技术（现有技术新应用、新技术）。供应商开发计划和概念文档评价T/XXXXXXX—XXXX78.2.2需求分配分析根据系统需求验证分配给硬件、软件和用户接口需求的正确性、准确性和完整），1)验证特定应用的需求（如功能多样性、故障检测、故障隔离以及诊2)验证已完整指定用户对系统的维护要求。3)验证从现有系统的移植和系统更换满足系统需求（如适用）。需求分配分析8.2.3可追溯性分析a)确定所有系统需求（这是硬件需求可追溯性的开始），验证这些需求是b)识别需求，对需求进行分类，区分是否进行需求追踪。需追踪的需求包括但不限于功能、性能等技术性需求、设备需求、环境需求、鉴定需求c)对需要追踪的需求按阶段进行正向和逆向追溯：8.2.4关键性分析主要功能、硬件部件、子系统或其他组件相关的系统需求分配完整性等b)记录分配给各个组件（例如，需求、主要功能、硬件部件、子系统或其他组件）的完整性等级。出于硬件V&V规划的目的，给系统分配的完整c)验证任意组件是否对已分配较高完整性等级的部件造成影响，如果存在8.2.5危害分析a)识别导致安全功能失效或影响安全功能执行的潜在危害（例如，系统故障、子系统故障、模块故障、供电故障、压力、辐射、温度和湿度等环d)确定每种危害的缓解策略。8.2.6信息安全防范分析a)查看系统所有者对可接受的安全风险级别的定义。8b)从安全角度分析系统概念，并确保识别机密性（披露敏感信息/数据）、为归因于个人/流程）方面的潜在安全风险。包括对要处理的信息/数据c)分析系统本身引入的信息安全风险以及与系统交互的环境相关的信息安8.2.7风险分析b)提供消除、减少或减轻风险的建议。8.3硬件需求V&V过程硬件需求V&V过程的目的是为了证明硬件需求是正确的、完整的并准确的满足分配给硬件的系统需求，生成系统测试计划和验收测试计划。表2列出了以下硬件需求V&V任务的内容以及要求的输入和输出。a)需求评价；b)接口分析；c)可追溯性分析；d)关键性分析；e)系统测试计划V&V；f)验收测试计划V&V（验收测试相关文件根据验收责任方要求发布）；g)危害分析；h)信息安全防范分析；i)风险分析。硬件需求过程在系统需求被定义并分配到硬件元素之后开始。硬件需求V&V过程需与软件需求进行相互验证，以证明硬件需求总体上满足系统需求。表2硬件需求V&V过程8.3.1需求评价收、用户操作和用户维护)的正确性、一致性、完整性、准确性、可读性和可2)并确认硬件需求遵循标准、引用文件、规3)运用领域专业知识、原型开发结果、1)验证硬件需求文件所有术语和概念编写一致；2)验证硬件需求具有内部一致性。T/XXXXXXX—XXXX92)验证硬件需求文件定义了所有首字母缩略8.3.2接口分析验证与确认硬件与软件、用户、操作员、其验证各接口均已说明，并包含性能准则（电8.3.3可追溯性分析分析已识别关系的正确性、一致性、完整性和验证硬件需求与概念文档之间的关系按一致1)验证每个硬件需求都能追踪到概念文档。8.3.4关键性分析告8.3.5系统测试计划V&Va)规划系统测试，以验证系统需求（例如，功能、性能、静态、瞬态b)规划系统需求到测试设计、用例、规程和结果的追踪。c)规划测试设计、用例、规程和结果的文档。2)用户文件（例如，培训材料和程序变更）的充分性。3)在边界（例如，数据和接口）和压力条件下边界的性能。e)验证系统测试计划满足以下准则：1)符合项目定义的测试文档目的、格式和内容。f)确认系统测试计划满足以下准则：1)所用测试方法和标准的适当性。4)运行和维护要求的可行性和可测试性。8.3.6验收测试计划V&Va)规划验收测试，以验证系统需求（例如，功能、性能、静态、瞬态b)规划系统需求到测试设计、用例、规程和结果的追踪。c)规划测试设计、用例、程序和结果的文档。d)验收测试计划应满足以下内容：1)运行环境中的系统应符合验收要求。e)验证验收测试计划满足以下准则：1)符合项目定义的测试文档目的、格式和内容。f)确认验收测试计划满足以下准则：2)运行和维护要求的可行性和可测试性（例8.3.7危害分析a)识别导致每个系统危害的硬件需求。b)验证硬件解决、控制或减轻了每个危害。8.3.8信息安全防范分析a)确认在HRS和IRS中识别的信息安全防范需求解决了系统概念引入b)验证系统信息安全防范需求将已识别的信息安全防范风险降低到可8.3.9风险分析a)使用先前的风险任务报告，审查和更新风险分析。b)提供消除、减少或缓解风险的建议。8.4硬件设计V&V过程硬件设计V&V过程的目的是为了证明硬件部件设计过程、硬件子系统设计过程、硬件集成设计过程满足硬件需求规格书、满足硬件性能、故障安全性及可靠性要求，并生成硬件部件测试设计、集成测试设计、系统测试设计以及验收测试设计。表3列出了以下硬件设计V&V任务的内容以及要求的输入和输出。a)设计评价；b)接口分析；c)可追溯性分析；T/XXXXXXX—XXXXd)关键性分析；e)硬件部件测试计划评估；f)硬件部件测试设计评估；g)集成测试计划V&V；h)集成测试设计V&V；i)系统测试设计V&V；j)验收测试设计V&V；k)危害分析；l)信息安全防范分析；m)风险分析。在硬件需求得到批准后，开始硬件设计过程，形成详细设计文件，以满足具体的硬件需求。根据硬件的不同，设计可表现为清单、图纸、电路图和其他机电描述的形式。硬件部件设计V&V过程、硬件子系统设计V&V过程、硬件集成设计V&V过程可分别开展，最终结果应体现在硬件设计V&V报告中。硬件部件测试、集成测试相关测试活动，在满足组织独立性的情况下，可直接使用其他组织的输出。对于某些仪控系统，无应用软件或其他原因导致的在硬件集成的环境下无法开展集成测试活动，在不影响产品质量的前提下，相关验证内容可放在系统测试阶段开展。附录B给出了一种基于规则模型的验证技术，硬件设计V&V执行过程中可参考。表3硬件设计V&V过程8.4.1设计评价1)验证硬件设计满足硬件需求和设计输入基线。4)确认详细设计及其元素间的相互作用不会导致不1)验证所有的术语和设计概念编写一致。2)验证设计元素的内部一致性。1)验证所有的硬件需求都包含在硬件设计中。1)验证文档对预期读者是可读的、可理解和无歧义1)验证是否有用于确认每个硬件设计元素的客观验8.4.2接口分析8.4.3可追溯性分析），验证设计元素和硬件需求之间的关系是按一致的详细程度规1)验证所有的设计元素都可以追踪到硬件需求。2)验证所有硬件需求都可以追踪到设计元素。8.4.4关键性分析使用HDD和IDD审查和更新先前关键性任务报告中的现有8.4.5硬件部件测试计划评估8.4.5.1完整性等级4、3和2a)验证开发人员的硬件部件测试计划是否符合项目定义b)确认开发人员的硬件部件测试计划是否满足以下准则：2)外部特征符合硬件需求和设计。3)单位要求之间的内部一致性。5)硬件集成和测试的可行性。8.4.5.2完整性等级1T/XXXXXXX—XXXX8.4.6硬件部件测试设计评估8.4.6.1完整性等级4、3和2a)验证开发人员的硬件部件测试设计是否符合项目定义b)确认开发人员的硬件部件测试设计是否满足本文件8.4.6.2完整性等级18.4.7集成测试计划V&Va)规划集成测试，以确认系统集成装配后的正确性。b)规划系统需求到集成测试设计、用例、规程和结果的追c)规划集成测试设计、用例、程序和结果的文档。d)集成测试计划应满足以下内容：2)外部特征与系统要求保持一致。8.4.8集成测试设计V&Vb)继续集成测试计划中要求的追踪。验证集成测试设计符c)确认集成测试设计满足本文件8.4.7条“集成测试计划8.4.9系统测试设计V&Vb)继续系统测试计划中要求的追踪。验证系统测试设计符c)确认系统测试设计满足本文件8.3.5条“系统测试计划8.4.10验收测试设计V&Vb)继续验收测试计划要求的追踪。验证验收测试设计符合c)确认验收测试设计满足本文件8.3.6条“验收测试计8.4.11危害分析a)验证实现关键需求的设计元素不会引入新的危险，验证b)评估已确定的缓解策略，以验证每个危害是否得到预8.4.12信息安全防范分析a)验证设计元素符合系统架构设计的信息安全功能，并且b)验证已识别的安全威胁和漏洞是可预防、控制或缓解的（任何未经缓解的威胁和漏洞都将作为系统和硬件运8.4.13风险分析a)使用先前的任务报告，审查和更新风险分析。b)提供消除、减少或减轻风险的建议。8.5硬件实现V&V过程硬件实现V&V过程的目的是为了证明制造的每一个硬件部件都满足整个系统的性能、安全性和可靠性要求，证明硬件制造过程、硬件集成过程满足硬件设计要求，且硬件实现过程未引入影响系统安全的风险，且生成系统测试用例和验收测试用例。表4列出了以下硬件实现V&V任务的内容以及要求的输入和输出。a)制造组件文档评价；b)接口分析；c)可追溯性分析；d)关键性分析；e)硬件部件测试规程和用例评估；f)集成测试规程和用例V&V；g)系统测试规程和用例V&V；h)验收测试规程和用例V&V；i)硬件部件测试执行评估；j)危害分析；k)信息安全防范分析；l)风险分析。在硬件设计被批准后，开始硬件制造(实现)过程。硬件实现V&V使用的方法包括目视检查、质量抽样测试、物理测量、形式/匹配检查以及完整的部件分析/测试。在实现过程中，硬件是由原材料制造的，电子元器件被选择并集成到电路板上，机械元件被塑造和连接，制造的零部件是由模具和铣削过程以及T/XXXXXXX—XXXX其他硬件制造方法创建的。硬件部件测试、集成测试相关活动，在满足组织独立性的情况下，可直接使用其他组织的输出。硬件实现V&V最终验证了应用软件集成到硬件中，并且上电后状态正确，满足开展下一阶段测试的先决条件。表4硬件实现V&V过程8.5.1制造组件文档评价a)正确性b)一致性验证制造组件类文件之间的一致性，如术语c)完整性验证制造组件文档内容完整，如：生产记录包含d)准确性8.5.2接口分析在满足组织独立性的情况下直接使用其他组织输出，不满足组织独立8.5.3可追溯性分析在满足组织独立性的情况下直接使用其他组织输出，不满足组织独立b)分析已识别关系的正确性、一致性和完整性。任务准则如下：验证已制造的组件安装、排布方式、顺序等均8.5.4关键性分析使用制造的组件及其相关文档审查和更新先前关键性任务报告中的现告告8.5.5硬件部件测试规程和用例评估在满足组织独立性的情况下直接使用其他组织输出，不满足组织独立8.5.5.1完整性等级4、3和2a)验证开发组织的硬件部件测试规程和用例符合项目定义的测试b)确认开发人员的硬件部件测试规程和用例8.5.5.2完整性等级18.5.6集成测试规程和用例V&Va)编制用于集成测试的测试规程和用例。b)继续进行集成测试计划要求的追踪。d)确认集成测试规程和用例满足本文件8.4.8“集成测试设计V&V硬件图纸（例如，8.5.7系统测试规程和用例V&Va)编制用于系统测试的测试规程和用例。b)继续进行系统测试计划要求的追踪。d)确认系统测试规程和用例满足本文件8.4.9“系统测试设计V&V例8.5.8验收测试规程和用例V&Va)编制用于验收测试的测试规程和用例。b)继续验收测试计划中要求的追踪。d)确认验收测试规程和用例满足V&V活动8.4.10“验收测试设例8.5.9硬件部件测试执行V&V在满足组织独立性的情况下直接使用其他组织输出，不满足组织独立使用开发人员的硬件部件测试结果验证硬件部件8.5.10危害分析b)评估已确定的缓解策略，以验证每T/XXXXXXX—XXXX8.5.11信息安全防范分析b)验证已识别的安全威胁和漏洞得到预防缓解的威胁和漏洞都将作为系统和硬件运行的一部分进行记录8.5.12风险分析a)使用先前的任务报告，审查和更新风险分析。b)提供消除、减少或减轻风险的建议。8.6测试V&V过程测试V&V过程的目的是为了证明所有系统需求均得以确认，软硬件集成后的系统满足系统需求及合同技术要求，测试过程中未引入新的影响系统功能执行的风险。表5列出了以下测试V&V任务的内容以及要求的输入和输出。a)集成测试执行；b)系统测试执行；c)验收测试执行；d)可追溯性分析；e)危害分析；f)信息安全防范分析；g)风险分析。系统测试是在完整的软硬件集成后的系统上执行的，以确认满足系统需求。然而，系统需求中可能存在的破坏性测试要求（如需通过环境试验、地震试验等手段证明其满足需求），根据HAF601的要求，需通过搭建模拟件的方式进行验证，用于运行使用的系统或设备通过分析手段证明其具备与模拟件相等同的能力。表5测试V&V过程8.6.1集成测试执行b)分析测试结果以确认系统集成的正确性。c)确认测试结果可追踪至测试设计或测试计划中建立的d)根据集成测试计划的要求记录结果。e)记录实际测试结果与预期测试结果之间的差异。例8.6.2系统测试执行b)分析测试结果以验证硬件满足系统需求。c)确认测试结果可追踪至测试设计或测试计划中建立的d)根据系统测试计划的要求记录结果。e)使用系统测试结果来验证硬件满足测试验收标准。f)记录实际测试结果和预期测试结果之间的差异。例8.6.3验收测试执行b)分析测试结果以验证硬件满足系统需求。c)确认测试结果可追踪至测试设计或测试计划中建立的d)根据验收测试计划的要求记录结果。e)使用验收测试结果来验证硬件满足测试验收标准。f)记录实际测试结果和预期测试结果之间的差异。例8.6.4可追溯性分析例8.6.5危害分析a)验证测试仪器及测试过程不会引入新的危害。b)评估已确定的缓解策略，以验证每个危害得到预防、缓8.6.6信息安全防范分析a)验证已实现的系统不会增加信息安全风险。b)验证已识别的安全威胁和漏洞得到预防、控制或缓解（任何未经缓解的威胁和漏洞都将作为系统和硬件运8.6.7风险分析a)使用先前的任务报告审查和更新风险分析。b)提供消除、减少或减轻风险的建议。8.7安装与检验V&V过程安装与检验V&V过程的目的是为了证明系统或设备按约定交付到预定地点，系统或设备在其运行环境中的状态是正确的，且在交付安装过程中未引入新的影响系统安全的风险。表6列出了以下安装与检验V&V任务的内容以及要求的输入和输出。T/XXXXXXX—XXXXa)安装配置审核；b)安装检查；c)危害分析；d)信息安全防范分析；e)风险分析。安装与检验V&V工作的结束代表着一个典型系统生命周期验证过程结束，后期可能存在的改造过程的验证递归地执行本文件各生命周期所要求的验证活动。表6安装与检验V&V过程8.7.1安装配置审核a)验证安装包中包含了正确安装和操作硬件所需的所有硬件b)验证所有与现场相关的参数或条件，以验证提供的值是正8.7.2安装检查a)进行分析或测试，验证已安装的硬件与提交给V&V的硬件b)验证硬件是否按指定方式初始化、执行和终止。c)在从一个硬件版本过渡到下一个硬件版本时，验证硬件是否可以替换为新版本，而不会对其余系统组件的功能产生d)验证过渡期间持续运行和服务的要求，包括用户通知的要e)评价下装的应用软件版本及过程的正确性。f)评价系统上电后状态的正确性（无功能故障、机柜状态故g)验证已交付产品满足系统设计要求。8.7.3危害分析a)验证安装过程和安装环境不会引入新的危害。b)评估已确定的缓解策略，以验证每个危害得到预防、缓解或控制（任何未缓解的危害都会被记录下来，并作为系统8.7.4信息安全防范分析a)验证已安装的硬件不会给整个系统带来新的或增加的漏洞b)验证已识别的安全威胁和漏洞是否得到预防、控制或缓解（任何未缓解的威胁和漏洞将作为系统和硬件操作的一部8.7.5风险分析a)使用先前的任务报告查看和更新风险分析。b)提供消除、减少或减轻风险的建议。表（规范性）基于安全功能关键性识别的完整性等级方案A.1概述本附录给出了一种基于安全功能关键性识别的完整性等级建立方案，其目的是为了规范工程实施过程中完整性等级建立的方法。该方案是通过对系统、子系统、部件等的安全功能关键特性进行赋值，进而得出完整性等级。安全功能关键特性考虑硬件的关键特性对执行安全功能的影响，根据本文件第6章完整性等级的定义，硬件安全功能关键特性主要为：安全分级、关键性、结构复杂性、通信安全性以及其他硬件独特特性。A.2完整性等级完整性等级应被记录在VVP中，生命周期各阶段通过关键性分析任务对完整性等级不断更新。本附录综合考虑了安全分级、关键性、结构复杂性及通信安全性方面的要求，定义了4级完整性等级方案，如表A.1所示。表A.1完整性等级的分级方案4通信安全性相关方面的影响，综合评分高的3性、通信安全性方面的影响，综合评分较高的系统2系统、子系统或部件安全重要程度一般，对系统影响程度一般。综合考虑安性、通信安全性方面的影响，综合评分较低的系统1系统、子系统或部件安全重要程度较低，对系统影响程度较低。综合考虑安性、通信安全性方面的影响，综合评分低的A.3建立完整性等级A.3.1建立架构框图分析人员应根据对目标系统的掌握在产品生命周期初期尽可能完整地识别出系统元素，构建出系统的结构框图，并在随后的工作阶段对前一阶段的结构框图进行更新。结构框图的构建可以从架构、功能或两者组合向下构建。A.3.2特性度量表A.2给出了对于系统/子系统/部件的安全分级、结构复杂性、通信安全性的定义，其赋值根据仪控系统特性逐级降低，采用综合评分法汇总各特性的赋值，进而确定完整性等级。表A.2硬件安全功能关键特性T/XXXXXXX—XXXX统A.4建立完整性等级应用举例A.4.1构建架构框图根据功能和架构的组合，以某一典型的反应堆保护系统为例，构建架构框图，如图A.1所示。图A.1架构框图示例注：本架构以核电厂专设安全逻辑系列A列为例，逻辑系列B列架构相A.4.2特性度量本节给出了一个基于图A.1架构的反应堆保护系统完整性等级方案示例，表A.3、A.4、A.5分别为系统、子系统和部件的完整性等级方案示例。表A.3某安全级DCS系统完整性等级方案示例级144424244424334424444424534424643424表A.4某安全级DCS系统中子系统完整性等级方案示例14442424242434331444421454442464421474331484242493442434213333134421344324442133432442424表A.5某安全级DCS系统中部件完整性等级方案示例性性级14442424342434242444342453343463342474342484342494331433434T/XXXXXXX—XXXX性性级42213421182413134131343213421182412182432131111111421821421824421343213412182（资料性）基于规则模型的验证技术B.1概述基于规则模型的硬件V&V方法是一种数字化的验证方法。该方法提供一种从需求到设计实现搭建形式化数据的桥梁，为硬件V&V的人工手动核查向自动化验证提供思路。该方法的提出基于硬件设计文件种类繁多、数量庞大，且其依据的设计输入众多，各类设计要求分散且原理复杂，采用人工验证的方式，在验证效率和验证质量方面存在显著且亟待解决的局限。基于规则模型的硬件V&V方法是建立一种目标规则模型框架，以规则模型框架为基础，将设计输入和验证对象（设计输出）分别转化为目标规则模型和验证对象模型，通过对比目标规则模型与验证对象模型的方式，实现验证。基于规则模型的硬件V&V方法是建立在设计输入数字化的基础上，根据当前现状，设计输入通常是以包含图、表的文档形式传递，设计输出也通常是文档形式，可采用不限于图文识别的方式来实现设计输入和输出文档的数字化。对于规则模型和对象模型的建模方式方面，常规的可采用数据库软件组织对象数据完成建模。复杂数据处理时可采用基于模型的系统工程方法来组织这些数据。实际工作中可权衡各种方法利弊，选择合适的验证方案。B.2规则模型的构建B.2.1规则模型数据来源使用规则模型验证的前提是验证基准和验证对象均需数字化，基于验证方法确定数字化的形式（差模文件、存储于数据库的离散数据、或其他数据格式）。目标规则模型的数据来源，是由设计需求和产品基线耦合而确定的一系列硬件设计输入数据，设计需求包含上游设计基线，即各类需求规格书、设计原则或变更函件等文本类的设计要求，以及FD/SAMA图纸、IO清单等图表类设计要求，也包含系统设计文件、硬件需求文件等，这些数据汇总即形成需求数据库，用于构建需求规则模型；产品基线包含设计约定规则、各产品的技术指标和应用限制条件及接线方式等，这些数据汇总即形成产品数据库，用于构建产品规则模型。需求数据库中的需求和产品数据库中相应的产品组织起来，即形成了设计基准数据库。对象规则模型的数据来源，是生命周期各阶段的设计输出数据。B.2.2产品规则模型的构建产品规则模型通常用于检查数据本身的自洽性及产品使用的正确性，产品规则模型按验证内容的不同，可分为设备命名规则、逻辑性检查规则、产品应用规则等。表B.1给出一个产品规则模型的范例。表B.1产品规则模型范例型机箱号为“X10X2CQ，其中X1为机柜流水号，为0~9范围内的数字，X2为1~9连槽位号为1~E的16进制，机箱号and槽位号不重复且不遗漏，槽位上的模设备编号为“X1X2X3Y1Y2”，其中X1为机箱流水号，X2为F或R(F为正面编号，R为背面编号)，X3为槽位号。Y1Y2=VO&模块型号后两位为“PL”:优选Y1Y2=IM&模块型号后两位为“PA”or“PD”orY1Y2=IO&模块型号后两位为“AI”or“DI”or“AO”or“DO”:调理模块。设备规格型号设备编号“X1X2X3Y1Y2”，Y1Y2=XK:继电器，测该设备规格型号为继电器数据库产品应用规则模设备选型规T/XXXXXXX—XXXX型则设备接线规则SAPW21：+=电压：24V~28V&电流：DC&介质SAPW21：-=电压：0V&电流：DC&介质：导线&线径：0.5mSAPW21：PE=电压：“”&电流：“”&介质：导线&线径：0.5设备匹配规则USER供电的4mA~20mA的信号调理分配=(模块型号：SAPA21&机箱型号：SACB21&转接型号：SAST11&接线单元型号：SATMB2)or(模块型号：“”&机箱型号：“”&转接型号：“”&接线单元型号：SB.2.3需求规则模型构建需求规则模型的构建通常关联到系统或硬件的生命周期，构建原则是从总体到局部，在硬件验证和确认活动中，需求规则模型是功能需求与架构的融合。在设计初期，需求规则模型用于系统设计和硬件需求设计的验证，随着生命周期的推进，需求规则模型逐步融入系统设计和硬件需求设计的数据，最终用于硬件设计验证。表B.2给出一个需求规则模型的范例。表B.2需求规则模型的范例系统子系统2EAAEABEACEADEAHEAGEESEAUEAV外部电源柜反应堆保护系统1000001101010100000110010110000011001011000001100101010000101101001000010101010100001010101010000101010100100011010100010001100101001000110010100100011001010001001011010000100101010100010010101010001001010101注：柜内供电的验证基于用电设备和输入输出信号供电需求，建立设B.2.4对象规则模型构建对象规则模型的构建方式同目标规则模型类似，建模过程注重验证对象所处的生命周期阶段。B.3建模工具选用不同的建模工具或不同的建模语言，构建的模型不同，本文的重点不是建模工具的介绍，重点是为建模规则提供思路性引导。但在众多基于模型的技术中，可能会涉及多种定义，如需求、模块、类、对象、行为等等。同一定义在不同的建模语言或不同的建模技术，甚至不同的建模工具中会有不同的含义，同一种含义在不同的建模语言或不同的建模技术中会定义成不同的含义。例如，通过识别一组实体（系统或硬件或硬件组）所共享的共用特性来应对复杂性的方式，从而使这些实体能够由具有这些共享特性更一般的实体来表达（建模），这个原则在某一建模语言中被定义为“类”，“类”的实例为“对象”；在另一建模语言中被定义为“块”，对“块”的实例同样定义为“块”。基于以上，我们可以将类似表G.1中，设备编号为“X1X2X3Y1Y2”定义为一个类，X1、X2、X3、Y1、Y2定义为属性，当Y1&Y2为CQ时，代表设备为机箱，即为对象。该技术的应用注重目标规则和验证对象规则的构建，可以选择任何一种适用的建模技术或建模语言。T/XXXXXXX—XXXX（资料性）基于标签和规则的自动追踪技术C.1概述基于标签和规则的自动追踪技术用于可追溯性分析任务，为生命周期各阶段需求标签化管理及需求手动追踪转向自动追踪提供一种思路。该方法的提出一方面基于核安全级仪控系统需求多源、异构且上游设计输入需在生命周期不同阶段作出响应（如FD/SAMA图、IO清单等用于设计阶段），使用常规的管理手段无法实现对需求分层、分类管理，且不利于需求识别；另一方面传统的手动追踪效率低，对分散需求易疏漏，导致需求追踪到不到位。基于标签和规则的自动追踪技术通过对某一特定需求赋予诸如需求属性、需求层级、需求归属、需求版本等代表特定含义的标签，并建立各类标签的追溯规则，通过标签信息检索和分析建立需求追溯矩阵。对需求赋予标签可通过传统的分析人员分析判断后借助工具软件手动标记，也可通过计算机技术将需求数字化，使用语言模型自动对需求添加标签。追踪矩阵的建立可依据标签检索建立，也可通过语义理解模型配合建立，无论是哪种方式，均需经过分析人员确认。计算机语言、数字化技术及大语言模型的应用不是本文件的重点，本文件立足于核安全级仪控行业，根据验证对象特点，规划如何正确地建立标签及追踪规则，为实际工作提供指导。C.2标签的构成对需求赋予标签的过程即是对需求结构化的过程，标签的作用是标识需求，实现需求的分类和检索分析，标签的构成包含但不限于：需求标识、需求来源、需求属性、需求层级、需求归属、需求版本等，具体内容见表C.1。每一种标签结构根据需求可设置多级，表C.2给出了一个四级需求属性标签示例。表C.1标签的构成用于需求存储和需求追踪规则，表征是什么方面的需/表C.2四级需求属性标签示例一级标签二级标签三级标签四级标签功能需求停堆功能允许信号输入逻辑处理输出其他模式切换/硬逻辑主控室停堆远程停堆报警功能仪控报警机柜状态监测一级标签二级标签三级标签四级标签维护与试验报警电源报警工艺报警/定期试验其他/T1试验输入通道试验冗余信号不一致比较T2试验RTS逻辑试验ESFAS逻辑试验T3试验PLM闭锁试验输出到外部接口试验停堆断路器动作试验性能需求精度通道精度/模块精度/响应时间保护功能响应时间P信号响应时间停堆功能响应时间专设功能响应时间安全显示功能响应时间安全显示上行响应时间安全显示上行响应时间手动操作响应时间C.3标签追踪规则的建立原则标签追踪规则不限于如下方面考虑：——生命周期各阶段正向追踪矩阵和逆向追踪矩阵的基准文件和验证对象文件。如，概念阶段正向追踪从上游设计输入追踪到系统设计文件，追踪规则的建立依赖于“需求来源”标签；——通过低层级的“需求属性”标签，判定需求是否为追踪项。如功能需求、性能需求、接口需求、硬件需求、供电需求、接地需求、鉴定需求、设备需求等技术需求判定为追踪项；文字概述、项目管理需求、供货商责任、质保需求等非技术性需求通过其他方式响应，判定为非追踪项；——通过高层级的“需求属性”标签，确定需求的对应关系；——通过“需求层级”标签，判定需求响应的阶段。如上游设计输入基线中的系统功能性能需求为概念阶段正向追踪的基准；上游设计输入中的根据接口类型细化的需求，如“二层盘台开关触点信息”中不同的设备类型接口方式不同，有的类型存在公共端，有的类型无公共端，用于指导硬件需求设计，该类需求应作为需求阶段硬件需求正向追踪的基准；上游设计输入中的各工艺系统的FD/SAMA图、IO清单，用于指导硬件设计，该类需求应作为硬件设计阶段需求正向追踪的基准；——通过“需求归属”标签，识别软件需求、硬件需求和接口需求。如上游设计输入中的机柜布置、机柜配线需求应作为需求阶段硬件需求正向追踪的基准；系统设计中的分配给硬件的需求应作为硬件需求正向追踪的基准。C.4应用举例采用B版RPS需求规格书中的某一需求举例：ECP手动保护逻辑的设计原则<RPS-SYS-RQ-064>ECP硬逻辑应按照如下原则设计：——应采用具有高可靠性且与RPS系统计算机化部分具有多样性的设备实现；——除了ECP上的手动触发功能需在ECP硬逻辑实现之外，位于BUP盘与这些触发功能相关的复位功能也需要在ECP硬逻辑中实现。T/XXXXXXX—XXXX表C.3标签应用举例需求内容标签结构标签内容一级二级三级应采用具有高可靠性且与RPS系统计算机化部分具有多样性的设备实现需求标识RPS-SYS-RQ-064-1需求来源RPS规格书需求属性功能需求硬逻辑硬逻辑设备需求需求层级L1需求归属硬件需求需求版本B除了ECP上的手动触发功能需在ECP硬逻辑实现之外，位于BUP盘与这些触发功能相关的复位功能也需要在ECP硬逻辑中实现。需求标识RPS-SYS-RQ-064-2需求来源RPS规格书需求属性功能需求硬逻辑功能硬逻辑功能输入接口需求硬逻辑接口硬逻辑接口-主控室需求层级L1需求归属硬件需求需求版本B（资料性）危害分析技术D.1危害分析概述D.1.1危害的定义危害分析是一项系统（系统是由人员、规程、材料、工具、设备、设施和软件组成的具有不同复杂程度的综合体。）工程活动。传统意义的危害通常指的是某种致因因素（设备、材料、人员、接口、功能、软件、环境等）对生命体、环境、财产、安全、健康或社会功能等造成的潜在或实际的损害、破坏、伤害或其他不利影响。核电厂作为一个系统，在系统需求之前和安装调试阶段均需执行系统的安全分析（如PSAR、FSAR对于特定的仪控系统，在某种意义上可理解为初步系统安全分析的产物，在其生命周期内执行危害分析主要考虑仪控系统本身执行的功能，故在硬件验证和确认活动中，核安全级仪控系统的危害通常指某些内部和外部因素（功能、硬件、人员、工具、方法、运输/装卸等）不达预期可失效而影响核安全功能的执行。危害分析侧重系统故障机制，而不是验证系统实现的正确性，系统实现的正确性由可追踪性分析、文件评价及接口分析等任务保证，危害分析也无需考虑某些假定的异常事件，如设计错误，V&V未发现。D.1.2危害的分类和构成理解危害的分类和构成的目的是为了使分析人员更好的识别危害。——危害的分类第一类是系统为了实现既定的功能或因为使用了特定设备导致其存在固有的潜在危害，例如，停堆功能、系统性能、模块、设备等，这些危害实际上是被设计到所构建和使用的系统中；另一类是在设备设计、装配、测试或包装/运输等必要活动中过程引入的危害，如人员设计差错、装配工具使用不当，测试方法不当，包装材料不合格等，这些是在系统架构、实现过程中可能被引入所构建和使用的系统中危害。——危害的构成危害的构成包含三个必要且耦合的要素，缺少任一个要素，危害都不会转化为发生的事故。分别为：危害元素（构成危害的基本危险源）、触发机制（引起危害发生的触发或引发事件）、对象/威胁（易受到伤害或破坏的设备或功能）。危害控制主要是围绕构成危害的三个要素开展。表D.1给出了危害分类和危害构成的示例。表D.1危害组成要素示例危险元素触发机制对象/威胁分类稳压器压堆某一个保护通道稳压器压力采集模块故障；稳压器压力高3停堆功能退化潜在危害某一个保护通道停堆信号输出模块故障；保护系统停堆功能退化设计人员设计差错（如：某一个保护参数采集回路设计错误未得到有效验证相应保护功能退化引入的危害T/XXXXXXX—XXXX危险元素触发机制对象/威胁分类电源模块电源模块故障不影响保护功能（基于冗余供电设计）潜在危害电源模块输入丧失不影响保护功能（基于冗余供电设计）装配工具装配工具使用不当设备损坏引入的危害装配工具力矩过大设备损坏测试方法测试强制值未恢复保护功能执行错误引入的危害D.1.3危害分析的目标系统安全的理想目标是研制没有危害的系统。但是，绝对的安全是不可能的，特别是对于核电厂本身是带有固有危害的复杂系统，其存在就预示着风险。所以系统安全是一个相对概念，意味着一种可度量和可接受的危害水平。在危害分析工作中，用“可能性”和“严酷度”来表示可度量和可接受水平。表D.2、D.3、D.4分别给出了核安全级仪控系统危害的严酷度分级、可能性分级及危害度矩阵。V&V分析中对严酷度的判定是考虑了当前已有的危害应对措施而给出的值。危害分析为系统安全提供了基础，对于核安全级仪控系统，开展危害分析的过程首先是识别危害，分析危害的触发机制及对系统功能的影响，从如何减小触发机制的可能性和降低对象/威胁的严酷度两个方面给出危害控制措施，直至危害消除或达到可接受水平，通常认为危害度在3级以下（不包含3级）认为危害是可接受的。表D.2危害严酷度等级后果等级定义灾难性的系统功能全部丧失，导致设备损毁，造成严重经济损失、人员伤害或环境严重毁坏。如：反应堆误动或拒动专设安全设施误动或拒动。严重的系统主要设备运行正常，部分功能受影响，或导致部分设备损坏。如：如影响部分大气排功能主控或远程SVDU功能丧失专设支持功能拒动或误动等轻度的导致系统的性能、功能退化。如“对象/威胁”为：2/4的保护逻辑退化成2/3或单通道触发部分主控或部分远程SVDU功能丧失轻微的I导致系统功能、性能稍有退化，但对系统功能无损害。如“对象/威冗余供电线路的一路故障冗余模块的其中之一故障。部分站点与NC通讯中断部分站点维护网络中断表D.3危害可能性等级可能性等级定义频繁A在生命周期内可能频繁发生很可能B在生命周期内可能发生若干次偶然C在生命周期内可能偶尔发生很少D在生命周期内不易发生，但有可能极少E在生命周期内不易发生，可认为不会发生，注：对于核安全级仪控系统，因对设备及功能均有着高可靠性要求，且设备研制、设计过程中均进行严格的可靠性分析，我们约定系统或设备物理因素导致失效的可表D.4危害度矩阵严重性I轻微的轻度的严重的灾难性的A频繁3444B很可能2344C偶然2334D很少1233E极少1122注：有些分析方法中引入可探测度指标，从危害分析的角度即使可探危害发生了，影响就产生了，但是可探测是防止危害进一步恶化的措施，可作D.2危害分析技术D.2.1危害分析技术概述危害分析技术确定了一种特有的分析方法，是指一种具体而特定的方法论，依据一组特定的规则开展并提供特定的结果。一般而言，为完成危害分析活动可以采用不同的技术，目前可用的危害分析技术数量众多，分析人员应根据分析的对象、类型、阶段、所需资料/时间/工具、复杂性、分析技术难度等选择适当的方法，但是任何一种危害分析的方法都存在着局限性，分析人员在选择使用某一危害分析技术时，应充分了解该技术的优缺点。表D.5列出了核安全级仪控行业常用的危害分析技术，及其适用的阶段和优缺点。表D.5常用危害分析技术举例1.简单易用，仍可提供有意义的结果；.是一种条理化的分析技术；.设计初期，总结历史项目经验，收集多专业T/XXXXXXX—XXXX识别的风险，并给出系统风险提示；.可用商业软件辅助进行PHA过程。.只能用于定性分析；.在没有危害清单的情况下，收集和记录已识别的危害、或其他途径反映出的危害需要花费较长时间。2失效模式、影响及.易于理解和实施，且能够提供有意义的结果；.分析严谨；.分析结果可用于可靠性预计；.有商业化软件工具辅助FMEA分析过程；.关注单个失效模式而不是失效模式组合；.无法识别与失效模式无关的危害；.对于人为差错的分析较少；.对于外部影响和接口分析较少。3.是一个结构化的、严格的、系统性的方法；.可以在不同的设计详细程度有效地开展；.可视化的因果关系模型；.可用于概率风险评估；.可综合考虑硬件、软件、环境和人的相互作.有商业软件可用。.建模耗时，难度相对较高；.要求分析人员受过培训且有相关实践经验。4危害和或操作性分析.分析技术易学易用；.结构化、系统化和逻辑化的分析过程；.严格关注于系统中的元素和危险；.有商业软件可用。.关注于单点事件，而不考虑可能事件的组合；.分析耗时；.关注于引导词，从而可能会忽略那些与引导词无关的危害。明确的系统架构，以及不同类型的信号明确了采用什么模块采集和输出，那么在概念阶段也可以在HAD102/10-2021“2.3.2仪控系统的危害分析”一节中明确要求“核仪控系统危害分析包括，核动力厂设备失效以及由硬件失效或软件错误导致的仪控失效或误动作”，据此，其适用的方法为失效模式和影响分析(FMECA)。另外，在收集到一份包含各专业及历史数据的危害清单的情况下，使用初步危害分析（PHA）可能会取得事半功倍的分析效果。对于硬件实现（制造）阶段、测试阶段、移交阶段推荐使用HAZOP分析法，分析操作者操作意图出现偏差对系统和硬件的危害。D.2.2失效模式、影响及危害分析（FMECA）D.2.2.1失效模式、影响及危害分析（FMECA）介绍FMECA是－种评价子系统、部件或功能潜在的失效模式，导致系统处于不期望状态的分析技术。FMECA是一种更详尽的FMEA分析技术，关注危害分析，通常称为失效模式、影响及危害分析，因两种分析技术本质上是一致的，故在很多场合对其名称并未进行严格区分。FMECA往往不能识别出系统的所有危害，因为它仅限于分析单一部件失效模式，而危害可能是由多重事件导致的结果，而不仅仅由于失效模式引起。FMECA实施过程如图D.1所示。图D.1FMECA实施过程理论上讲，采用FMECA实施危害分析，可采用如下3种方法：——功能方法。功能FMECA针对功能开展分析。被分析的功能可以位于任何约定层次：系统、子系统、单元或组件。这种方法关注于系统功能目标无法实现或发生错误的方式，该方法更倾向于系统级分析；——结构方法。结构FMECA针对硬件开展分析，关注于可能的硬件失效模式。被分析的硬件可以是任何硬件约定层次：子系统、单元、组件或零部件。结构方法倾向于在部件级开展详细的分析；——混合方法。混合FMECA是结构方法和功能方法的组合。混合方法首先开展系统的功能分析，然后将关注的焦点转至硬件，特别是直接导致安全关键功能失效的硬件。当系统是由将实现的功能来定义的情况下，应采用功能方法。当硬件产品可以通过原理图、图纸或其他工程和设计数据明确定义时，应开展硬件结构方法。混合方法综合了两类特性，首先分析重要的系统功能失效，然后识别导致这些系统功能失效的特定设备失效模式。系统功能层次与结构层次的示意图，如图D.2所示。T/XXXXXXX—XXXX图D.2功能与结构模型示例D.2.2.2FMECA分析表为确保危害分析工作的结构化、系统化和一致性，应采用FMECA分析表开展危害分析。通常情况下，分析表格的具体格式并不做严格要求，可以采用矩阵式、分栏式或文本式等不同表格。至少应填饱停下述内容：——失效模式；——失效模式对系统的影响；——失效模式和（或）危害的原因；——失效模式检测方式；——失效模式的现有应对措施；——基于特定失效模式的危害度评估。表D.6列出了典型的用于危害分析的表格。表D.6失效模式及影响分析表系统：1)子系统/功能：2)功能描述失效模式失效原因真接影响系统影响检测方法现有应严酷度可能性1)系统：该栏填写被分析的系统2)子系统/功能：该栏填写被分析的子系统或功能3)阶段：该栏填写被分析系统的生命周期阶段4)对象：该栏填写被分析的功能或部件；5)功能描述：该栏填写被分析对象的功能；6)失效模式：该栏填写被分析功能或部件所有可能发生的失效模式。失效模式是一种状态，可以从众多途径获得这些信息，如历史数据、经验数据、试验数据或专家头脑风暴等。典型的故障模式为：提前工作、在规定的工作时间内不工作、在非规定的工作时间内工作或性能下降等；7)失效原因：该栏填写导致特定失效模式的所有部件级可能原因，原因包括物理失效（如自身故障）、外部应力（如环境、外部故障、人为因素等）等。不考虑部件内部逻辑，如局部电路故障，或元器件故障。8)直接影响：该栏填写所确定的失效模式的最直接的影响后果，通常是低层次的影响；9)系统影响：该栏填写特定失效模式对于系统的最终影响后果，通常是系统最高层次的影10)检测方法：该栏填写在发生失效后和导致任何严重后果前，如何检测特定的失效模式。对于某些特定部件，可能没有失效检测方法，此处填无；11)现有应对措施：该栏填写如何防止特定的失效模式发生，或者一旦发生失效如何安全地减轻其影响。12)严酷度等级：该栏填写基于某种原因的特定故障模式对系统最终影响导致的严酷度，参照本附录表D.2；13)可能性等级：该栏填写基于某种原因的特定的故障模式发生的可能性等级，参照本附录表D.3；14)危害度：该栏填写某种严酷度和可能性等级所导致的危害度等级，参照本附录表D.1。D.2.2.3FMECA应用举例本章节以包含了两个多样性子组的2/4的反应堆保护系统为例，介绍FMECA工程实施应用。概念V&V阶段，根据系统功能设计和系统架构设计绘制系统框图，确定危害分析范围，详见图D.3。图D.3概念阶段FMECA实施框图举例T/XXXXXXX—XXXX表D.7概念阶段FMECA分析表举例系统：反应堆紧急停堆系统子系统/功能：信号预处理单元级级危害度块对现场采集的信号进行调理、隔离和D2E1无D2扰无D2需求V&V阶段，根据硬件需求和硬件架构设计绘制细化的系统框图，确定危害分析范围，详见图D.4，需求阶段FMECA分析表举例详见表D.8。图D.4需求阶段FMECA实施框图举例表D.8需求阶段FMECA分析表举例系统：反应堆紧急停堆系统子系统/功能：信号预处理单元级级危害度对现场采集的模拟量信号进行调理、D2T/XXXXXXX—XXXX系统：反应堆紧急停堆系统子系统/功能：信号预处理单元级级危害度块相关保护功能逻辑表E1无D2模块受到干扰相关保护功能逻辑表无D2块对现场控制站热电阻信号进行调理、采集、转换、输出与温度对应的电流D2E1无D2扰无D2需求V&V阶段，根据硬件需求和硬件架构设计绘制细化的系统框图，确定危害分析范围，详见表D.9。表D.9设计阶段FMECA分析表举例系统：反应堆紧急停堆系统子系统/功能：信号预处理单元级级危害度系统：反应堆紧急停堆系统子系统/功能：信号预处理单元级级危害度块对现场采集的信号进行调理、隔离和D2***保护功能逻辑E1模块元器件***保护功能逻辑无冗余信号不一致比较D2模块受到干扰***保护功能逻辑无D2块对现场控制站热电阻信号进行调理、采集、转换、输出与温度对应的电流D2E1无D2扰无D2T/XXXXXXX—XXXXD.2.3初步危害分析(PHA)D.2.3.1初步危害分析(PHA)介绍初步危害分析（PreliminaryHazardAnalysis,PHA）是一项在无详细设计信息时识别危害、危害致因因素、影响并给出建议措施的安全性分析工具。PHA提供了一套识别和梳理系统危害的方法，是最常用的危害分析技术,可用来分析产品生命周期早期阶段的系统、设施、操作和功能单元、子系统、系统或集成系统。在大多数情况下，PHA可识别大多数的系统危害。并且可支持在掌握更多详细设计信息后，开展后续危害分析技术，可识别出其余的危害，完善危害原因与危害影响的关系，并进一步细化设计要求。PHA的目的是分析已识别的危害（常由初步危害清单获得），并识别在产品生命周期过程中先前阶段未发现的危害。顾名思义，PHA通常以初步的或基本的设计方案为基础，是在概念V&V阶段开始开展的。有经验的危害分析人应该有条理的将PHA技术应用到给定系统，在有限的设计信息基础上识别系统危害，当然系统安全等概念和相关知识以及对危害分析理论的基本了解是必不可少的。在安全级仪控系统项目中，开展PHA，危害分析人员应拥有三方面信息：设计相关知识、危害相关知识和初步危害清单。图D.5列出了初步危害分析（PHA）流程。图D.5PHA分析流程图D.2.3.2PHA分析表PHA是一种结构化和严谨的详细危害分析方法，适合使用分析表开展分析，PHA分析表的格式并无严格规定，但重要的是，从PHA分析表中至少应能获得以下信息：——系统危害；——危害对系统的最终影响；——危害致因因素（或潜在致因因素）；——消除或降低危害的建议——危害度的评估。表D.10列出了一个典型的PHA的分析表。表D.10PHA分析表系统：1)子系统/功能：2)1)系统：该栏填写被分析的系统；2)子系统/功能：该栏填写被分析的子系统或功能；3)阶段：该栏填写被分析系统的生命周期阶段；4)危害：该栏填写假定、分析或头脑风暴会议得出的具体危害，部分危害来源于危害清单（是一份历史数据，包含了多专业、多渠道的、多项目安全经验教训的数据）；5)原因：该栏填写该导致该危害转变为事故的致因因素，包含条件、事件和故障等；6)系统影响：该栏填写特定失效模式对于系统的最终影响后果，通常是系统最高层次的影响；7)现有应对措施：该栏填写如何防止特定的失效模式发生，或者一旦发生失效如何安全地减轻其影响。8)严酷度等级：该栏填写基于某种原因的特定故障模式对系统最终影响导致的严酷度，参照本附录表D.2；9)可能性等级：该栏填写基于某种原因的特定的故障模式发生的可能性等级，参照本附录表D.3；10)危害度：该栏填写某种严酷度和可能性等级所导致的危害度等级，参照本附录表D.1。T/XXXXXXX—XXXX（资料性）信息安全防范分析技术E.1信息安全防范分析概述E.1.1信息安全风险定义核动力厂重要仪控系统中，某些设备或部件（如：具备网络通信功能的系统或部件）可能会被恶意利用，致使系统中的数据被窃取或者系统遭受破坏，最终导致信息泄漏或其功能无法实现。这种利用系统或部件的薄弱环节对系统数据进行恶意窃取或破坏的可能性称为信息安全风险，这种信息安全风险，通过事件发生的概率与事件后果的严重程度结合起来度量。本文件所描述的风险主要为具有恶意的事件，意外事件（如自然灾害、人为失误等）未包含在内。E.1.2信息安全风险的要素理解信息安全风险要素的目的是为了使分析人员能更好的识别信息安全风险。信息安全风险基本要素有资产、威胁、脆弱性和安全措施。——资产：是信息安全防范保护的对象，是具有价值的信息和资源。在核安全级仪控系统硬件V&V分析活动中，资产通常为系统、子系统、部件。如控制机柜、维护工程师站、交换机、网关以及各类模块等；——脆弱性：通常指由于系统或部件等资产本身存在的弱点，导致其被恶意利用或破坏的特性。在核安全级仪控系统硬件V&V分析活动中，脆弱性通常指访问控制脆弱性、通信传输脆弱性、交换机系统脆弱性；——威胁：可能对系统或硬件造成损害的潜在的恶意事件；——安全措施：技术措施。风险要素的核心是资产，而资产存在脆弱性。威胁通过利用资产存在的脆弱性导致风险。风险转化成安全事件后，又会对资产的运行状态产生影响。安全措施的实施通过降低资产脆弱性被利用难易程度、抵御外部威胁，以实现对资产的保护。其关系如图E.1所示。图E.1信息安全风险要素及其关系E.1.2.1信息安全防范分析目标信息安全防范分析的目标是通过V&V的执行来保证系统的信息安全风险是处于可以接受的水平，系统的信息安全风险不可能完全消除，特别是对于核安全级仪控系统这种复杂系统，采用了大量的网络设备，本身就存在风险。在信息安全防范分中，信息安全风险等级代表一种风险的可度量和可接受程度，表E.1提供了一种信息安全风险等级的示例。表E.1一种信息安全风险等级的示例序号标识风险等级描述1很高5一旦发生将对核电厂造成很大的影响，安全系统功能异常、发电中断。2高4一旦发生将对核电厂造成较大的影响，如不直接导致发电中断，不在规定时间内恢复将导致发电中断等。33一旦发生会对核电厂造成一定的影响造，但影响面和影响程度不大，如无法完成维护任务，导致核电厂无法恢复到可进行发电的状态。4低2一旦发生造成的影响程度较低，一般仅限于安全级仪控系统内部，通过一定手段很快能解决。5很低1一旦