网络103规约解析：报文格式、四遥调试与点表映射实战

简介：以南瑞继保网络103规约为核心的协议资料，面向电力系统自动化工程师、远动调试人员及对IEC 60870-5-103扩展实现感兴趣的技术学习者，可应用于调度中心、集控站与RTU之间的数据通信场景。压缩包内共1个doc文档，大小3.38MB，内容系统梳理了103规约的体系架构、主从通信模式以及遥测、遥信、遥控、遥调“四遥”功能的实现方式，并针对南瑞继保在兼容扩展性、安全性增强、性能优化、故障恢复、自定义服务及网络适应性等方面的特点进行了条目化说明。已有1974人学习，文档对报文格式、身份认证、数据加密、错误检测、拥塞控制等关键细节均有涉及，能够帮助读者快速建立对规约的整体认知，理解其数据编码与解码机制及应用层交互逻辑，为现场协议分析、调试排障和二次开发提供直接参考。整体以理论梳理为主，结构清晰，适合作为电力自动化领域的入门导读，也可作为日常工作的速查资料。

1. 网络103规约是什么：继保调试里绕不开的“黑匣子”

做继保调试和远动接入的工程师，几乎都避不开“南瑞继保网络103规约”这个名字。它本质上是从 IEC 60870-5-103 标准扩展出来、跑在以太网上的通信协议，用于继电保护装置、测控装置和后台或者远动机之间交换遥测、遥信、遥控、遥调数据。相比串口 103，网络103最大的特点是你不再需要关心 RS-485 的收发时序和波特率，而是直接面对 TCP/IP 连接和报文点号。很多刚接手的人会在前两周被它的私有功能号和校时逻辑折腾得头疼，因为厂家文档里只给了功能总表，却没说清楚哪些是保底字段、哪些是私有扩展。这篇文章我就按自己做网络103装置接入和主站联调的经验，把这个协议从报文格式、四遥解析、参数配置到常见坑位拆一遍，尽量让你照着能少加两周班。

2. 网络103规约的通讯骨架：从帧结构到典型连接建立

2.1 主从链路模型和网络化改造

标准 IEC 60870-5-103 定义的是不平衡主从传输方式，主站发起请求，从站应答，从站只在特定条件下上送事件。南瑞继保的网络103规约保留了这套模型，但把物理层从串行链路换成了 TCP/IP。也就是说，后台或者远动机作为 TCP 客户端去连接保护装置的 103 服务端口，连接建立后，主站发送总召唤、查询命令，装置返回测量值、状态量、事件记录。

这个模型下有一个容易被忽略的点：主从关系指的是“应用层”的问答关系，而不是 TCP 连接谁主动发起的关系。实际工程中，我一般让装置侧做 TCP Server，监听端口由厂家配置文件决定，后台作为 Client 主动连接。这样做的好处是装置只需要配置服务端口和允许访问的 IP 白名单，不需要关心对端 IP 变化。调试时最常翻车的反而是两边都以为自己是 Client，或者两边都等着对端连过来，结果网线通着却永远没有会话建立。

值得注意的另一点，网络化后帧格式不再要求 FT1.2 的物理层帧校验，因为 TCP 自己保证了字节流的有序和完整性。但很多厂家的实现会在应用层帧头里保留长度字段和 CRC，方便程序直接按帧切包。南瑞继保网络103的帧头通常不完全是标准 0x68 开头，所以要抓包后先看一眼十六进制，确认是定长帧头还是变长帧头，再做后续解析。

2.2 链路帧与 ASDU 的字段构成

IEC 103 的应用层报文可以拆成“链路帧头 + ASDU”两块。标准链路帧头包括启动字符、长度、控制域、地址域、校验和、结束字符，但在网络 103 里，很多实现简化成“报文头长度 + 控制域 + 地址域 + ASDU + CRC”的私有结构。ASDU 本身才是真正技术核心，它由以下字段组成：

调试时优先看类型标识和传送原因。比如总召唤响应报文通常是类型标识为遥测成组或者遥信成组，传送原因写成“总召唤”。如果是突发遥信，传送原因往往是“突发”或“事件”，这类报文需要特别关注时标，因为后台故障录波和 SOE 都依赖它。

我习惯把抓到的报文丢进脚本里按字段错位拆，一旦发现某条报文长度怎么都对不上，就先去检查可变结构限定词，很多误解析就是没把“连续元素个数”加入计算。

2.3 南瑞继保网络103的私有功能号与兼容性

标准 103 已经定义了保护设备常用的功能类型，比如距离保护、零序保护、重合闸等，但南瑞继保在工程实施中会把很多非标量打包到私有功能号里。这意味着你拿一个通用 103 规约分析工具去解析，能看懂通用 ASDU，但碰到装置主动上送的“保护事件报告”或者“故障波形摘要”时，功能类型值可能落到厂家自己定义的段位。

我处理过的一块国产保护装置里，遥测全部挂在标准功能号下，但保护动作信号被归到私有功能号，主站点表里写的却是“保护动作”，后台程序按标准 INF 映射，结果一直接收不到。这种兼容性问题不解决，点表做得再漂亮都是白搭。

建议的做法是：在做协议转换或者写前置解析程序时，把功能号和信息序号做成独立的映射文件，不要硬编码到程序里。南瑞继保的网络103规约文档通常会附一张“FUN/INF 点表”，里面列出每个功能码对应的中文描述、数据类型和品质位定义。虽然不同版本的装置点表有差异，但至少这个文件能当第一版参照，不需要从零猜。

3. 四遥报文实战：遥测、遥信、遥控、遥调怎么解

3.1 遥测：测量值报文中的标度与品质位

遥测是后台最关心的数据之一。网络103里，遥测报文通常以“带品质描述的测量值”形式上送，信息元素里除了数据本体，还包含品质描述：有效、溢出、非更新、被替换。别小看这个品质位，很多后台画面显示“数据跳变”或“冻结值”，其实是品质位为“非更新”，而不是数据本身出错。

遥测数值通常是标度化值，也就是带符号的 16 位整数，需要乘以遥测系数，才能得到电流、电压等实际工程值。南瑞继保很多装置的遥测死区和归一化基准都是“满量程对应 4096 或 32767”，具体基准值一定以装置手册为准。我踩过坑：同一个 10kV 线路电流，在 A 站按 32767 对应额定值计算，在 B 站程序却写成 4096，结果所有遥测都放大八倍，值班员当场就被假数据带偏了。

处理遥测的关键是把点号、基准值、变比、单位集中配置在“前置点表”里，不要试图在报文解析程序里硬算。常见的做法是后台程序只负责把原始值写入到内存表，由图形界面或计算模块统一查转换曲线。

3.2 遥信：变位上送与 SOE 事件时间戳

遥信在 103 规约里分成两类：状态变位和事件顺序记录。状态变位报文只包含当前值，而 SOE 报文会带毫秒级时间戳。实际上不少网络103主站在调试时只看遥信变位，不解析 SOE 时间，导致保护动作后时间全取主站接收时刻，误差可能达到几百毫秒，这在电网故障分析里是致命的。

解析 SOE 时要注意时标的顺序：103 标准里时标格式是“毫秒、分钟、小时、日、月、年”，不是我们常见的 Unix 时间戳。而且很多厂家会把时标放在信息元素末尾，如果你的通用解析工具只认标准位置，就必须自己按点表偏移去切片。

我曾经处理过一条 35kV 母线保护遥信一直延迟 2 秒才上送的案例，原因是装置侧把遥信事件放到低优先级队列，只有后台每 3 秒轮询缓冲区才上送。后来把遥信事件改成“变化上送 + 缓冲保护”，延迟立刻降到 50ms 以内。所以调遥信时不要只盯报文解析，还要看子站的事件处理策略。

3.3 遥控与遥调：选择-执行和直接执行的差别

遥控在 103 里通常有两种命令方式：选择-执行和直接执行。选择-执行，是主站先下发“选择命令”，装置确认选择成功后主站再下发“执行命令”；执行完成后装置返回执行确认。直接执行则把选择和执行合成一步，命令比较激进但响应快。

网络103遥控报文里最关键的字段是“命令状态”：选择成功、选择失败、执行成功、执行失败、命令取消。调试遥控时最常见的坑是主站收到选择成功就认为控制完成，其实还要等待执行确认。南瑞继保的保护装置大多数支持选择-执行模式，并且有选择后超时判定，超过规定时间没收到执行命令，自动取消选择。这个超时时间一般在几百毫秒到几秒之间，具体值可以去装置菜单里查。

调遥调一般指调节变压器分接头、无功补偿电容器投切等，本质也是命令帧，区别在于数据域里带调节目标值或分接位置。因为目标值可能为负，解析时注意有无符号扩展，不然把负调节量读成 65535 以后，后台会做出一堆奇怪的误判。

3.4 点表映射的经验：FUN/INF 与装置描述表

点表映射是整个网络103接入中最花时间的一环。无论你用的是南瑞继保的调试软件，还是自己写前置机，最终都需要把工程上的“线路有功功率”映射到某个装置 FUN 和 INF 上。该映射关系通常写在装置的“点表文件”或“CID 描述”里，也可以用厂家工具导成 CSV。

经验是拿到点表后先分三组：遥测组、遥信组、遥控组，每组的 FUN 区间一般固定。然后对照着抓包验证至少三条典型报文：总召唤后的稳态遥测、保护动作产生的变位遥信、一条遥控命令。如果这三类报文都能在抓包里找到并和点表对应上，这个项目的点表工作就基本稳了。

很多团队会直接把保护装置的“内部逻辑地址”当作 INF 使用，这是不严谨的。内部逻辑地址只是装置程序内部使用的索引，网络103规约报文中的 INF 才是应用层的信息序号，两者不在同一层。所以写点表转换脚本时要保留“装置逻辑名、FUN、INF、点表描述、转换系数”五个维度，缺一个，后期维护都是坑。

4. 搭建网络103联调环境：参数配置与抓包验证

4.1 主站侧参数：IP/端口/公共地址/超时

主站侧通信参数直接决定能不能把网络103通道建立起来。最常见配置项包括：装置 IP、端口号、公共地址、链路超时、总召唤周期、无应答重发次数。

• IP 和端口：必须和装置侧保持完全一致，端口不是固定值，以装置调试界面为准。
• 公共地址：通常和装置站号一致，主站对每个装置使用不同公共地址来区分数据源。如果主站把公共地址写错，装置即使响应，主站也会因为地址不匹配丢弃报文。
• 链路超时：指主站等待装置应答的最长时间。网络状况不稳定时，超时设太短会导致频繁重发，太长则会让遥控操作显得迟钝。我一般先设 3 到 5 秒，抓包看一次总召唤的平均响应时间再调。
• 总召唤周期：用于把突发丢失的数据补全。建议 15 秒做一次总召唤，不要小于 10 秒，否则装置CPU忙不过来。

下表是我在项目里常用的参数模板：

4.2 子站侧参数：南瑞继保装置侧的配置

从子站侧看，需要关注的参数主要集中在装置的网络参数和通信服务配置里。首先要保证装置和管理后台在同一个 VLAN，或者路由可达，不能只通 Ping 就直接连接。然后是通信服务开启状态，很多保护装置出厂默认只开 IEC 61850 服务或串口 103，网络103服务需要专门使能。

装置侧一般还会要求填入“主站 IP 白名单”，只允许指定的后台 IP 发起 103 连接。这个白名单在调试早期特别容易出错，我遇到过后台 IP 变了但白名单没改，导致连接一直被装置拒绝。另一个点是装置密码权限，遥控服务一般要求操作员权限以上，如果你用只读账号登录装置做遥控测试，会收到协议层的否定确认，表面现象却是“遥控返校不通过”。

建议在装置侧开启调试日志，命名为“103 通信日志”这类，里面会记录每一条收到的报文、报文来源、处置结果。这个日志是排查遥控失败的第一现场，优先级比后台抓包还高。

4.3 用 Wireshark 做通道验收

网络103虽然私有化程度高，但它终究是 TCP 报文，所以使用 Wireshark 依旧能达到很好的排查效果。抓包时要先确认抓在哪个网卡上：如果后台和装置之间经过交换机，建议抓后台侧网卡，因为能看到主站视角的收发情况；如果有镜像口，直接抓镜像口最省事。

Wireshark 里过滤出该通信链路最简单的表达式是：

tcp.port == 2404 && ip.addr == 192.168.10.100

如果没有确认端口，可以先用“tcp”过滤找包含 0x68 或 0x10 的载荷段。命令里没有端口过滤时，Wireshark 会把所有 TCP 流量都列出来，适合做通道初查。

抓到报文后，重点看三点：TCP 三次握手是否完成、应用层数据是否连续、有没有大量重传。TCP 重传率高是网络质量差的标志，这种情况即使报文格式解析正确，后台也会频繁出现总召唤超时。

用 tcpdump 在服务器侧抓包也很方便：

tcpdump -i eth0 -s 0 -w /tmp/net103.pcap host 192.168.10.100 and port 2404

抓下来的 pcap 可以直接拖进 Wireshark 分析。注意 tcpdump 命令里的-s 0表示抓取完整报文，不要省，不然报文被截断后，ASDU 长度字段根本没法验算。

5. 网络103调试验收的五个坑：现象、原因与解决

5.1 连接建立成功了，总召唤却无响应

现象是 TCP 连接能建立，后台也看到链路处于“在线”，但发总召唤后一直收不到装置响应，超时报文反复出现。

原因是 TCP 连接成功只代表内核网络栈通了，不代表应用层服务已经就绪。很多时候装置的网络服务全部集中在某个主进程里，该进程可能因为配置错误没有进入运行态，或者被其他调试任务占用了通道资源。还有一种常见原因：总召唤报文的公共地址和装置地址不一致，装置收到了字节但认为不是发给自己的。

解决思路是先查装置侧通信日志，确认装置有没有收到总召唤；收到但没回，就从应用层协议处理流程排查；如果日志里根本没有收到记录，就抓包对比源目的地址。经验是：TCP 握手正常、应用层无响应时，90% 是指针转换和地址过滤问题，先检查公共地址，再检查服务使能位。

5.2 遥信变位报不上来，事件窗口被冲掉

现象是保护动作发生在上午 10 点，后台却到 10 点 03 分才看到变位，而且中间可能丢了部分事件。

原因是装置侧的事件缓冲长度有限，网络通道不稳定时多次重传会占满缓冲区，新事件进不来。或者后台总召唤周期太长，缓冲累积后按“最旧优先”策略把新事件顶掉了。

解决方法是把总召唤周期缩短到 15 秒以内，同时开启装置侧的“事件溢出保护”，当事件缓冲超过 80% 时立刻上送当前最新一批事件。还有一点容易被忽视：后台程序处理遥信报文的线程如果阻塞在某个点表查询上，后续报文会全部排队，看起来像丢了事件。要确认这一点，可以在后台接收进程里面打印收到报文的序号，看是否存在跳跃。

5.3 遥控返校成功但执行失败，问题不在协议

现象是后台遥控界面显示“返校成功”，但装置开关没有动作，后台也没收到执行失败确认。

原因是很多保护装置的遥控执行前还有“软压板”和“操作允许”的开入条件，这些条件在协议层根本看不到。返校成功只代表装置通信模块认可了这条命令，但执行机构可能因为闭锁状态、控制模式不在远方、或者开关机构压力低，直接拒绝执行。

解决方法是先看装置面板上的操作允许灯和闭锁信息，再查看装置事件记录里的“遥控闭锁原因”。不要一上来就怀疑报文解析，要先排除装置侧的电气闭锁和软压板条件。做遥控测试前，我习惯先用装置的本地测试功能手动分合一次开关，确认执行回路本身没问题，再做协议遥控。

5.4 报文能解一半，私有点号全是乱码

现象是总召唤响应里的遥测能解析出来，但保护动作事件、故障数据这类报文解析出来完全是乱码，长度对不上。

原因是厂家的私有功能号中，信息元素结构和标准 ASDU 不同，可能多了设备标识、相对时标、故障波形索引等字段。通用解析器只认标准结构，硬拆当然乱。

解决办法是找到厂家点表里对应的 FUN/INF 描述，确认该报文包含了扩展字段，按扩展字段结构重新定义解析模板。我一般会建立一个“私有点表扩展结构清单”，每个私有功能号都记录字段顺序、字段长度和数据格式。后续再对接新版本装置时，只需要对比这个清单差异，不用全部重新解析。

5.5 通道几分钟断开一次，看门狗打架

现象是后台和装置之间的 TCP 连接每隔几分钟就断一次，重连后又正常，过几分钟再断。

原因是中间交换机或防火墙的空闲老化时间太短，把长期没有数据的 TCP 连接当成空闲连接清掉了。网络103链路在无事件常态下可能长时间没有应用层报文，TCP 保活如果没开启，就会被网络设备回收。

解决方法是开启 TCP Keepalive，后台侧设置保活时间小于交换机老化时间，一般 30 秒发射一次心跳。同时可以把总召唤周期当作应用层心跳，这样链路空闲窗口就不会拉满。配置了这些之后，我再没遇到过“后台显示装置离线，但 Ping 一直通”的诡异情况。

6. 进阶技巧：用抓包回放把网络103调试从“玄学”变成“工程”

调试网络103最怕的是复现不了问题。现场偶发一次的变位漏报，你盯着报文看一小时也不一定再出现。所以我的习惯是：任何一次异常都要先留下原始抓包文件，然后把关键报文截取出来做回放，用回放去验证主站解析逻辑是否正确。回放流程不复杂，关键是把数据链路层的字节原样保留，不要擅自修改任何字段。

抓包环境保持与现场一致的拓扑，尽量抓在同一个网口，避免跨网段后报文长度变了。抓到 pcap 以后，用 Wireshark 的“Follow TCP Stream”功能导出原始字节流，按 TCP 分段还原成一条条完整的应用层报文。我习惯把每一条报文保存成一个二进制文件，文件名按“类型_功能号_信息序号_时间”命名，后续回放时按批次发送。

回放报文我常用 Python 写一个小工具，核心逻辑是利用 socket 模拟主站向后台或者前置机发送数据。这里给一段最基础的回放示例：

import socket import sys def send_raw_frame(host, port, raw_file): with open(raw_file, 'rb') as f: payload = f.read() s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(3) try: s.connect((host, port)) s.sendall(payload) resp = s.recv(4096) print(resp.hex()) finally: s.close() if __name__ == '__main__': send_raw_frame('192.168.10.100', 2404, sys.argv[1])

这段代码里，host和port一定要指向被测试的主站或协议转换装置；raw_file是你从抓包里截取出来的原始字节流文件。执行后打印的resp.hex()是对端返回的原始确认报文，如果回放后对端没有任何响应，先不要怀疑 socket 程序，而是检查原始字节流是否包含 TCP 层额外包装的字段。用这种方式做回归测试，比拿真实装置一次次操作安全得多，特别是在做保护传动试验之前。

回放之外，我还喜欢做一个“点表一致性校验脚本”：把主站点表导出成 CSV，然后从抓包里自动提取所有出现过的 FUN/INF，用集合做差集比对。漏掉的点号、错位的点号、只存在于后台但从未在网络报文中出现的点，用脚本几分钟就能列全。

脚本核心是解析报文头里的功能类型和信息序号，具体实现依赖你使用的抓包分析库。但我给一个重要提醒：做点表校验时，一定要包含总召唤响应后的所有报文，因为只有总召唤能拉出全部稳态数据，才能暴露“后台点表有，但装置不上送”的配置问题。

从那以后，我每次接手网络103项目都会强制要求自己先抓一小时总纲报文、归档现场 pcap、再开回放脚本，然后再动装置参数。这套流程帮我避过了很多事后让人后怕的调度事故。希望这篇文章能让你少走一点弯路，也祝你三天内调通通道、点表一次对上。

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