Putting an LLM next to a Siemens TIA Portal project in 2026 means picking one of two routes. I picked six tools that have public pages you can actually check: four can write LAD, only three can run a test — and counting LadDoc next to TiaLink is what gets LAD to four.
How this was checked. Five of the six entries come from vendor pages read on 2026-10-02 and 10-25; the TiaLink row comes from its own product docs and hands-on use. Every cell a vendor does not state explicitly is marked "not stated" — that is not the same as "missing", and only someone who has installed the thing can tell the difference.
1. Two routes: whose model is it
Everything on this list falls on one line.
Route A — a purpose-built agent. The model is fixed, TIA knowledge is baked in, it works out of the box. You describe the job, review the result, sign off. You never pick a model and never touch MCP.
Route B — your own agent plus a tool. You choose the brain: Claude Code, Codex, Cursor, whatever. The tool layer only supplies hands — read blocks, edit blocks, compile, run a simulation. The tool can be an MCP server, an HTTP API, or a command-line program; the wiring changes, the route doesn't.
| Who supplies the model | What you have to do | The cost | |
|---|---|---|---|
| A · purpose-built agent | The vendor | Describe, review, sign | Model is not swappable; offline and intranet use is the vendor's call; switching clients means starting over |
| B · your agent + a tool | You | Install the tool, configure the client, write prompts, define acceptance | Free choice, but you own both the tool quality and the model quality |
A sells an outcome; B sells a capability. That single sentence decides everything downstream: do you want an assistant that hands back finished work, or a set of tools you can wire into your own pipeline?
2. Six tools, split by route
| # | Tool | Route | Form | Versions | Model |
|---|---|---|---|---|---|
| 1 | Siemens Industrial Copilot | A | In-product add-in | Recent TIA Portal | Vendor, fixed, cloud |
| 2 | Siemens Eigen Engineering Agent | A | In-product add-in | V19 U5+ / V20 U4+ / V21 | Vendor, fixed, cloud only |
| 3 | AnyAutomation Studio | A | Desktop IDE | V15–V21 | Your own key, fully local possible |
| 4 | Coilmind | A | Desktop client | V17–V21 | Included, own key optional, local supported |
| 5 | T-IA Connect | B | REST + MCP | V17–V21 | Your own key or a local model |
| 6 | TiaLink | B | HTTP MCP | V19–V21 | Any MCP client, local or national models |
Four A, two B. The split is not accidental: A sells convenience, so it bundles model and knowledge; B sells connectivity, so it hands the model back to you.
What is not in the table, and why: the open-source side has plenty of projects, but they stop at primitives plus generation and leave verification to you; and pasting code into a browser chatbot is not a route at all — it cannot reach the project.
A1: vendor agents — deepest, least free
Eigen is the April 2026 generation: an add-in that talks to the project directly, emits SCL and LAD, generates test and validation logic, and also covers HMI scripting, drives and axes, PROFINET topology, and bulk hardware import from a spreadsheet. It coexists with the 2023 chat-style Industrial Copilot rather than replacing it — one answers a question inside TIA Portal, the other finishes the job.
Its boundaries are all in Siemens' own documentation: fixed model, cloud only, S7-1200 and S7-1500 only, no older TIA versions, not approved for fail-safe programming, and no documented source-control integration. Those are not defects; they are the product definition — it guarantees behaviour Siemens has certified, not whatever model you want.
Locking the model has a rationale: in industrial software the hard part is not getting an LLM to write code, it is making the result accountable — who verified it, on which version, against which test cases. Fixed model plus a certified behaviour envelope is the shortest path to a closed responsibility chain. The price is that you cannot swap in a model you fine-tuned, and cannot wire generation into your own pipeline.
Deepest integration and least freedom, in the same product. If your work is standard TIA Portal, it is the cheapest path; if you need your own agent, your own model, or your own CI, it was never designed to leave you a door.
Siemens' own launch visual for Eigen (April 2026). The form factor of this generation: a plug-in plus cloud, with the engineer still at the desk.
A2: third-party purpose-built clients
This group is not tied to a vendor. It ships its own model and its own TIA knowledge, and sells "install it and work".
AnyAutomation combines an engineering IDE with an agent: versions all the way back to V15, local models (Ollama, LM Studio) as first-class options, SCL unit tests on PLCSIM Advanced, and a diff you approve before anything is imported. Coilmind covers every block type except F-blocks, documents its simulation testing down to PLCSIM Advanced V3–V6, and also lets you swap in your own key.
AnyAutomation Studio. The line on the right says what this category sells: 12 of 12 test cases passed on PLCSIM Advanced — the verification result is on screen, not in the marketing copy.
The smart part of this group is that it separates the two choices: the model can be yours, the client and the engineering surface stay theirs. You swap the brain, not the hands.
A category-wide trait: these tools are thick by construction — context, generation and verification arrive bundled, and you have no thinner option. Thin-versus-thick only becomes a real choice on route B.
B1: three ways to wire a tool, not one
"Does it support MCP?" answers nothing. MCP is only one of the wirings.
| Wiring | Who works out what tools exist and what arguments they take | What comes back | Fits |
|---|---|---|---|
| MCP (local process) | The protocol describes itself; the client reads the tool list and schemas | Structured results | One person, one machine, one client |
| MCP (HTTP endpoint) | Same, but the service lives independently of the client | Structured results | Several clients, scripts, CI sharing one service |
| HTTP API / CLI | You, or the agent reading documentation | Usually text or a JSON string | Gluing onto existing systems, throwaway scripts |
The difference is who is responsible for explaining the tool list and its parameters: with MCP the model reads it, with HTTP and CLI somebody has to write it down, otherwise the model guesses arguments — which is where hallucinations usually start. CLI has an underrated advantage: no service to install, no client config to edit, any agent with a shell can use it. The price is that arguments have to be assembled correctly every single time, and there is no state to carry between calls.
Verification splits into two levels, and they get conflated constantly. Unit verification checks what one block or one stretch of logic does for a given set of inputs — fast, no full hardware configuration, a hundred scenarios in a row. Whole-machine verification checks whether the entire project comes up on a virtual CPU: how OBs are scheduled, how the I/O image updates, how blocks call each other, how the HMI behaves. The first is cheap, the second is real. They are not alternatives; they are two rungs of the same ladder.
How the two B-route tools split across those rungs:
| Unit verification | Whole-machine verification | Where context comes from | |
|---|---|---|---|
| T-IA Connect | Test harness (running on PLCSIM) | Not stated | Project reports and dependencies |
| TiaLink | Its own engine, no TIA Portal required | PLCSIM | Built-in project knowledge graph |
Same task, different rung and different data source — which decides what the tool can answer for you.
B2: the two thick ones
T-IA Connect is the broadest in surface area: blocks and snapshots, project reports, a test harness, version management, several hundred tools exposed to an agent, V17 through V21, both REST and MCP. Its approach is to build the engineering platform first, then let an agent connect to it.
T-IA Connect's first screen. "100% on-premise" is a deliberate first-screen claim — that is the first dividing line between this class and cloud offerings.
TiaLink takes the other path: primitives, generation and whole-machine verification in one endpoint on the same machine — bulk import/export, generate SCL and compile, bulk HMI screen generation, start PLCSIM and run a test, then read the project back. Project-level context lives in the gateway as a knowledge graph; LAD generation is handled by another endpoint in the same product line, on purpose. Section B3 explains why.
Wiring matters a second time here: a local-process gateway lives inside the client process, so closing the client kills the connection and switching clients means reinstalling; an HTTP endpoint runs on the same machine as TIA Portal and can serve Claude Code, Codex, your own scripts and a CI job at once, without fighting each other; a CLI is the lightest, but stateless — every call reconnects to the project.
A gateway is a hand. The capability layer is an eye. With only a hand you have to trust what the AI says; with an eye you can look.
B3: why three endpoints instead of one program
Compressing each vendor into one table row creates a false impression: that "thick" means "everything stuffed into one binary".
Split, it is clearer. Producing a LAD block that TIA Portal will import, and running that logic to see if it behaves, are two different jobs: the first is deterministic generation (the same description always produces the same XML, identifiers and wiring assigned automatically, no output at all if validation fails), the second is deterministic execution (same program, same inputs, same result, every time). Written as one program, both get worse.
So the line is three endpoints, not one program:
| Endpoint | What it does | When you reach for it |
|---|---|---|
| Engineering operations (TiaLink, with the project knowledge graph inside) | Read the project, create and edit blocks, bulk import/export, compile, run PLCSIM, read back after writing; the graph answers "who calls whom, what breaks if I change this" | TIA Portal is installed and you are changing a real project |
| LAD generation (LadDoc Cloud) | JSON ladder description → validation → SimaticML block, importable as-is | A description has to become an importable block |
| Unit verification (cloud simulation) | Executes one block or one stretch of logic scan by scan — scripted cases, exhaustive matrices, seeded fuzzing, invariants | Behaviour check right after a change; no TIA Portal on the machine; batch regression |
All three are MCP, all three are callable by the same agent, and each works alone.
The graph deserves its own paragraph. In most tools "context" means the project tree plus a block list — the AI knows which blocks exist, not how they interlock. The project knowledge graph parses an exported project into a queryable model: who calls whom, which network reads or writes which tag, how a signal flows from a physical input to its consumers, which call sites an interface change reaches (transitive, not one hop), dead code, and the classic hazard of several places writing the same signal, plus fan-in, fan-out and call depth. Ask in natural language; the answer carries exact locations.
One impact graph from the knowledge graph. The question is "what does changing this block touch"; the answer is a transitive closure — call sites, instance DB, the enclosing network and OB, all the way to the block file.
It is a read-only analysis layer; edits happen on the engineering side. Analysis and execution being separate is itself a safety boundary: the thing that can tell you what a change would do has no permission to make it. It has limits, too — it works from an exported snapshot rather than a live controller, covers LAD, SCL and FBD (older languages are recognised but not analysed in depth), and excludes hardware configuration and HMI content.
One pleasant side effect of the split: people without TIA Portal can see results first. An unfinished block goes to the cloud engine, comes back passing, and only then travels to the machine that has TIA Portal. The reverse holds as well: when an import fails, go back to the generator and read the validation report instead of poking at TIA Portal.
The cloud engine verifies the unit, not the machine: it executes one ladder rung or one SCL program scan by scan — contacts, coils, timers, counters, edges, block calls, jumps — with scenarios that can be scripted cases, exhaustive matrices, seeded fuzzing, or invariants, returning PASS/FAIL in one call. It does not replace PLCSIM: PLCSIM checks whether the whole project comes up on a virtual CPU (OB scheduling, I/O image, inter-block calls, HMI), and that step still needs TIA Portal.
Once separated, the value is obvious: unit verification is cheap enough to run after every block edit; whole-machine verification is expensive enough that it only happens at milestones. Without the cheap rung, every AI edit waits until you have time to open TIA Portal.
What each route struggles with
A's problem in China's plant networks is connectivity: the model lives in a vendor cloud, and the internal network either has no route or needs an approval. That is compliance, not capability, and the bigger the plant the harder it gets. B's problem is scaffolding: a thin wrapper gives you a hand and nothing else — context and acceptance criteria are yours to build. The same route can go smoothly or end in "the AI writes worse code than I do"; the difference is usually not the tool but whether you have an acceptance process (section 6).
3. Of six, four can write LAD and three can run a test
The two numbers are not ratings; they are structural. LAD requires a structured description — element identifiers, wiring, branches, ordering — so one wrong identifier kills the whole import. Plenty of tools write SCL; only four write LAD, and LadDoc makes five. Testing requires an interface to a simulator, downloading the block, feeding inputs and reading results; three tools have that whole chain (AnyAutomation, T-IA Connect, Coilmind), and TiaLink makes four.
Siemens' Eigen says it "generates test and validation logic"; whether that executes on a simulator disagrees across two public sources, so it is not counted.
All three of those run PLCSIM Advanced, which means whole-machine verification and a Windows box with TIA Portal installed. Exactly one tool here can do unit verification of a single block without TIA Portal: TiaLink. Why that rung deserves its own column is in B3.
Generating is the entry ticket; verifying behaviour is what counts as integration.
4. "Wiring AI up" and "integrating AI" are two different things
There is a near-miss worth naming: OPC UA or Modbus can also "connect AI to TIA Portal" — but that path only exposes runtime data: tag values, registers, alarm bits. An AI that sees tag values still cannot see program blocks, cross-references, or compile errors, so it cannot change a program.
The test is simple: if the AI can see blocks and trigger a compile, that is integration; if it only sees values, that is data collection. You want both eventually, but never confuse them — one of them cannot fix a bug in an FB.
5. Building your own tool: five traps
Whether you install an existing tool or write your own, these five arrive within the first two days. None of them depends on your language or framework; they come from how TIA Portal is built.
One: a version upgrade splits the assemblies. The single engineering assembly of earlier versions was split — as of V21 — into base, PLC, HMI and safety assemblies in a new subfolder. A PLC-only tool must reference both base and PLC; namespaces are unchanged, but reference lists and runtime resolution paths are not.
Two: Copy Local has to be off. Copying the assemblies next to your binary fights the copy TIA Portal already has loaded — at best a load failure, at worst strange behaviour. Reference them, do not copy them.
Three: resolve assemblies by name at runtime. Since you are not copying, the program has to register a resolver before it touches any engineering type, looking assemblies up by simple name in the TIA Portal install directory.
Four: build once per major version. The binaries are not compatible across versions; one build, one version.
Five: default to a preview mode and return structured results. Writes should simulate first and only commit when explicitly allowed; and what comes back to the model should be structured data, not log text — logs invite the model to guess what happened.
Each of these costs half a day to two days. Together they are the real price of "build it yourself": not the install, but redoing it every time a version ships.
6. Acceptance: zero compile errors is only layer one
The most misleading sentence after an AI writes code is "it compiles". Five layers, each proving something different:
| Layer | Proves | Cannot prove |
|---|---|---|
| Structural validation (pre-import) | Syntax is valid, names do not collide | Whether the logic is right |
| Compile | Types, references, addresses, instruction usage | Behaviour across scan cycles |
| Unit verification (one block / one stretch) | Behaviour for given inputs, edges, counting, interlocks | How blocks interlock, how OBs schedule, how the I/O image updates |
| Whole-machine verification (PLCSIM) | The project comes up on a virtual CPU; scheduling and I/O image hold | Real I/O and field disturbances |
| Read-back comparison | What is in the project equals what you think you wrote | Whether the requirement itself is right |
The middle layers are the ones people skip, and they are the valuable ones.
A real example: during a refactor an impulse timer became an on-delay timer. Compile: 0 errors, 0 warnings. The code looked entirely normal. Under unit verification the motor simply would not turn — the difference was one instruction name, and the compiler cannot object because both are type-correct. After reverting, the same program passed 5,735 scans.
That is why "it compiles" is not a delivery criterion. It catches wrong types and wrong addresses; it cannot catch wrong semantics — and in control engineering the errors that hurt are almost always semantic.
Zero compile errors proves it looks like a program. Unit verification proves it means what you think. Whole-machine verification proves it still works once installed.
7. Choose by the work in front of you
| Your situation | Route | Why |
|---|---|---|
| Standard TIA Portal workflow, want vendor backing | A1 (Eigen) | Deepest integration, vendor support when it breaks |
| Want out-of-the-box, but your own model | A2 (AnyAutomation / Coilmind) | The client is theirs, the model can be yours |
| Need Git, CI, test reports | B (T-IA Connect) | Version management and a test harness are part of the product |
| Already have an agent, just need hands | Build your own (section 5) | Light, hackable, no network needed |
| Need to know "will this change break another block" | The thick B side (with a knowledge graph) | A thin wrapper has no call graph or data flow to query |
| On-site network cannot reach a cloud | A2 with local models, or the thick B side | Model runs on the machine, the project never leaves it |
| Projects on V17 / V18 | A2 (goes back to V15) or the B side | The vendor agents do not cover older versions |
| Want to verify logic before TIA Portal is installed | Unit verification (cloud) | A single block can return PASS/FAIL without an engineering box |
8. Three boundaries
Fail-safe programs are off limits. Siemens' own documentation excludes F-programs; third-party tools should not go further. Responsibility for F-program validation sits with people and the certification process.
Versions are hard-bound. A tool supports the versions it says it supports. Older projects either get their logic verified in simulation first, or need a route with a wider version range.
Write protection belongs in the process, not in a warning. Preview before write, read back after write, snapshot before bulk changes — those three do more than any "please be careful" notice.
9. Four questions that come up
Does TIA Portal need anything extra enabled? Yes. Openness — the interface that can read and write the project — is not on by default. It must be selected during installation, and the Windows account running the tool has to be in the Siemens TIA Openness group. Without both, nothing connects, and the error will not tell you why.
Does it need internet access? Depends which part. Engineering operations do not: the model can run locally and the gateway sits on the same machine as TIA Portal, so the project never leaves it. LAD generation and cloud simulation are online services — useful when there is no TIA Portal yet, or when a batch needs regression. Vendor agents are cloud inference, so connectivity is a hard requirement.
Once a gateway is installed, can the AI change programs? It can — but do not start there. Let it read only for a week: read blocks, read cross-references, read compile errors, answer questions. When its understanding survives your spot checks, enable writing, and make preview and read-back part of the process.
Can AI-written ladder logic be downloaded to a real machine? Not directly. Even after all five layers, on-site work is only the first small step of the last one: simulate, dry-run, single machine, then commissioning. That order has nothing to do with whether AI wrote the code.
Sources
- AI tools for TIA Portal compared: who writes LAD, who tests, who runs offline, svghmi.pro, checked 2026-10-02
- Best AI for PLC Programming 2026: 9 Tools Compared, anyautomation.ch, 2026-10-25
- Building a Siemens TIA Portal MCP Server on Openness V21: A Hands-On Guide, controlbyte.tech, updated 2026-10-29
- Siemens Eigen Engineering Agent launch and product pages (version range, cloud-only constraint, fail-safe boundary)
Vendor pricing and licensing change fast, so this piece lists billing models rather than amounts. "Not stated" means the vendor's public pages do not say; it does not mean the capability is absent.
What this comparison adds
The two routes are not "new tool versus old tool"; they are two ways of selling. A sells an outcome, B sells a capability — and inside B, thickness varies by an order of magnitude. The open-source projects stop at primitives or generation: light, fast, offline-friendly, but with no cross-reference data and no verifier, so they can change things without being able to tell you what the change breaks.
The thicker approach is to split the work into three callable endpoints: engineering operations (with the project knowledge graph inside), LAD generation, and unit verification. Each has its own determinism — the same description always produces the same XML, the same project parses to the same graph, the same program with the same inputs always gives the same result — so each can be accepted on its own and still be chained by one agent.
Context is where the spread is widest: exactly one of the six offers a program-level graph instead of a project tree and a block list. And that graph is read-only, with edits happening on the engineering side: the thing that can tell you what a change would do has no permission to make it.
Selection advice, in reverse order of how people usually ask: first ask whether your model can stay on your machine, then whether you can see and verify what the AI changed, and only then how good its generated code looks. The first two decide whether you can deploy at all; the last one only decides how pleasant it is.
Three entry points: TiaLink (engineering operations, V19 / V20 / V21, same machine as TIA Portal); LadDoc Cloud (LAD generation, produces importable blocks); cloud simulation (run ladder and SCL scan by scan without TIA Portal). Cross-references and call relationships are queried inside the engineering endpoint.
Top comments (0)