IEC 104测试工具实战：协议解析、参数配置与自动化调试

简介：面向电力系统自动化与设备调试场景，工具包提供了一个基于C#开发的IEC104协议客户端测试软件，解决了同类工具操作繁琐、报文解析不直观的问题。软件支持客户端报文实时显示与逐字段解释，可同步解析遥测、遥信、遥控、对时及SOE事件，并能按需调整规约格式，适用于协议联调、功能验证和学习研究。压缩包共包含13个文件，总体积约2.17MB，内有可执行主程序、运行所需的动态链接库、Excel格式的参数模板与数据文件、XML配置、文本说明等，结构简洁，便于直接运行和参数二次调整。工具还具备参数在线修改与系数设置、等量及增量赋值、语音报警、参数导入导出等实用功能，明显提升了测试效率与便利性。截至目前已有6657人学习下载，适合电力行业技术人员、协议开发者和测试工程师参考使用。需要留意的是，软件未附带使用说明书，需使用者具备一定的协议基础自行探索，且仅限非商业用途。

1. 为什么说iec104测试工具是电力自动化调试的便携弹药库

iec104测试工具.zip，这个看起来平平无奇的压缩包，在电力远动和变电站自动化调试圈子里，相当于一把随身的“协议万用表”。它通常以防安装形式分发：解压即用，不需要注册系统服务、不需要装数据库，在Windows或Linux上直接模拟主站或从站，把IEC 60870-5-104链路里的握手、总召、遥信遥测遥控，一条条报文摆到桌面上。搞变电站自动化、配网终端验收、新能源场站远动调试的工程师，现场最需要的就是这样一个便携工具。这篇笔记把整个工具链拆开讲：协议该抓哪几块、参数怎么配、脚本怎么写、坑在哪。

2. IEC 104协议测试前先背下三张表：帧类型、ASDU类型和超时参数

上手测IEC 104之前，很多人容易犯一个方向性错误：上来就抓包，看到一串68 04 07 00 00 00就以为链路通了，实际上后续的业务数据帧根本没跑对。IEC 104不像HTTP那样请求响应一一对应，也不像Modbus那样问什么答什么，它是一套带序号、带传输原因、带公共地址的异步规约。测试工具能不能派上用场，取决于你对协议本身有没有建立一张清晰的地图。

这一章把最核心的三块内容先立住：帧类型、ASDU类型、超时参数。这三块是整个测试工具配置和报文解读的地基。

2.1 帧类型与APCI：U帧、S帧、I帧分别负责什么

IEC 104的所有报文都遵循同一个APDU外壳：启动符68 + 长度 + 控制域(4字节) + 可选ASDU。控制域决定了这个帧是U帧、S帧还是I帧，三种帧的职责完全不同，测试工具配置错了帧类型，对端会直接丢弃。

用表说话：

工程上最容易出问题的点是：把U帧当成可以随便发的控制命令。实际上U帧只有三种：TESTFR（测试链路）、STARTDT（启动数据传输）、STOPDT（停止数据传输），各自带激活和确认两种形态。你要让从站主动上送数据，必须先发STARTDT激活，从站回STARTDT确认，之后才能发I帧承载业务数据。很多测试工具默认不做这一步，结果就是工具显示“连接已建立”，但底下没有任何数据流动，这就是典型的链路握手没走完。

2.2 ASDU类型分类：遥信、遥测、遥控和总召的类型号别记混

ASDU（应用服务数据单元）是IEC 104真正承载工业数据的部分，APCI只是外壳。ASDU里的第一个字节是类型标识（TypeID），这个字节决定后面怎么解析数据体。测试工具如果解析对不上TypeID，轻则显示乱码，重则把遥信值解析成遥测值，整个测试结论都是错的。

常用类型号需要形成条件反射：

调试中最常见的误解是把类型45当成两个东西——实际上45在报文方向不同时语义不同：主站发下来是遥控，从站上送是带时标的遥信，工具在解析时必须根据传输方向区分。

2.3 t0/t1/t2超时参数和k/w窗口的工程意义

IEC 104在全球变电站里跑了这么多年，靠的是一套严格的超时和窗口机制。测试工具界面上的t0、t1、t2、k、w五个参数，不是摆好看的，它们决定链路在异常情况下多久能被发现、重发多少次算超时。

常规取值如下：

实际测试中，有一类翻车非常隐蔽：主站和从站的t0取值不一致，主站设30秒，从站设10秒，链路空闲时没问题，一旦网络抖动超过10秒，从站先断开，主站还认为连接正常，等下一个总召命令发过去才发现链路已经凉了。工具在测试前必须能把五个参数一并下发，而且要和现场实际的调度主站参数对齐，不要用默认值硬跑。

3. 把iec104测试工具.zip解压跑通的最小配置：五个参数一个都不能错

拿到一个zip打包的IEC 104测试工具，第一步不是连设备，而是把工具本身跑干净。现场我见过太多人在这一步栽跟头：双加没反应、连不上、启动报错、抓不到包，最后发现全是环境或配置问题，跟协议本身一点关系都没有。

这一章按照实际操作的顺序来：解压环境检查、通信参数配置、链路参数配置、回环自测。

3.1 解压后先检查运行环境：Java版本、VC运行库和端口占用

zip形式的免安装工具，依赖的是宿主系统里已有的运行库。最常见的坑有三个：一是工具基于Java开发，但现场机器只装了JRE 8，工具需要JDK 17的特性直接报类版本错误；二是Windows下缺少VC++运行库，exe双击后进程一闪而过，连日志都不留；三是端口被占用，工具默认监听2404端口，但机器上已经跑了一个旧版本的调试程序，端口自然起不来。

建议按这个顺序检查：

# 1. 看Java版本，注意不是看装了没有，而是看大版本号 java -version # 2. 检查2404端口是否被占用 netstat -ano | findstr 2404 # 3. 看进程启动后是否存活 tasklist | findstr iec104

对应地，Java版本不符就装对应的JRE并配好JAVA_HOME；VC运行库缺失就装对应架构的vc_redist；端口被占用就找到占用进程PID，确认不是系统进程后杀掉，或者把测试工具的监听端口改到2405之类的空闲端口。有一点要提醒：不要因为图省事把监听端口改掉，然后直接连现场设备——现场调度主站就是固定连2404，你改了自己监听方便，但现场联调对方不改，这才是真麻烦。

3.2 五个核心通信参数：本地IP、对端IP、端口、公共地址CA、站地址

大多数IEC 104测试工具，无论是图形界面还是配置文件，核心参数只有五个。我们以常见的config配置文件为例，一般长这样：

[network] local_ip=192.168.1.100 remote_ip=192.168.1.200 remote_port=2404 [asdu] common_address=1 station_address=0

逐一说明参数含义：

local_ip是工具本机绑定的网卡地址。现场笔记本电脑经常有线和无线同时在线，如果绑错网卡，报文从错误的物理口发出去，抓包抓了半天发现根本不在链路上。remote_ip是对端设备地址，注意这里不是广播地址也不是组播地址，IEC 104就是纯TCP单播。remote_port默认2404，除非对端特殊配置，否则不要改。common_address是公共地址CA，它对应的是RTU或变电站的地址，不是设备内部某个点的地址。station_address在协议里不是一个独立字段，很多工具用它来推导信息体地址的信息体地址区间，配错会导致后面所有IOA偏移错位。

这五个参数里，CA最容易被当成“站号”填一个很大的数，实际常用取值范围是1到65535，很多现场的设备地址就是1、2、3这种小数字。填错了连接照样建立，但总召上去后对端根本不认你这个公共地址，数据一条都不会回。

3.3 链路参数与总召节奏：t0/t1/t2、k/w、总召间隔怎么设

通信参数保证能连上，链路参数保证连得稳。工具的链路参数设置界面一般长这样，按上一章的参数表对齐到现场即可：

[link] t0=30 t1=15 t2=10 k=12 w=8 [cycle] interrogation_interval=60

interrogation_interval是总召间隔，单位秒，这个参数非常关键。IEC 104的从站不会主动把所有数据推给主站，常规做法是主站周期性发总召命令，从站把全部数据扫一遍上送；两次总召之间的变化数据靠从站主动上报。测试工具扮演主站时，总召间隔设太短，比如1秒一次，从站会被刷爆，CPU占用拉满，正常数据反而上送不及时；设太长，比如300秒一次，现场变化信号不能及时看到，测试效率极低。

我的常用做法是：链路连通性验证阶段用10到15秒间隔，看链路稳定；完整数据采集阶段再用60秒间隔跑一个完整周期。工具如果支持把总召条件和间隔分开配，务必确认“启动后立即总召一次”这个选项勾上，不要等第一个周期结束才发总召。

3.4 先用回环地址自测：不接现场设备也能验证协议栈

跑通工具最稳妥的办法，是先用127.0.0.1地址做回环自测。把工具配成主站模式监听本机2404端口，再用另一个实例配成从站模式也监听本机2404端口，两个实例通过回环地址互连。这样做的好处是隔离了网络物理通路、防火墙、对端设备配置等干扰变量，只要自测能通，工具本身的协议栈就是好的，后面连设备出问题就能把排查范围缩小到对端和网络。

自测通过的标准有三条：

1. 主站能收到STARTDT确认，不再反复重发启动帧
2. 总召发出后能收到类型100的激活确认，之后再收到一批类型1、9、13的遥信遥测帧
3. 变化数据能实时上送，在从站端手动翻转一个遥信点，主站1秒内能看到对应报文

如果上面三条都过，工具侧就没有遗留问题，接下来所有精力都可以放到现场链路和对端设备上。

4. 自己写一个最小IEC 104主站脚本：报文构造、总召下发与回包解析

工具用顺手之后，你会发现一个现实问题：商用工具和开源工具的界面封装得太好，你点个按钮它就发报文，但报文长什么样、什么时候发、超时了怎么重发，全是黑匣子。做协议测试的人，手里必须有一套自己能完全控制的脚本，这样遇到工具本身解析不了的特殊帧，你才能手动构造、手动验证。

这一章用Python写一个最小可用的IEC 104主站脚本，覆盖连接、启动、总召、收包四步。

4.1 建立TCP连接并发送STARTDT激活帧

python # -*- coding: utf-8 -*- # demo_104_master.py # 最小IEC 104主站：连接、STARTDT激活、总召、打印响应 import socket import struct import time def startdt_activate(): """U帧 STARTDT激活，控制域=0x07""" return bytes.fromhex('68 04 07 00 00 00') def build_total_call(common_addr: int): """构造总召C_IC_NA_1 I帧报文。 ASDU结构: 类型100 + VSQ=0x01 + COT=0x06(激活) + CA(2字节) + IOA(3字节) + QOI=0x14 """ asdu_type = 0x64 # C_IC_NA_1 vsq = 0x01 # 一个信息对象 cot = 0x06 # 激活 # 用小端拼公共地址CA ca_low = common_addr & 0xFF ca_high = (common_addr >> 8) & 0xFF # IOA=0x000000, QOI=0x14 表示全局总召 asdu = bytes([asdu_type, vsq, cot, 0x00, ca_low, ca_high, 0x00, 0x00, 0x00, 0x14]) # APCI: 68 0E 02 00 00 00, 长度0x0E=4字节控制域+10字节ASDU frame = bytes.fromhex('68 0e 02 00 00 00') + asdu return frame sock = socket.create_connection(('127.0.0.1', 2404), timeout=5) # 第一步：发送STARTDT激活 sock.sendall(startdt_activate()) # 第二步：等待STARTDT确认(U帧确认, 控制域=0x0B) resp = sock.recv(1024) print('STARTDT响应:', resp.hex())

这段代码的要点是U帧控制域的硬编码。68 04 07 00 00 00里的长度04表示后面只有4字节控制域，控制域07高三位清零、低四位表示STARTDT激活，对端必须回68 04 0B 00 00 00才表示确认。控制域写错一个字节，对端不会回任何东西，TCP连接是通的，但协议层面不认你。

4.2 构造总召报文并发送

STARTDT激活确认之后，紧跟着发总召。总召属于I帧，承载ASDU数据，报文构造的逻辑在上面代码的build_total_call函数里已经体现。重点讲几个关键字段：

0x64是类型100，对应C_IC_NA_1。VSQ=0x01表示这一个ASDU里只有一个信息对象。COT=0x06是“激活”语义，表示这是主站发起命令；从站回的第一帧应该是COT=0x07（激活确认），之后才是COT=0x14（对总召的响应），这个顺序错了说明总召流程没走对。CA是公共地址，要和对端配置一致。IOA=0x00在这里不是随便写的，全局总召的要求就是信息体地址从0开始，从站才会全量扫描，写错了从站只会扫个别区间。QOI=0x14是召唤限定词，表示“全局总召”，只有这个值才会触发全数据扫描，其他值比如0x15是子站总召，行为完全不同。

发送完总召后，最好把读socket超时设置成3到5秒，避免对端没响应时脚本卡死：

# 第三步：发送总召并收取响应 sock.settimeout(5) sock.sendall(build_total_call(common_addr=1)) data = sock.recv(4096) print('总召响应帧:', data.hex())

这段代码里的timeout=5不是乱拍的。IEC 104的t1参数默认15秒，发送后等确认的窗口就是15秒，测试场景下把等待窗口压到5秒是为了快速暴露问题：如果5秒内对端还没有任何响应，基本可以判断要么CA配错、要么QOI不对、要么从站没进入运行状态，没必要傻等15秒。

4.3 解析回包：ASDU类型、COT和遥信数据体

收到回包后，需要按APCI和ASDU两层拆开看。第一层确认长度字段是否与实际一致，避免粘包或半包；第二层逐字节解析ASDU。

def parse_frame(data: bytes): """解析一个APDU帧的关键字段，仅用于调试""" if len(data) < 6: print('帧长不足，当前长度:', len(data)) return length = data[1] if length != len(data) - 2: print(f'警告：长度字段{length}与实际长度{len(data)-2}不一致') return # 控制域4字节, 后面就是ASDU asdu = data[6:] if not asdu: print('纯控制帧，无业务数据') return type_id = asdu[0] cot = asdu[2] # 传输原因低字节 ca = struct.unpack('<H', asdu[4:6])[0] print(f'类型={type_id}(0x{type_id:02x}) 传输原因={cot} 公共地址={ca}') # 读取过程中注意处理多帧情况，简单场景直接recv一次 try: frame = sock.recv(4096) parse_frame(frame) finally: sock.close()

解析这一步最容易忽略的是多帧问题。从站响应总召时，数据量大，一帧装不下，会分成多帧连续发送，每帧都是独立的APDU，但TCP读取时可能一次recv就收到好几帧，也可能一帧分两次才收完。测试脚本里不能假设一次recv对应一帧，正确做法是循环读取，用长度字段data[1]判断每帧的边界，帧什么时候收完、下一帧从哪里开始，都靠这个长度字段驱动。这也是为什么工具里看到的“报文条数”和wireshark里看到的TCP段条数总对不上——工具按APDU帧计数，wireshark按TCP包计数，一包可以含多帧，一帧也可以跨多个TCP包。

5. IEC 104测试工具踩坑记录：现象、原因和解法

协议测试工具跑不通，绝大多数时候不是工具坏了，而是规约细节没对上。这一章列五个我在实际项目中反复见到的坑，每条都是真实踩过的。

5.1 总召激活后从站毫无响应

现象：主站工具显示TCP连接正常，STARTDT确认也收到了，但总召命令发出去后，从站既不回激活确认，也不上送任何数据，界面上一片空白。

原因：最常见的是QOI召唤限定词和IOA的组合不对。很多国产从站实现里，全局总召的IOA必须从0开始，QOI必须是0x14，把IOA写成1，从站就认为你在召唤一个不存在的信息对象，直接丢弃。另外CA公共地址不对也会出现完全相同的现象。

解决：先用抓包工具看主站发出去总召帧的原始十六进制，确认CA、IOA=0x00、QOI=0x14三个关键字节都正确，再把CA切成和从站侧完全一致的数值，回环自测一次确认工具侧没问题，最后才连真实从站测试。这样三步排查下来，90%的总召无响应问题都能定位。

5.2 遥信值解析出来全部反相

现象：从站返回的单点遥信帧报文格式完全正确，TypeID是1，字节长度也对，但界面上显示的开关状态和现场实际正好相反，该合的分位，该分的合位。

原因：单点遥信M_SP_NA_1的SIQ字节，最低位SPI表示开关位置，0代表分、1代表合，这个定义是规约标准上的。但有些IED厂家习惯自己定义，0代表合、1代表分，而且不写在规约文档里。测试工具按标准解析自然就和现场对不上。

解决：这种问题不能靠改代码解决，要让现场厂家确认SIQ位的定义。工具如果有“遥信极性”或“SPI取反”配置，直接勾上取反再验证；如果工具没有这个配置，就在解析脚本里对SIQ最低位做一次异或，再和现场实际状态核对一次。注意不要把“反相”和“双点遥信按单点解析”两种错误混在一起，双点遥信是TypeID 3，两个位分别表示00中间态、01分、10合、11故障态，误用TypeID 1解析TypeID 3的报文，数据一定是乱的。

5.3 链路刚建好就周期性掉线

现象：主站和从站能建立连接，也能正常传一段时间数据，但每隔几十秒到几分钟就掉线一次，重连后又恢复正常，周而复始。

原因：链路参数的t1和t2不匹配。如果主站t1=15秒，从站t2=10秒，正常情况下从站每收到8个I帧或每10秒必须回一个S帧确认，但主站的接收确认间隔和从站发送确认间隔对不上，导致一方觉得对方已经确认了，另一方觉得还没确认，窗口溢出后直接断开。

解决：把t0、t1、t2重新对齐，最稳的配置是t0=30、t1=15、t2=10，主站从站必须一致。另一个隐蔽原因是链路空闲时双方都不发心跳，IEC 104没有专门的心跳帧，链路空闲时依赖TESTFR测试帧来保活，如果工具没有周期发送TESTFR的机制，长链路就会因为网络中间设备的空闲超时被掐断。工具里找一下“链路保活周期”之类的配置，通常30秒发一次TESTFR激活，能覆盖绝大多数中间设备的空闲断开机制。

5.4 CA和IOA混用导致报文全部串号

现象：数据能上送，但遥信表、遥测表全部对不上，A站的开关量显示到B站下面，或者同一个地址出现两组不同含义的数据。

原因：CA公共地址和IOA信息体地址概念被搞混。CA是站级地址，一对多通信时用于区分不同的从站；IOA是站内数据点地址，用于区分布点。有些工具把站地址和数据点地址合并成一个输入框，用户误填成同一个值，或者把CA填成0，导致数据全归到一个虚拟站下。

解决：在工具配置里把CA和IOA分开填。首先要向现场要一张点表，明确每个遥信遥测的IOA编号规则，比如遥信从10001开始、遥测从20001开始，然后核对工具的IOA偏移量设置，很多工具有“IOA起始偏移”参数，填错整体偏移一个常数，所有点全部串位。逐个点核对点表再下装测试，不要批量导入就直接跑。

5.5 zip工具双击后毫无反应

现象：从压缩包里解压出来的工具，双击exe后没有窗口，进程一闪就消失，或者提示缺少DLL，或者等了半天连日志都没有。

原因：三个常见因素。一是运行库缺失，上面3.1节已经提过；二是压缩文件本身有问题，比如zip带有伪加密标志——解压时提示要求密码但实际没有，或者解压出来的文件大小跟压缩包内索引不一致，这种包里的主程序损坏，启动必然失败；三是exe依赖的配置文件路径被写死成绝对路径，解压目录换了就找不到配置。

解决：先换7-Zip重新完整解压一次，解压时确认文件列表和大小完整，不要用系统自带解压工具直接拖出来；如果提示伪加密，在7-Zip里取消“加密文件名”选项强制解压。解压后右键exe属性看“兼容性”，勾选“以管理员身份运行”再试。还不行就把exe所在目录加进Windows Defender排除列表，曾经遇到过杀毒软件把免安装工具的授权文件当木马隔离，进程起了但功能残缺，排查了很久才发现是隔离区里有三个关键文件。

6. 把测试工具从手点变成自动化：回归脚本、故障注入与指标统计

工具用熟之后，下一层需求是重复测试和回归验证。手动点界面测一遍链路至少要五分钟，而且每次手点的报文时序不可能完全一致，做不了横向对比。把测试过程脚本化，是测试工具落地到项目验收环节的必经之路。

6.1 用Python把总召测试变成可重复的回归用例

在第四章最小主站脚本的基础上，把测试过程封装成用例函数，输入是CA、QOI、预期遥信点数量，输出是通过还是不通过。回归跑一遍，相当于把原来手点一小时的工作量压缩到半分钟。

一个稳定可用的回归用例至少要覆盖四件事：STARTDT激活和确认、总召下发和激活确认、遥信点数量核对、遥测值范围检查。只测“能连上”没有任何意义，链路通了不代表数据是对的。

6.2 故障注入：丢帧、乱序、延迟重发

测试工具只测“正常情况”是不够的，现场链路经常会抖动，主站和从站对异常报文的处理能力才是验收重点。故障注入的常见手段有三种：

在发送端主动丢弃某个I帧，观察从站能不能在超时后重发；把两个I帧的发送顺序颠倒，观察接收方的序号校验是否生效；在I帧发出后手动延迟3秒再发后续帧，观察窗口机制是否触发停止发送。这三种故障注入在真实设备上做起来都繁琐，但在脚本里只是加个sleep或跳过一帧不发的区别。

6.3 用一张指标表衡量链路质量

自动化脚本跑完之后，不要只看“通过”“不通过”，把关键指标打出来。我的习惯是每次回归都记录四个数字：总召响应时间从发出总召到收到第一帧响应数据的毫秒数、总召完成时间到收到最后一帧数据的毫秒数、链路中断次数和报文误码率。这四个数字横向对比同一台设备不同版本的程序，比任何界面截图都有说服力。

测试工具的终点不是“测通”，而是“能量化地证明这个从站实现是可靠的”。我自己的习惯是，每次接手一个新的远动项目，先花半小时把这套脚本跑一遍，把基线指标存档，等到现场出问题再对指标，能省掉一半的排查时间。这个习惯保留了好几年，希望帮到你。

本文还有配套的精品资源，点击获取