| 收藏 | 联系 | 首页 | 
中国城市轨道交通网 logo 首页
登陆   注册 
基于V模型的ATS软件验证方法研究
发布日期:2018-11-09 18:46:40

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

 
摘    要: 轨道交通信号系统必须经过严格的验证才能进入工程应用。  以 ATS 自动列车监控系统软件为例,研 究信号系统在生命周期 V模型下的验证方法,把开发周期简要划分为需求分析、设计实现、测试验证 3 个阶 段,用以论述验证活动,阐述在产品生命周期各个阶段采用如评审、追溯分析、测试分析等不同验证方法,从而 更大程度地保证系统的正确性。  说明 ATS 系统的验证活动是一个庞大的工程,在产品开发生命周期的各个阶 段都应执行充分的验证活动,收集足够的客观证据证明产品各个阶段的输出满足需求。
关键词: 城市轨道交通; 自动列车监控; 验证; V模型
中图分类号: U231      文献标志码: A    文章编号: 1672 - 6073(2017)03-  0035- 05
 

Using V  modeIMethodforVerifying ATSSoftware
LIANG Hongyu1 , YANFei2

(1.TrafficContro1Techno1ogyCo., Ltd., BeiJing100070;

2.Schoo1ofE1ectronicand  Information  Engineering, BeiJingJiaotongUniversity, BeiJing100044)

Abstract: ThesignaIsystem mustbethoroughIy examined beforeitcan beappIied in engineering.Taking theautomatictrain supervision system ( ATS)  asan exampIe, thispaperattemptsto investigatetheverification method used forthesignaIsystems undertheIifecycIeofV  modeI.ThedeveIopmentcycIeisdivided into 3 stages, incIuding requirementanaIysis, design impIe- mentation and testverification, in orderto demonstratethevaIidation activities.ThemodeIisdivided into differentstageswith varied methodsused in each stageofaproduct'sIifecycIe, incIuding assessment, traceabiIity anaIysisand testanaIysis, to en- sureahigherdegreeofaccuracy ofthesystem.Description ofATSsystem vaIidation activitiesisahugeproject, aIIvaIidation activitiesshouId beperformed  ataIIstagesoftheproductdeveIopmentIifecycIe,  and  coIIecting  sufficientobjectiveevidence shouId bedoneto demonstratethattheoutputofeach stageoftheproductmeetstherequirements.
Keywords: urban raiItransit; ATS; verification; V  modeI


 1    发展概况
       在轨道信号系统的招标文件和采购合同中,都明 确要求,信号系统应符合国际国内行业标准。  如国际 铁路行业标准( IRIS) 和中华人民共和国国家标准质量 管理体系( GBIT19001-2008 ) 中都明确要求,产品应 通过全生命周期的验证。  系统或软件的验证是指对一 个系统或产品评价的过程活动,以确定一个给定阶段 的输出是否满足该阶段开始时所给定的要求。  当前,国产信号系统发展获得广泛的工程应用,然而对信号 系统的验证活动相对缺乏[1 2] 。  因此,笔者以自动列 车监控系统( automatictrain  contro1system,ATS) 为例, 总结地铁信号系统的验证方法,旨在探索业内空白,并 对其他信号系统的验证活动提供参考。  本文以获得英 国劳氏铁路认证, 并成功应用于北京地铁 7  号 线 的 ATS 系统软件为例。
       ATS 系统的验证活动是一个庞大的工程,在产品 开发生命周期的各个阶段都应执行充分的验证活动, ATS 系统的安全完善度( safetyintegrity1eve1,SIL) 等级 根据安全分析被定义为 2 级,因此应按照 SIL2 的标准 对 ATS 系统进行验证活动。  安全生命周期应参考 EN50126 标准中的系统周期定义,并与产品项目中定义的 系统生命周期相一致。  系统生命周期中的设计和确认 部分可看作一个自上而下阶段并伴随一个自下而上的 阶段( 如 V型) [3 4] 。  信号系统的生命周期经常采用 图 1的 V模型,V模型可作为信号系统的一个通用模 型,由于软件规模以及开发周期历时等原因,通常对生 命周期的阶段进行合并,本文把开发周期简要划分为 需求分析、设计实现、测试验证 3 个阶段,用以论述验 证活动。
       参考图 1,需求分析阶段包括用户 I系统 I子系统 I 软件需求分析活动;设计实现阶段包括软件架构设计、 软件详细设计、编码实现活动;测试阶段则包括V模型 右半边的代码走查、软件单元测试、软件集成测试、软 件确认测试、系统测试等活动。

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


3       全生命周期验证方法

3.1  需求分析阶段验证
       验证活动首先要保证需求的正确性和完备性。  本 阶段验证活动应强调:需求分析的正确性与完备性、需 求的可追溯性、需求的可测性。
       需求验证通常采用的方法是标杆比较、专家评审、检查表和追溯矩阵。

 

3.1.1  标杆比较
       信号系统的需求通常来自于国际国内的行业标准 以及运营的特殊要求。  标杆比较则是将初步提取的需 求与行业标准、业内先进经验进行比较,从而分析出遗 漏与不足,改进自身需求的过程。
       以 ATS 系统为例,2015 年中国城市轨道交通轨道 技术装备专业委员会发布了《 城市轨道交通 CBTC信 号系统   ATS 子系统规范》,作为归纳总结后的需求规范,可作为重要的参考。  信号系统的其他产品可参考相应的子系统规范、IEEE的 CBTC性能功能需求以 及其他行业设计规范、法规。  安全系统还需要参考安 全评价 标 准, 如 欧洲电 气 标 准 委 员 会 定 义 的 ( CEN- ELEC) 基于 IEC61508 标准制定的轨道交通系统开发 和安全评价的 4 个参考标准[6] :
       1)  EN50126 铁路应用:可靠性、可用性、可维护性 和安全性( RAMS) 规范和说明。
       2)  EN50128 铁路应用:通信、信号和处理系统,铁 路控制和防护系统用软件。
       3)  EN50129 铁路应用: 通信、 信号传输和处理系 统,信号传输用于电子系统的安全。
       4)  EN50159 铁路应用:通信、信号和处理系统。
       由于 ATS 系统直接提供给调度人员直观的人机交 互界面,因此不同的运营线路常常有不同的需求。  例 如,北京地铁 2  号线全程都是地下车站, 而北京地铁 7 号线有地上、地下两种类型的车站,则需要 ATS 系统在站场显示时新增地标显示功能,用以区别地上或地 下车站。  因此,在验证需求时,不仅需要参考标准,还 需要参考合同文件及其他附属技术联络会议文件等, 根据实际情况进行调整,以满足特定用户的需求。

 

3.1.2  专家评审
       专家评审是保障需求正确性的重要手段。  在产品 需求经过内部评审后正式定稿前,验证人员应组织专 家评审,对需求进行二次检查。  专家评审通常以会议 的形式进行,邀请行业专家参会评审。
       通常事先将相关材料发放给专家,或是直接在会 上采取头脑风暴的方法进行专家提问。  ATS 系统的专 家评审会应邀请业内专家、运营调度人员或用户代表、
项目经理、产品经理、验证和确认人员。  在专家评审过程中,产品经理应起主导作用:阐述产品需求、记录专 家评审意见、进行解释说明、进行整改记录,最终获取 专家认可。  在专家评审会最终应达成专家评审意见, 获取专家对需求的认可,并进行签字确认。

 

3.1.3  检查表
       在 EN50129  表 E9 中,对 SIL2 级的产品强烈推荐 使用检查表的方式进行验证。  不仅是产品需求,产品 生命周期的所有文档都应进行文档检查。  通常在企业 标准中会制定相应的检查表。  以下以产品需求为例, 说明检查的内容。  产品需求的检查项,包括且不限于 以下方面。
       清晰性:
       是否存在有理解分歧的需求?  需求是明确、准确和清晰的吗?  是否每个需求都是切实可行的?
       追溯性:
      需求是可跟踪的吗? 完整性:
      是否所有的需求都被完整地定义了?  是否包括了 与功能性相关的所有需求?  是否包括了与性能相关的 所有需求?  是否包括了与外部接口相关的所有需求? 是否包括了与数据库相关的所有需求?  是否包括了与 硬件相关的所有需求?
         :
       不同的软件文档应制定不同的产品文档检查表模板,进行针对性的检查。

 

3.1.4  追溯矩阵
       在信息系统中,通常关注需求的分配基线,而系统 架构说明书则是分配基线的直观体现。  在系统架构 中,通常把系统的功能需求进行罗列,划分到各个子系统需求中,再由子系统需求分配到软硬件需求,再到概 要设计、详细设计, 最后通过编码实现。  在 ATS  产品 中,通常以调度人员的各个操作工作站为基础,进行划 分子系统。  常见的有计划 I编图 工作站、维护工作站、 调度工作站、派班工作站、值班工作站、网关计算机、现 地工作站等子系统。  在对分配基线进行验证时,主要 采取的手段是追溯矩阵。  追溯的目的是保证所有的需 求都能正确实现,且不存在不可追溯的内容,追溯需要 达到双向的 100%覆盖,即常说的双百覆盖。
       信号系统采取结构化的设计方法,因此对需求的 分配也是至上而下。  如,产品需求分配到子系统需求 应保证 100%,从而确保产品需求没有遗漏;其次,子系 统需求应追溯产品需求,保证没有多余的需求。  软硬 件需求、概要 I详细设计,代码同样需要遵循这个原则, 进行双百覆盖,保证产品线纵向的一致性。
       在这个过程中, 从上至下常常是一对多的关系。 比如通用的站场显示的需求,需要分配到调度工作站 子系统,也需要分配到现地工作站子系统。  在需求分 配时,则需要考虑到该条需求是否全部分配到对应的 子系统中去。
       在验证活动中,软件需求应完全满足需求,确保需 求得到满足,开发人员对此与验证人员容易达成一致。 比较有分歧的一点是,是否可以存在设计大于需求的 情况。  通常研发人员出于更全面的考虑,分析出来的 某条需求,无法向上层需求进行追溯。  然而,这样的设 计通常不被验证人员接受。  首先,多余的需求可能会 造成额外的故障;其次,可能会被认为是产品的固定附 加值:假设北京地铁获得了一个锦上添花的功能,上海 地铁在考察时,觉得该功能不错进行了采购,结果却未 获得该功能,则容易引起合同分歧。

3.2  设计实现阶段验证
       为确保设计和开发输出满足输入要求,应依据所 策划的安排对设计和开发进行验证。  验证结果及任何 必要措施的记录应予保持。  在设计阶段同样应采取追 溯的方法。
       在软件概要设计阶段,验证工作将强调:验证软件 概要设计的正确性;确认软件概要设计对软件需求覆 盖的完备性;确认软件集成测试用例作为软件概要设 计一系列测试案例的充分性。
       在完成软件概要设计后,验证人员应组织相关人 员对软件概要设计进行审查,主要审查设计方案与主 要算法的可行性和先进性,以及接口设计的性能和软件运行环境的恰当性,从而论证概要设计的正确性和 可行性;此外应对每个软件实施概要设计追溯分析,在 这项活动中,软件概要设计应追溯软件需求,软件集成 测试用例应追溯软件概要设计,从而论证软件概要设 计的完备性和可验证性。
       在软件详细设计阶段,验证工作将强调:确认软件 详细设计对软件概要设计覆盖的完备性;确认软件单 元测试用例作为软件详细设计一系列测试案例的充 分性。
       在完成软件详细设计后,验证活动分为 2 个阶段: 第 1 阶段,验证人员组织相关人员进行审查,评审软件 单元间的接口,包括共享外部数据,参数形式和传送方 式以及上下层调用关系,保证软件每个单元输入变量 和输出变量都能被明确定义;第 2 阶段,采用追溯分析 的方法保证软件详细设计到软件概要设计的追溯,分 析软件单元功能与概要设计的一致性。
       在代码实现阶段,验证工作将强调:确认软件代码 对详细设计覆盖的充分性和完备性;确认软件确认测 试用例作为软件需求一系列测试案例的充分性。
       在软件编码活动完成后,验证人员应实施验证活 动以保证代码的正确性、完备性及可用性。  首先,采用 人工走查的方法对软件的代码进行审查,组织相关人 员提出意见或缺陷;然后使用代码走查工具对代码进 行规则检查,进一步确保软件代码的正确性和规范性; 最后,通过建立软件代码与详细设计的追溯矩阵,保证 软件代码对详细设计覆盖的充分性,且所有软件代码 都能追溯软件详细设计,并且没有冗余代码。  如果以 上几种方式都可以通过,那么该代码即可发布,进行正 式的配置管理;若存在问题,则需要进行整改。
       在 ATS 系统中,较为特殊的是涉及多个公共模块。 例如,在调度工作站、现地工作站、派班工作站等都会 涉及操作日志记录、报警信息显示等这类公用模块,因 此在软件实现的时候较为合理的是开发公共模块,应 用软件通过调用公共模块实现产品功能。  因此,在进 行追溯分析时,应考虑模块应用的一致性以及模块的 追溯。

 

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

       实际上, 软件的 SIL等 级是根据功能来划分的。 ATS 系统定义为 SIL2 级则是按功能的 SIL2 等级定义。 由于 ATS 是一个庞大的信息系统,除了安全功能外,还 有许多非安全功能。  对于 SIL0  的模块, 功能测试、 接 口测试是强烈推荐,因此验证员也需要关注这些 SIL0 的模块是否进行了功能测试和接口测试。  由于 ATS 系 统软件直接参与运营活动, 因此 SIL0  模块的白盒测 试,在条件允许的情况下仍建议进行,从而保证提供给 用户高质量的产品。  由于 ATS 是 ATC的 重要组成子 系统,因此,ATS 通常会与 ATC的其他子系统有信息交 互,比如来自 CI( 计算机联锁) 的站场信息、来自 VOBC
( 车载控制器) 的车辆信息、来自 DSU( 数据库存储单 元) 的限速信息等。  ATS 必须通过与这些系统的接口 测试才能正确实现产品功能,所以系统对外的接口测 试不区分 SIL等级,都是必不可缺的。
在传统自动驾驶模式( AM) 下, ATS 的安全功能 涉及临时限速、道岔强扳和计轴复位;在全自动驾驶 模式( FAM) 下,安全功能还涉及雨雪模式、火灾联动 等。  对于这些影响行车安全的功能主程序以及逻辑 处理层,建议进行黑白盒测试,而不是仅选择欧标列 出的最低标准;对于其他非安全模块,可以根据实际 情况酌情删减,比如日志记录、报警等仅需做功能测 试和接口测试,代码走查、单元测试则需要考虑投入 的性价比。
       在 EN50128 中,将静态分析作为验证的手段,实 际上静态分析作为测试手段更为恰当。  静态分析可分 为桌前检查( 程序员自己检查)、内部走查( 测试人员 独自检 查) 和 外 部 走 查 ( 测 试 人 员 与 程 序 员 一 起 检查),选用哪种方式取决于代码量、程序的复杂程度、测 试人员对代码的理解程度。  但常见的活动是由独立研 发的白盒测试人员直接测试代码正确性,而验证人员 对比活动进行二次检查。  验证活动在本阶段主要是检 查测试的代码覆盖率、用例的执行率,测试活动的充分 性以论证产品的正确性。


3.4  变更验证
       在 V模型中,变更活动始终贯穿于产品开发的生 命周期中。  信号系统属于慢迭代稳定系统,因此对变 更的控制具有严格要求。  如果发生变更,验证活动则 需要被重复实施。  通过对需求、设计、测试活动重复进 行验证,给出审核结论,保证变更后的系统仍具有正确 性和一致性。
       在变更验证过程中,验证人员应重点关注:变更完 成是否与变更申请一致;变更是否可追溯;变更是否可 验证;变更是否测试验证通过。
       以 ATS 系统为例,在不同的工程项目中应用,通 常需要对通用产品进行特殊应用开发。  V模型的一 个重大优越性在于变更的控制,而信号系统产品生命 周期内 的 变 更 无 法 避 免, 因 此 对 变 更 的 验 证 同 样 重要。

 

4    结语
       综上所述,ATS 系统需要经过充分的验证活动,收 集足够的客观证据证明产品各个阶段的输出满足需 求。  尽管在验证活动中,验证员通常需要反复提出意 见要求整改,但是验证活动的初衷绝不是找出系统的 错误,而是搜集系统正确的证据,从而提供给产品生成 方、评估方乃至产品使用者充足的信心。  因此,验证员 所扮演的绝不是一个挑毛病的角色,而是帮助产品趋 于完善。
       本文以 ATS 系统为例 对 验 证 活 动 进 行 研 究, 对 于其他 SIL2  的信号系统, 如 冗 余 ATO( 列 车 自 动 驾 驶系统) 可参考本验证方法, SIL等 级 较 高 的 CI( 计 算机联锁) 、ATp( 列车自动保护装置) 等, 则需要更 加严格的验证活动, 从而更大限 度 地 保 证 产 品 的 正 确性。



收稿日期, 2016 07 19 修回日期, 2016 10 08
第一作者, 梁鸿煌 女 本科 系统保证工程师 专业方向为信号系统 验证与确认应用 IhysmiIe@foxmaiI.com

> > > 您还没有登录,请登陆后查看全文!!!

下一条:无
 
分享到:
友情链接
主办单位:中国土木工程学会轨道交通分会
协办单位:中国节能协会城市轨道交通节能专业委员会
中国城市轨道交通网 版权所有 CopyRight; 2003-2017 chinametro.net
京ICP证 040257-1 号
京公网安备 11010202007575号