做电力自动化和动环监控的朋友，对IEC104协议应该不陌生——站内的RTU、DCS、保护装置，基本都靠它往主站送遥测遥信，也靠它接收调度端的遥控命令。可一旦这套系统要往“网管侧”对接，问题就来了：网管平台看的是SNMP，认的是OID，MIB树一展开全是1.3.6.1开头的节点，两边语言完全不同。最近我刚好完成了一个电力IEC104设备数据转SNMP的协议转换项目，把站端设备和综合网管系统打通，整个过程踩了不少坑。这篇文章把案例从需求拆解、协议分析、转换设计到现场调试完整梳理一遍，核心就是IEC104协议详解、SNMP协议适配，以及两者之间协议转换的落地细节，给准备做类似对接的朋友一个可直接参考的思路。项目听起来不难，但实际做起来，总召时序、品质位处理、OID规划、Trap防风暴，哪一步马虎都会让你在现场多熬几宿。
1. 项目背景与需求分析
1.1 为什么会有“104转SNMP”这种需求
先说场景。这里的IEC104设备，泛指以IEC 60870-5-104协议对外通信的站端设备，比如RTU、测控装置、DCS系统、电度表采集器等。这些设备在上层业务系统里，扮演着“数据源”的角色：一路遥测电压电流、一路遥信开关位置，都需要实时上送。通常它们被调度主站、监控后台采集，数据语义很完整，有品质描述、有带时标的记录、有遥控确认帧。
SNMP这边，则是综合网管、数据中心动环监控、企业能耗管理平台这类软件。它们通常只认SNMP协议，通过轮询OID来取数，靠Trap接收故障上报。网管平台不太关心什么ASDU、IOA、传输原因，它只想知道“这个点的当前值是多少”“这个点状态变了没有”。
问题就出在中间。同一个机房或站房里的设备，数据要同时发给两套完全不同的系统，甚至同一个系统里既有104的设备，又有SNMP的平台。传统做法是买两种网关各自对接，或者让设备厂家开放第二种通信协议。但老设备往往只有一个通信口、只支持104，改造起来费时费力。更麻烦的是，很多老旧RTU的通信规约是固化在固件里的，既不能升级协议，也不方便开放网口做多路并发。
用一台协议转换网关做“104主站 + SNMP Agent”，把协议转换在中间层完成，是目前最务实的方案。转换网关既不打扰原有设备的数据流向，也不需要改动站内现有SCADA配置，只是作为一台额外的客户端接入设备，同时以SNMP服务端的形式把数据交给网管平台。这种“旁路式接入”在电力技改项目里特别好用，风险小、实施快、回退也容易。
1.2 核心需求拆解
我对接的这个项目需求比较典型，可以归纳成四个点：
- 数据采集：网关作为IEC104主站，主动连接站端RTU（从站），完成建链、启动、总召、周期数据接收和突发数据处理。
- 协议转换：把104侧的遥测、遥信、遥控状态、累计量等数据映射成SNMP的对象标识符OID和对应的数据类型。
- 被动查询：让网管平台能用SNMP GET/GETNEXT/GETBULK读到实时值，读到的是干净、可靠、带品质语义的数据。
- 主动上报：遥信变位、遥测越限这类事件，网关要主动发SNMP Trap给网管平台，不能只靠轮询。
除了这几个直接需求，还有一些隐性需求很容易被忽略，但在项目实施后慢慢变成关键点：
- 数据品质要一起转发，不能让无效数据混进网管平台形成误告警；
- 网关要支持断线重连情况下恢复数据的一致性，链路恢复后要自动重新总召；
- 老设备的数据点表差异很大，映射规则要能灵活配置，不能把IOA写死在代码里；
- 点位数量可能上千，网关的性能要能支撑全量轮询和突发上报同时进行。
2. IEC104协议核心机制与应用要点
2.1 得先把104的交互逻辑搞明白
做转换网关，首先要以104主站的身份去和从站打交道。IEC 60870-5-104跑在TCP之上，默认端口是2404，通信过程分三个阶段：建链、启动传输、正常数据交互。很多刚从设备端转过来的人会有一个误解，觉得连上TCP就能收数据，其实不是，104有自己的一套握手流程。
连接建立之后，第一件事是发U帧里的STARTDT激活命令，请求启动数据传输。注意，这时候还不能直接发总召，从站只会在收到STARTDT激活并回复确认后，才把链路置为“活跃”状态。漏掉这一步，后续发任何业务报文都会被从站无视，或者引发连接被重置。收到STARTDT确认后，链路才算真正通起来，主站才能发总召、接收数据。
数据帧按控制域分成三类：
- I帧（信息帧）：带发送序号和接收序号，用来承载ASDU业务数据；
- S帧（确认帧）：只带接收序号，用来确认收到对方的I帧，不带业务数据；
- U帧（控制帧）：不带序号，完成STARTDT、STOPDT、TESTFR等链路控制功能。
I帧里装的就是APDU，由6字节APCI头加ASDU组成。ASDU的结构固定为：类型标识、可变结构限定词VSQ、传输原因COT、公共地址、信息体。每个信息体里又包含信息对象地址IOA（3字节）和实际数据值。
我记得第一次独立写104解析代码时，花了很长时间调试序号匹配。因为TCP是可靠传输，104又在TCP之上做了一套类似“窗口确认”的机制，I帧的发送序号和接收序号必须严格递增，收到S帧确认后才能继续发下一批。实际上做转换网关不用深入到这个层面，直接用成熟的104主站协议库就行，但前提是你得理解这套交互模型，否则连库的日志都看不懂。
2.2 总召条件与总召时序：最容易出问题的地方
“iec104 总召条件”是最近很多人搜的点，我把它单独拿出来讲。总召的学名是“总召唤”，英文是Station Interrogation，用C_IC_NA_1（类型标识100）报文发起。它的作用是让从站立刻把当前全部有效数据完整地上送一遍，相当于给主站做一次全量快照。
什么条件下需要总召？从我的项目经验看，至少有以下几种：
- 转换网关与从站建立TCP连接并完成STARTDT之后，必须发总召；
- 链路断开后重新建立连接，必须重新总召；
- 从站设备自身重启、复位之后，主站通常也应再次总召；
- 如果需要定期校正数据基线，或者网管平台要求每天对齐一次数据，可以周期性发起总召。
总召的完整流程是：主站发C_IC_NA_1，传输原因置6（激活）；从站先回一个传输原因为7（激活确认）的响应；随后从站开始上送数据，这些数据报文里的传输原因是20（响应站召唤）；直到从站发完所有点位，会发一个传输原因为10（激活终止）的报文，表示这轮总召彻底结束。
这里有个新手极易踩的坑：很多人收到激活确认后就开始处理数据，或者收到一部分数据就认为“总召完成”，开始对外提供数据。实际上必须等到传输原因10的报文到达，才能确认整轮总召结束。我在现场遇到过好几次，因为没等COT=10，就把半截数据当完整数据集转出去了，导致SNMP侧看到的遥测缺了一半。原因很简单，一个站上千个点位，从站上送是需要时间的，转换网关如果在中途就开放读取，网管平台拿到的就是残缺状态。
还有一个细节：总召期间发上来的数据，和正常运行时变化上报的数据，虽然在ASDU结构上一样，但接收方的处理逻辑应该不同。总召数据是“整表刷新”语义，正常周期数据是“周期更新”语义，突发变化数据是“增量更新”语义。我的做法是为每个从站维护一个“总召未完成”标志，在这个标志置位期间，缓存中的数据只写入、不对外输出，等COT=10到达后一次性开放读取，这样能保证网管平台永远拿不到中间态的数据。
2.3 遥测、遥信与遥控的报文特征
转换网关每天处理最多的就是遥测和遥信，这两类数据的ASDU类型标识要记熟：
- 遥信（单点信息）：M_SP_NA_1，类型标识为1；带品质描述和时标的还有类型30（M_SP_TB_1，带CP56Time2a时标）。值只有0/1，对应开关分合、保护动作信号。
- 遥测（测量值）：类型9（M_ME_NA_1，标度化值，带品质描述的短整型）；类型13（M_ME_NC_1，短浮点，IEEE754单精度浮点）。现场电压、电流、有功功率、频率这类模拟量，绝大多数走类型13，老设备也有走9的。
- 遥控（命令）：C_SC_NA_1（类型45，单点命令）、C_DC_NA_1（类型46，双点命令）。如果转换网关要支持反向控制，需要把SNMP Set操作翻译成遥控命令，还得处理命令确认帧。
- 累计量（遥脉）：M_IT_NA_1，类型标识15，用于电度、流量等累计值。
再说传输原因。正常情况下，周期数据的传输原因是1，突发变化数据的传输原因是3。品质描述符QUALI也要解析，高位表示数据是否有效，还包含越限、溢出等标志位。为什么要强调品质位？因为电力设备在检修、故障、通信中断时，会照样把“当前值”发上来，但品质位会标记为无效或异常。如果转换网关不看品质位，把这些垃圾值转给SNMP，网管平台就会产生大量误告警。
项目里我们遇到过一个典型案例：某路遥测在设备检修时上送了一个几千伏的电压值，品质位明确规定无效，但因为转换网关最初版本没处理品质位，这个值直接进了网管平台，导致告警系统半夜响个不停。后来在映射引擎里加了一条规则：品质位异常的数据，SNMP侧对应的OID值返回一个约定好的无效标志（比如整数-1或浮点NaN，具体看平台约定），并把品质状态单独映射成另一个OID便于平台排查。这个问题才彻底解决。
3. SNMP侧协议设计与OID规划
3.1 SNMP基础与版本选择
SNMP这边，我们面对的网管平台通常会问：“你支不支持v2c？Trap挂哪个端口？”我的建议是先用v2c把业务跑通，因为大部分第三方网管对v2c的支持最成熟，MIB浏览器、告警配置、测试工具一抓一大把，调起来最简单。如果项目对安全合规有硬性要求，再上v3，用USM用户配合authPriv模式，MD5或SHA做认证，DES或AES加密，但要做好平台侧配置联调的心理准备。
SNMP有两条数据通路。一条是轮询方向：网管平台作为管理器，周期性向Agent（也就是转换网关）发GET/GETNEXT/GETBULK请求，Agent返回OID对应的当前值。另一条是上报方向：Agent检测到事件后，主动向管理器的162端口发Trap报文。转换网关必须把这两条通路都实现完整，不能说只做被动查询不做主动上报，否则遥信变位就全丢了。
版本选择有个经验：如果用v2c，Trap社区串和轮询社区串最好分开设置，不要都用public裸奔。很多网管平台默认配置都是public，但现场环境复杂，万一保护装置、管理网里还有其他设备，公共社区串容易造成误收Trap。设成两套不同的社区串，至少能避免隔壁系统的Trap串进来。
3.2 MIB与OID怎么规划
OID规划是转换项目里最考验细节的环节之一。规划得好，网管侧写导入模板、配告警规则时省心；规划得乱，后期每加一个测点都要改MIB、调平台，维护成本翻倍。
我习惯用“设备+分组+测点”三层结构来组织自定义OID，挂在企业私有节点1.3.6.1.4.1下面。举个例子，假设厂商节点是1.3.6.1.4.1.xxxxx，往下这么分配：
- 一级：设备类型节点，比如 .1 表示RTU、.2 表示DCS、.3 表示电度表采集器；
- 二级：组类型节点，比如 .1 表示遥测组、.2 表示遥信组、.3 表示遥控状态组、.4 表示品质位组；
- 三级：具体测点序号，从1开始紧凑排列。
最终一个逆变器A相电压的OID可能就是1.3.6.1.4.1.xxxxx.1.1.37。这种固定叶子节点的做法，比表格式ROW结构更高效。电力测点虽然是大量数据，但相对静态，不会像IP路由表那样频繁增删，固定OID方便网管平台直接扫描导入，也方便工程师拿着点位表人工比对。
数据类型也要匹配好。104侧类型13的短浮点，在SNMP侧常见的映射方式是OCTET STRING（携带四字节IEEE754原始值）或INTEGER（把工程值乘以比例因子后取整展示）。为了兼容不同网管平台，我通常把两种都映射出来：一个OID放原始浮点值的整型形式，另一个OID放字符串形式，平台按自己的规则选。SNMP侧没有真正的浮点类型，这是个天然限制，所以提前和网管平台约定解析方式非常关键，否则两边各猜各的，最容易产生“数据对不上”的矛盾。
3.3 Trap上报设计
Trap设计的目标很简单：把变化和故障可靠地送到网管平台，同时不制造风暴。
遥信变位是最高优先级的Trap事件。开关从合到分、保护动作、装置告警，这些都要立即上报。但变位频繁的设备很容易触发Trap风暴，现场我见过一个抖动的遥信点一分钟发几百条Trap，直接把网管平台的告警库打爆。处理办法是在Agent里加去抖滤波：连续两次状态变化之间至少要满足设定时间间隔（比如300ms），或者短时间内同一OID只报一次，等状态稳定超过设定时间后再补一条最终状态。
遥测越限告警也建议用死区加定时的方式。死区就是变化超过一定阈值才产生事件，避免信号在告警阈值附近反复横跳。我习惯把遥测Trap做成两种：越限告警Trap和恢复Trap，网管侧只要收到两种状态就能做闭环，而不是每次变化都报。
Trap用的是UDP 162端口，UDP丢包是常态。不能只发一条就指望它必达。我们最后加了简单重传机制：同一事件重发两次，间隔500ms，实测网管接收可靠率明显提升。但重发也要有上限，否则事件量大时照样产生重复告警，我的经验是重发不超过2次，且只在trap这类高优先级事件上启用。
4. 协议转换网关的实现方案
4.1 转换网关整体架构
实现方式我见过三种：纯软件部署在服务器上、用嵌入式工控机整机交付、买专用协议转换盒子。这次用的是工业级嵌入式Linux网关，一个主进程，内部拆成三个模块：
- 104采集模块：作为TCP客户端，负责连接多个从站、维护会话状态、解析ASDU、响应总召、处理链路断线重连和超时重传。
- 映射引擎：负责把104侧的数据点表映射到内部数据缓存，再对应到SNMP OID。点表通过配置文件或Web界面导入，运行时可动态加载。
- SNMP服务模块：实现SNMP Agent和Trap发送器。轮询请求从缓存取值，事件触发时组装Trap报文发出。
模块之间用内存缓存做数据交换，不查数据库。缓存里维护每个测点的最新值、品质位、更新时间戳、变位次数。SNMP GET请求直接从缓存读，毫秒级响应，完全能扛住网管平台全量轮询。
映射引擎是核心，要支持几种映射类型：IOA到OID的直接映射、类型转换（短整型到浮点、带比例因子换算）、点位过滤（某些调试点不对外暴露）、数据无效标记（品质位异常时在SNMP侧置无效）。映射引擎还负责Trap事件检测，判断哪些变化需要上报、哪些要丢弃。
4.2 数据映射与配置设计
数据映射是整个项目里最脏最累的活，因为每个设备厂家的点表风格都不一样。有的给参数号，有的给信息体地址，有的把遥信放在0~999、遥测放在1000~1999，还有的干脆给一个两三百行的Excel表让你自己去抠IOA。我们必须先把点位表的真实IOA搞清楚，再导入映射配置。
配置文件我用CSV加分组标志，字段大致为：源设备号、104侧的IOA、类型标识、转换后的OID节点索引、数据格式、缩放因子、工程单位、是否参与Trap、死区阈值。用CSV的好处是可以在Excel里批量处理，几百个点一次性整理完，比在Web界面上一个个点快得多。文件内容大致是这种风格：
设备号,IOA,类型标识,OID索引,数据格式,缩放因子,单位,是否Trap,死区 1,1001,13,1,float,1,V,1,0.5 1,1002,13,2,float,1,A,1,0.5 1,2001,1,37,bool,1,,1, 2,1010,9,101,short,0.01,kV,1,1.0关于IOA的连续性，有个小细节值得讲。104侧的IOA是3字节，最大能到上万个，有些厂家的点号排列会留下大量空洞，直接拿IOA当OID尾号会产生一堆空节点，网管平台扫描时效率很低。我的做法是在网关内部把点表重编号，用紧凑序号做OID尾号，同时保留IOA作为MIB里的Index值。这样SNMP侧是连续干净的，追溯现场点位时又有IOA可查。
4.3 关键参数与初始调试配置
给出一份我们项目里实际用过的关键参数供参考：
| 配置项 | 参数值 | 说明 |
|---|---|---|
| 104端口 | 2404 | 标准IEC104默认端口 |
| 连接超时 | 5s | TCP建链超时 |
| 重连间隔 | 10s | 断开后自动重连 |
| T0超时 | 30s | 总时间裕度，用于整个会话的确认超时 |
| T1超时 | 15s | 确认超时，等S帧或I帧确认 |
| T3超时 | 20s | 链路空闲时发TESTFR测试帧 |
| STARTDT后等待 | 1s | 给从站处理缓冲时间 |
| 总召周期 | 24h | 定期全量校正一次 |
| SNMP轮询超时 | 5s | Agent响应超时设置 |
| Trap发送队列 | 500条 | 超出的旧事件丢弃 |
| Trap去抖时间 | 300ms | 短时间重复事件合并 |
| Trap重发次数 | 2次 | 间隔500ms |
这些参数没有行业统一标准，不同厂家设备对104的适应度也不一样，但总体思路是：该等报文就等报文，该超时就超时，宁可多等一小段时间确认，也不要把未同步数据放出去。比如T1设太短，可能设备处理稍慢就触发超时重传，造成序号混乱；T1设太长，链路异常又发现得慢。现场可以根据设备厂家的建议微调。
5. 现场实施与调试实录
5.1 联调流程：从点到面逐步推进
联调不要一上来就几百个点全挂上，一定要分三步走。
第一步，单点验证。先用IEC104测试客户端工具单独连接一台从站设备，抓一个遥测点，确认设备送数正常、总召流程完整、数据值没问题，再切到转换网关。这一步先把设备侧的“锅”排除掉，免得后面出问题分不清是谁的毛病。测试工具可以用开源的IEC104主站模拟器，也可以直接用抓包工具看报文。
第二步，小范围映射验证。只导入10个左右的关键点位，包含一个遥信、一个浮点遥测、一个标度化遥测、一个累计量，再手动核对一遍映射表。用snmpwalk从根节点扫描，用snmpget拉单点值，核对数值和单位。这里最难核的是类型9标度化值，它需要根据点位表里的缩放比例换算成实际工程量；类型13浮点则直接是物理值，两者经常被人搞混。有一次我们排查半天，发现某遥测大了一百倍，原因就是把一个缩放系数为0.01的标度化值当整数直接发了。
第三步，全量接入。把完整点表导入，持续运行24小时以上，对比104源端、转换网关缓存、网管平台三侧的数据一致性，确认无漏点、无溢出、无乱码Trap后才算验收。全量接入阶段要重点关注网关的CPU和内存占用，几十个设备、上千个点位同时刷新时，有没有出现响应延迟，这些都要记录在案。
5.2 常见问题速查与排查技巧
把这次项目里实际踩过的问题按“现象—原因—处理”整理成速查表：
| 现象 | 原因 | 处理方式 |
|---|---|---|
| 网关一直收不到数据，从站侧无任何上送 | STARTDT激活没完成，从站不响应业务数据 | 抓包看U帧交互，确认STARTDT确认后才发总召 |
| 总召发出后一直收不到激活终止COT=10 | 从站应答太慢或中途断链 | 调大T0，打印已收IOA统计，判断卡在哪个测点 |
| SNMP读回来部分遥测为负数或乱码 | 浮点字节序不对，104侧是大端，实现里用了小端 | 统一字节序解析，用已知数值验证 |
| 遥信状态一直不变，但104报文里有变化 | IOA映射错位，点表地址对不上 | 打开点位调试日志，对比IOA和OID逐条核 |
| Trap风暴 | 抖动点或死区没配 | 开启去抖滤波和死区，短时间重复事件合并 |
| 网管平台轮询超时 | SNMP响应线程阻塞或锁竞争 | 缓存读取改成原子读或无锁快照，检查UDP端口占用 |
排查问题最有效的工具组合是tcpdump加Wireshark。104侧抓TCP 2404端口，SNMP侧抓UDP 161和162端口，两边同时抓，时间轴对齐，问题到底是协议交互错误还是映射错误一眼就能看出来。我还习惯在网关里加一行日志，每处理一个ASDU就记录“收到IOA=1001, 值=220.5, 品质=0x00”，这样对上位机提供的数据，立刻知道字段是从哪一步开始错的。
5.3 实操经验与避坑心得
做完整项目才发现几个平时文档里不会写到的细节。一是现场一定要准备完整的抓包工具链，104侧和SNMP侧同时抓包，能快速定位问题出在协议侧还是映射侧。二是点位表不要靠口头沟通，一定要求设备方提供带IOA的标准Excel点位表，而且要标注清楚数据类型和缩放因子，没有这个文件，后面全是扯皮。三是转换网关上线时，加一个“只读模式”开关，先只上送遥测遥信，把遥控和SNMP写操作屏蔽掉，等数据稳定一两天再开启控制通道。在电力现场这是基本的安全习惯，防止联调期间误操作遥控开关。
还有一个经验是关于“小步快跑”的。协议转换网关的进程一定要设计成可热加载配置，点表修改后不需要重启进程就能生效。第一次实施时没有这个功能，每次改错一个点都要重启服务，导致SNMP侧连接中断，网管平台反复告警，被运维同事念叨了好久。后来加了配置文件监听和动态刷新，新增测点几秒钟就能生效，整个调试节奏快了很多。
6. 扩展方向：IEC104与SNMP转换的后续演进
项目验收之后，有几个扩展方向很值得考虑。一是把转换网关做成双链路热备，104的TCP连接和SNMP的UDP监听都支持主备切换，保证单一进程故障时数据不中断。二是把点位表管理做成数据库动态下发，通过一个简单的后台页面维护映射关系，省去每次改点都要下载CSV再导入的麻烦。三是增加运行监控看板，实时展示转换延迟、丢包率、点位同步率、Trap发送成功数，这对长期运维帮助很大。
如果站点规模再大，还可以考虑把“一网关一站点”的部署模式改成“一网关多站点汇聚”，用一个中心节点同时采集多个站的数据，再按站点拆分成不同的OID子树。这种模式适合区域级集控中心的使用场景，但要注意104从站数量增多后的线程模型和缓存性能。总之，这套“IEC104数据上送+SNMP统一出口”的思路，在电力数据接入、动环监控整合、企业能效管理几个方向都是通用的，值得做一次透彻的验证和沉淀。
我个人在实际操作中最深的一点体会是：协议转换项目，难点从来不在协议本身的解析，而在数据语义的传递。104的APDU结构、SNMP的OID映射，这些是死的，查文档就能解决；但品质位怎么处理、总召什么时候算完成、Trap怎么防风暴，这些是活的，必须在现场反复调试才能形成手感。如果非要给后来者一个最实用的建议，那就是在项目启动第一天就把点位表要全、把总召时序画明白，这两件事做扎实，后面80%的问题都能提前规避。
