做电力自动化调试、变电站监控或者新能源接入项目的朋友对 IEC 104 这名字应该都不陌生。IEC 60870-5-104简称 IEC 104是基于 TCP/IP 的电力远动通信规约主站侧 SCADA 系统和从站侧 RTU、测控装置做数据交互基本都绕不开它。只要涉及规约对接、联调、验收手边没个趁手的从站/服务端模拟器那真是寸步难行。先澄清一个概念。提到“仿真器”这三个字嵌入式圈第一反应是 ST-Link、J-Link 这类硬件调试器但在电力规约调试这个圈子里我们说的从站模拟器/仿真器是一个跑在电脑上的软件服务端用来“装成”一台 RTU 或测控装置等着主站来连接。下文聊的全是后者别搞混。这篇文章我把自己这些年用过的、踩过坑的 IEC104 从站模拟器和配套调试工具从头捋一遍从开源库到可视化模拟器从抓包工具到联调实战技巧一次性讲清楚。适合刚接触 104 协议、不知道怎么搭一个从站环境的调试工程师也适合做 SCADA 主站开发、需要一套可配置的假从站来验证功能的朋友以及那些被厂家设备“黑盒”坑过、想自己掌控联调节奏的兄弟们。1. 先把需求讲透为什么总要找一个从站模拟器1.1 从站模拟器到底在模拟什么IEC 104 协议走的是 TCP/IP典型架构就是主站作为 TCP 客户端主动去连从站的 2404 端口。从站也就是服务端在这个端口上监听按 104 规约的帧格式响应主站命令并主动上送遥测、遥信、电度这些数据。很多人一开始会把它想简单了觉得“我起一个 TCP Server往 socket 里塞数据不就得了”。真不是这样。104 从站模拟器真正模拟的不是 TCP 服务而是整套 104 协议状态机。包括最基础的 U 帧控制帧握手主站连上来之后会先发一个 STARTDT act 激活数据传输从站必须回一个 STARTDT con两边才算进入可传数据状态。之后才是 I 帧信息帧传数据、S 帧监视帧做确认每帧都有 2 字节的收发序号要管理。打个比方主站好比一个客服中心从站就是下面各个被监控的站点设备。真设备没到位的时候模拟器就是一个“替身演员”顶上去跟客服中心把该走的台词全走一遍。替身不光要站到台上还得懂剧本——这个剧本就是 104 协议里 ASDU 的编解码规则、控制流程、序号管理这些底层细节。1.2 没有从站模拟器调试会变成什么样子我在项目里见过太多组同事主站快联调了从站设备还没到货或者到了但点位表是厂家写死的想改个参数得层层审批。这时候如果没有模拟器调试基本就卡死在那了。就算有一台真装置在手上很多场景也搞不定。比如你想模拟“某个遥测值缓慢越限”“一个单点遥信频繁抖动变位”“某块表数据瞬间全丢”这种异常情况用真装置很难控制。真装置的点位、死区、上送周期都是按现场运行配置死的你想让它故意发些“不规范”的数据它反而不配合。还有一种替代方案是拿抓包工具去抓主站和真装置之间的报文事后分析。这只能被动看不能主动造数据调试主站逻辑时非常被动。所以从站模拟器的核心价值就一句话把主动权拿回自己手里想发什么数据就发什么数据想什么时候变位就什么时候变位。1.3 一个合格的从站模拟器应该具备哪些能力这些年用下来我评判一个从站模拟器好不好用主要看五个维度能力项说明点位建模灵活性能不能快速建遥测、遥信、电度、遥控/遥调点地址、类型、初始值、品质位能不能随意改连接管理规范性公共地址、端口、心跳周期、T0/T1/T2/T3 超时参数能不能配断线重连策略是否合理事件场景可编程能不能手动触发变位、告警、SOE、报文异常注入能不能定时自动执行双向调试能力既能模拟从站也能当简易主站去主动发总召唤、遥控验证对端从站可观测性收发报文能不能即时展示错误能不能可读能不能导出日志/抓包后面的工具推荐我就按这几个维度来聊。2. 工具盘点从开源库到可视化模拟器哪些值得用2.1 lib60870 / j60870开源协议栈里的首选如果要找一个开源、跨平台、能嵌进自己工程里做从站二次开发的方案MZ Automation 的 lib60870 系列基本是首选。它分 C 版本的 lib60870-C、.NET 版本的 lib60870.NET、Java 版本的 j60870主站和从站功能都完整支持。我为什么优先推它第一协议栈实现非常“标准”严格按照 IEC 60870-5-101/104 来跟各种主流主站兼容性都很好第二源码在 GitHub 上开箱即用注释清晰适合拿来当学习材料也适合做深度定制第三Server 示例写得很完整几分钟就能起一个从站第四社区活跃度不错遇到问题去 issue 区翻一翻经常能找到同类问题。对想深入理解 104 协议的朋友我尤其建议去读它的源码尤其是控制域序号管理和 ASDU 编解码那两段。读懂了你对 104 协议的理解会比只看标准文档深刻得多。2.2 FreyrSCADA 的 IEC104 模拟器可视化的免费方案FreyrSCADA 家的 IEC 60870-5-104 Client/Server Simulator 是商业软件但有免费评估版本对很多联调场景来说够用了。它最大优势是可视化图形界面配点表、改参数、看收发报文不用写一行代码。它提供两个角色。Server Simulator 用来模拟从站监听主站连接配置各种类型的点位能手动触发变化上送Client Simulator也就是很多人搜的 freyrscada iec104 client master用来模拟主站主动去连第三方从站发总召唤、遥控命令观测返回报文。这两个角色配合起来可以自己跟自己先测一遍再去跟真实设备对接。小提示免费评估版会有一些限制比如工程保存受限、点位数量受限、运行时限。严格来说拿来临时调试没问题但如果是商用项目长期用还是建议买正式授权别在这种工具上省出合规风险。2.3 HslCommunication国产通信库的便利国内做上位机、产线自动化的朋友对 HslCommunication 应该不陌生。胡工这套通信库除了支持各种 PLC、ModbusIEC 104 也做了完整支持里面直接封装了 Iec104Server 和 Iec104Client。它最大的价值在于文档是中文的遇到问题查起来效率高而且收发数据做了结构化封装点位值可以直接通过对象属性读写不用自己拼报文。你要是做的是上位机系统想在一个进程里集成本地数据处理、数据库记录、IEC104 上送这套库会省很多事。需要提醒的是授权问题HslCommunication 个人学习免费商业使用需要买授权。公司项目直接用之前一定确认清楚否则后面有合规麻烦。2.4 Wireshark永远不能少的抓包分析工具不管用哪个模拟器Wireshark 都是调试 104 的必备搭档。新版 Wireshark 自带的 iec104 dissector 已经能解析 U 帧、I 帧、S 帧以及 ASDU 内部结构比看着十六进制流自己数字节省太多时间。抓包时最常用的过滤条件是tcp.port 2404简单直接。如果 Wireshark 能识别出协议名也可以用iec104过滤。联调时我通常两台机器都开着抓包从站机器上抓响应主站机器上抓请求两边一对问题很快能定位到是发包没发出来还是回包没回对。2.5 其他值得关注的辅助工具Hercules SETUP Utility轻量级 TCP/UDP 调试工具适合先验证 2404 端口到底通不通排查防火墙和网络问题很顺手。PLANETEK SimSuite、SISCO ICC Toolkit专业的 IEC 协议仿真/测试平台功能强大价格也漂亮一般大项目或协议栈厂商才用。Python 脚本用 scapy 或者现成的 iec104 解析库批量解析报文、做自动化压力测试适合需要大量回归的场景。各家保护测控厂家的“后台仿真软件”很多是面向 IEC 61850 的跟 104 协议调试不是一回事选型时别混。3. 实操用 lib60870.NET 三分钟起一个从站3.1 获取工程先从 GitHub 把仓库拉下来git clone https://github.com/mz-automation/lib60870.git cd lib60870/lib60870.NETCore dotnet buildWindows 下记得装好 .NET SDK建议 .NET 6 或更高版本。如果不想用命令行直接用 Visual Studio 打开仓库里的lib60870.NETCore.Examples工程右键运行 ServerExample 也很快。3.2 理解 Server 的启动流程lib60870 的 Server 模式是典型的异步监听模型。启动前你要给它配三样东西本地监听端口默认 2404一个 ASDUHandler负责处理主站下发的 ASDU像总召唤、遥控、时钟同步都在这里写响应逻辑一个 ServerEventHandler处理连接建立、关闭等事件一般用来打日志。有个细节要注意从站调试时监听地址别只绑 127.0.0.1。主站可能是从局域网里别的机器连过来的绑回环会导致外面连不上。如果不需要限定来源监听所有网卡就行。3.3 最小可运行的 Server 示例代码下面这段代码演示了一个从站最小的三个能力启动监听、接收主站命令、周期上送数据。不同版本 API 命名可能有差异以你拉下来的仓库里的 Example 为准using lib60870; using lib60870.CS101; namespace ServerExample { class Program { static void Main(string[] args) { Server server new Server(); server.SetLocalPort(2404); server.SetUseSMS(false); // 1) 连接事件处理 server.ServerEventHandler (srv, con, eventType) { Console.WriteLine($连接事件: {eventType}); return true; }; // 2) ASDU处理主站下发的命令都走这里 server.SetASDUHandler (srv, con, asdu) { Console.WriteLine($收到ASDU TypeID{asdu.TypeID}); if (asdu.TypeID TypeID.C_IC_NA_1) { // 总召唤回确认然后全量上送数据 // 注意区分传输原因6(激活) 和 8(停止激活) } else if (asdu.TypeID TypeID.C_SC_NA_1) { // 单点遥控先回激活确认执行完回激活终止 } return true; }; server.Start(); // 3) 周期任务每2秒上送一个遥测点 int infoObjAddr 1001; while (true) { Thread.Sleep(2000); // 构造遥测ASDU通过 server.Connections 获取连接后 SendASDU // 注意设置品质位为有效否则主站会判为无效数据 } } } }周期上送的代码核心是这样一段ASDU asdu new ASDU(server.GetApplicationLayerParameters(), CauseOfTransmission.PERIODIC, false); asdu.SetCommonAddress(1); asdu.AddInformationObject( new MeasurementShortFloatInformationObject( new InformationObjectAddress(1001), 23.5f, QualityDescriptor.VALID)); server.Connections[0].SendASDU(asdu);这里有个经典坑很多开源库在构造信息对象时如果不显式设置品质描述符默认值可能是“无效”。你把数据发上去了主站那边也能收到包但点位显示“无效”或者“品质异常”实际上就是 Quality 位的问题。联调时先把这个置成有效能少排查很多事情。3.4 联调一把用 Client 连上来验证从站起来后用 FreyrSCADA 的 Client 模拟器或者你手头已有的 SCADA 主站直接连IP运行从站那台机器的局域网 IP端口2404公共地址和从站保持一致默认通常为 1连上之后观察从站控制台的日志能看到连接事件、收到的 ASDU 类型。我强烈建议同时开着 Wireshark在从站机器上过滤tcp.port 2404核对三件事是不是先有 STARTDT act/con把数据传输激活了总召唤的请求、确认、终止三步是不是完整周期上送的 I 帧序号是不是连续。这三步对完一大半连接类问题基本都能定位。4. 可视化模拟器的点表配置与参数避坑4.1 点位类型怎么选用 FreyrSCADA 这类图形化模拟器最核心的工作是配点表。每个点至少要选类型标识TypeID单点遥信、双点遥信、归一化遥测、标度化遥测、短浮点遥测、电度、单点遥控、双点遥控、设定值遥调等信息对象地址IOA和主站点表严格对应一般遥信一段、遥测一段、遥控一段别跨段品质描述Quality有效、无效、溢出、替换平时置有效想测异常再切换变化死区决定变化量达到多少才触发主动上送。最容易踩的坑就是遥测类型没对齐。主站点表里定义的是浮点型遥测你在模拟器里配成了归一化整型或者反过来结果是主站一直报数据类型不匹配或者数据变成了“天文数字”。所以动手配点之前先跟主站侧要一份点表把类型标识逐项核对清楚。4.2 公共地址与 IOA 的对应关系104 规约里ASDU 中有公共地址Common Address通常 2 字节每个信息对象又有信息对象地址IOA3 字节。主站收到数据后是用“公共地址 IOA”这个组合来索引点位的。模拟器里这两项必须配准公共地址一般一个站一个比如 1IOA 按点表映射比如遥信从 1 到 1000遥测从 1001 到 2000。联调时最诡异的一种现象是从站数据一直发得好好的主站就是“收不到”看抓包也正常最后发现公共地址一个配成 1一个配成 2ASDU 在应用层就被主站丢弃了。所以配置完先把这个字段检查三遍这是 104 联调里最高频的低级错误。4.3 变化上报和周期上送怎么配合从站模拟器一般有两种上送模式。周期上送按设定时间间隔把一批数据打包发出适合模拟稳态数据。变化上报则是当点值变化超过死区立即生成一个事件 ASDU 发出去模拟真实装置的突发告警、越限、变位。实际调试时这两种模式必须配合主站连上后一般会发总召唤从站回全量数据之后靠变化上报让主站实时刷新。很多模拟器默认只做周期上送这就导致主站侧的“变化告警”“SOE事件”“主动变位刷新”这些功能根本没法测。所以选模拟器时一定要确认它能手动触发单点变位、多点联动变位设置每个点的变化死区把变化事件按突发COT3上送。4.4 遥控/遥调命令的处理流程主站下发遥控命令104 标准流程是主站发激活命令传输原因 6从站回激活确认传输原因 7从站执行完成后回激活终止传输原因 10。这三步缺任何一步主站都会报“遥控超时”。用模拟器联调时先确认你用的模拟器支持完整的遥控响应流程。有些简单模拟器只做遥测遥信上送遥控命令处理根本没实现联调一测遥控就卡住你还以为是配置问题。另外遥控命令分单点C_SC和双点C_DC。双点命令的值有四种状态合1、分2、不确定0、中间态3模拟器要能正确映射到设备开关状态。实际项目里先测单点遥控通了再测双点能省不少排查时间。5. 联调实战中的高频问题排查5.1 TCP 连不上、STARTDT 不成功先别急着怀疑协议栈按这个顺序查从站是不是真的在监听 2404在从站机器上netstat -ano | findstr 2404看一眼防火墙有没有放行 TCP 2404Windows 上很多人临时把防火墙全关才能连上这类问题太常见了主站配置的 IP、端口是否和从站一致特别注意 104 是主站作为 TCP 客户端主动发起连接不是从站去连主站Wireshark 里看有没有 TCP 三次握手。如果 SYN 包一直在重传那就是网络层问题跟协议没关系TCP 通但 STARTDT 一直不回重点查从站的 U 帧处理逻辑以及 T1/T3 超时参数是不是配得太小。5.2 数据上去了但主站显示无效或收不到这种情况十有八九是下面几个原因公共地址Common Address不一致类型标识和主站点表不一致品质描述 Quality 没置有效位IOA 不在主站点表范围内。排查方法最直接打开 Wireshark把 ASDU 的原始字节取出来逐字段核对 Common Address、IOA、TypeID、Quality。尤其注意 104 是大端字节序地址字段是高位在前看十六进制时别按小端理解。5.3 遥控命令总超时主站下遥控后从站没反应先确认这几件事模拟器对遥控类型标识是否注册了处理逻辑有没有按“激活 → 激活确认 → 激活终止”三步响应传输原因是否写对激活是 6激活确认是 7激活终止是 10。常见错误是把确认原因填成“响应20”主站根本不认识。还有一个细节如果主站下发的是“选择执行”双命令模式从站还要分别对“选择”和“执行”各自做确认和终止模拟器如果只处理了执行没处理选择照样超时。5.4 报文抓到了但我看不懂第一次看 104 报文确实容易懵满屏十六进制。我建议按四个层次拆TCP 层确认源/目的端口是不是 2404帧类型看控制域第一个字节低两位I 帧为 0、S 帧为 1、U 帧为 3若为 I 帧继续拆 ASDU类型标识、传送原因、公共地址、信息对象地址、信息元素具体含义对照标准文本或者直接看 Wireshark 的解析结果。我自己学习时的土办法是先用模拟器发一个固定值抓包看对应的字节再改一个值抓包对比变化。改三次ASDU 结构基本就摸透了。5.5 联调时数据刷新总是“卡”出现数据刷新慢、变位延迟高常见原因有三个模拟器用的周期上送间隔太长变化上报事件优先级又没提起来TCP 开启了 Nagle 算法小包被合并延迟发送。部分协议栈和应用支持设置 TCP_NODELAY 来优化测试机性能太差或者后台有别的进程抢占 CPU。联调时尽量给模拟器一个干净环境别开一堆浏览器和编译任务。6. 我的工具选型建议与最后的经验提醒6.1 什么时候用什么工具场景推荐只想临时验证主站连接FreyrSCADA Server Simulator需要深度二次开发、嵌入自己系统lib60870 / HslCommunication学习协议、研究报文Wireshark lib60870 Server需要当主站主动测试第三方从站FreyrSCADA Client Master Simulator大批量点位性能测试lib60870 脚本编排6.2 个人经验提醒最后聊几个我踩过坑之后沉淀下来的经验。第一模拟器测出来的“通”不代表现场真装置一定通。模拟器通常对异常情况很宽容比如不严格校验帧序号、不处理重复帧、不模拟通讯中断。联调推进到一定阶段一定找一台真装置做一次交叉验证尤其是遥控和故障上送这类流程性功能。第二协议参数全程对齐。k/w 窗口、T0/T1/T2/T3、最大 ASDU 长度主站和从站必须一致。不然高速变化数据时会出现序号溢出、超时重传表象很像是网络问题实际是参数不匹配。第三每次联调保留原始抓包文件。出问题的时候先把 pcap 存下来标注时间、设备角色、故障现象。这东西比任何聊天记录里的截图都有说服力后面回溯、甩锅、写测试报告都用得上。第四如果项目是长期维护的别把模拟器当成一次性玩具。把点表、参数配置、测试脚本沉淀成项目资产。下一次主站升级、点表改版直接拉出来回归一遍能省出大量跟厂家的沟通时间。我希望这篇东西能把你在 IEC104 从站模拟和调试工具选型上的弯路省掉一些。调试工具这东西没有绝对的“最好”只有“合适”。但有一条放之四海皆准的原则工具拿过来先小范围验证一遍确认它能覆盖你的核心场景再投进正式联调里用。