网络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用的是FUN+INF各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、端口、链路地址和帧格式。后台侧建通道时，这些参数必须一一对应。我一般会先按下面的表整理好，再动配置界面：

这套参数表建好，通道才能进入联调阶段。下一步就是做点表。

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开头，那就是链路帧格式；如果每个包首字节在1～40之间跳动、且看不出统一规律，多半是直接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 按“先总召唤、再变位、最后扰动”的顺序验收

联调不要想一口气全通，按下面顺序走，每步有明确的成功标准，失败也能马上定位：

总召唤是第一步，它通了说明通道和公共地址没问题；变位上送通了说明点表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链路才敢说真正具备投运条件。

我吃过一次亏：定值能读、遥测正常，波形召唤也能回，结果真实故障时录波文件只有一半。后来查下来是后台拼包超时时间设得太短，录波数据量一大就丢尾部包。从此我的验收清单里永远多一项“模拟触发一次录波并核对文件完整性”，不再轻信单条召唤成功。希望这份经验能帮你少走一段弯路，联调顺利。

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