电力现场的通信故障大多不是什么高深难题但排查起来往往能折腾掉一整天。最近一个风电场升压站的调试项目里我带着笔记本和一根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对BGND一定要接。这种方案最简单适合短距离、总线设备不多的情况但前提是调试模块必须改成只收不发。方案二是经过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-101Info列会显示帧的作用比如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帧占比异常低先回头检查解析器配置和抓包参数别在被错误解析的文件上浪费时间。这套流程我用了不少项目稳定可靠希望对你有帮助。