SemaPLC: A Project-Grounded, Verification-Gated Agent Harness for PLC Code Generation

Summary (Overview)

  • SemaPLC is a verification-gated agent harness for PLC (Programmable Logic Controller) code generation that grounds generation in the target project and withholds completion until external checks confirm the result—rather than relying on the model's own self-assessment.
  • The harness enforces three verification layers: specification audits, compilation checks, and live runtime validation, with a strict completion rule requiring logged external evidence for every claimed pass.
  • On the function track (117 independent-POU tasks), SemaPLC achieves the highest strict verified pass rate on all seven models (72.6% mean vs. 63.9% for the strongest baseline), improving every backbone by 8.5–33.3 points.
  • On the project-context track (65 tasks across ten industrial plants), SemaPLC leads in integrated compilation (89.4%), static behavior (81.6%), and dynamic behavior (52.2% vs. at most 31.4% for baselines)—demonstrating that methods looking similar under static evaluation differ sharply at runtime.
  • The harness is open-sourced at https://github.com/midea-ai/SemaPLC.

Introduction and Theoretical Foundation

Background

Programmable logic controllers (PLCs) run industrial plants—factory lines, power plants, and water-treatment facilities—and are programmed primarily in IEC 61131-3 languages, of which Structured Text (ST) is the textual member. Prior work has established that LLMs can generate independent PLC program organization units (POUs), benefiting from:

  • Compiler-in-the-loop repair
  • Formal or property checking
  • Multi-agent iteration
  • Vendor IDEs
  • Physical or simulated testbeds

The Gap

In production, control logic is rarely an isolated POU. Deployment imposes two further requirements:

  1. Project grounding: Generated logic must integrate into an established project, reuse its modules and function blocks, respect its variables/types/interfaces, and honor build, reset, initialization, and safety conventions.
  2. Correct runtime behavior: Even when integrated programs compile and pass static checks, they can still misconfigure timers, take wrong state transitions, miss resets, break interlocks, or drive outputs with wrong timing.

Key insight: Prior systems execute generated code to demonstrate it can run, not to measure how reliably it runs. No unified assessment establishes, across methods and models, how reliably generated logic meets these two requirements.

Three Design Principles of SemaPLC

  1. Project-grounded generation: Anchors code generation and editing in available task or project context.
  2. Multi-source verification: Treats specification checks, compilation, and live runtime validation as first-class external evidence.
  3. Verification-gated iteration: Forbids the agent from terminating on its own judgment; failures, absences, or indeterminate outcomes require repair or incompletion reporting.

Methodology

Problem Formulation

Function track: Given requirement RfR_f and local interface IfI_f, the system produces a POU Lf=G(Rf,If)L_f = G(R_f, I_f). The primary metric is:

VerifiedPass(Lf)=1[Vf0.80],(1)\operatorname{VerifiedPass}(L_f) = \mathbb{1}[V_f \geq 0.80], \tag{1}

where VfV_f is the fraction of model-checked properties verified satisfied, with the 0.80 threshold following Agents4PLC.

Project-context track: Given requirement RpR_p and existing project PP, the system produces logic Lp=G(Rp,P)L_p = G(R_p, P) and integrated program P=PLpP' = P \oplus L_p, scored by three independent metrics:

  • Integrated compilation C(P){0,1}C(P') \in \{0, 1\}
  • Static behavior S(P,Rp)[0,100]S(P', R_p) \in [0, 100] (assertion-based, on program text)
  • Dynamic behavior D(P,T)[0,100]D(P', \mathcal{T}) \in [0, 100] (golden-trace differential on live runtime)

Algorithm: Verification-Gated Generation

The harness runs on a generic event-driven tool-use core with five components:

  1. Agent core: Plans, edits, interprets verification results
  2. Project/task grounding: Retrieves project structure, reuses existing variables and function blocks
  3. PLC skill library: Domain knowledge in documents (rules file, curated wiki, procedural skills)
  4. Verification processes: Specification audits, compilation, live runtime validation
  5. Verification gate: Decides completion per Algorithm 1

Three gate invariants:

  • Bounded retries: Each check allows at most r=2r = 2 repair rounds
  • Edit invalidation: Any modification voids all prior verdicts; every check re-runs
  • Earned claims: Each outcome is a machine-readable sentinel cross-validated against the tool-call log

Live Runtime Validation

Builds and deploys the implementation, initializes the runtime, injects scenario inputs, and samples external variables. Failure stages prescribe repair targets:

  • Flat trace → wiring problem
  • Changing but wrong trace → block logic
  • Late transition → timer or edge detector

Empirical Validation / Results

RQ1: Function-Level Reliability

Table 1: Function track strict verified pass rate (%, denominator 117)

ModelLLM4PLCAutoPLCAgents4PLCSemaPLC bareSemaPLC full
MiniMax-M2.722.249.653.839.369.2
MiniMax-M315.465.055.660.769.2
Qwen3.5-Plus13.767.567.562.475.2
DS-V4-Flash41.054.754.734.267.5
DS-V4-Pro43.661.562.455.669.2
GLM-5.230.859.074.463.276.1
GPT-5.544.479.578.671.882.1
Mean30.262.463.955.372.6
Worst13.749.653.834.267.5

Key findings:

  • SemaPLC attains the highest rate on all seven models (+8.8 points mean over strongest baseline)
  • Cross-model spread shrinks from 37.6 points (bare) to 14.6 points (full)
  • Weakest models gain most (MiniMax-M2.7 +29.9, DeepSeek-V4-Flash +33.3)

RQ2: Project-Grounded Reliability

Table 2: Project-context track (0–100, best per column in bold)

MethodMiniMax M2.7MiniMax M3Qwen3.5 PlusDS V4-FlashDS V4-ProGLM-5.2GPT-5.5WorstBestMean
Integrated compilation
LLM4PLC47.753.816.960.052.380.0100.016.9100.058.7
AutoPLC69.295.458.458.595.495.498.558.498.581.5
Agents4PLC47.769.240.075.478.589.298.540.098.571.2
SemaPLC81.595.480.084.689.295.4100.080.0100.089.4
Static behavior
LLM4PLC76.176.774.570.369.277.186.369.286.375.7
AutoPLC68.973.568.976.266.575.588.866.588.874.0
Agents4PLC63.473.577.671.464.562.888.662.888.671.7
SemaPLC74.984.979.978.081.288.084.174.988.081.6
Dynamic behavior
LLM4PLC3.026.16.618.413.934.654.53.054.522.4
AutoPLC4.043.519.823.945.721.961.14.061.131.4
Agents4PLC4.530.811.428.328.844.663.64.563.630.3
SemaPLC31.352.143.154.157.461.965.431.365.452.2

RQ3: Verification Across Layers

Key finding: All methods fall within 10 static points of one another, whereas dynamic scores separate them sharply (22.4 to 31.4 for baselines vs. 52.2 for SemaPLC).

Layer ablation (Table 3, DeepSeek-V4-Flash, 65 tasks):

Verification layersComp.StaticDyn.Tok.Reqs.
None (generate only)64.671.523.134k8.9
+ Spec70.874.030.360k14.6
+ Compile83.177.843.774k25.5
+ Runtime (full)84.678.054.1129k47.8

Formal verification coverage (Table 5): Timers are the boundary—none of the 174 properties across 32 timer-bearing programs obtained a conclusive verdict, motivating runtime validation for stateful timing constructs.

RQ4: Interaction Cost

MethodRequests/taskTime/task (s)
Function track
Agents4PLC6.3 (4.4–7.2)454 (241–688)
SemaPLC6.5 (5.5–7.6)71 (41–156)
Project track
Agents4PLC6.9 (6.8–7.0)344 (47–917)
SemaPLC34.1 (16.4–60.4)347 (25–1380)

Theoretical and Practical Implications

  1. Execution is the faithful test: Static scoring compresses and even reorders methods that runtime validation separates sharply. Benchmarks must execute generated logic to distinguish reliable methods from unreliable ones.

  2. Verification-gated iteration is a model-agnostic reliability layer: The harness improves every backbone model (8.5–33.3 points), with the weakest models gaining most—the external checks compensate for model limitations.

  3. Delivery-integrity guarantee: The three invariants (bounded retries, edit invalidation, earned claims) ensure the delivered program is identical to the candidate that earned every reported pass, with no unlogged self-reported pass surviving.

  4. Formal verification has coverage boundaries: Timers (TON) fall outside conclusive model-checking coverage in practice, making runtime validation a necessary complement rather than an alternative.

  5. Cost is architectural: SemaPLC's open-ended loop issues more requests (each tool call is a model decision), but achieves comparable wall-clock time on the project track and lower time on the function track.

Conclusion

SemaPLC demonstrates that a verification-gated agent harness—assembled from conventional tools but governed by strict external-check completion discipline—substantially improves PLC code generation reliability across models and evaluation layers. Key takeaways:

  • Best results across all layers: 72.6% mean verified pass rate (function track), 89.4% integrated compilation, 81.6% static behavior, and 52.2% dynamic behavior (project track).
  • Runtime validation is essential: Similar static scores mask sharply different runtime behavior; execution, not static scoring, is the faithful test.
  • Two limitations remain: (1) dynamic scoring exercises a bounded scenario set, so behavior under unseen conditions remains unmeasured; (2) the advantage narrows on the strongest model (GPT-5.5).

Future directions: An end-to-end PLC development environment on this harness architecture, with editing, generation, and deployment governed by the same verification gate, and validation extended to process simulation.

Related papers