基于V模型的ATS软件验证方法研究

梁鸿煜， 燕 飞

(1. 交控科技股份有限公司， 北京 100070; 2. 北京交通大学电子信息工程学院, 北京 100044)

基于V模型的ATS软件验证方法研究

梁鸿煜1， 燕 飞2

(1. 交控科技股份有限公司， 北京 100070; 2. 北京交通大学电子信息工程学院, 北京 100044)

轨道交通信号系统必须经过严格的验证才能进入工程应用。以ATS自动列车监控系统软件为例，研究信号系统在生命周期V模型下的验证方法，把开发周期简要划分为需求分析、设计实现、测试验证3个阶段，用以论述验证活动，阐述在产品生命周期各个阶段采用如评审、追溯分析、测试分析等不同验证方法，从而更大程度地保证系统的正确性。说明ATS系统的验证活动是一个庞大的工程，在产品开发生命周期的各个阶段都应执行充分的验证活动，收集足够的客观证据证明产品各个阶段的输出满足需求。

城市轨道交通； 自动列车监控； 验证； V模型

1 发展概况

在轨道信号系统的招标文件和采购合同中，都明确要求，信号系统应符合国际国内行业标准。如国际铁路行业标准(IRIS)和中华人民共和国国家标准质量管理体系(GB/T 19001—2008)中都明确要求，产品应通过全生命周期的验证。系统或软件的验证是指对一个系统或产品评价的过程活动，以确定一个给定阶段的输出是否满足该阶段开始时所给定的要求。当前，国产信号系统发展获得广泛的工程应用，然而对信号系统的验证活动相对缺乏[1-2]。因此，笔者以自动列车监控系统(automatic train control system，ATS)为例，总结地铁信号系统的验证方法，旨在探索业内空白，并对其他信号系统的验证活动提供参考。本文以获得英国劳氏铁路认证，并成功应用于北京地铁7号线的ATS系统软件为例。

ATS系统的验证活动是一个庞大的工程，在产品开发生命周期的各个阶段都应执行充分的验证活动，ATS系统的安全完善度(safety integrity level，SIL)等级根据安全分析被定义为2级，因此应按照SIL2的标准对ATS系统进行验证活动。安全生命周期应参考EN 50126标准中的系统周期定义，并与产品项目中定义的系统生命周期相一致。系统生命周期中的设计和确认部分可看作一个自上而下阶段并伴随一个自下而上的阶段(如V型)[3-4]。信号系统的生命周期经常采用图1的V模型，V模型可作为信号系统的一个通用模型，由于软件规模以及开发周期历时等原因，通常对生命周期的阶段进行合并，本文把开发周期简要划分为需求分析、设计实现、测试验证3个阶段，用以论述验证活动。

参考图1，需求分析阶段包括用户/系统/子系统/软件需求分析活动；设计实现阶段包括软件架构设计、软件详细设计、编码实现活动；测试阶段则包括V模型右半边的代码走查、软件单元测试、软件集成测试、软件确认测试、系统测试等活动。

图1 生命周期V模型Fig.1 V-type model of the life cycle

2 ATS系统概述

自动列车监控系统是列车自动控制系统(automatic train control system, ATC)的重要子系统之一，是一套提供给运营调度人员进行在线监测行车状态、进行自动控制和人工干预的信号系统。一方面，ATS通过其他信号子系统获得现场信号设备和列车运行的实时状态信息，并把这些信息如实地展示给调度人员进行站场状态监视；另一方面，ATS还提供了人机交互界面，方便调度人员根据现场情况实时进行人工控制。针对不同的控制级别，ATS提供不同的自动化控制手段，从而减轻运营调度人员的作业负担，提高运输效率和服务水平。其主要功能包括：站场信息显示、信号控制、列车追踪和控制、控制区域管理、运行图管理、报警/日志管理、其他辅助功能[5](见图2)。

图2 越南河内线ATS调度工作站车辆段站场图Fig.2 The depot map of ATS scheduling workstation of Hanoi, Vietnam

3 全生命周期验证方法

3.1 需求分析阶段验证

验证活动首先要保证需求的正确性和完备性。本阶段验证活动应强调：需求分析的正确性与完备性、需求的可追溯性、需求的可测性。

需求验证通常采用的方法是标杆比较、专家评审、检查表和追溯矩阵。

3.1.1 标杆比较

信号系统的需求通常来自于国际国内的行业标准以及运营的特殊要求。标杆比较则是将初步提取的需求与行业标准、业内先进经验进行比较，从而分析出遗漏与不足，改进自身需求的过程。

以ATS系统为例，2015年中国城市轨道交通轨道技术装备专业委员会发布了《城市轨道交通CBTC信号系统——ATS子系统规范》，作为归纳总结后的需求规范，可作为重要的参考。信号系统的其他产品可参考相应的子系统规范、IEEE的CBTC性能功能需求以及其他行业设计规范、法规。安全系统还需要参考安全评价标准，如欧洲电气标准委员会定义的(CENELEC)基于IEC 61508标准制定的轨道交通系统开发和安全评价的4个参考标准[6]：

1) EN 50126铁路应用：可靠性、可用性、可维护性和安全性(RAMS)规范和说明。

2) EN 50128铁路应用：通信、信号和处理系统，铁路控制和防护系统用软件。

3) EN50129铁路应用：通信、信号传输和处理系统，信号传输用于电子系统的安全。

4) EN 50159铁路应用：通信、信号和处理系统。

由于ATS系统直接提供给调度人员直观的人机交互界面，因此不同的运营线路常常有不同的需求。例如，北京地铁2号线全程都是地下车站，而北京地铁7号线有地上、地下两种类型的车站，则需要ATS系统在站场显示时新增地标显示功能，用以区别地上或地下车站。因此，在验证需求时，不仅需要参考标准，还需要参考合同文件及其他附属技术联络会议文件等，根据实际情况进行调整，以满足特定用户的需求。

3.1.2 专家评审

专家评审是保障需求正确性的重要手段。在产品需求经过内部评审后正式定稿前，验证人员应组织专家评审，对需求进行二次检查。专家评审通常以会议的形式进行，邀请行业专家参会评审。

通常事先将相关材料发放给专家，或是直接在会上采取头脑风暴的方法进行专家提问。ATS系统的专家评审会应邀请业内专家、运营调度人员或用户代表、项目经理、产品经理、验证和确认人员。在专家评审过程中，产品经理应起主导作用：阐述产品需求、记录专家评审意见、进行解释说明、进行整改记录，最终获取专家认可。在专家评审会最终应达成专家评审意见，获取专家对需求的认可，并进行签字确认。

3.1.3 检查表

在EN 50129 表E9中，对SIL2级的产品强烈推荐使用检查表的方式进行验证。不仅是产品需求，产品生命周期的所有文档都应进行文档检查。通常在企业标准中会制定相应的检查表。以下以产品需求为例，说明检查的内容。产品需求的检查项，包括且不限于以下方面。

清晰性：

是否存在有理解分歧的需求?需求是明确、准确和清晰的吗?是否每个需求都是切实可行的?

追溯性：

需求是可跟踪的吗？

完整性：

是否所有的需求都被完整地定义了?是否包括了与功能性相关的所有需求?是否包括了与性能相关的所有需求?是否包括了与外部接口相关的所有需求?是否包括了与数据库相关的所有需求?是否包括了与硬件相关的所有需求?

⋮

不同的软件文档应制定不同的产品文档检查表模板，进行针对性的检查。

3.1.4 追溯矩阵

在信息系统中，通常关注需求的分配基线，而系统架构说明书则是分配基线的直观体现。在系统架构中，通常把系统的功能需求进行罗列，划分到各个子系统需求中，再由子系统需求分配到软硬件需求，再到概要设计、详细设计，最后通过编码实现。在ATS产品中，通常以调度人员的各个操作工作站为基础，进行划分子系统。常见的有计划/编图工作站、维护工作站、调度工作站、派班工作站、值班工作站、网关计算机、现地工作站等子系统。在对分配基线进行验证时，主要采取的手段是追溯矩阵。追溯的目的是保证所有的需求都能正确实现，且不存在不可追溯的内容，追溯需要达到双向的100%覆盖，即常说的双百覆盖。

信号系统采取结构化的设计方法，因此对需求的分配也是至上而下。如，产品需求分配到子系统需求应保证100%，从而确保产品需求没有遗漏；其次，子系统需求应追溯产品需求，保证没有多余的需求。软硬件需求、概要/详细设计，代码同样需要遵循这个原则，进行双百覆盖，保证产品线纵向的一致性。

在这个过程中，从上至下常常是一对多的关系。比如通用的站场显示的需求，需要分配到调度工作站子系统，也需要分配到现地工作站子系统。在需求分配时，则需要考虑到该条需求是否全部分配到对应的子系统中去。

在验证活动中，软件需求应完全满足需求，确保需求得到满足，开发人员对此与验证人员容易达成一致。比较有分歧的一点是，是否可以存在设计大于需求的情况。通常研发人员出于更全面的考虑，分析出来的某条需求，无法向上层需求进行追溯。然而，这样的设计通常不被验证人员接受。首先，多余的需求可能会造成额外的故障；其次，可能会被认为是产品的固定附加值：假设北京地铁获得了一个锦上添花的功能，上海地铁在考察时，觉得该功能不错进行了采购，结果却未获得该功能，则容易引起合同分歧。

3.2 设计实现阶段验证

为确保设计和开发输出满足输入要求，应依据所策划的安排对设计和开发进行验证。验证结果及任何必要措施的记录应予保持。在设计阶段同样应采取追溯的方法。

在软件概要设计阶段，验证工作将强调：验证软件概要设计的正确性；确认软件概要设计对软件需求覆盖的完备性；确认软件集成测试用例作为软件概要设计一系列测试案例的充分性。

在完成软件概要设计后，验证人员应组织相关人员对软件概要设计进行审查，主要审查设计方案与主要算法的可行性和先进性，以及接口设计的性能和软件运行环境的恰当性，从而论证概要设计的正确性和可行性；此外应对每个软件实施概要设计追溯分析，在这项活动中，软件概要设计应追溯软件需求，软件集成测试用例应追溯软件概要设计，从而论证软件概要设计的完备性和可验证性。

在软件详细设计阶段，验证工作将强调：确认软件详细设计对软件概要设计覆盖的完备性；确认软件单元测试用例作为软件详细设计一系列测试案例的充分性。

在完成软件详细设计后，验证活动分为2个阶段：第1阶段，验证人员组织相关人员进行审查，评审软件单元间的接口，包括共享外部数据，参数形式和传送方式以及上下层调用关系，保证软件每个单元输入变量和输出变量都能被明确定义；第2阶段，采用追溯分析的方法保证软件详细设计到软件概要设计的追溯，分析软件单元功能与概要设计的一致性。

在代码实现阶段，验证工作将强调：确认软件代码对详细设计覆盖的充分性和完备性；确认软件确认测试用例作为软件需求一系列测试案例的充分性。

在软件编码活动完成后，验证人员应实施验证活动以保证代码的正确性、完备性及可用性。首先，采用人工走查的方法对软件的代码进行审查，组织相关人员提出意见或缺陷；然后使用代码走查工具对代码进行规则检查，进一步确保软件代码的正确性和规范性；最后，通过建立软件代码与详细设计的追溯矩阵，保证软件代码对详细设计覆盖的充分性，且所有软件代码都能追溯软件详细设计，并且没有冗余代码。如果以上几种方式都可以通过，那么该代码即可发布，进行正式的配置管理；若存在问题，则需要进行整改。

在ATS系统中，较为特殊的是涉及多个公共模块。例如，在调度工作站、现地工作站、派班工作站等都会涉及操作日志记录、报警信息显示等这类公用模块，因此在软件实现的时候较为合理的是开发公共模块，应用软件通过调用公共模块实现产品功能。因此，在进行追溯分析时，应考虑模块应用的一致性以及模块的追溯。

3.3 测试阶段验证

软件测试是验证产品正确性的重要手段。在测试阶段，广义的验证包括测试活动本身，狭义的验证则仅指测试审核的过程。本文中的验证指的是狭义的验证。由于ATS系统的安全完善度等级定义为SIL2，因此，需要按照EN 50128：2011的标准执行测试。在EN 50128：2011Table A.5-Verification and Testing 中对SIL2的功能测试进行了要求[6-12]，其中静态分析、动态分析/测试、功能/黑盒测试、性能测试、接口测试都是强烈推荐(HR)，而静态分析、动态分析/测试和功能测试则是必做其一。因此，在测试活动策划初期，验证就应该介入，检查这些测试活动是否完备(见表1)。

表1 根据SIL等级的建议测试方法

实际上，软件的SIL等级是根据功能来划分的。ATS系统定义为SIL2级则是按功能的SIL2等级定义。由于ATS是一个庞大的信息系统，除了安全功能外，还有许多非安全功能。对于SIL0的模块，功能测试、接口测试是强烈推荐，因此验证员也需要关注这些SIL0的模块是否进行了功能测试和接口测试。由于ATS系统软件直接参与运营活动，因此SIL0模块的白盒测试，在条件允许的情况下仍建议进行，从而保证提供给用户高质量的产品。由于ATS是ATC的重要组成子系统，因此，ATS通常会与ATC的其他子系统有信息交互，比如来自CI(计算机联锁)的站场信息、来自VOBC(车载控制器)的车辆信息、来自DSU(数据库存储单元)的限速信息等。ATS必须通过与这些系统的接口测试才能正确实现产品功能，所以系统对外的接口测试不区分SIL等级，都是必不可缺的。

在传统自动驾驶模式(AM)下，ATS的安全功能涉及临时限速、道岔强扳和计轴复位；在全自动驾驶模式(FAM)下，安全功能还涉及雨雪模式、火灾联动等。对于这些影响行车安全的功能主程序以及逻辑处理层，建议进行黑白盒测试，而不是仅选择欧标列出的最低标准；对于其他非安全模块，可以根据实际情况酌情删减，比如日志记录、报警等仅需做功能测试和接口测试，代码走查、单元测试则需要考虑投入的性价比。

在EN 50128中，将静态分析作为验证的手段，实际上静态分析作为测试手段更为恰当。静态分析可分为桌前检查(程序员自己检查)、内部走查(测试人员独自检查)和外部走查(测试人员与程序员一起检查)，选用哪种方式取决于代码量、程序的复杂程度、测试人员对代码的理解程度。但常见的活动是由独立研发的白盒测试人员直接测试代码正确性，而验证人员对比活动进行二次检查。验证活动在本阶段主要是检查测试的代码覆盖率、用例的执行率，测试活动的充分性以论证产品的正确性。

3.4 变更验证

在V模型中，变更活动始终贯穿于产品开发的生命周期中。信号系统属于慢迭代稳定系统，因此对变更的控制具有严格要求。如果发生变更，验证活动则需要被重复实施。通过对需求、设计、测试活动重复进行验证，给出审核结论，保证变更后的系统仍具有正确性和一致性。

在变更验证过程中，验证人员应重点关注：变更完成是否与变更申请一致；变更是否可追溯；变更是否可验证；变更是否测试验证通过。

以ATS系统为例，在不同的工程项目中应用，通常需要对通用产品进行特殊应用开发。V模型的一个重大优越性在于变更的控制，而信号系统产品生命周期内的变更无法避免，因此对变更的验证同样重要。

4 结语

综上所述，ATS系统需要经过充分的验证活动，收集足够的客观证据证明产品各个阶段的输出满足需求。尽管在验证活动中，验证员通常需要反复提出意见要求整改，但是验证活动的初衷绝不是找出系统的错误，而是搜集系统正确的证据，从而提供给产品生成方、评估方乃至产品使用者充足的信心。因此，验证员所扮演的绝不是一个挑毛病的角色，而是帮助产品趋于完善。

本文以ATS系统为例对验证活动进行研究，对于其他SIL2的信号系统，如冗余ATO(列车自动驾驶系统)可参考本验证方法，SIL等级较高的CI(计算机联锁)、ATP(列车自动保护装置)等，则需要更加严格的验证活动，从而更大限度地保证产品的正确性。

[1] 燕飞,郜春海,唐涛.轨道交通信号工程安全管理与认证模式[J].都市快轨交通,2011,24(4):12-16.

YAN Fei,GAO Chunhai,TANG Tao.Safety management and authentication modes for a rail transit signaling engineering project [J].Urban rapid rail transit, 2011, 24(4):12-16.

[2] 燕飞,唐涛,郜春海.城市轨道交通安全评价体系研究[J].都市快轨交通,2010,23(3):32-36.

YAN Fei,TANG Tao,GAO Chunhai.Esearch on safety assessment framework for urban rail transit[J].Urban rapid rail transit, 2010, 23(3):32-36.

[3] 中国城市轨道交通轨道技术装备专业委员会.城市轨道交通CBTC信号系统:ATS子系统规范:CZJS/T 0030—2015[S].北京,2015.

CAMET.ATS subsystem specification:CBTC signal system for urban rail transit:CZJS/T 0030—2015[S].Beijing, 2015.

[4] 陈俊强. 基于数据驱动的ATS系统功能测试方法研究[J].铁路通信信号工程技术，2016，13(2)：70-73.

CHEN Junqiang. Research on ATS function testing method based on data driven[J]. Railway signal & communication engineering, 2016, 13(2):70-73.

[5] 地铁设计规范:GB 50157—2013[S].北京: 中国建筑工业出版社,2014.

Code for design of metro: GB 50157—2013[S].Beijing: China Architecture & Building Press, 2014.

[6] STEVEN R R.Software verification and validation for practitioners and managers[J].Artech house,Inc.,2001(2): 44-45.

[7] Railway application:Communication, signalling and processing systems：software for railway control and protection systems: EN 50128: 2011[S].CENELEC, 2011.

[8] Railway applications：Communication, signalling and processing systems：safety related electronic systems for signaling: EN 50129: 2003[S].CENELEC, 2003.

[9] 基于通信的列车控制(CBTC)系统的性能和功能要求：IEEE Std.1474.1—2004[S].IEEE-SA Standards Board,2004.

Communications-based train control (CBTC) performance and functional requirements:IEEE standard 1474.1—2004[S].IEEE-SA Standards Board,2004.

[10] International railway industry standard:IRIS: 2009 V02 [S].UNIFE, 2009.

[11] Guide for software verification and validation plans:IEEE Std 1059—1993[S].IEEE,1993.

[12] Standard for software verification and validation:IEEE Std 1012—1998[S].IEEE-SA Standards Board,1998.

(编辑：郝京红)

Using V-model Method for Verifying ATS Software

LIANG Hongyu1， YAN Fei2

(1. Traffic Control Technology Co., Ltd., Beijing 100070; 2. School of Electronic and Information Engineering, Beijing Jiaotong University, Beijing 100044)

The signal system must be thoroughly examined before it can be applied in engineering. Taking the automatic train supervision system (ATS) as an example, this paper attempts to investigate the verification method used for the signal systems under the lifecycle of V-model. The development cycle is divided into 3 stages, including requirement analysis, design implementation and test verification, in order to demonstrate the validation activities. The model is divided into different stages with varied methods used in each stage of a product′s lifecycle, including assessment, traceability analysis and test analysis, to ensure a higher degree of accuracy of the system. Description of ATS system validation activities is a huge project, all validation activities should be performed at all stages of the product development lifecycle, and collecting sufficient objective evidence should be done to demonstrate that the output of each stage of the product meets the requirements.Keywords: urban rail transit; ATS; verification; V-model

10.3969/j.issn.1672-6073.2017.03.007

2016-07-19

2016-10-08

梁鸿煜，女，本科，系统保证工程师，专业方向为信号系统验证与确认应用，lhysmile@foxmail.com

U231

A

1672-6073(2017)03-0035-05