全自动运行系统场景验证平台及其应用

崔海刚

GoA4级全自动运行系统是高度集成化和自动化的城市轨道交通系统。全自动运行条件下,乘客服务、设备管理、列车调度等将在无人值守即全自动的条件下进行。全自动运营场景定义明确了全自动运营正常场景、降级场景、故障场景中各专业系统需要实现的功能,定义了不同专业之间的接口,明确了多职能队伍在不同场景下的应对方式。为验证全自动运行系统场景定义的正确性以及设计的合理性,本文介绍了一套全自动运行系统场景验证平台,并举例说明了如何使用这套平台对具体的运营场景进行验证。

1 全自动运行系统场景验证需求

1.1 全自动运行系统运营场景

全自动运行系统以为乘客提供经济、安全、舒适、高效的乘车服务为目的,在保证安全的前提下,实现列车的无人值守驾驶和运营调度维护的自动化和智能化。它以信号系统为核心,结合站台门系统、车站及列车的乘客信息系统（PIS/PA）、通信系统、自动售检票系统、环境与设备监控系统（BAS）、火灾报警系统和电力监控系统等,实现一系列的全自动运行功能［1］。其系统组成见图1。

图1 全自动运行系统组成

全自动运行系统在传统的有人驾驶系统基础上,对城市轨道交通若干专业提出了新的需求［2］。它可以实现列车的自动唤醒和休眠、正线列车的全自动运行、自动洗车等正常运营需求,车门和站台门故障条件下的对位隔离、车载设备故障后的降级蠕动运行等降级需求,以及列车火灾和站台火灾的系统自动处理、自动疏散等应急场景需求［3−4］。

为了明确全自动运行功能,及全自动运行项目中各专业的功能分配,目前已经开通及在建的全自动运行项目均定义了全自动运行运营场景。同时全自动运行运营场景规范的制定也在稳步推进中,如上海市交通运输协会发布了《城市轨道交通全自动运行运营场景规范》（征求意见稿）。运营场景定义对于指导后期的建设工作非常重要,为保证场景设计的合理性,有必要对运营场景进行验证。

1.2 现有城轨集成测试平台的局限性

现有的城市轨道交通集成测试平台,由于接口方式单一,建模简单,往往只能进行专业内的功能测试,运营场景的设计无法得到有效验证。例如信号系统的测试平台仅能模拟简单的列车继电输入,道岔、信号机设备的继电输入等,无法执行全自动运行系统的整体测试,以支撑全自动运行系统的场景验证,存在一定局限性［5］。

1）无法提前验证全自动运营场景。场景的设计是否合理无法在设计阶段进行验证,只能在现场调试阶段进行。在后期联调之后若发现场景设计有问题,修改的资金和时间成本都比较高昂。

2）无法在室内开展各专业集成测试。现有各专业的室内测试平台均偏重于专业内的功能测试,试验室内无法开展涉及多个专业的联调联试,无法提前验证厂家的产品功能和项目执行能力。

3）现有集成测试平台无法执行多职能队伍演练和培训。全自动运行项目对远程运维人员的要求更高,特别是应急和故障场景的应对,而现有集成测试平台不包含运营和维护人员的参与,系统功能的设计是否合理,各类运营场景下运维人员的应对无法在室内测试阶段得到验证。

1.3 全自动运行系统场景验证平台功能需求

全自动运行系统场景验证平台需要实现如下功能。

1） 支持不同专业系统的室内集成。在场景设计阶段,各专业供应商可以将其最小化的实物设备接入该平台,通过接口和功能的调试,完成各专业的初次集成。

2） 验证全自动运行系统各专业的联动场景。基于该平台,可以以多种视角执行全自动运行运营场景定义的联动功能。如全自动无人驾驶过程中列车的运行,进/出站客流和闸机联动,客流和电扶梯联动,乘客信息系统的联动等。

3）验证全自动运行系统的故障场景。验证在设备故障情况下的系统联动反应,如:列车发生故障导致区间停车超时后,信号系统、车载PIS/PA、区间机电系统的联动；再如单个闸机设备故障时,进出站客流发生的实时变化,乘客服务水平变化等。

4）验证全自动运行系统的应急场景。根据运营场景的定义,在系统预设的各种应急输入条件激活的情况下,验证各被测系统和被测设备是否能按预定义的流程正常反应,如火灾应急联动、水患应急联动、瞬时大客流下系统的全自动处理等。

5）支持多职能队伍的演练和培训。运维人员可以很直观的方式使用该系统,根据运维规程执行演练和培训,例如应急驾驶培训、车站应急事件处置流程培训等。

2 全自动运行系统场景验证平台

2.1 总体仿真和建模方法

为了更好地设计适合于全自动运营场景验证的系统,需对全自动系统的组成要素进行重新认识。从系统使用者的角度来看,城市轨道交通可以分为乘客、运营调度人员、维护人员三大类,见图2的绿色部分；支撑系统运营的设施包含车辆、站台设施、站厅层设施,以及轨道、道岔、信号机、场段、存车线、隧道风机、逃生平台等一系列基础设施设备和可控制的设备,见图2的蓝色部分；各专业供应商的被测系统,见图2的紫色部分。为了对全自动运行系统进行整体验证,需要在试验室构建完整测试体系,对室内没有的基础设施部分,即图2中定义的蓝色部分进行3D虚拟建模。

图2 全自动运行系统场景仿真建模要素

系统使用者:该部分包含客流信息和场景验证者接口两部分。客流信息可以在系统中选择设定的客流模型,如早高峰模型、平峰模型、晚高峰模型等。用客流去验证系统设计的合理性,例如列车停止时间、列车编组、站台换乘设计的合理性等。同时系统还提供了VR入口,场景验证者可以佩戴VR头盔进入全自动运行的模型世界,以乘客的视角实际体验进站、换乘和乘车；也可以以车站值班员视角体验应急场景,如夹人、夹物的应急处理,大客流的应急处理；还可以从维护人员视角操作应急抢修的流程。这样既可以在运营初期指导场景验证,还可以在系统建成后实施多职能队伍的培训。

设施层面:根据线路的土建设计构建整体3D模型。在系统中对基础设施进行3D建模,并设定控制接口。如信号系统的联锁可以实际控制3D建模世界的道岔状态、信号机状态,BAS系统可以关闭、开启3D建模世界的风机等。

1）正线线路:考虑实际线路走向,根据在建系统的轨道长度、坡度和轨道曲率数据构建正线线路。例如地铁隧道内线路建模如图3所示,土建参数和设备布置均按1∶1比例配置,最大限度接近真实。

图3 地铁隧道内线路建模

2）车辆段:对车库进行建模,包含存车库、停车列检库、试车线和洗车线等。并根据信号系统设计设置信号机,根据车辆段实际情况设置登车平台、场段信标、照明、广播和无人隔离区等。

3）列车:设置车内照明、车载信号系统、乘客信息系统、广播系统、可开关的车门和司机室门、走行系统和供电空调系统等。

4）站台设施:活动的站台门可以在收到开关门指令时打开和关闭站台门。站台端门可以与门禁系统连接。站台PIS可以显示PIS系统实时发送的列车预到站时间、运行方向等,显示应急的乘客提示信息,并可播报站台广播。站台设施还包括车站值班室,电扶梯和闸机等。

各专业控制系统:通过验证平台集成各专业的机电系统,对于不具备条件的系统采用接口模拟的方式,构建整体的全自动运行系统仿真集成环境。

2.2 全自动运行系统场景验证平台实现

2.2.1 全自动运行系统场景验证平台架构

基于既有的用于测试信号系统的仿真验证平台［6−7］,开发了全自动运行系统场景验证平台［8］,包含运维人员体系、被测系统、仿真系统、被测设备和3D虚拟建模设施5部分,如图4所示。运维人员体系代表用户,是被测系统的直接使用者；被测系统主要包含信号系统和综合监控系统两大块,该部分由参与全自动运行系统建设的供应商提供；仿真系统在被测设备和被测系统之间起到桥梁作用,是全自动运行系统场景验证平台的核心；被测设备包含各专业厂家提供的真实设备；3D虚拟建模设施包含支撑全自动运行运营场景验证的虚拟设备。

图4 全自动运行系统场景验证平台架构

仿真系统包含3层。

系统接口层:对各专业的各类接口,如信号继电接口、综合监控Modbus/P104接口等进行仿真建模。在该接口层的支持下,室内环境不具备的设备如信号机、转辙机的驱动采集信号、车辆电路的继电器信号、计轴和轨道电路采集信号等能纳入场景验证平台进行集成。

仿真模拟层:对活动设备的复杂行为建模,如车辆的机械性能、转辙机的模型等。能接近真实地模拟出如车辆复杂的牵引制动行为、道岔牵引锁闭行为、轨道交通照明、空调、电扶梯、闸机行为等,同时在此基础上还支持设备的故障注入。

外部接口层:包含真实设备接口和仿真动画接口。真实设备接口包含设备网关和PLC控制器,仿真系统通过该接口控制被测真实设备并采集其状态；3D虚拟建模设施通过仿真动画接口接入仿真系统,仿真系统将各类设备模型状态同步至3D模型,同时将客流信息传输至3D模型,3D模型据此更新基础设施状态,并将状态信息发送给仿真系统［9］。

2.2.2 全自动运行系统场景验证平台核心技术

1） 与真实设备一致的系统接口。平台使用的接口与真实设备一致,对于不具备接入真实设备的专业,可以用仿真模型替代,并在3D建模中进行展示。例如综合监控系统通过Modbus TCP/IP协议向真实PIS和仿真PIS发送列车编号、预计到站时间、到达状态、跳停信息等乘客导向信息,发送站台紧急通知等文本信息,发送音量控制信息等。真实PIS和仿真PIS反馈站台PIS屏状态、音视频状态和故障状态等。不同站台以及同一站台的不同PIS根据ID进行区分,仿真PIS再将需要显示的信息和需要播放的声音在3D建模世界的站台PIS上显示和播放。通过与真实设备一致的系统接口即可同时测试真实PIS设备及综合监控系统的站台PIS接口部分。

2） 真实的仿真设备逻辑。不同设备的仿真分为两部分:设备逻辑仿真和设备模型仿真。设备逻辑仿真按照真实设备逻辑处理输入输出信息,设备模型仿真在3D系统中对设备建模,并同步逻辑与模型的状态。例如PIS逻辑仿真既接收综合监控系统发送的列车预到站信息,也负责将该PIS屏状态反馈给综合监控系统；PIS模型仿真将列车预到站信息显示在3D系统中。验证人员可以逐一查看3D系统中PIS显示内容。在故障场景的验证中,可以设置部分站台PIS故障；在应急场景验证中,还可以下发紧急状态下的文字和语音乘客提示,如站台火灾时疏散乘客。

3） 客流信息的引入使联调联试更贴近于真实运营环境。平台建立了入站客流、站台等待客流、乘车客流等信息,并将客流与仿真设备的模型建立联动关系。例如引入客流信息后,入站排队客流、站内等待客流会随闸机的开合发生实时变化,站台等待客流信息又可以随列车到站发车发生实时变化,客流、列车运行、闸机等内容就联动了起来。客流的引入可以验证闸机类型、数量的设置是否合理,客流与站台长度、列车行车间隔的匹配等,相比于纯设备之间的联调联试,能发现更多场景设计上的问题。

2.3 全自动运行系统场景验证流程举例

以车载控制器故障导致区间运行阻塞的应急场景为例［10］,说明场景验证平台的验证方法,其过程如下。

1） 初始状态:启动系统,佩戴VR头盔的演示人员以乘客身份进入虚拟环境,列车运行至站台正常开关门,乘客上车。

2） 注入故障:在列车运行至区间后,通过平台在后台注入一个车载控制器故障,列车在区间故障停车。

3） 全自动运行系统触发各专业联动:根据运营场景的定义,区间停车超时需要触发设备联动,包括安抚乘客的PIS信息显示和列车广播信息、保证隧道内通风条件的送风风机启动、车辆通风模式的空调启动等。佩戴VR设备的乘客可以在虚拟系统中体验到相关功能,按照运营场景定义的全自动联动流程一一确认联动功能是否正常。区间停车超时联动场景见图5。

图5 区间停车超时联动场景

4） 场景验证的反向互动反馈:演示场景的乘客可以在车内行走,通过触发远程紧急对讲与控制中心通信系统联动,以验证通信系统接口。

5） 车载远程故障恢复:中心调度人员通过远程控制车载控制器重启,故障恢复。

6） 列车进入远程限制驾驶模式:中心调度人员通过远程控制授权列车进入远程限制驾驶模式。

7） 列车恢复正常运行:在限制人工驾驶模式下重新完成定位后,列车恢复全自动无人驾驶模式,并在下一站精确停车。

3 总结

近些年来,多个大城市均在开展全自动运行项目的建设,各地也都在兴建用于全自动运行系统测试和人员培训的试验室。本文介绍的全自动运行系统场景验证平台可以在全自动运行系统建设的初期完善和优化场景设计,指导功能的开发,并用于各专业系统的集成,进而很好地支撑全自动运行系统的建设。在全自动运行系统建成后,该平台还可以用于各专业系统的迭代测试和运维人员培训。目前该平台基于上海地铁10号线全自动运行线路,完成了系统的建设和场景的推演,并在上海地铁15、18号线,成都地铁9号线等全自动运行线路建设中进行了场景验证及系统集成测试的应用,并计划在后续参建的一系列全自动运行线路中继续发挥更大作用。