Industrial control code generation (PLC, IEC 61131-3)

Programmable logic controllers (PLCs) run machines and plants, and their programs are still largely written by hand in vendor IDEs. LLM assistants now sit inside those IDEs (Siemens TIA Portal, CODESYS, TwinCAT, Rockwell) and research agents close the loop with compilers, simulators and model checkers. The realistic benefit is faster first drafts, explanation of legacy blocks and better test coverage, not unattended generation of safety-relevant control logic.

Problem & value

• Today: engineers translate a functional specification into Structured Text (ST), ladder (LD), function block diagram (FBD) or sequential function chart (SFC), by hand, in vendor-specific tools with proprietary dialects and libraries. Knowledge sits in a few senior people; skilled automation engineers are scarce; legacy code is poorly documented.
• AI value: draft boilerplate (state machines, motion/valve/drive wrappers, alarm handling), explain unfamiliar blocks, search manuals in natural language, generate tests and documentation, and port between dialects. Siemens, CODESYS and Beckhoff position these assistants as productivity aids for repetitive tasks [1][3][4].
• Evidence is thin: published benefit claims are mostly vendor statements. Academic work reports partial success: Agents4PLC reports formal verification success of up to ~68.8% on 23 tasks, and a 2025 paper notes remaining gaps between research results and industrial requirements [5][6]. Measure on your own code before promising numbers.

Variants

• IDE copilot (engineering assistant): chat/completion inside the vendor IDE; the most deployed form.
• Spec-to-code agent: specification in, ST out, with compiler, simulator and model-checker feedback (LLM4PLC / Agents4PLC pattern).
• Dialect translation and legacy migration: e.g. Step 7 / ladder to ST, vendor A to vendor B or to CODESYS-based runtimes (see CODE-005).
• Test and commissioning support: generate test sequences and virtual-commissioning scenarios against a digital twin.
• Machine builders (SMB): parametrise a library of function blocks per customer variant instead of free-form generation.
• Education/hobby: learning ST on simulators; no safety impact.

How it works

1. spec / I/O list / P&ID (+ company standard, vendor libraries via RAG)
2. LLM plans design (state machine, interfaces, tags)
3. LLM writes ST / function blocks
4. compile check (vendor compiler, or open-source MATIEC for IEC 61131-3 ST)
5. simulate / unit test (PLCSIM-class simulator, CODESYS Control Win, digital twin)
6. optional formal check (nuXmv, PLCverif) against requirements as temporal properties
7. errors fed back to LLM (loop, bounded)
8. engineer review + peer review + FAT/SAT commissioning
9. download to PLC

• Key components: a code LLM with retrieval over vendor manuals and your function-block library; deterministic tool feedback (compiler, simulator, model checker) as the main quality lever; the Model Context Protocol (MCP) to expose the IDE to the model (CODESYS MCP Server) [4].
• Human-in-the-loop: mandatory. The engineer reviews every generated line, runs the test suite in simulation, and only a human downloads code to a real controller. Safety code (safety PLC, SIL/PL-rated functions) is never auto-generated; Rockwell's copilot, for example, can explain but not modify safety-related code [7].

Data preparation

The AI needs your engineering context: existing PLC projects and function-block libraries, naming and coding standards, I/O lists, P&IDs and functional descriptions, vendor manuals and commissioning notes. In an SMB these live in TIA Portal or CODESYS project files, file shares, laptops of individual programmers, PDFs and paper plans.

Typical gaps: no common library or naming convention, specifications as scans or in Word, no simulation model to test generated code, undocumented machine behaviour, knowledge held by one senior programmer, and project files with customer-confidential machine data.

Preparation steps: - Consolidate reference projects and approved function blocks in version control (PREP-009, PREP-010). - Write the coding standard and tag naming rules down as a short rulebook (PREP-014, PREP-015). - Convert I/O lists and specs into tidy tables (PREP-011); scan and OCR old plans only where needed (PREP-006). - Curate manuals and standards as a searchable knowledge base (PREP-013). - Set up a PLC simulation or test bench as evaluation (PREP-018).

Effort share: low to medium, about 15-25 %, mostly library clean-up. GUIDE-003 offers an inventory template.

Implementation paths

Which path for whom

• SMB: Path A, because the PLC vendors (Siemens, CODESYS/WAGO, Beckhoff) ship copilots inside their engineering tools, and the machine builder or integrator stays in one supported ecosystem.
• Enterprise: Path B, because plant and machine know-how is a trade secret, standards and libraries are company-specific, and a harness with simulation and static analysis can be reused across vendors.
• Developer: Path B, because integrators and tool builders need vendor-neutral generation and verification against their own function-block libraries; self-hosting is optional where code must stay on site.

Path A — Buy (recommended)

• Siemens Industrial Copilot / Engineering Copilot TIA (EU): chatbot connected to a local TIA Portal, generates SCL for Simatic, explains blocks, searches manuals; built on Azure OpenAI; used e.g. by Schaeffler [1][2].
• CODESYS AI-supported engineering incl. MCP Server (EU, Germany): connects cloud or local LLMs to the CODESYS Development System; WAGO PLC Agent (EU) as add-on [4].
• Beckhoff TwinCAT Chat (EU): LLM chat in Visual Studio/TwinCAT 3 for function blocks, optimisation, documentation [8].
• Rockwell FactoryTalk Design Studio Copilot: code generation for entitled projects; safety code excluded [7].
• Choose A when: you already standardise on one vendor ecosystem; keeps data flow and support inside the vendor's terms.

Path B — Build on cloud APIs

• Frontier code/reasoning models (Claude, GPT, Gemini, Mistral/Codestral as EU provider) in EU regions, driven by an agent that calls your compiler, simulator and checker. Use the MCP server of the IDE where available.
• RAG over manuals, company PLC coding standard (naming, PLCopen guidelines) and an approved function-block library; export/import via PLCopen XML.
• Choose B when: multi-vendor estates or custom workflows (spec checking, test generation) are needed.

Path C — Self-host (open source)

• Open-weight code models (e.g. Qwen-Coder, DeepSeek-Coder, Codestral-class, Granite code) served via vLLM/Ollama; MATIEC (open-source IEC 61131-3 compiler), nuXmv/PLCverif for checking, OpenPLC or CODESYS runtime for simulation; research code of LLM4PLC/Agents4PLC/AutoPLC as starting points [5][6][9].
• Plants with strict IP or air-gapped engineering networks often require this. Hardware: HW3 for 30-120B class code models; HW2 for small models with narrow libraries. Ops effort is moderate to high.

Path D — Custom training

Worth it for vendor-dialect accuracy: ST is scarce in public training data and dialects differ, so AutoPLC-style vendor-aware generation (retrieval plus fine-tuning on your own compiling code) helps [9]. Needs a few thousand compiling, reviewed programs with specs; mind licence and IP of customer code.

State of the art (2026)

• Vendor copilots matured from chat (Beckhoff 2023) to IDE-integrated generation (Siemens 2024) and MCP-based agent access (CODESYS) [1][4][8].
• Research converged on generate, then verify: compiler and model checker in the loop beat pure prompting [5][6]. Vendor-aware retrieval improves compilation rates on proprietary dialects; reported figures vary by benchmark and version, so treat them cautiously [9].
• Limits and failure modes: hallucinated library calls or non-existent instructions; dialect mixing; compiling but wrong logic; missing timing, scan-cycle and interlock considerations; weak handling of ladder/FBD graphics versus text; unsafe default states on fault or restart; benchmark success on small tasks does not transfer to plant-scale projects.

Shared resources & combinations

• Same code-LLM and agent stack as CODE-001/CODE-002; test generation CODE-004; documentation CODE-006; migration CODE-005; embedded and safety-critical practices CODE-020; IaC-style pipelines (version control, CI with simulation) CODE-009.
• Downstream or adjacent: ANOM-005 (process anomaly detection on the same plant data), VIS-001 (inspection systems that interface with PLCs). A shared HW3 inference server can serve these.

Effort, cost & KPIs

• A: weeks to pilot (licences, IDE upgrade, training). B/C: 3-9 months for a verified pipeline incl. simulator integration. D: adds data curation and evaluation.
• Cost drivers: simulator and test-bench build-out, library curation, review time, licences.
• KPIs: compile-first-time rate, share of generated code accepted unchanged, defects found at FAT/SAT, engineering hours per project, test coverage, review time per block.

People & change

Involve: management (scope and safety responsibility), the head of automation as process owner, the PLC programmers as users, IT and IT security (OT/IT separation, no direct connection of the LLM to running controllers), legal/compliance for liability, CE and machinery rules, and suppliers or customers whose code or specifications are processed. A data protection officer is only needed if projects contain personal data, which is rare.

Works council: generally no, because the tool processes machine code and not employee behaviour. It becomes relevant if usage is logged per programmer or used to measure output (§87(1) no. 6 BetrVG), and §90(1) no. 3 asks for timely information about AI-supported work processes. Public sector: Personalrat.

AI literacy: support programmers with training on reviewing generated IEC 61131-3 code and on the limits of the models (GUIDE-006). Safety-related code stays outside AI generation.

Pilot and communication: start with non-safety routines such as scaling, alarm handling or documentation, run on a simulator, and measure time saved. Typical concerns are safety liability and deskilling; address them by mandatory review, simulation and sign-off by a qualified person, so the human always decides what runs on the machine (GUIDE-008, GUIDE-009, GUIDE-013).

Risks, regulation & compliance

• EU AI Act: the coding assistant itself is generally minimal risk (AI literacy, Art. 4). But PLC code often forms the safety function of a machine; AI-assisted development does not itself make the machine an AI system, yet if AI is used as a safety component inside a product (machinery, Annex I) high-risk rules can apply. Classification depends on the end product, hence "depends" [10].
• Machinery and safety: Machinery Regulation (EU) 2023/1230 (applies from Jan 2027), IEC 61508 / ISO 13849 / IEC 62061 validation duties remain with the manufacturer; critical infrastructure operators face NIS2 and Cyber Resilience Act obligations for software supply chain and secure development [11].
• GDPR: normally no personal data; operator data or shift logs in prompts may qualify.
• Cybersecurity/IP: control logic reveals process know-how; do not send it to non-contracted APIs; restrict AI access to the engineering network (IEC 62443 zones).
• Mitigations: generated code treated as untrusted input, mandatory peer review, simulation and FAT, traceability from requirement to code to test, version control with provenance tags for AI-generated blocks, no AI in safety-rated code paths.

Getting started

1. Pick a low-risk scope: utility blocks, alarm handling, documentation and explanations, no safety code.
2. Enable the vendor copilot (or CODESYS MCP Server) for 2-3 engineers and capture time and defect data.
3. Digitalise your coding standard and function-block library as retrieval material.
4. Build a simulation-based test bench; require compile plus tests before review.
5. Define a policy: review rules, labelling of AI code, IP and network rules; run an AI-literacy training.

Sources

1. Siemens — Engineering Copilot TIA — https://xcelerator.siemens.com/global/en/all-offerings/products/e/engineering-copilot-tia.html
2. Automation World — Schaeffler brings Siemens Industrial Copilot to its shop floor — https://automationworld.com/factory/digital-transformation/news/55235167/schaeffler-brings-siemens-industrial-copilot-to-its-shop-floor
3. Electropages — Generative AI and PLC coding — https://electropages.com/2024/09/generative-ai-and-plc-coding-automation-beyond-basics
4. CODESYS — AI-supported Engineering — https://www.codesys.com/products/engineering/ai-supported-engineering/
5. Agents4PLC (arXiv 2410.14209) — https://arxiv.org/pdf/2410.14209v1
6. LLM4PLC (arXiv 2401.05443) — https://arxiv.org/html/2401.05443v1
7. Rockwell — FactoryTalk Design Studio Copilot — https://www.rockwellautomation.com/en-ie/docs/factorytalk-design-studio/current/contents-ditamap/getting-started/factorytalk-design-studio-copilot.html
8. Beckhoff — TwinCAT Chat — https://www.beckhoff.com/en-au/company/press/twincat-chat-using-innovative-chatbot-technology-in-twincat-engineering-2023-04.html
9. AutoPLC (arXiv 2412.02410) — https://arxiv.org/html/2412.02410v2
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
11. Regulation (EU) 2023/1230 (Machinery Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1230/oj