IEC104电力远动通信协议详解：报文机制与工程调试实战

1. 先搞懂IEC104到底解决什么问题

1.1 电力调度通信的真实场景

先说说IEC104通信协议在我实际工作中到底是怎么冒出来的。如果你在电力自动化、新能源电站、储能站、智能变电站、配网自动化这些领域待过，一定绕不开一件事：站内的测控装置、保护装置、电度表、环境监测设备，需要把电压、电流、有功、无功、开关位置、告警信号这些数据送到调度主站或者集控中心去。反过来，调度主站也要能下发遥控命令，比如分合闸、调节有功出力、设置定值。这套站端设备与主站之间“数据上送+命令下发”的通信规则，就是远动通信协议要干的事。

IEC104通信协议，全称是IEC 60870-5-104，它本质上是把早期基于串口的IEC 60870-5-101协议，映射到TCP/IP网络传输层上的一套应用层协议。简单理解：101是“老式串口邮局”，104是“互联网化之后的快递系统”。它默认跑在TCP 2404端口上，主站作为TCP客户端去连接作为服务端的站端设备（当然角色也可以互换，但工程上绝大多数是主站主动连接）。为什么这么多年过去了，IEC104还是绝对主力？因为稳定性好、实现成本低、调试方便、上下游生态成熟，不管是南瑞、国电南自、许继、四方这些国内主流厂家的设备，还是西门子、ABB、施耐德的保护测控装置，基本都支持。

如果你刚入行，或者准备做电力监控系统集成、储能EMS系统开发、光伏电站SCADA系统，又或者要对接调度侧数据网，这篇文章可以帮你把IEC104从报文层面、交互流程层面、工程排障层面整个串起来。我不会只讲理论，更多是这些年调试设备时踩过的坑和总结的规律。

1.2 为什么不是Modbus，也不是IEC61850

很多人会拿IEC104和Modbus、IEC61850作比较。Modbus在工业现场确实统治级存在，但它有一个先天问题：没有标准的对象寻址体系，数据点表全靠自己约定，而且功能码设计偏向寄存器读写，做遥信变位、SOE（事件顺序记录）、时钟同步这些电力业务时非常别扭。而IEC104天生定义了信息体地址，四种基本数据类型（遥测、遥信、遥控、遥调）分类清晰，还内置了召唤、时钟同步、档位调节、SOE等电力行业专用功能。

IEC61850则是另一条路线，它面向变电站站内通信，基于MMS、GOOSE、SV，建模思想是面向对象、自描述，非常强大但也非常复杂，调试门槛高，对设备性能要求也高。对于“站端到调度主站”这条远动链路，IEC104恰好处于一个甜点位：比Modbus更规范，比IEC61850更轻量。用一句话概括：做站内保护联锁选61850，做出站远动上送选104，做本地设备互联选Modbus。

1.3 一个典型系统的通信架构长什么样

我参与过不少光伏电站和储能电站的远动通信项目，结构基本是这样：站内各间隔的测控装置、保护装置、电能表，先通过RS485（Modbus）、IEC61850或者硬接线汇总到一台远动通信管理机（或者叫远动机、数据采集器）。远动通信管理机再按照IEC104协议，把整理好的点表数据封装成报文，通过电力调度数据网（通常是专用的路由器加纵向加密装置）送到调度主站。

这里有个关键点：站内采集用什么协议随意，但面向调度侧的出口协议，调度主站会明确要求是IEC104，点表也是双方提前核对签字的。所以做工程的人，可以不完全熟悉站内每种设备协议，但必须把IEC104这一层吃得透透的。否则点表对不上、报文发不出去、遥控被拒，现场会非常被动。

2. 协议核心机制拆解：从APDU到ASDU

2.1 报文结构：APCI和ASDU各管什么事

IEC104的报文全部基于APDU（应用协议数据单元）来组织，一个APDU由APCI（应用协议控制信息）和ASDU（应用服务数据单元）组成。如果你抓包看过，会在Wireshark里看到类似这样的十六进制片段：

text复制68 0E 00 00 00 00 64 01 06 00 01 00 00 00 00 14 00 00 00

• 0x68：起始字节，固定值，表示“我是一条IEC104报文”。
• 0x0E：后续长度，表示从下一个字节开始到报文结束一共多少个字节。
• 后4个字节是APCI的控制域，后面是ASDU内容。

APCI主要负责传输控制，包括I帧（信息帧）的发送序号和接收序号、S帧（监视帧）的确认序号、U帧（控制帧）的启动/停止/测试命令。ASDU则承载业务数据，里面包含类型标识、可变结构限定词、传送原因、公共地址、信息体地址和实际数据值。

很多初学者一上来就背报文结构，背了又忘。我的建议是从业务角度理解：APCI管“这封信怎么安全送到”，ASDU管“信封里装的是什么业务数据”。 调试时遇到收不到数据，先看APCI的序号有没有正常增长、有没有一直在重发；遇到数据值不对，再去看ASDU里的类型标识和信息体地址。

2.2 I帧、S帧、U帧：三种帧的职责边界

I帧（信息帧）用来传输业务数据，比如遥测、遥信、SOE，同时它也能捎带确认对端发来的报文。每个I帧带两个序号：发送序号N(S)和接收序号N(R)，都用3个比特位加一个取反位表示，因此序号有效范围只有0到15，超过15会循环回绕。注意，这和TCP序号不一样，TCP序号是32位的，IEC104因为早期基于串口设计，序号空间很小。

S帧（监视帧）不携带ASDU，只有一个接收序号N(R)，作用是纯确认，告诉对方“你发的序号到N(R)-1的报文我都收到了”。主站和从站交互频繁的场景里，如果有一方业务报文不多，但需要及时确认对方数据避免窗口占满，S帧就派上用场。

U帧（控制帧）用于链路控制，包括STARTDT（启动数据传输）、STOPDT（停止数据传输）、TESTFR（测试链路）。它们都没有序号，只有命令字节。最典型的场景是TCP连接建立后，从站先收到主站发来的STARTDT激活命令，然后才开始上送数据。这个机制极其重要，如果你在调试中发现TCP已经连上但一直收不到遥测数据，十有八九是STARTDT没有成功激活。

2.3 四遥数据类型和传送原因：别把YX和YC搞混

IEC104里最常见的几类ASDU类型标识：

类型标识决定这条ASDU“长什么样”，而传送原因（COT）决定“为什么发这条数据”。传送原因常见的几个值：6表示激活，7表示激活确认，8表示停止激活，9表示停止激活确认，20表示响应总召唤，3表示突发（变位），4表示周期上送。

我调试时经常遇到一个现象：装置发生了遥信变位，主站侧看到了SOE报文，类型标识70，传送原因3，信息体地址正确，但画面上的遥信状态没刷新。后来发现是主站对SOE报文和普通遥信报文的处理分支不同，SOE用于事件记录显示，实时位表刷新需要报文里带当前状态，若网关转发表没“反推”这个状态，画面自然不动。所以做转发时一定得注意SOE和常态遥信两条链路的处理差异。

2.4 信息体地址怎么编排：点表对不上的根源

信息体地址（IOA）是IEC104点表的核心。国内工程惯例一般是：遥信从1开始编（1~N），遥测从1025或2049开始编（比如2049=1路遥测，2050=2路遥测），遥控从4097或6145开始编。但每个省调、地调或者项目业主可能有自己的规定，所以点表必须以双方确认的“四遥点表”为准。

我用过一个方法快速核对IOA是否错位：先看同一帧里连续多个信息体地址的递增规律，如果地址从2049跳到2060，中间隔了10个，大概率点表里有些点被屏蔽或没有配置。排查时不要只盯单个点，要结合地址段分布来推断组态软件的配置。

2.5 链路超时参数：T0、T1、T2、T3分别管什么

IEC104工程调试中最容易被忽略、但出问题最多的就是一组超时参数。

T2为什么要小于T1？因为如果接收方迟迟不确认，发送方会在T1超时后触发重发或断链，如果T2大于T1，还没等到接收方的S帧确认，发送方就先判定超时了，链路会频繁断开。T3一般建议设为20秒，在只有长空闲没有业务的链路上，如果T3没有每20秒发一次TESTFR，NAT设备或防火墙可能会判定连接空闲而回收会话。

我遇到一个案例：某光伏电站远动链路频繁断开，排查很久发现是运营商侧防火墙的空闲会话超时设置为15分钟，而站端T3设的30分钟，导致链路被防火墙静默断开，双方都不知道，直到下一次数据上送才发现链路断了重新建连。后来把T3改小、加了心跳检测才彻底解决。

3. 从零搭一个IEC104通信链路：实操细节

3.1 TCP连接建立与STARTDT激活闭环

以最常见的“主站主动连接从站”为例，完整流程是：

1. 主站向从站的IP:2404发起TCP连接。
2. TCP三次握手建立后，主站发送U帧STARTDT激活：68 04 07 00 00 00。
3. 从站收到后回复U帧STARTDT确认：68 04 0B 00 00 00。
4. 从此刻开始，从站才能上送数据，主站也可以下发命令。
5. 如果主站要停止数据传输，可发STOPDT激活；链路空闲时，一方可发TESTFR测试链路。

很多新手只看TCP连接状态是ESTABLISHED，就以为通信正常，其实STARTDT激活之前，双方是不会进行业务数据传输的。调试时先用抓包软件确认几个关键帧：TCP握手→STARTDT激活→STARTDT确认→然后才看到总召唤或遥测报文。如果卡在第二步，检查主站的工作模式是否配成了“被动”模式，或者从站侧的规约配置里把“允许启动”关掉了。

3.2 总召唤、时钟同步、遥测上送：一个完整交互段

STARTDT激活之后，主站第一件事通常是下发总召唤命令（类型标识100，传送原因6），从站收到后先回激活确认（传送原因7），然后按信息体地址顺序把全站的遥信、遥测数据统统上送一遍（传送原因20），最后还要发一帧总召唤结束标志（类型标识100，传送原因10）。没收到这个结束标志前，主站应该把后续收到的数据都视作总召唤响应的一部分。这么做是为了保证画面初始化时能拿到全站全量的数据状态。

接下来是时钟同步。主站下发时钟同步命令（类型标识103，传送原因6），从站回确认。对时的意义不只是让站端和主站时间一致，更重要的是SOE事件记录必须依赖站端精确时标。如果对时失败，SOE时标会出错，事故追忆就会乱套，这是电网调度运行特别忌讳的。所以现场调试时，一定要确认对时命令被正确应答，同时比对主站和从站显示时间。

做完总召唤和对时，从站进入正常运行状态，周期上送遥测数据（传送原因4，周期），变位时立即上送遥信和SOE（传送原因3），主站对每一帧确认。如果主站长时间不确认，从站发送序号窗口填满了就会停止发送，直到收到确认。这个机制一定要理解，不然你看到从站“突然不发数据”会一头雾水。

3.3 遥控下发与返校机制：为什么遥控要“两步走”

遥控（YK）在电力系统里是高危操作，所以IEC104设计了“选择-执行”两步机制（S/E，Select/Execute）。主站先下发遥控选择命令（类型标识45或46，传送原因6，S/E位=S），从站收到后校验命令合法性，校验通过回一个选择确认（传送原因7），并把S/E位回声为S。然后主站再下发执行命令（S/E位=E），从站再次校验，校验通过回执行确认（传送原因7，S/E位=E），最后执行开关分合。

为什么不能直接执行？因为遥控命令一旦误发就是事故，两步机制确保主站先“预告”我要操作哪个点、操作什么值，从站确认这个点存在且值合法，主站再下达最终执行命令，相当于给了一次“人为确认”的机会。调试遥控时，如果从站回了“选择拒绝”或“执行拒绝”，先查遥控点号是否配置、控制输出是否被闭锁、S/E位是否填对。遇到过不少现场问题其实是组态软件把S/E位设置反了，导致从站永远当成了执行命令直接拒绝。

3.4 数据上送的两种模式：周期上送与变位上送

从站侧遥测默认是周期上送，周期通常设定为1秒、3秒或5秒。但不是所有数据都必须周期上送，像一些变化缓慢的温度、水位信号，周期太长实时性差，周期太短浪费带宽。很多装置支持“死区变化上送”，即变化量超过设定门槛（比如额定值的0.5%）才上送，否则不送，这跟Modbus那种“定时轮询”完全是两种思路。

遥信则全部依赖变位上送，开关状态不变化时不用重复发。但这里有个坑：链路刚重建或总召唤后，主站需要知道所有开关的当前状态，所以总召唤是必须的。如果从站设备的遥信变位上送功能没开，只是周期上送遥测，主站侧会看到电压电流一直在刷新，但开关状态永远不变，这种问题排查起来最费时间。

4. 常见问题排查与调试工具实战

4.1 从站接收不到报文/主站连不上2404端口

先确认物理链路和网络配置有没有问题，用telnet测试一下TCP端口通不通：

bash复制telnet 192.168.1.100 2404

如果端口不通，依次检查防火墙、路由、物理网线。如果端口通但主站连上后又立刻被断开，可能是主站规约参数配置不对，或者从站规约服务被其他主站连接占用。IEC104没有强制规定一个从站只能被一个主站连接，但很多厂家的实现默认只允许单连接，第二个主站连接会被直接拒绝。

4.2 报文在Wireshark里怎么看

Wireshark对IEC104的支持很好，拿到抓包文件后，直接在过滤栏输入：

text复制tcp.port == 2404 && ip.src == 192.168.1.10

Wireshark会解析出APCI字段、ASDU字段，甚至能解析出具体的遥测值。但有个前提：Wireshark会把多个TCP段拼成完整的APDU，如果网络有乱序或者TCP分段，它也能识别。遇到APDU解析异常，先看TCP层有没有重传/乱序。如果TCP层正常但IEC104解析乱码，很可能对端发的是非标准实现，这时要手动按字节去对。

4.3 调试工具选型：模拟主站和模拟从站

纯粹做协议对接测试，我用过几个比较有用的工具：

• IEC104主站模拟器：可以配置TCP客户端去连从站，发起总召唤、对时、遥控，查看返回的遥测遥信数据。用来测试从站设备是否正常很方便。
• IEC104从站模拟器：用来模拟装置侧，给主站调试提供数据源。有些商用模拟器支持点表导入、变位模拟、SOE主动上送，做培训演示也很实用。
• 综合规约分析工具：能同时启动多个实例，分别扮演主站和从站，还能按点表批量模拟遥测变化。现场排查时很顶用。
• Wireshark：被动抓包分析，不打乱现有通信。

工具的正版、破解问题我不展开，只说一点：无论是正版还是试用版，用模拟器之前先确认它实现的协议版本是2002版还是2016版，两者在部分扩展类型上存在差异，用错了版本互操作试验会莫名失败。

4.4 高频故障速查表

5. 工程实践中的核心经验与协议扩展

5.1 点表核对这件事，省不了也急不得

做了几年远动调试，我最大的体会是：协议本身并不复杂，真正拉开项目周期差距的，是四遥点表的编制和核对。点表错了，报文层面一切正常，但主站画面上数据全乱。所以每次验收前，我都会和主站侧一起逐点做“摇信传动”：对每一个遥信点，现场短接或分合一次开关，确认主站收到对应变位；对每一个遥测点，用继保仪加量，确认主站显示值与加量值一致；对每一个遥控点，先做选择，再执行，确认现场出口正确。

这套流程很枯燥，但省掉它的项目后期一定返工。我见过一个项目，全站800多个遥信点没做完整传动，投运后两天内发现了40多个错点，光是定位返工就花了一周。所以不要嫌麻烦，点表核对应专项安排时间。

5.2 与不同厂家设备的互操作：规约一致性比想象中重要

IEC104标准本身规范了报文格式，但实际实现时，不同厂家对某些细节处理并不完全一致。比如：有的从站在收到总召唤后，会先发一些缓冲的事件数据再发总召唤响应数据；有的从站对信息体地址的编排，不是按顺序而是按实际点号跳变。这些都不违反标准，但如果主站实现比较挑剔，就可能出现数据漏处理。

做系统集成时，建议在项目采购阶段就要求所有设备提供IEC104规约一致性测试报告，并安排一次联调前预测试。不同厂家的通信管理机固件版本不同，行为也有差异，调试时尽量统一版本。如果遇到设备行为异常，先查厂家规约说明书，不要自作聪明去改主站逻辑绕过去。

5.3 从IEC104走向IEC61850：你的技能树怎么点

IEC104相当长一段时间内会是电力远动通信的主流协议，但随着智能变电站和数字化变电站普及，站内设备越来越多采用IEC61850建模，远动通信管理机也逐步支持将61850模型自动映射到104点表上送。也就是说，未来的趋势是“站内61850，出站104”，你既需要懂61850的对象模型和SCD文件，也需要懂104的无编号点表。这两者之间的映射关系，是未来几年电力通信工程师的核心技能之一。

如果你刚接触IEC104，建议先把协议规范中的报文结构、类型标识、传送原因、四遥流程吃透，再配合实际设备或模拟器做几轮交互测试，最后通过抓包工具逐字节分析报文，才能真正形成自己的判断能力。

5.4 最后一个实用建议：永远保留一份干净的抓包文件

每次项目调试结束时，我都会把从TCP握手到正常运行的完整抓包文件导出存档，标注好日期、设备型号、固件版本、点表版本、关键操作时间点。这个习惯帮了我大忙：项目后期主站侧说“你们当初联调的时候数据是好的，现在怎么不行了”，直接把存档抓包文件拉出来比对，几分钟就能定位问题是新改配置引入的还是环境变化导致的。IEC104调试本身不复杂，复杂的是沟通成本和责任界定，有一份干净的报文记录在手，比任何嘴仗都有说服力。