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 的那一天总会到来，我由衷期待这一天早日来临。
Select Language