SIMATIC AX - SHIFTING PARADIGM IN INDUSTRIAL AUTOMATION

My recent post about focusing on a new technology from Siemens raised some eyebrows. Among other things, I stated that part of the team and I will be spending more effort on working with the new platform from Siemens called SIMATIC AX. In a very short time, my inbox was flooded with questions about what happened, and why I would be joining the ‘dark side’.

This article is my way to explain the reasons.

SIMATIC AX?

A bit of context. Anyone who followed me over the past few years may have noticed my disdain for the TIA Portal. Although TIA brought considerable improvements, it was firmly rooted in the past. Our expectation was that Siemens would lead the (r)evolution by bringing in successful approaches from the world of software engineering. Instead, TIA merely happened to be a fancier edition of the ancient world. It was like watching a black and white movie on color television in a higher resolution. Besides that, Siemens remained faithful to its tradition, and delivered a closed black box solution slightly `opened` by TIA Openness (an API to manage TIA projects).

The years of maturation brought some improvements (TIA is at version 18 at present), however, the foundation laid at the beginning does not allow it to fly. One example for all: the integration of Git resulted in a pitiful struggle to combine the best of version control with something that could not fit the frame by its very nature.

At some point, we understood that if we want to have our PLC software scalable, testable, composable, and organised in reusable packages; TIA is simply not the enabler, rather the opposite. So, we made the hard and adventurous decision to migrate to a platform that would open up these possibilities for the more modern methodologies. In our case, it was Beckhoff’s TwinCAT3 (we also considered other CoDeSys-based platforms, and B&R).

TwinCAT3 became our companion for more than a decade, and we developed the tooling that eventually became Inxton. We also invested a lot into sharing our experience and knowledge in the open; the development of the TcOpen framework in particular. Thus, I have become a known evangelist of BECKHOFF’s TwinCAT3 platform, and PC-based automation in general. The reasons for our preference for TwinCAT3 were outlined in an article a couple of years ago.

Last year, I was contacted by the representatives of Siemens about whether or not I’d be willing to have a look at what they are up to. I was not sure. I suspected they would be showing me TIA Openness, and Git integration that I was already aware of and not at all impressed with. Reluctantly, I accepted the offer out of politeness.

Then, I was shown SIMATIC AX, and I was thunderstruck! Man, my jaw dropped! I understood immediately what it meant, and its potential.

There were some aspects of the TwinCAT3 platform that were extremely annoying. Things like: the use of the XML format to store the source code; reducing the usability in version control, the antiquated dependency management of the PLC libraries, and the Automation Interface; something like TIA Openness; faster, but also very cumbersome and not particularly stable. The integration of CoDeSys into Visual Studio was an excellent idea, but these things did not always play well together.

With SIMATIC AX, I was introduced to something that gracefully avoids all these problems.

What is changing the paradigm?

Editor

Firstly, let me introduce you to how SIMATIC AX looks and feels at first glance. SIMATIC AX comes with an AXCode editor based on VSCode. It is a lightning fast, extensible, and highly customisable IDE. It is not the kind of environment that the automation engineers are used to, but with a bit of good will; anyone can discover the power of this incredibly well-crafted editor. It has pretty much everything you need to develop, monitor, and debug your PLC program.

Source as plain text

SIMATIC AX’s source code is stored in plain text (human readable) files, and so are all possible project and configuration settings (hardware, project files, scripts, etc.). Therefore, when using a version control (like Git), you have a clear understanding of who changed what and when. Everything is derivable from the source — no magic files, just text source.

Dependency management

If you have ever encountered a problem where two of your dependencies were using the same library, but in different versions; you will understand what Dependency Hell is. Or maybe you have had trouble finding the right version of a library once it was lost from the file system due to some accident. There are different approaches to how to avoid this. SIMATIC AX took the battle-proven method; NPM-based package management. This approach naturally leads to componentisation, and thus, provides a framework for creating reusable libraries.

Language and compiler

Another important feature of SIMATIC AX is the implementation of the object-oriented features — as defined in IEC61131-3 — the best implementation I have seen so far. The authors of the compiler took inspiration from the latest developments in programming languages and compilers. The language has succinct form through the use of coherent grammar, clean syntax, and semantic models. This may seem like an overly academic matter, but I believe that the gems hidden in this approach are extremely pragmatic. For example, you can extend your compiler through the creation of additional analysers.

CLI First

The authors of SIMATIC AX opted for a CLI (Command Line Interface) First approach. This means that all the possible actions you complete by clicking on an icon can be effectively performed from the terminal, which is very useful for the automation of repetitive tasks, and continuous integration/delivery scenarios.

Unit testing

The built-in unit testing framework is another feature that stands out. There is very little culture in regards to the automated testing of software in industrial automation. The quality is presumably assured by a set of standards and reviews, but to be honest, even this is rare in the absolute majority of projects. SIMATIC AX comes with an integrated unit testing framework, and different approaches are viable: TDD, BDD, or any other unit testing methodology you prefer. There is even a test coverage feature that visually indicates which parts of the code are or are not covered by the unit tests.

What is it good for?

Text-based sources, package management CLI, and testing frameworks; are the prerequisites for effective continuous integration and delivery. Furthermore, it makes an approach called IaC (infrastructure as code) incredibly simple; you can faithfully reproduce any build from the source code.

Open architecture

Let me briefly point out another important aspect that might not be so obvious from the above: SIMATIC AX is an open platform by design, it is inherently exposed to all sorts of customisations — from the AXCode extensions to the compiler analysers, code generators, and customised scripts. This is not typical for Siemens, and it is an undeniable sign that something is changing in a very positive direction.

The SIMATIC AX team is full of very open and forward-thinking people. We have been collaborating with them for a while now, as piloting and co-creation partners. So, I can share firsthand experience with you, about their open and productive environment.

Why should you pay attention?

All of the features above may seem like a bizarre thing to many in the industry, but this is the crux of it: these features are the core enablers of the methodologies painfully developed over time in software engineering known as DevOps. They allow the acceleration of software development by a landslide. We have used DevOps for quite some time. We have an ecosystem where many developers contribute to the codebase every day; any change runs through a pipeline, where the code is tracked, automatically tested, and deployed in the form of reusable and consistently versioned packages. The fresh updates are available on a daily basis (new features, fixes, improvements).

SIMATIC AX is still young, but has very solid foundations upon which further development can firmly stand.

If your company is aiming to shorten the time to market, and improve the quality, scalability, and maintainability of your control software; this is the right direction to proceed in.

In conclusion

And so, here is my answer to those who feel that I am a ‘traitor’ for moving to the ‘dark side’.

The preference for a control system is a complicated topic. More often than not, a preference for a particular brand, programming language, or tooling; has quasi-religious and dogmatic connotations, but not for me.

Here is the way I see it:

A)?Be interested first and foremost in technology.

B)?The technology must have the potential to create an ecosystem and culture to support it.

These two principles led me to choose TwinCAT3 twelve years ago, and the same principles lead me to engage with SIMATIC AX today.

In my role as CTO, I am responsible for following and evaluating technologies beneficial for the future of our company, and SIMATIC AX is definitely a technology that I cannot ignore.

?

I need to add the following disclaimer from the AX team since the product is not fully released yet:

‘SIMATIC AX is currently in a limited sales release in selected European countries only. You will need to request access from the AX team which will check if your use case is suitable for the current state of the product. The first step to getting the approval is contacting your local SIEMENS sales representative or writing an email to [email protected]

News

For those of you that made it this far, I have some exciting news:

I am not leaving the TwinCAT3 community. I will still be helping my colleagues that will continue to support both Inxton and TcOpen.

Inxton for TwinCAT3 is free of charge

We have decided to de-commercialise the Inxton libraries for TwinCAT3. The major version v2 is being released as you read these lines. The only difference between the latest v1 and v2 is the removal of the licensing protection (no license code will be needed anymore). TL; DR: it allows you to use the Inxton compiler and libraries without any charge for all commercial and non-commercial projects.

For more details, please consult the simple license agreement you can find in the documentation at https://docs.inxton.com/#licencing.

This also means that you can use all the features of the TcOpen framework without incurring any fees whatsoever.

What’s next?

The support for Inxton will be granted based on the resources available to us. In some instances, this might be subject to fees. Needless to say, all existing paying customers will be rightfully supported.

Although the Inxton libraries are rendered free of charge, they will not be open sourced, as this would require too much additional time and too many resources to do so.

We will also suspend (not terminate) the further development and feature updates for the Inxton libraries (there are no further plans to update to the newer versions of .NET, and the version for .NET5.0 remains experimental).

We will continue to develop the TcOpen framework to ensure a stable version.