SIMATIC AX Explained: What It Is, How It Differs From TIA Portal, And How To Prepare Without A Licence

SIMATIC AX is one of the clearest signs of where Siemens wants PLC engineering to go. The more useful questions are what AX actually changes, where it still falls short of TIA Portal, and how engineers can prepare before spending serious money on it.

If you work in Siemens PLC software today, there is a good chance your daily environment is still TIA Portal. That makes SIMATIC AX easy to misunderstand. Some people assume it is just another Siemens editor. Others assume it is about to replace TIA Portal outright. Neither of those views is especially helpful.

SIMATIC AX changes the engineering model around PLC code. It pushes Siemens users toward text-first development, Git-based workflows, package management, unit tests, automated pipelines, and a much closer overlap with mainstream software engineering practice. That is a big shift, even for teams that are not planning to buy AX this year.

What SIMATIC AX Is

Siemens describes SIMATIC AX as a cloud-based engineering environment for PLC engineering with an integrated engineering editor based on Visual Studio Code. That wording tells you two things immediately. AX is a broader engineering environment rather than a simple language add-on, and Siemens is deliberately moving toward a more open, software-style engineering stack.

In practical terms, SIMATIC AX gives you a text-based development environment for building PLC software using Structured Text, object oriented constructs, packages, tests, and command line workflows. Around that core you also get AX Code, the AX command line tooling, package handling, Git-friendly project files, community resources, and an increasingly public ecosystem of examples and templates.

That means the real value of AX extends well beyond the editor window. It sits in the development model around the code. Teams can version it properly, review it properly, test it earlier, and automate more of the surrounding workflow than most are used to in classic PLC engineering.

What SIMATIC AX Can Actually Do Today

One reason SIMATIC AX still feels abstract to many engineers is that people mix up two different questions. One is, “Where is Siemens trying to go?” The other is, “What can AX genuinely do today?” The public Siemens developer overview, release notes, and learning material show a platform that is already capable enough to be useful, especially for software-centric teams, but still uneven if you expect the full breadth of TIA Portal in one place.

Today, AX can already support a surprisingly broad set of engineering tasks:

• Develop PLC applications and libraries in a VS Code based environment using Structured Text and object-oriented constructs.
• Organize projects through apax.yml, namespaces, dependencies, scripts, and package catalogs rather than a binary project tree.
• Build reusable libraries, version them, and connect those workflows back into TIA Portal library use cases through TIAX style bridges.
• Run unit tests on a PC without needing a physical PLC, which is one of the biggest practical shifts in the whole platform.
• Build, load, monitor, debug, and trace PLC software remotely, with Siemens now exposing more unified online tooling such as PLC Online Hub.
• Handle hardware configuration as YAML, generate template files from order numbers, and compile hardware definitions into I/O mappings.
• Work with newer target-system support such as S7-1500 variants, software controllers, and, in the 2510 release, direct ET200SP Open Controller support in AX Logic Control Engineering.

That shift shows AX is no longer just a concept demo about “Git for PLCs”. It now has enough real engineering surface area to justify serious attention. At the same time, the strongest current use cases are still quite specific: standard libraries, software platforms, reusable machine applications, and teams that already think in repositories, tests, and versioned components.

Yuriy Mosiyenko’s guide for TIA Portal engineers is useful here because it removes some of the mystery. The familiar Siemens concepts still exist, but they are represented differently. OB-like tasks, global data, hardware mappings, source blocks, and downloads are still there. The project becomes text files, manifests, YAML, packages, and command-driven workflows instead of a graphical project tree.

How SIMATIC AX Differs From TIA Portal

TIA Portal is an integrated engineering suite. It is built around the full project: PLCs, HMIs, drives, technology objects, hardware configuration, diagnostics, commissioning, and a workflow that most Siemens users already recognize. SIMATIC AX is much more focused on the software engineering side of PLC development.

The simplest useful summary is this. TIA Portal is project-centric. SIMATIC AX is code-centric. TIA wants to be the place where the whole automation project comes together. AX wants to make the PLC software part behave more like a modern software product.

If you are a Portal user, the easiest way to reduce the intimidation factor is to stop treating AX as an alien platform. A lot of the engineering intent is still familiar. What changes is the representation, the workflow, and the amount of software discipline exposed to the user.

Siemens’ own target-system overview makes the current relationship very clear. AX can handle user-program development, library usage, software download, and monitor/debug activities, but TIA Portal still appears in Siemens’ own hybrid workflow where technology objects and hardware configuration are involved.

What Software Disciplines Are Changing

If you only describe AX as “PLC code in a different editor”, you miss the important part. AX changes the surrounding software disciplines more than it changes the basic PLC runtime model.

Version control stops being optional decoration. Siemens’ own AX guidance openly references GitHub, GitLab, Azure DevOps, and Bitbucket. In AX, branch discipline, pull requests, review quality, and release history stop being awkward extras wrapped around the tool. They become part of the toolchain itself.

Package management becomes part of automation engineering. Reuse is no longer just “copy the block” or “import the library”. AX pushes teams toward dependencies, package versions, publishable artifacts, and controlled release boundaries. That is much closer to how mainstream software teams handle shared modules.

Unit testing moves further left. In classic PLC teams, defects are often found when logic is already wired into a project, simulator, or real plant. AX changes that by making small, local, repeatable tests practical much earlier. That shift affects engineering discipline as much as tooling.

Continuous integration becomes realistic for PLC teams. It is worth being precise here. In automation, the first big win usually comes from compile checks, package validation, test runs, and release tagging rather than aggressive deployment into a live plant. AX makes that workflow normal enough to be worth the effort.

Configuration starts to look more like code. Recent releases such as 2411, 2504, and 2510 added YAML hardware configuration templates, project variants, and more usable generated hardware assets. That is a strong signal that Siemens wants more engineering information to live in maintainable text forms rather than being trapped in opaque containers.

Roles can separate more cleanly. Siemens’ TIA Portal V19 material explicitly showed a “standardizer” and an “engineer” around the TIAX library flow. That is an important shift. A central group can own standard assets and quality. Project engineers can consume them. That is much closer to product-team thinking than the old habit of every project quietly becoming its own standard.

It is also worth saying that TIA Portal has been moving in this direction as well. Siemens already added openness, version-control interfaces, multiuser workflows, and testing options around TIA. AX brings those software-style habits much closer to the center of the workflow.

Why You Should Care About AX In The Future

The strongest case for paying attention to AX is Siemens’ direction of travel. AX shows that direction more clearly than any single TIA release note does.

First, Siemens keeps adding serious capability. The release trail from 2023 to 2025 shows AX moving beyond a library engineering niche into something broader: more hardware support, more debugging, more documentation, better hardware templating, project variants, and more usable tooling around real target systems.

Second, more of the project is becoming text-based. This is where Yuriy Mosiyenko’s public LinkedIn post on WinCC Unified Elements is especially interesting. The key point is that Siemens is already doing HMI inside the AX family rather than merely hinting at it. Yuriy described WinCC Unified Elements as the newest member of the SIMATIC AX family, with both visual design and YAML-defined screens and faceplates, while also stating that the software was not publicly available yet and that he was testing it through early access. If that direction holds, the long-term consequence is huge. PLC code, HMI definitions, dependencies, tests, and configuration can all start living in version control together.

Third, AX lowers the wall between IT-fluent developers and automation engineering. The toolchain becomes much more familiar to engineers who already know repositories, code reviews, packages, and CI pipelines. For some organizations, that is strategically important, even though real commissioning skill still sits firmly in the automation domain.

Fourth, the AI and LLM story gets more credible when the project is made of text. This is an inference, not a Siemens promise. LLM tools work better with human-readable source code, tests, YAML, markdown, and diffs than with opaque project files. If future AX workflows keep moving in that direction, AI assistance becomes more useful, more auditable, and less gimmicky.

Fifth, library engineering and platform thinking become much more practical. If your team builds many variants of the same machine, many modules for the same site standard, or many reusable equipment types, AX has the potential to pay back much earlier than a one-off project team would expect.

Why It Is Not So Relevant Right This Second

This part is worth saying plainly. SIMATIC AX is important, but its current relevance varies sharply across the Siemens user base.

For a lot of readers, AX is more important as a direction signal than as an immediate purchasing decision. The value becomes strongest when your software process is the bottleneck. If your actual bottleneck is site support, client handover, HMI delivery, mixed skill levels, or keeping a familiar TIA workflow for a maintenance team, AX may feel interesting but not urgent.

A good example is controller coverage in real projects. In a public LinkedIn post about getting early access to AX, Yuriy Mosiyenko described liking the direction and still deciding it had no practical value for his immediate work because much of it depended on S7-1200 rather than S7-1500. That is a very useful reality check. A platform can be strategically important and still fail the “does this help me on Monday?” test for a large share of engineers.

The better message is simple: many teams should start getting ready now, because the workflow direction is becoming clearer.

What The Roadmap Looks Like

No single public Siemens roadmap page appears to list every future AX milestone cleanly. The clearest public picture comes from release notes, product pages, community posts, and recent practitioner commentary.

• November 2022: Siemens publicly introduced SIMATIC AX in the TIA Portal V18 era as a lean, VS Code based, IT-style engineering environment.
• November 2023: TIA Portal V19 technical slides highlighted TIAX direct loading, library use-case improvements, and the benefits of OOP, unit testing, and Git connectivity for standard library engineering.
• February 2025, release 2411: Siemens added YAML hardware configuration templates, project variants, a GSDML viewer, and S7-1500V support.
• May 2025, release 2504: Siemens added more OOP capability in function blocks, unit-test improvements, trace capabilities, and comments in generated hardware templates.
• November 2025, release 2510: Siemens added direct ET200SP Open Controller support in AX Logic Control Engineering, debug improvements for multiple called methods, PLC Online Hub, local packages, and public user documentation.
• November 18, 2025: Siemens announced direct U.S. marketplace availability, while also saying other regions would continue rolling out over time.
• March 2026: Yuriy Mosiyenko showed that Siemens was already testing HMI inside the AX family through WinCC Unified Elements, while also stating that the software was not publicly available yet and that safety, drives, and motion libraries were still gaps.

The overall direction is clear. Siemens is steadily broadening AX and making it more complete. The equally important detail is that the public market message is still mixed. The product pages now talk about subscription options and even a 30-day solution trial. The developer portal, however, still labels AX as Early Access for selected productive use cases. That mismatch is part of why AX can feel simultaneously strategic and not fully settled.

Barriers To Entry

Price is still a serious barrier. Siemens now openly markets AX through subscription and marketplace channels, and it also offers a 30-day solution trial with guided tutorials and no installation requirement. Even so, a single licence is already over £1000, so this is still a commercial platform decision rather than a casual free tool for every individual engineer. For freelancers, small integrators, and self-funded learners, that becomes a real constraint straight away.

Availability has been uneven and a bit confusing. Siemens announced direct U.S. purchase availability on November 18, 2025. The developer portal still describes AX as Early Access for selected productive use cases, and the contact page still pushes people toward local representatives and staged access. That makes the access story feel less mature than the marketing headline alone suggests.

The support ecosystem is still thin compared with TIA Portal. Siemens has done a lot here: public docs, community forums, GitHub examples and learning paths, and even highlighted third-party frameworks such as AXOpen. But compared with the size of the TIA ecosystem, AX still has a shallow bench of trainers, experienced integrators, end-user support expectations, and widely recognized project patterns.

The skills barrier is significant. AX asks for comfort with Git, branches, repositories, code reviews, package versions, tests, and scripts. Some teams take to that quickly. Others experience it as a broader engineering-culture shift rather than a straightforward tool change.

The client-facing barrier is just as real. End users buy familiarity, maintainability, tenderability, and confidence that the next engineer can support the system, alongside technical capability. If the maintenance team, preferred integrator, or corporate standards still revolve around TIA Portal, AX becomes an organizational discussion long before it becomes a technical one.

There are still platform boundaries. Siemens staff confirmed in March 2025 that local Linux and macOS support had not reached the platform yet, with Windows or browser-based access as the supported routes. Many automation teams can live with that, but it is still another sign that AX comes with constraints mainstream developer tools often avoid.

What The Advantages Of SIMATIC AX Are

Unit testing is one of the clearest reasons to care. It is a practical benefit available now. Validating logic on a PC before a PLC is involved changes how defects are found, how standards are trusted, and how aggressively a team can refactor shared code.

The important nuance is where this helps most. For one-off project logic, the gain is there but limited. For reusable libraries, equipment modules, and multi-engineer standards work, the gain is much bigger. You can release library changes with more confidence and fewer plant-level surprises.

AI and LLM workflows fit AX much better than traditional binary project containers. AX creates the kind of artifacts AI tools can actually work with: text source, tests, YAML configuration, diffs, repository history, and eventually, if Siemens keeps moving in this direction, text-defined HMI assets as well. Siemens community discussions around VS Code extensions and GitHub Copilot context already point in that direction.

This is why Yuriy’s March 2026 HMI post is so useful. If screens and faceplates can sit beside PLC code as YAML and text, the whole system becomes much more legible to AI-assisted tooling. Better raw material makes AI assistance more useful and more auditable, even though it still needs engineering judgment.

CI/CD becomes useful in realistic ways. For automation teams, the biggest early win is usually continuous integration, not reckless continuous deployment to a live plant. AX makes it much more natural to run build checks, package validation, test suites, and release pipelines. That is often enough on its own to improve quality.

Code reuse becomes more deliberate. AX supports packages, testable libraries, and clearer standardization boundaries. That is a big step up from the old reality where a library is sometimes just a block folder that got copied around carefully enough to feel “standard”.

It matches modern engineering teams more naturally. If your team already works with Git, issue tracking, markdown docs, review workflows, and automation in other domains, AX fits those habits far better than trying to force them around a project file that was not designed with those workflows at the center.

It is also more flexible than some people assume. Siemens community examples show monitoring and variable modification through the debugging workflow in the VS Code style interface alongside command-line usage. That makes the platform more livable for real engineers and less dependent on a pure DevOps-style workflow.

What The Disadvantages Of SIMATIC AX Are

Support outside Siemens remains thin. The official ecosystem is improving, but it is still small compared with the TIA world. That means fewer experienced partners, fewer people who have handed over AX-heavy projects to end users, and fewer established answers when a client asks, “Who else around here uses this?”

End-client reluctance is rational, not backward. Most clients are not trying to buy the most modern development workflow. They are trying to buy a system that can be maintained, modified, and tendered again in ten years. If AX feels unfamiliar to their maintenance team or local support chain, hesitation is reasonable.

Some people are still getting over the move from SIMATIC Manager to TIA Portal. This is exactly the kind of field reality that rarely shows up on a product slide. Many teams spent years standardizing on Portal after STEP 7 Classic. Asking them to move again, this time into a much more software-centric model, is a bigger change than Siemens marketing language sometimes makes it sound.

The story is still hybrid, which can mean more tools rather than fewer. Siemens itself still presents combined AX and TIA workflows. That may be the right engineering answer, but it also means coexistence overhead. During a transition phase, teams may need to understand more tools, more interfaces, and more handover decisions, not fewer.

The programming culture is narrower. AX’s value proposition is deeply tied to Structured Text, object-oriented design, and text-first workflows. That is great for some engineering teams. It is less great for organizations where long-term support still depends on people being comfortable in graphical languages and a familiar TIA-style environment.

Commercial risk is substantial. Subscription cost, access model, rollout maturity, training time, and client acceptance all add up. AX can be strategically attractive and still be a poor short-term fit for a business that mainly delivers one-off Portal projects.

How To Prepare Yourself For SIMATIC AX If You Cannot Afford The Licence

The most durable part of the AX shift sits in the engineering habits around it, more than in the licence itself. A lot of AX’s value can be prepared for before the platform is ever purchased.

• Use Siemens’ official learning paths. The public documentation, GitHub learning path, community forum, and SITRAIN freemium material are all available without a production subscription.
• Use the official trial if you can. Siemens now promotes a 30-day SIMATIC AX solution trial with guided tutorials and no local installation required. That is probably the best low-risk way to see whether the workflow clicks for you.
• Read AX through a TIA lens. Yuriy Mosiyenko’s mapping guide is valuable because it translates AX back into familiar concepts for Siemens engineers. That reduces the intimidation factor quickly.
• Get good at Git now. Learn branching, pull requests, commit quality, release tags, and sensible repo structure. Those skills will be useful whether you adopt AX this year or not.
• Write more testable Structured Text. Even in TIA Portal, you can start separating pure logic from hardware mapping and making your code easier to validate. That pays back immediately and makes AX easier later.
• Think in packages and standards, not copied folders. Start treating reusable code as something with ownership, versions, and release intent.
• Practice CI on safe projects. A small internal codebase is a better first pipeline than a live PLC project. Use GitHub Actions, GitLab CI, or Azure DevOps to learn the habits.
• Watch the ecosystem as well as the licence. Follow the SIMATIC AX GitHub community, release notes, and third-party frameworks such as AXOpen. Adoption becomes easier when the surrounding world is getting stronger.

If you want the blunt version, prepare the habits before the platform. Teams that already manage Git cleanly, write modular Structured Text, think in tests, and treat standards as versioned assets will adapt much faster when AX becomes commercially or strategically right for them.

Where SIMATIC AX Sits Right Now

SIMATIC AX shows Siemens’ long-term direction much more clearly than any single feature announcement. The durable change sits in the move toward text-based engineering, testing, version control, packaging, and software-style release discipline around PLC code.

AX is most relevant to teams with reusable software, library ownership, and appetite for stronger software engineering discipline. For many delivery teams and end users, TIA Portal remains the more practical center of gravity today.

SIMATIC AX is absolutely worth paying attention to, because it is a serious signal about the future of Siemens engineering. It is just not necessary to pretend that future has fully arrived in every project type yet.