Industrial Software Development

In traditional IEC 61131 development, quality assurance means: onsite commissioning, fingers crossed, hope. We do it differently.

Every function in our control software is secured by automated tests:

Unit tests verify individual functions in isolation – before they're integrated into the overall system. A motion profile generator is tested with edge cases: zero velocity, maximum values, negative inputs. Does everything work? Only then do we proceed.

Component tests validate the interaction of multiple modules. An axis controller with position control, velocity profile, and safety monitoring is tested as a unit. Does it respond correctly to setpoints? Does the safety logic trigger on limit violations?

End-to-end tests simulate complete machine sequences. A virtual production cycle runs through all stations, all sensor signals are simulated, all movements verified. The system behaves exactly as if real hardware were running – only faster and without risk.

The result: When software arrives at the customer, it's not "in operation for the first time" – it has already been run through thousands of times. Bugs are found in the development process, not at the customer's site.

Classic problem in the IEC 61131 world: Hardware addresses are hard-wired in code. A motor at %Q0.5, a sensor at %I1.3. If the hardware configuration changes, the code must be modified. With a hundred IO points, this becomes a nightmare.

Virtual Wiring solves this fundamentally:

Application logic works with abstract names: `Motor_MainDrive`, `Sensor_EndPosition_Left`, `SafetyRelay_Door`. No developer needs to know which physical IO point the signal is connected to.

The mapping of abstract names to hardware IOs happens in a separate configuration file – without touching the control code. Hardware swap? New terminal at a different location? No problem: adjust configuration, done.

Transformational Links go one step further: IO signals can be transformed, filtered, scaled before they reach the application. An analog 0-10V sensor is automatically converted to physical units (e.g., 0-100 bar). A digital sensor gets software debouncing.

The result: True IO system independence. The same application logic runs on Beckhoff EtherCAT, Siemens Profinet, or embedded Linux with GPIO. Only the configuration changes – not the code.

Classic IEC 61131 development: Tests happen on the real machine. Every change means: drive to the facility, upload code, hope nothing breaks, search for errors, back to the desk, next iteration. Inefficient, risky, expensive.

Full Context Simulations turn this around:

The control software runs bit-for-bit identical – whether on real hardware or in simulation. The only difference: the IO task is swapped.

In the real system, the IO task communicates with EtherCAT terminals, reads sensors, switches relays. In simulation, it communicates with a virtual machine model: motors are modeled as mathematical motion profiles, sensors as state machines, processes as physical equations.

The machine model is as detailed as needed:

- Simple simulation: Digital IOs are simulated with time delays ("sensor switches 2 seconds after motor start"). - Physical simulation: Motor movements are calculated with realistic kinematics, including acceleration, mass, friction. - Process simulation: Chemical processes, temperature curves, pressure changes – all modeled virtually.

The result: Complete software tests without hardware. Developers test locally on laptops. CI/CD pipelines run automated end-to-end tests. Bugs are found long before the machine is built.

And when the system actually goes into operation? It's not the first time the software runs – it's the thousandth time. Only this time with real hardware.

This is where IEC 61131 systems fundamentally fail – and it has nothing to do with missing libraries.

The Problem: Static Allocation in IEC 61131

TwinCAT, TIA Portal, CODESYS – they all work with fixed heap and static memory allocation. What does this mean concretely?

When you develop a machine control, you must determine at compile time: How many axes? How many sensors? How many process steps? The compiler reserves exactly this amount of memory – no more, no less.

Example: A robot arm controller for 5 axes.

- You develop the application, compile it, test it. Works. - Next customer: Needs 10 axes. What now? - You must modify and recompile the application. - Enlarge arrays, reallocate memory, test again.

And if the next customer only needs 3 axes? Modify again, recompile again. Every time a new binary, every time new testing effort, every time potential new bugs.

Our Approach: Dynamic Initialization

We don't have a fixed heap. We can allocate memory at runtime – based on configuration, not code.

The same compiled application can:

- Control 1 robot arm - Control 10 robot arms - Control 100 robot arms

What changes? Only the configuration file.

The application reads at startup: "How many axes exist?" and initializes the corresponding number of instances. No code change. No recompiling. No new test cycle.

Why This Makes a Huge Difference

1. One Binary for All Variants

You develop one machine control. It's tested, validated, commissioned. And then it runs – whether at customer A with 5 axes, customer B with 50 axes, or customer C with 500 axes.

No variant explosion. No "version for small machines" and "version for large machines". One software. Many configurations.

2. Bugfixes Propagate Automatically

A bug is found? You fix it once – in the one binary. All customers get the fix. Not just those with 5 axes. Not just those with the "small variant". Everyone.

3. True Product Families Become Possible

If you build machines in different sizes – small, medium, large – you have one control software for all three. Configured, not programmed.

New features? Develop once, all variants benefit.

4. Scaling Is Not Engineering Effort

Customer wants more axes later? No problem. Adjust configuration file, restart, done. No developer needed. No recompiling. No regression tests.

This is the difference between "reusable" and "scalably reusable"

Yes, TwinCAT has libraries too. Yes, IEC 61131 has modules too. But the application itself is static. Each variant is a new binary.

We build applications that adapt to requirements at runtime – without code changes. That's true reusability for product families.

The honest answer: Because the tools don't support it.

TwinCAT, TIA Portal, CODESYS – these are the dominant platforms in IEC 61131 automation. They all share one problem: They were conceived in the 90s and have barely evolved since.

No Test Framework: There's no built-in way to write unit tests. No test runners, no mocking frameworks, no assertions. Quality assurance = Manual tests onsite.

No Real Simulation: Some tools offer "simulation" – but that means: PLC runtime without hardware. That's not a complete machine model. Sensors don't switch automatically, motors don't move virtually. It's an empty shell.

Static Memory Allocation: Fixed heap means: Each machine variant needs a new binary. 5 axes? Compile. 10 axes? Recompile. No possibility for dynamic initialization at runtime.

Proprietary Ecosystems: Every vendor cooks their own soup. Beckhoff code doesn't run on Siemens. Siemens code doesn't run on CODESYS. Vendor lock-in is built in.

Why We Can Do It Differently:

We didn't try to repair IEC 61131. We started fresh.

- Foundation: Modern programming languages (C++, Rust) with package managers, test frameworks, and dynamic memory management. - Git version control instead of proprietary project files. - CI/CD pipelines with automated tests on every commit. - Hardware abstraction that enables true portability – not just lip service. - Dynamic allocation for scalable applications that adapt at runtime.

The result: Software developed according to modern standards – and still supports EtherCAT, Profinet, and all common fieldbuses.

For Whom Is This Relevant?

If you build more than one-off machines – if you produce machine series, manage variants, need long-term maintenance – then you're in the right place. Then these methods pay off. Then the difference between "works somehow" and "is systematically tested, modularly built, and maintainable" isn't academic – it's real money.