简介：这份资源面向电力自动化、远动通信方向的开发者与运维人员，聚焦IEC 101规约（IEC 60870-5系列）在RTU与主站通信中的报文解析与实现，尤其涉及南瑞设备的101规约应用。包内共2个文件，以1个cpp源码和1个txt说明文档为主，压缩包约13KB，体量轻便，便于直接阅读与二次开发。源码可用于对照理解101报文的帧头、控制域、地址域、信息域与帧尾结构，以及遥信变位20报文、遥测数据上报等典型交互逻辑；txt文档则提供配套说明与参考信息，帮助快速定位关键实现。已有789人学习下载，说明该主题在电力通信调试与协议学习中具有一定关注度。对于需要排查南瑞101设备通信问题、梳理报文收发流程或搭建协议解析原型的读者，这份小而实用的代码与文档组合可作为入门与排错的参考素材。
1. 南瑞101规约报文解析：从RTU101.rar里翻出可复现的调试路径
手上拿到一个叫rtu101.rar的压缩包，里面是南瑞的 IEC 101 规约实现，配套还有一堆抓包报文，这种场景在变电站自动化调试里太常见了。IEC 101 规约（也叫 IEC 60870-5-101）是国内电力系统运动通信的底层标准之一，南瑞的 RTU 设备大量使用它做串口主从通信。问题在于，规约文档厚得像砖头，报文十六进制看着像天书，现场调试时链路不通、总召唤没响应、遥测值跳变，往往只能靠经验和抓包工具硬扛。这篇笔记面向的是需要对接南瑞 101 规约的嵌入式工程师、自动化调试人员和协议开发新手，目标是把「报文长什么样、怎么解析、参数怎么配、坑在哪」这条链路走通，让你拿到rtu101.rar这类资料后能自己拆出可用的调试方法，而不是对着文档干瞪眼。
2. IEC 101 规约的帧结构与南瑞实现的报文特征
2.1 三种帧格式：固定帧、可变帧、单字符
IEC 101 规约在链路层定义了三种帧格式，这是解析任何一条报文的第一道门槛。固定帧长 5 字节，用于链路控制（如请求链路状态、复位链路）；可变帧长度不固定，承载应用层数据（如总召唤、遥测上送）；单字符帧就是一个 0xE5，用于确认。南瑞的 RTU 实现严格遵循这套格式，但在具体字段填充上有自己的习惯，比如链路地址的默认值和信息体地址的起始偏移，这些在rtu101.rar的配置文件中通常能找到线索。
固定帧的结构是：启动字符 0x10 + 控制域 1 字节 + 链路地址 1 字节 + 校验和 1 字节 + 结束字符 0x16。可变帧则是：启动字符 0x68 + 长度域 1 字节 + 长度域重复 1 字节 + 启动字符 0x68 + 控制域 1 字节 + 链路地址 1 字节 + 应用层数据 + 校验和 + 结束字符 0x16。校验和的计算范围是从控制域第一个字节到应用层数据最后一个字节的算术和取低 8 位。很多新手第一次解析时会把长度域算错，导致后面所有字段偏移全乱。
南瑞的 101 实现里，控制域的功能码定义和标准一致，但发送序号和接收序号的翻转逻辑在调试中容易让人迷惑。控制域的低 4 位是功能码，高 4 位在信息传输格式中拆分为发送序号和接收序号。I ㊣ 格式帧用于编号的信息传输，S 格式帧用于编号的监视功能，U 格式帧用于未编号的控制功能。南瑞设备在链路建立阶段通常先发 U 格式的请求链路状态帧，收到确认后再进入 I 格式的数据传输。
2.2 应用层数据单元：ASDU 的类型标识与信息体
ASDU 是应用服务数据单元，是可变帧里真正承载业务数据的部分。它的结构是：类型标识 1 字节 + 可变结构限定词 1 字节 + 传送原因 2 字节 + 公共地址 2 字节 + 信息体地址 3 字节 + 信息体 + 时标（可选）。类型标识决定了这条报文是干什么的，比如 0x64 是总召唤，0x01 是单点遥信，0x09 是归一化遥测，0x0B 是标度化遥测，0x0D 是浮点遥测。
可变结构限定词的最高位表示信息体地址是否连续，低 7 位表示信息体个数。这个字节是解析时最容易翻车的地方：如果最高位是 1，表示后续信息体地址连续，只需要解析第一个地址然后递增；如果是 0，表示每个信息体都带独立地址，需要逐个读取。南瑞的 RTU 在遥测上送时通常使用连续地址模式，但在遥信变位上报时可能使用离散模式，具体取决于设备配置。
传送原因占 2 字节，低字节是原因码，高字节是源发站地址。常见原因码：0x03 是突发，0x05 是请求或被请求，0x06 是激活，0x07 是激活确认，0x0A 是激活终止，0x14 是响应站召唤。公共地址在 101 规约里通常对应 RTU 的站地址，南瑞设备默认可能是 1 或 255，需要和主站配置一致。信息体地址是 3 字节小端序，遥测通常从 0x4001 开始，遥信从 0x0001 开始，电度从 0x6401 开始，这些偏移量在南瑞的规约点表里有明确定义。
2.3 南瑞 RTU101 的报文抓取与初步识别
拿到rtu101.rar后，第一步不是急着看代码，而是把里面的报文样本文件找出来。常见的格式是.txt或.log，里面是十六进制字符串，可能带时间戳。用串口调试助手或专门的 101 规约分析工具打开，先看有没有 0x68 或 0x10 开头的行。南瑞的报文样本通常会标注方向，比如「主站→RTU」和「RTU→主站」，这对理解交互流程很关键。
识别一条报文时，先看第一个字节。如果是 0x68，就是可变帧，接着读第二个字节得到长度，然后跳过两个字节（长度重复和第二个 0x68），从第五个字节开始是控制域。如果是 0x10，就是固定帧，直接读控制域和链路地址。如果是 0xE5，就是单字符确认。这个判断逻辑用几行 Python 就能实现，后面会给出代码。
南瑞的 101 实现里有一个细节：链路地址在固定帧和可变帧里都是 1 字节，但有些老版本设备会把它扩展成 2 字节，这会导致按标准解析时校验和对不上。遇到校验和错误时，先确认链路地址长度，再检查校验和计算范围是否包含了启动字符和长度域——标准规定校验和不包含启动字符、长度域和结束字符，只算控制域到应用层数据。
3. 用 Python 解析 101 报文：从十六进制到结构化数据
3.1 搭建最小解析环境与报文输入
不需要复杂的框架，一个 Python 3 环境加标准库就够了。我一般会建一个parse_101.py，把报文样本作为字符串列表硬编码进去，方便反复调试。如果你有rtu101.rar里的实际抓包文件，可以用open()读取后按行处理。关键是要把十六进制字符串转成bytes对象，注意去掉空格和换行。
# parse_101.py # 最小 101 报文解析环境，输入为十六进制字符串 import struct # 示例报文：南瑞 RTU 总召唤激活帧（可变帧） # 68 09 09 68 73 01 64 01 06 00 01 00 00 00 14 16 raw_hex = "68 09 09 68 73 01 64 01 06 00 01 00 00 00 14 16" def hex_to_bytes(hex_str): """去掉空格，转成 bytes""" clean = hex_str.replace(" ", "").replace("\n", "") return bytes.fromhex(clean) frame = hex_to_bytes(raw_hex) print(f"帧总长度: {len(frame)} 字节") print(f"原始字节: {frame.hex(' ').upper()}")这段代码的输出会告诉你帧的实际长度和十六进制表示。注意bytes.fromhex()要求字符串长度是偶数，如果抓包数据里有奇数个字符，需要先补零或检查是否漏读。参数说明：raw_hex替换成你自己的报文，hex_to_bytes里的replace链可以扩展处理制表符等空白字符。
3.2 帧类型判断与校验和验证
拿到bytes后，先判断帧类型。固定帧以 0x10 开头，可变帧以 0x68 开头，单字符帧就是 0xE5。判断完类型后，可变帧需要验证校验和。校验和的计算范围是从控制域（第 5 个字节，索引 4）到应用层数据最后一个字节（倒数第 3 个字节，索引 -3），不包含结束字符 0x16。
def check_frame(frame): """判断帧类型并验证校验和""" if len(frame) == 1 and frame[0] == 0xE5: return "单字符帧", True if frame[0] == 0x10: # 固定帧：10 控制域 链路地址 校验和 16 if len(frame) != 5: return "固定帧长度错误", False calc_sum = sum(frame[1:3]) & 0xFF return "固定帧", calc_sum == frame[3] if frame[0] == 0x68: # 可变帧：68 长度 长度 68 控制域 链路地址 ASDU... 校验和 16 if len(frame) < 6: return "可变帧长度不足", False length = frame[1] if frame[2] != length or frame[3] != 0x68: return "可变帧长度域或启动字符错误", False # 校验和范围：索引 4 到 4+length-1（即倒数第3个字节之前） calc_sum = sum(frame[4:4+length]) & 0xFF recv_sum = frame[4+length] return "可变帧", calc_sum == recv_sum return "未知帧类型", False frame_type, checksum_ok = check_frame(frame) print(f"帧类型: {frame_type}, 校验和: {'通过' if checksum_ok else '失败'}")逻辑说明：固定帧的校验和只算控制域和链路地址两个字节；可变帧的校验和算控制域开始、长度为length的所有字节。参数length是长度域的值，表示从控制域到应用层数据最后一个字节的字节数。如果校验和不通过，先检查报文是否完整，再检查长度域是否读对。南瑞设备在某些版本里长度域可能包含校验和本身，这是血泪经验——遇到校验和总是差一个字节时，试试把长度域加 1 再算。
3.3 解析控制域与 ASDU 核心字段
校验通过后，开始拆控制域和 ASDU。控制域的格式取决于帧是 I 格式、S 格式还是 U 格式。判断方法：看控制域最低两位。如果最低位是 0，是 I 格式；如果最低两位是 01，是 S 格式；如果最低两位是 11，是 U 格式。I 格式里，控制域的第 1 字节低 7 位是发送序号，第 2 字节低 7 位是接收序号，最高位分别是两个序号的最高位。
def parse_control(ctrl_bytes): """解析控制域，返回格式和序号""" ctrl = ctrl_bytes[0] | (ctrl_bytes[1] << 8) if (ctrl & 0x01) == 0: # I 格式 tx = ((ctrl >> 1) & 0x7F) | ((ctrl >> 8) & 0x80) rx = ((ctrl >> 9) & 0x7F) | ((ctrl >> 8) & 0x80) # 简化处理，实际需按位拆 return "I", tx, rx elif (ctrl & 0x03) == 0x01: return "S", None, None elif (ctrl & 0x03) == 0x03: return "U", None, None return "未知", None, None # 对示例报文，控制域在索引 4 和 5 ctrl_fmt, tx_seq, rx_seq = parse_control(frame[4:6]) print(f"控制域格式: {ctrl_fmt}, 发送序号: {tx_seq}, 接收序号: {rx_seq}")ASDU 从控制域和链路地址之后开始。对于可变帧，链路地址在索引 6，ASDU 从索引 7 开始。类型标识是第一个字节，可变结构限定词是第二个字节，传送原因从第三个字节开始占 2 字节，公共地址占 2 字节，信息体地址占 3 字节。解析时注意小端序：传送原因、公共地址、信息体地址都是低字节在前。
def parse_asdu(asdu_bytes): """解析 ASDU 头部""" type_id = asdu_bytes[0] vsq = asdu_bytes[1] cot = asdu_bytes[2] | (asdu_bytes[3] << 8) ca = asdu_bytes[4] | (asdu_bytes[5] << 8) ioa = asdu_bytes[6] | (asdu_bytes[7] << 8) | (asdu_bytes[8] << 16) num_info = vsq & 0x7F is_continuous = (vsq & 0x80) != 0 return { "类型标识": hex(type_id), "信息体个数": num_info, "地址连续": is_continuous, "传送原因": hex(cot), "公共地址": ca, "信息体地址": hex(ioa) } # 示例报文中 ASDU 从索引 7 开始 asdu_info = parse_asdu(frame[7:]) for k, v in asdu_info.items(): print(f"{k}: {v}")参数说明：vsq的最高位是地址连续标志，低 7 位是信息体个数。cot的低字节是原因码，高字节是源发站地址。ioa是 3 字节小端序，南瑞的遥测点表里这个地址通常对应具体的测量量。如果num_info大于 1 且is_continuous为真，后续信息体地址依次加 1；否则需要按每个信息体单独解析地址。
4. 南瑞 101 规约调试避坑：链路、参数与报文异常排查
4.1 链路始终建不起来：先查物理层再查链路地址
现象：主站发请求链路状态帧，RTU 无响应，串口调试助手上看不到任何回码。原因通常有三层：物理层接线错误（RS-232 的 2、3 脚交叉，RS-485 的 A、B 反接）、串口参数不匹配（波特率、数据位、停止位、校验位）、链路地址不一致。解决步骤：先用万用表确认 RS-485 的 A 对 B 有差分电压，再用示波器看 RTU 的发送脚有没有波形。如果物理层正常，检查主站和 RTU 的链路地址是否一致，南瑞设备默认链路地址可能是 1，但有些工程会改成 255。在rtu101.rar的配置文件里搜索link_addr或链路地址关键字，确认实际值。
4.2 总召唤无响应或响应超时：公共地址与传送原因要对齐
现象：链路建立后，主站发总召唤激活帧（类型标识 0x64，传送原因 0x06），RTU 回了激活确认（0x64，0x07），但后续的总召唤数据帧一直不来。原因可能是公共地址不匹配。总召唤帧里的公共地址必须和 RTU 配置的站地址一致，南瑞设备有些版本要求公共地址等于链路地址，有些则允许独立配置。解决：抓包对比主站发出的公共地址和 RTU 配置文件里的common_addr，改成一致。另外，总召唤的传送原因在激活帧里是 0x06，激活确认是 0x07，激活终止是 0x0A，如果 RTU 回了 0x47（原因码 0x47 表示未知类型标识），说明 RTU 不支持该类型标识，需要检查点表配置。
4.3 遥测值跳变或明显错误：信息体地址与数据类型要核对
现象：总召唤上来的遥测值一会儿是 0，一会儿是满量程，或者数值明显不对。原因通常是信息体地址对错了，或者数据类型解析错了。南瑞的遥测类型标识可能是 0x09（归一化值）、0x0B（标度化值）、0x0D（浮点数）。归一化值是 2 字节有符号数，范围 -1 到 1-2^-15，需要乘以量程系数；标度化值是 2 字节有符号整数，直接对应工程值；浮点数是 4 字节 IEEE 754。解决：先确认 RTU 点表里每个遥测点的类型标识和信息体地址，再在解析代码里按对应格式解包。如果地址对不上，遥测值会串到别的测量量上，看起来就是跳变。
4.4 校验和频繁失败：长度域和链路地址长度是重灾区
现象：抓包工具显示校验和错误，但报文看起来完整。原因有两个常见坑：一是长度域的计算范围理解错误，南瑞某些版本的长度域包含了校验和字节本身，导致按标准算时差一个字节；二是链路地址长度不是 1 字节，有些老设备用 2 字节链路地址，导致后续所有字段偏移错位。解决：先用已知正确的报文反推长度域和校验和的关系，写一个小的校验和计算函数，遍历可能的长度偏移，找到能通过校验的那个。如果链路地址是 2 字节，解析时把链路地址后的所有字段偏移加 1。
4.5 报文粘包与半包：串口读取要按帧头切分
现象：串口调试助手收到的数据一坨一坨的，有时候两条报文粘在一起，有时候一条报文被截断。原因：串口是字节流，没有消息边界，RTU 和主站的发送节奏不一致时就会粘包或半包。解决：在接收端维护一个缓冲区，按帧头（0x68 或 0x10）切分。遇到 0x68 时，读取后续的长度域，然后等缓冲区里凑够长度 + 6个字节再解析。遇到 0x10 时，等凑够 5 字节。这个逻辑在 Python 里用bytearray实现最方便，每次recv后追加到缓冲区，然后循环尝试解析完整帧。
5. 从报文到点表：用解析结果反向验证南瑞 RTU 配置
5.1 构建报文-点表映射表
解析出 ASDU 后，最有价值的动作是把信息体地址和实际物理量对应起来。南瑞的 RTU 点表通常是一个 Excel 或 CSV，里面列了每个遥测、遥信、电度的信息体地址、类型标识、量程系数和描述。我一般会写一个脚本，把抓包解析出的所有信息体地址去重点出来，然后和点表做交集，快速定位哪些点没上送、哪些点上送了但点表里没有。
| 信息体地址 | 类型标识 | 解析值 | 点表描述 | 量程系数 | 工程值 |
|---|---|---|---|---|---|
| 0x4001 | 0x09 | 0x1234 | A相电压 | 0.01 | 46.60 |
| 0x4002 | 0x09 | 0x2345 | B相电压 | 0.01 | 90.29 |
| 0x4003 | 0x0D | 0x42F60000 | 频率 | 1.0 | 123.0 |
| 0x0001 | 0x01 | 0x01 | 断路器位置 | 无 | 合位 |
这张表是调试时的核心依据。如果某个地址在报文里出现了但点表里没有，说明点表漏配；如果点表里有但报文里没出现，说明 RTU 没上送该点，需要检查 RTU 的配置里该点是否使能。
5.2 用解析脚本批量处理抓包文件
rtu101.rar里的报文样本可能有很多条，手动解析不现实。写一个批量处理脚本，读取整个抓包文件，按行解析，输出每条报文的摘要信息。这样能快速看出总召唤的完整流程：主站发激活帧 → RTU 回激活确认 → RTU 发数据帧 → 主站回确认 → RTU 发激活终止。
def batch_parse(file_path): """批量解析抓包文件，每行一条十六进制报文""" with open(file_path, "r", encoding="utf-8") as f: for line_num, line in enumerate(f, 1): line = line.strip() if not line or line.startswith("#"): continue try: frame = hex_to_bytes(line) ftype, ok = check_frame(frame) if ftype == "可变帧" and ok: asdu = parse_asdu(frame[7:]) print(f"行{line_num}: {ftype} | 类型={asdu['类型标识']} " f"原因={asdu['传送原因']} 地址={asdu['信息体地址']} " f"个数={asdu['信息体个数']}") else: print(f"行{line_num}: {ftype} | 校验={'通过' if ok else '失败'}") except Exception as e: print(f"行{line_num}: 解析异常 {e}") # 用法：batch_parse("rtu101_capture.txt")参数说明：file_path是抓包文件路径，每行一条报文，支持#开头的注释行。这个脚本的输出能让你一眼看出总召唤流程是否完整，哪一步断了。如果发现 RTU 只回了激活确认但没有后续数据帧，重点检查 RTU 的点表配置和总召唤使能位。
5.3 反向验证：用已知工程值反推量程系数
如果点表里的量程系数不确定，可以用已知的工程值反推。比如你现场用万用表量到 A 相电压是 220V，报文里解析出的原始归一化值是 0x5C28（十进制 23592），归一化值的满量程是 32767 对应 1.0，那么工程值 = 23592 / 32767 * 量程。反推量程 = 220 / (23592 / 32767) ≈ 305.5。这个值应该和点表里的量程系数一致，如果不一致，说明点表配错了或者报文解析的类型标识搞错了。这个方法在调试现场特别管用，不需要等主站工程师确认点表，自己就能验证。
5.4 把解析逻辑固化成一个可复用的调试工具
每次调试都重写解析代码太累，我习惯把上面的函数封装成一个命令行工具，支持三种模式：单条报文解析、批量文件解析、实时串口解析。实时模式用pyserial读串口，按帧头切分后调用解析函数，输出到控制台。这样在现场接上串口就能看报文，不用依赖主站软件。工具的核心是帧切分逻辑，必须处理粘包和半包，否则实时解析会频繁报错。一个稳定的做法是：维护一个bytearray缓冲区，每次读到新数据就追加，然后循环检查缓冲区开头是否是 0x68 或 0x10，如果是 0x68 就等长度域指示的完整帧，如果是 0x10 就等 5 字节，凑够就弹出解析，不够就继续等。
提示：实时解析时，串口的超时设置建议为 0.1 秒，避免阻塞。如果 RTU 发送频率高，控制台输出可能刷屏，可以加一个过滤条件，只打印类型标识为 0x64、0x09、0x0D 的报文。
6. 进阶：用 101 规约的时标与品质位做故障定位
6.1 解析时标：CP56Time2a 的 7 字节结构
带时标的 ASDU 在信息体后面会附加 7 字节的 CP56Time2a 时间。结构是：毫秒低字节、毫秒高字节（0-59999）、分钟（低 6 位有效）、小时（低 5 位有效）、日（低 5 位有效）、月（低 4 位有效）、年（低 7 位有效，范围 0-99）。南瑞的 RTU 在遥信变位和 SOE 上报时会带时标，遥测总召唤通常不带。解析时标能帮你定位事件发生的精确时间，对比主站收到的时间就能算出通信延迟。
def parse_cp56time2a(data): """解析 7 字节 CP56Time2a""" ms = data[0] | (data[1] << 8) minute = data[2] & 0x3F hour = data[3] & 0x1F day = data[4] & 0x1F month = data[5] & 0x0F year = data[6] & 0x7F return f"{year:02d}-{month:02d}-{day:02d} {hour:02d}:{minute:02d}:{ms//1000:02d}.{ms%1000:03d}" # 假设时标从某个偏移开始 # ts = parse_cp56time2a(frame[offset:offset+7])参数说明：毫秒值范围 0-59999，除以 1000 得到秒，取余得到毫秒。分钟、小时、日、月、年都做了位掩码，因为高位可能被置位表示无效或夏令时。如果解析出的年份是 0，说明时标无效，RTU 可能没有对时。
6.2 品质位：IV、NT、SB、BL 的含义与排查
遥测和遥信信息体里通常有一个品质位字节（QDS），位定义：IV（无效）、NT（非当前值）、SB（被取代）、BL（被闭锁）、OV（溢出）。如果 IV 位为 1，说明这个测量值无效，主站应该丢弃。NT 位为 1 表示值不是当前采样值，可能是缓存的历史值。SB 位为 1 表示值被人工置数取代。BL 位为 1 表示值被闭锁，不参与逻辑计算。调试时如果发现某个遥测值一直是 0 但品质位 IV 为 1，说明 RTU 的该通道故障或未接线。如果 NT 为 1，说明 RTU 的采样周期和上送周期不匹配，需要检查 RTU 的采集配置。
6.3 用 Wireshark 插件或自定义解析器做可视化
如果抓包数据量大，控制台输出不够直观，可以用 Wireshark 的自定义解析器功能，把 101 报文按字段着色显示。Wireshark 支持 Lua 脚本解析自定义协议，写一个简单的 Lua 脚本，识别 0x68 和 0x10 帧头，然后按字段偏移标注类型标识、传送原因、信息体地址。这样在 Wireshark 里就能像看 TCP 报文一样看 101 报文，过滤特定类型标识的帧特别方便。不过 Lua 脚本的调试成本不低，如果只是偶尔用，Python 脚本加表格输出已经够了。
6.4 一个具体技巧：用总召唤的激活终止帧判断点表完整性
总召唤流程的最后一步是 RTU 发激活终止帧（类型标识 0x64，传送原因 0x0A）。这个帧本身不携带数据，但它标志着本轮总召唤结束。我习惯在解析脚本里统计激活终止帧之前收到的所有数据帧的信息体个数，然后和点表里的总点数对比。如果少了，说明有些点没上送；如果多了，说明点表里有重复地址或者 RTU 上送了未定义的点。这个对比能在调试初期快速发现点表配置问题，比逐个点核对快得多。血泪经验：南瑞某些版本的 RTU 在总召唤时会把所有点都上送一遍，包括品质位为 IV 的点，所以统计时要把 IV 为 1 的点排除，否则会误判为点表多了。
6.5 我踩过的坑与留下的习惯
调试 101 规约这些年，最大的教训是不要相信任何「默认配置」。南瑞的 RTU 出厂默认链路地址、公共地址、波特率都可能和现场要求不一致，拿到设备第一件事就是读配置、对点表、抓报文。第二个教训是校验和失败不要慌，先怀疑长度域和链路地址长度，这两个地方翻车概率最高。第三个习惯是每次调试都保留完整的抓包文件，用时间戳命名，事后复盘时能快速定位问题。最后一个习惯是把解析脚本和点表放在同一个目录，脚本输出直接和点表做 diff，减少人工核对。希望帮到你。
本文还有配套的精品资源，点击获取
