干电力自动化调试这一行的对IEC104应该都不陌生。日常打交道最多的就是遥测、遥信、遥控、遥调这“四遥”但真正到了现场尤其是做测控装置维护、保信子站接入、固件批量升级的时候你会发现四遥根本不够用——你得能跟对端把“文件”倒腾起来。比如录波文件上送、定值单下发、软件升级包传输这些在IEC104体系里都有对应的标准做法。这篇文章就围绕IEC104的文件传输与软件升级展开把协议层面的ASDU机制、传输可靠性设计以及一次完整升级操作要怎么走流程一步步拆开讲清楚。适合刚接触104规约二次调试的工程师也适合准备做远程维护工具、想搞清楚“文件到底是怎么传过去的”的朋友参考。1. 文件传输在IEC104体系里的定位与整体设计思路1.1 四遥之外的第五种能力IEC 60870-5-104习惯上直接叫IEC104是把IEC 60870-5-101的远动应用层搬到TCP/IP之上的一种规约。它的核心任务是解决调度主站和变电站之间的实时数据交换也就是我们常说的“四遥”遥测、遥信、遥控、遥调。但在实际工程里大量运维工作并不只是读几个遥测量、发几个遥控命令那么简单而是需要把文件从一端搬到另一端。举几个最常见的场景故障录波文件、SOE事件记录、保护动作报告从子站上送到主站定值单、配置文件从主站下发到子站装置固件升级包从主站侧下发到测控装置、远动终端装置参数备份、日志文件定期回收。这些需求在IEC104标准体系里都有对应的设计文件传输并不是额外扩展的私有功能而是应用层ASDU的一部分。也就是说你不需要在安全分区里额外开通什么端口或服务直接在已有的104链路上跑文件数据即可。这对电力监控系统的网络安全管理来说非常友好因为安全策略可以保持统一只放行2404端口即可完成绝大部分业务。不过要注意IEC104标准正文里对文件传输的描述相对精炼很多细节是由配套标准IEC 60870-5-102以及各厂商的具体实现来补充的。这就导致了现场调试时经常出现“两边都说支持文件传输但联调起来发现报文对不上”的情况。所以理解文件传输的机制和各段报文的交互逻辑比死记几个ASDU类型码重要得多。1.2 为什么场站升级很少直接用SCP或共享文件夹有朋友可能会问现在做局域网文件传输太方便了SCP命令、网页版文件传输工具、共享文件夹随便一个都比104文件传输简单直观为什么电力设备升级还要用104规约这个问题在现场其实有很现实的原因。先看一组对比传输方式依赖服务/端口校验机制断点续传审计追溯适用场景SCP/SSH22端口需SSH服务端SSH传输层校验通常不支持依赖系统日志通用IT运维非电力专用网页版文件传输HTTP/HTTPS需Web服务HTTP无内置校验靠前端实现依赖Web日志局域网内临时传文件共享文件夹/SMB445等端口需SMB服务协议层有限校验支持依赖文件系统日志办公网环境IEC104文件传输2404端口复用远动通道文件级校验和/CRC支持多数实现ASDU报文可完整回放审计电力调度网内主站与子站之间电力调度网的安全分区策略和通用办公网完全不是一个量级。站控层、间隔层设备往往部署在生产控制大区安全II区甚至安全I区对外部主动发起的连接有严格限制。如果你在测控装置上开一个SSH服务或者SMB共享安全评估这一关就过不去而且这类通用服务面向的是人机交互不是程序化的自动传输很难嵌入到调度主站的自动化流程里。更重要的是IEC104文件传输是嵌入在已有链路上的“业务数据”它不是独立于远动系统之外的旁路通道。调度主站可以像处理遥测遥信一样对每一次文件传输做统一的事后审计和报文回放这对电力系统的运行管理来说非常关键。所以哪怕SCP再方便在电力二次系统里标准答案仍然是“通过104文件传输能力完成”。2. 文件传输的核心机制与ASDU拆解2.1 文件传输涉及的ASDU与分工先理清一个概念ASDU是应用服务数据单元是IEC104应用层的“消息信封”。文件传输相关的ASDU常见的主要有这么几类文件目录请求/应答用来获取子站存储了哪些文件、文件大小、修改时间、属性等信息。F_SR_NA_1文件节选请求主动请求对端发送文件中的某一“节”或者请求对端接收某一节。F_SC_NA_1文件节选确认对文件节选请求的应答表示允许或拒绝该节的传输。F_SG_NA_1文件段实际承载文件数据的ASDU里面装的是文件内容的字节块。F_TF_NA_1文件传输用于整体描述文件传输过程的ASDU包括文件标识、方向等属性。F_AF_NA_1文件肯定确认对接收到的文件段、节或整个文件的确认回复。这些助记符看起来有点绕但拆开就好懂了F代表FileSR是Select and RequestSC是Select and ConfirmSG是SegmentTF是TransferAF是Acknowledge File。不同厂商在具体命名上可能稍有差异但核心分工是一致的请求、确认、传数据、回执。这里要特别提醒一点不要一上来就死记ASDU类型码的十进制编号。因为IEC104标准在不同版本和配套规范里编号存在微调可能而且现场设备厂商的报文实现也不尽相同。正确的打开方式是先看“信息体结构”搞清楚报文里哪些字节描述的是“哪个文件、哪一节、哪一段”哪些字节是真正的数据负载。只要结构对得上类型码编号就是个查表的事。2.2 文件-节-段三级结构与传输流程文件传输在设计上采用了一个很有意思的“文件-节-段”三级结构这和操作系统里“文件-块-扇区”的思想有异曲同工之处。为什么不能直接用一帧报文把整个文件发过去因为IEC104一个APDU的长度是受限的。常用的64K扩展格式虽然理论上允许更大的APDU但现场很多设备依然按255字节甚至更小的长度来组帧。一个几百KB的升级包或者一个几十MB的录波文件必须切块才能塞进APDU里。直接切成一堆裸数据块也有问题如果传输中断怎么定位到具体是哪个块丢了如果是多文件并发传输怎么区分数据块属于哪个文件所以就有了三级结构文件File一个完整的文件有文件名、长度、属性等信息节Section文件内部的逻辑分区比如一个文件可以按偏移量划分为第0节、第1节……每节又有独立的长度段Segment节内部的最小传输单元一段数据对应一帧或连续几帧ASDU。一次典型的文件读取流程大概是这样的主站向子站发送文件目录召唤请求子站返回文件信息列表主站选择需要读取的文件发起文件读请求带上文件名或文件标识子站返回节选确认告知文件总长度、校验方式等属性主站请求文件中的第0节子站以文件段ASDU逐段返回第0节的数据主站收到每一段后回复肯定确认第0节传输完毕主站请求第1节继续循环直到所有节传输完毕主站发起关闭/结束文件传输子站确认整个会话结束。这个流程看上去很繁琐但每一步都有它的意义。节和段的分级让传输具备“断点续传”的潜力如果传输在第3节第7段断掉了重新建立会话后可以只从第3节第7段继续而不需要重新传整个文件。对于录波文件这种动不动几十MB的大文件这个能力简直是救命稻草。2.3 传输可靠性序号、超时与校验文件传输是建立在104链路之上的而104链路本身的可靠性设计已经相当完善APDU的I帧序号机制保证报文不会乱序、不会丢包S帧确认机制让发送方知道对端已经收到哪些报文链路超时参数T0、T1、T2控制着重连、发送确认和接收确认的节奏。但光有链路层保障还不够文件传输还需要在应用层做自己的可靠性设计。我在实际调试中总结的几个关键点是段序号管理文件段ASDU自带段序号接收方可以识别出有没有跳段总长度核对文件属性里会带文件总长度接收完所有段之后需要把实际收到的字节数与声明长度比对校验字段不少厂家的实现中文件属性或传输结束报文里会携带CRC16/CRC32或者简单累加和用来判断整个文件接收是否正确偏移量续传支持断点续传的实现会记录已经确认收到的最大段号或偏移量重新打开文件后从该位置继续。这里我需要强调一个容易踩坑的点IEC104的文件传输确认机制和TCP的滑动窗口有类似之处但两者是不同层面的东西。TCP保证的是“字节流到达”104的应用层确认保证的是“业务数据被正确处理”。如果你看到的是帧层面已经S帧确认了但应用层迟迟没有文件段确认那问题多半出在子站的处理逻辑上而不是物理链路。3. 基于IEC104的软件升级实操流程3.1 升级准备升级包、版本规划与主站参数理论讲完进入正题。用IEC104做软件升级本质上就是“传文件执行升级动作”两件事的组合。但正因为涉及到“动固件”准备工作比普通文件传输要细致得多。先说升级包。厂方给的升级包一般是一个二进制镜像文件比如app_v1.2.3_20250101.bin。在实际项目里我强烈建议在文件名里带上版本号、发布日期和适用装置型号因为站内往往有多个型号的装置升级包混用是现场常见事故之一。升级包做出来之后第一时间计算一组校验值MD5、SHA256、CRC32都行写在发布说明里。如果你的主站工具支持在传输结束后自动比对校验值直接配置进去如果不支持那就得人工比对这一步千万别省。然后看存储分区。以常见的双区备份方案为例装置Flash大致规划如下分区用途说明Bootloader引导程序出厂固化升级时绝对不覆盖应用区A当前运行固件正常工作时的运行区应用区B备用固件升级写入的目标区参数区定值、配置、日志升级时需要保持不丢升级包大小一定要提前确认别到了现场才发现B区空间不够。我在现场遇到过几次“传了半天最后写入失败”的情况一查原因就是目标分区剩余空间比升级包小几十KB这种低级错误提前自查能完全避免。主站侧参数也要在开始前配置好。重点看几项传输超时时间一般设置在5到15秒之间。如果站内网络经过多级交换机、综合自动化系统转发时延会明显增大超时时间要适当调大否则连续重传反而拖慢速度单帧数据长度/段大小常见为240字节或1024字节。段越小报文交互次数越多时延敏感型网络反而更稳段越大效率高但对链路质量要求高重试次数默认3次比较稳妥升级窗口尽量选择检修期、夜间等低负荷时段避免在实时遥控操作过程中升级防止链路被大量实时数据挤占。3.2 主站下发升级包的完整交互过程下面用一个实际下发的例子展示主站和子站之间的典型交互过程以描述为主具体报文结构以设备厂家为准。主站 - 子站召唤文件目录查看当前装置里有什么文件 子站 - 主站文件目录应答列出现有固件文件名、大小、版本 主站 - 子站请求打开文件 app_v1.2.3_20250101.bin属性写入 子站 - 主站节选确认同意写入返回可写入的最大节长度 主站 - 子站F_SR_NA_1 请求写入第0节 子站 - 主站F_SC_NA_1 允许写入第0节 主站 - 子站F_SG_NA_1 文件段数据块0长度240字节 子站 - 主站F_AF_NA_1 肯定确认第0段接收正确 ... 重复“传段-确认”循环直到第0节写完 ... 主站 - 子站F_SR_NA_1 请求写入第1节 子站 - 主站F_SC_NA_1 允许写入第1节 ... 继续循环 ... 主站 - 子站所有节传输完成发送“关闭文件”请求并附带整个文件的校验值 子站 - 主站确认文件写入完成本地校验通过 主站 - 子站下发“升级/重启”指令也可以由子站自动触发 子站 - 主站确认收到升级指令置升级标志开始重启看这个流程应该能明白主站和子站之间是“一问一答”式的交互每个数据段都需要确认只有前面确认了才会发下一段。这种设计虽然看上去“慢”但在电力这种对可靠性要求极高的场景下慢就是稳稳就是快。真正传一个2MB的升级包如果按240字节一段大约需要8500多次交互在正常局域网条件下也就几十秒到两三分钟完全可接受。写入阶段还有一个关键原则升级包不能直接写到当前运行区。正确做法是先写到备用区等全部数据传完、校验通过之后再置升级标志重启引导时由Bootloader把运行区指向新版本。这样即使升级包写了一半就断掉也不影响当前运行版本装置还能继续正常工作。这个设计我在后面双区备份部分再展开。3.3 双区备份与失败回滚双区备份是现场抗风险能力最强的方案也是我强烈推荐在项目中坚持使用的方案。它的核心逻辑可以这样理解装置里同时存在两个应用区A区是当前正在跑的程序B区是留给升级的新程序。升级包写B区写完校验通过后把“启动标志”改为“从B区启动”然后重启。Bootloader在启动时读取这个标志再决定加载哪个区的固件。这个方案的优势非常明显升级失败不影响运行如果B区写入失败或者校验不过Bootloader不会切换A区继续跑装置保持正常工作支持自动回滚如果新版本启动后连续几次崩溃、重启Bootloader可以自动切回A区相当于有了一层“保险丝”可维护性好下次升级时B区变成旧版本A区变成新版本两区角色互换但机制完全不变。我在实际项目里见过不少只做了单区覆盖的装置升级时一旦中途断电基本就“变砖”了只能返厂重新烧录非常被动。所以如果你正在做104软件升级功能我建议无论如何都要把双区备份做成标配哪怕产品规格里没有写也要组织内部评审讨论清楚风险。回滚逻辑要注意一个细节升级成功后最好让子站主动向主站上报一次当前版本号。主站在收到版本号并确认是新版本后才认为升级流程完成。如果子站重启后迟迟不上报或者上报的还是旧版本号就说明切换没有生效得赶紧看Bootloader的启动标志和引导日志。4. 传输与升级的验收要点和工具方法4.1 常见问题速查与排查思路调试104文件传输和软件升级最怕的就是问题定位不准折腾半天不知道是链路问题、数据包问题、Flash问题还是应用逻辑问题。我把现场高频踩坑的问题整理成了一张速查表现象可能原因排查方向传输经常超时、反复重传网络时延大、报文被防火墙丢弃、单帧数据长度设置过大抓包看TCP往返时延适当调小段大小检查防火墙策略卡在某一节/某一段不前进子站接收缓冲区不足、对端确认帧丢失、段大小不匹配查看子站日志确认该段是否已写入Flash检查S帧和ASDU确认是否对齐文件传完但校验失败升级包本身损坏、主站与子站对字节序/长度字段理解不一致、Flash写入异常先本地校验升级包再用固定内容做小文件传输测试逐字节比对重启后版本没切换升级标志未正确写入、Flash写保护、Bootloader不支持双区切换查子站重启日志确认引导程序读取的分区标志核对Flash写操作流程传输中断后无法续传子站不支持断点续传或最大段号限制导致超范围地址确认设备规格书是否声明支持续传不支持只能整包重传目录召唤返回空子站文件索引未初始化、目录区损坏检查子站Flash文件系统状态尝试重建索引排查时有个通用原则先把“链路”和“文件应用”分开。链路问题用抓包一眼就能看出来双方TCP重传率高、S帧确认不及时基本就是网络侧问题。如果有大量“I帧发了但对方不回S帧”的现象要怀疑对端处理能力不足或者报文格式不兼容。文件应用的问题则依赖子站日志和ASDU层的确认信息重点看是“没收到”还是“收到了但比对不过”。4.2 抓包与日志分析技巧抓包是确认104文件传输细节最直接的手段。Wireshark就能搞定过滤条件用tcp.port 2404能把这台主站和子站之间的104报文全部过滤出来。拿到报文后有几个信息值得优先看I帧的发送序号N(S)和接收序号N(R)是否连续。如果有跳号说明链路层有报文丢失或重排S帧确认是否及时。如果对端长时间不确认要查应用层是否卡在某个文件段处理上ASDU类型码是否在预期范围内。如果出现了设备私有类型码得去翻厂商协议文档不要当成标准类型硬解文件段ASDU里的段号和文件标识是否按顺序递增。最怕看到“文件已经写入成功了但段号乱序”的情况那大概率是子站并发处理出了问题。子站日志方面升级相关的关键字通常包括file、upgrade、flash、boot、crc err、image等。建议在升级前把日志级别调到调试级别一次升级完再调回来否则现场日志信息量会太大反而干扰判断。我自己惯用的做法是升级前先做一轮纯文件读取测试把装置里一个已知大小的文件完整读上来校验MD5一致后再做升级写入。这样可以确认文件传输通道本身是健康的真正升级时如果失败问题基本就锁定在“写入切换”环节排查范围能缩小一大半。4.3 验收清单参考最后给一份可用于现场验收的检查清单每完成一项打一个勾直接拿去用主站能正常读取子站文件目录文件列表与实际情况一致小文件100KB上传和下载均成功内容校验一致大文件2MB传输稳定无中途断开或超时重传过多传输过程中手动断开链路重新连接后能从断点续传升级包写入备用区成功后当前运行区固件运行不受影响下发升级指令、重启后新版本号正确上报模拟传输中途断电装置重启后仍能正常启动旧版本固件升级完成后检查参数区确认定值、配置未丢失记录完整升级耗时确认在可接受的检修窗口内。这块清单看起来简单但每一条都把常见的坑覆盖进去了。尤其是“传输中断后恢复”和“中途断电”这两条很多项目在实验室测得好好的一到现场就出问题原因就是没有把异常情况纳入验收。我个人在实际操作中的体会是IEC104文件传输和软件升级真正的难点从来不在协议本身而在工程细节升级包管理是否规范、Flash分区规划是否合理、异常断电保护是否到位、版本切换后的自检是否完善。协议只是把数据送过去能不能安全地完成升级拼的还是基本功。调试这类功能时建议先从文件读取和校验做起把目录召唤、内容比对这些流程彻底跑通再动升级标志。否则一旦直接把Flash写崩现场只能返厂处理那种被动局面是所有人都不想面对的。