每个搞电力自动化调试的人，迟早都会面对一个需求：手里没有真实的RTU或保护装置，却要验证主站的遥测、遥信、遥控、SOE这些功能。我入行头几年也吃过苦头，为了测一个主站的总召逻辑，抱着十几斤的装置在实验室反复拆接线。后来发现，用IEC104从站模拟器在电脑上起一个虚拟子站，几分钟就能完成同样的验证，而且改值、变位、触发SOE都比真实装置灵活得多。这篇文章就把我这些年用过、折腾过的IEC104从站/服务端模拟器和配套调试工具整理一遍，说说它们各自适合什么场景，也把踩过的坑一并列出来，给正在选型或者刚接触这协议的朋友做个参考。
1. 先搞懂IEC104从站模拟器到底在模拟什么
1.1 协议印象：一次信息交互的基本流程
IEC104是建立在TCP/IP之上的远动规约，默认端口是2404。主站（客户端）主动发起到从站（服务端）的连接，从站监听2404端口，等待主站的STARTDT激活、总召唤、时钟同步、遥控等命令，然后按标准报文格式返回数据。从站模拟器干的事，就是在电脑上把这个“服务端”实现出来：监听端口、处理APCI握手、解析ASDU、维护点表、生成响应。
可以把这套交互想象成考官和考生的面试：主站是考官，从站是考生，模拟器就是一个“标准答案机器人”。考官问什么，机器人答什么，问总召就把所有点表报一遍，问遥控就回答选择成功、执行成功。实际工程里，IEC104报文分为U帧、S帧、I帧三类，模拟器会自动处理U帧的启动传输（STARTDT）、停止传输（STOPDT）、链路测试（TESTFR），也会对主站发来的I帧做S帧确认。你只需要关心ASDU里的具体数据和点表，不用手动拼每一帧APCI，这是模拟器最大的价值。
1.2 从站模拟器在调试工作中的定位
很多人觉得模拟器只是“没有真设备时的凑合替代”，但实际用过就知道，它的定位远不止如此。以我做的SCADA主站项目为例，调试阶段经常需要验证画面刷新、告警推送、遥控流程、历史存储。如果用真实装置，每改一个遥测值就要去现场拨码或者改装置组态，测一个SOE还要反复触发硬接点，效率极低。模拟器则可以在数据库里随便改值、模拟通信中断、生成异常品质，把主站的边界情况都测一遍。
模拟器与真实装置的关系，应该是一种互补，而不是替代。真实装置能够验证规约之外的东西，比如电气接线、采样精度、保护逻辑；而模拟器擅长的是快速、反复、批量化地验证协议交互和主站逻辑。我通常在项目前期用模拟器完成80%的主站联调，留到最后才拉真装置做整体验证，这样整个调试周期能缩短一半以上。
2. 我常用的IEC104从站/服务端模拟器盘点
2.1 开源首选：lib60870库及其自带示例
MZ Automation维护的lib60870是我最常推荐的开源方案。它支持C/C++、C#、Java、Python等多个语言绑定，在Windows、Linux、嵌入式平台都能跑。很多人以为它只是一个协议库，其实它的examples目录里就带了slave示例程序，编译后就是一个可以直接使用的IEC104从站模拟器，支持配置TCP端口、公共地址、信息对象地址，还能把存好的点表自动加载进去。
我没有入坑前总觉得开源库要写代码太麻烦，真正用过一次才知道，它的编译难度远低于预期。以C#版本为例，拉到源码后用Visual Studio打开示例工程，编译运行，一个监听2404端口的从站就起来了。对于熟悉Python的朋友，c104这个绑定模块更加友好，可以在脚本里动态添加遥测、遥信、遥控点，按自己的逻辑修改数据值。缺点是它不提供可视化的点表管理界面，手头没有现成配置模板时，得自己写点表文件或脚本，适合愿意折腾一点的人。
2.2 低代码快速模拟：FreyrSCADA IEC104 Server Simulator
如果不想碰代码，FreyrSCADA的IEC104 Server Simulator可以看一下。它在电力自动化调试验证场景里算是比较成熟的产品，界面是Windows图形化操作，左侧树形结构维护站点、公共地址、信息对象地址，右侧直接修改点值、品质、时间戳，支持同时开启多个Server实例模拟多个子站。
我之前用它做过一次现场演示，五分钟之内就把一个包含几个遥测、几十个遥控点的虚拟RTU起起来了，主站那边正常总召、遥控，完全没有问题。这个工具对非研发背景的调试人员更友好，因为不需要理解底层库函数，所有点表操作都是点鼠标完成。它比较适合时间紧、只要模拟一个常规从站的场景，比如软件验收测试、培训演示这种。它的定位是商业软件，项目里要长期使用需要购买授权，但评估版也能完成大部分基础功能验证。
2.3 抓包验证必备：Wireshark与协议过滤器
有了从站模拟器，就离得开抓包工具吗？离不开。不管模拟器界面做得再好，最终判断协议交互是否符合标准，还是得看报文。Wireshark本身并不算是“从站模拟器”，但它是调试IEC104模拟器时最重要的辅助工具。在Wireshark里设置tcp.port == 2404过滤器，可以直接看到主站和从站之间的每一个APDU，包括U帧的STARTDT激活确认、I帧的总召唤、S帧的编号确认。
我做联调时有一个固定习惯：无论用哪款模拟器，第一步都要抓一次完整的启动和总召包，确认链路建立、数据类型、地址映射没有问题，再往后继续操作。这样做的好处是出了问题可以直接定位到哪一层，而不是在主站界面和模拟器界面之间反复猜。Wireshark还有专门的IEC104协议解析器，能自动解析APCI和ASDU字段，省掉了手动比对字节的功夫。
2.4 传统RTU调试软件与商业方案
除了上述两类，实际工程里还会遇到各类厂家自带的站端调试软件，这些软件往往内置了IEC104从站模拟功能。比如某些保护装置厂家，把模拟器直接做到调试软件里，选择装置型号后就能模拟出该装置的点表结构、品质描述，甚至能模拟一些厂家扩展ASDU类型。这种方案的优势是贴近真实装置，在验证特定厂家点时很有用；劣势是只能模拟自家型号，且软件往往只有配合硬件狗才能用。
此外，市面上还有针对IEC104协议一致性测试的商业工具，比如一些从站/主站仿真测试系统，内置大量标准符合性用例，支持自动判定通过与否。这类工具价格不低，通常用于产品入网检测、实验室认证等正式场合。对绝大多数普通项目调试而言，开源库加图形化模拟器加Wireshark这三板斧已经足够覆盖日常需求了。
3. 选型前先搞清这些关键能力
3.1 协议支持深度是硬门槛
很多新手以为，只要能连上就是好模拟器，但我实际用下来发现，协议支持深度才是真正的硬门槛。IEC104里面有不少容易被忽略但又很关键的点，比如总召唤结束后要发送总召唤结束确认，比如支持带时标的ASDU类型M_SP_TB_1、M_ME_TD_1，比如双点遥控C_DC_NA_1的选择/执行时序，再比如品质描述QDS中无效、溢出、被取代、闭锁这些标志位。
选型时我建议列一个清单，逐项对照模拟器是否支持。至少要覆盖：U帧、S帧、I帧处理；总召唤、时钟同步、链路测试；遥测M_ME_NC、遥信M_SP_NA、遥控C_SC/C_DC、SOE M_SP_TB；公共地址配置；多客户端连接。如果模拟器连这些基本项都做不全，等联调到一半再发现不支持的ASDU类型，换工具的成本会很高。下表是一个我常用的对比维度：
| 评估维度 | 基础需求 | 进阶需求 |
|---|---|---|
| 帧类型 | 支持U/S/I帧 | 支持嵌套私有扩展 |
| ASDU类型 | 遥测、遥信、遥控、SOE | 带品质、带时标、事件缓存 |
| 连接模式 | 单客户端 | 多客户端并发，异常断线重连 |
| 点表规模 | 1000点内 | 上万点，支持动态加载 |
| 动态行为 | 手动改值 | 自动变位、随机突变、脚本控制 |
3.2 模拟规模与动态行为决定测试效率
一个实际变电站的点表动辄几千上万点，如果模拟器只能手动一个个加，效率会非常低。我在测试一个地调主站时，需要模拟两个子站共两万多个遥测、遥信点，最后选的是能用脚本批量生成点表的方案。批量生成之后，还要考虑动态行为：模拟器能不能让某一路遥测按一定趋势自动变化？能不能让某几个遥信随机翻转来模拟现场抖动？这些能力直接决定测试覆盖度。
有些模拟器支持配置变化策略，比如周期递增、正弦波动、随机跳变，有些则需要通过外部脚本或API触发。如果是用lib60870这类库，这些逻辑完全可以通过代码实现，自由度最高；图形化模拟器则要看软件本身是否提供自动变化功能。选型之前，先把你要模拟的点表类型和动态变化需求列清楚，不要等环境搭好了才发现模拟器只能输出固定值。
3.3 免费与商业工具的取舍建议
我理解很多团队选型时最关心的就是成本。免费开源的lib60870确实很好，但它的本质是库，需要有人能写代码、能编译；如果你的团队全是纯调试工程师，没人熟悉代码，强行上开源库反而会拖慢进度。反过来，如果团队里有开发能力，花半天时间熟悉文档，后面所有点表、异常场景都能自己扩展，自由度高得多。
商业工具的优势在于界面友好、支持到位、输出规范，适合交付时间紧、没有专职开发、又需要应付客户验收的场合。我的建议是：先花几个小时试用一套开源方案，验证基本链路；如果觉得配置点表太痛苦，再考虑商业工具。如果项目本身涉及产品长期运行、多次回归测试，商业工具的价值会更明显，因为它在重复性和稳定性上通常比临时脚本更可靠。
4. 从零搭建一个IEC104从站测试环境
4.1 用lib60870的示例程序快速启动一个从站
以lib60870为例，最快搭建一个从站测试环境的步骤如下。先到GitHub上把lib60870仓库拉下来，选择你需要的语言绑定，我习惯用C#版本做Windows调试。进入examples目录，找到slave示例工程，直接编译运行。默认配置下它会监听本机2404端口，并加载一个内置的示例点表，里面有遥测、遥信、遥控各若干点。这时在另一台机器或本机用主站调试客户端连接，就能看到数据了。
如果你熟悉Python，也可以尝试c104绑定。安装非常简单，只需一行命令。下面这个例子是示意结构，具体API要以你安装版本的官方文档为准：
import c104 # 创建一个从站，监听2404端口 server = c104.Server(port=2404) # 添加一个站，公共地址为1 station = server.add_station(1) # 添加一个遥测点，信息对象地址5000，类型为短浮点遥测 point = station.add_point(io_address=5000, type=c104.Type.M_ME_NC) point.value = 22.5 # 启动从站 server.start() input("从站已运行，按回车停止") server.stop()这个脚本的逻辑很直观：创建一个从站，加一个站，加一个点，启动后就开始监听。主站连接并总召时，这个点就会以M_ME_NC类型发送出去。如果只是做功能验证，这个级别的代码投入已经是多数人能接受的。
4.2 配置主站连接参数和点表
从站起来之后，最常出问题的不是监听端口，而是主站和从站的地址映射对不上。IEC104里面有两层地址概念：第一层是公共地址（即站地址），用于标识是哪个子站；第二层是信息对象地址IOA，用于标识该子站下的某个具体测点。主站连接参数里配置的IP、端口、站地址，必须与模拟器一致，否则总召和遥控都会失败。
举个例子，模拟器配置了一个站公共地址是1，信息对象地址5000是遥测值，那么主站侧也必须建立相同的信息对象地址5000，并将ASDU类型配置为M_ME_NC。如果主站那边把这个点配置成了遥信M_SP_NA，即使地址相同，收到的数据也无法正确解析。我调试时有一个习惯：先把模拟器点表导出来，在主站数据库里批量导入，然后用类型对照表再核对一遍，这样能减少大量低级错误。
点表的配置涉及一个常见术语“映射”。不同模拟器导出的点表格式可能不一样，有的导出为一列IOA、一列类型、一列初始值，有的是标准CSV。建议在搭环境之前就统一约定一种格式，方便自动化测试脚本后续复用。我每次搭环境都会保留一份点表模板，后续换站点只需要批量替换公共地址和数量，能省不少时间。
4.3 用Wireshark验证链路建立和总召唤
从站起来、点表也配好了，下一步就是抓包确认链路是否正常。打开Wireshark，选择对应网卡，在过滤器里输入tcp.port == 2404。然后在主站侧发起连接，并按常规流程执行总召唤。正常情况下，你应该依次看到：
- 主站发送U帧STARTDT激活，从站返回STARTDT激活确认；
- 主站发送总召唤I帧（类型C_IC_NA_1，原因1/20），从站回复一系列数据帧；
- 数据帧以遥测M_ME_NC、遥信M_SP_NA等ASDU为主，最后有一条总召唤结束帧（C_IC_NA_1，原因10）。
如果总召唤后没有任何数据帧返回，优先确认模拟器的点表是否为空，或者主站请求的公共地址与模拟器配置是否一致。如果只有连接、没有STARTDT激活确认，那就说明模拟器没有正确响应U帧，需要检查模拟器是否真正启动在2404端口，或者防火墙是不是把连接拦了。Wireshark里还可以直接看ASDU的类型、IOA、值，方便逐点核对。
5. 调试现场的高频故障与排查实录
5.1 主站连接不上或频繁断线
这是排障第一个遇到的坑。先别急着怀疑协议，先确认物理链路，用telnet或者TCP调试助手试一下2404端口通不通。如果端口不通，八成是防火墙或IP配置问题。如果端口通但连接后立刻断开，就要看IEC104的TCP保活机制和超时参数了。
IEC104规定了一系列定时器：T0是连接建立超时，T1是发送或测试帧确认超时，T2是接收确认超时，T3是无数据时的测试帧周期。主站和从站两侧的这些参数必须匹配，否则会出现“连接正常，但几秒钟就断”的现象。还有一种高频原因是从站模拟器只支持单客户端连接，主站重连时旧连接还没释放，新连接就被拒绝。我遇到过一次，排查半天最后发现是模拟器界面里连接的客户端列表里残留了一个死连接，清掉之后立刻正常。
5.2 总召唤后依然收不到遥测数据
总召发了，从站也连着，但主站画面上一个遥测都没有。这种情况我一般按三步定位。第一步，抓包看从站有没有回总召确认和总召结束确认，如果只回了确认、没回数据，说明模拟器没有把点挂到总召响应列表里。第二步，看返回ASDU的公共地址和IOA是否在主站数据库中存在。很多主站对不在点表范围内的IOA会直接丢弃，导致画面看起来“没有数据”。第三步，看品质描述QDS，如果数据带INVALID或BLOCKED标志，主站可能出于安全考虑不刷新画面。
我见过一个很隐蔽的问题：模拟器返回的遥测值超过了主站配置的量程上限，主站判断为超量程后把数据置为无效。后来才发现不是协议问题，是模拟器里随手填了一个超大量测值。所以遇到收不到数据，除了看报文，还要把主站侧的量程配置一起检查一遍。
5.3 遥控选择/执行不成功
遥控是IEC104调试里最让人头疼的部分，因为涉及选择和执行两个阶段。标准的双点遥控流程是主站先发C_DC_NA_1，置S/E=1表示选择；接着再发一帧，S/E=0表示执行。模拟器在处理时要牢记当前站点的遥控状态，如果主站跳过选择直接执行，或者先执行再选择，模拟器必须按标准返回合适的拒绝原因。
我踩过的坑是模拟器只做了选择确认，没有做执行确认。主站那边显示“选择成功”，但执行命令迟迟没有返回确认，遥控超时。排查时抓包才发现，模拟器收到执行帧后根本没有回应。后来在代码里补上了执行状态处理，问题才解决。如果你用的是图形化模拟器，要确认它的遥控逻辑是完整的选择/执行状态机，而不是只回一次确认。
5.4 时间同步和SOE时间戳错乱
IEC104的时间同步通过C_CS_NA_1实现，主站下发站时钟，从站收到后要修正自身时间。这里最容易踩的坑是时区问题。模拟器运行在PC上，PC的本地时间、UTC时间、时区设置都会影响SOE的时标。你期望的SOE时间戳是本地时间，但报文里带的是UTC，主站显示出来就差了好几个小时。
处理办法是在模拟器里明确时间基准，并在主站侧配置好时区偏移。我做跨时区项目时，统一约定所有模拟器用UTC时间，主站负责转换成当地时区，这样避免两端重复加减。SOE另一个常见问题是信息对象地址和时标格式，CP56Time2a是7字节，毫秒、分钟、小时、日期、星期、月份、年份每个字段都有对应关系，如果模拟器生成的时标有非法值，主站可能直接丢弃该条SOE。遇到这种情况，用Wireshark逐字节核对时标是最有效的手段。
6. 我的一点习惯和后续扩展
6.1 模拟器不是万能，自动化脚本要跟上
用了这么长时间IEC104从站模拟器，我最大的体会是：工具只是敲门砖，真正提升效率的是把模拟器纳入自动化测试体系。如果你只用图形界面手动改值，一次两次还行，要测主站24小时稳定性、批量验证几千个点的时候，手动操作根本不现实。我的做法是把lib60870或者c104封装成一套测试脚本，通过脚本批量下发点值、翻转遥信、生成SOE、触发遥控，让模拟器变成一个可以程序控制的“协议测试机器人”。
脚本还能模拟异常场景，比如突然断开TCP连接、连续发送大量报文、发送异常ASDU类型，用来验证主站的容错和恢复能力。这些测试如果靠人工操作，既慢又容易遗漏。平时多花一点时间把点表、动态行为、故障注入都做成可配置的脚本，后面项目复用起来会非常舒服。
6.2 从站模拟器还能用于哪些场景
最后聊聊模拟器的扩展用途。除了常规联调，我还用它做新员工培训。新人刚接触IEC104时，在真实设备上练习风险太高，用模拟器代替，随便折腾都不怕，还能结合Wireshark直观地看到每一帧报文，学习效率比看文档高得多。
在项目验收测试里，模拟器也可以用来构造边界条件，比如让某个遥测点输出满量程、负值、品质无效，验证主站是否按预期处理。协议一致性自测时，模拟器加Wireshark的组合，能帮助你逐个字段核对标准报文格式，提前发现产品协议实现里的短板。对我个人而言，模拟器已经不是一个“应急工具”，而是每次协议调试前必开环境的一部分。建议所有做SCADA、远动通信、配电自动化的朋友，都花点时间把一套趁手的IEC104从站模拟方案跑通，后续项目里你会感激这个决定。
