基于非安全级分散控制系统软件V&V浅析

周长荣

摘 要：针对重大专项消化吸收课题数字化核电站控制系统平台原理样机研制项目过程总结，结合软件验证和确认的基本要素，旨在概述基于软件的分散控制系统工程应用开发阶段的质量管理策略。对核电站在出厂前控制软件开发的质量提供基本的活动支持，从而提高软件生命周期内的质量，以满足系统开发需求。

关键词：DCIS 软件 V&V 质量控制 管理

中图分类号：HL362.1 文献标识码：A 文章编号：1007-3973（2013）009-122-03

1 引言

随着科技的发展，数字化仪控系统设备在核电领域的应用范围逐渐扩大。越来越多的仪控设备开发涉及硬件的开发、软件的开发及软/硬件的集成。为满足国内外法规/标准的要求，软件及基于软件的系统均采用验证与确认（Verification and Validation，V&V）的策略以确保开发过程受控、检验及证明产品的性能、保证相应的需求已正确实现以保证软件或系统（基于软件）的置信度。

V&V是软件开发过程的一部分，它包括一系列系统化的评审与测试活动，其贯穿于软件开发或基于软件的系统开发生命周期全过程。

2 软件V&V概述

因为软件有一些特有的方面需要被考虑，不同于以往设备（硬件）的质量保证（QA）及质量控制（QC），在软件开发时往往关注软件V&V，确切地说，软件V&V是系统V&V的一部分。系统一般由硬件作支撑运行，硬件部分与生产、制造等相关特有活动，通常由QA、QC确保其产品质量。对于系统分配至硬件的需求及设计、涉及与软件相关的硬件产品、硬件设计的过程文件、活动记录文件等，软件及系统V&V的技术方法均适用。

V&V过程需要文件控制、需求管理、配置管理等辅助活动支持，用以提高V&V的执行效率。V&V过程涉及与软件开发一样的控制与管理问题。其结果同样可用于第三方或公司内部专业质保人员评审。

2.1 V&V与QA的基本关系

V&V是质量保证（QA）的一部分。V&V既注重产品质量，同样也注重产品开发过程。V&V的“验证”关注过程的实施。这点基本与QA思路一致。

当讨论核电站基于软件的数字系统时，V&V与QA的关系可能被混淆。在上世纪末，软件QA计划一般遵循IEEE Std 730，其将软件分类为关键软件和非关键软件。软件QA包含软件开发生命周期、编码标准、管理控制与V&V。为澄清术语及应用，EPRI的报告重新定义了核电QA与软件QA的概念：

（1）核电QA——10 CFR 50附录B中规定安全相关核电系统必须执行的QA活动。

（2）软件QA——IEEE 730描述的对于关键软件和非关键软件的QA活动。

所以，V&V可以被认为是QA的活动子集。若一套数字控制或保护系统在核电QA大纲下执行，那么必然包含完整的V&V活动。反之，V&V的执行并不意味着执行了核电QA。V&V适用于确保基于软件的数字控制系统的质量。

QA应包含软件V&V计划及相应等级的V&V活动需求。随着系统工程的发展，IEEE Std. 1012- 2004逐渐取代软件QA的概念，更注重对过程的管理、执行与产品的质量控制。4个软件完整度等级的定义量化了软件关键的数量，有效地协助项目组织对于资源的合理分配，以达到全面、有效地保证软件质量。

项目团队应正式、清晰地记录V&V活动数据，供项目QA专业执行人员审查。

2.2 V&V与CM的基本关系

配置管理（CM）必须满足项目QA计划的要求。CM必须确保：

（1）项目开发期间，每一个文档版本的使用是正确的。

（2）在测试执行期间，硬件、软件、或系统参数的使用是正确的。

CM与V&V是并行的活动。CM的结果可用于V&V评审活动的输入。若CM要求严格地执行，V&V在某些方面的活动可能显得低效。当项目组织使用螺旋型生命周期模型（迭代开发）时，CM是尤其重要的。

项目开发组织必须谨慎地控制涉及软件功能执行的元素，保持其一致性，从而确保V&V的结果可以支持现行的配置。在开发期间，如果不能确定被安装的配置是否与已存在的配置数据一致，即使这个系统被成功地开发（伴随相适应的V&V活动），那么其意义也是毫无价值的。

3 V&V过程

控制系统工程应用开发过程中的V&V可遵循IEEE Std. 1012-2004标准或国际行业协会各报告中的指导内容开展相关质量控制与管理活动。

控制系统开发生命周期及相关V&V过程与活动，如图1所示。

图1 数字化控制系统开发过程V模型

通常，V&V输出由V&V团队生成。对于安全级系统，V&V团队必须与设计团队相互独立，保持充分的独立性，确保V&V流程不受设计流程中的进度和资源的影响。本项目中涉及的系统属于非安全系统，因此保持项目组内部的V&V技术的独立性即可，来自设计团队的工程师可以进入V&V团队执行验证团队的任务，但注意执行此任务的产品项必须不是本人开发的。基于不同的完整度等级，验证任务也可以由开发团队来生成，但这个过程及结果应由V&V团队来审查或见证。

为检查软件生命周期内所定义的阶段之间传递信息的正确性，应通过验证来控制、保证。验证过程覆盖了从系统需求规格书阶段到设计、运行调试、维护和修改阶段的全过程。

每个阶段验证的目的是为了确认本阶段开发的产品（输出）正确地实施了本阶段的输入要求。每个阶段的验证过程包括对要求验证的输入文件、编码和数据的审查，产生验证结果文件。

确认的目的是为了证明软件和硬件集成的系统正确地执行了系统需求规格书定义的功能。要求通过集成的系统全面测试来判定该系统是否能完全地、正确地、一致地和精确地执行所有特定的功能。在确认过程中，该系统与其他系统及用户接口的完整性、正确性、一致性和精确性得到评估。确认必须评估关键性能参数、重要的功能和其他的系统要求已满足，必须证明控制系统完成其需求规格书的要求。

确认是基于系统需求规格书的基础上。通常确认活动通过FTs（工厂试验），FATs（工厂验收试验）和SATs（现场验收试验）实施。

4 过程管理

4.1 组织需求

根据RG 1.168-2004，“用于核电站安全系统的数字计算机项目的验证、确认、审核、和审计”，IV&V（独立验证与确认）活动对于评审人员有特定的独立等级需求。IV&V评审的深度基于安全等级分类。

对于安全级系统而言，NRC与NNSA均要求验证人员应该不同于那些执行初始设计的人员，应该由负责V&V的组织为V&V的充分性承担责任。负责V&V的人员必须与负责设计的人员相互独立。必须要有充分的独立性，以确保V&V流程不受设计流程中的进度和资源的影响。对于非安全级的控制系统项目而言，V&V活动的深度与独立性可适当降低要求，但必须满足最基本的技术独立需求。

V&V活动期间，管理控制关注以下几个方面：

（1）文件/软件/测试项的传递；（2）文件/测试事件报告和日志；（3）文件/测试总结报告；（4）V&V状态管理；（5）验证工程师所执行的活动内容；（6）可审查的配置管理执行。

4.2 传递控制

V&V与开发过程在许多项目的执行中存在一定的瓶颈。尤其是双方在过程产物传递的控制过程。无论是设计中间产品提交给V&V团队，还是V&V团队将评审结果反馈至开发小组，其中设计团队和V&V团队的关系在第3章进行了描述。文件和项目文档的维护是设计和V&V流程中的一个关键元素。在设计团队和V&V团队之间传递的可验证材料、交流信息可通过项目文控工程师进行传递。该工程师必须具备良好的CM执行意识，确认工程输出符合过程程序要求，保留当前和过往历史版本，并且保留发布的记录和已验证输出的记录。

4.3 问题跟踪

在执行V&V任务期间检测到的任何差异都必须进行记录。产品相关负责人需控制每一份差异报告，并且在需要时通知技术经理，如未及时汇报，差异报告至少应包含在V&V阶段总结报告中。

所有的差异经分析后会引申出一定的问题，而问题跟踪确保V&V活动中发现的问题得以被记录、追踪并最终落实到具体的人员解决。典型的需要记录的信息包括：

（1）问题发生的时间；（2）问题发生的位置；（3）问题发生前系统的状态；（4）发生问题的证据；（5）导致问题发生的条件/输入；（6）描述系统理想状态的运行情况，以及相关的需求；（7）解决问题的优先级。

4.4 软件相关的信息安全控制与管理

信息安全是保证项目产品质量与V&V活动正确展开的重要环节，其活动主要包括防止外部人员恶意窃取或篡改软件产品、资料或验证记录，以及内部人员非故意的信息泄漏、意外修改。

5 控制及执行策略

本章节提供了软件质量控制及执行V&V任务时要遵循的通用技术和方法。单独技术或集成技术可用于执行一项验证/确认任务，以控制软件及其产品的质量。

5.1 清单核查

清单用于协助产品的验证和确认。清单中的内容提供了执行验证的工程师在评审过程中应考虑到的基本事项集，可应用于各阶段、各种的设计产品。核查清单提供了一种可量化的评审方式。

5.2 检查/分析

检查/分析包含了研究被验证的产品。需要确认设计的某些方面，可以是正式记录的评估和计算，但不限于正式证明、图表分析方法和相关技术。分析包括完整性和正确性的评估。分析应重点关注以下几个方面：

（1）危害和风险分析；（2）可跟踪性分析；（3）数据分析；（4）COTS和质量鉴定审核前的产品分析；（5）V&V回归（变更）分析；（6）工具分析。这些方法适用于整个系统/软件开发的生命周期。

5.3 测试策略

测试适用于开发的各个方面。测试由系统或设备在具体条件下的操作、结果记录、和基于结果做出正确性评价组成。测试应该自下而上地执行，低等级目标测试的执行先于高等级组合。

测试可以分为两类：功能测试和结构测试。功能测试（黑盒测试）用于确定模块或系统的执行符合具体的需求。功能测试的测试用例直接由需求规范驱动，并且以模块或系统输入和输出为基础。该方法对于检查模块接口非常有用。结构测试（白盒测试）评估软件的内部结构。结构测试应该通过分支和路径测试的结合来完成。分支测试涉及生成测试用例，以提供充分的可信度，认为模块中所有的分支都可以到达。在路径测试中，开发测试用例以提供充分的可信度，认为所有的路径（所有模块中可行的分支结合）都被测试到。功能测试和结构测试的结合确保应用中没有意想不到的功能存在。

对于待执行的各测试，应提供测试规范、测试程序、测试结果报告、和任何差异报告。测试设备必须控制和记录。测试工具必须校准、控制、和记录。

测试方法采用低层级到高层级的方案。但是，为了确认合适的集成或低等级实体组合（元素、处理器模块、或通道）的执行功能，有必要采取重叠的功能测试。由于硬件组装，软件设计和与硬件集成，应执行一系列硬件和软件测试。现场验收测试（SAT）作为安装流程的一部分执行。现场验收测试在执行以完成安全系统开发的V&V范围之外。主要测试活动有：

（1）机柜硬件测试；（2）单元软件测试；（3）软件集成测试；（4）系统集成测试；（5）验收测试；（6）设备质量鉴定测试；（7）回归测试。

6 记录与度量

在控制系统开发过程的质量控制和管理过程中，记录的控制和管理将是重要的一环。在法规和标准中，对于记录的控制和管理有着强制的要求。10 CFR 50附录A中要求在核电厂的整个生命周期期间，安全重要系统和设备的设计、制造、安装的记录必须由核电厂执照持有者进行控制和管理。同时ASME NQA-1要求，记录必须提供描述满足质量需求的相关活动的证明文件。在记录的控制和管理过程中，考虑将图纸、技术规格书，采购文件，测试设备检定程序和检定报告，不符合项报告和纠正措施报告，审查、检查、监查、监督工作执行报告，试验和材料分析的结果都将作为记录的一部分。

6.1 验证与确认记录

质量保证记录中包括了验证和确认过程中产生的验证记录和测试记录，并且在项目的开展过程中合理地控制和管理这些记录。根据消化吸收原理样机研制项目实践经验，对于生命周期的不同阶段，验证的记录可以采用审查清单的方式，选择合适的审查内容，编制不同的审查记录清单。

而测试的记录则重点要求测试配置记录，测试执行记录，测试数据记录，不符合项记录与纠正措施记录的完整性、一致性。以确保在某些分析活动下，可以再次复现测试活动。

6.2 度量探索

度量活动适用于整个V&V流程中，以帮助分析、预测、确定有疑问的倾向。这些信息将尽快反馈到设计和V&V流程中，以纠正管理缺陷和减少返工。

7 结束语

本文对基于重大专项消化吸收课题数字化核电站控制系统原理样机研制项目V&V活动进行概述，其过程满足国内外法律、法规要求，并适用于核电站其它非安全相关的仪控子系统生命周期内软件的V&V活动。

参考文献：

[1] 龚益.核电厂安全系统软件验证和确认方法探索[J].低压电器，2004（5）：27.

[2] RG 1.153-2011：Criteria for Use of Computers in Safety Systems of Nuclear Power Plants.

[3] TR-103291-CD，1998：Handbook for Verification and Validation of Digital Systems.

[4] IEEE Std 730-1998：Software Quality Assurance Plans.

[5] ASME NQA-1-2004，Quality Assurance Requirements for Nuclear Facility Applications.

[6] IEEE Std 1012-2004：Standard for Software Verification and Validation.

[7] IEEE Std 828-1998：Software Configuration Management Plan.

[8] IAEA TRS No.384，1999：Verification and Validation of Software Related to Nuclear Power Plant Instrumentation and Control.

[9] RG 1.168-2004：Verification， Validation， Reviews， and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants.

[10] SEI-CM-13-1.1，1988，Introduction to Software Verification and Validation.

[11] HAD 106-2004：核电厂基于计算机的安全重要系统软件.

[12] IEEE Std 1028-2008：Standard for Software Reviews and Audits.