针对车载PIS系统通信故障的优化处理建议

针对车载 PIS系统通信故障的优化处理建议

谢海丹 张祖简

南宁轨道交通集团有限责任公司运营分公司 广西南宁 530001

摘要：某地铁公司试运营初期电客车车载显示屏频报PIS通讯故障，后续调查故障原因为车载PIS系统数据处理模块软件逻辑存在缺陷导致，通过对此问题的分析，对车载PIS系统数据处理模块软件逻辑给出优化处理建议。

关键词：车载PIS系统；TCMS模块；软件；缺陷；建议

1. 引言

随着国内城市建设的大规模发展，城市轨道交通已成为公共交通的重要组成部分，城市轨道交通电客车作为乘客运输的载体，直接面向乘客，其良好的服务对树立地铁公司的良好企业形象有着非常重要的意义。而车载PIS系统为乘客提供语音报站等服务，其设施的好坏直接影响电客车的运营服务质量。本文针对某地铁公司试运营初期，电客车在正线运营时车载显示屏不时上报“PIS通讯故障”的问题，分析故障原因并给出了优化处理建议，以保证车载PIS系统的稳定和有效运行。

2. 故障现象及原因分析

2.1故障现象

某地铁公司试运营初期，电客车在正线运营时车载显示屏不时上报“PIS通讯故障”，同时全列车没有报站广播，一段时间后故障自动消失。

2.2 故障原因分析

2.2.1 列车广播系统原理

车载乘客信息系统（PIS）与信号系统（ATC）、列车网络系统（TCMS）的联系如下图所示：

图1 列车三大系统联系图

电客车广播有3种广播模式，一种为全自动广播，列车广播系统完全接收来自信号系统（ATC）的触发信号及站点信息实现广播报站，另外两种分别是半自动广播与手动广播，这两种广播均直接接收来自列车网络系统（TCMS）的信号实现广播报站。列车在正线上运行时优先采用全自动广播报站，只有在全自动广播故障时，才允许切换至半自动或手动广播实现报站。

乘客信息系统的报站流程如下图所示：

图2 全自动广播报站流程图

PIS系统通过ATC数据接口模块接收信号系统（ATC）发送的站点及触发信号等信息，ATC数据接口模块将数据传送到数据处理模块，数据处理模块做存储记录后转发给PIS系统的控制模块，控制器模块做综合分析处理后，控制广播报站相关模块播放音频文件，最终经客室扬声器传输至乘客。

2.2.2 故障原因分析

列车回库后检查与报站相关的设备均未发现异常。下载数据处理模块记录的数据分析，发现完整的数据包有时少于115字节，有时多余115字节。

在PIS系统中，数据处理模块与MVB模块之间建立通讯联系的协议为：

FE+数据（……）+FF，总计115字节。

数据处理模块通讯协议包头为标识字节FE，包尾为标识字节FF，数据长度恒定（总长115字节），只有同时满足这三个条件，数据处理模块才会接收该正确的数据，然后将数据发送给车载PIS系统控制模块处理后实现报站。然而通过数据分析，发现完整的数据包有时少于115字节，有时多余115字节，这种情况在通讯中经常会遇到。但该地铁公司电客车数据处理模块采用的软件算法是只简单的考虑头尾标识字节FE、FF以及字节总长，只有头尾标识分别为FE、FF并且字节长度总长为115字节，数据处理模块软件才会接受ATC数据接口模块发送过来的数据包；当软件发现第一个包头为FE的数据，软件就会读取该数据包第115个字节看是否为FF，若不是，TMS软件就会将这115字节的数据包悉数扔掉，再继续等待下一个以FE开头的数据，然而，如果下一个数据中也含有FE字节而第115个字节又不是FF，软件就会继续扔掉该数据包，依次类推，一直到完全相符的数据，数据处理模块才会将数据发给车载PIS系统控制模块。由于软件采用这种简单的算法，即便每个状态都发送多个数据包，PIS系统还是会出现持续扔掉数据包的情况，这种情况会存在一段时间，几秒、几分钟甚至十几分钟都有可能，产生的结果是数据处理模块不会回复PIS状态给车载显示屏，导致车载显示屏因收不到PIS回复状态信号而报PIS通信故障以及数据处理模块接收不到有效的数据包而没有数据发给车载PIS系统控制模块触发列车报站广播，导致无报站广播情况发生。

3. 问题及建议

通过分析本次事件的直接原因为车载PIS系统数据处理模块软件算法过于简单导致数据持续丢包最终电客车车载显示屏上报“PIS通讯故障”且无报站广播，为此，提出优化数据处理模块软件的建议如下：

在原来接收数据的程序中增加校验和，如果数据处理模块查找到包头为标识符FE的数据包，软件会查看第115个字节是否为FF，若不是，软件不会将这个包含115字节的数据包全部扔掉，而是继续读取该115字节的数据里面的FE标识符，并以这个FE为包头，顺延114个字节，检查第115个字节是否为FF，这样一直持续，直到在每一个数据包里找到正确的数据。

优化后的软件具有更强的纠错能力，能明显降低因程序问题而扔掉正确的数据的概率，因为车辆网络在不同状态（比如离站、下一站，到站等状态）时，列车网络系统会给PIS系统发送相应状态的数据包，每个状态持续3～4秒，而每个数据包之间时间间隔300ms，即每个状态发送数据包的数量约为8～10个，每个数据包内包含了很多字节，即使列车扔掉一些数据或数据包，修改后的程序也还能收集到正确的数据，而PIS系统只要接收到其中的一个正确数据就能正确播报全自动广播，如此就提高了通讯的可靠性。优化后的程序比原来程序具备更高的纠错能力，并且降低了扔掉正确数据的概率。

地铁公司采用该措施优化车载PIS系统数据处理模块软件后，后期运营未再出现车载显示屏频报“PIS通讯故障”以及无报站广播的问题。

4. 结论

本文通过对列车正线车载显示屏不时上报“PIS通讯故障”的问题进行分析并提出相应的优化处理措施，对同行地铁公司具有一定的指导意义。

参考文献

[1] 陈静，秦孝峰.西安地铁二号线列车广播系统故障分析及解决措施[J].陕西：轨道 交通装备与技术， 2014.

[2] 周方俊. 地铁列车国产化PIS系统通信可靠性研究. 铁道机车车辆工人, 2010, (03).