简介IEC101通讯规约报文流程及解析技术文档面向电力系统自动化领域工程技术人员与通讯规约学习者。文档围绕2002版IEC101规约展开系统梳理主站与RTU之间的问答机制、报文格式定义及关键流程环节并对2002版与1997版ZD101规约的差异进行对比说明同时介绍链路地址、公共地址、传输原因、信息体地址等参数的字节配置方式以及DF8900等系统中的规约号差异。资源包内含1个doc格式文档整体大小约121KB已有2751人学习浏览。文档通过报文实例逐帧拆解握手请求链路状态、复位链路、总召唤、一级数据召唤等核心流程并给出遥信、遥测等典型报文的解析示范可帮助读者快速掌握IEC101规约的实际报文交互过程为电力系统自动化设备的调试、维护与故障排查提供直接参考。1. 现场最常遇到的问题报文能抓到流程却对不上做过电力远动调试的人都有过这种经历串口抓包工具里明明全是68 0C 0C ... 16这种完整报文十六进制也能逐字节对上主站却报“通讯中断”或“总召唤超时”。后来才发现问题根本不在单帧报文而在于帧与帧之间的流程顺序错了——该先复位链路的时候没复位该看 ACD 位的时候没看导致两边的链路状态机一直对不上。这就是 IEC101 通讯规约IEC 60870-5-101和 HTTP、Modbus 这类“一发一收”协议最大的区别它是面向状态机设计的远动规约报文的正确性只是入场券流程的节奏才是能不能通的关键。这篇文章要讲的就是从帧格式、典型流程到报文解析的完整落地路径适合刚接手站端接入的开发者、写采集/解析工具的工程师以及要在现场快速定位通讯问题的调试人员。读完你会知道一帧报文怎么拆、一个完整流程由哪几步组成以及哪些地方最容易翻车。2. 看懂一帧报文FT1.2 帧格式与三类帧的适用边界2.1 三类帧固定帧、可变帧、单字节帧IEC101 的链路层基于 FT1.2 帧格式实际线路上只出现三种帧固定帧、可变帧、单字节帧。它们的用途非常明确不要混用。固定帧格式为0x10 C A CS 0x16只有 5 个字节C 是控制字段A 是链路地址也就是 RTU/站端地址CS 是校验和。它用来承载主站发起的复位链路、请求链路状态以及从站返回的链路确认、链路状态。比如主站请求链路状态发的是10 49 01 4A 16其中0x49表示“主站请求链路状态”链路地址为0x01校验和0x4A就是0x49 0x01的累加结果。这类帧不携带应用层数据所以轻量、固定、适合做控制类交互。可变帧格式为0x68 L L C A ASDU CS 0x16其中 L 是 C、A、ASDU 三部分的字节数ASDU 就是应用层数据单元。遥信、遥测、总召唤、时钟同步这类真正带数据的报文都走可变帧。单字节帧则只有0xE5表示链路层确认在高速轮询场景下用来替代固定帧确认减少线路开销。选型理由判断一帧报文是何种类型先看第一个字节。0x10是固定帧0x68是可变帧0xE5是单字节帧。调试时看到0x68就直接找长度字节 L看到0x10就按 5 字节收完能省很多定位时间。2.2 控制字段里的状态位PRM、FCB、FCV、ACD、DFCC 字段是 IEC101 里最容易看漏的一个字节但它决定了整帧报文的“身份”。C 字段是 8 位bit7 是保留位bit6 是 FCV 或 DFCbit5 是 FCB 或 ACDbit4 是 PRMbit0 到 bit3 是功能码。PRM 位标记方向PRM1 表示主站到从站PRM0 表示从站到主站。功能码配合 PRM 才能解释同一个数值在不同方向上含义完全不同。比如从站上送用户数据时 C0x02PRM0功能码 2而主站发送用户数据时可能是 C0x64PRM1功能码 4两者都涉及“用户数据”但方向和控制语义不一样。FCB 位是链路控制的核心主站每成功发送一帧下一次再发时 FCB 要翻转0 变 11 变 0。从站收到数据帧后会校验 FCB如果不匹配就会认为链路失步拒绝处理。这也是平时最容易出问题的地方很多调试工具固定 C0x64 不变从站前几帧还能处理到后面就突然不理你了。从站方向ACD 位表示“从站还有 1 级数据等待上报”。主站收到链路状态帧后如果发现 ACD1应当立即发起“请求 1 级数据”来把事件取走。DFC 位则表示从站接收缓冲区满主站看到 DFC1 要暂停发送等它恢复。2.3 ASDU 结构类型标识、传送原因、公共地址、信息体ASDU 是可变帧里真正承载业务数据的部分。一个标准的 ASDU 由类型标识、SQ 位、传送原因、公共地址、信息体或信息体序列组成。类型标识占 1 字节代表数据类型这是解析时最先要看的。常见类型标识中0x01是单点遥信0x03是双点遥信0x0D是短浮点遥测0x1E是带时标的单点遥信SOE 事件0x64是总召唤 C_IC_NA0x67是时钟同步 C_CS_NA。类型标识决定了后面的信息体怎么拆。SQ 位占 1 字节的低 1 位为 1 表示多个信息体地址连续只需要记录起始地址为 0 表示每个信息体都带完整地址。传送原因占 2 字节常见值有0x06激活、0x07激活确认、0x0A激活终止。主站发总召唤时传送原因是0x06从站回确认是0x07总召唤数据发完是0x0A这三个值把总召唤的完整生命周期串起来了。公共地址占 2 字节常见配置下与链路地址相等但这不是标准强制要求。接入多个厂站时如果链路地址出错接收方根本不会回应如果公共地址配置错了链路是通的但数据会解析成别的厂站的这个坑在下一章会展开。信息体部分按类型标识决定长度单点遥信每个信息体 1 字节或 3 字节带地址短浮点遥测是 3 字节地址加 4 字节浮点带时标的 SOE 则要额外加 7 字节的 CP56Time2a 时间戳。解析时不要按固定模板硬拆先判类型标识和 SQ 位再决定步长。3. 主线流程拆解从链路复位到总召唤再到事件上报3.1 一次完整的链路建立与总召唤过程IEC101 的典型运行流程不是“主站发一条、从站回一条”而是一套有顺序的交互过程。我一般按“链路复位 → 链路状态检查 → 总召唤 → 周期轮询”这个顺序去推流程。链路复位通常在通讯建立或链路异常恢复后做。主站发固定帧复位远方链路控制字段 C0x53从站收到后回一个固定帧确认控制字段 C0x00链路复位完成。这一步的作用是把 FCB 计数器归零让两侧的状态机回到已知起点。如果跳过这步直接发数据从站可能因为 FCB 对不上而静默丢弃主站还以为是通道问题。复位后主站会请求链路状态发10 49 01 4A 16。从站回10 41 01 42 16表示链路正常且无事件如果从站有变位或 SOE 待报控制字段会变成0x61也就是 ACD 置 1这时主站就要马上进入 1 级数据读取而不是直接开始总召唤。总召唤是站端数据接入的“全量同步”动作。主站发可变帧C 字段为 0x64发送用户数据级别 1ASDU 类型标识为 0x64传送原因为 0x06 激活信息体地址通常为 0x000000限定词为 0x14。从站收到后先回固定帧链路确认再上送一个 ASDU 类型标识 0x64、传送原因为 0x07 的激活确认然后才开始分批上送遥信、遥测数据。所有数据上送完毕后从站会发一个传送原因为 0x0A 的激活终止帧告诉主站“总召唤结束”。主站如果没收到 0x0A就不能认为总召唤已经完成。3.2 周期轮询与事件上报ACD 位驱动的两级数据模型总召唤结束后系统进入正常运行状态。主站周期性地发“请求 2 级数据”来取循环量测也就是遥测里的模拟量、电度等周期性变化的数据。C 字段通常是 0x65 或类似功能码具体值取决于 FCB 当前状态。2 级数据轮询不会触发事件上报。事件上报走的是另一个通道从站检测到遥信变位或产生 SOE 后会在下一次链路状态响应里把 ACD 置 1。主站看到 ACD1发“请求 1 级数据”取事件。取完这一帧如果从站还有更多事件会在响应帧里继续带 ACD1主站就继续请求 1 级数据直到 ACD0。这个机制叫“两级数据模型”是 IEC101 应对突发事件的固有设计。我在现场见过最典型的错误是主站把 2 级数据轮询的频率调高了但完全没检查链路状态帧里的 ACD 位结果从站的事件堆积变位迟迟上报不上来值班画面上的开关状态跟实际完全对不上。正确做法是每个轮询周期都先看 ACD有事件就暂停 2 级轮询优先把 1 级事件取完。3.3 时钟同步与对时报文时间戳乱了怎么排查时钟同步是 IEC101 里另一条重要流程直接关系到 SOE 事件的时间戳是否可信。主站发 ASDU 类型标识 0x67C_CS_NA传送原因为 0x06信息体地址固定为 0x000000信息体是 7 字节的 CP56Time2a 时间。从站收到时钟同步后回传送原因为 0x07 的激活确认。如果从站时钟本身有偏差它会按主站下发的绝对时间校准。时间戳解析要按 CP56Time2a 的字节序来前 2 字节是毫秒随后依次是分、时、日、月、年且每个字段还带有星期和夏令时标记位。调试时如果发现 SOE 时间比实际时间差好几个月多半是解析时把年字节的世纪位丢掉了或者字节序搞反了。我建议在验证流程时把时钟同步、总召唤、链路复位三条流程分别用抓包工具单独跑一遍确认每一步的响应都符合预期再合入完整的调度轮询循环。这样出问题的时候能直接定位到是哪条流程的状态机卡住了。4. 报文解析落地用 Python 把串口字节流还原成可读数据4.1 一个最小的帧解析函数边收边拆不依赖第三方库抓包拿到的是连续的字节流不能假设每帧都完整对齐。最稳的做法是维护一个接收缓冲区先找到帧起始符再根据帧类型确定整帧长度最后做校验和验证。下面的代码实现了固定帧和可变帧的解析可以直接塞进你的调试脚本里。import struct def parse_frame(data: bytes) - dict: 解析单帧 IEC101 报文返回结构化字典。 if not data: return {} if data[0] 0x10: # 固定帧0x10 C A CS 0x16 if len(data) 5 or data[4] ! 0x16: raise ValueError(固定帧长度或结束符错误) c, a, cs data[1], data[2], data[3] if (c a) 0xFF ! cs: raise ValueError(f校验和不匹配: sum{(c a) 0xFF:#04x}, cs{cs:#04x}) return {type: fixed, control: f{c:#04x}, addr: a, data: data} if data[0] 0x68: # 可变帧0x68 L L C A ASDU CS 0x16 if len(data) 6 or data[1] ! data[2]: raise ValueError(可变帧长度字段不一致) length data[1] total 5 length # 起始符1 长度2 C/A/ASDU(length) CS1 结束符1 if len(data) total or data[total - 1] ! 0x16: raise ValueError(可变帧总长度或结束符错误) c data[3] a data[4] asdu data[5 : 5 length - 2] # length 包含 C/A/ASDU故剪掉 C 和 A cs data[total - 2] calc (sum(data[3 : total - 2])) 0xFF if calc ! cs: raise ValueError(f校验和不匹配: calc{calc:#04x}, cs{cs:#04x}) return { type: variable, control: f{c:#04x}, addr: a, asdu: asdu.hex().upper(), data: data, } raise ValueError(f未知起始符: {data[0]:#04x})这个函数先处理固定帧。固定帧总长是 5 字节校验和就是控制字段加链路地址的低 8 位算出结果和帧里的 CS 比对不一致就直接抛异常避免把错帧当有效帧继续往下走。可变帧的处理逻辑是先确认两个长度字节一致再计算理论总长如果缓冲区里字节不够就报长度错误由外层等待更多数据。4.2 把解析结果进一步展开成 ASDU 结构拿到可变帧的 ASDU 字段后还要按 ASDU 格式拆出类型标识、SQ、传送原因、公共地址和信息体。这部分是数据上送核心直接决定你能不能把报文变成“可读的遥信值”或“遥测浮点数”。继续扩展上面的解析函数def parse_asdu(asdu_bytes: bytes) - dict: 解析 ASDU 字段返回常用字段和信息体列表。 if len(asdu_bytes) 6: raise ValueError(ASDU 长度不足) type_id asdu_bytes[0] sq asdu_bytes[1] 0x01 cause struct.unpack(H, asdu_bytes[2:4])[0] common_addr struct.unpack(H, asdu_bytes[4:6])[0] info_body asdu_bytes[6:] info_list [] if type_id in (0x01, 0x03): # 单点/双点遥信 step 1 if sq else 3 for i in range(0, len(info_body), step): if sq: info_list.append({index: i, value: info_body[i] 0x01}) else: addr struct.unpack(I, info_body[i:i3] b\x00)[0] info_list.append({addr: addr, value: info_body[i3] 0x01}) elif type_id 0x0D: # 短浮点遥测 step 7 if sq else 7 for i in range(0, len(info_body), 7): if sq: val struct.unpack(f, info_body[i:i4])[0] info_list.append({index: i // 7, value: round(val, 3)}) else: addr struct.unpack(I, info_body[i:i3] b\x00)[0] val struct.unpack(f, info_body[i3:i7])[0] info_list.append({addr: addr, value: round(val, 3)}) return { type_id: f{type_id:#04x}, sq: sq, cause: f{cause:#04x}, common_addr: common_addr, info_count: len(info_list), info_list: info_list, }这个函数的拆包步长是按类型标识走的0x01单点遥信在 SQ0 时每个信息体是 3 字节地址加 1 字节值0x0D短浮点遥测是 3 字节地址加 4 字节 IEEE754 浮点。信息体地址统一按小端读取IEC101 的地址字段都是低字节在前初学时最容易在这个地方翻车。4.3 从总线字节流中抽取完整帧一个接收状态机实际串口接收不是一次给全一帧往往是半帧、多帧混在一起。要可靠地切帧需要一个简单的状态机找起始符、读长度、攒够字节数、验校验和。下面给一个生成器实现适合接在串口读取循环里用。def frame_generator(stream: bytes): 从字节流中不断产出完整帧yield 每帧 bytes。 buf bytearray() for byte in stream: buf.append(byte) if len(buf) 2 and buf[0] 0x68: length buf[1] total 5 length elif len(buf) 1 and buf[0] 0x10: total 5 else: continue if len(buf) total: frame bytes(buf[:total]) try: parse_frame(frame) except ValueError: # 校验失败时丢掉帧头继续向后找 buf buf[1:] continue yield frame buf buf[total:] if buf: # 流被截断保留残余数据等待下一次接收 pass这段代码的核心是只有看到0x68或0x10才开始预测帧长否则持续丢弃字节。每攒够一帧就先用解析函数做校验校验不过的帧不会交给上层而是丢掉帧头继续找下个起始符。这个逻辑在弱信号或干扰大的串口链路上很关键能避免把沾满噪声的字节流硬套进协议结构里。使用这套解析脚本时可以先拿抓包存的原始二进制文件喂给frame_generator逐帧打印parse_asdu的结果与抓包工具对比确认一致再挂到真实串口上跑。这样解析代码的正确性在进现场之前就已经验证过了到了现场只需要关心链路参数和流程配置。5. IEC101 解析与调试的 5 个常见坑现象、原因与处理5.1 校验和怎么算都对不上现象抓包工具里报文完整但自写解析脚本一跑就报“校验和不匹配”。逐字节看了半天没发现计算错误。原因IEC101 的校验和不是 Modbus 那种 CRC16 或取反累加而是从控制字段 C 开始到 ASDU 最后一个字节为止逐字节算术累加后取低 8 位不取反。很多人把网络报文解析里“校验码0x100-累加和”的习惯带进来自然怎么算都不对。另外计算范围要排除帧头 0x68、两个长度字节 L 以及帧尾 0x16。解决按“从 C 开始到 ASDU 最后一字节”取和再 0xFF比对 CS。遇到可变帧时先确认 L 包含的是 CAASDU而不是整个帧长这会直接影响你从哪里截取参与校验的字节。5.2 从站偶尔不响应重发后又恢复现象主站连续轮询一段时间后从站对某些帧突然不回复主站超时重发同样内容从站又正常响应了。看起来像“偶发丢包”但又不像线路问题。原因大概率是 FCB 位没有按链路规则翻转。IEC101 规定主站每成功发送一帧带 FCB 的报文下一帧必须翻转 FCB。从站内部会记录上一次收到的 FCB如果两次相同就判定为链路重发或失步丢弃处理。调试时如果图省事把控制字段写死成固定字节就会出现这种“随机性”掉线。解决在主站发送逻辑里维护一个fcb变量每发完一帧并且收到从站确认后执行fcb ^ 1。构造 C 字段时把 FCB 位拼进去。现场判断方法也很简单把从站重启后复位链路成功后前几帧正常之后开始丢响应基本就是 FCB 没翻转。5.3 总召唤发了从站也回了一堆数据但主站界面还是空的现象报文流程看起来完整总召唤的激活确认、一堆遥信遥测数据都收到了但监控画面迟迟不刷新。原因主站收到了数据但没收到“总召唤结束”标记。从站上送完所有数据后会发一个传送原因0x0A激活终止的 ASDU 来表示总召唤结束。很多主站实现是必须收到这个帧才把缓存中的总召唤数据一次性提交入库。如果中间漏了一帧数据或者主站因为超时提前终止从站就不会发 0x0A数据就全卡在缓存里。解决抓包的过滤条件加上“ASDU 类型标识为 0x64 且传送原因为 0x0A”确认它存在。如果没有往前查是不是中间某帧数据没有用“请求 1 级数据”取完导致从站认为总召唤还没发完。我在模拟项目X里就遇到过从站侧因为信息体数量太大分三帧上送主站只取了两帧就停结果总召唤永远收不到 0x0A。5.4 遥测值解析出来是天文数字或负数现象遥测报文结构正确类型标识也匹配但解析出来的浮点值是 1e-38 这种垃圾数据或者符号完全反了。原因短浮点遥测0x0D的信息体是 3 字节地址加 4 字节 IEEE754 单精度浮点字节序是小端。如果按大端去解或者把地址字段的长度算错浮点的 4 个字节就错位了。还有一种情况是 SQ1 时第一个信息体不带地址直接是 4 字节浮点解析代码没有区分 SQ把浮点前 3 个字节当地址给啃掉了。解决先用手工方式把一个遥测 ASDU 的原始字节拆出来按地址 3 字节加浮点 4 字节的步长核对一遍确认步长对了再改代码。SQ1 时信息体序列首元素只有数据没有地址步长就是 4 字节SQ0 时才是 7 字节步长。我习惯在解析结果里同时打印原始 hex 和解析值出问题能马上回看是哪一段字节拆错了。5.5 链路地址对、公共地址对数据还是串到了别的厂站现象多个厂站接入同一个主站链路层通讯都正常但从站A 的数据偶尔出现在从站B 的画面上或者公共地址查出来不是本厂站。原因链路地址和公共地址是两个独立配置项。链路地址决定链路层能不能通公共地址决定应用层数据归属哪个站。如果两侧把公共地址配成了相同值或者主站侧按链路地址去索引数据就会串数据。更隐蔽的情况是公共地址 2 字节的小端序处理错误01 00被读成0x0100而不是0x0001站号一错位数据全乱。解决统一用struct.unpack(H, ...)读公共地址并在配置表里把链路地址和公共地址显式对照。接入新站时先用解析脚本打印原始公共地址确认和主站配置表完全一致再投运。调试时发现数据串站优先怀疑公共地址而不是线路问题能少走很多弯路。6. 一个实用的调试验证技巧用历史报文回放检查流程边界解析工具能跑通还不够真正要验证的是“整个流程是否符合状态机”。我的习惯是把现场抓包保存成二进制文件用前面写的frame_generator和parse_asdu把全部报文解析后按时间顺序生成一张流程时间线然后人工检查每个关键边界。做法很简单在解析脚本里对每一帧提取“控制字段方向主站→从站还是从站→主站、ASDU 类型标识、传送原因、ACD 位、FCB 值”按顺序打出来。然后对照标准流程逐段核对链路复位后第一条主站数据帧的 FCB 是否从 0 开始总召唤的激活确认有没有在数据帧之前最后一帧传送原因是不是 0x0A事件上报期间链路状态帧的 ACD 位是不是先置 1 再清零。这个回放技巧最有价值的地方是能帮你把“偶发故障”从玄学变成可复现的现场。我遇到过一次从站每隔半小时掉一次链抓包后回放发现是从站事件较多时连续三帧 1 级数据都没取完主站就切回了 2 级轮询从站缓冲区溢出后主动复位链路。把时间线打出来看问题边界一目了然。我用这套分析方法解决过的另一个案例是某场站总召唤经常超时回放发现主站总是在收到激活确认后没有立即请求 1 级数据而是先发了一轮 2 级轮询从站就没机会上送数据直到 ACD 超时才处理整个总召唤被拖慢了 3 秒。如果你还没有现成的抓包工具可以先在仿真环境里搭一个虚拟从站对照标准流程逐条回执再用同一个脚本检查回执的正确性。这样等真机接入时解析脚本和流程边界都已经验证过了剩下的只是现场链路层面的收尾。希望这套方法能帮你在下一次调试时少一点抓包到凌晨的辛苦多一点一次通调的踏实。本文还有配套的精品资源点击获取