RealPLC AI集成CODESYS实现编程和验证闭环!无需任何费用!

我们把产品层面统一成 RealPLC Agent，但运行时必须保持“强独立”。我不建议把 TIA、CODESYS 代码合并进一个大进程，也不建议安装两个完全重复、各自连接云端的 Agent。

最佳形态是：

一个 RealPLC Agent Core + 独立 Connector + 一次性验证 Worker

这样既有统一的用户体验，又能做到 TIA、CODESYS、后续 OEM 在故障、权限、升级和配置上的真正隔离。

一、参考主流 Agent 得出的设计原则

RealPLC 应吸收的是这些产品共同的成熟模式，不必照搬它们的技术栈。

二、推荐的最终架构

RealPLC Cloud
│ HTTPS / WebSocket，唯一云端连接
▼
┌────────────────────────────────────┐
│ RealPLC Agent Core                 │
│ 配对、身份、任务队列、策略、审批、升级、审计 │
└─────────────────┬──────────────────┘
│ 本机 Named Pipe / gRPC
┌───────┴────────┐
▼                ▼
┌────────────────┐  ┌──────────────────┐
│ TIA Connector  │  │ CODESYS Connector│
│ 独立进程/版本   │  │ 独立进程/版本     │
└───────┬────────┘  └─────────┬────────┘
▼                     ▼
TIA Job Worker         CODESYS Job Worker
每个任务启动一次        每个任务启动一次
│                     │
TIA Openness       CODESYS ScriptEngine / Win PLC

再增加一个当前 Windows 用户下运行的：

RealPLC Session Broker

它负责启动必须运行在用户桌面会话、访问用户安装目录或用户许可证的 OEM Worker。Core 本身作为 Windows Service 常驻，不直接加载 TIA 或 CODESYS SDK。

这样可以直接使用用户已有的软件和许可证，不引入额外授权成本。

三、组件应该怎样命名

用户看到的产品名称只有：

内部及诊断界面显示：

不建议都叫“Agent”，否则用户会误以为需要安装、配对、维护很多 Agent。专业产品通常是一个 Agent 管理多个 Integration/Connector。

四、“独立”需要达到什么程度

TIA 与 CODESYS 至少要在以下方面独立：

但以下能力应当共享：

这正是“用户体验统一、运行时强隔离”。

五、Connector 协议

不应该继续在 Core 里增加这种分支：

if (action == "codesys_validate") { ... }
if (action == "tia_compile") { ... }

应该建立一个稳定的 RealPLC Connector Protocol，每个 Connector 实现同一组生命周期接口：

Handshake()
GetCapabilities()
Diagnose()
ExecuteJob()
StreamEvents()
CancelJob()
GetHealth()
Shutdown()

Capabilities 建议包含：

{
"connectorId": "codesys",
"connectorVersion": "1.0.0",
"protocolVersion": "realplc.connector.v1",
"detectedProducts": [
{
"product": "CODESYS",
"version": "3.5.18",
"edition": "Standard"
}
],
"operations": [
"project.import",
"project.compile",
"runtime.download",
"runtime.start",
"test.execute"
],
"runtimeBackends": [
"Win V3 x64",
"Control Win V3 x64 SoftMotion"
],
"maxConcurrency": 1
}

Core 至少兼容当前和上一个 Connector 协议版本，避免一次升级牵动所有组件。

六、MCP 应放在哪一层

MCP 不建议作为 Core 与 Connector 之间的内部总线。

推荐位置是：

AI / 大模型
│ MCP
RealPLC MCP Adapter
│
RealPLC Agent Core
│
Connector

原因是：

GitHub 上开源的 CODESYS MCP 项目可以继续参考或复用，但应当包在 CODESYS Worker 内部，固定版本、审计源码和许可证，不要让它直接拥有 Agent 云端令牌或者绕过审批策略。

七、Worker 应当一次一任务

Connector 是长生命周期的监督进程，真正操作 OEM 软件的是一次性 Worker。

例如一次 CODESYS 验证：

每个 Worker 放入 Windows Job Object，设置：

CODESYS 与 TIA 可以并行，但同一个软件版本默认并发数为 1，避免 IDE、许可证和工程缓存发生冲突。

八、安全边界

建议遵循以下规则：

Connector 状态建议统一为：

未安装
已禁用
正在检测
需要配置
就绪
忙碌
异常降级
已隔离
需要升级
等待用户会话

九、UI 应怎样呈现

设置页面建议调整为：

RealPLC Agent
├─ 概览
├─ 连接与配对
├─ 集成
│  ├─ Siemens TIA Portal
│  ├─ CODESYS
│  └─ 添加集成
├─ 任务
├─ 审批
├─ 日志与诊断
└─ 更新

“集成”页面每个 Connector 都是独立卡片：

CODESYS
状态：就绪
Connector：1.0.0
检测到：CODESYS 3.5 SP18
仿真目标：Win V3 x64
上次验证：2 分钟前，成功
队列：0
[配置] [运行诊断] [查看日志] [禁用]

TIA 和 CODESYS 设置必须完全分开。一个 Connector 异常时，另一个仍显示真实状态并可继续执行任务。

ST 生成后的页面应增加明确的闭环阶段：

生成 ST
→ 静态检查
→ 正在等待 CODESYS Connector
→ 正在编译
→ 正在下载 Win PLC
→ 正在运行 TestSpec
→ 验证通过/验证失败

不能只生成 _UNVALIDATED.st 后结束。

最终建议

我建议正式确定为：

RealPLC Agent 是统一的设备侧控制面；每个 OEM 是独立、进程外、可单独升级的 Connector；每个验证任务由一次性 Worker 执行。

首版采用：

我们目前还在内部测试中，敬请关注RealPLC！