目录
DCS控制模块第三方监理测评实施方案
序号 | 阶段 | 时间 | 工作内容 | 参与者 |
| 启动 | 第1、2周 | 项目启动会、 测评计划、测评方案、 周例会汇报机制、培训交流、 阶段交付件与验收点、问题处理流程 | 测评团队 |
| 阶段测评 | 第3至12周 | 流程辅导、培训交流、 监控、现场见证、 交付件评审、 阶段验收、阶段测评 | 测评团队 |
| 综合测评 | 第13、14周 | 综合验收、综合测评、 测评报告编写、沟通与确认、 交付件整理 | 测评团队 |
| 测评移交 | 第15周 | 测评报告甲方评审、 测评移交、 甲方确认 | 甲方、测评团队 |
DCS系统功能分层,分散控制集中管理,包括分散控制装置、通信系统、集中操作和管理装置,DCS系统结构:
集散系统三大块:
- 分散过程控制装置对应现场控制级和过程控制装置级,
- 集中操作和管理系统对应于操作管理级、优化调度管理级。
- 通讯系统完成各层之间的通信。
这次任务主要测试验收控制级系统模块:
包括信息系统、控制级、现场级设备接口,核心控制级模块,但通过信息系统入口,同时需要与底层设备通讯。
通过信息系统或者测试工具测试控制系统,测试分三块:
信息系统相关展示和操作层面达标,信息系统与控制系统通讯接口正常; 控制系统本身的功能、性能、可靠性达标、故障隔离、异常处理与告警上报,控制模块与底层设备通讯达标:传感器仪表数据上传接收达标、下达控制指令达标。
测评活动主要有流程辅导、需求设计交流与评审、测试调试方案评审,设计图纸抽查、测试点抽样检查、现场监察,验收测试,输出测评方案与过程文档,测评报告分析、以及PDCA改进建议等。
依据《HAF0208-1988核电厂安全有关仪表和控制系统》从产品设计角度我们理解总结主要的关注点,作为需求设计与测试方案、测评范围的重要依据:
核电厂中对系统和参数的监测及控制起重要作用的系统称为仪表和控制系统,
它们分为两类:信息系统和控制系统。这两类系统都根据测量设备提供的信号进行工作。
信息系统的功能是监测电厂参数和系统,在正常运行、预计运行事件和事故工况下,它 们显示和报警与这些参数和系统的状态有关的信息,并记录所选择数据作短期或长期储存。
控制系统使电厂参数维持在运行工况规定的限值内,或改变电厂参数使其恢复到规定限 值内。通过自动或手动地切换泵、开启或关闭阀门、移动控制棒等手段,可用来改变电厂设备的状态。核安全因素:
核安全系统 | 安全因素 | 说明 |
安全系统总则 | 性能 | 仪表和控制系统的性能要求必须根据核电厂的安全要求和安全分析加以规定。对于每一假设始发事件和(或)有关的运行工况,必须确定所需仪表和控制系统的作用,还必须确定例如所测变量的范围、精确度、响应时间以及输出信号电平等性能要求。在安全有关仪表和控制系统设计中必须考虑动力源特性的瞬态偏差和正常偏差例如电压波动、频率偏差、仪表 压缩空气的气压偏差等的影响,使其达到为保证仪表和控制系统足以实现它们的安全功能所必需的程度。 |
环境条件 | 必须规定仪表和控制系统在运行工况和事故工况下所要经受的坏境条件和在该环境条件下预计使用的时间。必须考虑下列环境条件:最高和最低温度、压力、湿度、电离辐射、电•气干扰、振动、腐蚀、疲劳和应力。 | |
可用率 | 每个系统需要的可用率必须在设计基准中加以规定。对安全越重要的仪表和控制系统,它的可用率应该越高,规定所需可用率的一种方法是对3每一等级规定一个用数字表示的不可用率数值。另一种方法是通过在工程经验的基础上对某些典型系统的可用率进行判断,将它们确定为各等级,然后确定典型的排列次序,以此对各种等级规定分级 的、非数值形式的可用性要求。然后将相同等级的其他各系统与典型系统进行比较。 | |
信息系统 | 安全功能 | |
在事故工况期间,将电厂有关安全的情况通知厂内和厂外的安全专家。 | ||
记录或打印安全重要过程变量的短期和长期变化,供立即分析或事后分析并在营运 单位内和向上级主管当局报吿之用。 | ||
控制系统 | 安全特性 | 控制系统将过程变量维持在电厂安全分析中所假定的限值以内。 |
系统参与安全功能的执行。 | ||
系统中的随机故障和共因故障会发出使保护系统动作的要求,即这些故障为假设始 发事件 | ||
与安全设备的接口 | 保护系统、安全驱动系统及安全系统辅助设施之间的设备接口 | (1)电厂安全系统与电厂控制系统之间的相互连接处; (2)与监测安全系统状态的设备的连接处; (3)与动力源的连接处。 |
根据规范《核电厂系统和软件的验证和确认》的理解,摘取重要的描述如下,作为第三方对研发流程管控和产品测评的主要依据:
包括软件技术过程、硬件技术过程、系统技术过程,软件和硬件技术过程相似,系统技术过程包括了系统技术、用户需求和运维,这些都是乙方须保证的范围,对于测评团队主要关注系统的交付、测评和安全特性的设计实现与可靠性。
验证是对需求的实现进行功能和非功能测试,符合设计要求;确认是从用户和需求的角度验,既满足了需求、同时又是用户可接受的结果。如果用户不可接受则需求设计都需要重新审视、不能直接交付、沟通或整改。
根据甲方的要求,乙方应提供完整的交付件: 包括文档、过程文档和可运行的系统。
交付文档范围和标准依据流程规范要求,这是乙方的交付件。
第三方监管根据项目需求和双V流程对乙方的研发过程和交付件进行验收、测评,乙方的需求设计与开发文档、测试文档与测试结果、以及可运行的系统进行管控、评审、测评,同时对乙方的研制过程管控、测评,第三方依据测评方案测评给出测评报告,评审通过后移交给项目监管方甲方,交付件包括乙方的交付件是经过测评OK的、同时监管方的交付件证明交付的系统通过安全认证测试。
特点:V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析,系统设计的验证,需求的满足情况一直到后期的验收测试才被验证;没有体现出“尽早地和不断地进行软件测试”的原则。
-
-
- 测试模型:双V-W模型
-
特点:由两个V字型模型组成,分别代表测试与开发过程,明确表示出了测试与开发的并行关系,测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等开发输出的文档同样要测试。优点:
测试的活动与软件开发同步进行,
测试的对象不仅仅是程序,还包括需求和设计,
尽早发现软件缺陷可降低软件开发的成本。
按照双V模型、参考业界标准,测试验证活动贯穿开发从需求设计至交付运行的全过程,
开发测试协同一体化,将测试贯穿到整个软件的生命周期中,且除了交付系统要测试,需求、设计等都要测试;测试更早的介入到软件开发中,能尽早的发现缺陷进行修复;测试与开发独立动作、并与开发并行。
双V又叫W模型,由两个V字型模型组成,分别代表测试与开发过程,明确表示出了测试与开发的并行关系,测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等开发输出的文档同样要测试。测试范围包括软件部份、硬件部份和整个系统部份,流程要符合双V规范以及规定的交付件,针对安全设计要求产品需要单独对安全特性设计与测试。
测试方案包括测试计划、测试需求分析:依据项目需求和双V标准进行测试需求分析,确定测试范围,单独列出安全特性,依据通用测试设计方法和与涉核系统设计的安全标准,进行测试类型确定和测试; 安全特性从设计检查表,至测试全覆盖检查表。下面主要描述双V测试的主要测试类型:
大概描述测试类型和应有的活动作为乙方研发测试标准,和第三方监管的监察依据:文档测试、单元测试、集成测试、系统测试、确认测试、验收测试、安全特性测试,如下各项测试由乙方完成,第三方监管负责监管审查。
-
-
- 文档审核与测试
-
检查文档、设计文档完整性,与业务需求、双V标准、安全系统设计规范符合度:
安装文档、运维文档、用户说明书等测试。
-
-
- 单元测试:
-
又称模块测试,是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求,发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试
-
-
- 集成测试
-
也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行集成测试。集成测试是单元测试的逻辑扩展。集成测试是检验程序单元或部件的接口关系,逐步集成为符合概要设计要求的程序部件或整个系统。
集成测试的目标是按照设计要求使用那些通过单元测试的构件来构造程序结构、装置。单个模块具有高质量但不足以保证整个系统的质量,两种测试技术是用于集成测试:功能性测试、非功能性测试:对模块的性能或可靠性进行测试。
-
-
- 系统测试
-
是对整个系统的测试,将硬件、软件、操作人员看作一个整体,是在真实的系统运行的环境下,检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接,并最终满足用户的所有需求。检验它是否有不符合系统说明书的地方,这种测试可以发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善,能不能保证系统不受非法侵入;压力测试是测试系统在正常数据量以及超负荷量(并发) 等情况下是否还能正常地工作。
系统测试是将经过集成测试的软件,作为计算机系统的一个部分,与系统中其他部分结合起来,在实际运行环境下对计算机系统进行的一系列严格有效地测试,以发现软件潜在的问题,保证系统的正常运行,内容包括:功能测试:即测试软件系统的功能是否正确,其依据是需求文档,如《产品需求规格说明书》; 健壮性测试:容错能力、恢复能力。
-
-
- 涉核安全特性测试
-
乙方需要对安全特性的设计与实现进行单独测试,并包括在阶段测试报告和验收报告中。
依据7章节安全系统总则、信息系统、控制系统、与安全设备的接口,乙方应细化系统中涉及的功能点,如果不涉及则明确标注,测试方案中应单独标识设计。
-
-
- 确认测试
-
确认测试,是对通过组合测试的软件进行的,这些软件已经存于系统目标设备的介质上。确认测试的目的是要表明软件是可以工作的,并且符合”软件需求说明书”中规定的全部功能和性能要求。确认测试是按照这些要求定出的”确认测试计划”进行的,验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。测试工作由一个独立的组织进行,而且测试要从用户观点出发、就是用户可接受,与用户原始需求审视。
-
-
- 验收测试
-
验收测试是软件产品检验的最后一个环节,按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接收或拒收系统,可能会包括物理测试或是性能测试,是向未来的用户表明系统能够像预定要求那样工作。
经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。
验收测试让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。
验收测试是确认一系统是否符合设计规格或契约之需求内容的测试,验收测试是软件开发结束后,用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求,以及用户能否接受的问题。由于它不只是检验软件某个方面的质量,而是要进行全面的质量检验,并且要决定软件是否合格,因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划,进行软硬件配置评审、功能测试、性能测试等多方面检测。
用户验收测试可以分为两大部分:软件硬件配置审核和可执行程序、装置测试,其大致顺序可分为:文档审核、配置脚本审核、测试程序或脚本审核、可执行程序、装置测试。乙方验收测试通过后将交付的系统交由监管方进行最后的安全综合测评。
依据双V规范和安全设计要求,将软件技术过程、硬件技术过程、系统技术过程以及测评监控实施全流程表述如下,表明研发过程开发测试并行、与第三方测评并行; 第三方对整个研制过程监控,从技术、流程、交付件各个维度管控、测评:
根据双V流程标准和涉核系统安全设计标准,测评主要工作如下,
-
-
- 测评计划:
-
包括但不限于人员、计划、验收与测评范围、安全特性、沟通机制、测评方法、阶段验收点、交付件清单、质量控制与整改PDCA流程等。测评活动包括主要活动和辅助活动,如下描述测评的主要活动和过程。
-
-
- 辅助活动:
-
流程辅导、技术交流、交付件沟通等
-
-
- 流程监控:
-
记录流程异常、并作出整改处置
-
-
- 阶段测评:
-
交付件接受、评审、确认,整改处置。
-
-
- 流程审查:
-
阶段确认、终验,对流程输出审计,对流程活动审计
-
-
- 文档审核:
-
对交付文档审核、过程文档抽检。
对于安全特性单独验收,监管方主导测试并给出评价。安全特性符合度检查表:
序号 | 设计要求 | 是否涉及 | 安全特性数 | 完成数 | 通过数 |
| 性能 | ||||
| 可靠性 | ||||
| 独立性 | ||||
| 设备鉴定 | ||||
| 可试验性 | ||||
| 可维修性 | ||||
| 动力源 | ||||
| 电气干扰 | ||||
| 控制室 | ||||
| 辅助控制点 | ||||
| 数字计算机系统 | ||||
| 多路传输 | ||||
| 报警和通话系统 |
-
-
- 确认性测试
-
对乙方确认性测试方案、用例审核,测试报告审核,选取一二级用例测试。
-
-
- 验收性测试
-
对乙方验收性测试方案、用例审核,测试报告审核,选取一二级用例测试;
-
-
- 测评评价
-
在项目验收完成待交付阶段,监管方依据双V标准和安全特性设计规范,制定测评表,最终打分,给出综合评价,交付件清单等,通过测评报告评审会,附上移交清单,由甲方、乙方签字确认,对于所有文档评价过程乙方、第三方承诺以实事为依据。关键测评表与评审审计清单如下:
- 安全特性符合度检查表
- 流程符合度检查表
评价阶段 | 硬件 | 软件 | 系统 | 说明 | ||||||
标准分 | 打分 | 评价人 | 标准分 | 打分 | 评价人 | 标准分 | 打分 | 评价人 | ||
需求分析 | 20 | 20 | 20 | |||||||
架构设计 | 20 | 20 | 20 | |||||||
实现 | 20 | 20 | 20 | |||||||
集成 | 20 | 20 | 20 | |||||||
移交 | 10 | 10 | 10 | |||||||
运维 | 10 | 10 | 10 | |||||||
总分 | 100 | 100 | 100 | 审核人 | ||||||
结论 | 整改、通过 | 整改、通过 | 整改、通过 | 审核日期 |
- 测评评分表
评价因素 | 标准分 | 打分 | 评价人 | 说明 |
流程 | 10 | |||
硬件 | 10 | |||
软件 | 10 | |||
安全特性 | 30 | |||
系统 | 40 | |||
总分 | 100 | 审核人 | ||
结论 | 结论:整改、通过 | 审核日期 |
- 乙方交付件审计表
评价阶段 | 硬件 | 软件 | 系统 | 说明 | ||||||
文档数 | 实际数 | 质量分 | 文档数 | 实际数 | 质量分 | 文档数 | 实际数 | 质量分 | ||
需求分析 | ||||||||||
架构设计 | ||||||||||
实现 | ||||||||||
集成 | ||||||||||
移交 | ||||||||||
运维 | ||||||||||
总计 | 审核人 | |||||||||
结论 | 整改、通过 | 整改、通过 | 整改、通过 | 审核日期 |
- 乙方功能清单审计表
评价阶段 | 硬件 | 软件 | 系统 | 说明 | ||||||
功能数 | 实际数 | 质量分 | 功能数 | 实际数 | 质量分 | 功能数 | 实际数 | 质量分 | ||
需求分析 | ||||||||||
架构设计 | ||||||||||
实现 | ||||||||||
集成 | ||||||||||
移交 | ||||||||||
运维 | ||||||||||
总计 | 审核人 | |||||||||
结论 | 整改、通过 | 整改、通过 | 整改、通过 | 审核日期 |
- 测评报告:
报告包括内容有测评方案、测评范围与目标、测评计划、测评流程、测评成员、问题列表、遗留列表,测评过程 、测评结果:流程符合度检查表、安全特性符合度检查表、确认需求符合度、测试执行与方案符合度、乙方测试覆盖率,产品功能性能等指标满足度,故障隔离与异常处置备案,乙方功能清单审计表 , 乙方交付件审计表 ,测评评分表等。
-
-
- 测评移交
-
最后依据交付件清单移交,测评文档和通过安全测试的系统产品,由甲方确认测评项目结束。
测评不只是针对产品和交付标的测试评价,还要有流程规范的跟踪审计要求,这些都应体现在最后的交付件、测评方案、测评报告中。就是在开发的前期需求阶段乙方人员投入测试需求分析与测试设计,乙方还应有QA流程管控人员参考,而我们监管也是从项目生命周期一开始介入,跟进所有的控制点和交付件、并进行阶段验收、测评。