1. 从一次深夜告警说起为什么我们需要了解104规约凌晨两点监控大屏上一个变电站的通信状态突然从绿色变成了刺眼的红色告警信息是“与站端104通信中断”。运维同事的电话立刻打了过来“主站和子站之间的数据全断了遥测、遥信都收不到调度那边已经催了。” 这不是我第一次处理104规约的通信故障但每一次都像是一场与时间的赛跑。104规约这个在电力自动化领域如同空气和水一样基础却又常常被忽视的通信协议一旦出现问题就意味着调度员失去了对远方变电站的“眼睛”和“耳朵”。简单来说IEC 60870-5-104规约我们通常简称104规约是电力系统调度自动化中用于主站调度中心与子站变电站、发电厂之间进行实时数据通信的国际标准协议。它定义了数据如何打包、如何传输、如何确认确保遥测如电压、电流、遥信如开关分合状态、遥控如远程操作开关等关键信息能够准确、可靠地在广域网上交换。你可以把它想象成电力系统内部一套精密而严格的“电报密码本”主站和子站必须使用同一本密码本才能进行有效对话。对于从事电力自动化、配网运维、SCADA系统开发或集成的工程师来说深入理解104规约不是可选项而是基本功。无论是进行新站调试、排查通信故障还是开发数据采集程序你都会发现对104规约的认知深度直接决定了你解决问题的效率。本文将从协议框架、报文解析、会话流程到实战排错为你彻底拆解这套“密码本”让你不仅能看懂报文更能理解其设计哲学从而在遇到问题时能快速定位是“密码本”本身的问题还是通信链路或设备配置的问题。2. 协议栈与帧结构104规约的“骨骼”与“血肉”要理解104规约首先要把它放在OSI七层模型里看。104规约主要定义了应用层第七层的报文格式和规则而它依赖于成熟的TCP/IP协议栈来处理网络传输。这是一个非常关键的设计应用层104负责业务逻辑传输层TCP负责可靠连接。这意味着104规约自身不需要像它的前身101规约基于串行链路那样处理复杂的链路层确认、超时重发而是可以专注于数据本身的高效组织。一个完整的104规约报文就是在TCP数据流中一个个独立的“应用协议数据单元APDU”。每个APDU都由两部分构成启动字符68H、长度字段、控制域和应用服务数据单元ASDU。其中控制域是104规约的“大脑”决定了这个报文是心跳、确认还是携带数据而ASDU则是“货物”里面装着具体的遥测、遥信等信息。2.1 控制域C会话管理的核心控制域占4个字节是理解104会话状态的关键。它主要分为三种格式对应三种类型的报文I格式信息传输格式用于传输包含ASDU的数据报文。它的控制域包含发送序列号N(S)和接收序列号N(R)。这借鉴了TCP的思想实现了应用层的确认机制。发送方每发一个I帧N(S)就加1接收方正确收到后需要在回复的I帧或S帧中将N(R)设置为已收到的最后一个I帧的N(S)1以此进行确认。S格式监视格式这是一个“纯确认”报文。当接收方没有数据要发送但需要确认已收到的I帧时就发送一个S格式报文。它只包含接收序列号N(R)用来告诉对方“你发到N(R)-1号的数据我都收到了。”U格式控制格式用于建立和释放连接。主要有三种类型STARTDT启动数据传输连接建立后由主站或子站发送激活数据传输通道。在这之前双方即使TCP连接通了也不会交换业务数据。STOPDT停止数据传输暂停数据传输但保持TCP连接。TESTFR测试帧用于连接保持心跳。当长时间没有业务数据I帧需要发送时双方会定时发送TESTFR激活帧对方回复TESTFR确认帧以此证明链路活跃。注意很多初学者会混淆TCP的Keep-Alive和104的TESTFR。TCP Keep-Alive是操作系统网络栈层面的机制间隔很长通常以小时计目的是探测TCP连接是否存活。而104的TESTFR是应用层心跳间隔很短通常10-30秒目的是证明104应用层进程是活跃的。一个TCP连接可能活着但104进程可能已经僵死此时就需要TESTFR来发现。2.2 ASDU结构数据组织的艺术ASDU是业务数据的载体结构复杂但规整。一个ASDU由数据单元标识符和一个或多个信息对象组成。数据单元标识符像是快递单号告诉你这是什么“货物”类型标识Type ID, 1字节最重要的字段。它直接定义了ASDU的类型。例如9归一化值遥测每个值占2字节代表一个带品质描述的测量值。1单点信息遥信每个值占1字节表示一个开关/刀闸的状态合1分0。45单命令遥控用于下发一个简单的开关操作。100召唤目录用于初始化数据召唤。103时钟同步命令。可变结构限定词VSQ, 1字节最高位指示信息对象的组织方式。为1表示“顺序方式”即后续信息对象的地址是连续的为0表示“非顺序方式”每个信息对象都自带完整地址。低7位表示本ASDU中包含的信息对象数量。传送原因COT, 1或2字节说明这个数据是为什么传送的。常见值有3突发自发—— 子站主动上送变化数据。5被请求—— 主站召唤后上送的数据。6激活—— 遥控、设点等命令的激活。7激活确认—— 对激活命令的确认。10激活终止—— 命令执行终止。20响应站召唤—— 响应主站的站召唤命令。公共地址Common Address, 1或2字节代表子站的站地址。在一个TCP连接上可能复用多个子站地址即多个逻辑站这个字段用于区分数据来自哪个逻辑站。信息对象则是具体的“货物内容”。它至少包含信息对象地址IOA, 通常3字节和信息元素。IOA是系统中每个数据点如“1号主变高压侧A相电流”的唯一标识。信息元素则是该数据点的具体值其格式由类型标识决定。例如一个传输3个连续遥测点的ASDU可能看起来像这样类型标识: 9 (归一化值) VSQ: 0x83 (最高位1顺序低7位33个对象) 传送原因: 3 (突发) 公共地址: 0x0001 (站地址1) 信息对象地址: 0x000100 (起始地址) 信息对象1值: 0x1234 (带品质描述的值) 信息对象2值: 0x5678 信息对象3值: 0x9ABC由于VSQ指示为顺序方式系统知道这三个遥测点的地址分别是0x000100, 0x000101, 0x000102。3. 通信会话流程全解析从握手到数据奔流理解了静态的帧结构我们来看动态的会话流程。一个完整的104通信周期就像一场精心编排的双人舞。3.1 连接建立与激活TCP三次握手这是底层网络连接由操作系统完成。确保物理链路和IP路由是通的。104连接建立TCP连接建立后双方104应用程序开始对话。通常由主站或子站取决于配置发送一个U格式的STARTDT激活帧。对方收到后必须回复一个STARTDT确认帧。关键点只有交换了STARTDT确认之后双方才能开始传输携带ASDU的I格式报文。在此之前只能传输U格式或S格式报文。这是104规约一个重要的状态机切换点很多通信不通的问题就卡在这里——TCP通了但STARTDT没成功交换。3.2 总召唤与时钟同步数据初始化的“标准动作”连接激活后主站为了获取子站的完整数据状态会发起两个关键初始化过程总召唤总查询主站发送一个类型标识为100的召唤目录ASDU传送原因一般为“激活”6。子站收到后回复一个相同的ASDU作为“激活确认”传送原因变为7。接着子站开始将站内所有需要上传的遥信、遥测等数据分多个I帧发送给主站。每发送一批主站都需要用I帧或S帧进行确认。全部数据发送完毕后子站再发送一个类型标识为100的ASDU传送原因变为“激活终止”10告知主站总召唤过程结束。时钟同步主站发送一个类型标识为103的时钟同步命令ASDU里面包含主站的当前时间。子站收到后首先回复一个“激活确认”传送原因7然后将自己的系统时钟调整为接收到的或稍作处理后的时间。调整完成后子站再发送一个“激活终止”传送原因10的确认帧。有些规约会要求子站回送一次自己的时间作为验证。实操心得在调试新站时一定要在监控软件或抓包工具里确认“总召唤”和“时钟同步”流程完整走通。如果总召唤后收不到数据可能是子站库配置信息体地址、类型与主站库不对应。如果时钟同步失败后续所有带时标的数据如SOE的时间都可能有问题会给故障分析带来极大困扰。3.3 平衡式传输与流量控制104规约采用平衡式传输即主站和子站都可以主动启动传输例如子站可以主动上送变位遥信。这依赖于之前提到的I帧序列号N(S)和N(R)。流量控制通过两个参数实现k和w。k表示发送方在未收到对方确认的情况下最多能连续发送的I帧数量。默认值通常为12。w表示接收方最多能接收的未确认I帧数量。默认值通常为8。发送方维护N(S)每发一个I帧N(S)加1。当“已发送未确认的I帧数量”即 N(S) - 最近收到的N(R) 达到k时发送方必须停止发送新的I帧直到收到确认使未确认数量小于k。 接收方维护N(R)当“已接收但未回复确认的I帧数量”达到w时即使没有数据要发送也必须立即发一个S帧进行确认以防止发送方因达到k而阻塞。这个机制有效地防止了快速发送方淹没慢速接收方是104规约在不可靠网络环境下保持稳定的关键。3.4 通信中断与恢复当TCP连接意外断开网络闪断、设备重启恢复后的处理至关重要重新建立TCP连接。重新交换STARTDT激活连接。关键步骤主站通常会立即重新发起一次“总召唤”。因为连接中断期间子站可能发生了很多状态变化遥信变位主站需要通过总召唤来同步全数据确保两侧数据库状态一致。之后子站再将以“突发”原因上送中断期间积压的SOE事件顺序记录等信息。4. 关键参数与工程配置实战纸上得来终觉浅绝知此事要躬行。理解协议后最终要落到配置上。以下是工程实施中必须关注的几个核心参数及其配置逻辑。4.1 超时时间参数t0, t1, t2, t3这些参数定义了各种状态下的等待时间配置不当会导致链路频繁中断或响应迟缓。参数名默认值典型含义配置要点与影响t030秒连接建立超时。TCP连接尝试建立的等待时间。网络状况差时可适当延长。超时后认为连接失败。t115秒发送或测试APDU的超时。发送一个I帧或U帧后等待确认的最长时间。这是最重要的参数之一。设置过短在网络延迟大时容易误判超时频繁断线设置过长故障响应慢。需根据实际网络RTT调整。t210秒无数据报文时确认收到I帧的最长时间。即收到I帧后如果t2时间内没有其他I帧要发就必须单独发一个S帧来确认。通常小于t1。影响确认的及时性。t320秒长期空闲连接测试周期。当超过t3时间没有发送任何I帧就主动发一个U格式的TESTFR测试帧。用于维持应用层心跳。应小于TCP连接的超时时间。配置经验在跨地域的广域网中网络延迟可能达到几百毫秒甚至更高。此时t1绝对不能使用默认的15秒。一个比较稳妥的做法是在链路空闲时通过ping命令测试一下主站到子站的往返延迟RTT然后将t1设置为 RTT * 3 缓冲时间例如2秒。例如RTT为500mst1可设为 0.5*3 2 3.5秒建议配置为5秒。t3则应略大于t1确保在等待确认时不会误触发TESTFR。4.2 站地址与信息体地址IOA这是最容易出错的配置点直接导致数据对不上。公共地址站地址在子站设备如测控装置、保护设备和主站系统中必须配置一致。它通常是一个1-65535的整数。一个物理通道一个IP端口上可以承载多个不同公共地址的逻辑连接。信息体地址IOA这是每个数据点在系统中的“身份证号”。例如1号主变高压侧A相电流的IOA可能是0x0000011号线路开关的位置可能是0x400001。主站系统的数据库点表必须和子站设备生成的点表严格一一对应包括IOA、类型标识是遥测9还是遥信1、数据格式是归一化值还是标度化值。避坑指南点表配置是调试工作的重中之重。强烈建议使用Excel等工具制作点表对照表至少包含“信号名称”、“子站IOA”、“子站类型”、“主站IOA”、“主站类型”这几列。在调试前双方工程师必须逐项核对。一个常见的错误是子站定义的IOA是3字节如0x000001而主站系统配置时误将其当作2字节整数1处理导致地址映射全部错位。4.3 网络配置IP、端口与TCP参数IP与端口104规约默认使用TCP端口2404。主站作为客户端主动连接子站服务器端。需要在子站设备上设置监听IP和端口在主站上配置目标IP和端口。确保防火墙放行了相关端口。TCP Keep-Alive虽然104有自己的TESTFR但操作系统的TCP Keep-Alive也应启用作为底层链路的最后保障。可以设置为比t3更长的时间如300秒。TCP缓冲区对于数据量大的站如大型变电站适当调大TCP发送和接收缓冲区可以减少因缓冲区满导致的传输延迟或丢包。5. 典型故障排查思路与报文分析实战当通信中断或数据异常时系统性的排查思路比盲目尝试更有效。下面结合一个典型案例展示如何利用抓包工具如Wireshark进行分析。故障现象主站显示与某子站通信中断但ping子站IP是通的。排查步骤确认物理与网络层ping测试通过说明物理链路和IP层基本正常。检查主站和子站的网卡指示灯、交换机端口状态。检查TCP连接在主站或网络设备上使用netstat -an | findstr :2404Windows或netstat -tlnp | grep 2404Linux命令查看2404端口是否有ESTABLISHED状态的连接。如果没有说明TCP连接未建立。抓包分析核心手段在子站服务器或中间网络设备上如有镜像端口进行抓包过滤条件设为tcp.port 2404。场景ATCP连接反复建立后立即断开。查看抓包文件发现主站发送TCP SYN子站回复SYN-ACK主站再回复ACK完成三次握手。但紧接着主站发送了TCP RST复位报文。这通常意味着主站的104应用程序在连接建立后主动关闭了连接。可能原因有主站配置的子站IP或端口错误连接到了错误的设备。子站设备尚未启动104服务程序。主站侧程序异常崩溃。场景BTCP连接建立但无104报文交换。看到TCP连接保持ESTABLISHED状态但没有任何104报文68H开头的报文。这说明TCP通路正常但104应用层没有启动。可能原因子站设备104服务未激活或配置错误。主站侧未配置对该子站的连接或连接被禁用。场景C有104报文但通信状态不稳定。这是最常见也最需要分析协议交互的场景 查看报文发现流程如下主站 - 子站: U帧 (STARTDT激活) 子站 - 主站: U帧 (STARTDT确认) // 连接激活成功 主站 - 子站: I帧 (类型标识100总召唤激活) 子站 - 主站: I帧 (类型标识100总召唤激活确认) // 此后子站开始发送大量I帧数据... 主站 - 子站: S帧 (确认号N(R)x) // 主站确认了一部分数据 // 一段时间后主站发送TESTFR激活 主站 - 子站: U帧 (TESTFR激活) // 等待超过t1时间如15秒... 主站 - 子站: TCP RST // 主站主动断开连接分析问题出在子站没有回复TESTFR确认。主站发送TESTFR激活后启动t1定时器等待子站的U格式TESTFR确认帧。超时后主站认为应用层连接失效于是发送TCP RST断开连接。根本原因在于子站设备处理U格式报文异常或者网络存在单向中断子站收得到发不回。进阶分析序列号与流量控制。如果通信时断时续可以观察I帧的N(S)和N(R)。发送方N(S)停滞如果发现主站或子站的发送序列号N(S)长时间不增加说明它被流量控制卡住了达到了k值上限在等待对方的确认。检查对方回复的S帧或I帧中的N(R)是否在增长。如果N(R)也不变说明确认报文可能丢失或接收方处理不过来。序列号回绕N(S)和N(R)是模128循环的0-127。这是正常现象。但有些老旧的主站系统在处理序列号回绕时可能有bug导致误判。工具推荐Wireshark内置了104规约解析器。安装后抓取的数据包可以直接在“应用层”看到解析好的104报文结构包括类型标识、传送原因、IOA等极大提升了分析效率。务必学会使用这个工具。6. 常见疑难杂症与处理经验除了上述典型故障在实际运维中还会遇到一些“奇怪”的问题。遥信频繁抖动双点通信一个开关位置在“分”和“合”之间频繁变化。首先排除一次设备实际抖动的可能。然后检查报文确认子站上传的遥信值是稳定的。问题很可能出在主站系统的数据库点表配置错误将“单点信息”值1合0分错误地配置成了“双点信息”值1分2合0/3无效。当子站上传稳定的“1”时主站按双点解释就成了“分”与实际情况相反如果再有其他干扰就可能显示抖动。遥控预置成功但执行失败遥控过程分为“预置选择”和“执行”两步。预置成功说明通信和点号正确。执行失败需要查看子站是否回复了“激活终止”或“遥控执行”报文。如果没有可能是子站内部逻辑如五防校验、就地/远方把手位置未通过。务必在子站本地日志或装置面板上查看具体的拒绝原因。通信正常但部分数据不上送检查子站设备的上送机制。104规约支持周期上送和变化上送突发。如果某个遥测点配置为“变化上送”且“死区”设置过大那么当数值变化未超过死区值时就不会触发上送。对于非常重要的数据建议配置为“周期上送”以确保连续性。SOE时标错乱SOE事件顺序记录对时标精度要求很高通常毫秒级。如果发现SOE时间错乱首先检查时钟同步是否成功。其次检查子站SOE时标的时区配置。有些设备产生的时标是UTC时间而主站系统可能按本地时间处理导致显示相差8小时。处理这些问题的核心在于建立清晰的逻辑将问题域层层剥离。先区分是网络问题、104链路问题还是数据配置问题。用抓包工具确认报文交互是否符合协议流程用对比法确认两侧配置是否一致。每一次成功的排障都是对104规约理解的一次深化。这个协议看似枯燥但当你真正读懂每一帧报文背后的对话就能在复杂的自动化系统中游刃有余成为那个在深夜告警中快速定位问题、恢复通信的关键角色。