4、通信层排查：物理链路、协议配置与报文分析
通信层出问题，是SCADA系统里最让人头疼的。为什么？因为故障现象往往很诡异——数据时有时无，或者干脆全部卡死。我干这行十几年，处理过的通信故障少说也有上百起，今天就把我的排查套路分享给你。
4.1 物理链路：别小看那根线
很多人一上来就查软件配置，其实物理链路才是第一道坎。我见过太多案例，折腾了半天协议配置，最后发现是网线水晶头松了。
物理链路排查三步走：
- 网线：看指示灯。交换机端口灯不亮？大概率是线断了。我习惯用测线仪扫一遍，8根线全通才算完。有一次现场干扰大，换了屏蔽线立马解决问题。
- 串口：RS232/485最坑的是接线定义。2、3、5脚对不对？485的A/B线有没有接反？我建议你随身带个串口调试助手，发个0x55看回显，立马知道通不通。
- 光纤：别用眼睛看光口有没有光，那会伤眼睛。用光功率计测，接收功率在-20dBm以上才算正常。我遇到过光纤弯折半径太小导致衰减过大的情况，重新布放就好了。
我的小习惯：每次去现场，包里都备一根成品网线、一个USB转串口模块、一个光功率计。这三样东西救过我无数次场。
4.2 通信协议配置：参数对不上，神仙也救不了
物理链路通了，数据还是读不到？八成是协议配置出了问题。说白了，就是两边没对上暗号。
串口通信的参数就那么几个：波特率、数据位、校验位、停止位。两边必须完全一致。我遇到过最离谱的一次，现场工程师把波特率设成了9600，但PLC那边是19200，结果数据全是乱码。
| 参数 | 常见值 | 我的建议 |
|---|---|---|
| 波特率 | 9600、19200、115200 | 能高就别低，115200是首选 |
| 数据位 | 7、8 | 绝大多数情况用8位 |
| 校验位 | None、Even、Odd | None最省事，干扰大时用Even |
| 停止位 | 1、2 | 1位就够了，除非设备特别老 |
注意：Modbus RTU和Modbus ASCII的配置完全不同。RTU用8位数据位，ASCII用7位。搞混了，数据根本解析不出来。我曾经在项目验收时被这个问题卡了整整一天。
4.3 抓包分析：让数据说话
物理链路和协议配置都检查过了，还是不行？那就上抓包工具吧。我个人最常用的是Wireshark和串口监视器。
为什么会用到抓包？因为很多时候，设备发了数据，但上位机没收到；或者上位机发了指令，设备没响应。抓包能让你看到最原始的数据流，问题一目了然。
4.3.1 串口抓包
串口通信没有网络那么方便，但也不是没办法。我常用的方法是：
- 用串口分线器，一头接设备，一头接电脑
- 打开串口调试助手，设置好波特率等参数
- 观察接收到的数据是不是预期的报文格式
举个例子，Modbus RTU的报文长这样：
发送：01 03 00 00 00 01 84 0A
接收：01 03 02 00 01 79 85如果收到的数据全是0xFF或者0x00，那基本可以断定是物理链路或者配置问题。如果数据有变化但格式不对，那就是协议解析的问题。
4.3.2 网络抓包
以太网通信就简单多了。Wireshark打开，选择网卡，过滤条件设好，数据包就全出来了。
我常用的过滤条件：
ip.addr == 192.168.1.100——只看某个IPtcp.port == 502——Modbus TCP默认端口modbus——直接过滤Modbus协议
避坑指南：我曾经遇到一个案例，抓包看到上位机发了请求，设备也回了响应，但上位机就是显示无数据。后来发现是设备回包太快，上位机还没来得及处理下一个请求就超时了。解决办法很简单，在请求之间加个100ms的延时。
4.4 知识体系速览
下面这张图，是我自己总结的通信层排查逻辑。你照着这个顺序走，90%的问题都能定位到。
嗯，通信层排查就讲到这里。记住一个原则：先物理，再协议，最后抓包。别一上来就开Wireshark，那会把自己绕晕。我刚开始干这行时也犯过这个错，后来吃了亏才学乖的。