Pith. sign in

REVIEW 3 major objections 6 minor 56 references

AutoPLC: Generating Vendor-Aware Structured Text for Programmable Logic Controllers

T0 review · 3 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper shows that a general LLM, supplied with vendor API libraries, a requirement-to-code case base, and real vendor compiler feedback, can generate Structured Text PLC code that compiles more than 90% of the time.

desk verdict AutoPLC is a real engineering artifact, but the headline 90% pass rate is inflated by benchmark leakage; fix the evaluation split before believing the number. read the letter →

arxiv 2412.02410 v2 pith:7JXVXKWQ submitted 2024-12-03 cs.SE cs.AI

Donghao Yang , Aolang Wu , Tianyi Zhang , Li Zhang , Fang Liu , Xiaoli Lian , Yuming Ren , Jiaji Tian
show 1 more author
Xiaoyin Che
This is my paper · ORCID
classification cs.SEcs.AI
keywords StructuredTextProgrammableLogicControllersLLMcodegenerationvendor-awareretrieval-augmentedcompilerfeedbackIEC61131-3industrialautomation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that industrial Structured Text (ST) programming, which is fragmented by vendor-specific dialects, can be automated from natural-language requirements without fine-tuning a large language model. It builds two vendor-specific knowledge sources—an API library and a requirement-to-code case library—and routes generation through four stages: natural-language planning, case retrieval with LLM reranking, API recommendation, and an iterative repair loop that feeds compiler errors from the real vendor platform back into the model. On a 914-task benchmark spanning two ST variants, the framework reports compilation pass rates above 90%, with 100% compilation on a 23-task external benchmark and an average cost of about $0.13 per task. Experienced PLC engineers rated the output useful, including code that did not compile. A sympathetic reading is that retrieval plus authentic vendor compiler feedback, rather than larger or specialized models, is the key to making LLM-generated control code usable.

What carries the argument

The load-bearing machinery is the paired knowledge infrastructure and a four-stage generation workflow. The API library stores vendor functions with descriptions, parameters, examples, and a generated three-dimensional index (functional summary, usage scenarios, ST keywords), which makes low-level hardware-aware functions retrievable from high-level plans. The case library stores requirement-plan-code-API quadruples, so the model receives proven implementation experience in context. The workflow classifies the task, writes a natural-language plan (state-machine style for process control, linear steps otherwise), retrieves top cases by embedding similarity then LLM reranking, recommends APIs by combining BM25 retrieval, I/O type matching, and similar-case augmentation with LLM filtering, and finally generates code that is repaired against compiler diagnostics from the actual vendor IDE, fixing declaration errors before implementation errors.

What would settle it

Hold out entire source library families during retrieval (for example, build the case database only from the open ST library and test on the two SCL sets, then swap), keeping planning, API recommendation, and compiler feedback unchanged; if pass rates stay above 90% the headline result is robust, and if they fall steeply the substring-only filter is doing much of the work.

Watch

Extended reading notes

Core claim

The paper's central claim is that the bottleneck in LLM-based PLC code generation is not reasoning ability but missing vendor knowledge and missing authentic validation. With an API library whose entries are indexed by generated summaries, scenarios, and ST keywords, and a case library of requirement-plan-code-API quadruples, the pipeline lets a general LLM produce code that matches vendor syntax and function signatures. The reported evidence: compilation pass rates of 92.72% on the general-purpose SCL set, 91.11% on the process-control set, and 92.90% on the open ST set, plus 78.30% formal-validation pass rate and 100% compilation on the external 23-task benchmark. The framework outperforms all compared baselines and closes most of the gap between raw LLM performance and the 90%+ target.

Load-bearing premise

The benchmark and the case database are built from the same three source libraries, and the only guard against the retriever returning the ground-truth solution is a case-name substring filter.

Editorial extensions

If this is right

  • If correct, the framework shows that per-vendor fine-tuning is unnecessary: a general LLM plus curated knowledge and real compiler feedback reaches above 90% compilation on two different ST dialects.
  • The ablation data attributes the largest gains to case retrieval and the compiler-feedback repair loop, so subsequent systems should invest in knowledge bases and authentic validation rather than only in stronger models.
  • At $0.13 per task and about 52 seconds per task, the pipeline is cheap enough to be an interactive engineering aid rather than a batch research tool.
  • Because the benchmark covers mostly basic functions and small process-control tasks, the established claim is about compilable first drafts; the paper explicitly leaves complex interlocking, recipe management, and large-system integration as future work.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper's claims, its leakage guard is a substring-name filter between benchmark tasks and cases drawn from the same three source libraries; a stronger test would hold out entire library families to measure how much retrieval of near-duplicate ground-truth code contributes to the reported pass rates.
  • Beyond the paper's claims, the recipe of explicit state-machine planning, small curated case retrieval, and feedback from the real toolchain is transferable to other stateful, vendor-fragmented languages such as IEC 61499 function blocks or embedded C variants.
  • Beyond the paper's claims, the expert comments suggest the next concrete extension: teach the repair loop to add input validation and runtime-safety checks, moving the headline metric from 'compiles' toward 'safe to execute'.
  • Beyond the paper's claims, a community-standard conformance checker that emulates vendor extensions would make future PLC-generation benchmarks reproducible without requiring proprietary IDEs.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. AutoPLC is a framework for generating vendor-specific Structured Text (ST) code for PLCs from natural-language requirements, targeting Siemens SCL (TIA Portal) and CODESYS ST. The system builds two knowledge bases, APILib (vendor API metadata with three-dimensional indexes) and Rq2ST (requirement-plan-code cases), and uses a four-stage pipeline: NL-based planning with state-machine support for control tasks, case retrieval with LLM reranking, API recommendation with BM25 and type-based augmentation, and iterative code generation with compiler feedback from real vendor IDEs. The evaluation uses a 914-task benchmark curated from OSCAT (718), Siemens LGF (151), and a Siemens competition dataset (45), plus the external 23-task Agents4PLC benchmark. The paper reports compilation pass rates above 90% on all three self-built datasets and 100% on Agents4PLC, with lower average error counts than six general LLM baselines, LLM4PLC, and MapCoder. It also presents an ablation study, an execution-based functional test on a 71-task subset, and a manual expert evaluation of 90 sampled cases. The authors open-source the framework and benchmark.

Significance. If the empirical claims are trustworthy, AutoPLC is a substantial practical contribution: it demonstrates that retrieval-augmented generation combined with vendor-IDE compiler feedback can produce syntactically valid ST code at very low cost ($0.13 per task), and it provides one of the largest open benchmarks for ST generation. The use of real TIA Portal and CODESYS compilation, the ablation study covering all four stages, the external Agents4PLC comparison, and the open-source release are concrete strengths that go beyond what most prior work in this area provides. The manual evaluation and the explicit discussion of limitations show a degree of methodological care. However, the central evaluation is compromised by a data-leakage risk: Rq2ST is built from the same corpora that form the 914-task benchmark, and the leakage filter is only a substring-name match. The functional-correctness check, where AutoPLC passes the full test suite on only about half of the examined tasks, further tempers the headline compilation-success claim. The external benchmark partially mitigates the leakage concern but is too small to fully support the paper's conclusions.

major comments (3)
  1. [Section IV-C and VI-B] The Rq2ST knowledge base is constructed from the same OSCAT, LGF, and Siemens Competition corpora that define the 914-task benchmark (Section IV-B1), and Stage 2 (Case Retrieving) injects the top-3 retrieved cases into the generation prompt. The only exclusion filter is mutual substring containment of case names; this does not remove near-duplicate implementations with rephrased requirements, renamed variables, or minor API differences. For a typical target task, the ground-truth code (or a close variant) is therefore present in Rq2ST, so the reported 92.72%/91.11%/92.90% pass rates measure performance when the answer is retrievable, not generalization to unseen ST requirements. The ablation in Table III (removing Case Retrieving drops the pass rate by 35.01% on LGF and 19.51% on Competition) is consistent with this leakage. The defense in VI-B that semantic overlap reflects real-world conditions is not a rebuttal: the benchmark is meant to measure system capability, and held-out tasks are required for that. The external Agents4PLC set (23 tasks) is independent and helps, but is too small to support the headline claim.
  2. [Section V-A and VI-C] The execution-based evaluation covers only 71 tasks, selected as the intersection of compilation-passing cases from AutoPLC and MapCoder. AutoPLC achieves full-suite success on 35 of these 71 tasks (about 49%), and across all 487 test cases the two models pass 76%. The paper reports these numbers but the RQ1 answer and the abstract present only compilation pass rates. Because the 71-task subset is not a random sample of the benchmark, the compilation numbers and the correctness numbers cannot be combined, and the resulting picture is that on the subset where correctness was actually measured, AutoPLC fails roughly half the tasks under the paper's own strict all-test-cases-must-pass criterion. This should be reported as a central limitation and should temper the claim that AutoPLC generates ST code that is practically usable, even though Section VI-C does acknowledge limited functional assessment.
  3. [Section IV-D and Table II] The baseline comparison is not symmetric. AutoPLC uses Rq2ST and APILib, which are built from the same corpora as the benchmark, while the baselines (except Agents4PLC as reported) do not have access to these knowledge bases. The large gaps, e.g., 92.72% vs. 15.23% for Claude-3.5-Sonnet on LGF, may therefore reflect the availability of near-answer retrieval rather than the superiority of the four-stage pipeline. To support the comparative claim, the authors should evaluate a version of AutoPLC without the knowledge bases (which the ablation partially provides) and, ideally, give the baselines access to an equivalent held-out knowledge source, or compare on tasks where the knowledge base is guaranteed not to contain the ground truth.
minor comments (6)
  1. [Section II-A] The text contains multiple 'Fig.??' placeholders, so the figure references in the background section do not render; these should be fixed before publication.
  2. [Section III-A] There are formatting errors in the text such as 'T askand Code' and 'AP Isare'; these should be corrected.
  3. [Section IV-C] The filter described in this section is called 'strict,' but it only checks mutual substring containment of names; a more precise term such as 'name-based exclusion' would be less misleading.
  4. [Section V-A] The reported improvement of 1620.8% over LLM4PLC on Agents4PLC is a relative percentage comparison of pass rates (100.00% vs. 36.36%); the paper should state this as percentage-point difference or otherwise clarify the metric to avoid overstatement.
  5. [Section IV-B2 and Table II] The terminology 'Valid. Rate' in Table II is introduced as 'formal verification pass rate' in the introduction; the two terms should be unified for consistency.
  6. [Section V-B] The phrase 'As shown in Huang et al. (2024) [17]' cites a broad trustworthiness survey without pinpointing the specific finding about external knowledge and feedback; a more precise citation would help the reader verify the claim.

Circularity Check

1 steps flagged · score 6.0 of 10

Benchmark pass rates are partially circular: the Rq2ST retrieval corpus is built from the same OSCAT/LGF/Competition code used as benchmark ground truth, and Stage 2 injects retrieved code as few-shot examples, making compilation success partly a retrieval artifact; the external 23-task Agents4PLC benchmark only partially breaks the loop.

  1. self definitional [Sections IV-B1, IV-C, and III-C]
    ""For each function in these library documentations, we extract the description and input/output parameters as task description, and the corresponding code implementation as the ground truth." ... "We construct the Rq2ST knowledge base using the Competition and LGF datasets (Section IV-B1)... The Rq2ST knowledge base integrates the OSCAT dataset.""

    The 914 benchmark tasks are extracted from OSCAT/LGF/Competition code, and Rq2ST is populated from exactly these same datasets. Stage 2 retrieves cases by embedding similarity and injects "their requirements, plans, and ST code as few-shot examples" into the generation prompt, so the generator can receive the ground-truth implementation or a close sibling as context. The only exclusion rule is mutual substring containment of textual names, which does not remove semantically similar cases (the paper concedes "some cases implementing similar logic to the task may remain"). The >90% pass rate is thus partly a retrieval artifact rather than an independent measure of generation ability; the 23-task Agents4PLC benchmark partially breaks the loop but is too small to carry the headline.

full rationale

The central claim of AutoPLC—over 90% compilation pass rate on the 914-task benchmark—is not a first-principles prediction; it is produced by a pipeline whose retrieval stage draws on a knowledge base built from the same three libraries that define the benchmark ground truth. Section IV-B1 states that each benchmark task is the description extracted from a library function and that the library code is the ground truth; Section IV-C states that Rq2ST is constructed from the Competition, LGF, and OSCAT datasets; Section III-C states that Stage 2 injects retrieved requirement-plan-code triplets as few-shot examples. The substring-name filter does not exclude semantically near-identical cases, as the paper itself acknowledges in IV-C and VI-B. Therefore the high pass rate is substantially explained by the generator reproducing or lightly adapting a retrieved near-answer, not by independent synthesis. This is a data-leakage circularity in the benchmark, not a hidden mathematical one. The external Agents4PLC evaluation (23 tasks, 100% compilation) is genuinely independent and provides some support, so the paper is not wholly circular; however, that benchmark is too small to validate the headline. The paper's self-citations (e.g., [31,32] for LLM filtering ability) are not load-bearing; they support peripheral claims about API recommendation. The ablation results (removing Case Retrieving drops pass rate by up to 35%) are consistent with retrieval supplying near-answer code rather than general domain knowledge. Overall score 6: partial, but not total, circularity of the main quantitative claim.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The central results are empirical, so the ledger lists the hand-set hyperparameters and the domain assumptions that the evaluation rests on. No new physical or mathematical entities are introduced.

free parameters (2)
  • top_k_retrieval_cases = 5 candidates, final 3
    Hand-chosen retrieval sizes; no ablation across values reported.
  • max_repair_iterations = 3
    Hand-chosen limit for the compiler-feedback loop; not swept.
assumptions (3)
  • domain assumption Compilation success in TIA Portal V19 and CODESYS V3.5 SP20 is a valid proxy for code quality and usefulness.
    The evaluation's primary metric is compilation pass rate; functional correctness is only checked on a subset of 71 tasks.
  • ad hoc to paper The substring-based name filter is sufficient to prevent data leakage between Rq2ST and the benchmark tasks.
    Rq2ST is built from the same OSCAT/LGF/Competition libraries that define benchmark ground truth; only mutual substring containment is excluded, leaving room for semantic near-duplicates.
  • domain assumption Benchmark tasks extracted from library documentation are representative of real-world PLC programming tasks.
    Tasks are constructed from open-source libraries and one competition (Siemens Competition Dataset); process control coverage is limited (45 tasks).

how reviews work

0 comments
Cite this review

Pith. "Pith review of AutoPLC: Generating Vendor-Aware Structured Text for Programmable Logic Controllers." pith.science (2026). https://pith.science/paper/7JXVXKWQ

@misc{pith2026241202410,
  author       = {Pith},
  title        = {Pith review of: AutoPLC: Generating Vendor-Aware Structured Text for Programmable Logic Controllers},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7JXVXKWQ}},
  note         = {Machine review of arXiv:2412.02410}
}
abstract

Among the programming languages for Programmable Logic Controllers (PLCs), Structured Text (ST) is widely adopted for industrial automation due to its expressiveness and flexibility. However, major vendors implement ST with proprietary extensions and hardware-specific libraries - Siemens' SCL and CODESYS' ST each differ in syntax and functionality. This fragmentation forces engineers to relearn implementation details across platforms, creating substantial productivity barriers. To address this challenge, we developed AutoPLC, a framework capable of automatically generating vendor-aware ST code directly from natural language requirements. Our solution begins by building two essential knowledge sources tailored to each vendor's specifications: a structured API library containing platform-exclusive functions, and an annotated case database that captures real-world implementation experience. Building on these foundations, we created a four-stage generation process that combines step-wise planning (enhanced with a lightweight natural language state machine support for control logic), contextual case retrieval using LLM-based reranking, API recommendation guided by industrial data, and dynamic validation through direct interaction with vendor IDEs. Implemented for Siemens TIA Portal and the CODESYS platform, AutoPLC achieves 90%+ compilation success on our 914-task benchmark (covering general-purpose and process control functions), outperforming all selected baselines, at an average cost of only $0.13 per task. Experienced PLC engineers positively assessed the practical utility of the generated code, including cases that failed compilation. We open-source our framework at https://github.com/cangkui/AutoPLC.

Figures

Figures reproduced from arXiv: 2412.02410 by the authors.

Figure 1
Figure 1. Example code segments implemented by different vendors. (a) is ACTUATOR, (b) and (c) are both FIFO. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Framework of AutoPLC. • Overly generic plans fail to capture control logic specifics. Public LLMs, trained predominantly on general-purpose tasks, tend to produce plans that inadequately represent the state transitions fundamental to process control tasks. • Pseudocode-formatted plans introduce syntactic noise in ST generation. According to our observation, when plans are expressed in pseudocode, the code-generation… view at source ↗
Figure 3
Figure 3. Violin plot showing the manual evaluation results. [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

56 extracted references · 41 canonical work pages

  1. [1]

    Gpt-4 technical report

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, et al. Gpt-4 technical report. arXiv preprint arXiv:2303.08774, 2023

    arXiv 2023

  2. [2]

    Claude, 2024

    anthropic.com. Claude, 2024. URL https://claude.ai/new

    work page 2024

  3. [3]

    Program synthesis with large language models

    Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, et al. Program synthesis with large language models. arXiv preprint arXiv:2108.07732 , 2021

    arXiv 2021

  4. [4]

    Generative AI Application Competition: Code Generation for Industrial Software - Biendata, June 2024

    biendata.xyz. Generative AI Application Competition: Code Generation for Industrial Software - Biendata, June 2024. URL https://www.biendata.xyz/competition/ siemens-ai

    work page 2024

  5. [5]

    Language models are few-shot learners

    Tom B Brown. Language models are few-shot learners. arXiv preprint arXiv:2005.14165 , 2020

    arXiv 2005

  6. [6]

    Codesys group, May 2021

    codesys.com. Codesys group, May 2021. URL https: //www.codesys.com

    work page 2021

  7. [7]

    Plc code generation based on a formal specification language

    D ´aniel Darvas, Enrique Blanco Vi ˜nuela, and Istv ´an Ma- jzik. Plc code generation based on a formal specification language. In 2016 IEEE 14th International Conference on Industrial Informatics , pages 389–396. IEEE, 2016

    work page 2016

  8. [8]

    Source code repository, 2024

    Mario de Sousa. Source code repository, 2024. URL https://bitbucket.org/mjsousa/matiec git. 2024-11-03

    work page 2024

Show all 56 references
  1. [9]

    A survey on in-context learning, October 2024

    Qingxiu Dong, Lei Li, Damai Dai, Ce Zheng, Jingyuan Ma, et al. A survey on in-context learning, October 2024

    2024

  2. [10]

    Self- collaboration code generation via chatgpt

    Yihong Dong, Xue Jiang, Zhi Jin, and Ge Li. Self- collaboration code generation via chatgpt. ACM Trans- actions on Software Engineering and Methodology , 33 (7):1–38, 2024

    2024

  3. [11]

    Llm4plc: Harnessing large language models for verifiable pro- gramming of plcs in industrial control systems

    Mohamad Fakih, Rahul Dharmaji, et al. Llm4plc: Harnessing large language models for verifiable pro- gramming of plcs in industrial control systems. In Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Practice, pages 192–203, 2024

    2024

  4. [12]

    Iec 61131-3: Programming languages (edition 3.0-2013), 2024

    PLCopen for efficiency in automation. Iec 61131-3: Programming languages (edition 3.0-2013), 2024

    2013

  5. [13]

    Chatglm: A family of large language models from glm- 130b to glm-4 all tools

    Team GLM, Aohan Zeng, Bin Xu, Bowen Wang, et al. Chatglm: A family of large language models from glm- 130b to glm-4 all tools. arXiv preprint arXiv:2406.12793, 2024

    2024 arXiv

  6. [14]

    Llm-based code generation method for golang compiler testing

    Qiuhan Gu. Llm-based code generation method for golang compiler testing. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering , page 2201–2203. Association for Computing Machinery, 2023

    2023

  7. [15]

    Deepseek- coder: When the large language model meets programming–the rise of code intelligence

    Daya Guo, Qihao Zhu, Dejian Yang, et al. Deepseek- coder: When the large language model meets programming–the rise of code intelligence. arXiv preprint arXiv:2401.14196, 2024

    2024 arXiv

  8. [16]

    Training llms for generating iec 61131-3 structured text with online feedback

    Aaron Haag, Bertram Fuchs, Altay Kacan, and Oliver Lohse. Training llms for generating iec 61131-3 structured text with online feedback. arXiv preprint arXiv:2410.22159, 2024

    2024 arXiv

  9. [17]

    Trustllm: Trustworthiness in large language models, 2024

    Yue Huang, Lichao Sun, Haoran Wang, Siyuan Wu, Qihui Zhang, et al. Trustllm: Trustworthiness in large language models, 2024

    2024

  10. [18]

    Qwen2.5-coder technical report

    Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, et al. Qwen2.5-coder technical report. arXiv preprint arXiv:2409.12186, 2024

    2024 arXiv

  11. [19]

    Plc market size & share analysis- growth trend & proecasts (2024-2029), 2024

    Mordor Intelligence. Plc market size & share analysis- growth trend & proecasts (2024-2029), 2024

    2024

  12. [20]

    Mapcoder: Multi-agent code gen- eration for competitive problem solving

    Md Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez. Mapcoder: Multi-agent code gen- eration for competitive problem solving. arXiv preprint arXiv:2405.11403, 2024

    2024 arXiv

  13. [21]

    Self- planning code generation with large language models

    Xue Jiang, Yihong Dong, Lecheng Wang, et al. Self- planning code generation with large language models. ACM Transactions on Software Engineering and Method- ology, 33(7):1–30, 2024

    2024

  14. [22]

    SWE-bench: Can language models resolve real-world github issues? In The Twelfth International Conference on Learning Representations , 2024

    Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R Narasimhan. SWE-bench: Can language models resolve real-world github issues? In The Twelfth International Conference on Learning Representations , 2024

    2024

  15. [23]

    nuxmv, 2024

    Fondazione Bruno Kessier. nuxmv, 2024. URL https: //nuxmv.fbk.eu/

    2024

  16. [24]

    jubnzv/iec-checker, November 2024

    Georgiy Komarov. jubnzv/iec-checker, November 2024. URL https://github.com/jubnzv/iec-checker

    2024

  17. [25]

    LLM-based Control Code Generation using Image Recognition

    Heiko Koziolek and Anne Koziolek. LLM-based Control Code Generation using Image Recognition. In 2024 IEEE/ACM International Workshop on Large Language Models for Code (LLM4Code), pages 38–45, April 2024

    2024

  18. [26]

    Chatgpt for plc/dcs control logic generation

    Heiko Koziolek, Sten Gruener, and Virendra Ashiwal. Chatgpt for plc/dcs control logic generation. In 2023 IEEE 28th International Conference on Emerging Tech- nologies and Factory Automation (ETFA) , pages 1–8. IEEE, 2023

    2023

  19. [27]

    Automated control logic test case generation using large language models

    Heiko Koziolek, Virendra Ashiwal, Soumyadip Bandy- opadhyay, and Chandrika K R. Automated control logic test case generation using large language models. In 2024 IEEE 29th International Conference on Emerging Technologies and Factory Automation (ETFA), pages 1– 8, 2024

    2024

  20. [28]

    LLM-based and Retrieval-Augmented Control Code Generation

    Heiko Koziolek, Sten Gr ¨uner, Rhaban Hark, Virendra Ashiwal, et al. LLM-based and Retrieval-Augmented Control Code Generation. In Proceedings of the 1st International Workshop on Large Language Models for Code, LLM4Code ’24, pages 22–29. Association for Computing Machinery, S...

    2024

  21. [29]

    A survey on retrieval-augmented text gen- eration

    Huayang Li, Yixuan Su, Deng Cai, Yan Wang, and Lemao Liu. A survey on retrieval-augmented text gen- eration. arXiv preprint arXiv:2202.01110 , 2022

    2022 arXiv

  22. [30]

    Structured chain-of-thought prompting for code generation

    Jia Li, Ge Li, Yongmin Li, and Zhi Jin. Structured chain-of-thought prompting for code generation. ACM Transactions on Software Engineering and Methodology, 2023

    2023

  23. [31]

    Imperfect code generation: Uncovering weak- nesses in automatic code generation by large language models

    Xiaoli Lian, Shuaisong Wang, Jieping Ma, Xin Tan, Fang Liu, et al. Imperfect code generation: Uncovering weak- nesses in automatic code generation by large language models. In 2024 IEEE/ACM 46th International Confer- ence on Software Engineering: Companion Proceedings (ICSE-Co...

    2024

  24. [32]

    Incorporating verification standards for security requirements generation from func- tional specifications

    Xiaoli Lian, Shuaisong Wang, Hanyu Zou, Fang Liu, Jiajun Wu, and Li Zhang. Incorporating verification standards for security requirements generation from func- tional specifications. Proc. ACM Softw. Eng. , 2(FSE), June 2025

    2025

  25. [33]

    Context- aware code generation framework for code repositories: Local, global, and third-party library awareness

    Dianshu Liao, Shidong Pan, Qing Huang, Xiaoxue Ren, Zhenchang Xing, Huan Jin, and Qinying Li. Context- aware code generation framework for code repositories: Local, global, and third-party library awareness. arXiv preprint arXiv:2312.05772, 2023

    2023 arXiv

  26. [34]

    Agents4plc: Automat- ing closed-loop plc code generation and verification in industrial control systems using llm-based agents

    Zihan Liu, Ruinan Zeng, et al. Agents4plc: Automat- ing closed-loop plc code generation and verification in industrial control systems using llm-based agents. arXiv preprint arXiv:2410.14209, 2024

    2024 arXiv

  27. [35]

    Llama-3.1 (8b): A large language model, 2024

    Meta. Llama-3.1 (8b): A large language model, 2024

    2024

  28. [36]

    Chaplin, David Sanderson, and Svetan Ratchev

    Fan Mo, Miriam Ugarte Querejeta, Joseph Hellewell, Hamood Ur Rehman, Miren Illarramendi Rezabal, Jack C. Chaplin, David Sanderson, and Svetan Ratchev. Plc orchestration automation to enhance human–machine integration in adaptive manufacturing systems. Journal of Manufacturing ...

    2023 doi

  29. [37]

    URL https://www.sciencedirect.com/science/article/ pii/S0278612523001474

  30. [38]

    Niang, B

    M. Niang, B. Riera, A. Philippot, J. Zaytoon, F. Gel- lot, and R. Coupat. A methodology for auto- matic generation, formal verification and implementa- tion of safe plc programs for power supply equip- ment of the electric lines of railway control sys- tems. Computers in Indus...

    2020 doi

  31. [39]

    Codegen: An open large language model for code with multi-turn program synthesis

    Erik Nijkamp, Bo Pang, Hiroaki Hayashi, et al. Codegen: An open large language model for code with multi-turn program synthesis. In ICLR. OpenReview.net, 2023

    2023

  32. [40]

    Chatgpt: Optimizing language models for dialogue, 2022

    OpenAI. Chatgpt: Optimizing language models for dialogue, 2022

    2022

  33. [41]

    Oscat basic

    oscat.de. Oscat basic. product description and spec- ifications, 2024-11-03. URL http://www.oscat.de/de/ 63-oscat-basic-321.html

    2024

  34. [42]

    Re- trieval augmented code generation and summarization

    Md Rizwan Parvez, Wasi Uddin Ahmad, Saikat Chakraborty, Baishakhi Ray, and Kai-Wei Chang. Re- trieval augmented code generation and summarization. arXiv preprint arXiv:2108.11601 , 2021

    2021 arXiv

  35. [43]

    The probabilistic relevance framework: Bm25 and beyond

    Stephen Robertson and Hugo Zaragoza. The probabilistic relevance framework: Bm25 and beyond. Found. Trends Inf. Retr., 3(4):333–389, April 2009

    2009

  36. [44]

    Code llama: Open foundation models for code

    Baptiste Roziere, Jonas Gehring, et al. Code llama: Open foundation models for code. arXiv preprint arXiv:2308.12950, 2023

    2023 arXiv

  37. [45]

    UDAPDR: Unsupervised domain adaptation via LLM prompting and distillation of rerankers

    Jon Saad-Falcon, Omar Khattab, Keshav Santhanam, et al. UDAPDR: Unsupervised domain adaptation via LLM prompting and distillation of rerankers. In Pro- ceedings of the 2023 Conference on Empirical Methods in Natural Language Processing , pages 11265–11279. Association for Comp...

    2023

  38. [46]

    Library of general functions (LGF) for SIMATIC STEP 7 (TIA Portal) and SIMATIC S7

    Siemens. Library of general functions (LGF) for SIMATIC STEP 7 (TIA Portal) and SIMATIC S7... - ID: 109479728 - Industry Support Siemens, 2024

    2024

  39. [47]

    SIMATIC STEP 7 inkl

    Siemens. SIMATIC STEP 7 inkl. Safety, S7-PLCSIM and WinCC V19 TRIAL Download - ID: 109820994 - Industry Support Siemens, 2024

    2024

  40. [48]

    Automated code generation for programmable logic controllers based on knowledge acquisition from engineering artifacts: Con- cept and case study

    Michael Steinegger and Alois Zoitl. Automated code generation for programmable logic controllers based on knowledge acquisition from engineering artifacts: Con- cept and case study. In Proceedings of 2012 IEEE 17th International Conference on Emerging Technologies & Factory Au...

    2012

  41. [49]

    technavio. Programmable logic controller (plc) market analysis apac, north america, europe, middle east and africa, south america - us, china, japan, germany, uk - size and forecast 2024-2028, 2024

    2024

  42. [50]

    CodeHalu: Code Hallucinations in LLMs Driven by Execution-based Verification, April 2024

    Yuchen Tian, Weixiang Yan, Qian Yang, Qian Chen, Wen Wang, et al. CodeHalu: Code Hallucinations in LLMs Driven by Execution-based Verification, April 2024

    2024

  43. [51]

    Plc programming: A comprehensive guide to mastering the art of automation, 2024

    WEVOLVER. Plc programming: A comprehensive guide to mastering the art of automation, 2024

    2024

  44. [52]

    Versicode: Towards version-controllable code generation, 2024

    Tongtong Wu, Weigang Wu, Xingyu Wang, Kang Xu, Suyu Ma, Gholamreza Haffari, et al. Versicode: Towards version-controllable code generation, 2024

    2024

  45. [53]

    Learning to mine aligned code and natural language pairs from stack overflow

    Pengcheng Yin, Bowen Deng, Edgar Chen, Bogdan Vasilescu, and Graham Neubig. Learning to mine aligned code and natural language pairs from stack overflow. In International Conference on Mining Software Reposito- ries, MSR, pages 476–486. ACM, 2018

    2018

  46. [54]

    Tenenbaum, and Chuang Gan

    Shun Zhang, Zhenfang Chen, Yikang Shen, Mingyu Ding, Joshua B. Tenenbaum, and Chuang Gan. Plan- ning with large language models for code generation. In The Eleventh International Conference on Learning Representations, 2023

    2023

  47. [55]

    Syntax-aware retrieval augmented code genera- tion

    Xiangyu Zhang, Yu Zhou, Guang Yang, and Taolue Chen. Syntax-aware retrieval augmented code genera- tion. In The 2023 Conference on Empirical Methods in Natural Language Processing, 2023

    2023

  48. [56]

    Retrieval-Augmented Generation for AI-Generated Content: A Survey, Febru- ary 2024

    Penghao Zhao, Hailin Zhang, et al. Retrieval-Augmented Generation for AI-Generated Content: A Survey, Febru- ary 2024

    2024

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.