《针对车载PIS系统通信故障的优化处理建议》由会员分享，可在线阅读，更多相关《针对车载PIS系统通信故障的优化处理建议（4页珍藏版）》请在金锄头文库上搜索。
1、针对车载PIS系统通信故障的优化处理_rJ建议摘要：某地铁公司试运营初期电客车车载显示屏频报 PIS 通讯故障，后续调 查故障原因为车载 PIS 系统数据处理模块软件逻辑存在缺陷导致，通过对此问题 的分析，对车载 PIS 系统数据处理模块软件逻辑给出优化处理建议。关键词：车载PIS系统；TCMS模块；软件；缺陷；建议1.引言随着国内城市建设的大规模发展，城市轨道交通已成为公共交通的重要组成 部分，城市轨道交通电客车作为乘客运输的载体，直接面向乘客，其良好的服务 对树立地铁公司的良好企业形象有着非常重要的意义。而车载PIS系统为乘客提 供语音报站等服务，其设施的好坏直接影响电客车的运营服务质量。
2、本文针对某 地铁公司试运营初期，电客车在正线运营时车载显示屏不时上报“ PIS通讯故障” 的问题，分析故障原因并给出了优化处理建议，以保证车载PIS系统的稳定和有 效运行。1.故障现象及原因分析2.1 故障现象某地铁公司试运营初期，电客车在正线运营时车载显示屏不时上报“PIS通 讯故障”，同时全列车没有报站广播，一段时间后故障自动消失。2.2 故障原因分析2.2.1 列车广播系统原理车载乘客信息系统（PIS）与信号系统（ATC）、列车网络系统（TCMS）的联系如下图所示：图 1 列车三大系统联系图电客车广播有 3 种广播模式，一种为全自动广播，列车广播系统完全接收来 自信号系统（ATC ）的触
3、发信号及站点信息实现广播报站，另外两种分别是半自 动广播与手动广播，这两种广播均直接接收来自列车网络系统（TCMS）的信号实 现广播报站。列车在正线上运行时优先采用全自动广播报站，只有在全自动广播 故障时，才允许切换至半自动或手动广播实现报站。乘客信息系统的报站流程如下图所示：PIS系统通过ATC数据接口模块接收信号系统（ATC）发送的站点及触发信号 等信息，ATC数据接口模块将数据传送到数据处理模块，数据处理模块做存储记 录后转发给 PIS 系统的控制模块，控制器模块做综合分析处理后，控制广播报站 相关模块播放音频文件，最终经客室扬声器传输至乘客。2.2.2 故障原因分析列车回库后检查与报站
4、相关的设备均未发现异常。下载数据处理模块记录的 数据分析，发现完整的数据包有时少于 115 字节，有时多余 115 字节。在 PIS 系统中，数据处理模块与 MVB 模块之间建立通讯联系的协议为：FE+数据（）+FF,总计115字节。数据处理模块通讯协议包头为标识字节FE,包尾为标识字节FF，数据长度 恒定（总长115字节）,只有同时满足这三个条件,数据处理模块才会接收该正 确的数据,然后将数据发送给车载 PIS 系统控制模块处理后实现报站。然而通过 数据分析,发现完整的数据包有时少于1 15字节,有时多余1 15字节,这种情况 在通讯中经常会遇到。但该地铁公司电客车数据处理模块采用的软件算法
5、是只简 单的考虑头尾标识字节FE、FF以及字节总长，只有头尾标识分别为FE、FF并且 字节长度总长为115字节，数据处理模块软件才会接受ATC数据接口模块发送过 来的数据包；当软件发现第一个包头为FE的数据，软件就会读取该数据包第115 个字节看是否为FF，若不是，TMS软件就会将这115字节的数据包悉数扔掉，再 继续等待下一个以FE开头的数据，然而，如果下一个数据中也含有FE字节而第 115个字节又不是FF,软件就会继续扔掉该数据包，依次类推，一直到完全相符 的数据，数据处理模块才会将数据发给车载PIS系统控制模块。由于软件采用这 种简单的算法，即便每个状态都发送多个数据包，PIS系统还是会
6、出现持续扔掉 数据包的情况，这种情况会存在一段时间，几秒、几分钟甚至十几分钟都有可能， 产生的结果是数据处理模块不会回复PIS状态给车载显示屏，导致车载显示屏因 收不到PIS回复状态信号而报PIS通信故障以及数据处理模块接收不到有效的数 据包而没有数据发给车载PIS系统控制模块触发列车报站广播，导致无报站广播 情况发生。1.问题及建议通过分析本次事件的直接原因为车载PIS系统数据处理模块软件算法过于简 单导致数据持续丢包最终电客车车载显示屏上报“PIS通讯故障”且无报站广播, 为此，提出优化数据处理模块软件的建议如下：在原来接收数据的程序中增加校验和，如果数据处理模块查找到包头为标识 符FE的
7、数据包，软件会查看第115个字节是否为FF,若不是，软件不会将这个 包含115字节的数据包全部扔掉，而是继续读取该115字节的数据里面的FE标 识符，并以这个FE为包头，顺延114个字节，检查第115个字节是否为FF，这 样一直持续，直到在每一个数据包里找到正确的数据。优化后的软件具有更强的纠错能力，能明显降低因程序问题而扔掉正确的数 据的概率，因为车辆网络在不同状态（比如离站、下一站，到站等状态）时，列 车网络系统会给PIS系统发送相应状态的数据包，每个状态持续34秒，而每 个数据包之间时间间隔300ms，即每个状态发送数据包的数量约为810个，每 个数据包内包含了很多字节，即使列车扔掉一些
8、数据或数据包，修改后的程序也 还能收集到正确的数据，而PIS系统只要接收到其中的一个正确数据就能正确播 报全自动广播，如此就提高了通讯的可靠性。优化后的程序比原来程序具备更高 的纠错能力，并且降低了扔掉正确数据的概率。地铁公司采用该措施优化车载PIS系统数据处理模块软件后，后期运营未再 出现车载显示屏频报“PIS通讯故障”以及无报站广播的问题。1.结论本文通过对列车正线车载显示屏不时上报“PIS通讯故障”的问题进行分析 并提出相应的优化处理措施，对同行地铁公司具有一定的指导意义。参考文献1 陈静，秦孝峰西安地铁二号线列车广播系统故障分析及解决措施J. 陕西：轨道 交通装备与技术， 2014.2 周方俊.地铁列车国产化PIS系统通信可靠性研究.铁道机车车辆工人, 2010, (03).
