HMI屏报PIS通信故障为什么过一会儿又自己消失？

xzshengli

HMI屏报PIS通信故障为什么过一会儿又自己消失？

直接答案：
这类故障多数不是设备坏了，而是TMS模块接收数据包的软件判据过于简单，把本来正确的数据包当成错误数据丢弃，导致HMI收不到PIS回复状态而报通信故障。等后续数据包恰好满足判据时，通信恢复，故障现象就自动消失。

原因说明：
PIS即列车乘客信息系统，报站数据要先经MVB模块接收，再送到TMS模块存储记录，然后转发给中央控制器处理，最后控制数字报站器播放音频。TMS模块与MVB模块之间约定：数据包以标识字节FE开头、以FF结尾，总长度固定为115字节，三个条件同时满足，TMS才接收该数据并转发。

问题出在TMS原来的软件算法上。它只简单检查头尾标识和字节总长：发现第一个FE就读取第115个字节，若该字节不是FF，就把这115字节整包扔掉，再等下一个FE开头的数据。如果下一个数据包中又含有FE字节、而第115字节仍不是FF，软件继续整包丢弃，依次类推，直到碰到完全相符的数据包才转发给中央控制器。

而实际通信中，完整数据包有时少于115字节，有时多于115字节，这种情况在通信中经常遇到。于是软件会在一段时间内持续扔包，几秒、几分钟甚至十几分钟都有可能。这段时间里TMS不向HMI回复PIS状态，HMI因收不到回复就报PIS通信故障；同时中央控制器收不到有效数据，也就无法触发全自动报站广播。一旦某个数据包恰好满足FE、FF和115字节三个条件，通信立即恢复，故障便自动消失。

解决思路是优化TMS软件、重写接收数据代码：在接收程序中增加校验和。查到FE包头后，若第115字节不是FF，不再把整包115字节全部扔掉，而是继续在该115字节数据内查找FE标识符，以这个FE为新包头顺延114字节，再检查第115字节是否为FF，如此反复，直到找到正确数据。这样纠错能力更强，明显降低扔掉正确数据的概率。

现场提示：
列车网络在不同状态（离站、下一站、到站等）会给PIS发送相应状态数据包，每个状态持续3至4秒，数据包之间间隔约300毫秒，即每个状态约发送8至10个数据包。即使丢掉部分数据，修改后的程序仍能收集到正确数据，PIS只要收到其中一个正确数据就能正确播报全自动广播。

注意事项：
此类故障回库检查时，MVB模块、TMS模块、中央控制器、数字报站模块、音量调节模块的指示灯往往都显示正常，设备无异常，容易误判为偶发问题。判断时应重点下载TMS记录数据，核查数据包长度是否符合115字节的协议约定。涉及软件修改和参数调整，须以现行有效文件及现场管理要求为准。

资料来源：《列车乘客信息系统典型故障案例分析》。
说明：本文仅供学习参考；涉及规章、技术参数和现场作业要求时，以现行有效文件为准。