1、系统主要设备
监控管理层主要设备：服务器、交换机、通信前置机、工作站
控制层设备：大型PLC、远程IO、交换机
管理层和控制层之间的通信协议：modbus tcp
2、系统网络结构
控制层通过PLC将数据上传到管理层的通信前置机，管理层将数据处理后存储并显示。
3、问题现象
在管理层工作站报警记录中控制层某些远程IO站点会无规律的出现短暂的掉站报警。
4、故障分析过程
· 第一次故障分析
出现这种故障后首先怀疑的是控制层交换机组成的环网，到现场看了一下控制层交换机的日志记录，发现环网中大部分交换机的环网端口存在短时间内的'link up'、'link down'状态切换。
但由于之前系统并没有对控制层交换机校时，这种现象发生的时间和管理层报警时间无法对应，所以参考意义不大。
虽然在管理层工作站看到了相关报警，但到目前为止，还没有确切的证据证明故障源就在控制层的设备，所以需要对故障进行捕捉记录，分析故障源位置。
· 故障捕捉部署
首先，在控制层内设置交换机校时功能，确保在故障发生时交换机产生的日志有参考意义。
其次，在PLC中添加故障点位记录程序，当相关点位为报警状态时，记录报警次数和报警时间，可以和管理层报警记录对比。
再次，在控制层的维护工作站上，添加相关点位的报警功能，辅助报警对比。
最后，在管理层通信前置机上打开通信报文记录功能，记录和控制层通信的所有报文，以便在发生报警时进行对比分析。
· 故障捕捉结果分析
经过2天时间记录，又有几次此类报警发生，到现场核对相关记录，发现，控制层交换机、PLC、控制层维护工作站均无此故障记录。
由此可以基本确定，问题存在于管理层于控制层的通信上，通过通信前置机的报文分析，发现报文确实存在问题。
问题1、前置机向PLC发送请求后未收到响应，重复3次无响应后，进行了下一包数据的请求，但这时连续收到了上面4次请求的响应数据。这说明，管理层和控制层之间存在较大的网络延时，在这种控制系统中属于不正常状态。
问题2、通信前置机向PLC发送的请求报文中，事务处理标识符没有变化，网络延时同时收到4包回复数据，导致数据错乱。
问题3、在这两天的记录中控制层交换机没再出现'link up'、'link down'状态切换问题，初步判断是调试时由于人为操作或设备掉的造成的问题，此问题暂不处理，待后续观察。
5、解决问题
第一步，解决问题2中报文事务处理标识符的问题，确保数据正确。
第二部，检查管理层交换机，查找网络延时问题，确保数据的实时性。
6、其它启发
1、多交流讨论，广大网友可以提供新思路。
2、大型控制系统的时间同步，并非都如电力输送系统那么高的精度要求，甚至不是业务逻辑上的需求。但系统内时间同步是非常必要的，至少在查看系统、设备故障日志时，对排查故障提供极大的方便。
过年了，祝大家新年快乐！
閱讀更多 工控野人 的文章
