简介面向电力系统自动化技术人员的IEC规约入门培训PPT教案系统讲解IEC-101与IEC-104等常用规约的基础知识、通信原理与工程应用适合SCADA系统运维、变电站调试及调度自动化岗位的集中培训和自学。资源为单个PPTX演示文稿压缩包共1个文件大小约1.27MB模块化设计便于按章节开展导入式教学。内容涵盖IEC规约概述、101串行通信与104以太网通信的对比、OSI七层模型映射、固定帧长与可变帧长格式、链路控制域和链路地址定义、校验和计算方式、97版与02版字段长度差异以及S1无应答、S2发送/确认、S3请求/响应等传输服务类型并用大量帧结构图解和版本对比表格辅助理解。通过本教案的学习读者能认清平衡传输与非平衡传输的区别理解不同厂商设备间的互操作性原理看懂常见链路报文格式并形成电力调度通信领域的初步排错思路。已有108人学习下载。1. IEC 规约入门从 101 到 104这份 PPT 讲透了电力通信的底牌在电力自动化调试现场摸爬滚打过的工程师都知道厂站和调度主站之间能不能说上话关键就看规约对不对。而 IEC-101 和 IEC-104 这对兄弟几乎承包了国内 SCADA 系统九成以上的远动通信场景——一个守着串口线一个跑在以太网上应用层定义却高度一致。这份 73 页的培训教案把 IEC 规约从体系结构、帧格式到链路层控制域、应用层类型标识全部串了一遍既有 97 版和 02 版的字段差异对照也有固定帧长、可变帧长的逐字节拆解适合刚入门的调试工程师通读也适合干了两年现场却只停留在能通就行层面的兄弟补一补底层逻辑。它解决的不是怎么连上而是报文为什么长这样、出错时看哪一位。2. IEC 规约家族与选型逻辑为什么现场只认 101 和 1042.1 四兄弟的分工串口和网口各管一摊IEC 规约不是一个协议而是一族协议。PPT 里开篇用一张表就把四个主要规约的适用范围和通讯方式划清楚了IEC-101 负责厂站与调度主站之间的串行通讯IEC-102 管电量主站与站内抄表终端IEC-103 面向站内继电保护设备IEC-104 则是厂站与调度主站之间跑以太网。这个分工很关键——你在调试时拿到一个需求第一件事不是打开报文分析工具而是先确认物理通道是什么。提示凡是新上项目先问通道。串口还是网口直接决定你该翻 101 的资料还是 104 的资料。两者的应用层几乎一样但传输机制和排错手段完全不同。实际选型时老站改造常见 101 串口通道透传或专线新建站点基本清一色 104 走以太网。PPT 里还专门强调了一个容易忽略的细节104 规约结构上映射到 OSI 的应用层、传输层、网络层、链路层和物理层而 101 只有三层——应用层、链路层、物理层。这意味着 104 天然继承了 TCP/IP 的可靠性机制而 101 必须在链路层自己处理确认和重发。2.2 相同点与不同点应用层同源传输机制分家101 和 104 最迷惑人的地方就是它们长得太像。PPT 里用了相同点和不同点两个维度来拆。相同点在适用范围都是厂站与主站之间和规约结构应用层定义相同——这就是为什么你学会了 101 的应用层再看 104 的 ASDU 几乎无障碍。不同点集中在通讯方式和服务类型上101 串行、104 以太网101 多采用非平衡传输104 多采用平衡传输。这里有个非常实际的坑非平衡传输意味着只有主站启动站能发起通讯子站从动站只能被动响应。而平衡传输下双方都可以发起通讯过程。调试 104 的时候调度端可能主动下发遥控命令厂站端也可能主动上送变位信息这要求你理解 TCP 连接的两端角色并不完全等同于主站/子站的角色划分。我一般会建议新手先死记一条101 的启动站永远是主站104 里 TCP 的客户端和服务端都可以是启动站。表101 与 104 关键差异速查对比项IEC-101IEC-104物理通道串行RS-232/485以太网TCP/IP传输模式多采用非平衡传输多采用平衡传输OSI 层次应用层、链路层、物理层应用层、传输层、网络层、链路层、物理层链路地址长度97版 1 字节02版 1~2 字节传输时携带在 APCI 中典型场景老站改造、专线透传新建站、网络调度2.3 启动站与从动站一次完整交互是谁在主导PPT 用第 9 页专门讲了启动站和从动站的定义发起通讯的一方为启动站响应服务的一方为从动站。这个定义虽然简单但它是理解整个链路层控制域的钥匙。链路控制域的 PRM 位启动标志位就是用来标记方向的——主站到子站为 1子站到主站为 0。链路控制域的各个位在平衡和非平衡模式下定义还不同。非平衡模式下子站方向有 ACD有一级数据标识和 DFC流量控制标识平衡模式下 ACD 不再使用子站数据通过发送/确认S2方式上送。这两个位的含义直接关系到链路是否卡死后面避坑章我会展开讲。3. IEC-101 帧格式拆解固定帧长与可变帧长的逐字节对照3.1 固定帧长5 个字符链路状态请求全靠它101 的固定帧长帧只有 5 个字符格式是0x10启动字符、Link Control链路控制域、Link Address链路地址域、Check Code校验和、0x16结束字符。这里最容易看花眼的是校验和的计算范围——PPT 写得很清楚Link Control 和 Link Address 累加和的 256 模值。也就是说校验和只覆盖两个字节不包含启动字符和结束字符。我刚开始抓报文的时候总习惯把 0x10 也加进去算校验结果怎么算都对不上还以为是设备厂家报文有问题。后来翻资料才确认固定帧长的校验范围就是链路控制域加链路地址域多算一个字节就全错。这类帧典型用途是请求链路状态和复位远方链路都是链路维护类操作不携带应用层数据。帧格式10 [Link Control] [Link Address] [Check Code] 16 示例 10 49 01 4A 16 校验和0x49 0x01 0x4A取 256 模仍为 0x4A链路控制域 0x49 拆开看PRM1 表示是主站发出的帧功能码为 9 对应请求链路状态FCB 位为 0。这类帧长度恒为 5抓包时一眼就能认出来——看到 10 开头 16 结尾且中间只有三个字节基本可以断定是链路维护帧。3.2 可变帧长长度域怎么数、校验和覆盖到哪个字节可变帧长的结构是0x68 Len Len 0x68开头随后是链路控制域、链路地址域、应用层数据、校验和、0x16结束字符。注意这里有坑启动字符 0x68 出现两次中间夹着两个 Len 字节。Len 表示的是从链路控制域到校验和之前的数据长度——也就是链路控制域、链路地址域、应用层数据三部分加起来的总长度。PPT 里反复强调校验和是链路控制、链路地址、应用层数据所有数据累加和的 256 模值这个范围比固定帧长多了一个应用层数据域。我见过不少人算校验和时只算了链路层头部漏掉 ASDU结果每一帧都被对端丢弃。更隐蔽的问题是 Len 的计算——Len 本身不包含启动字符 0x68也不包含结束字符 0x16很多初学者把整个帧体都数进去导致长度域比实际值多一两个字节。帧格式68 Len Len 68 LinkControl LinkAddress ApplicationData CheckCode 16 示例 68 0C 0C 68 53 01 01 64 01 02 00 00 00 00 00 00 14 16 Len 计算0x0C 12 字节从 53 开始数到校验和前一位正好 12 个字节上面这条实际报文对应的是总召唤确认帧。链路控制域 0x53PRM1功能码 3 发送/确认链路地址 0x01应用层数据为01 64 01 02 00 00 00 00 00 00——类型标识 0x01 总召唤、传输原因 0x02循环、公共地址 0x0100低字节在前、信息体地址 0x000000。完整拆开就是一条标准 ASDU。3.3 非平衡与平衡模式下的链路控制域每一位都有职责链路控制域一个字节能拆出 8 个位每个位在平衡和非平衡模式下职责还不同。非平衡模式下主站到子站的字节结构是RES PRM FCB FCV 功能码子站到主站则是ACD DFC 功能码。PPT 里给了几个关键定义FCV 是 FCB 有效位S2、S3 服务时为 1S1 服务时为 0FCB 是帧计数位主站每向从站发起新一轮的发送/确认或请求/响应传输服务时取反。FCB 的翻转规则是很多人第一次调 101 链路时翻车的地方。主站为每个从站保存一个 FCB 拷贝如果超时没收到应答就重发重发时 FCB 保持不变重发次数最多 3 次。也就是说同一轮传输服务内重发的帧 FCB 是相同的只有进入新的一轮服务时 FCB 才翻转。如果你在调试时发现从站一直不回确认先别急着查线路数一数主站是不是 FCB 翻转逻辑出了问题——从站会丢弃 FCB 不对的帧。平衡模式下多了一个 DIR 位方向标志主到子为 1子到主为 0ACD 位不再使用子站数据通过 S2 服务发送。我一般调试时看见平衡模式就把 FCB 的关注度降一档重点看 DIR 和 PRM 的配合是否一致。4. 三种服务类型与应用层结构S1/S2/S3 决定了你能不能拿到数据4.1 发送/无应答、发送/确认、请求/响应什么时候用哪个PPT 把服务类型分成三档每一档对应的可靠性和适用场景完全不同。S1发送/无应答从动站无须回答启动站也不知道对方是否收到典型用途是校时——广播一条时间报文出去不确认丢了就丢了。S2发送/确认从动站接收后必须回确认报文通常用于发送参数、控制命令。S3请求/响应从动站用数据响应请求典型场景是召唤数据和请求链路状态。提示实际调试时S1 服务的报文抓包成功率是最低的因为它没有确认机制发了就完事了。如果你发现校时总是不准先怀疑链路丢帧而不是马上查时钟源。我第一次调 101 链路时犯过一个印象深刻的错把遥控命令用 S1 服务发出去结果执行机构纹丝不动。后来对照 PPT 才发现遥控属于控制命令链路层必须用 S2发送/确认从站收到后还要回一个确认帧主站收到确认才算完成一轮传输。S1 只适合校时这类丢了也无所谓的场景。4.2 应用层五要素类型标识、可变结构限定词、传输原因、公共地址、信息体地址可变帧长的应用层ASDU部分是理解 101/104 的核心。PPT 用一个表格精准概括了五个字段的职责类型标识回答什么类型帧可变结构限定词回答如何解析传输原因回答什么原因传输公共地址回答什么地址信息体地址回答哪个数据点。这五要素缺一不可抓包分析时按顺序逐个字段读基本不会走偏。可变结构限定词要注意低字节的 SQ 位——SQ0 表示信息体地址逐个连续SQ1 表示地址连续递增。解析时如果忘了看这个位遇到多个信息体可能把地址搞错。传输原因分两大类主动上送如 0x03 突发、0x0A 总召唤结束和请求响应如 0x06 激活、0x07 激活确认调试时先看传输原因就能判断这条报文是谁先发起的。表常用类型标识速查来源 PPT 第19页类型标识含义常用场景0x01总召唤遥信、变位遥信主站下发总召唤0x02SOE 事项带时标的事件顺序记录0x09越限遥测遥测越限告警0x0F电度量电能数据采集0x15总召唤遥测量总召唤后遥测上送0x2D / 0x2E遥控45/46断路器分合闸命令0x30遥调设定值下发0x64总召唤主站发起全数据召唤0x65召唤电度量电度数据召唤0x67校时对时命令下发4.3 97 版和 02 版的差异字节长度变化决定报文兼容性101 规约有 97 版和 02 版两个版本很多人调试老站时遇到报文对不上最后发现是版本混用了。PPT 给了一张对比表链路地址长度从 97 版的 1 字节扩展到 02 版的 1~2 字节传输原因长度同样从 1 字节扩展到 1~2 字节应用层公共地址从 1 字节扩展到 1~2 字节信息体地址从固定 2 字节扩展到 2~3 字节时间戳则是 3 字节或 7 字节。用 02 版报文去连一个只认 97 版的旧主站最常见的现象就是主站报帧解析错误然后整帧丢弃。我处理过一起这样的案例某个水电站的 RTU 升级了程序默认启用了 02 版扩展地址结果调度端老主站只能解析 97 版的 1 字节地址双方反复链路复位就是建立不起来。解决方式是在 RTU 配置里把报文版本改回 97 版兼容模式而不是去升级主站——老调度主站的升级周期是按年算的现场根本等不起。信息体地址从 2 字节扩到 3 字节带来的变化更隐蔽。97 版信息体地址范围最大 6553502 版可以到 16777215。如果你新增的测点号超过了 65535老版规约直接地址溢出表现为遥测数据乱跳或错位。规划测点表时我一般会给遥信、遥测、遥脉保留足够的地址分段防止后期扩容撞上限。5. 常见问题排查链路调不通时先查这五个地方5.1 从站一直不回确认帧现象主站下发发送/确认帧后从站没有响应链路始终建立不起来。原因最常见的是 FCB 翻转逻辑不一致。从站会校验 FCB 位如果主站重发时 FCB 没有保持或者本轮服务 FCB 翻转时机不对从站会认为这是非法帧直接丢弃。其次检查链路地址是否匹配——101 的链路地址是子站的标识主站下发时填的是接收站地址子站上传时填的是发送站地址方向搞反了也会被丢弃。解决先用固定帧长的请求链路状态测试从站是否在线。如果这条通了再用 S2 服务发一条用户数据帧观察从站是否回确认。把 FCB 当作一个独立变量排查确认主站每个从站单独维护 FCB 拷贝传输超时重发时保持 FCB 不变只有进入新一轮传输服务时才翻转。5.2 总召唤后遥测数据只有一部分现象主站下发总召唤0x64从站响应的数据帧信息体地址不连续部分测点缺失。原因信息体地址越限。02 版规约下信息体地址可以是 3 字节但如果从站配置里测点地址超过了 97 版兼容范围的 65535或者主站侧按 2 字节解析 02 版的 3 字节地址就会出现高字节丢失表现为大号测点数据串位或缺失。解决核对从站测点表确认所有测点地址都在规约版本允许范围内。如果站点规模大、测点多建议统一启用 02 版 3 字节信息体地址并确保主站侧同步开启了 02 版解析。现场排查时还可以抓一条完整的总召唤响应报文看最后一个信息体地址是否等于理论最大值如果不是说明有测点漏配。5.3 Len 算错导致整帧被丢弃现象抓包工具显示报文格式清晰但装置侧日志报帧长度错误一帧都没解出来。原因Len 字段计算范围不对。Len 表示从链路控制域到校验和之前的数据长度很多初学者把启动字符 0x68 或者结束字符 0x16 也算进去导致 Len 比实际多 1~2 字节。接收方按 Len 截取报文截到错误位置后校验和自然对不上。解决记住 Len 的计数边界——以第二个 0x68 之后为起点以校验和前一字节为终点。发送前在程序里用一个变量累加链路控制域、链路地址域、应用层数据的字节数再填入 Len 字段不要手算。调试时最快捷的验证方法是拿一条已知正确的报文逐字节核对 Len 是否与实际长度一致。5.4 S1 服务发了校时从站时钟还是不准现象主站定时下发校时帧从站时钟仍然每天偏差几秒。原因S1 服务无确认机制发送即结束主站无法知道报文是否到达。串口链路上如果存在干扰或噪声校时帧很容易在物理层被破坏而主站侧完全感知不到。解决确认校时用的服务类型是不是 S1如果是建议在链路质量较差的场景下改用手动校时或改用 S2 服务配合确认机制。另一个办法是缩短校时周期增加发送次数用概率换可靠性。但最根本的方案还是检查串口链路质量——接地、屏蔽、波特率匹配把物理层问题解决了S1 的丢帧率会明显下降。5.5 DFC 置位后链路永久卡死现象从站 DFC 位置 1 后主站持续发送数据但从站一直不回链路看起来像死掉了一样。原因DFC 位表示从站缓冲区已满无法接受新数据。主站收到 DFC1 后应该停止发送数据帧等从站处理完缓冲区后主动清除 DFC 位。但如果主站实现里没有处理 DFC 的逻辑或者从站清除 DFC 的时机不对双方就僵持住了。解决查主站侧代码对 DFC 位的处理逻辑——收到 DFC1 后应当暂停 S2/S3 服务等待从站上报 DFC0 的帧后再恢复发送。从站侧排查缓冲区释放逻辑确认数据被上层取走后 DFC 正确清零。这个问题在非平衡模式下比较常见因为从站只能被动响应缓冲区压力大。6. 把 PPT 变成自己的排查工具三步验证法与一帧多读拿到这份 PPT 之后最有价值的动作不是从头到尾翻一遍而是把它变成排查报文时的案头手册。我自己养成了一套三步验证法第一步抓到报文先看启动字符0x10 结尾 0x16 是固定帧长链路维护帧0x68 开头是可变帧长数据帧第二步校验和先算——固定帧长只算链路控制域加链路地址域可变帧长多算一个应用层数据域先确认帧没被线路干扰弄坏第三步链路控制域逐位拆PRM 决定方向、FCB 决定轮次、DFC 决定是否拥塞功能码决定服务类型。转成 Python 脚本可以让这个过程更省力。下面这个函数能同时处理固定帧长和可变帧长两种格式的校验和验证def parse_101_frame(data: bytes) - dict: 解析 IEC-101 帧返回关键字段和校验结果 result {valid: False, raw: data.hex(), error: } if len(data) 5: result[error] 帧长度不足 return result if data[0] 0x10 and data[-1] 0x16: # 固定帧长10 控制域 地址域 校验 16共 5 字节 chk (data[1] data[2]) % 256 result[frame_type] fixed result[link_ctrl] hex(data[1]) result[link_addr] hex(data[2]) result[check_ok] (chk data[3]) result[valid] True elif data[0] 0x68 and data[3] 0x68: # 可变帧长68 Len Len 68 控制域 地址域 ASDU 校验 16 frame_len data[1] # Len 是从链路控制域到校验和前一位的长度 body data[4:-2] # 去掉启动字符和结束字符 chk_data body[:frame_len - 2] # 链路控制域 地址域 ASDU chk sum(chk_data) % 256 result[frame_type] variable result[link_ctrl] hex(body[0]) result[link_addr] hex(body[1]) result[asdu] body[2:].hex() result[check_ok] (chk data[-2]) result[valid] True else: result[error] 非法的启动字符组合 return result这个脚本我建议你留一个副本在调试笔记本里——抓到的每一帧过一遍解析校验不过直接 alert会比肉眼看十六进制快很多。参数说明固定帧长模式下校验和只覆盖第 1 和第 2 字节脚本里就是data[1] data[2] % 256可变帧长模式下先把data[-2]当作校验字节len 字段就是data[1]需要用它截取参与校验的 body 区间。frame_len - 2是因为 Len 计数从链路控制域开始减掉链路控制域和链路地址域各自的 1 字节才是纯 ASDU 部分的长度——如果你的站点配了 2 字节链路地址这里的-2要改成-3。我从那以后每次链路联调都强制走一遍这个流程抓包、过校验、拆控制域、对功能码四步下来基本能定位九成的问题。这份 PPT 的实用之处也在这里——它不是让你背规约条文而是给你一张查错地图哪一位代表什么、哪一段出问题往哪查翻到对应页就能对上。希望这一套思路帮你在下次碰到链路不通时少走几步弯路。本文还有配套的精品资源点击获取 IEC 101/104规约从入门到排错：帧格式、链路控制与工程调试要点
简介面向电力系统自动化技术人员的IEC规约入门培训PPT教案系统讲解IEC-101与IEC-104等常用规约的基础知识、通信原理与工程应用适合SCADA系统运维、变电站调试及调度自动化岗位的集中培训和自学。资源为单个PPTX演示文稿压缩包共1个文件大小约1.27MB模块化设计便于按章节开展导入式教学。内容涵盖IEC规约概述、101串行通信与104以太网通信的对比、OSI七层模型映射、固定帧长与可变帧长格式、链路控制域和链路地址定义、校验和计算方式、97版与02版字段长度差异以及S1无应答、S2发送/确认、S3请求/响应等传输服务类型并用大量帧结构图解和版本对比表格辅助理解。通过本教案的学习读者能认清平衡传输与非平衡传输的区别理解不同厂商设备间的互操作性原理看懂常见链路报文格式并形成电力调度通信领域的初步排错思路。已有108人学习下载。1. IEC 规约入门从 101 到 104这份 PPT 讲透了电力通信的底牌在电力自动化调试现场摸爬滚打过的工程师都知道厂站和调度主站之间能不能说上话关键就看规约对不对。而 IEC-101 和 IEC-104 这对兄弟几乎承包了国内 SCADA 系统九成以上的远动通信场景——一个守着串口线一个跑在以太网上应用层定义却高度一致。这份 73 页的培训教案把 IEC 规约从体系结构、帧格式到链路层控制域、应用层类型标识全部串了一遍既有 97 版和 02 版的字段差异对照也有固定帧长、可变帧长的逐字节拆解适合刚入门的调试工程师通读也适合干了两年现场却只停留在能通就行层面的兄弟补一补底层逻辑。它解决的不是怎么连上而是报文为什么长这样、出错时看哪一位。2. IEC 规约家族与选型逻辑为什么现场只认 101 和 1042.1 四兄弟的分工串口和网口各管一摊IEC 规约不是一个协议而是一族协议。PPT 里开篇用一张表就把四个主要规约的适用范围和通讯方式划清楚了IEC-101 负责厂站与调度主站之间的串行通讯IEC-102 管电量主站与站内抄表终端IEC-103 面向站内继电保护设备IEC-104 则是厂站与调度主站之间跑以太网。这个分工很关键——你在调试时拿到一个需求第一件事不是打开报文分析工具而是先确认物理通道是什么。提示凡是新上项目先问通道。串口还是网口直接决定你该翻 101 的资料还是 104 的资料。两者的应用层几乎一样但传输机制和排错手段完全不同。实际选型时老站改造常见 101 串口通道透传或专线新建站点基本清一色 104 走以太网。PPT 里还专门强调了一个容易忽略的细节104 规约结构上映射到 OSI 的应用层、传输层、网络层、链路层和物理层而 101 只有三层——应用层、链路层、物理层。这意味着 104 天然继承了 TCP/IP 的可靠性机制而 101 必须在链路层自己处理确认和重发。2.2 相同点与不同点应用层同源传输机制分家101 和 104 最迷惑人的地方就是它们长得太像。PPT 里用了相同点和不同点两个维度来拆。相同点在适用范围都是厂站与主站之间和规约结构应用层定义相同——这就是为什么你学会了 101 的应用层再看 104 的 ASDU 几乎无障碍。不同点集中在通讯方式和服务类型上101 串行、104 以太网101 多采用非平衡传输104 多采用平衡传输。这里有个非常实际的坑非平衡传输意味着只有主站启动站能发起通讯子站从动站只能被动响应。而平衡传输下双方都可以发起通讯过程。调试 104 的时候调度端可能主动下发遥控命令厂站端也可能主动上送变位信息这要求你理解 TCP 连接的两端角色并不完全等同于主站/子站的角色划分。我一般会建议新手先死记一条101 的启动站永远是主站104 里 TCP 的客户端和服务端都可以是启动站。表101 与 104 关键差异速查对比项IEC-101IEC-104物理通道串行RS-232/485以太网TCP/IP传输模式多采用非平衡传输多采用平衡传输OSI 层次应用层、链路层、物理层应用层、传输层、网络层、链路层、物理层链路地址长度97版 1 字节02版 1~2 字节传输时携带在 APCI 中典型场景老站改造、专线透传新建站、网络调度2.3 启动站与从动站一次完整交互是谁在主导PPT 用第 9 页专门讲了启动站和从动站的定义发起通讯的一方为启动站响应服务的一方为从动站。这个定义虽然简单但它是理解整个链路层控制域的钥匙。链路控制域的 PRM 位启动标志位就是用来标记方向的——主站到子站为 1子站到主站为 0。链路控制域的各个位在平衡和非平衡模式下定义还不同。非平衡模式下子站方向有 ACD有一级数据标识和 DFC流量控制标识平衡模式下 ACD 不再使用子站数据通过发送/确认S2方式上送。这两个位的含义直接关系到链路是否卡死后面避坑章我会展开讲。3. IEC-101 帧格式拆解固定帧长与可变帧长的逐字节对照3.1 固定帧长5 个字符链路状态请求全靠它101 的固定帧长帧只有 5 个字符格式是0x10启动字符、Link Control链路控制域、Link Address链路地址域、Check Code校验和、0x16结束字符。这里最容易看花眼的是校验和的计算范围——PPT 写得很清楚Link Control 和 Link Address 累加和的 256 模值。也就是说校验和只覆盖两个字节不包含启动字符和结束字符。我刚开始抓报文的时候总习惯把 0x10 也加进去算校验结果怎么算都对不上还以为是设备厂家报文有问题。后来翻资料才确认固定帧长的校验范围就是链路控制域加链路地址域多算一个字节就全错。这类帧典型用途是请求链路状态和复位远方链路都是链路维护类操作不携带应用层数据。帧格式10 [Link Control] [Link Address] [Check Code] 16 示例 10 49 01 4A 16 校验和0x49 0x01 0x4A取 256 模仍为 0x4A链路控制域 0x49 拆开看PRM1 表示是主站发出的帧功能码为 9 对应请求链路状态FCB 位为 0。这类帧长度恒为 5抓包时一眼就能认出来——看到 10 开头 16 结尾且中间只有三个字节基本可以断定是链路维护帧。3.2 可变帧长长度域怎么数、校验和覆盖到哪个字节可变帧长的结构是0x68 Len Len 0x68开头随后是链路控制域、链路地址域、应用层数据、校验和、0x16结束字符。注意这里有坑启动字符 0x68 出现两次中间夹着两个 Len 字节。Len 表示的是从链路控制域到校验和之前的数据长度——也就是链路控制域、链路地址域、应用层数据三部分加起来的总长度。PPT 里反复强调校验和是链路控制、链路地址、应用层数据所有数据累加和的 256 模值这个范围比固定帧长多了一个应用层数据域。我见过不少人算校验和时只算了链路层头部漏掉 ASDU结果每一帧都被对端丢弃。更隐蔽的问题是 Len 的计算——Len 本身不包含启动字符 0x68也不包含结束字符 0x16很多初学者把整个帧体都数进去导致长度域比实际值多一两个字节。帧格式68 Len Len 68 LinkControl LinkAddress ApplicationData CheckCode 16 示例 68 0C 0C 68 53 01 01 64 01 02 00 00 00 00 00 00 14 16 Len 计算0x0C 12 字节从 53 开始数到校验和前一位正好 12 个字节上面这条实际报文对应的是总召唤确认帧。链路控制域 0x53PRM1功能码 3 发送/确认链路地址 0x01应用层数据为01 64 01 02 00 00 00 00 00 00——类型标识 0x01 总召唤、传输原因 0x02循环、公共地址 0x0100低字节在前、信息体地址 0x000000。完整拆开就是一条标准 ASDU。3.3 非平衡与平衡模式下的链路控制域每一位都有职责链路控制域一个字节能拆出 8 个位每个位在平衡和非平衡模式下职责还不同。非平衡模式下主站到子站的字节结构是RES PRM FCB FCV 功能码子站到主站则是ACD DFC 功能码。PPT 里给了几个关键定义FCV 是 FCB 有效位S2、S3 服务时为 1S1 服务时为 0FCB 是帧计数位主站每向从站发起新一轮的发送/确认或请求/响应传输服务时取反。FCB 的翻转规则是很多人第一次调 101 链路时翻车的地方。主站为每个从站保存一个 FCB 拷贝如果超时没收到应答就重发重发时 FCB 保持不变重发次数最多 3 次。也就是说同一轮传输服务内重发的帧 FCB 是相同的只有进入新的一轮服务时 FCB 才翻转。如果你在调试时发现从站一直不回确认先别急着查线路数一数主站是不是 FCB 翻转逻辑出了问题——从站会丢弃 FCB 不对的帧。平衡模式下多了一个 DIR 位方向标志主到子为 1子到主为 0ACD 位不再使用子站数据通过 S2 服务发送。我一般调试时看见平衡模式就把 FCB 的关注度降一档重点看 DIR 和 PRM 的配合是否一致。4. 三种服务类型与应用层结构S1/S2/S3 决定了你能不能拿到数据4.1 发送/无应答、发送/确认、请求/响应什么时候用哪个PPT 把服务类型分成三档每一档对应的可靠性和适用场景完全不同。S1发送/无应答从动站无须回答启动站也不知道对方是否收到典型用途是校时——广播一条时间报文出去不确认丢了就丢了。S2发送/确认从动站接收后必须回确认报文通常用于发送参数、控制命令。S3请求/响应从动站用数据响应请求典型场景是召唤数据和请求链路状态。提示实际调试时S1 服务的报文抓包成功率是最低的因为它没有确认机制发了就完事了。如果你发现校时总是不准先怀疑链路丢帧而不是马上查时钟源。我第一次调 101 链路时犯过一个印象深刻的错把遥控命令用 S1 服务发出去结果执行机构纹丝不动。后来对照 PPT 才发现遥控属于控制命令链路层必须用 S2发送/确认从站收到后还要回一个确认帧主站收到确认才算完成一轮传输。S1 只适合校时这类丢了也无所谓的场景。4.2 应用层五要素类型标识、可变结构限定词、传输原因、公共地址、信息体地址可变帧长的应用层ASDU部分是理解 101/104 的核心。PPT 用一个表格精准概括了五个字段的职责类型标识回答什么类型帧可变结构限定词回答如何解析传输原因回答什么原因传输公共地址回答什么地址信息体地址回答哪个数据点。这五要素缺一不可抓包分析时按顺序逐个字段读基本不会走偏。可变结构限定词要注意低字节的 SQ 位——SQ0 表示信息体地址逐个连续SQ1 表示地址连续递增。解析时如果忘了看这个位遇到多个信息体可能把地址搞错。传输原因分两大类主动上送如 0x03 突发、0x0A 总召唤结束和请求响应如 0x06 激活、0x07 激活确认调试时先看传输原因就能判断这条报文是谁先发起的。表常用类型标识速查来源 PPT 第19页类型标识含义常用场景0x01总召唤遥信、变位遥信主站下发总召唤0x02SOE 事项带时标的事件顺序记录0x09越限遥测遥测越限告警0x0F电度量电能数据采集0x15总召唤遥测量总召唤后遥测上送0x2D / 0x2E遥控45/46断路器分合闸命令0x30遥调设定值下发0x64总召唤主站发起全数据召唤0x65召唤电度量电度数据召唤0x67校时对时命令下发4.3 97 版和 02 版的差异字节长度变化决定报文兼容性101 规约有 97 版和 02 版两个版本很多人调试老站时遇到报文对不上最后发现是版本混用了。PPT 给了一张对比表链路地址长度从 97 版的 1 字节扩展到 02 版的 1~2 字节传输原因长度同样从 1 字节扩展到 1~2 字节应用层公共地址从 1 字节扩展到 1~2 字节信息体地址从固定 2 字节扩展到 2~3 字节时间戳则是 3 字节或 7 字节。用 02 版报文去连一个只认 97 版的旧主站最常见的现象就是主站报帧解析错误然后整帧丢弃。我处理过一起这样的案例某个水电站的 RTU 升级了程序默认启用了 02 版扩展地址结果调度端老主站只能解析 97 版的 1 字节地址双方反复链路复位就是建立不起来。解决方式是在 RTU 配置里把报文版本改回 97 版兼容模式而不是去升级主站——老调度主站的升级周期是按年算的现场根本等不起。信息体地址从 2 字节扩到 3 字节带来的变化更隐蔽。97 版信息体地址范围最大 6553502 版可以到 16777215。如果你新增的测点号超过了 65535老版规约直接地址溢出表现为遥测数据乱跳或错位。规划测点表时我一般会给遥信、遥测、遥脉保留足够的地址分段防止后期扩容撞上限。5. 常见问题排查链路调不通时先查这五个地方5.1 从站一直不回确认帧现象主站下发发送/确认帧后从站没有响应链路始终建立不起来。原因最常见的是 FCB 翻转逻辑不一致。从站会校验 FCB 位如果主站重发时 FCB 没有保持或者本轮服务 FCB 翻转时机不对从站会认为这是非法帧直接丢弃。其次检查链路地址是否匹配——101 的链路地址是子站的标识主站下发时填的是接收站地址子站上传时填的是发送站地址方向搞反了也会被丢弃。解决先用固定帧长的请求链路状态测试从站是否在线。如果这条通了再用 S2 服务发一条用户数据帧观察从站是否回确认。把 FCB 当作一个独立变量排查确认主站每个从站单独维护 FCB 拷贝传输超时重发时保持 FCB 不变只有进入新一轮传输服务时才翻转。5.2 总召唤后遥测数据只有一部分现象主站下发总召唤0x64从站响应的数据帧信息体地址不连续部分测点缺失。原因信息体地址越限。02 版规约下信息体地址可以是 3 字节但如果从站配置里测点地址超过了 97 版兼容范围的 65535或者主站侧按 2 字节解析 02 版的 3 字节地址就会出现高字节丢失表现为大号测点数据串位或缺失。解决核对从站测点表确认所有测点地址都在规约版本允许范围内。如果站点规模大、测点多建议统一启用 02 版 3 字节信息体地址并确保主站侧同步开启了 02 版解析。现场排查时还可以抓一条完整的总召唤响应报文看最后一个信息体地址是否等于理论最大值如果不是说明有测点漏配。5.3 Len 算错导致整帧被丢弃现象抓包工具显示报文格式清晰但装置侧日志报帧长度错误一帧都没解出来。原因Len 字段计算范围不对。Len 表示从链路控制域到校验和之前的数据长度很多初学者把启动字符 0x68 或者结束字符 0x16 也算进去导致 Len 比实际多 1~2 字节。接收方按 Len 截取报文截到错误位置后校验和自然对不上。解决记住 Len 的计数边界——以第二个 0x68 之后为起点以校验和前一字节为终点。发送前在程序里用一个变量累加链路控制域、链路地址域、应用层数据的字节数再填入 Len 字段不要手算。调试时最快捷的验证方法是拿一条已知正确的报文逐字节核对 Len 是否与实际长度一致。5.4 S1 服务发了校时从站时钟还是不准现象主站定时下发校时帧从站时钟仍然每天偏差几秒。原因S1 服务无确认机制发送即结束主站无法知道报文是否到达。串口链路上如果存在干扰或噪声校时帧很容易在物理层被破坏而主站侧完全感知不到。解决确认校时用的服务类型是不是 S1如果是建议在链路质量较差的场景下改用手动校时或改用 S2 服务配合确认机制。另一个办法是缩短校时周期增加发送次数用概率换可靠性。但最根本的方案还是检查串口链路质量——接地、屏蔽、波特率匹配把物理层问题解决了S1 的丢帧率会明显下降。5.5 DFC 置位后链路永久卡死现象从站 DFC 位置 1 后主站持续发送数据但从站一直不回链路看起来像死掉了一样。原因DFC 位表示从站缓冲区已满无法接受新数据。主站收到 DFC1 后应该停止发送数据帧等从站处理完缓冲区后主动清除 DFC 位。但如果主站实现里没有处理 DFC 的逻辑或者从站清除 DFC 的时机不对双方就僵持住了。解决查主站侧代码对 DFC 位的处理逻辑——收到 DFC1 后应当暂停 S2/S3 服务等待从站上报 DFC0 的帧后再恢复发送。从站侧排查缓冲区释放逻辑确认数据被上层取走后 DFC 正确清零。这个问题在非平衡模式下比较常见因为从站只能被动响应缓冲区压力大。6. 把 PPT 变成自己的排查工具三步验证法与一帧多读拿到这份 PPT 之后最有价值的动作不是从头到尾翻一遍而是把它变成排查报文时的案头手册。我自己养成了一套三步验证法第一步抓到报文先看启动字符0x10 结尾 0x16 是固定帧长链路维护帧0x68 开头是可变帧长数据帧第二步校验和先算——固定帧长只算链路控制域加链路地址域可变帧长多算一个应用层数据域先确认帧没被线路干扰弄坏第三步链路控制域逐位拆PRM 决定方向、FCB 决定轮次、DFC 决定是否拥塞功能码决定服务类型。转成 Python 脚本可以让这个过程更省力。下面这个函数能同时处理固定帧长和可变帧长两种格式的校验和验证def parse_101_frame(data: bytes) - dict: 解析 IEC-101 帧返回关键字段和校验结果 result {valid: False, raw: data.hex(), error: } if len(data) 5: result[error] 帧长度不足 return result if data[0] 0x10 and data[-1] 0x16: # 固定帧长10 控制域 地址域 校验 16共 5 字节 chk (data[1] data[2]) % 256 result[frame_type] fixed result[link_ctrl] hex(data[1]) result[link_addr] hex(data[2]) result[check_ok] (chk data[3]) result[valid] True elif data[0] 0x68 and data[3] 0x68: # 可变帧长68 Len Len 68 控制域 地址域 ASDU 校验 16 frame_len data[1] # Len 是从链路控制域到校验和前一位的长度 body data[4:-2] # 去掉启动字符和结束字符 chk_data body[:frame_len - 2] # 链路控制域 地址域 ASDU chk sum(chk_data) % 256 result[frame_type] variable result[link_ctrl] hex(body[0]) result[link_addr] hex(body[1]) result[asdu] body[2:].hex() result[check_ok] (chk data[-2]) result[valid] True else: result[error] 非法的启动字符组合 return result这个脚本我建议你留一个副本在调试笔记本里——抓到的每一帧过一遍解析校验不过直接 alert会比肉眼看十六进制快很多。参数说明固定帧长模式下校验和只覆盖第 1 和第 2 字节脚本里就是data[1] data[2] % 256可变帧长模式下先把data[-2]当作校验字节len 字段就是data[1]需要用它截取参与校验的 body 区间。frame_len - 2是因为 Len 计数从链路控制域开始减掉链路控制域和链路地址域各自的 1 字节才是纯 ASDU 部分的长度——如果你的站点配了 2 字节链路地址这里的-2要改成-3。我从那以后每次链路联调都强制走一遍这个流程抓包、过校验、拆控制域、对功能码四步下来基本能定位九成的问题。这份 PPT 的实用之处也在这里——它不是让你背规约条文而是给你一张查错地图哪一位代表什么、哪一段出问题往哪查翻到对应页就能对上。希望这一套思路帮你在下次碰到链路不通时少走几步弯路。本文还有配套的精品资源点击获取