AI in PLC Programming: What Works in TIA Portal Today

The short answer: In TIA Portal, AI can now generate blocks in SCL and FBD, compile them, check them against a functional design specification, test them in simulation and keep the documentation up to date. It becomes reliable only inside a fixed process: a functional specification agreed with the customer at the start, a test in simulation at the end. Safety-related code is written by the engineer, and a person, not an agent, always downloads to a real CPU.

This article is for buyers, project managers and maintenance managers deciding whether to hand a control project to an engineering firm that works with AI. It explains how we use AI agents in our office, where we draw firm lines, what lies behind the most common objections, and how all this differs from Siemens' Eigen Engineering Agent.

1.Chat window or toolchain: two kinds of AI for PLC programming

For most people, "AI and PLCs" means a chat window: describe a task, get SCL code back, paste it into the project. For small, self-contained functions that can be enough. For a plant program it is not. The model does not know the project, does not compile anything and does not test anything. Whether the code fits the existing data types, block interfaces and naming conventions is still left to the programmer.

The second kind is AI agents that work directly inside the engineering tool instead of handing over code from a chat window. They know the structure of the project, receive the compiler's feedback and can act on it. They work inside the project rather than next to it, and that is what turns AI from a curiosity into a usable engineering tool.

2.How we use AI agents in TIA Portal

Our AI agents work directly in TIA Portal. Every project follows the same sequence:

1. Functional specification first. Before any code is written, there is a functional design specification (FDS) agreed with you. Everything that follows is measured against it.
2. Generate and compile blocks. The agents write SCL for calculations and data handling and FBD for interlocking logic, then compile the project. If the compiler reports errors, the block goes back for rework.
3. Review against the specification. Each block is checked against the FDS: is every described function implemented, and does the code do anything the FDS does not ask for?
4. Functional test in simulation. The program runs on a simulated controller. The tests can be repeated after every change.
5. Operator-level test. Operating the HMI is checked against the simulated PLC, the way an operator will later use it: press a button, acknowledge an alarm, change a setpoint, check the response.

The HMI itself is derived from the PLC structure. Screens, alarms and tags for WinCC Unified are generated from blocks and data types, and the same applies to migrating existing Comfort Panel projects to Unified. More on this on our HMI visualization with WinCC Unified page. How we structure and hand over PLC programs is covered under PLC programming in TIA Portal, and pre-commissioning testing under commissioning and end-to-end testing.

One example of groundwork that can otherwise tie up days: from a wiring diagram in PDF form, the agents produce an I/O list and from that the TIA Portal tag table. We measured this on a 51-page diagram set, which was processed in about eleven minutes. The result is still checked against the drawings afterwards.

3.Legacy plants: re-documenting code without symbols

The biggest benefit is often not in new plants but in existing ones. Many S7-300 controllers have been running for decades on a program that survives only as an online upload: STL code with no symbols and no comments, memory bits and data blocks as bare addresses. Anyone modernising such a plant first has to understand what it actually does.

For this as-is analysis, the agents read the existing code block by block, trace signals across block boundaries and derive a functional specification from it. Here our strictest rule applies: every statement must be backed by evidence. Each claim about the plant has to point to a location in the code or in the documents. Anything that cannot be backed up goes into the document as an open question and is clarified at the plant or with the operator. The model does not fill gaps with plausible guesses.

The new program is then built from that specification, for migrations preferably in FBD and LAD, so that maintenance staff can see in online mode which condition is missing. We follow this path for control system retrofits from S5 and S7-300 as well as for CODESYS to TIA Portal migrations. What useful plant documentation should contain is described in our article on PLC documentation.

4.Guardrails: what the AI is not allowed to do

An error in a control program is not a cosmetic flaw. A contributor on the r/PLC forum put it plainly: "In our industry, a 99% success rate is a catastrophic failure." From my own commissioning work, I agree. That is why five rules apply in every project, without exception:

• No programming without a functional specification. Without an agreed FDS there is nothing to check a result against.
• Everything is tested in simulation. No block is delivered that has not been tested in simulation.
• Safety stays with the engineer. Safety-related code is written by the engineer personally and validated the conventional way.
• A person downloads to the real CPU. Loading a program onto the plant is always a deliberate human step, never an agent's.
• Evidence is mandatory on existing plants. Anything not backed up counts as open.

5.Why AI raises quality, not just speed

Discussions about AI usually revolve around saving time. For the customer, another effect often matters more: more gets checked.

More testing. In many conventional projects, much of the testing happens only during commissioning, under time pressure and on the plant. Tests in simulation, by contrast, can be repeated after every change, so something that worked once does not quietly break with a later modification.

Better groundwork. I/O lists, tag tables and alarm texts consume engineering hours that are then missing from the actual plant logic. When the agent takes over the typing, more time is left for questions that need experience: what happens on a wire break? How does the plant restart after a power failure?

Documentation that matches the program. Functional specification, program and HMI come from the same source. When the program changes, the documentation is updated in the same pass instead of being reconstructed from memory at the end of the project.

We deliberately do not put a figure on the overall time saved. We have measured individual steps such as the I/O list above. How large the effect is across a whole project depends on the plant, the available documents and the state of the existing code.

6.Buyers' objections and what lies behind them

Reservations about AI are well documented. For its study Künstliche Intelligenz 2025, the German digital industry association Bitkom surveyed 604 companies. As obstacles, 53 per cent named legal uncertainty, 48 per cent data protection, 39 per cent the fear that data could fall into the wrong hands, 38 per cent a lack of traceability and 36 per cent the quality of the results. Machine builders see it similarly: in an AI survey by the German engineering federation VDMA, 39 of 144 respondents cited legal questions such as data access and liability.

These concerns are legitimate, and they deserve concrete answers:

7.Data protection: what happens to your project data

A TIA Portal project contains the process know-how of a plant, so we work to fixed rules:

• No training on your data. Your project data is not used to train AI models.
• Our own systems, not public chat tools. Projects are stored on our own systems and are not copied into public chat tools.
• Data routes agreed before the project starts. Which documents go into AI-assisted processing and which do not is agreed with you before work begins.
• Anonymisation where possible. Company names, site names and other identifying details are removed or replaced before processing, as far as this does not get in the way of the work.
• Non-disclosure agreement on request. If you wish, we sign a non-disclosure agreement (NDA) before the project starts.

This is not legal advice and does not replace a legal review on your side. If your IT or data protection team has requirements for external contractors, that preliminary discussion is the place for them.

8.Siemens Eigen Engineering Agent: a tool, not a service

On 20 April 2026, Siemens made the Eigen Engineering Agent generally available as the successor to the Industrial Copilot for Engineering. Siemens describes it as an AI solution for PLC coding, HMI visualization and device configuration (press release). It requires TIA Portal V19, V20 or V21 and an Industry Organization Account (product page). It is licensed as an annual SaaS subscription, with one seat covering three assigned users (licensing). In Siemens' US store, a seat costs 2,100 US dollars per year (Siemens store).

For an engineering department with its own TIA Portal programmers, this can be a sensible tool. It sits in the familiar environment, comes from the PLC manufacturer and is maintained by them. It should be seen for what it is, though: a tool for people who program themselves. The functional specification, testing, acceptance and responsibility remain with the user.

Two points belong in the assessment:

• It starts at V19. Plants on S5 or STEP 7 Classic predate that. These are often exactly the plants where only an online upload without symbols exists, and the program has to be understood and rebuilt before any tool inside TIA Portal can be applied.
• A tool does not add capacity. If you have no programmers of your own, or cannot free them up for a project, you need a service, not another tool.

The two are not mutually exclusive. A plant can use the agent for small in-house changes and still contract out a larger project.

9.Five questions to ask a contractor who programs with AI

A few questions are enough to find out whether a supplier uses AI responsibly. The answers should be specific rather than reassuring:

1. Is there a functional specification, agreed with us, before programming starts?
2. How is the program tested before it goes to the plant, and which test results do we receive?
3. Who programs and validates the safety functions?
4. Where is our project data stored, does it go into public chat tools, and is it used to train AI?
5. Who downloads the program to the real PLC, and who answers for the result?

If the answers stay vague, the fixed process that makes AI output verifiable in the first place is usually missing. Questions 1, 2 and 5, incidentally, are ones any contractor should be able to answer, including one that does not use AI at all.

10.Conclusion: the process matters more than the model

AI in PLC programming is ready for practical use in TIA Portal. Whether it helps or becomes a risk depends less on the model than on the process around it: functional specification before code, simulation before the plant, safety in the engineer's hands and a person who downloads the program to the controller.

Prybisch Automation is an engineering office in Luxembourg for Siemens automation (TIA Portal, WinCC Unified, retrofits) with AI-assisted engineering, working across the Greater Region and throughout Europe. We work as one experienced engineer with a well-practised set of AI agents that takes on groundwork, testing and documentation, while decisions and responsibility stay with people.

11.Sources

• Bitkom Research: Künstliche Intelligenz 2025, survey of 604 companies (in German)
• VDMA: AI survey, 144 respondents (in German)
• Reddit r/PLC: forum thread on error tolerance in automation, an individual practitioner's view, not a study
• Siemens: Eigen Engineering Agent press release, product page, licensing and purchase and Siemens store (US)

All sources accessed on 26 October 2026.

---

About the author: This article was written by David Prybisch, owner of Prybisch Automation. Prybisch Automation is an engineering office in Luxembourg for Siemens automation (TIA Portal, WinCC Unified, retrofits) with AI-assisted engineering, working across the Greater Region and throughout Europe. David Prybisch has been programming PLCs for more than twelve years and has worked in industrial environments for 20 years. How a Siemens retrofit runs as a project is described in S5 & S7-300 retrofit to S7-1500 and WinCC Unified.