保护系统1E级软件独立验证实施管理

魏 鹏 黄平儿 吴 俊

（海南核电有限公司 海南昌江）

随着数字化仪控技术的快速发展，在我国新建电厂中，反应堆保护系统及事故后监视等安全重要功能均已采用数字化仪控系统（以下简称DCS）来实现。DCS系统的可靠性取决于设备硬件和软件两方面。为保证安全性和可靠性，数字化保护系统除必须通过通常的质量鉴定程序确认其硬件质量外，还必须对执行安全功能的1E软件遵循国家的各项核安全法规、导则及标准，进行独立验证与确认活动（即Independent Verification&Validation）。

1E软件独立验证和确认是一种综合性的软件质量保证方法。验证（verification）是通过检查和提供客观证据，证实规定的需求已经得到满足；确认（validation）用于证实特定预期用途的需求是否得到满足。验证侧重于过程性检查测试，即白盒测试，确保前一个活动输出的产品合格地成为后一个活动的输入；确认侧重于对结果的检查测试，保证系统和软件所做的符合需求规格说明书和合同的规定，从而满足用户的预期，即黑盒测试。两者结合起来形成一个套IV&V方法论，它包括了对软件产品和过程的分析、评价、评审、审查、评估和测试等活动，集中了许多技术和方法，覆盖了软件生存周期过程的所有基本过程，具有较高的独立性和可操作性。

对于每项具体的IV&V活动，需结合相应设计、测试、分析等技术领域的通用标准并将其与核安全领域的法规、导则、标准的特定要求相结合，制定出符合要求并且可行的具体执行方法。在IV&V活动的执行过程中，应严格遵循法规及标准的要求，并将该要求贯彻落实到每项具体的IV&V行动中。

一、海南项目IV&V实施概况

海南项目1E IV&V活动，根据核安全法规HAF 102-2004中的要求，基于核安全导则HAD102/16-2004中的验证与确认的基本流程及相应的要求，并参考IEEE Std 1012-1998软件V&V、IEEE Std 1028-1997软件审查，Nureg 1.168-2004用于核电厂安全级系统数字化计算机软件验证、确认、审查、审计导则等，编制SVVP（软件验证确认大纲）。

海南项目RPS系统平台设备Triconex V10已经过美国核管会、中国核安全局验证、审查，取得核级鉴定证明，故海南项目软件IV&V活动仅针对应用软件，不包括操作系统、硬件、平台软件。本文仅针对在出厂测试阶段的IV&V活动，其他获取、供应、开发、运作、维护、组织、文档编制、配置管理、质量保证、审核等软件生命周期阶段的IV&V活动和任务，不在本文论述范围内。

1.IV&V团队组织和责任

根据法规要求、海南项目合同约定，并基于供货商项目管理架构，海南项目由设计团队、质保团队、IV&V团队等共同开展IV&V活动管理工作。为保证海南项目IV&V活动的独立性，在1E应用软件的开发过程中，由满足技术、管理和财务独立的团队组成IV&V测试团队。

IV&V测试团队负责实施独立设计文件审查、软件设计验证、需求跟踪、开发和审查IV&V文件，准备和执行IV&V分析任务，并负责IV&V测试执行。确保应用软件开发每个阶段的输出满足上一阶段的约束，确保每个阶段的输出满足用户需求和法规要求，确保最终产品满足用户需求。为保证独立性，IV&V测试团队根据IV&V活动自身的情况来制定计划，而不受来自软件设计团队的任何限定、财务约束、直接或间接的压力。

对于项目工程设计团队，在整个核级应用软件开发生命周期中，仅负责依据设计输入，完成项目软件和硬件设计，系统集成发货等工作，完全独立于IV&V活动。

在整个IV&V活动中，项目QA团队依据项目的质保大纲和软件IV&V大纲监督和检查IV&V活动，审查测试规程确保符合项目质保程序，执行独立核查和监督，管理IV&V活动中的不符合项，审查和关闭测试活动中的异常报告（Anomaly Report）。

2.软件完整性

IEEE 1012-1998标准对保护系统软件完整性Software Integrity Level（ SIL）建立了分类模型，在 IEC 61508（ 2.18）和IEC 61513（2.20）中也援引此模型。完整性模型将1E软件错误的后果分为灾难性的、严重性的、微小的、可以忽略的，并依据导致该错误运行状态的概率，将应用软件归为4类，根据Nureg 1.168-2004导则建议，将 RTS（反应堆停堆功能）和 ESFAS（专设安全功能）归为SIL-4级。不管其是否执行安全功能，依照Nureg 1.152-2006（2.3）导则要求，任何1E级计算机系统的软件模块都将被归为SIL-4级。

故保护系统IV&V过程中任何微小的、可以忽略的，即便不经常发生的软件错误都必须经过验证和确认。

3.IV&V活动工具、技术、方法等资源管理

为了保证IV&V活动过程的高效性、准确性、独立性，并保证活动符合发挥、导则、标准要求，IV&V引入了先进的软件工具、技术、测试方法，实践中采取了一系列的措施，以支持软件的验证和确认过程。各阶段使用的工具、技术、方法分别介绍如下。

需求跟踪环节，供货商采用IBM Rational DOORS软件，将需求以具体的条目形式保存，通过创建RTM（Requirement Traceability Matrix）跟踪需求矩阵，整个需求分为从系统需求SyRS（系统需求规格书）、子系统设计需求、软件需求SRS（软件需求规格书）和软件设计需求SDD等几个等级，在每一个等级中，所有的需求都以条目形式管理。每个条目都具有相应的创建、修订和变更历史，并维持了与上下级需求之间的链接关系。RTM跟踪器中中每一条独立的设计需求。并据此生成每个子系统的SDD（软件设计描述），以及单独的测试规程文件TP。V&V环节通过跟踪RTM文件，来证明应用软件100%的依照设计需求来实施，从上下游跟踪需求也证明了其可追溯性，并为需求追溯分析提供支持。

软件部件测试（Software component test）、集成测试（Software Integration test）环节的工具主要包括：TriStation 1131 4.7.0，Triconex Emulator 1.1.0，Triconex 动态数据交换（ DDE）客户端4.7.0，TS1131仿真测试驱动，供货商开发的SCT、SIT自动测试脚本，微软Excel等工具；验收测试环节IV&V活动包括一些经过验证的供货商内部软件、CAPE商用货架测试软件和硬件，如利用商用计算机仿真电站传感器、执行机构输入输出，利用Tristation IVU工具检查Triconex硬件之间的连接，利用经过验证的VP-link仿真工具模拟现场设备输入、提供GUI图形接口画面，测试人员可以手动改变现场设备的输入输出值。其他IV&V工具还包括：UCM文档管理系统、SVN版本管理软件、eroom文档交换系统、其他办公软件和工具。

二、IV&V开发生命周期

为了确保系统的软件安全可靠，针对软件的V&V必须贯穿软件的生存周期，以验证各项需求被满足且未引入新的风险。从软件最初的需求获取到最终的运行、维护，V&V均需全程参与。并且涵盖软件、硬件和外部运行环境综合进行考虑。在当前阶段，V&V更多是从软件角度来考虑，但由于软件的可靠性等与硬件及外部运行环境密不可分，为此，目前的趋势越来越多的将三者一并考虑。在本文中描述的内容是以软件为主，同时考虑了相关的硬件及外部运行环境。

1.管理活动

IV&V管理活动也属于IV&V开发流程中的一个环节。这个活动将持续地评审V&V工作，应用软件开发是一个循环和交互的过程，管理活动基于更新的项目进度和开发状态对SVVP进行必要的修订，并与开发方以及诸如质量保证、配置管理、评审和审核等其他支持过程协调V&V结果。根据IEEE 1012-1998标准要求SVVP软件验证确认大纲编制作为SIL-4级的任务在IV&V管理活动中进行。SVVP作为整个IV&V活动开始后的第一项工作，其他管理工作将伴随整个IV&V开发生命周期过程。

2.软件IV&V开发流程

根据IEEE 1012-1998标准，软件IV&V开发过程，包括需求分析、设计、代码编制、集成、测试、安装、验收测试活动；这些活动被划分为6个阶段：概念V&V、需求V&V、设计V&V、实施V&V、测试V&V、安装和检验V&V。

其中概念V&V活动涉及系统体系结构设计和系统需求分析，概念V&V的目标是验证系统需求的分配，确认选定的解决方案，确保没有采纳错误的解决方案。安装和检验V&V活动是指在目标环境下对软件产品的安装、以及需方对软件产品的验收评审和测试。安装和检验V&V活动涉及软件安装和软件验收支持。V&V的目标是验证和确认在目标环境下软件安装的正确性。

基于SVVP大纲，由于概念V&V在参考机组中已完成，安装检查V&V由电站运营单位自主实施，所以不在IV&V开发流程内。

根据IV&V流程，每个阶段都需要完成相应的确认和验证工作，包括关键性、安全性、危害、风险和追溯性（Criticality/Hazard/Risk/Interface/Traceability）分析，并完成相应阶段的IV&V报告。

①关键性分析（criticality analysis）。针对系统失效、系统老化或未能满足软件要求或系统目标所造成影响的严重性而进行的软件特性（例如，安全性、安全保密性、复杂性和性能）的结构化评估。

②危险（hazard analysis）。危险性分析是指在人身伤害和健康、财产、环境的损害等方面的潜在伤害来源或具有潜在伤害的情形。在概念阶段需通过故障树等多种方法来确定系统潜在的危险源，并评估其严重性、概率等。在其后的每个阶段的危险分析活动中，均需对每项危险源的后继处理进行分析，以确定该危险已被系统明确的定义了相应的需求项来缓解或消除，并且该需求被正确地设计和实现；同时还需确保在软件的研发活动过程中没有引入新的危险。

③风险（risk analysis）。特定危险事件的频率或概率与后果的综合。

④接口分析（interface analysis）。当信息横穿边界时（例如硬件到软件、软件到软件、软件到用户），总有丢失一些信息或改变信息内容的可能性。接口分析的目的是在接口需求的正确的、一致的、完整的和精确的描述方面去评价具体的软件可交付产品（ 例如，需求、设计、代码）。

⑤可追溯性分析（traceability analysis）。可追踪性是标识初始需求与最后所得到的系统特征之间关系的能力，它提供了把一个要素与另一个要素联系起来的线索。在需求、设计和实现活动中，要进行可追踪性分析。

（1）需求V&V。软件需求V&V活动构成设计和验证活动的基础，用于整个软件生命周期，也同样是设计、实施环节的基础。需求V&V活动确定了功能性和性能需求、软件外部接口、合格性需求、安全性和安全保密性需求、人因工程、数据定义、软件用户文档、安装和验收需求、用户操作和执行需求、用户维护需求。软件需求V&V活动的目标是确保软件需求的完整性、正确性、一致性、清晰、可追溯性和可测性。软件需求跟踪文件的主要目的是，清除的定义系统谁就和开发过程的对象和需求，并作为作为设计V&V环节的基础。

根据IEEE 1012-1998标准的分级，SIL-4级系统的需求V&V活动最低限度需要完成以下任务：可追踪性分析；软件需求评价；接口分析；关键性分析；系统V&V测试计划生成和验证；验收V&V测试计划生成和验证；配置管理评估；危险分析；风险分析。

以上任务将产生如下输出文件：系统V&V测试大纲文件、验收V&V测试大纲文件、任务报告-软件配置管理评估报告，需求V&V环节的关键性、安全性、危害、风险（Criticality/Hazard/Risk/Interface）分析报告文件，任务报告-追溯性分析报告，任务报告-本阶段需求评估报告，以及各任务的异常项报告（ Anomaly Report）。本环节结束后，将完成需求V&V活动总结报告。

（2）设计V&V。在1E软件设计IV&V活动中，软件需求被转化为系统体系结构、信息流、处理步骤、每个软件部件的结构和详细设计以及其他需要实施方面。设计包括数据库和接口（软件外部、软件部件间、软件单元间）。设计V&V活动涉及软件体系结构设计和软件详细设计。V&V的目标是验证设计输出文件可理解、清晰、正确、准确、一致、完整、可测试、可追溯的转化了来自于上一环节的设计输入，而且没有引入非预期的特征。

根据IEEE 1012-1998标准的分级，SIL-4级系统的设计V&V活动最低限度需要完成以下任务：可追踪性分析；软件设计评价；接口分析；关键性分析；部件V&V测试计划生成和验证；集成V&V测试计划生成和验证；V&V测试设计生成和验证；危险分析；风险分析。

以上任务将产生如下输出文件：更新SVVP文件、部件级V&V测试大纲、集成V&V测试大纲、测试规格书（包含测试规程和用例）、任务报告-软件设计评估报告，设计V&V环节的关键性、安全性、危害、风险（ Criticality/Hazard/Risk/Interface）分析报告文件，任务报告-追溯性分析报告，任务报告-本环节需求评估报告，以及各任务的异常项报告（Anomaly Report）。本环节结束后，将完成设计V&V活动总结报告。

（3）实施V&V。实施V&V活动将设计转化为代码、数据库结构和相关的可执行机器表示。实施阶段文件的客观性促进了有效的生产、测试、使用、传递和转化到不同的环境，为后续修改、设计文件的追踪性提供便利。实施V&V活动涉及软件编码和测试，通过确认软件的源代码、数据结构等，进行部件级测试和软件集成测试SIT，验证整个设计过程，属于白盒测试。实施V&V的目标是验证和确认这些转化是正确、准确和完备的，回答了以下问题：①软件实施是否满足设计文件；②软件实施是否符合相关设计标准；③软件实施是否符合相关文档标准；④软件实施是否满足用户的生产、测试、使用、传递等需求。

根据IEEE 1012-1998标准的分级，SIL-4级系统的实施V&V活动最低限度需要完成以下任务：可追踪性分析；源代码和源代码文档评价；接口分析；关键性分析；V&V测试用例生成和验证；V&V测试规程生成和验证；部件V&V测试执行和验证；危险分析；风险分析。

以上任务将产生如下输出文件：更新SVVP文件、部件级测试规格书/测试规程/用例、集成测试规格书/测试规程/用例、系统&验收测试规格书/测试规程/测试用例，执行的部件级测试规程和测试用例，部件级别测试结果，实施V&V环节的关键性、安全性、危害、风险（Criticality/Hazard/Risk/Interface）分析报告文件，任务报告-源代码和源代码文件评估报告，任务报告-本环节追溯性分析报告，以及各任务的异常项报告（Anomaly Report）。本环节结束后，将完成实施V&V活动总结报告。

（4）测试V&V。通过以上需求、设计、实施环节的IV&V活动，能够保证软件在一定程度上适当、准确的转化了设计需求。测试IV&V活动用来确定保护系统软件是否满足其逻辑功能、运行、系统级性能、外部接口（包括第三方及I/A）、内部接口、可测性等设计指标；系统确认通过在目标软件、硬件设备上测试，评估了软件在实际运行环境下的性能。

测试V&V活动覆盖软件逻辑功能测试、软件集成、软件合格性测试、系统集成和系统合格性测试。测试通过驱动系统输入确认输出来验证，属于黑盒测试，V&V的目标是确保通过执行集成测试、系统测试和验收测试使软件需求和分配给软件的系统需求得到满足。

根据IEEE 1012-1998标准的分级，SIL-4级系统V&V工作应生成自己的V&V软件和系统测试产品（例如，计划、设计、用例、规程），执行并记录自己的测试，并对照软件需求验证开发过程的测试计划、设计、用例、规程和结果。测试V&V活动最低限度需要完成以下任务：可追踪性分析；验收V&V测试规程生成和验证；集成V&V测试执行和验证；系统V&V测试执行和验证；验收V&V测试执行和验证；危险分析；风险分析。

以上任务将产生如下输出文件：更新SVVP文件、集成测试规格书/测试规程/用例/任务报告-测试结果、验收测试规格书/测试规程/测试用例，执行的系统测试规程和用例/任务报告-测试结果，执行验收测试规程/测试用例/任务报告-测试结果，测试V&V环节的危害、风险（Hazard/Risk）分析报告文件，任务报告-本环节追溯性分析报告，以及各任务的异常项报告（Anomaly Report）。本环节结束后，将完成测试V&V活动总结报告。并完成IV&V活动最终报告。

（5）其他任务。根据标准中列出的可选任务，海南项目1E反应堆保护系统软件还进行了安全评价（Security Assessment），用来评估系统是否安全可控，保证系统的硬件、软件的部件不会被未授权使用、修改、披露，并验证用户权限管理。验证系统安全相关对象的存储、归档是否受控等。本任务在各阶段都需执行，并形成相应分析报告。

三、IV&V 过程管理

在开展IV&V开发各生命周期各环节活动中，都有可能出现各种问题，海南项目主要出现的问题有：AR、任务重新执行、TRB审查。

关于AR异常项（Anomaly Reports），每个环节出现的AR将都会被统计在相应环节的IV&V总结报告中。但在测试阶段，发现有SRS的AR需要处理，则仅需在测试环节总结报告中描述即可，无需返回修前几个阶段的总结报告。对于AR解决，依据Nureg-1.168-2004（2.4）的推荐，采用回归测试作为处理AR、复测的手段。如果测试过程中发现与测试规程之间存在差异或偏离，也将需生成AR，在经过充分的分析后，将需要修改测试步骤或者验收标准，在修改前，须要经过AR处理和确认过程，包括测试文件确认、受影响文件的独立审查等工作。在执行过程中，IV&V团队辨识软件AR和工程设计团队处理软件AR、IV&V测试AR均需独立进行。在完成复测后，测试结果将作为AR报告的一部分，完成

关于任务确认工作，在IV&V活动中，由于本环节的输入变更，应基于对应用质量和软件完整性的影响两方面的评估，来决定V&V任务重复执行的范围。如果输入变更仅限于软件需求版本、性能准则，此时评估仅影响软件功能，需要复测，为确认修改没有引入其他非预期性副作用。但如果修改涉及到计算机的基本性能要求，比如程序执行时间，通讯负荷、自诊断路线，评估工作应包含所有受影响的安全级计算机。

关于测试文件审查工作，根据Nureg-1.168-2004导则建议，海南项目IV&V活动建立了Test Review Board（TRB）机构，TRB机构由项目经理、质保工程师、IV&V测试工程师等组成。所有项目测试文件的重大修改都需要经过TRB审批。包括测试大纲、规程、用例、分析报告、测试记录、测试报告等文件。

四、结论

讨论了IV&V的方法论及其在对数字化核安全级仪控系统开展软件验证与确认过程中的具体应用，同时也介绍了为确保该活动的有效开展而制定或建立的验证与确认工作流程、技术规范体系以及V&V工作平台等，这些不但推动了验证与确认工作的开展，还可使得验证与确认的工作更规范、更可信。这套方法及相应的平台将有助于在产品功能、性能、安全性及可靠性等指标的符合性方面给出客观、可信的评价。

针对数字化核安全级仪控系统的验证与确认的过程及技术、平台等也可应用到诸如铁路信号、航空航天、军工等其他多个安全领域。