电力现场的通信故障，大多不是什么高深难题，但排查起来往往能折腾掉一整天。最近一个风电场升压站的调试项目里，我带着笔记本和一根USB转RS485线，用Wireshark直接挂在IEC 101总线上抓包，二十分钟就定位了困扰现场两天的通信中断问题。这篇文章就把这套方法完整记录下来，从接线、抓包到报文解析，再到几个典型案例的排查思路，给同样在现场跟IEC 101规约打交道的人做个参考。
IEC 101规约，全称是IEC 60870-5-101，在电力远动、变电站综自、风电光伏AGC/AVC这些领域用得极广。它跑在串口上，最常见的就是RS485总线、9600波特率、8数据位这种组合。这类通信出故障时，最头痛的不是协议本身，而是物理层和配置层面的问题掺杂在一起，光靠万用表量通断、串口助手看十六进制，很难快速定位。Wireshark作为协议分析工具，抓串口只是它众多能力里不起眼的一项，但恰恰是这项不起眼的能力，能把IEC 101的链路层交互过程完整呈现出来，让故障从"猜"变成"看"。
1. IEC 101规约通信基础与故障特征
1.1 IEC 101在电力远动系统中的位置
IEC 101在电力系统里的地位，有点类似Modbus在工业控制里的地位，但它的设计比Modbus更严谨，帧结构也更复杂。它定义了主站（比如调度主站、监控后台）和从站（比如RTU、保护装置、测控装置）之间在串行链路上的通信规则，包括链路层的帧格式、传输控制、应用层的ASDU（应用服务数据单元）编码规则。
从OSI模型看，IEC 101覆盖了物理层之上的链路层、应用层，甚至还包括了传输层的部分时序逻辑。它不像TCP/IP那样有明确的会话概念，而是靠链路层的一来一回、帧计数位翻转来维持通信秩序。这也是它排查起来有点门槛的原因：你不仅要看单帧内容对不对，还要看帧与帧之间的时序关系对不对。
1.2 RS485物理层与9600波特率下的调试特点
RS485是半双工差分总线，A、B两根线传输差分信号，抗共模干扰能力强，传输距离可达上千米。在9600波特率、8N1格式下，每个字节的传输时间约1.04毫秒，一个典型的固定帧长报文（10 7B 01 7C 16）大概5个字节，也就5毫秒多一点。这个速度对Wireshark来说完全没压力，时间戳精度到微秒级别，足够分析帧间间隔和超时关系。
但9600波特率也意味着单帧传输时间短、误码窗口小。现场如果总线没有加终端电阻、屏蔽层接地不良、或者USB转485模块的GND没和从站共地，干扰信号很容易在某个字节上制造一个误码。这种偶发误码在低速下表现为"偶尔一帧校验错"，如果不去抓包，光看主站界面的报错信息，会觉得网络时好时坏，非常难判断。
1.3 现场故障的三种典型表现
结合我调试过的项目，IEC 101通信故障基本可以归为三类：
第一类是"完全不通"，主站发召唤链路后没有任何回包，或者一呼一应都是乱码。这类问题通常指向物理链路、地址配置或串口参数。
第二类是"时好时坏"，抓包能看到正常报文，但时不时冒出一帧校验错的垃圾帧，或者从站有一阵子不应答。这类问题多为干扰、终端电阻、地电位差等物理层原因。
第三类是"链路通但不干活"，帧结构正常、校验和没问题，但主站就是收不到正确的数据，或者数据值明显不对。这类问题往往出在ASDU地址、信息体地址、点表映射这些应用层配置上。
把故障分类之后，排查思路就清晰了。物理层问题看波形和信号完整性，链路层问题看交互流程和帧格式，应用层问题看ASDU内容和点表。Wireshark抓包对第二类和第三类问题的帮助最大，对第一类问题也能快速排除主站侧发送是否正常。
2. 抓包前的准备：工具选型与总线接入
2.1 为什么选择Wireshark抓串口
串口调试助手这类工具只能把收到的字节流按十六进制显示，对于单帧几十个字节的IEC 101报文，肉眼扫一遍还能对付，但要分析几十轮交互、对比不同时间点的帧内容、统计误码率，就非常吃力了。
Wireshark的价值在于三个层面：首先是解析能力，它内置了IEC 60870-5-101协议解析器，能把原始字节拆成帧头、控制域、地址域、ASDU、校验和，控制域里的功能码、FCB位、ACD位也会以树形结构展开；其次是分析能力，过滤器、时间列、协议统计、导出报文，这些都是为长时抓包分析准备的；第三是保存能力，可以把抓取的数据存成pcap文件，带回办公室慢慢看，甚至发给设备厂家做技术分析。
2.2 USB转RS485模块的选择与"只收不发"改造
抓RS485总线数据，核心工具就是一个USB转RS485模块。选模块时优先挑使用FT232、CP2102这类成熟芯片方案的产品，驱动稳定，抓长时数据不容易掉线。有些山寨模块用的是CH340加MAX485的裸方案，本身没问题，但注意别选那种"自动收发切换"逻辑有缺陷的，否则模块在空闲时会一直占住发送方向，把总线拉死。
这里有个关键点：监听RS485总线时，调试模块绝不能往总线上发数据。半双工总线上如果两个设备同时发送，数据必然冲突，反而制造出新的故障。所以抓包前最好把模块改成"只收不发"。做法其实不复杂：打开模块外壳，找到485收发芯片（通常是MAX485或SP485），把DE和RE引脚短接并固定到低电平，也就是让芯片永远处于接收使能状态。有些模块预留了收发控制跳线帽，直接调到"接收"档就行。如果不想改硬件，也可以使用带监听口的RS485共享器，监听口本身就只接收不发送。
2.3 接入RS485总线的三种方案对比
接入方式要根据现场条件选，我试过三种：
方案一是直接并联。把USB转485的A、B、GND三根线并到总线上，注意A对A、B对B，GND一定要接。这种方案最简单，适合短距离、总线设备不多的情况，但前提是调试模块必须改成只收不发。
方案二是经过RS485共享器/分配器的监听口。这类设备有专门的监听输出，不影响原总线时序，适合对总线稳定性要求高的场合。缺点是现场不一定有这种设备，得提前准备。
方案三是串接电流采样，用高阻差分探头跨接在A、B线上，通过示波器或逻辑分析仪间接观察。这种方案对总线零侵入，但设备门槛高，现场调试一般不这么干。
无论用哪种方案，接入前都要确认总线上没有正在进行的通信，最好是联系运行人员或在检修窗口期操作，避免带电拔插导致设备损坏。
2.4 串口参数确认：一个容易忽略的起点
RS485通信参数不是随便填的，必须在抓包之前确认。IEC 101在串口上最常见的配置是9600波特率、8数据位、无校验或偶校验、1停止位，但不同厂家设备默认值不一样，有的保护装置默认偶校验，有的测控装置默认无校验，还有的把校验位设在停止位里面，配置错一个字段，抓出来的包就是一片乱码。
所以开工前第一件事，不是插线，而是找从站设备说明书或进设备菜单确认实际参数。主站侧也要核对，不要想当然认为"后台配置里填的就是实际值"。我遇到过不止一次，主站界面写的9600、N、8、1，但底层驱动实际初始化的是19200，这类问题不抓包根本看不出来，一抓包满屏都是校验错的帧。
3. 实战抓包：Wireshark串口捕获与解析配置
3.1 打开串口捕获接口并设置参数
Wireshark从3.0版本开始，原生支持串口捕获，无需额外插件。打开Wireshark，在主界面的接口列表里会多出一类"串口"接口，展开后能看到系统里的COM口列表。如果没有显示，检查一下驱动安装，或者查看"捕获选项"里是否能手动添加。
选中对应COM口后，点齿轮图标进入参数设置，把波特率、数据位、校验位、停止位填成刚才确认好的值。流控一般选无，因为RS485本身不依赖硬件流控。特别注意，Wireshark打开串口会独占该端口，其他串口助手、组态软件必须关闭，否则会提示打开失败。
这里有个常见坑：有些版本的Wireshark对串口抓包支持不稳定，打开后只显示"Interface went down"之类的报错。这时可以试试先把Wireshark关掉，重新插拔USB转485模块，再打开软件。如果还不行，换一个USB口，Windows下某些USB口和特定驱动组合会有兼容问题。
3.2 触发故障复现与抓取报文
串口抓包和网卡抓包不同，串口没有实时流量，总线上的数据是由主站配置的轮询周期决定的。如果不做任何操作，可能要等很久才能遇到一次异常。聪明的做法是主动制造复现条件。
比如，问题表现为"主站启动后通信一直不建立"，那就让主站软件重新启动或触发一次链路复位，把整个链路建立过程完整抓下来。如果问题表现为"每隔一段时间就断链重连"，那就先正常跑着，同时用Wireshark的"自动保存到文件"功能，按时间分片保存，抓够一两个小时再来看。
抓包期间不要频繁操作Wireshark界面，避免界面卡顿影响时间戳准确度。现场笔记本性能不够的话，可以关掉实时显示的包列表刷新，只用状态栏的包计数观察数据量是否在增长。
3.3 让Wireshark正确解析IEC 101报文
串口捕获的原始数据在Wireshark里默认显示为Data协议，因为Wireshark不知道这些字节是什么格式。这时需要手动指定解析器：选中任意一个数据帧，右键"解码为"（Decode As），在协议列表里找到"iec60870_5_101"或"IEC 60870-5-101"，确认后整份capture文件都会被按IEC 101解析。
如果没有这个选项，说明当前Wireshark版本较旧或协议模块未加载。建议升级到较新版本，协议解析器覆盖更全。还有一种情况是帧被解析成了"iec60870_5_104"，这是跑在TCP上的版本，串口数据不应该选它，选错了解析树会完全对不上。
正确解析后，包列表的协议列会显示"IEC 60870-5-101"，Info列会显示帧的作用，比如"Call data, class 2"、"Response data, class 1"这种。到这一步，抓包基本上就成功了，接下来的重点是看懂这些帧在说什么。
3.4 三个高价值过滤器和时间列设置
抓完包后，面对几百上千帧报文，用过滤器缩小范围是最基本的操作。我常用三个：
过滤器一：iec60870_5_101，只看所有被解析为IEC 101的帧，排除少量未能解析的原始数据帧。
过滤器二：frame contains 68 16，查找可变帧长帧。IEC 101的可变帧长帧以0x68开头、0x16结尾，应用层ASDU数据都包含在这里面，查看数据上送是否正常靠它。
过滤器三：iec60870_5_101.c.type == 0x0b或根据实际需要指定功能码，专门看某一类控制帧。比如只看从站的数据响应帧，统计数量是否和预期一致。
时间列是排查链路超时的利器。默认Wireshark显示的是绝对时间，建议打开"视图→时间显示格式→以相对时间显示"，把时间基准设在第一帧捕获时刻，这样你能直接看到每个报文距离起始点过去了多少毫秒。分析超时问题时，再叠加一个"增量时间"列，观察相邻两帧之间的间隔，如果主站发出请求后超过1秒才收到响应，或超时重发了好几次，问题就暴露得很直观。
4. IEC 101报文结构拆解与故障定位方法
4.1 固定帧长与可变帧长的识别
IEC 101的帧格式分两大类。固定帧长帧以0x10开头、0x16结尾，中间只有控制域和地址域和校验和，一共5个字节，典型用途是链路管理命令，比如召唤链路、复位链路、确认。可变帧长帧以0x68开头，带两个长度字节，可以承载ASDU数据，用于上送遥信、遥测、遥控回执等实际业务数据。
识别这两类帧是排查的基础。固定帧长帧结构简单，一眼能看完，链路层交互是否正常基本靠它判断。可变帧长帧才是"数据"的载体，长度字段指示了ASDU的大小。在Wireshark的解析树里，长度字段会自动关联，如果长度与实际字节数不一致，解析器会高亮报错，这一般意味着传输过程中发生了丢字节或干扰。
4.2 控制域功能码：判断主站命令与从站状态
控制域里的功能码是整个链路层交互的核心。主站发出去的帧和从站回回来的帧，功能码的含义完全不同。不需要背所有编码，但几个常用的得认识：
主站侧：0x53表示召唤链路，主站用它探测从站是否在线；0x5B或0x7B表示请求1级数据；0x5A或0x7A表示请求2级数据；0x13表示复位远方链路。
从站侧：0x03表示对召唤链路的确认响应；0x0B表示有数据响应；0x09表示无数据响应；0x00或0x80段的值表示确认。
在Wireshark的Info列里，这些含义会直接显示为英文短语，比如"Call link"、"Request data, class 1"、"Response data, class 1"、"No data"等等。排查时把主站发的一轮请求和从站的一轮响应并排看，如果主站发0x5B请求1级数据，从站回的不是0x0B而是0x09，说明从站目前没有1级数据要上送，这是正常情况；如果从站什么都不回，那就是链路或地址有问题。
4.3 地址域与ASDU公共地址：最常见的配置坑
帧格式里有两个地址概念，一个是链路层的地址域（也叫从站地址），位置在控制域后面，通常是1个字节，范围0到255；另一个是ASDU里的公共地址，位置在ASDU头部，可能占1个或2个字节。两者都要和从站设备的实际配置匹配。
从站设备一般通过拨码开关、面板按键或后台软件设置自己的通信地址。主站发送的请求帧里必须带上正确的地址，从站才会响应。如果地址不匹配，从站会直接丢弃该帧，不会给任何回包。从站在响应时，会把地址域填成自己的地址，ASDU公共地址也填成配置值，主站收到后如果发现公共地址不在本站点的数据配置表里，也会把数据丢弃。
我在现场遇到过一次很迷惑的情况：抓包看从站明明有响应，响应帧也很完整，但主站就是显示"通信中断"。后来仔细一查，从站的ASDU公共地址配置成2，主站点表里公共地址配的是1，数据全被主站拒收了。这种问题不抓包看ASDU头，光在两边界面里翻配置，真的很难发现。
4.4 从召唤链路到总召唤的完整交互流程
理解了上述字段，就能看懂IEC 101的完整交互流程了。主站启动后，先发召唤链路帧，从站回确认，链路建立。然后主站周期性地请求1级数据和2级数据，从站按顺序把变化的数据、事件、SOE等通过1级数据上送，把周期扫描的遥测、遥信通过2级数据上送。
总召唤是另一个关键环节，它是一帧应用层命令，类型标识为100，用于让从站把全量数据重新上送一遍。主站下发总召唤后，从站会连续上送大量遥信遥测，整个流程交互密集，报文数量是平时的几十倍。排查数据漏点、点表错位问题时，总召唤过程是最有价值的观察窗口。用Wireshark抓一段总召唤前后的报文，统计从站上送了哪些类型的ASDU、上送了多少个信息体，和点表一对比，问题往往就清楚了。
5. 三个真实故障案例的排查全过程
5.1 案例一：完全无响应，问题竟在从站地址
现场反馈某风电场一台箱变测控装置通信中断，主站后台报"链路超时"。我到场后先按照3.2节的方式接入RS485总线，抓包看到主站持续发送召唤链路帧，控制域0x53，帧内容完全正确，但总线上没有任何响应帧。这至少说明主站发送链路是好的，问题出在从站侧或总线分配上。
接着检查从站，发现设备面板的通信地址拨码是02，而主站后台的从站地址配置是01。主站发出去的帧地址域全是0x01，从站自然不应答。把主站后台地址改成02后，通信立即恢复。整个过程从开机到定位不到二十分钟，而现场此前的两天排查里，大家一直在怀疑RS485线缆和接口板卡的问题。
这个案例想说明的是，地址配置错误比想象中常见，而且比硬件故障更容易被忽略。抓包的价值就在于，它能把"主站到底在请求谁"这个问题用一帧报文回答得明明白白。
5.2 案例二：偶发乱码与校验错，串口参数背锅
另一个项目的调度主站与RTU通信时好时坏，抓包时看到大量"Malformed"帧和校验错帧，Wireshark能解析出的IEC 101帧只占一部分。比较奇怪的是，校验错的帧里，字节内容并非完全随机，而是呈现出一定的规律性。
我用Wireshark看原始字节流，把所有校验错的帧按字节内容排在一起对比，发现有一个共同特征：同一个报文在某些固定位置出现位错位。这种规律性错位指向了串口参数不匹配。一查RTU的实际配置，它跑的是偶校验，而调度主站配置成无校验。两个设备本身都没有"故障"，但一个以偶校验编码，一个按无校验解码，导致后者收到的数据偶尔能撞对、经常校验失败。
把主站串口参数改成偶校验后，错误帧立刻消失，通信恢复稳定。这个案例提醒我，串口参数要以设备侧实际配置为准，不能只看主站界面。Wireshark的抓包相当于把两边的"真实配置"都暴露了出来，任何一端参数不对，都会在报文里留下痕迹。
5.3 案例三：周期性断链重连，物理层干扰的定位
第三个案例比较难缠，是某水电站AGC系统与测控装置通信，正常运行几小时后会突然断链，主站发复位链路重连后又能恢复正常，如此反复。从主站报表看，断链时间没有明显规律，用户怀疑是某台装置死机。
我连续抓了12个小时的报文，用时间列分析发现，断链发生前总会出现一帧接收超时：主站发出请求后，从站当时没有响应，或者响应帧只到了前几个字节就中断了。现场检查RS485总线布线，发现通信电缆有一段和动力电缆敷设在同一个桥架里，且距离长达二十多米。第二个疑点是整条总线只在主站端加了终端电阻，从站端没有。
处理办法是调整电缆敷设路径，把通信电缆和动力电缆分开，并在总线最远端并联一个120欧终端电阻。改造后连续运行一周，未再出现断链。这个案例的教训是，偶发性问题一定要靠长时抓包确认现象，再结合物理层检查找根因。Wireshark在这里扮演的是"监工"角色，它告诉你问题确实存在、发生在什么阶段，而解决要靠现场工程师的物理层判断。
6. 现场排查速查表与避坑心得
6.1 故障现象与排查方向速查表
| 现象 | 可能原因 | 第一步排查动作 |
|---|---|---|
| 主站发召唤链路后无任何回包 | 从站地址不匹配、A/B接反、从站未上电 | 先抓包确认主站发送帧，再看物理层接线 |
| 能收到帧但大量校验错 | 波特率或校验位不一致、干扰严重 | 核对两侧串口参数，检查原始字节规律性 |
| 偶发断链，时报时通 | 终端电阻缺失、共地不良、电缆受干扰 | 长时间抓包，用相对时间列定位断链前兆 |
| 链路正常但数据不刷新 | ASDU公共地址不匹配、点表配置错 | 抓总召唤过程，核对信息体地址映射 |
| 复位后能通，一段时间又断 | 主站超时参数过短、从站忙未及时响应 | 查看断链前的帧间隔，适当调大t1/t3参数 |
6.2 六个容易忽略的现场细节
第一，USB转485模块的GND线必须接。很多人在现场图省事只接A、B两根线，结果监听设备本身的地电位和现场总线不一致，轻则抓到的包噪声大，重则共模电压过高损坏模块。三线制接线是底线。
第二，抓包时不要在Wireshark里一边抓一边做高强度过滤。串口数据量虽然不大，但长时间抓包加上复杂显示过滤器，会让低配笔记本界面卡顿，甚至丢包。
第三，保存pcap文件时记得同时保存一份原始导出txt，万一客户要求打印或邮件传输，txt格式比pcap通用得多。
第四，IEC 101的帧间间隔和超时参数，不同项目配置差异很大。主站发一帧后，如果从站忙，允许在较长时间内不应答，这不算故障。不要把"一帧没回就判定异常"，要先看主站的重发逻辑和超时门槛。
第五，现场抓包前先拍照记录总线拓扑和设备地址拨码状态。很多故障排查到最后，会发现是调试过程中有人动过拨码开关或换过设备，照片能帮你快速排除这些人为因素。
第六，抓包分析要结合从站设备的事件记录。Wireshark只能看到总线上的通信过程，无法知道从站内部发生了什么。如果从站侧有自诊断菜单或事件日志，一并调出来对照，故障分析才会完整。
结尾的一点个人体会
做串口通信调试这几年，我最大的体会是：很多看起来玄乎的通信故障，本质上都是参数、地址、物理链路这三个层面的问题，而Wireshark抓包能把这三个层面的证据一次性摆到桌面上。它不会直接告诉你"该改哪个参数"，但能把排查方向缩小到极小的范围，省掉大量盲目换硬件、重启设备的无用功。
最后再分享一个小技巧：现场环境复杂，抓到的pcap文件可能包含大量无关流量。回到办公室分析时，先别急着逐帧看，用"统计→协议分级"功能看一眼整体分布，如果IEC 101帧占比异常低，先回头检查解析器配置和抓包参数，别在被错误解析的文件上浪费时间。这套流程我用了不少项目，稳定可靠，希望对你有帮助。
