SemaPLC: 一个基于项目、验证门控的 PLC 代码生成智能体框架

TL;DR SemaPLC 用外部验证（规范、编译、实时运行）而非模型自评作为完成门槛，生成可集成进现有 PLC 项目的控制逻辑；动态执行测试中显著领先基线（52.2 vs 最高 31.4），证明运行验证才是可靠标准。

问题

问题背景

工业控制领域，PLC 程序设计长期依赖人工编写，随着 LLM 在代码生成上的进展，模型已能独立生成程序组织单元（POU），但真正部署到现有 PLC 项目并正确运行，仍缺乏系统化验证。

现有方法局限

现有 PLC 代码生成方法存在三个关键缺口：

• 停止条件主观：多数代理以模型自身判断“输出足够好”作为终止信号，缺少外部客观校验，容易过早停止于错误或次优解。
• 验证层次浅：只检查编译通过或少量静态行为，未接入真实 PLC 运行时，无法暴露扫描周期、I/O 时序、状态机竞争等动态问题。
• 项目集成缺失：生成逻辑独立于现有工程，不考虑全局变量、任务调度、其他 POU 交互，导致集成编译或运行时行为不一致。

为什么这个问题难且重要

PLC 代码直接控制物理设备，错误可能引发产线停机或安全事故，因此可信验证远比普通软件更关键。然而，集成验证需要处理大量项目特定上下文，动态行为测试又依赖真实硬件或仿真运行时，自动化成本高、可复现性差。业界亟需一种可度量、可重复的验证流水线，将生成逻辑置于真实项目中经受编译与运行时双重检验。

行业类比

类似自动驾驶系统开发中，纯仿真通过只是必要条件，还需封闭场地与公开道路测试；PLC 生成同样需要从静态检查走向运行时痕迹对比，才能证明控制逻辑真正可用。

核心洞察

• 验证门控完成规则把任务完成条件从模型自我判断改为外部日志确认，这是对 agentic code generation 可信度的根本修正。 现有方法通常在模型自评足够时停止，或仅以编译通过作为完成信号；而 SemaPLC 要求规格检查、编译、静态行为与 live runtime 动态行为全部由外部日志确认后才宣布完成。这种门控机制压制了模型自我高估，使生成逻辑在工业控制等高可靠性场景中具备可审计性，尤其适合 PLC 这类不允许静默失败的系统。
• 动态行为分数比静态指标更能区分不同生成方法，静态指标会产生虚假的接近感。 在项目上下文 track 中，所有方法的静态分数相差不到 10 分，而动态分数从 baseline 的 22.4–31.4 拉开到 SemaPLC 的 52.2。这说明部署到真实 PLC runtime 并比较执行轨迹，比编译通过或代码相似度更能反映生成逻辑是否真正可用。该结果挑战了以静态匹配为主的 PLC 代码评估基准设计，提示执行行为应是更忠实的测试。

方法

输入 → 关键模块 → 输出

SemaPLC 的输入是一个 PLC 编程任务，可为独立 POU 或嵌入现有 PLC 项目上下文。系统以 LLM 作为生成器，但通过外部工具与严格完成规则约束迭代过程。

关键模块

1. Project Grounding 与 PLC Skills：从现有项目抽取符号表、数据类型、POU 接口及项目结构，并结合 PLC 技能库（如 review skill、交付门禁）注入上下文，让生成代码与项目约定对齐。
2. Multi-Source Verification：对生成结果执行三层外部检查——规范检查（spec）、编译检查（compilation）和静态行为检查，确保逻辑未偏离需求且可编译。
3. Live Runtime Validation：将生成逻辑与参考逻辑部署到实时 PLC runtime，记录执行轨迹并比较。该动态行为层是 SemaPLC 区别于静态评分基线的关键。
4. Verification-Gated Iteration：不以模型自评为完成条件，只有所有外部检查日志通过后任务才结束；任一检查失败则进入修复循环。

输出为通过全部验证的 PLC 代码与验证日志。与同类方法的差异在于：完成判据从“模型判断输出合格”改为“外部运行时执行证据”，因此动态行为得分显著更高。

实验

实验设计

• 两条评测轨道：independent-POU track 复现 117 个独立 POU 任务；project-context track 包含 65 个任务，要求生成逻辑在真实项目中编译并运行。
• 验证分为三层：规范检查、集成编译、以及 live PLC runtime 行为；动态层通过将生成逻辑与参考逻辑部署到同一 runtime 并比较执行轨迹完成。
• 基线覆盖 7 个模型，SemaPLC 作为验证门控 agent harness 与之比较。

关键发现

• 在 117 个独立 POU 任务上，SemaPLC 获得平均 strict verified pass rate 72.6%，在所有七个模型上均为最高。
• 在 65 个项目上下文任务上，SemaPLC 在集成编译、静态行为、动态行为三项均值均为最高。
• 动态行为区分度最大：基线动态分数仅 22.4–31.4，SemaPLC 达 52.2；而静态分数各方法差距在 10 个点以内。

对比解读

• 传统方法依赖模型自我判断输出质量即停止，SemaPLC 仅在外部日志验证通过后才声明任务完成，避免“看起来正确”的假阳性。
• 静态指标无法拉开方法差距，executed traces 才是可信判据，提示工业 PLC 代码评估应把 live runtime 验证纳入 CI/CD 流程。
• 验证门控在每一层均值均有提升，且在 runtime 层提升最显著。

行业影响

落地场景

SemaPLC 可直接用于工业自动化领域的 PLC 代码生成与验证。典型场景包括：

• 汽车制造产线：为焊接、涂装、总装等工位自动生成 PLC 程序组织单元（POU），并通过编译和实时运行验证，减少人工调试周期。
• 智能仓储物流：快速迭代堆垛机、输送线、分拣系统的控制逻辑，在虚拟或真实 PLC 运行时上比对行为后上线。

商业价值

核心收益在于降低人力成本 和 缩短交付周期。传统 PLC 开发高度依赖资深工程师，现场验证风险高、返工频繁。SemaPLC 采用验证门控机制，只有通过规格、编译和动态行为检查才判定任务完成，论文中动态行为得分从基线均值 22.4–31.4 提升至 52.2，显著减少返工和停机损失。对装备制造商与集成商而言，这意味着更快的产线部署速度和更可靠的代码质量，可直接转化为项目利润率提升。

与现有产品/工作流的接口

SemaPLC 基于常规工具（编译器、PLC 运行时、规范检查器）组装，可无缝嵌入现有开发栈：

• IDE 插件：集成到 TIA Portal、CODESYS 等主流 PLC 开发环境，作为智能生成与审查助手。
• CI/CD 流程：在 Git PR 阶段调用 SemaPLC 作为 pre-merge gate，自动执行编译与仿真验证。
• 数字孪生/HIL 平台：通过 API 接入硬件在环环境，将动态行为比对作为发布门禁。

无需替换现有工具链，命令行或 API 即可驱动，降低企业采用门槛。

局限

• SemaPLC 的验证门控机制深度依赖 PLC 工具链（如符合 IEC 61131-3 的编译器、硬件或仿真 runtime）。虽然作者声明由常规工具组装，但实际部署仍需大量适配工作，限制了向其他代码生成任务的泛化。此外，动态行为 oracle 基于参考逻辑的执行轨迹，假定参考实现是唯一正确标准；在复杂控制场景中，多个功能等价实现可能产生不同但合法的轨迹，导致误判。评估任务规模（117 + 65）相对较小，可能不足以全面反映工业级 PLC 项目的多样性。
• 验证门控迭代涉及多次外部工具调用（规范检查、编译、部署到 live runtime 并比较轨迹），带来显著的计算和时间开销。论文虽然分析了交互成本（RQ4），但未提出有效的成本优化策略。live runtime 验证需要真实硬件或高保真仿真环境，部署成本高，可能阻碍在资源受限场景中的快速迭代。此外，方法的效果提升部分源于 baseline 缺乏动态验证能力，当面对更强 baseline（如自带运行时验证的 agent）时，SemaPLC 的优势可能缩小。
• 论文主要关注独立 POU 和项目上下文中的代码生成，但未深入探讨多任务协同、长期维护或跨项目泛化。PLC 项目往往包含大量相互依赖的 POU，而实验中的 65 个 project-context 任务仍属于中等规模，难以覆盖复杂的工业级项目结构。另外，作者使用的 PLC 技能库（skill library）可能针对特定平台或语言版本，如何保持技能库的更新与跨平台兼容性未作说明。