IEC-104报文解析与调试实战：从APCI控制域到ASDU体逐字节拆解

简介：面向电力系统自动化领域研发与调试人员的 IEC 104 报文速查资料，帮助读者理清主站与子站间常用报文类型、帧格式及每个字节的详细含义，尤其适合刚接触 104 规约、需要在开发或联调中快速定位报文问题的工程师。资料内置 PDF 与 HTML 两种阅读形态，PDF 便于离线精读，HTML 页面支持在浏览器中直接检索查看，并配合页面演示辅助理解。

资源包共 11 个文件，主要包含 1 份 PDF 详解文档、2 个 HTML 页面、3 个 JavaScript 脚本以及字体、文本说明等辅助文件，整体约 838KB，轻量便携。PDF 文档可离线打开，HTML 页面适合快速浏览，配套的 JS 脚本支撑网页中的演示效果，文本说明文件则提供简要使用指引。

目前已有 8258 人浏览学习。内容从开发痛点出发，逐条拆解常用报文的作用和关键字节含义，让学习者避免反复翻查协议文档；通过对照页面展示，能更快掌握 104 报文规则，提升实际项目中的报文解析、联调与排错效率。无论课堂自学还是现场调试，都可作为随手查阅的速查手册。

1. 一条不刷新的遥测，逼我重新读懂了IEC-104报文

IEC-104报文平时看着不难，出问题时却能逼疯一屋子人。某天现场A同学拿着抓包文件来找我，主站画面上一条遥测半小时没刷新，而从站那边仪表显示值早就变了。我把包里那几帧IEC-104报文逐字节拆开，发现根本不是网络问题：从站一直在按突发上送，主站也确实收到了，只是主站按错误的类型标识把它当成了另一个点，数据进了隔壁的遥控信息体。这让我意识到，IEC-104报文平时不出事感觉简单，一出事就绕不开APCI控制域、ASDU体这几层基本功。

IEC-104是电力调度自动化里最常用的远动规约，它把远动应用层搬到TCP/IP上，遥信、遥测、遥控、遥调、总召唤、时钟同步全在这一套报文里。这篇笔记不打算复述协议原文，而是按「报文长什么样→怎么解析→怎么联调→踩过哪些坑→怎么把抓包变成自动化用例」的顺序，把现场真正用得上的东西一次讲清。适合刚接手变电站调试的运维、做配电主站开发的工程师，以及总被报文搞到半夜的调试人员。

2. IEC-104报文的基本盘：四字节控制域与三类帧的判定

2.1 帧格式骨架：起始符、长度字段与APCI

一条IEC-104报文在TCP流里以APDU为单位存在，每个APDU的结构是固定的：起始符0x68占一个字节，长度字段占一个字节，后面跟着4字节控制域和可变长的ASDU。这里有个新手最容易数错的细节：长度字段表示的是「控制域4字节加ASDU」的总长度，并不包含0x68和长度字段自身。比如68 0E意味着后面一共14字节，拆出来是4字节APCI加10字节ASDU；如果你按14字节去读ASDU，必然越界。

控制域也就是APCI，固定4字节。第一个字节的最低两位用来区分帧类型：00表示I帧，01表示S帧，11表示U帧。I帧负责携带ASDU业务数据，同时靠接收序号确认对方发来的I帧；S帧是纯确认帧，只回接收序号、不带ASDU；U帧则用来做启动传输、停止传输和链路测试，也没有ASDU。这个分类是看懂后续所有报文交互的前提。

I帧的发送序号和接收序号各占两个字节，但真正的序号只有15位，因为最低位被帧类型标志占用了。所以解析时要把取到的16位数值右移一位，才是真实序号。举个例子，控制域02 00 06 00：第一字节低两位是00，判定为I帧；发送序号是0x0002右移一位等于1，接收序号是0x0006右移一位等于3。序号是模32768循环的，超过32767后回绕到0，很多主站在这里没做回绕处理，导致链路跑一两个月后莫名卡死。

2.2 三类帧怎么配合：从握手、确认到心跳

U帧的命令集中在第一个字节上，靠特征位区分：0x07是STARTDT act（启动传输请求），0x0B是STARTDT con（启动传输确认），0x13是STOPDT act，0x23是STOPDT con，0x43是TESTFR act，0x83是TESTFR con。链路建立后主站必须先发STARTDT act，从站回STARTDT con，之后双方才允许传输I帧。这个先后顺序卡得很死，有的从站实现里没收到STARTDT就直接丢弃所有I帧。很多系统集成商第一次连104链路，上来就发总召唤，结果石沉大海，原因就在这里。

S帧不背业务数据，它干的活就是确认。当接收方短时间内收到多帧I帧而来不及处理时，先回一个S帧把接收序号确认掉，避免对方的发送窗口被占满。识别S帧很简单：控制域第一字节的低两位是01，典型样子是68 04 01 00 06 00，长度4说明只有APCI没有ASDU，接收序号同样是右移一位。调试时如果发现某侧从不回S帧，那对端的发送窗口迟早被撑爆，表现就是链路还连着、业务数据不更新。

I帧承载真正的遥测遥信遥控。I帧里的接收序号必须严格递增，接收方一旦发现中间少了序号，就会按丢帧处理并丢弃后续I帧直到序号重新对上。实际现场常见的情况是主站和从站之间有防火墙做了TCP劫持或缓冲，导致一批I帧乱序到达，从站全拒收，主站屏幕上那一批数据全部不动。遇到这种「一串数据同时卡住」的现象，优先怀疑I帧序号不连续，而不是单个点表配错。

2.3 三个必查字段：类型标识、传送原因与品质位

ASDU的固定头部依次是：类型标识TI占1字节、可变结构限定词VSQ占1字节、传送原因COT占2字节、公共地址占2字节，之后才是信息体地址和信息体数据。类型标识决定了这条报文里信息体的长度和语义，TI=1是单点遥信，TI=13是短浮点遥测，TI=45是单点遥控，TI=100是总召唤。解析报文的第一个动作永远是看TI，TI认错了后面所有字段都会跟着错，当初我排查那条不刷新的遥测，最后就是发现主站把TI=13的帧按TI=9去解析了。

可变结构限定词VSQ的bit7是SQ位，bit0到bit6是信息体个数。SQ位决定信息体地址是否连续：SQ=1表示连续，后一个信息体地址自动加一，报文里只写第一个IOA；SQ=0表示不连续，每个信息体都带完整的三字节IOA。解析时一定要先看SQ位再决定读取方式，否则信息体个数对不上，整帧长度就算不齐。公共地址占2字节，是站地址，多数从站配成1；COT的常见取值是1周期、3突发、6激活、7激活确认、10激活终止、20响应站召唤。COT高字节的bit7是P/N位，置1表示负确认，命令被拒绝时多半能在这里看到。

遥信和遥测信息体末尾会跟一个品质描述符QDS：bit0是IV无效，bit1是NT非当前值，bit2是SB被取代，bit3是BL被闭锁，bit4是OV溢出。品质位全0才是正常值。主站画面数据不刷新，很多时候不是链路断了，而是从站把IV或NT位置1，主站按品质策略直接拒绝更新画面。排查时把QDS从报文里抠出来看一眼，比在界面上反复对点表快得多。下面两个速查表建议贴在调试台上，比翻几百页协议原文方便。

类型标识速查：

传送原因速查：

3. 把一条报文从hex拆成人话：手写解析与抓包验证

3.1 一条上行遥测的逐字节拆解

拿到一段抓包，比如这条上行遥测：

68 12 02 00 06 00 0D 01 03 00 01 00 01 00 00 00 CD CC 4C 3E 00

先看头两个字节68 12：长度0x12等于18，说明后面有18字节。接着是控制域02 00 06 00：低两位是00，I帧，发送序号1，接收序号3。从第7个字节开始读ASDU：0D是类型13，即短浮点遥测；01是VSQ，信息体个数1个、SQ=0；03 00是传送原因3，突发上送；01 00是公共地址1；01 00 00是信息体地址1，注意IOA是三字节小端，01 00 00表示地址1，不是0x010000。

后面的CD CC 4C 3E按小端拼成0x3E4CCCCD，用IEEE754单精度解出来约等于0.2；最后一个字节00是品质位，表示数据有效。把整帧从68数到末尾，4字节控制域加14字节ASDU正好18字节，长度字段吻合。拆过这一帧，你对IEC-104就不再有「黑匣子」的感觉，后面所有联调问题都可以回到这条拆解线上找原因。

拆的时候有两点要注意。第一，短浮点遥测TI=13的数值就是标准IEEE754单精度，不需要缩放，按字节直接解就行；而TI=9归一化遥测是两个字节的整数，需要除以一个系数才能得到工程值，很多主站把TI=9和TI=13混用，解析出来数值差一大截。第二，品质位字节一定要解析出来看，而不是跳过。上行数据里品质位是0、1、2、4、8这些值都有特殊含义，以前我遇到过一段数据的QDS一直为0x01（IV置位），主站全丢弃，排除好久才发现是从站采集板没初始化完成。

3.2 用Python写一个最小解析器：批量把hex变成结构化数据

调试时手上往往是一大段连续hex，一帧帧手数太容易出错，而且TCP粘包可能让一包数据里挤了好几条APDU。我一般用脚本先按长度字段循环切帧，再逐帧解析字段。下面这个简化版解析器只处理I帧，S帧和U帧打印类型后跳过，核心逻辑是把每个字段读出来并格式化输出。

import struct def parse_104(raw: bytes): """解析单条IEC-104 APDU，返回字段字典或None""" if len(raw) < 6 or raw[0] != 0x68: return None length = raw[1] # 长度含控制域4字节+ASDU，不含68和长度自身 frame = raw[2:2 + length] # 按长度字段切出完整帧体 ctrl = frame[:4] # 控制域4字节 c0 = ctrl[0] # 低两位：00=I帧 01=S帧 11=U帧 if c0 & 0x03 == 0x00: send = ((ctrl[1] << 8) | ctrl[0]) >> 1 # 16位右移1位才是真实序号 recv = ((ctrl[3] << 8) | ctrl[2]) >> 1 asdu = frame[4:] if len(asdu) < 6: return {"type": "I", "send": send, "recv": recv, "note": "ASDU不完整"} type_id = asdu[0] # 类型标识TI vsq = asdu[1] # 可变结构限定词 num = vsq & 0x7F # 信息体个数 sq = (vsq >> 7) & 0x01 # 0=不连续地址 1=连续地址 cot = struct.unpack("<H", asdu[2:4])[0] # 传送原因，2字节小端 ca = struct.unpack("<H", asdu[4:6])[0] # 公共地址，2字节小端 ioa = asdu[6] | (asdu[7] << 8) | (asdu[8] << 16) # 3字节小端 body = asdu[9:] # 信息体原始数据 return {"type": "I", "send": send, "recv": recv, "type_id": type_id, "num": num, "sq": sq, "cot": cot, "ca": ca, "ioa": ioa, "body": body.hex()} elif c0 & 0x01 == 0x01: recv = ((ctrl[3] << 8) | ctrl[2]) >> 1 return {"type": "S", "recv": recv} else: return {"type": "U", "cmd": f"0x{c0:02X}"} raw_hex = "6812020006000D010300010001000000CDCC4C3E00" raw = bytes.fromhex(raw_hex) print(parse_104(raw))

这段代码有四个关键点。第一，先用长度字段切帧，而不是按TCP包边界读，这样能正确处理一包多个APDU的粘包情况。第二，I帧的序号必须右移一位，这个细节错一次会连锁错一大堆。第三，IOA是三字节小端，COT和公共地址是两字节小端，不能复用同一个解析函数。第四，返回的body字段是信息体原始hex，下一步按TI类型解析时直接从这里取数据就行，比如TI=13时读前4字节为浮点、第5字节为品质，TI=1时只读1字节。

运行后输出大概是：{'type': 'I', 'send': 1, 'recv': 3, 'type_id': 13, 'num': 1, 'sq': 0, 'cot': 3, 'ca': 1, 'ioa': 1, 'body': 'cdcc4c3e00'}。拿这个结果和Wireshark协议树对比，能快速验证你理解的字段边界对不对。实际用的时候，把抓包文件里每帧的data.data字段导出来，循环喂给这个函数，几秒钟就能把几千帧报文变成一张结构化表格。

3.3 用Wireshark快速定位：过滤端口与核对协议树

现场抓包最快的方式还是Wireshark，过滤器先写 tcp.port == 2404，把IEC-104流量全拉出来，这是104的默认端口。新版Wireshark自带104解析器，抓到后在协议树里能看到APCI和ASDU两层，Type ID、COT、公共地址、IOA都有可读显示。看协议树时重点核对四列：Type ID、COT、公共地址、IOA。如果你发现Wireshark显示正常、主站日志显示类型不对，那就是两边的解析口径差异，通常出在厂商自定义类型上。

Wireshark里还有个有用的习惯：抓包保存成pcap后，把包含总召唤、变位、遥控执行的帧单独标记。后面从站升级或换装置，重放这份抓包对比行为，比盯着一堆在线数据要快得多。对于I帧，右键选择Follow TCP Stream，按时间排序一帧帧核对序号是否连续。序号跳变意味着期间有丢包或从站重启，这是主站侧日志看不到的底层信息。注意抓包时上游交换机会丢弃一些错误帧，抓到的包不完整时，先怀疑抓包口镜像配置，不要上来就怀疑从站。

4. 用最小链路跑通全流程：启动、总召唤与遥控的报文对照

4.1 最小链路怎么搭：从站模拟器、信息体表与端口参数

联调前手头没有真实装置，常见做法是找一开源IEC-104从站模拟器，配一张最小信息体表。信息体表建议至少三列：信息体地址IOA、类型标识TI、初始值。比如IOA=1到10配TI=1单点遥信，IOA=20到30配TI=13短浮点遥测，公共地址统一填1。这个配置的目的不是模拟真实容量，而是把「从站发什么、主站按什么收」的对应关系先立起来。后面换真实装置时，把IP和端口一改就能沿用这套验证逻辑。

模拟器监听2404端口，主站侧用一个支持104的客户端或另一个模拟器连过去。启动前先核对五个参数：公共地址是不是1、端口是不是2404、T0连接超时是不是30秒、k值是不是12、w值是不是8。多数开源模拟器默认值就是标准值，但有些打包版本改过，不核对直接跑，链路反复断都不知道是哪边的参数问题。链路通断看U帧：TCP建立后主站发STARTDT act，从站回STARTDT con，这时才允许I帧。没有STARTDT就没有I帧，这个顺序在模拟器日志里看得一清二楚。

4.2 启动时序：从TCP握手到总召唤结束的报文对照

一条标准链路启动顺序固定为：TCP三次握手、STARTDT act/con、主站发总召唤TI=100且COT=6、从站回TI=100且COT=7激活确认、从站上送全量数据COT=20、从站再发TI=100且COT=10激活终止。整个过程在抓包里一目了然，报文对照表如下。

总召唤报文的信息体地址固定为0、VSQ=0，表示对整个站的召唤。COT=7的确认帧和COT=10的终止帧之间才是数据段，如果误把COT=7当成数据开始，读到的会是类型100的召唤帧体，自然提取不到任何业务数据。常见误用是拿COT=6的召唤帧去对数据响应，然后抱怨从站不回数据，其实从站早就把数据夹在COT=20的帧里发过来了，只是你找错了帧。

除了总召唤，主站启动后还会做时钟同步。时钟同步用TI=103，COT=6，信息体地址0，信息体是7字节的CP56Time2a时间格式，精确到毫秒。从站收到后回COT=7确认，校时完成。时标不准会直接影响事件顺序记录（SOE），如果现场发现两个站的事件顺序对不上，先查主站有没有做时钟同步，而不是查通道。时钟同步在IEC-104里是常规操作，很多从站规定启动后必须校时，否则带时标的报文不按正确时间上送。

4.3 遥控操作：选择与执行的报文差异及常见歧义

遥控分两步：先选择，再执行。以单点遥控TI=45为例，选择命令的信息体是一个字节，bit0是S/E位，置1表示选择；执行命令同样一字节，bit0清零表示执行。完整报文举例如下。

选择帧：68 0E 04 00 06 00 2D 01 06 00 01 00 05 00 00 01 执行帧：68 0E 06 00 04 00 2D 01 06 00 01 00 05 00 00 00

拆开看选择帧：控制域04 00 06 00是I帧，发送序号2、接收序号3；2D是类型45单点遥控；VSQ=01一个信息体；COT=06激活；公共地址01；IOA=05 00 00即5号对象；最后一个字节01，bit0为1表示选择。执行帧最后一个字节00，bit0为0表示执行，其余字段完全一致。从站正常反馈顺序是：收到选择先回COT=7确认，收到执行再回COT=7，执行完成回COT=10。如果从站不支持选择/执行模式，会直接回COT=10拒绝，这时要看第二字节P/N位，P/N=1代表负确认。

有些装置把选择/执行模式合并，只认执行帧不认选择帧，主站照样按两步走，就会看到选择被拒。这类兼容问题只能靠抓包确认：先发选择帧看返回，如果是COT=44未知类型标识或COT=10负确认，说明这个从站实现不走标准两步遥控。解决办法是在主站侧关闭选择功能，直接下发执行帧。另外QU字段是限定词，QU=0无条件执行，QU=1短脉冲，QU=2双脉冲。不少从站只支持短脉冲，主站却填0，导致装置拒动。拿不准时先在模拟器上试三种QU值，看哪个能通过，再改主站配置。

5. IEC-104报文调试避坑：5个真实翻车现场

5.1 现象：链路反复断开重连

现象是主站日志里TCP连接不断建立又断开，从站侧模拟器显示连接存活时间经常不到1分钟。原因十有八九是T0/T1/T2/T3四组超时参数两端不一致。常见组合是主站T1设15秒，从站T1设30秒，主站发完I帧后15秒内没收到确认就断开，而从站一直傻等主站继续发。T2是监视超时，T3是测试帧周期，任何一个参数不匹配都会导致误判死链。

解决方法是把T0=30秒、T1=15秒、T2=10秒、T3=20秒作为基准值在两端统一配置，并确认从站周期发TESTFR act、主站能正确回TESTFR con。抓包里如果只有TESTFR act没有con，问题在主站的U帧处理逻辑上，而不是从站。这四组参数虽然只是数字，却是链路稳定性的地基，别偷懒按默认值省事，必须逐项核对。

5.2 现象：遥测偶发丢点，刷新停在一个值上

现象是数据列表里个别点长时间不更新，重启从站后恢复，过一会儿又卡住。原因通常是k参数和w参数配置过小。k是未确认I帧的最大个数，标准默认12；w是收到多少帧未确认就发S帧确认，默认8。有些厂家为了省带宽把w改成1，结果主站或从站稍有延迟，发送窗口就满了，后续I帧全被缓存或丢弃，表现就是某几个点不刷新。

解决方法是恢复标准值k=12、w=8，同时确认接收侧及时回S帧，不要攒批确认。排查时抓一段正常上送的数据流，数一下连续I帧数量和S帧间隔是否符合w参数。如果连续12帧都没有S帧回来，那窗口必然溢出，这个锅不在从站，在主站的确认策略。

5.3 现象：遥控选择成功、执行后从站不动

现象是主站下发遥控，抓包看选择帧和执行帧都收到了COT=7确认，但从站现场设备无动作，几秒后收到COT=10。原因通常是S/E位写反或QU限定词不匹配。最常见的是厂家自定义网关把选择/执行做了合并，选择帧信息体字节必须为0x81而不是0x01，导致从站识别成普通置位；还有一种情况是执行帧晚发了3秒，超过从站2秒的选择有效期，从站返回COT=10终止。

解决方法是先查从站说明书，确认信息体bit0的S/E判定和QU取值，再调整主站选择执行间隔。选择后执行要快，建议控制在1秒以内；如果业务上做不到，就在从站侧把选择有效期调大。这种问题在模拟器上验证比在现场试安全得多，先在模拟器发一组标准帧，看从站返回什么，再比照现场主站的报文差异。

5.4 现象：总召唤后数据全是历史值，画面不刷新

现象是总召唤完成后，主站画面所有点显示上次值，后续变化也不上送。原因多数是品质位QDS被置IV或NT。很多从站初始化后，数据源还没采到有效值，就把IV置1打包上送；主站按品质策略直接丢弃，保持旧值。总召唤的COT=20响应数据里如果没把IV清掉，整个站的画面都会是旧值，不是单个点的问题。

解决方法是抓包里检索所有QDS非0的报文，定位到具体信息体，再查从站侧该点的采集链路是否正常。如果单点正常而全站都旧值，问题在主站的品质处理策略，可以暂时关闭品质过滤来验证。还有一种情况是TI不匹配，从站发TI=9归一化遥测，主站按TI=13短浮点解析，读出来的数值驴唇不对马嘴。这种要先对点表确认TI定义，再改主站侧类型标识。

5.5 现象：A开关变位，B开关动作

现象是操作A开关，画面B开关变位，或者遥测数据串到相邻信息点。原因多是IOA偏移：从站按信息体地址十六进制排列，主站点表从1开始按十进制累加，两边差了整整一段；也有公共地址从0开始配，主站按1配，导致全站错位。这类问题最坑的地方是链路完全正常，报文也合法，错的是地址映射本身。

解决方法是总召唤后把抓包里的IOA列表导出来，和主站数据库逐条比对。我一般写个小脚本，把pcap里TI=1和TI=13的IOA全提出来，排序后和点表文件做diff，一次就能把偏移量找出来。比对时注意IOA的三字节小端格式，别把05 00 00当成0x050000，那是地址5。这个习惯能省掉大半数据串位的排查时间，也让点表核对从人工变流程。

6. 进阶：把抓包文件变成回归测试用例

6.1 从pcap提取基线报文，建立回归基准

从站固件升级后最容易出的问题不是功能消失，而是某个报文字段悄悄变了，比如类型标识换了、传送原因从3变成20、信息体长度多了个字节。把联调通过时抓的pcap存成基线，用tshark按帧导出hex，之后每次升级或改配置，重新抓一份同样场景的包，用脚本把两份hex逐帧比对。字段不一致的帧直接标红，不用重新全量联调，半小时就能覆盖主要链路。

我实际是把基线pcap放在固定目录下，文件名带日期和从站版本号。升级后跑一次同样的联调用例，导出的新抓包和基线对比，输出差异帧清单。这个流程对验证从站固件修改尤其有用，因为固件改动经常影响报文的填充字节和时标字段，而这些在主站界面上根本看不到。别小看这个动作，有一次模拟项目X就是靠它抓到新固件把总召唤的COT=7错误地发成了COT=20，导致主站把确认帧当数据帧处理。

6.2 用回放验证从站行为：tcpreplay与自制校验器

比对比hex更进一步的，是用tcpreplay把基线pcap按原时序回放到测试从站，观察从站响应是否和基线一致。回放前把pcap里的IP和端口改成测试环境的值，再确认TCP序列号和时间戳不影响从站判断。回放后对照两边日志：如果新固件对同一总召唤返回的TI、COT、IOA和基线不同，基本能定位到改动点。这个流程我固定成了发布前必做项，宁可多花20分钟回放，也不在投运当天被叫起来查报文。

回放之外还可以做一个简单的断言脚本，把「总召唤后必须收到COT=7再收到COT=10」这类链路规则写成检查项，跑完用例自动输出通过/失败。断言脚本不需要复杂框架，几十行Python就能完成：先按长度字段切帧，再把每帧的类型标识、COT、公共地址、IOA顺序存进列表，最后用一组预置规则去匹配。第一次写这个脚本大概花一个下午，但之后每次联调省下的时间远不止一个下午。

IEC-104报文调试到最后，拼的其实是耐心和记录习惯。每个坑第一次踩都是玄学，把现象、抓包、处置写进一张表，第二次就变成了流程。我现在每处理一个现场问题，都会把关键帧存一份pcap、写一段现象描述、留一条处置结论。这个习惯救过我很多次，希望你也能用上。

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