干变电站综自调试的人十有八九躲不开103规约这四个字。它是继电保护装置与监控后台之间的“对话规则”搞清楚主站、子站之间怎么建立连接、怎么交换数据、怎么把一组组报文翻译成看得懂的遥信遥测现场调试至少能少熬一半的夜。这篇文章结合我调试南自系列保护装置的经验把以太网103规约的通信机制从头到尾捋一遍既有理论也有现场踩坑记录适合刚入门的继保调试、监控系统集成工程师也适合准备做规约转换和协议分析的朋友。1. 项目背景与整体设计思路1.1 为什么现在还要啃103规约有些朋友会问现在不都在推61850了吗103还有必要学吗有而且实际工程里碰到得比想象中多得多。第一存量设备基数太大。早期投运的变电站、电厂里保护装置十有八九走的是103规约这批设备还远没到退役年限日常运维、消缺、技改都要跟它们打交道。第二103规约本身就是围绕继电保护专业设计的保护动作、重合闸、故障测距、定值这些信息在103里都有专门的模型和报文组织方式从调试角度讲通过103理解保护装置的通信行为反而比直接用61850更直观。第三很多规约转换装置、通讯管理机对外接61850对内接保护装置时仍然要用103或者104你作为主站侧工程师不懂子站侧的103定位起问题来会非常吃力。1.2 以太网103和串口103的本质差异传统103最早是跑在串口上的RS232或者RS485波特率一般9600或者19200一对一或者手拉手。串口103的问题很明显速率低传录波这种大文件要等半天距离也受限而且一个串口通常只能连一个主站扩展性很差。以太网103就是把这套应用层规约搬到TCP/IP网络上传输一般有两条路线一种是把FT1.2链路帧整个封装到TCP报文里以太网只起管道作用链路层、应用层的格式跟串口103基本一致另一种是直接丢掉FT1.2帧壳用TCP承载ASDU相当于把链路层替换成TCP层控制域、地址域的信息直接放到应用层处理。南自的保护装置在以太网103上多数采用前一种思路链路层帧结构还保留着只是底层从串口换成了Socket。这么做的好处是兼容性好原来串口103的报文字节能继续使用现场维护人员上手成本低坏处是帧里保留了不少在以太网上已经“冗余”的校验字段刚接触的人容易被这堆字节搞晕。1.3 南自设备通信架构特点南自系列保护装置的网口一般分前面板调试口和背板站控层口做以太网103通信用的是站控层口。一个装置可以同时作为TCP服务端监听固定端口接受监控后台发起的连接。也就是说连接是主站主动建立的子站被动等。工作现场常见的接法是保护装置网口接到站控层交换机监控后台主机也接到同一台交换机组成一个二层局域网。IP地址按工程规划好装置和后台必须在同一个网段否则连不通。还有一点要提醒南自这类保护装置在出厂或者定检后端口配置、IP地址都可能被改过新接入后台之前先用厂家调试软件或者面板菜单确认装置当前的网络参数比盲目在后台侧反复改配置要快得多。2. 报文格式与信息模型详解2.1 以太网103的帧格式以太网103的链路层沿用了IEC 60870-5-1的FT1.2帧格式。一帧报文大概长这样68H L L C A ASDU CS 16H68H启动字符固定不变就是一帧开始的标志L帧中控制域C到ASDU结束的字节数占两个字节内容相同用于校验长度的一致性C控制域标识这帧是主站发的还是子站发的、是确认帧还是数据帧、有没有序号请求A地址域一般填装置地址或者公共地址ASDU应用服务数据单元规约要传的业务数据全在这一段CS校验和前面所有字节累加后取低8位16H结束字符固定不变。这里解释一下在串口链路上FT1.2加这么多校验是为了防止线路干扰。到了以太网上TCP协议本身已经提供了可靠传输和流控这些校验字段其实起不到额外保护作用但规约要兼容历史报文所以字节结构还是保留了下来。听懂这点你抓包看报文时就不会因为“怎么这么多没用的字节”而纠结。我在调南自装置时经常用厂家调试软件抓一段报文再和规约文档逐字节对比。第一次建议找一个“总召唤结束”这种短帧练手结构简单不容易看花眼。2.2 ASDU应用服务数据单元ASDU是整个103规约的核心。它由类型标识、可变结构限定词、传送原因、公共地址、信息体地址和信息元素组成。类型标识告诉你这条报文是什么类型比如是遥信变位、遥测值、保护事件还是通用分类数据可变结构限定词表示后面跟了几个信息体以及信息体是否按顺序排列传送原因说明这条数据是周期上送、总召唤响应还是突发上送公共地址是该装置在系统中的编号信息体地址和信息元素就是实际的点号和值了。在103规约里一旦涉及保护功能相关的数据就不是直接给一个简单的点号而是用功能类型FUN加上信息序号INF来定位。打个比方如果把保护装置比作一个大柜子FUN就是“哪个抽屉”INF就是“抽屉里第几个格子”只有FUN和INF组合在一起主站才能知道这条数据对应的是距离一段动作、过流二段动作还是重合闸出口。通信调试中很多“报文收到了但画面不变”的问题往往就是FUN/INF对应的点表没对上。2.3 功能类型FUN与信息序号INF怎么查每个厂家的103规约点表里都有FUN/INF的对照表。以保护装置某个开关量输出为例它在点表里可能是某个FUN下的某个INF保护动作事件也可能是不同的FUN和INF组合。实际操作中我建议把厂家点表打印出来或者做一个Excel映射表把FUN、INF、描述、数据类型、上送方向列清楚。联调时用模拟变位或保护试验仪加量逐个触发观察后台收到的是不是点表对应的点。如果实际收到的FUN/INF和点表不一致要优先怀疑是装置侧点表配置错了还是后台数据库映射错了。前者需要用厂家调试软件读取装置内部点表后者需要检查后台的数据库关联配置。点表核对看起来枯燥但它是103调试里最花时间也是最重要的一环。点表错了通信链路再通、报文再漂亮后台画面和事件照样是错的。3. 主站与子站通信机制深入拆解3.1 连接建立与心跳维持以太网103的通信第一步是建立TCP连接。子站保护装置作为服务端监听一个固定端口主站监控后台作为客户端用配置文件里写的IP和端口去连。TCP连接建立以后规约层通常还要做链路确认。主站会周期性发送测试帧或者链路状态询问报文子站收到以后回一个确认帧。这个交互有双重作用一是确认双方规约层状态正常二是维持连接不被中断。实际运行中如果主站和子站长时间没有业务数据而中间交换机开启了空闲连接超时策略TCP连接可能会被清除这时候有一路心跳帧就能把连接“钓住”避免通信频繁中断。我调过一些现场后台显示通信正常但一有保护动作就报“通信中断”后来发现是连接里空闲时间太长中间设备把会话清了而主站又没有及时重连。解决办法就是把链路的测试帧周期改短或者让保活机制生效。3.2 总召唤流程主站和子站建立连接并确认链路正常后接下来就是总召唤。总召唤的目的是让子站把自己当前的全量数据状态都上送给主站包括所有遥信、遥测、保护定值、装置参数这些。主站重启、后台切机、通信中断后恢复都需要靠总召唤把画面刷起来。过程大概是主站下发总召唤命令子站收到后开始按顺序上送数据数据量大的时候会分成很多帧主站要一帧一帧收直到收到子站上送的总召唤结束报文才算这一轮总召唤完成。如果总召唤没有结束报文主站会一直处于“等待数据”的状态画面上很多点可能会卡住不刷新。现场常见问题就是总召唤数据太多子站要一条条排队上送带宽不够时容易超时。遇到这种情况先看交换机端口是否有大量丢包或冲突再确认子站上送间隔配置是否合理。别一上来就怀疑装置坏了。3.3 主动上送遥信变位与保护事件这是103最核心的能力。当保护装置检测到开关变位、保护动作、告警等信息时它会主动向主站上送带时标的报文不需要等主站来问。这条报文里包含具体的FUN/INF信息、状态、品质描述和发生时刻的时标时标精度往往是毫秒级。为什么毫秒级时标重要因为SOE事件顺序记录要依赖它。变电站里多个装置几乎同时上报保护动作和开关变位后台要按真实发生顺序还原整个故障过程时标错一个毫秒事件顺序就可能颠倒分析结论就完全不同。主动上送的报文主站收到后一般要回确认。如果子站没收到确认会根据重发次数和超时机制重发这条报文。调试时如果发现同一事件后台收到了好几条先查是不是确认机制那一侧没配对或者网络丢包导致子站误判。3.4 时钟同步与对时保护装置内部的时钟精度有限而且会漂移。为了让所有装置的事件时标一致主站需要定时向子站下发对时命令。常用的对时方式有SNTP、IRIG-B、103规约对时命令等具体用哪种要看工程和装置支持情况。在103链路里主站周期发送时钟同步命令子站收到后用命令里携带的时间校准本地时钟。对时失败是个很隐蔽的问题表面看通信正常、报文也有可SOE事件时标一旦比对发现各装置时间相差几秒甚至几分钟故障分析就乱了。排查时优先看对时源的稳定性、网络是否拥塞、装置是否配置了正确的时区和对时方式。3.5 文件传输与录波上送保护动作后会生成故障录波文件可能包含故障前后的电压电流波形。103规约有一套文件传输机制来上送这类文件大致流程是子站生成文件后上送文件目录信息主站收到后根据文件标识下发读文件请求子站把文件内容分块上送主站校验完整后确认接收。也有不少现场采用折中方案103只管通知“有录波文件生成”实际文件通过FTP或者其他方式由监控系统拉取。无论哪种方式主站侧都要处理好文件命名、时间对应和去重逻辑不然一个故障可能把同一段波形重复上送好几遍。4. 现场调试实操与配置要点4.1 IP规划与端口配置调试前先把IP理清楚。保护装置、后台主机、调试电脑都要在同一网段子网掩码一致否则TCP连接建立不起来。如果装置有双网口双网冗余情况下两个口的IP要按厂家的冗余方案规划不要随手填否则反而不通。端口号方面以太网103没有像104规约那样固定为2404南自装置常用的端口要看该型号的规约文档和装置参数菜单。我在现场遇到不少调试人员习惯性用2404或者默认端口去连连不上才想起翻文档白白浪费时间。建议进场调试前先用厂家调试软件连接装置把IP、端口、装置地址这些参数都确认一遍。还有一点修改装置的网络参数后有些装置需要重启才能生效有些即时生效都要确认清楚。改完IP后先ping一下ping不通先检查物理链路别继续往下配。4.2 点表核对流程点表是103调试的灵魂。流程一般是先拿到厂家确认的103规约点表然后把后台监控系统的数据库按照点表建立映射再把点表导入或者录入后台组态软件最后用现场试验逐点验证。验证方法很直接用保护试验仪或者装置面板操作让装置触发一个遥信变位或保护事件看后台对应的点是否正确上送、名称是否匹配、时标是否准确。遥测也一样给装置加一个电流电压量看后台数值是否和加量一致。这一步别嫌麻烦我在现场见过因为点表错位导致“重合闸动作”显示成“断路器合位”的乌龙排查了半天最后发现是点表映射整体偏移了一位。4.3 用抓包工具定位通信问题抓包是调试以太网103的必备技能。Wireshark抓TCP报文过滤条件可以直接用tcp.port 端口号。抓包后先看TCP三次握手是否成功再看有没有规约层的测试帧、总召唤命令和子站的上送报文。如果是链路层问题抓包能明显看到重复发送、乱序或者TCP重传如果是应用层问题TCP看起来一切正常但一帧ASDU都解析不出来此时多半是端口不对、报文格式不兼容或者点表映射错。我的习惯是先确认连接建立再确认总召唤有没有完整结束最后再定位具体业务报文。链路不好业务报文分析得再细也没用。5. 常见问题与排查技巧实录5.1 高频问题速查表现象可能原因排查思路主站一直连不上子站IP不在同一网段、端口错误、装置103服务未开启、中间交换机隔离ping装置IP确认端口和装置参数连接建立后无任何报文主站没发总召唤、链路测试周期未配置查看主站规约参数确认是否发起了总召唤总召唤超时或数据不完整子站数据量大、上送拥塞、TCP窗口太小观察抓包的重传和丢包调大缓冲遥信变位不上送点表映射错、对应功能未使能、主站未确认核对FUN/INF检查装置上送使能收到报文但后台无画面后台数据库点号映射错误、类型不匹配比对点表和后台库做模拟变位验证事件时标不对对时失败、时区设置错、装置时钟漂移检查对时源和SNTP状态5.2 三个值得细看的排查案例一个案例是后台频繁报通信中断。当时抓包发现TCP连接反复重建是因为后台重启后发起了大量连接请求而子站的连接数被占满新的连接进不来。后来在后台侧限制了连接重试次数和间隔并在子站侧调整了连接空闲释放时间问题才解决。还有一个案例是总召唤一直收不到结束帧。抓包发现子站按顺序上送但上行TCP窗口很小导致数据帧被拆得特别碎主站处理不过来出现了大批次TCP重传。调整主站侧接收缓冲和TCP窗口参数后总召唤几秒钟就完成了。第三个是保护动作事件重复上送。后台每收到一条保护事件就打印一次结果一个单相接地故障后台刷出了五条相同记录。最终查下来是主站的确认帧超时设置得太短子站没来得及收到确认就重发。把确认超时调整到合理值之后重复事件立刻消失。这些情况提醒我规约调试遇到问题时一定要先分清楚是链路层、规约层还是应用层的问题。链路层看TCP握手和重传规约层看总召唤和测试帧应用层看点表和数据库映射。一层一层排查绝大多数问题都能快速定位。6. 最后再说几句经验我在实际调试里有个习惯每到一个新现场先把装置的规约版本、点表版本、后台版本三个版本号记录清楚再开始联调。103规约看起来标准统一但各个厂家、各个版本之间总有一些细节差异版本对不上很多问题会查得一头雾水。另外如果你也是刚接触以太网103建议先从“总召唤”这条最简单的链路入手把一帧报文的每个字节都对着文档看一遍再去看事件上送和文件传输你会发现后面的东西都是在这个基础上叠加的。抓包工具一定要熟练很多通信疑难杂症最终都是靠抓包一锤定音。这个内容后续还可以继续扩展比如把103规约和104规约在应用场景上的区别单独写一篇或者把南自装置的通用分类读写定值下装流程拆开细讲。如果你手头正好在调相关项目欢迎留言交流我可以把遇到过的细节再补充进来。