网络103规约联调避坑：故障录波与FUN/INF映射实战-北京尧图网络

简介南瑞继保网络103规约文档是电力系统远动通信领域的专业参考资料面向调度自动化、变电站集控及二次设备调试维护人员解决标准103规约在实际工程中如何适配南瑞继保设备与网络环境的问题。内容涵盖基于IEC 60870-5-103的扩展功能包括遥测、遥信、遥控、遥调四遥机制并涉及兼容性设计、安全认证、数据编码优化、故障处理及网络适应性等关键点。资源为1个doc文件压缩包整体约3.38MB以协议说明和报文解析为主便于查阅和打印。目前已有1974人学习在同类协议资料中关注度较高。文档从规约结构、主从通信流程、功能码与命令帧/应答帧定义入手帮助读者建立对厂家定制103规约的系统认知同时给出错误处理与异常恢复方面的分析思路对现场联调、协议转换和故障排查具有较强的实用价值。1. 南瑞继保网络103规约为什么故障录波老是“卡”在网络上后台遥控、遥测全正常但一点“召唤故障波形”就超时保信子站自动拉取保护动作报告动不动缺条记录——这类问题在110kV及以上变电站并不少见根子往往不在设备上而在网络103规约的通道与点表配置上。简单说南瑞继保网络103规约就是把你面前这台PCS系列保护装置的信息接口从串口换成以太网仍沿用IEC 60870-5-103的报文结构来传送遥信、遥测、SOE、定值和故障录波。它解决的核心痛点很明确新站信息量越来越大串口速率和物理链路成了瓶颈。适合谁继保调试人员、后台组态工程师、保信子站集成商——凡是需要把保护装置接入监控后台或保信子站的人这篇就是照着联调用的。2. 报文骨架先认ASDU再谈总召唤和扰动传输2.1 为什么103不像104那样“抄点表就能通”用过104规约的人都知道后台侧只要把“信息体地址”按顺序排好装置就能把数据对上来。网络103规约不一样它靠的是“功能类型FUN 信息序号INF”的组合来定位一个测点而FUN和INF不是连续地址是装置厂家在装置内部就定死的逻辑编号。南瑞继保的PCS系列保护装置里每个信号点都带一组FUN/INF后台侧必须和装置一致数据才上得来。另一个区别在报文组织方式。104规约的ASDU里信息体地址是3字节地址连续可推算103规约的ASDU用的是FUNINF各1字节且不同用途的信号分属不同类型的ASDU——遥测是遥测的类型标识遥信是遥信的类型标识带时标的事件又单独占一类。所以103联调的第一件事不是建表而是认帧。常见做法是先抓一帧报文确认链路帧格式再对照标准里的类型标识表把装置信号清单里的FUN/INF翻译成后台数据库里的点。这个顺序不能反一上来就建点表多半会翻车。2.2 一次总召唤两个关键帧网络103规约继承了串口103的主从问答机制总召唤是所有数据上送的起点。主站下发类型标识为1的ASDU装置收到后开始逐条上送遥测、遥信和带时标的事件最后一定会回一帧类型标识为2的ASDU表示这一轮总召唤结束。很多后台工程师有个习惯收到数据就落库不等结束帧。这在数据量小的时候看不出问题数据一多就会出现“库里的点少了一部分”这种摸不着头脑的怪象。正确做法是先把这一轮总召唤的报文全部缓存等类型2到达后再统一入库。值得留个心眼的是带时标的信息体。103规约里ASDU分1E型和2E型1E型自带时标2E型没有时标需要靠接收时刻补。网络103里绝大多数事件都是1E型时间应该取报文里的时标而不是后台收到的时间否则事件顺序会乱。这个坑我在第5章还会细讲。2.3 扰动数据传输和定值回读网络103的另一半价值如果只是传遥信遥测网络103相比104没有优势。它真正的价值是能把故障录波和定值也走同一根网线传回主站。扰动数据在103规约里有专门的类型标识区段主站下发扰动召唤装置先回“扰动数据传输开始”然后逐包上送录波数据最后回“扰动数据结束”。后台侧需要把这些分散的包拼成完整的COMTRADE文件.cfg和.dat文件才能给保护分析软件用。定值回读走的是另一组类型标识。主站下发定值区召唤装置把当前区号和定值清单回上来。注意网络103下改定值不是标准推荐做法现场一般只做定值回读改定值还是用装置面板或专用工具更稳妥。从工程视角看网络103真正省掉的是“保护屏到后台的多根RS-485线”。但代价是TCP承载带来的粘包、拆包、半开连接这些网络层问题应用层必须自己做长度判断和超时重召。2.4 通道参数表把装置参数翻译成后台配置南瑞继保装置上电后通信参数里能查到IP、端口、链路地址和帧格式。后台侧建通道时这些参数必须一一对应。我一般会先按下面的表整理好再动配置界面参数项常见设置说明装置IP与后台同网段别和其他装置冲突检查掩码103服务端口看装置通信参数没有固定标准端口别拿104的2404硬套链路地址1255对应ASDU公共地址后台侧必须一致帧格式带0x68链路头 / 直接ASDU抓包先确认选错通道会一直不通时标格式UTC或本地时间后台统一按UTC存界面再转本地总召唤超时建议10s以上数据量大时加大否则误报通道故障这套参数表建好通道才能进入联调阶段。下一步就是做点表。3. 从装置到后台的点表制作FUN/INF映射的落地步骤3.1 先理清三类信号拿到装置信号清单后不要急着往后台导。先把信号分成三类遥信类、遥测类、事件类。遥信是开关量对应103的类型标识4和5双点信息要特别注意“合位/分位”的组合遥测是模拟量对应类型标识3数值背后有标度和倍率事件类对应带时标的类型标识6和7这类信号在保信子站里是最关键的保护动作、重合闸、告警都需要它。南瑞继保装置的信号清单一般会直接给出每个信号的FUN和INF有的还带“装置内部点名”。这些字段是后台点表的核心。如果拿到的清单里只有信号名没有FUN/INF别猜去装置调试软件里导或者用装置本身的信息查看功能翻。分类完成后还要顺手标一下哪些信号是检修态会上送的。很多后台会把检修态信号当成真实位置入库导致监控画面误报。这个标记在点表阶段就做掉后面省很多事。3.2 用CSV点表把FUN/INF钉死到后台数据库后台组态工具一般都支持CSV导入。我会先把信号整理成下面这样的CSV再导入后台FUN,INF,类型标识,点名,数据类型,单位,倍率,备注 240,1,3,线路有功功率,float,MW,1,PCS-931主保护 240,2,3,线路无功功率,float,MVar,1,PCS-931主保护 239,1,4,断路器合位,uint,,1,双点信息取合位 239,2,4,断路器分位,uint,,1,双点信息取分位 241,17,6,保护动作,uint,,1,带时标事件 241,18,7,重合闸,uint,,1,带时标事件 242,3,21,故障测距,float,km,0.01,故障报告用这里FUN和INF两列是关联后台点表与装置内部点的关键。类型标识列决定这套点表在运行时走哪类ASDU解析逻辑。后台导入时一般会要求能手工指定“类型标识映射”务必把CSV里的类型标识和后台的ASDU类型对应起来不能只靠点名匹配。倍率这一列常常被忽略。103规约上送的是整数后台要乘倍率才能显示实际值。如果倍率填错功率显示值会差几个数量级这类问题看起来像信号错误其实是点表倍率填错。测距的倍率尤其要注意0.01km和1km的结果完全不同。3.3 映射检查与两个常见陷阱CSV导入后不要急着上电联调。先做一次系统性的重名和冲突检查对FUN和INF这两列做分组统计确保没有重复或空值。不同装置的点表可以分开建通道但同一个通道下FUN/INF不能有重叠。第一个常见陷阱是“FUN拆分习惯”。有的后台工程师习惯把遥信、遥测分别从不同FUN段起头但南瑞继保装置内部FUN是固定的。如果后台侧为了排序方便改了FUN值装置根本不认。正确的做法是后台完全沿用装置的FUN/INF排序显示交给后台的点名和分组不要改地址。第二个陷阱是“INF重叠但类型标识不同”。103规约允许同一个INF在不同类型标识下出现例如动作信号既可能上送为类型6也可能上送为类型7。后台点表里如果没把类型标识一起设进去就会出现“两个点读到同一个值”的诡异现象。做点表时一定要把FUN、INF、类型标识三列当作组合主键缺一不可。4. 联调与报文验证抓包确认三条链路都通4.1 Wireshark怎么认网络103帧通道建好、点表导入后进入联调阶段。我的习惯是先抓包再看后台数据。Wireshark抓网络103报文并不难但有一件事必须提前确认帧格式。如果网络103通道沿用了串口103的链路帧那TCP流里会看到以0x68开头的帧头帧头后面跟着长度、控制域、地址域再往后才是ASDU。如果装置侧做的是“直接ASDU承载”TCP流里就没有0x68头第一个字节直接是类型标识。这两种格式在后台组态时要用不同的通道类型选错就一直是“通但收不到数”的黑匣子状态。抓包过滤器可以用端口号过滤例如tcp.port 4001。抓下来后先看长度列的规律如果每个包都带0x68开头那就是链路帧格式如果每个包首字节在140之间跳动、且看不出统一规律多半是直接ASDU。4.2 一个能帮你少跑现场的ASDU解析脚本野外调试最缺的就是一个能快速看报文内容的工具。写个简单的Python脚本把Wireshark导出的hex流逐行读进来解析类型标识、信息体个数、传送原因、公共地址和FUN/INF定位就快得多# 网络103规约帧快速解析读取一行hex打印关键字段 import sys def parse_asdu(body): # body 从ASDU起始第0字节为类型标识 if len(body) 6: return None t body[0] # 类型标识1总召唤 2结束 3遥测 4/5遥信 6/7事件 vsq body[1] 0x7F # 可变结构限定词低7位信息体个数 cot body[2] # 传送原因具体值查协议手册 addr body[3] # 公共地址(链路地址) fun body[4] # 功能类型 inf body[5] # 信息序号 return t, vsq, cot, addr, fun, inf for line in sys.stdin: line line.strip().replace( , ) if len(line) 0 or len(line) % 2 ! 0: continue try: raw bytes.fromhex(line) except ValueError: continue if raw[0] 0x68: # 带0x68链路头找到第二个0x68再跳过控制域和地址域 idx raw.find(b\x68, 1) if idx -1: continue body raw[idx 3:] else: body raw res parse_asdu(body) if res: t, vsq, cot, addr, fun, inf res print(类型{:3} 信息体数{:3} 传送原因{:3} 公共地址{:3} FUN{:3} INF{:3}.format(t, vsq, cot, addr, fun, inf))脚本用法把Wireshark里每个TCP报文的数据段复制出来存成一行一帧的文本文件然后运行python3 parse103.py frame_hex.txt。脚本会自动识别链路帧剥掉头再解析ASDU。多数情况下类型标识和FUN/INF一打印出来问题在哪一目了然。如果FUN和INF对不上先把这两个字段对调再试一次。部分厂家把信息序号的高低位顺序调换了脚本里固定按FUN在前解析对调后能对上就说明是字节序问题不是点表问题。4.3 按“先总召唤、再变位、最后扰动”的顺序验收联调不要想一口气全通按下面顺序走每步有明确的成功标准失败也能马上定位测试项操作预期结果失败时检查TCP连接telnet 装置IP 端口连接成功装置网卡、防火墙、网线总召唤后台下发总召唤收到类型2结束帧链路地址、帧格式、超时时间变位上送短接/断开一个开入量后台实时变位FUN/INF映射、检修态标记扰动召唤后台手动触发故障录波召唤收到完整的COMTRADE文件允许扰动远传、拼包逻辑定值回读后台下发定值区召唤定值清单完整上送定值只读权限、类型标识配置总召唤是第一步它通了说明通道和公共地址没问题变位上送通了说明点表FUN/INF映射正确扰动召唤通了说明大包传输和拼包逻辑没有翻车。三步全通网络103规约的主干才算真正跑通。5. 南瑞继保网络103避坑指南四条血泪踩坑记录5.1 现象后台能遥测但故障录波一直收不到一个很常见的翻车现场遥测遥信全正常保护动作信息也能上送唯独“故障录波召唤”一直超时。后台侧反复看通道配置没发现问题装置侧看通信报文也没报错。原因基本出在“扰动传输允许”这个开关上。103规约的扰动数据不随总召唤上送需要主站单独下发扰动召唤而装置侧有一个独立开关控制是否允许远传录波。很多保护装置出厂默认该功能投入但部分型号或部分固件版本默认是禁止的需要装置面板或调试软件里手动投入。解决路径是先手动触发一次扰动召唤看装置有没有回“扰动数据传输开始”。如果没回进装置通信参数里找“扰动传输允许”或“录波远传”选项投入后重新召唤。这类问题不是网络问题是装置侧的业务开关没打开。5.2 现象事件时标差8小时保护动作记录上送后后台显示的时间和装置本体的时间差8小时整差得很规律。这通常不是对时失败而是时区处理不一致。常见原因是103规约报文里的时标按UTC存储而后台直接按本地时间解析入库。装置本体显示的是北京时间上送报文里却是UTC后台如果不做时区转换所有事件就会整体偏移8小时。另一个隐蔽场景是装置对时源优先级问题SNTP对时源和IRIG-B对时源各指各的时钟导致装置内部时间就是错的。解决方法是先把装置对时状态确认好再统一后台的时标解析逻辑。规范的做法是后台内部统一按UTC存储展示层再转本地时间这样即使报文来自不同厂牌装置也不会出现各差各8小时的乱象。5.3 现象总召唤偶尔缺数据重启通道就好后台运行一段时间后总召唤回来的数据总少几个点把通道重启一下又恢复正常。这种“重启就好”的玄学问题九成是TCP半开连接造成的。装置作为服务端后台作为客户端如果后台侧长时间没有数据交互中间交换机的连接老化机制会静默回收这条TCP连接但装置侧并不知道还保持半开状态。后台再发总召唤时报文进了交换机就被丢弃表现就是“召唤超时”重启通道让TCP重新握手又能撑一阵子。解决方法是把后台侧的TCP keepalive参数打开并调短空闲检测时间。我一般会设置空闲5秒、探测间隔3秒、重试3次这样链路能持续保持活性不会再出现几个小时后总召唤半死不活的情况。同时检查交换机端口上有没有不必要的NAT或连接超时策略。5.4 现象按104的信息体地址填103点表全线错位习惯了104规约的工程师第一次做103联调时最容易犯的错就是拿104那套“信息体地址连续地址”的思路来填103的点表。104的信息体地址是3字节连续地址后台按顺序排就行103的FUN/INF是两维坐标中间任何一个点错位后面全部跟着错。具体表现是后台点表里第一个点对得上第二个开始全错位而且错位的规律“看起来很有序”。原因是FUN相同但INF不同的信号被后台误按顺序递增了。解决方法是回到装置信号清单逐条核对FUN和INF的实际值后台侧不要做任何自动补位。如果后台组态工具支持按CSV导入就严格按第3章的点表格式导入不要手工在界面里拉序号。这四条坑每一条我都实打实踩过。前两条偏业务逻辑后两条偏网络和习惯但都具备一个共同特征表面现象像网络故障实际是配置问题抓包一帧就能定位。6. 进阶验证用定值回读加波形回传给链路做体检通道建好、点表通了、避坑也看完了最后一步是把这条链路做成“可验收”的状态。我平时收尾时会做三件事叫它链路体检三件套。第一件是定值回读。在后台下发定值区召唤能完整读回装置当前定值区号和定值清单说明应用层双向通信和ASDU解析都没问题。定值回读是纯问答式交互不依赖任何外部触发条件是最干净的上行验证。第二件是波形回传。在装置上模拟一次故障或手动触发录波然后后台发起扰动召唤看能否收到完整的COMTRADE文件。这里要检查的不只是“有没有文件”还要看.cfg里的通道数和.dat里的采样点数是否完整。文件能回传说明网络103的大包传输、拼包逻辑、文件重组全部正常。第三件是观察一次真实的保护动作。把检修压板投入短接开入量让保护出口确认后台能收到带时标的保护动作事件、故障测距和录波文件三者时间戳要能对上。这一步过了这条网络103链路才敢说真正具备投运条件。我吃过一次亏定值能读、遥测正常波形召唤也能回结果真实故障时录波文件只有一半。后来查下来是后台拼包超时时间设得太短录波数据量一大就丢尾部包。从此我的验收清单里永远多一项“模拟触发一次录波并核对文件完整性”不再轻信单条召唤成功。希望这份经验能帮你少走一段弯路联调顺利。本文还有配套的精品资源点击获取

网络103规约联调避坑：故障录波与FUN/INF映射实战

相关推荐

长任务Agent工程实战：Context、Loop与Graph架构设计

Windows 本地部署 MinerU 4.0：RAG 文档解析与批量处理实战

零成本搭建AI工作流：编排与执行分离的工程实践

更多资讯

攻击溯源与应急响应系统设计：从日志分析到处置闭环实战指南

双向链表与循环链表实战：多级菜单回退与轮询调度

LoRa自组网设备原理：RS485、net_id与IAP协同机制深度解析

SO-DIMM物理兼容性指南：DDR3与DDR4不可互插的四大铁律

PCB拼板设计全攻略：邮票孔、工艺边与Mark点实操指南

PCIe Polling.Compliance进入与pattern生成：合规性测试避坑指南

今日更新

Multisim仿真NE555 PWM控制器：从搭电路到调占空比全流程

S32K312 AUTOSAR BSW开发实战：从配置踩坑到烧录交付

双目视觉三维人脸重建：从视差图到点云粗配准全流程解析

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？