简介以南瑞继保网络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 本身才是真正技术核心它由以下字段组成字段字节数说明类型标识1区分遥测、遥信、命令等报文类型可变结构限定词1高位置 1 表示元素连续低 7 位表示信息元素个数传送原因1表示周期、突发、总召唤、命令执行等公共地址1-2装置站地址多装置接入时靠它区分功能类型1即 FUN按保护设备功能划分信息序号1-2即 INF对应具体遥测点或状态位信息元素不定具体数据、时标、品质描述、命令状态调试时优先看类型标识和传送原因。比如总召唤响应报文通常是类型标识为遥测成组或者遥信成组传送原因写成“总召唤”。如果是突发遥信传送原因往往是“突发”或“事件”这类报文需要特别关注时标因为后台故障录波和 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忙不过来。下表是我在项目里常用的参数模板参数推荐值备注主站 TCP 模式Client主动连接装置端口按装置配置常见为 2404 或私有端口必须和装置一致公共地址1-254与装置站号对应链路超时3s可微调总召唤周期15s视通道延迟调整命令选择超时1s以装置手册为准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、再开回放脚本然后再动装置参数。这套流程帮我避过了很多事后让人后怕的调度事故。希望这篇文章能让你少走一点弯路也祝你三天内调通通道、点表一次对上。本文还有配套的精品资源点击获取