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 safety-code boundary in a GuardLogix 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. Two of the largest PLC vendors 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. A long engineering conversation therefore loses its early instructions, 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.

Siemens announced its Industrial Copilot in an April 2024 press release, stating that it provides automated code generation in Structured Control Language (SCL), that the TIA Portal engineering framework can take the code suggestion directly from the AI without copying and pasting, and that the copilot can explain SCL code blocks, help create an initial machine or plant visualization in WinCC Unified, and search Siemens manuals in natural language. The release stated availability from the Siemens Xcelerator marketplace starting in summer 2024.

Neither source claims that a copilot delivers a finished, validated control program. What they document is a drafting and explanation aid that sits inside the vendor's tool, with the engineer still accepting, placing, testing, and downloading 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. The fourth edition, IEC 61131-3:2025, was published in May 2025 and runs to 518 pages. It defines four languages:

  • Structured Text (ST), a textual language
  • Ladder Diagram (LD), a graphical language
  • Function Block Diagram (FBD), a graphical language
  • Sequential Function Chart (SFC), graphical and textual elements for organizing program sequences

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 relative to the prior edition.

The documented copilots do not cover all four languages. 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. That 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, are often 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.

The target controller's own rules narrow the choice further. In a GuardLogix safety controller, the safety reference manual states that only ladder diagram is supported in the safety task and that safety routines can only be written in ladder logic, so a structured-text draft cannot be dropped into a safety routine at all (IEC 61131-3:2025, Ed. 4, abstract and Annex B; Rockwell Automation 1756-RM012J-EN-P-2025, Ch. 6, pp. 47 and 50).

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

The most important sentence on the FactoryTalk Design Studio Copilot page is its 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 limit that applies to everything the Copilot produces: it may display inaccurate information, and the user is directed to the FactoryTalk Design Studio online help to verify its responses. Taken together, the two statements define three zones for a controls engineer:

  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 therefore 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).

Why is safety code a hard boundary inside a GuardLogix controller?​

The controller architecture enforces the separation the Copilot documentation describes. Rockwell's GuardLogix 5580 and Compact GuardLogix 5380 safety reference manual rates a GuardLogix 5580 primary controller with a safety partner for use up to SIL 3 under IEC 61508 and up to PLe, Category 4, under ISO 13849-1, and a primary controller without a safety partner up to SIL 2 and PLd, Category 3. To hold those ratings, the manual sets several structural rules:

  • Only the safety task, not standard tasks, can be used for safety functions.
  • A safety program can contain only safety components; it cannot contain standard routines or standard tags.
  • Safety routines cannot read or write standard tags, and only safety-certified instructions, or Add-On Instructions composed from them, are used in safety routines.
  • Standard data reaches the safety task only through safety tag mapping, which copies standard tag values into safety task memory at the beginning of the safety task and can increase safety task scan time.

The safety signature ties those rules to change control. The manual describes it as a unique 64-character identification number that applies to the entire safety portion of the project, states that nothing in the standard application is included in it, and requires it for the controller to operate at a SIL 2 or SIL 3 rating; operation without a safety signature is only suitable during development. When the controller is safety-locked or a safety signature exists, the programming software blocks creating or modifying safety programs, routines, tags, safety AOIs, and safety I/O devices, as well as creating or changing tag mappings. A copilot that drafts standard logic works on the side of the project the signature does not cover, which is why standard-side edits must still be checked for their effect on timing and tag mapping into the safety task (Rockwell Automation 1756-RM012J-EN-P-2025, Ch. 1, pp. 8–9; Ch. 2, p. 16; Ch. 6, pp. 47–53).

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

The validation obligations in a safety controller do not change because a copilot drafted part of the program. Rockwell's safety reference manual sets out what project validation must include:

  • A suitable set of test cases covering the application, filed and retained as the test specification
  • Tests that prove the validity of formula calculations used in the application logic, for which equivalent range tests (within the defined value ranges, at the limits, or in invalid value ranges) are acceptable
  • Active simulation with field devices, which the manual describes as the only way to verify that sensors and actuators are wired correctly
  • Tests of the reaction to wiring faults and network communication faults, and tests of fault routines and input and output channels

For edits, the manual requires that all program changes be documented with authorization, impact analysis, execution, test information, and revision information. Online edits that exist only in standard routines are not required to be validated before returning to normal operation, but the engineer must confirm that changes to standard routines regarding timing and tag mapping are acceptable to the safety application. Offline edits to the safety program require revalidation of all affected elements, as determined by the impact analysis, before operation resumes, and the manual notes that IEC 61508 requires an impact analysis before modifying components in a certified functional safety system.

The practical rule for AI-drafted logic follows directly: treat each accepted copilot suggestion as a change with its own record in that five-part change log, and run the boundary-value and fault-reaction tests against the drafted routine the same way as for hand-written code. The Safety Signature report can show which safety elements changed, which confirms that a standard-side copilot edit left the signed safety portion untouched (Rockwell Automation 1756-RM012J-EN-P-2025, Ch. 8, pp. 69–70 and 75–76).

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, but its four functions 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 the safety task and motion tuning
  • Measure: how drafted code is tested, for example the boundary-value and fault-reaction test cases a safety manual already requires
  • 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 scope covers the properties, related risk factors, and available methods and processes for three distinct 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.

A PLC code copilot falls in the third category. The report's framing makes the point that using AI as a development tool is a different risk case from putting AI inside the safety function, but it does not remove 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 sets the general principles for risk assessment and risk reduction in machinery design. A copilot does not perform or replace the risk assessment.
  • ISO 13849-1:2023 covers the general principles for the design of safety-related parts of control systems. The safety functions it governs are the ones the Rockwell Copilot is documented not to modify.

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, and the Machinery Directive, Directive 2006/42/EC, is repealed with effect from the same date. For AI, its most significant provision is in Annex I Part A. 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 is not available.

The distinction the regulation draws is between behaviour that evolves through machine learning and behaviour that is fixed. Its recitals state that the third-party conformity assessment provisions for software ensuring safety functions apply only to systems with fully or partially self-evolving behaviour using machine learning, and not to software that cannot learn or evolve and is programmed only to execute certain automated functions. 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 for at least 10 years and, where relevant, to make the source code or programming logic it contains available to national authorities on a reasoned request. OEMs shipping heavy handling equipment into the EU should therefore be able to trace every safety function to validated, fixed logic, however that logic was drafted.

The failure mode to plan for is a machine design that places a learning model, such as a vision classifier, 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).

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 and GuardLogix 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, communications run on a separate core and do not interrupt the user task, and in a GuardLogix 5580 the same Logix engine that runs the user program and motion task also executes the safety 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 two tasks at the same priority are triggered together, 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.

Those rules 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; a heavy routine added at a high priority delays every lower-priority task on the controller; and adding standard tags to safety tag mapping, to feed a drafted routine's data into the safety task, can increase safety task scan time. 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; Rockwell Automation 1756-RM012J-EN-P-2025, Ch. 6, p. 53).

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. 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.

On heavy handling equipment the stored energy is often 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. Energy control procedures under 1910.147 rely on physical isolation, lock and tag application, and release or restraint of stored energy.

IEC 60204-1:2016 sets the general requirements for the electrical equipment of machines, the layer on which the PLC, drives, and safety circuits are built; 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; IEC 60204-1:2016).

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 tasks, and condition monitoring that trends motor current, temperature, and vibration. A copilot touches only part of that stack:

  • 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 the safety manual says can only be verified by active simulation with field devices.

That split follows the signature chain. 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. 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 1756-RM012J-EN-P-2025, Ch. 8, p. 69; 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-RM012J-EN-P-2025: GuardLogix 5580 and Compact GuardLogix 5380 Controllers Safety Reference Manual. Rockwell Automation, 2025.
  • 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.
  • OSHA 29 CFR 1910.147-1989: The Control of Hazardous Energy (Lockout/Tagout). Occupational Safety and Health Administration, 1989.
  • IEC 60204-1:2016 (Ed. 6.0): Safety of Machinery -- Electrical Equipment of Machines -- Part 1: General Requirements. International Electrotechnical Commission, 2016.

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