Skip to main content

Can Generative AI Write PLC Code? Copilots and Their Documented Limits

Generative AI copilots can now draft PLC routines inside the vendors' own engineering tools, but the vendors' documentation is explicit about what those copilots may not touch and who remains responsible for the result. UTEC Industrial designs, engineers, machines, fabricates, and installs custom material handling systems for aerospace and heavy industry from its Spokane Valley, WA facility, integrating Allen-Bradley PLC and motion control with in-house CNC machining, heat treating, and stress relief. This article sets out what the Rockwell Automation and Siemens copilots are documented to do, the boundary between safety code and standard code in the controller, the validation and change-control steps that AI-drafted logic still has to pass, and the standards and regulations that frame AI near safety functions. On a heavy handling system the controls sit near the end of one chain, design → engineering → parts machining → fabrication → assembly → weld fatigue → stress relief → drives → controls → tuning → monitoring, so a copilot changes how one link is drafted, not what the links before and after it demand.

Can generative AI write PLC code today?​

Yes, within limits the vendors publish. Rockwell Automation and Siemens now ship generative AI assistants inside their engineering environments, and both are documented to generate controller code rather than only answer questions about it.

Rockwell Automation's FactoryTalk Design Studio Copilot is described in the product's online documentation as a tool that can query help content, release notes, and error-code documentation, search a project, and generate code. Its documented prompt patterns include creating an Add-On Instruction (AOI) with a named function and creating routines in Ladder Diagram (LD), Structured Text (ST), or STX. The same page sets hard edges on that capability: project search and code generation are exclusive to Core entitlement users and must be enabled, and the Copilot's conversational context is limited to the 5 most recent prompts and responses at the Basic level or the 10 most recent at the Core level. As engineering reasoning, a long engineering conversation can fall outside that window, which is a practical reason to restate constraints such as tag naming, task placement, and I/O addressing in each prompt rather than assume the copilot remembers them.

In an April 2024 press release, Siemens described the new Siemens Industrial Copilot for TIA Portal Engineering, stating that its features include automated code generation in Structured Control Language (SCL) and that the TIA Portal engineering framework can take the code suggestion directly from the AI without copying and pasting. The release also stated that the copilot can explain SCL code blocks, guide and create an initial machine or plant visualization in WinCC Unified, and let engineering teams search Siemens manuals in natural language. The release stated that it would be available for download from the Siemens Xcelerator marketplace starting in summer 2024.

Neither source claims that a copilot delivers a finished, validated control program. What they describe is a drafting and explanation aid that sits inside the vendor's tool; as engineering reasoning, the engineer still accepts, places, tests, and downloads the result (Rockwell Automation 2026, FactoryTalk Design Studio Copilot, undated web documentation, accessed September 2026; Siemens 2024, Industrial Copilot press release).

Which PLC languages do copilots write, and how does IEC 61131-3 define them?​

The programming languages a copilot outputs into are defined by IEC 61131-3, which specifies the syntax and semantics of programming languages for programmable controllers as defined in IEC 61131-1. The fourth edition, IEC 61131-3:2025, was published in May 2025 and runs to 518 pages. Its abstract describes a unified suite of three languages and one additional set of elements:

  • Structured Text (ST), a textual language
  • Ladder Diagram (LD), a graphical language
  • Function Block Diagram (FBD), a graphical language
  • Sequential Function Chart (SFC), an additional set of graphical and equivalent textual elements for structuring the internal organization of programs and function blocks

The edition's listed technical changes include the addition of UTF-8 strings and their associated functions, and an Annex B that lists the features added, removed, or deprecated in comparison to IEC 61131-3:2013.

The documented copilots do not cover everything the standard defines. The Rockwell documentation lists routine creation in LD, ST, or STX; the Siemens release describes code generation in SCL. Neither source documents FBD or SFC generation. The rest of this paragraph is engineering reasoning. The gap matters on material handling equipment because sequence-heavy machines, such as a transfer car that indexes between furnace, quench, and unload stations, or a positioner that steps through weld orientations, can be structured as sequential logic. An engineer who wants a copilot's help on that sequence has to work in a language the copilot is documented to write and then verify that the result preserves the state-machine behavior the specification calls for (IEC 61131-3:2025, Ed. 4, abstract and Annex B; Rockwell Automation 2026, FactoryTalk Design Studio Copilot, undated web documentation, accessed September 2026; Siemens 2024, Industrial Copilot press release).

What does Rockwell's documentation say the Copilot cannot do?​

The Safety Support section of the FactoryTalk Design Studio Copilot page states the safety limit: the Copilot can explain, but cannot modify, safety-related PLC code and device configuration. That is a documented boundary set by the vendor, not a best practice an integrator has inferred.

The same page carries a second, general limit: the Copilot may display inaccurate information, and the user is directed to the FactoryTalk Design Studio online help to verify its responses. The three zones below and the closing failure-mode sentence are engineering reasoning from those two statements, not the page's own structure:

  1. Safety-related code and device configuration. The Copilot may explain existing logic, which can help a reviewer understand an inherited program, but it does not modify it. Changes stay with qualified people working through the controller's safety change process.
  2. Standard logic. The Copilot can generate routines and AOIs, but the output carries the vendor's own warning that it may be inaccurate, so every line is a draft until reviewed and tested.
  3. Reference questions. Answers about instructions, error codes, and release notes are also subject to the inaccuracy warning and should be checked against the cited help topic before they drive a design decision.

The failure mode these two statements point to is not a copilot silently rewriting a safety routine, which the tool is documented not to do, but an engineer accepting inaccurate standard logic or an inaccurate explanation without verification (Rockwell Automation 2026, FactoryTalk Design Studio Copilot, undated web documentation, accessed September 2026).

The FactoryTalk Design Studio Copilot page states that the Copilot can explain, but cannot modify, safety-related PLC code and device configuration, so the vendor keeps modification of the safety portion of a project out of the copilot's reach. Safety functions such as the emergency stop and guard interlocks can be realized by safety-related parts of control systems designed to ISO 13849-1:2023, which specifies a methodology and provides related requirements, recommendations and guidance for the design and integration of safety-related parts of control systems that perform safety functions, including the design of software, in high demand and continuous modes of operation. ISO 12100:2010 specifies principles of risk assessment and risk reduction and describes procedures for identifying hazards and estimating and evaluating risks; that is the process through which the hazards those functions address are identified.

As engineering reasoning, a copilot used on standard logic works outside the safety-related code the vendor bars it from modifying. What still needs checking is how drafted standard logic interacts with the rest of the program, such as its task placement, priority, and timing, which the controller's task and scan model governs, as covered below (Rockwell Automation 2026, FactoryTalk Design Studio Copilot, undated web documentation, accessed September 2026; Rockwell Automation 1756-RM094N-EN-P-2025; ISO 13849-1:2023; ISO 12100:2010).

How should AI-drafted PLC logic be validated before it runs a machine?​

The validation obligations on a machine do not change because a copilot drafted part of the program. Rockwell's Copilot documentation warns that the Copilot may display inaccurate information and directs the user to the FactoryTalk Design Studio online help to verify its responses. The same documentation states that the Copilot cannot modify safety-related PLC code and device configuration.

The rest of this answer, up to the NIST pointer, is engineering practice rather than a requirement of the Copilot documentation. Every accepted suggestion remains a draft until it has been reviewed and tested; drafted logic belongs on the standard side of the project, and any change to the safety-related side stays with qualified people working through the machine's safety change process. Each accepted copilot suggestion can be treated as a change with its own record: who accepted it, what it changed, and how it was tested. The same practice tests the drafted routine against the project's test specification in the same way as hand-written code, including boundary values and the machine's reaction to wiring and communication faults, and records the result before the program returns to operation. The NIST framework covered next gives a controls group one way to structure those decisions (Rockwell Automation 2026, FactoryTalk Design Studio Copilot, undated web documentation, accessed September 2026; NIST AI 100-1, 2023, AI RMF Core functions).

How does the NIST AI Risk Management Framework apply to an engineering team using a copilot?​

NIST AI 100-1, the Artificial Intelligence Risk Management Framework (AI RMF 1.0), was released on January 26, 2023. NIST describes it as intended for voluntary use, to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. Its core is organized into four functions: Govern, Map, Measure, and Manage.

The framework does not prescribe PLC practices. The mapping below, and the scope-creep failure mode after it, are this article's engineering application of the four functions, not NIST's text. They give a controls group a structure for deciding how a copilot is allowed into the workflow:

  • Govern: who is authorized to accept AI-generated code, and which projects allow it at all
  • Map: which parts of a program are in scope, for example standard-task HMI status and alarm-text routines, and which are out of scope, such as safety-related code and motion tuning
  • Measure: how drafted code is tested, for example the boundary-value and fault-reaction test cases in the project's test specification
  • Manage: how accepted suggestions are tracked, reverted, and reviewed after commissioning

One failure mode this structure can guard against is scope creep: a copilot first used for alarm text gradually drafts interlock logic without anyone deciding it should. Writing the Map boundary into the project's controls specification turns that decision into a reviewable line item rather than a habit (NIST AI 100-1, 2023, AI RMF Core functions).

Can AI be used inside or around a safety function at all?​

The standards bodies have started to address this question, but only at the level of guidance. ISO/IEC TR 5469:2024, Artificial intelligence — Functional safety and AI systems, is a technical report rather than a requirements standard. Its abstract says it describes the properties, related risk factors, and available methods and processes relating to three uses: AI used inside a safety-related function to realize that function; non-AI safety-related functions used to ensure safety for AI-controlled equipment; and AI systems used to design and develop safety-related functions.

The next three sentences are engineering reasoning, not the report's text. A PLC code copilot falls in the third category. Listing the uses separately sets AI as a development tool apart from AI inside the safety function, and nothing in that abstract removes the obligations of the functional safety standards the finished system is built to. The two machinery standards that frame those obligations stay in force regardless of how the code was drafted:

  • ISO 12100:2010 specifies basic terminology, principles and a methodology for achieving safety in the design of machinery, including principles of risk assessment and risk reduction. A copilot does not perform or replace the risk assessment.
  • ISO 13849-1:2023 specifies a methodology and provides related requirements, recommendations and guidance for the design and integration of safety-related parts of control systems that perform safety functions, including the design of software, in high demand and continuous modes of operation. As engineering reasoning, the safety-related PLC code that implements those functions is the code the Rockwell Copilot is documented not to modify.

As engineering reasoning, a failure mode to guard against in this area is category confusion: treating an AI-assisted development step as if it were a validated safety tool, or treating a safety function designed with AI help as if the AI's involvement changed its required performance level (ISO/IEC TR 5469:2024, scope; ISO 12100:2010; ISO 13849-1:2023).

What changes in the EU machinery rules in 2027?​

Regulation (EU) 2023/1230 on machinery applies from 14 January 2027, with some of its Articles applying from earlier dates listed in Article 54, and the Machinery Directive, Directive 2006/42/EC, is repealed with effect from 14 January 2027. Its Annex I Part A names machine learning directly. Points 5 and 6 list safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions, and machinery with embedded systems of that kind that have not been placed on the market independently, in respect of those systems only. For an Annex I Part A category, Article 25(2) requires one of three procedures: EU type-examination followed by conformity to type, full quality assurance, or unit verification. The internal production control route that Article 25(3) allows for Part B categories, where the product is designed and constructed to the category's harmonised standards or common specifications covering all relevant essential requirements, is not available. Regulation (EU) 2026/1744 (OJ 24 July 2026) amended Regulation (EU) 2023/1230 in its Articles 8, 20 and 47 and left Article 54 and Annex I unchanged. The new Article 8 text requires the Commission to adopt delegated acts amending Annex III "by adding health and safety requirements" for AI systems classified as high-risk under Article 6(1) of the AI Act, Regulation (EU) 2024/1689, "due to the fact that they are a safety component in a product covered by this Regulation, or they are themselves a product covered by this Regulation". The same text adds: "Those delegated acts shall apply by 2 August 2028."

The distinction the regulation draws is between behaviour that evolves through machine learning and behaviour that is fixed. Recital 55 states that the third-party conformity assessment provisions for software ensuring safety functions should only apply to systems with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions, and should not apply to software incapable of learning or evolving and programmed only to execute certain automated functions of machinery or related products. As engineering reasoning, a copilot that drafts deterministic ladder logic offline, which an engineer then reviews, tests, and downloads as a fixed program, produces software of the second kind. Documentation still matters: Article 10(3) requires manufacturers to keep the technical documentation and the EU declaration of conformity at the disposal of the market surveillance authorities for at least 10 years after the product is placed on the market or put into service, and, where relevant, to make the source code or programming logic included in the technical documentation available to the competent national authorities on a reasoned request, if they need it to check compliance with the essential health and safety requirements. As engineering reasoning, OEMs shipping heavy handling equipment into the EU should be able to trace every safety function to validated, fixed logic, however that logic was drafted.

Also as engineering reasoning, the failure mode to plan for is a machine design that places a learning model with fully or partially self-evolving behaviour, such as a vision classifier that keeps learning in service, inside a safety function without recognizing that this can move the product into Annex I Part A (Regulation EU 2023/1230, Arts. 10(3), 25(2), 51 and 54, recital 55 and Annex I Part A; Regulation EU 2026/1744, Art. 3).

Where does the controller's task and scan model limit copilot-drafted code?​

A copilot drafts a routine; it does not decide where that routine runs or what it does to the rest of the scan. Rockwell's Logix 5000 design considerations manual lists ControlLogix 5580 controllers as supporting 32 tasks, including continuous, periodic, and event tasks, with up to 1,000 programs per task, and event tasks triggered by consumed tags, EVENT instructions, module input data changes, and motion events. On these controllers, control and motion, communications, and packet processing each run on a separate core, and the manual states that communications handled by the communications core, which manages all Class 3 and unconnected communications, do not interrupt the user task.

The manual's execution rules set the constraints any drafted routine inherits:

  • Each periodic or event task has a priority from 1 to 15; a higher-priority task interrupts a lower one, and the continuous task has the lowest priority.
  • A project does not require a continuous task, and if one is used there can be only one.
  • If a periodic or event task is executing when another is triggered and both are at the same priority, they execute in 1 ms increments until one completes.
  • The motion planner interrupts all other tasks regardless of their priority.
  • Too many tasks can make the continuous task take too long to complete, cause other tasks to overlap, and slow controller communication.

The rest of this answer is engineering reasoning from those rules. They produce specific failure modes for drafted code. A routine written as if it runs every scan behaves differently when it is placed in a 100 ms periodic task, and a heavy routine added at a high priority delays every lower-priority task on the controller. Task placement, period, and priority are therefore design decisions the controls engineer makes and documents before any drafted routine is accepted (Rockwell Automation 1756-RM094N-EN-P-2025, Ch. 2, pp. 17 and 19, and Ch. 5, pp. 40–42).

Can a copilot-drafted software interlock stand in for lockout/tagout?​

No. OSHA's hazardous energy standard, 29 CFR 1910.147, defines an energy-isolating device as a mechanical device that physically prevents the transmission or release of energy, and states that push buttons, selector switches, and other control-circuit-type devices are not energy-isolating devices. Applying that definition, a PLC interlock, a software permissive, or an HMI "maintenance mode" is a control-circuit function, whether it was written by hand or drafted by a copilot.

As engineering reasoning, on heavy handling equipment the stored energy can be large and not electrical: a raised lift table held by hydraulic pressure, a transfer car parked on a grade, a counterweighted door on a heat-treat furnace, or a rotating drum with residual momentum. None of these is made safe for maintenance by logic that tells the drive not to move. The energy control steps in 1910.147(d) are physical isolation of the machine from its energy sources, application of lockout or tagout devices to the energy isolating devices, relief or restraint of stored energy, and verification of isolation.

IEC 60204-1:2016+AMD1:2021 applies to the application of electrical, electronic and programmable electronic equipment and systems to machines not portable by hand while working, the layer on which the PLC, drives, and safety circuits are built; as engineering reasoning, it frames the electrical design, not the maintenance energy-control procedure. A copilot can help document a lockout sequence or explain the logic of an existing interlock, but the physical isolation points must come from the machine's hazardous-energy analysis (OSHA 29 CFR 1910.147-1989, paragraph b, definitions, and (d)(3)–(d)(6); IEC 60204-1:2016+AMD1:2021).

What does a copilot change in the controls and sensing of heavy material handling equipment?​

The intelligence layer on a heavy handling system is built from encoders and position sensing on drives, load cells on lifts and positioners, limit and zone interlocks on transfer cars and conveyors, VFD and servo drives, PLC logic split between standard and safety-related code, and condition monitoring that trends motor current, temperature, and vibration. A copilot touches only part of that stack. The split below is engineering reasoning, except the safety-code limit, which is the Rockwell page's:

  • Where the documented tools can help: drafting standard-task routines such as alarm text, status words, recipe handling, and HMI data preparation; explaining an inherited program during a retrofit; and searching vendor documentation for instruction behavior and error codes.
  • Where the documented tools do not reach: safety-related code and device configuration, which the Rockwell Copilot is documented not to modify; drive and servo tuning, which depends on the machine's actual inertia, stiffness, and friction measured at commissioning; and sensor selection, placement, and wiring, which depend on the physical machine and its field devices.

That split follows the design-to-monitoring chain set out at the start of this article. The frame design, machining, fabrication, and stress relief determine the stiffness and alignment the drives see; the drives and controls are tuned against that physical machine; monitoring then watches it in service. UTEC Industrial builds this layer as a Rockwell Automation Recognized System Integrator on Allen-Bradley ControlLogix and CompactLogix platforms, with UL 508A panel building, factory acceptance testing, and on-site commissioning, so any drafted logic meets the same test specification as the rest of the program. As engineering reasoning, a failure mode to guard against is treating the copilot's draft as the design: a routine that compiles, but was never exercised against wiring faults, communication loss, or boundary values on the real machine (Rockwell Automation 2026, FactoryTalk Design Studio Copilot, undated web documentation, accessed September 2026).

Related Articles

References​

  • Rockwell Automation (2026). FactoryTalk Design Studio Copilot. FactoryTalk Design Studio Online Documentation. Rockwell Automation, 2026 (undated web documentation, accessed September 2026).
  • Siemens (2024). Siemens Xcelerator: Scaling roll-out of generative AI with Siemens Industrial Copilot. Press release, Siemens, 2024.
  • IEC 61131-3:2025: Programmable controllers — Part 3: Programming languages. IEC, 2025 (Ed.4).
  • Rockwell Automation 1756-RM094N-EN-P-2025: Logix 5000 Controllers Design Considerations. Rockwell Automation, 2025.
  • NIST AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, 2023.
  • ISO/IEC TR 5469:2024: Artificial intelligence — Functional safety and AI systems. ISO/IEC, 2024.
  • ISO 12100:2010: Safety of machinery — General principles for design — Risk assessment and risk reduction. ISO, 2010.
  • ISO 13849-1:2023: Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design. International Organization for Standardization, 2023.
  • Official Journal of the European Union. Regulation (EU) 2023/1230 on machinery, 2023.
  • Regulation (EU) 2026/1744: Amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 2026.
  • OSHA 29 CFR 1910.147-1989: The Control of Hazardous Energy (Lockout/Tagout). Occupational Safety and Health Administration, 1989.
  • IEC 60204-1:2016+AMD1:2021 CSV (Ed. 6.1): Safety of Machinery -- Electrical Equipment of Machines -- Part 1: General Requirements. International Electrotechnical Commission, 2021.

Ready to Discuss a Material Handling System?​

UTEC Industrial designs, engineers, machines, fabricates, and installs custom material handling systems for heavy industry, from the stress-relieved structure and drives to the Allen-Bradley PLC controls, tuning, and monitoring that run them, at its Spokane Valley, WA facility. Send UTEC the application, loads, and duty cycle to start a system review.

Request a Quote →

Questions? Call (509) 922-1832 or email sales@utec.co

Last updated on