城市轨道交通信号系统设计确认表管理方案
2022-09-09侯雪莉何争艳刘锋周文娟邱良辰
侯雪莉 何争艳 刘锋 周文娟 邱良辰
（卡斯柯信号有限公司 上海市 200071）
1 DVT目的
城市轨道交通信号系统的设计确认管理是指对项目需求跟踪矩阵中用户技术性和接口类需求进行识别、分配、确认和管理。
PTR-DVT 为Project Technical Requirement Design Validation Table，项目技术类需求设计确认表，目的是进行项目技术类需求的确认方式分配、覆盖及验证。
SyEID-DVT 为System Interface description Design Validation Table，项目外部接口需求设计确认表，目的是进行项目外部接口需求的确认方式分配、覆盖及验证。
2 DVT管理
本方案DVT创建基于需求管理方案中的需求跟踪矩阵，整个需求管理包含需求识别、分类、覆盖及覆盖验证。其中需求识别是获取技术类、外部接口类、管理类需求的一个过程。技术类需求纳入到PTR-DVT 中进行确认分配及覆盖，外部接口类需求纳入到SyEID-DVT 中进行确认分配及覆盖，管理类需求不做确认分配与覆盖。由验证和确认经理编制PTR_DVT 和SyID_DVT，并进行初步确认方式分类、项目组内评审分类、分类明确后相关人员,相关人员使用测试规程文档或报告进行覆盖、覆盖验证、验证问题确认、出具验证报告。
2.1 DVT创建
2.1.1 PTR-DVT 创建
PTR-DVT 的输入是项目需求跟踪矩阵，由于需求跟踪矩阵分类会不断更新，为了保持DVT 的相对稳定，首次创建PTR-DVT 建议选用分类稳定的需求矩阵版本，即已经过验证并修改后的需求矩阵。项目周期较长的项目，建议使用第3 版基线下需求矩阵，即V&V 验证完并修改过后的需求矩阵，项目周期较短的项目，建议选用第2 版需求基线下的矩阵，即需求完成分类评审且完成第一轮设计覆盖。
项目需求追踪矩阵如图1 所示，含有Req ID、Text、Applicable、Project|Platform 列。 在Applicable 列 筛 选Applicable，Project|Platform 列筛选Project 项，得到所有项目技术类需求，复制Req ID 和Text 列到DVT 的excel 中，并且在同一sheet 页中增设以下列跟踪分配及覆盖，如图2所示：
图1 ：需求跟踪矩阵
图2 ：PTR-DVT 分配及覆盖
-增设确认方式分类列（Validation Allocation）：用来确定每条需求分配类型；
-增设覆盖文档（Test procedure or test sheet reference or verification report/Version）及章节列（Test Case ID|Chapter ID）：用来记录回填覆盖情况；
-增设验证结论列（Coverage Verification 包含Status、Verifier's remarks、Comments）：用来跟踪记录覆盖验证状态，
最后，利用统计页（Synthesis），对DVT 的分配和覆盖验证状态分NA(不适用)、OK(验证通过)、NOK（验证不通过）、Not Covered（未覆盖）、Not checked(未验证)进行数据统计，直观体现覆盖率。
2.1.2 SyEID-DVT 创建
SyEID-DVT 的输入是项目外部接口技术规格书，信号系统外部接口通常涉及到信号与站台门，防淹门、洗车线、综合后备盘、紧急关闭按钮、联络线、与车辆、与大屏、无线通信、时钟、广播、综合监控、乘客信息系统、线网指挥中心、发车表示器等，如图3 所示。
图3 ：信号系统外部接口
外部接口需求及功能均在接口技术规格书中定义并描述，其中每一个章节和对应描述内容即是一条需求。SyEIDDVT 的输入是项目外部接口技术规格书，项目外部接口稳定后即可创建SyEID-DVT。常采用手动复制到SyEID-DVT excel 中，不同的外部接口单独对应一个sheet 页面。类似PTR-DVT 创建，同一sheet 页面也曾设分类列、覆盖文档列、章节列及验证列，同时增设统计页，能够对DVT 的分配和覆盖验证状态进行直观体现，最终汇总成SyEID-DVT excel。
2.1.3 DVT 创建时机
PTR-DVT：
由于项目需求跟踪矩阵分类会不断更新，为了保持PTR-DVT 的相对稳定：项目周期较长的项目，建议使用第3 版需求基线，即完成首轮需求验证并更新后的需求跟踪矩阵导入PTR-DVT；项目周期较短的项目，建议选用第2 版需求基线，即完成分类评审且第一轮需求覆盖完成后的需求根据矩阵，这时需求分类已相对比较稳定。特殊项目情况下，例如第一版需求分类评审效果较好，或需求矩阵升级不够及时，也可考虑选用第一版需求矩阵作为输入生成PTRDVT。
SyEID-DVT：
项目外部接口规格书稳定后即可创建SyEID-DVT，建议最晚创建时间不能晚于外部接口调试节点。
2.2 DVT分配
2.2.1 PTR-DVT 分配
PTR-DVT 创建完成后即可在Validation Allocation 列进行分类，分类主要用于确定需求确认的方法，主要方法有：T&C、SYS 确认、ATC 确认、ATS 确认、CI 确认、MSS 确认，DCS 确认、安装、设计验证、仿真，RAMS，EMC，verify，Platform，NA。PTR-DVT 具体分类原则如表1 所示。
表1 ：PTR-DVT 分类原则
项目实际管理过程中，倾向纯软件数据功能类需求，室内可以测试的，尽量分到室内测试，减小现场测试压力。由单独一个子系统实现的功能分给FIVP 子系统测试：如ATS确认。由两个以上子系统实现的功能分给FIVP 系统确认。现场调试相关或FIVP 无法测试的功能需分给T&C 确认；FIVP 无法完整确认的功能需求分给T&C，比如ATO 自动调整，ATO 精确停车，PSR，性能相关等。接口类需求在外部接口定义文件中有更详细的需求，PTR-DVT 中这部分需求可以通过填写为
DVT 完成确认方式分配后，需要在评审系统进行评审，邀请的评委需要包含：工厂集成测试经理、项目技术经理、各子系统经理、T&C 经理、EMC 经理、RAMS 经理、安装经理、调试经理，所有子系统及系统级测试人员、设计验证人员，以保证DVT 分配的正确性。根据评审意见，DVT 作者完成修改，评审人员确认修改通过后，DVT 升级为正式版发布。
2.2.2 SyEID-DVT 分配
SyEID-DVT 创建完成后即可在Validation Allocation 列进行分类，分类原则与PTR-DVT 相同，不同之处是分类种类较少，大部分分类现场调试，少部分分配给室内测试，还有部分属于原理性描述或者接口中对对方的要求，可以NA，备注合理的解释。
2.3 DVT覆盖
DVT 分配完成后即可分发给不同的负责人进行覆盖和回填，具体时机和覆盖回填内容如图4 所示。
图4 ：DVT 覆盖
2.3.1 设计验证覆盖
为了变更和验证有更好的追溯性和一致性，本方案中确认和验证经理（V&V）在设计基线发布之后，将DVT 中分配发给设计验证需求表格分配测设计验证人员，设计验证人员需要确认项目的设计文档覆盖了设计类的需求，设计验证人员回填设计验证文档名称、版本、对应章节号到对应的DVT 表格中。
2.3.2 工厂测试覆盖
为了DVT 在首轮遍历测试中得到充分验证，本方案中确认和验证经理（V&V）需在工厂集成测试开始前，将DVT 分配发给各子系统及系统级的需求下发给相关测试人员，测试人员在编写用例的同时，需要将设计类需求转化成测试运营场景，测试人员回填测试用例名称和版本，测试用例编号到对用的DVT 表格中。
2.3.3 现场调试/安装覆盖
为了减少现场调试安装规程变更次数，本方案中确认和验证经理（V&V）需在现场安装调试规程完成之前，将DVT 分配发给安装、调试经理，确保安装和调试类的需求，在安装和调试规程出具的时候有效覆盖。安装和调试经理回填安装调试规程名称和版本、规程章节号到对用的DVT 表格中。
2.3.4 其它覆盖
常见分配覆盖除了设计验证覆盖，工厂测试覆盖，现场调试/安装覆盖，还有其他分配例如EMC、RAMS、Platform、NA、Verify、Simulation 需求的覆盖，具体覆盖方式详见图5。
图5 ：其它覆盖
其中RAMS 需求覆盖注意区别，需求跟踪矩阵里需要用计划类文档覆盖，DVT里需要用分析报告覆盖；EMC需求，需求跟踪矩阵中对分包商EMC 的需求，用分包商的技术规格书来覆盖即可。
2.4 DVT验证
2.4.1 PTR-DVT 验证
PTR-DVT 验证内容：
（1）回填的文档、章节、版本、测试用例等内容全部正确覆盖需求中的所有功能；例如：相应的测试用例及步骤可以覆盖需求中的全部功能。
（2）验证结论，VV 填写结论到DVT 表格中 “Coverage Verification”。
1.Status 结论有3 类，OK：验证通过；NOK：验证全部或部分不通过，由测试或安装调试提交CR 记录相关没覆盖的需求，确保项目按DVT 中的需求实施；Not Covered：暂时未覆盖验证，未到项目计划阶段，后期数据或调试已计划补充；
2.Verifier's remarks里面需要备注需求矩阵报告的版本，例如“comment on V1.1.0：验证通过”；
3.Comments:备注修改信息，例如：扣车功能未覆盖，升级系统用例增加覆盖等；
2.4.2 SyEID-DVT 验证
SyEID-DVT 的验证方法与PTR-DVT 完全相同；
2.4.3 DVT 验证时机
DVT 验证时机定义如下：
（1）在信号系统室内测试见证前完成室内FIVP 测试部分的覆盖验证，在FIVP 测试正式开始前，实现需求覆盖率90%以上，并升级V1.1.0。测试用例初版编写完成并反馈关联需求的测试用例后，即可开始验证，验证完成后如有NOK 项，及时反馈给测试人员修改或补充用例，并进行回归验证。第一轮测试可遗留部分需求待确认或覆盖NOK 项，遗留项需在后续的回归测试中尽快确认并覆盖；
（2）在信号系统现场系统运行及性能测试前需完成调试安装部分的覆盖验证，现场调试规程初稿完成后即与调试经理开会讨论覆盖，并同时验证。由于现场调试工作开始后，调试文档修改工作推行起来比较困难，因此DVT 调试安装部分验证工作建议与调试安装经理配合尽量在调试安装规程评审工作同时进行，在调试安装基线建立前验证完成，以便及时反馈问题并修改调试安装规程；
（3）在信号系统试运行前完成DVT 所有需求验证，最晚开通运营之前全部完成。
如有遗留项未完成覆盖，需要组织项目CCB 分析未覆盖的合同需求对信号系统开通运行的影响，如有影响，需要输出相关限制给业主。如项目分阶段发证，需要关注对应阶段的需求，确保DVT 相应内容完成覆盖验证
2.5 DVT更新
项目需求矩阵更新后，如果涉及需求分类发生变化，DVT 相应的也需要升级变更，需要将新增需求重新分配、覆盖并验证，确保需求变更部分得到跟踪记录。新分配到工厂测试部分的，如果影响到测试用例，需在下一轮工厂测试尽快更新测试用例以覆盖，新分配到现场调试/安装覆盖的，如果影响到调试/安装规程需要及时更新并打入下一轮调试/安装基线中。
3 结语
本文介绍的这种城市轨道交通信号系统设计确认表管理案，成功应用于笔者公司的城市轨道交通信号工程项目实施过程中，从已开通项目来看，该方案使项目技术类和接口需求得到合理且清晰的确认管理，对项目变更和相关影响做出了正确的判断，并识别了技术类和接口类需求与已实现需求之间的不一致性，有效确保项目技术类和接口类需求确认完整有效，实施落地。
