地铁车辆和信号系统显示屏融合方案研究

李春明，高春兵，杨逸凡

根据公共交通国际联会（UITP）发布的《World Metro Figures·2018》报告，全自动运行系统（fully automatic operation，FAO）将是未来城市轨道交通的主要发展方向和主流趋势［1-3］。全自动运行系统的快速发展和应用，对地铁车辆运行过程中乘客的安全防护措施提出了更高的要求，相应的规范和标准也随之陆续出台。如《地铁设计防火标准》（GB 51298—2018）中提到，行驶于地下区间的列车车头和车尾需设置紧急疏散门［4］。对于B型地铁列车（地铁列车按车辆规格分为A、B、C、D、L共5种类型）［5］，其车体宽度较A型车窄、司机室更狭小，而FAO列车较传统有人驾驶车辆，需要安装的设备和元器件数量更多［6］。因此，车头处的空间设计需更加合理、智能。

目前，应用FAO系统的苏州轨道交通6号线车辆车头处需设置4块显示屏，分别为列车控制与监测系统的司机显示单元（Driver Display Unit，DDU）、信号系统的人机界面（Man Machine Interface，MMI）、视频监控系统和机车台控制盒。若完全按照4块显示屏布置，则没有紧急疏散门的设置位置，这将大大增加运营安全风险系数［7］。为此，本文创新性地提出显示屏融合设计方案，旨在将MMI显示的信号系统信息通过特定的通信方式，融合至车辆DDU中，使司机可以直接通过DDU同时查看列车控制与监测系统和信号系统的显示信息。该方案的提出不仅提升了驾驶室空间的利用率、降低了运营成本，而且为在车头处设置紧急疏散门提供了可能，为乘客提供紧急情况下的逃生通道，对后续FAO的应用有着十分重要的借鉴指导意义。

1 融合方案

1.1 系统环境

基于信号MMI与车辆DDU融合的需求，在系统环境上做了如下配置。

1）车辆DDU硬件技术参数：12.1吋彩色液晶显示器，电容式触摸屏；4核1 GHz处理器，1 GB内存；110 V电源，额定功率5 W；1对DSUB9型MVB通信接口；2个10/100 M自适应以太网通信接口，M12-D Code母座；2路USB通信接口；1路RS-485通信接口。

2）DDU软件使用C语言编程和 Qt Creator 开发工具，在Linux操作系统上开发。这种程序框架易于扩展，允许组件编程［8］。

1.2 通信连接

考虑到信号系统与DDU之间冗余通信需求，信号系统的车载ATP同时通过以下2种方式，将需要显示的数据发送给车辆DDU显示屏：①MVB（multifunction vehicle bus）方式，ATP插箱通过通信板1、通信板2新增的MVB口，采用MVB协议将显示信息发送到车辆控制单元（vehicle control unit，VCU），然后由VCU将收到的信息显示到DDU上；② TRDP（train real-time date protocol）以太网方式，ATP插箱通过内部TRDP板卡的以太网口与DDU设备直接连接，将数据发送给DDU。通信连接方式见图1。2种通信方式互为冗余，MVB通信链路为主用，TRDP通信链路为备用。

图1 通信连接方式

1.3 软硬件修改

为实现本方案，车辆和信号系统需要对原有产品的软硬件进行修改设计。

1）硬件上，对通信板卡内部电路进行重新设计，增加MVB信息接收口、发送口、复位口和中断发送口，所增接口具备MVB通信能力。信号方面，原TRDP板卡拥有2个10/100 M自适应以太网通信接口，为双网口冗余，仅供信号内部通信使用，现将其施行内部禁用，改为直接与车辆DDU连接，实现信号与车辆DDU的冗余通信。车辆方面，原DDU的以太网口用于车辆DDU运行日志下载，现亦将其内部禁用，改为直接连接至信号的TRDP板卡。

2）软件上，同步修改相关软件，使ATP通信板与车辆VCU能够正常通信。同时车辆系统和信号系统需要共同开发基于TRDP通信协议的软件，以保障DDU能够与信号TRDP板进行数据传输。

1.4 数据传输

DDU优先采用ATP通信板卡MVB接口传输的数据进行显示，当MVB通信链路中断时，再采用TRDP板传输的数据进行显示，数据传输示意见图2。

图2 数据传输示意

ATP插箱与车辆DDU之间每200 ms向对方发送一次数据包，每个数据包长度为100 B。协议约定当超过1 s未接收到对方发送的有效报文时，就判断与对方通信中断。

1.5 界面设计

将原信号人机交互界面和车辆人机交互界面进行融合，融合后的车辆DDU人机交互界面见图3。通过显示屏底部的导航键（软按钮），可分别切换到“主界面”以及“车辆”“牵引”“制动”等界面。当DDU启动完成并进入正常运行时，系统将默认显示“主界面”内容。

图3 融合后的车辆DDU人机交互界面

融合后的DDU界面显示简洁明了，在一块显示屏上可同时显示信号交互界面与车辆交互界面。图3中数字标注1部分为车辆的车门信息以及站台门显示等，用于为司机提供车门及站台门的工作状态显示；数字标注2部分，将原本信号界面的列车运行速度信息直接通过数字显示，可将列车的运行速度实时告知司机，有利于司机对列车进行更好的控制；数字标注3部分，将原本信号界面的速度表盘重新设计，缩小了表盘的显示范围，使司机能够更加方便地看到信号推荐速度（表盘中的黄标）以及紧急制动触发速度（表盘中的红标），便于司机按照推荐速度驾驶列车，且不超过紧急制动触发速度。

2 故障场景

与原有2块屏的显示方式相比，新设计方案的应用会产生一系列新的运营场景。为避免DDU非正常显示对司机造成影响，下面探讨运营过程中可能发生的故障场景。

2.1 DDU与ATP通信异常

1）DDU与ATP主机通信闪断，DDU界面信号图标不能正常显示，并在该区域显示“ATP无信息显示”字样。

2）DDU收到的ATP数据取值超出正常范围，DDU界面相应信息状态显示“？”，并在“故障”清单显示“ATP数据错误”。

3）DDU与ATP主机通信中断，DDU界面的故障文本处显示“DDU与ATP通信故障”；其余信号系统显示区信息用“？”显示。

上述3种场景仅影响DDU界面显示，考虑到车辆在正常运行时DDU不需要进行人机交互，因此不会对列车的正常运行造成影响。当ATP系统出现故障时，将向DDU发送系统故障信息，并DDU在主界面信息栏显示。若故障影响列车正常运行，信号系统将控制列车继续运行至站台后，打开车门不关闭，等待司机上车处理；若故障导致列车无法继续运行至站台停车，则列车将在区间实施紧急制动，等待司机上车处理。

2.2 DDU与VCU通信故障

VCU与DDU通信故障时，DDU上只显示信号界面内容，而不显示车辆界面内容，相关图标显示未知。此时工作人员只能操作信号相关按钮。该场景仅影响MVB通信链路，ATP与DDU之间的通信还可采用TRDP链路，因此，ATP与DDU之间的通信不会受到影响。

2.3 DDU硬件故障

DDU显示器仅设置了一块显示屏，长期使用可能导致硬件本身故障。当DDU硬件设备发生故障时，由于没有冗余显示屏，因此DDU上的内容均无法正常显示。但因为列车在正常运行时采用的是全自动无人驾驶模式，在功能实现上不需要进行人机交互，因此，当DDU故障时，不会对列车的正常运营造成影响，列车依然可以正常运行至车站或场段停车，等待工作人员上车检修。

3 室内模拟验证

为保障融合后的DDU实时显示，运行稳定，需对传输协议、硬件接口和显示功能等进行室内模拟测试验证。本次实验室测试使用真实的FAO车载机柜、ATP软硬件、DDU软硬件，以及苏州地铁6号线线路数据和仿真环境，且充分考虑使用场景，编制了完整的测试用例。

3.1 测试环境

测试环境与真实的苏州地铁6号线软硬件环境一致（如室内外软件通信方式、车辆电路控制方式、ATP与DDU连接方式等），采用冗余的通信方式，通过车载VOBC机柜内部的TRDP板和ATP通信板与车辆DDU连接。

在工作站上搭建模拟驾驶台和TCMS仿真系统。模拟驾驶台可仿真真实车辆在线路上运行的情况［8］，为DDU界面的信号显示信息提供输入来源，其界面见图4。TCMS仿真系统可模拟车辆向信号系统发送车辆状态信息，以便信号系统对车辆进行控制。

图4 模拟驾驶台界面

3.2 测试用例执行

根据测试指导书要求，本次模拟测试共需执行199条测试用例。其中实验室可执行163条，测试通过率为100%；剩余的36条受室内测试环境无真实站台门、真实站台按钮等限制，不具备执行条件。通过分析，该36条测试用例仅是对界面显示不同设备图标的测试，对显示区显示图标的功能验证已由其他测试用例覆盖，因此不影响融合方案实施。

通过测试可知，MVB和TRDP通信链路均能正常收发信息并达到预期结果，证明本方案可行，能满足FAO系统的功能需求。部分测试用例执行情况见表1。

表1 部分测试用例执行情况

4 结语

从融合方式、故障场景和室内模拟验证3方面阐述了信号与车辆显示屏融合方案。该方案将信号数据融合至车辆DDU进行显示，提高了驾驶舱的空间利用率，为设置紧急疏散门提供了可能，为降低运营成本提供了现实的帮助［9-10］。目前该方案已完成室内仿真测试，下一阶段将在苏州地铁6号线车辆真实环境中进行现场调试，预计2024年1月调试完成并投入使用。