★ FEATURED ARTICLE 简介南瑞继保网络103规约是电力系统远动通信领域的重要协议文档基于IEC 60870-5-103标准并针对国内电网环境及南瑞继保设备特点进行了扩展优化面向电力自动化工程师、二次调试人员和协议开发者用于梳理RTU与调度中心之间遥测、遥信、遥控、遥调等“四遥”数据交换的报文结构、命令帧与应答帧规则以及实际组网应用要点。压缩包内为1个doc文档总体积3.38MB以文字说明为主体内容围绕标准103规约下的兼容与扩展展开适合现场调试和日常学习查阅。文档涉及安全性增强、通信性能优化、故障诊断与恢复机制、自定义服务接口、不同网络拓扑适应性以及高效数据编码方式等特征同时介绍了主从通信模式下南瑞继保的调整与应对策略可帮助读者识别报文类型、理解帧格式细节、掌握错误处理流程并应用于变电站自动化、调度主站接入等场景的联调与排障。目前已有1977人学习对于从事电力通信系统设计、设备调试和维护的工程技术人员是一份值得参考的专项资料。1. 网络103规约串口时代的老协议为什么今天还在变电站后台里跑如果你在变电站后台或者继保调试现场待过对“网络103”这个词应该不陌生。它说的是把 IEC 60870-5-103 规约——一套原本跑在 RS-232/RS-485 串口上的继电保护通信规约——搬到以太网 TCP/IP 通道上来跑。装置网口化已经很多年了但保护装置和后台监控之间跑的报文内核还是上世纪就定型的 FT1.2 帧。很多新入行的工程师第一次抓包时会懵明明是网络通信报文里却看不到 TCP 头以外的东西全是 0x68 开头、0x16 结尾的老式帧。这篇文章就围绕“南瑞继保网络103规约”这个方向展开讲清楚网络103和串口103的关系、帧结构长什么样、怎么用最小代码把链路跑通、以及现场调试点表和总召唤时最容易翻车的地方。适合三类人刚接手变电站监控系统调试的工程师、做规约转换或后台接入的开发人员、以及被现场“召唤无响应”折磨的运维。你不需要预先精通 IEC 60870-5-103但看完后至少能独立抓包、切帧、判断问题出在哪一层——是 TCP 没通还是 ASDU 里的公共地址对不上。2. 网络103的帧长什么样FT1.2帧结构、ASDU和TCP承载方式2.1 为什么说是FT1.2而不是TCP报文很多人在第一次抓网络103的包时会下意识地找 TCP 负载里的“应用层协议头”。但网络103没有像 IEC 60870-5-104 那样重新封装 APCI 头它直接把 FT1.2 帧塞进了 TCP 字节流。FT1.2 是 IEC 60870-5-1 里定义的一种帧格式特点是有启动字符、有长度字段、有校验和、有结束字符。帧边界完全靠内容自己标识不依赖 TCP 的包边界。这意味着两件事。第一TCP 粘包和拆包对网络103是常态你不能按“一次 recv 就是一帧”来解析必须自己做缓冲和切帧。第二只要做了可靠的字节流切割串口时代写的那套解析代码几乎可以原样搬到网络上。这也是网络103最大的价值装置固件不需要大改后台软件也不用重写只是把物理层从串口换成了网口。常见做法是后台侧用 TCP 客户端主动连接装置装置侧做 TCP 服务端监听。也可以反过来但现场我见到的九成以上是后台主动建链。调试时先确认这条 TCP 链路通了再去关心 0x68 开头的帧内容顺序不能反。2.2 可变帧长的字节排布与校验规则FT1.2 帧分三种单字符帧、固定帧长帧、可变帧长帧。网络103里大量交互用的是可变帧长帧例如总召唤、遥信变位上送、定值读取。单字符帧只用来做确认固定帧长帧偶尔用在时钟同步这类短命令。可变帧长帧的排布如下表字节位置内容说明0启动字符 0x68固定值1长度 L从控制域到校验和前所有字节数2长度 L 重复与第1字节相同做校验3启动字符 0x68再次出现固定值4控制域 C区分帧类型、主站/从站方向5地址域 A装置地址也叫公共地址6 起ASDU类型标识、传送原因、信息体等末尾-2校验和 CS控制域到 ASDU 最后字节的算术和末尾-1结束字符 0x16固定值校验和算法很简单从控制域 C 开始到 ASDU 最后一个字节为止所有字节累加取低 8 位。不需要 CRC 查表不需要异或就是纯加法。这个细节很多人写错尤其是从 IEC 104 转过来的人惯性用 CRC结果帧发出去装置完全不响应。2.3 ASDU里到底装了什么类型标识、传送原因、信息体ASDU 的全称是 Application Service Data Unit应用服务数据单元。它才是网络103真正要表达的业务内容。一段 ASDU 里最关键的有五个字段类型标识、可变结构限定词、传送原因、公共地址、信息体。类型标识决定了这段 ASDU 是什么——是总召唤命令、带时标的遥信、还是定值写命令。可变结构限定词告诉你后面信息体是个体还是连续数组。传送原因标识这次通信是“激活”“响应”“确认”还是“结束”。公共地址对应装置地址后台靠它区分是哪台保护。信息体则是实际数据开入状态、模拟量、时标等。南县继保这类装置的网络103实现类型标识和传送原因的取值基本符合 IEC 60870-5-103 标准附录里的定义但不同固件版本对某些私有 ASDU 的处理并不完全一致。我的建议是手头一定要放一份厂家规约文本遇到“看起来不符合标准”的帧先查文本不要急着怀疑抓包有问题。标准是底线私有定义才是现场的主角。2.4 网络103与串口103的差异点帧边界识别与TCP粘包串口103时代一帧数据从发到收是完整连续的帧边界天然存在。网络103没有这个物理保障TCP 可能把两帧粘在一起发过来也可能把一帧拆成两次发。切帧算法必须自己写依据就是 0x68、长度 L、0x16 这三个锚点。最稳妥的切帧逻辑是读到一个 0x68先不急着认为是帧头接着读下一个字节如果是长度 L再读第三个字节和 L 比较相等才继续然后读第四个字节确认是 0x68之后按 L 的长度把整帧读完最后检查尾字节是不是 0x16。这个流程能过滤掉大部分 TCP 字节流里的“伪帧头”。我见过有人只在缓冲区里找 0x68 和 0x16 之间的数据结果遇到 ASDU 内部恰好出现 0x16 时直接切错帧整个链路解析乱套。网络103还有一个隐蔽差异串口有波特率和流控网络没有。串口调试时常见的数据位、停止位、校验位配置在网络103里全部消失取而代之的是 TCP 端口号、连接超时和重连策略。很多人习惯性地去问“波特率多少”在现场会被老工程师纠正看端口号别问波特率。3. 先跑通链路再谈协议建立TCP连接、参数配置与最小报文交换3.1 装置侧和后台侧的参数怎么对IP、端口、公共地址在聊报文之前先把链路参数对齐。网络103虽然承载的是老帧但它仍然是 TCP 应用网络层的三要素跑不掉装置 IP、装置端口、后台本机 IP。装置 IP 和端口一般写在装置的面板菜单里不同型号位置不同通常在“通信参数”或“网络配置”子菜单里找。端口号没有统一标准我经手的项目里见过 2000 以上到 5000 多的完全看厂家出厂设置。不要凭经验猜端口直接在装置菜单里看或者问厂家技术支持。公共地址是第二个关键参数它对应帧里的地址域 A也对应 ASDU 里的公共地址字段。后台配置的公共地址必须和装置一致否则 TCP 能连上但总召唤没有响应或者遥信上送被后台丢弃。还有一种常见做法后台软件里配置连接参数时会区分“本端地址”“对端地址”“公共地址”三个栏位。前两个是 IP 层面的后一个是应用层面的。很多人配置时把公共地址填成后台本机 IP这是本世纪最常见的配置错误。3.2 用Python搭一个最小103主站连上去、发召唤、看响应先做一件事验证 TCP 连通性。不需要写程序用系统自带的工具就能测。Linux 下用 ncWindows 下用 Telnet 客户端或者用 Python 一句话连一下。import socket # 装置IP和端口按现场实际配置修改 DEVICE_IP 192.168.1.100 DEVICE_PORT 2404 sock socket.create_connection((DEVICE_IP, DEVICE_PORT), timeout5) print(TCP connected:, sock.getpeername()) sock.close()逻辑说明这段代码用 Python 内置 socket 模块建立一条到装置端口的 TCP 连接5 秒超时。如果打印出对端地址说明网络层没问题如果超时或拒绝连接先查装置 IP、端口、网线、防火墙不要往下走协议。参数说明DEVICE_IP 和 DEVICE_PORT 必须改成现场装置的实际参数。timeout 建议先设 5 秒生产环境可以放宽到 10 秒。这里的端口号我刻意留成 2404它只是演示实际装置端口以现场菜单为准不要照抄。TCP 通了之后再写一个最小帧解析器。跑通了切帧才能谈后续业务。def parse_ft12_stream(stream): frames [] i 0 while i len(stream): # 找帧头 0x68 if stream[i] ! 0x68: i 1 continue # 帧头后要有长度字段和重复长度 if i 2 len(stream): break length stream[i 1] if stream[i 2] ! length: i 1 continue # 再确认第二个 0x68 if i 3 len(stream): break if stream[i 3] ! 0x68: i 1 continue # 整帧长度 6 length其中 length 包含控制域到校验和 frame_len length 6 if i frame_len len(stream): break frame stream[i:i frame_len] if frame[-1] ! 0x16: i 1 continue # 校验和校验 cs sum(frame[4:-2]) 0xFF if cs ! frame[-2]: print(checksum error at offset, i) i 1 continue frames.append(frame) i frame_len return frames逻辑说明这段代码是一个标准 FT1.2 切帧器。它按“0x68 长度L 重复长度 0x68 数据 校验和 0x16”的结构从字节流里切出完整帧并对校验和做了核验。切帧不依赖 TCP 包边界所以粘包也好拆包也好都能正确还原。参数说明length 是帧长度字段表示从控制域到校验和的字节数。整帧实际总长度是 length 6等于 2 个 0x68 2 个长度字节 length 个数据字节 1 个 0x16。校验和范围是 frame[4:-2]也就是控制域、地址域和 ASDU。这一段代码可以直接用于网络103抓包后的离线分析也可以接到实时 socket recv 缓冲上。3.3 一份能直接用的抓包/日志对照流程调试网络103时我的工作流从来都是先抓包再解析最后翻装置日志。抓包工具用 Wireshark 或者 tcpdump 都行。现场如果在后台机 Linux 上一条 tcpdump 就能解决问题。tcpdump -i eth0 -s 0 -w /tmp/net103.pcap host 192.168.1.100 and port 2404逻辑说明这条命令把 eth0 网卡上、与装置 IP 192.168.1.100 的 2404 端口通信的所有数据包保存到 pcap 文件里。-s 0 表示抓完整包避免截断导致后续分析不完整。参数说明-i 指定网卡名现场可能是 eth0、ens32 或别的名字用 ip link 查。host 和 port 按装置实际参数改。-w 指定保存路径建议存到非系统盘避免日志文件写满根分区。抓包时长控制在发现问题所需的最短时间比如从发起总召唤到异常结束不要一挂挂半天。抓完包后把 TCP 负载提取出来直接喂给上面的 parse_ft12_stream就能得到所有有效帧。提取 TCP 负载可以用 Wireshark 的“Follow TCP Stream”导出原始数据也可以用 tshark 命令自动化tshark -r /tmp/net103.pcap -T fields -e tcp.payload | sed s/://g /tmp/ft12_hex.txt逻辑说明tshark 从 pcap 里提取每个 TCP 包的应用层负载去掉冒号分隔符输出成纯十六进制文本。这个文本可以直接作为字节流解析器的输入验证刚才的切帧逻辑。这一步做完你就把“网络103调试”从黑匣子变成了白盒。TCP 通不通、帧有没有发、帧校验对不对全都在你手里不需要靠猜。4. 三次关键报文交互总召唤、对时、遥信变位怎么调4.1 总召唤流程与常见“召唤无响应”排查思路总召唤是网络103调试里遇到的第一个业务交互也是后台和装置建立数据同步的基础。主站发一条总召唤命令装置收到后把所有遥信、遥测、事件顺序记录按 ASDU 逐帧上送最后回一个总召唤结束标志。总召唤无响应是现场最高频的问题。按排查顺序来先看 TCP 链路通不通再看发出去的帧校验和和时间间隔是否正确再看公共地址对不对最后看装置是否处于“就地”或“调试锁定”状态有些装置在就地状态下不回总召唤。常见的一个误区是后台发送总召唤后发现装置一条不回立刻怀疑装置网口坏了。实际很多原因是后台发帧时把 0x68 长度字段写错装置收帧后发现长度对不上直接丢弃。这种问题抓包看一次就能定位不需要重启装置。4.2 对时命令为什么网络103对时比串口更容易丢103规约的时钟同步靠主站下发对时命令装置收到后更新内部时钟再回一个确认帧。串口103时代这条命令从发出到确认通常在几十毫秒内完成时序非常紧凑。网络103把这条命令放进 TCP 帧后时序变成不可控的从前台调度到装置应用的时间可能受网络缓冲区影响。实际调试里我见过后台每 10 秒下发一次对时命令但装置时钟仍然越走越偏。原因不是命令丢也不是装置晶振差而是后台发的对时 ASDU 里时标格式和装置期望的字段位不一致。对时命令的时标精度通常是毫秒级如果后台只填了秒字段毫秒全是 0装置校准后反而产生最多 1 秒的跳变。我的建议是对时问题不要只看报文有没有回确认要看装置时钟在对时前后是否平滑跳变。如果每次对时时钟都往回跳或者往前跳优先查后台时标构造代码别怀疑装置。4.3 遥信变位与带时标报文时间戳不准先看这里遥信变位上送是网络103里最体现“协议设计年代感”的地方。装置检测到开入变位后并不是直接往 TCP 里塞一帧就完事而是先把事件按优先级放进不同队列主站需要周期发送“召唤 1 级数据”命令装置才把队列里的带时标变位报文取出来上送。这就解释了为什么很多人第一次调试时看到装置面板上变位指示灯亮了后台却迟迟收不到变位。不是装置没发是主站没去取。后台监控软件通常每 100 到 200 毫秒轮询一次召唤 1 级数据如果轮询周期太长变位报文延迟变大看起来就像“丢数据”。带时标报文的时标字段是装置自己打上去的包含毫秒、秒、分、时、日、月、年。如果装置本身没对时时标就是装置上电后的默认时间后台解析后会出现“变位时间比当前时间早两年”的怪象。这种问题主站这边怎么改都没用先把装置对时和时钟电池搞定。5. 网络103调试避坑5个现场踩过的坑5.1 坑一TCP粘包导致帧解析错位报文全乱现象后台收到的网络103报文解析后全是乱码有时候一帧里能看到好几段 0x68 开头的数据有时候 0x16 结束符找不到。原因TCP 是字节流装置可能一次把两帧甚至三帧连着发过来也可能把一帧拆成两次发。解析程序如果按 recv 次数来断帧必然出错。解决使用缓冲区积累数据按 3.2 节的切帧逻辑处理不要依赖单次 recv 的边界。切帧时一定要做“重复长度字段校验”和“结束符校验”缺一个都会被伪帧头带到沟里去。5.2 坑二公共地址配错导致总召唤正常但遥信不上送现象总召唤有响应遥测有值但任何遥信变位后台都收不到。抓包发现装置确实上送了变位帧但后台就是不入库。原因网络103的 ASDU 公共地址字段和总召唤响应保持一致但后台设备表里关联的公共地址配成了另一个值导致应用层直接丢弃了这条变位。解决把后台设备配置里的公共地址、装置菜单里的公共地址、抓包里 ASDU 的公共地址三处对齐。不要只看 TCP 通不通TCP 通只能说明网络层正常应用层地址错了数据照样进不了库。5.3 坑三类型标识表不能只信网上的版本厂家定义有差异现象按标准文档解析类型标识把某条报文判断为遥信实际它是遥测或定值后台数据全错位。原因IEC 60870-5-103 的类型标识在标准附录里给了普适定义但厂家私有 ASDU 经常复用或扩展其中的取值。不同固件版本对同一类型标识的解释也有差异。解决手头准备厂家版本对应的规约文本。遇到类型标识无法正向匹配时反向查从装置说明书里看这条功能对应哪个 ASDU再回到报文集里找特征字节。切忌拿网上的通用表直接套现场报文。5.4 坑四后台和调试工具同时连装置互相踢线现象调试时用笔记本连上装置后台紧接着也发起连接然后笔记本的连接立刻断开或者后台掉线。原因部分装置对 TCP 连接数有限制同一个服务端口只允许一个客户端连接。后连接方把先连接方顶掉了或者装置直接拒绝第二个连接。解决现场调试时先和后台确认谁占用连接谁用完谁断开。不要开着后台监控软件的同时再用调试工具重复连接。如果必须同时用需要确认装置是否支持多连接不支持就串行操作。5.5 坑五校验和算法看起来对但参数帧类型不对现象帧切出来了校验和计算也正确但装置就是不响应或者后台收帧时提示“校验和错误”。原因FT1.2 校验和覆盖范围是从控制域开始到 ASDU 最后一个字节不包括帧头的 0x68、长度字段和结束符。有人把长度字段也算进了校验和或者把结束符也纳入了累加算出来的校验和自然不对。解决严格按“控制域 地址域 ASDU”三个部分做累加取低 8 位。写代码时用一个变量记录起始索引不要用固定偏移因为 ASDU 长度会变。校验和错误时先用 3.2 节的解析器打印每一帧的各段字节肉眼核对是哪段多算了或漏算了。6. 用捕获文件验证整个链路离线回放与回归测试技巧网络103调试最麻烦的一点是现场环境不固定复现问题往往要等很久。我个人的习惯是每次现场调试都保留完整的 pcap 文件回办公室后用离线脚本反复分析。这不只是排查手段更是回归测试的依据——换装置型号、升级固件、改后台版本后把旧 pcap 里的主站请求重新发一遍对比装置响应是否一致能提前发现很多兼容性雷。具体做法把 pcap 里提取出的主站→装置方向的帧按时间顺序保存为一个十六进制文本文件。回归测试时写个简单的 TCP 客户端逐帧发给装置每发一帧就等装置响应再把响应帧和旧 pcap 里的装置响应做逐步字节对比。这个对比能帮你在不依赖后台监控软件的情况下验证装置行为是否发生变化。我在某次装置固件升级后就是这样发现厂商悄悄改了带时标报文的时标精度字段后台差点把所有变位时间都解析错。另一个验证习惯是写定时任务跑帧解析脚本。把现场抓回来的 pcap 做批量解析统计每一类 ASDU 的出现次数、平均响应延时、校验和错误率。这个统计结果能直接量化链路质量。比如总召唤响应帧里带时标遥信的平均间隔如果超过 200 毫秒说明装置侧转发队列或网络有瓶颈这时候再去调后台轮询周期才有依据。最后说一句血泪经验抓包窗口一定要覆盖到问题发生前后至少 30 秒别只抓那几帧。网络103的问题往往有前兆——比如某条连接重发了、某个帧的响应延迟变大了——完整窗口才能看到前因后果。离线回放和回归测试做得好现场调试时间能省一半。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
