IEC 104 Slave Simulator 开发与调试记录

1. 方案设计

工作需要测试 IEC 104 通讯协议，重点实现数据发生功能。我打算用 C# 编写一个 IEC 104 的 Slave Simulator 。首先使用 Claude Code 做方案设计，与它反复确认后形成了一份详细的方案文档。

2. 初次编程

方案确定后，我将文档交给 Cursor 进行第一次编码。我是 Cursor 的付费用户，但当时额度已用完，只能使用 Auto mode。生成代码后，用真实的 IEC 104 Master 连接测试，结果可以连上，却读取不到任何数据。奇怪的是，仿真器界面上数据显示是在变化的。

3. 优化调试

遇到问题后，我改用 Claude Code + Deepseek V4 Flash 进行调试（开启了 thinking mode ，未用 Pro mode ，也未开 1M 上下文）。AI 只修改了一次代码，大约花了 10 分钟，问题就解决了。Master 成功读到数据，整个调试过程花费极低。

最主要的是 deepseek 几乎是完全重构了最关键的 IEC104 的 lib60870 库的使用。

DS 的输出反馈： ● Root Cause

SlaveServer.cs 使用了原始 TcpListener 接收 TCP 连接，但完全没有实现 IEC 104 协议栈：

收到报文后只打印 Hex 日志，不做任何协议响应（不回复 STARTDT CON 、S 帧、I 帧）

PublishPoint 只做 TxCount++，从不发送数据

引用了 lib60870.NET NuGet 包，但从未调用任何库方法

架构文档中提到了 lib60870 层，但实际代码跳过了整个协议栈

所以 IEC 104 Master 可以建立 TCP 连接，但收不到任何 IEC 104 协议报文，显示"已连接"但无数据。

修改内容

Services/SlaveServer.cs — 完全重写

用 lib60870.CS104.Server 替换原始 TCP 逻辑（关键发现：CS104.Server 继承自 CS101.Slave ，天然具备全套协议处理能力）：

协议栈完整实现：TCP 连接、APCI 层、STARTDT/S 帧/U 帧/I 帧全部由 lib60870 自动处理

总召唤响应 (C_IC_NA_1)：收到 interrogation 后按 TypeID 分组发送所有数据点，最后发 ACT_TERM

遥控命令 (C_SC_NA_1)：收到单点遥控后发 ACT_CON → 执行 → 发 ACT_TERM

设点命令 (C_SE_NC_1)：收到浮点设点后发 ACT_CON → 执行 → 发 ACT_TERM

时钟同步 (C_CS_NA_1)：接收并确认

数据发布：PublishPoint 实际编码为 ASDU （ MeasuredValueShort/SinglePointInformation ），通过 Server.EnqueueASDU() 发送

APCI 参数：K/W/T1/T2/T3 从配置加载

连接管理：最大客户端限制、连接跟踪、收/发统计

Form1.cs — 新增一行

添加 _slaveServer.SetPoints(_runtimePoints.ToList()) 传递数据点引用，使总召唤时能读取当前值。

建议测试步骤

构建并启动程序，加载 station_01.json

用 IEC 104 Master 连接 127.0.0.1:2404

预期：总召唤后应收到所有数据点值，周期上送正常

测试遥控：对 IOA=400 下发 C_SC 命令

测试设点：对 IOA=401 下发 C_SE_NC 命令

4. 总结与展望

目前尚未涉及非常复杂的 task ，后续我会持续更新这个案例。这次经历让我感到：国产 AI 模型替代 Claude Code 、替代 ChatGPT 的那一天总会到来，我由衷期待这一天早日来临。

deepseek-v4-flash 能力强大

IEC 104 Slave Simulator 开发与调试记录

1. 方案设计

2. 初次编程

3. 优化调试

4. 总结与展望