Industrielle Softwareentwicklung

In traditioneller IEC 61131-Entwicklung bedeutet Qualitätssicherung: Inbetriebnahme vor Ort, Daumen drücken, hoffen. Wir machen es anders.

Jede Funktion in unserer Steuerungssoftware wird durch automatisierte Tests abgesichert:

Unit-Tests prüfen einzelne Funktionen isoliert – noch bevor sie in das Gesamtsystem integriert werden. Ein Bewegungsprofil-Generator wird mit Grenzfällen getestet: Null-Geschwindigkeit, Maximalwerte, negative Eingaben. Funktioniert alles? Erst dann geht es weiter.

Component-Tests validieren das Zusammenspiel mehrerer Module. Eine Achssteuerung mit Positionsregelung, Geschwindigkeitsprofil und Sicherheitsüberwachung wird als Einheit getestet. Reagiert sie korrekt auf Sollwerte? Greift die Sicherheitslogik bei Grenzüberschreitungen?

End-to-End-Tests simulieren komplette Maschinenabläufe. Ein virtueller Produktionszyklus durchläuft alle Stationen, alle Sensorsignale werden simuliert, alle Bewegungen geprüft. Das System verhält sich exakt so, als würde echte Hardware laufen – nur schneller und ohne Risiko.

Das Ergebnis: Wenn die Software beim Kunden ankommt, ist sie nicht "zum ersten Mal in Betrieb" – sie wurde bereits tausendfach durchgespielt. Bugs werden im Entwicklungsprozess gefunden, nicht beim Kunden.

Klassisches Problem in der IEC 61131-Welt: Hardwareadressen sind fest im Code verdrahtet. Ein Motor an %Q0.5, ein Sensor an %I1.3. Ändert sich die Hardware-Konfiguration, muss der Code angefasst werden. Bei hundert IO-Punkten wird das zum Albtraum.

Virtual Wiring löst das grundlegend:

Anwendungslogik arbeitet mit abstrakten Namen: `Motor_Hauptantrieb`, `Sensor_Endposition_Links`, `Sicherheitsrelais_Tür`. Kein Entwickler muss wissen, an welchem physikalischen IO-Punkt das Signal hängt.

Die Zuordnung von abstrakten Namen zu Hardware-IOs erfolgt in einer separaten Konfigurationsdatei – ohne den Steuerungscode zu berühren. Hardware-Tausch? Neue Klemme an anderer Stelle? Kein Problem: Konfiguration anpassen, fertig.

Transformational Links gehen noch einen Schritt weiter: IO-Signale können transformiert, gefiltert, skaliert werden, bevor sie die Anwendung erreichen. Ein analoger 0-10V Sensor wird automatisch in physikalische Einheiten (z.B. 0-100 bar) umgerechnet. Ein digitaler Sensor wird mit Software-Debouncing entstört.

Das Ergebnis: Echte IO-System-Unabhängigkeit. Die gleiche Anwendungslogik läuft auf Beckhoff EtherCAT, Siemens Profinet oder embedded Linux mit GPIO. Nur die Konfiguration ändert sich – nicht der Code.

Klassische IEC 61131-Entwicklung: Tests finden an der echten Maschine statt. Jede Änderung bedeutet: Zur Anlage fahren, Code übertragen, hoffen dass nichts kaputtgeht, Fehler suchen, zurück zum Schreibtisch, nächste Iteration. Ineffizient, riskant, teuer.

Full Context Simulations drehen das um:

Die Steuerungssoftware läuft Bit-für-Bit identisch – ob auf echter Hardware oder in der Simulation. Der einzige Unterschied: Der IO-Task wird ausgetauscht.

In der echten Anlage kommuniziert der IO-Task mit EtherCAT-Klemmen, liest Sensoren, schaltet Relais. In der Simulation kommuniziert er mit einem virtuellen Maschinenmodell: Motoren werden als mathematische Bewegungsprofile modelliert, Sensoren als Zustandsautomaten, Prozesse als physikalische Gleichungen.

Das Maschinenmodell ist so detailliert, wie nötig:

- Einfache Simulation: Digital-IOs werden mit Zeit-Verzögerungen simuliert ("Sensor schaltet 2 Sekunden nach Motorstart"). - Physikalische Simulation: Motorbewegungen werden mit realistischer Kinematik berechnet, inklusive Beschleunigung, Masse, Reibung. - Prozess-Simulation: Chemische Prozesse, Temperaturverläufe, Druckänderungen – alles virtuell modelliert.

Das Ergebnis: Komplette Software-Tests ohne Hardware. Entwickler testen lokal auf dem Laptop. CI/CD-Pipelines führen automatisierte End-to-End-Tests aus. Bugs werden gefunden, lange bevor die Maschine gebaut wird.

Und wenn die Anlage dann tatsächlich in Betrieb geht? Es ist nicht das erste Mal, dass die Software läuft – es ist das tausendste Mal. Nur diesmal mit echter Hardware.

Das ist der Punkt, an dem IEC 61131-Systeme fundamental scheitern – und es hat nichts mit fehlenden Libraries zu tun.

Das Problem: Statische Allokation in IEC 61131

TwinCAT, TIA Portal, CODESYS – sie alle arbeiten mit fixem Heap und statischer Speicherallokation. Was bedeutet das konkret?

Wenn Sie eine Maschinensteuerung entwickeln, müssen Sie zur Compile-Time festlegen: Wie viele Achsen? Wie viele Sensoren? Wie viele Prozessschritte? Der Compiler reserviert genau diese Menge an Speicher – nicht mehr, nicht weniger.

Beispiel: Eine Roboterarm-Steuerung für 5 Achsen.

- Sie entwickeln die Anwendung, kompilieren sie, testen sie. Funktioniert. - Nächster Kunde: Braucht 10 Achsen. Was jetzt? - Sie müssen die Anwendung anpassen und neu kompilieren. - Arrays vergrößern, Speicher neu allokieren, wieder testen.

Und wenn der übernächste Kunde nur 3 Achsen braucht? Wieder anpassen, wieder kompilieren. Jedes Mal eine neue Binary, jedes Mal neuer Test-Aufwand, jedes Mal potenzielle neue Bugs.

Unser Ansatz: Dynamische Initialisierung

Wir haben keinen fixen Heap. Wir können Speicher zur Laufzeit allokieren – basierend auf der Konfiguration, nicht auf dem Code.

Die gleiche kompilierte Anwendung kann:

- 1 Roboterarm steuern - 10 Roboterarme steuern - 100 Roboterarme steuern

Was ändert sich? Nur die Konfigurationsdatei.

Die Anwendung liest beim Start: "Wie viele Achsen gibt es?" und initialisiert entsprechend viele Instanzen. Kein Code-Change. Kein Re-Kompilieren. Kein neuer Test-Zyklus.

Warum das einen riesigen Unterschied macht

1. Eine Binary für alle Varianten

Sie entwickeln eine Maschinensteuerung. Diese wird getestet, validiert, in Betrieb genommen. Und dann läuft sie – egal ob bei Kunde A mit 5 Achsen, bei Kunde B mit 50 Achsen, oder bei Kunde C mit 500 Achsen.

Keine Varianten-Explosion. Keine "Version für kleine Maschinen" und "Version für große Maschinen". Eine Software. Viele Konfigurationen.

2. Bugfixes propagieren automatisch

Ein Bug wird gefunden? Sie fixen ihn einmal – in der einen Binary. Alle Kunden bekommen den Fix. Nicht nur die mit 5 Achsen. Nicht nur die mit der "kleinen Variante". Alle.

3. Echte Produktfamilien werden möglich

Wenn Sie Maschinen in verschiedenen Größen bauen – klein, mittel, groß – dann haben Sie eine Steuerungssoftware für alle drei. Konfiguriert, nicht programmiert.

Neue Features? Entwickeln Sie einmal, profitieren alle Varianten.

4. Skalierung ist kein Engineering-Aufwand

Kunde will nachträglich mehr Achsen? Kein Problem. Konfigurationsdatei anpassen, neu starten, fertig. Kein Entwickler nötig. Kein Re-Kompilieren. Keine Regression-Tests.

Das ist der Unterschied zwischen "wiederverwendbar" und "skalierbar wiederverwendbar"

Ja, auch TwinCAT hat Libraries. Ja, auch IEC 61131 hat Module. Aber die Anwendung selbst ist statisch. Jede Variante ist eine neue Binary.

Wir bauen Anwendungen, die sich zur Laufzeit an die Anforderungen anpassen – ohne Code-Änderungen. Das ist echte Wiederverwendbarkeit für Produktfamilien.

Die ehrliche Antwort: Weil die Werkzeuge es nicht hergeben.

TwinCAT, TIA Portal, CODESYS – das sind die dominierenden Plattformen in der IEC 61131-Automatisierung. Sie alle teilen ein Problem: Sie wurden in den 90ern konzipiert und haben sich seitdem kaum weiterentwickelt.

Kein Test-Framework: Es gibt keine eingebaute Möglichkeit, Unit-Tests zu schreiben. Keine Test-Runner, keine Mocking-Frameworks, keine Assertions. Qualitätssicherung = Manuelle Tests vor Ort.

Keine echte Simulation: Manche Tools bieten "Simulation" – aber das bedeutet: SPS-Runtime ohne Hardware. Das ist kein vollständiges Maschinenmodell. Sensoren schalten nicht automatisch, Motoren bewegen sich nicht virtuell. Es ist eine leere Hülle.

Statische Speicherallokation: Fixer Heap bedeutet: Jede Maschinenvariante braucht eine neue Binary. 5 Achsen? Kompilieren. 10 Achsen? Neu kompilieren. Keine Möglichkeit zur dynamischen Initialisierung zur Laufzeit.

Proprietäre Ökosysteme: Jeder Hersteller kocht sein eigenes Süppchen. Beckhoff-Code läuft nicht auf Siemens. Siemens-Code läuft nicht auf CODESYS. Vendor Lock-in ist eingebaut.

Warum wir es anders machen können:

Wir haben nicht versucht, IEC 61131 zu reparieren. Wir haben neu angefangen.

- Basis: Moderne Programmiersprachen (C++, Rust) mit Package-Managern, Test-Frameworks und dynamischer Speicherverwaltung. - Git-Versionskontrolle statt proprietärer Projektdateien. - CI/CD-Pipelines mit automatisierten Tests bei jedem Commit. - Hardware-Abstraktion die echte Portabilität ermöglicht – nicht nur Lippenbekenntnisse. - Dynamische Allokation für skalierbare Anwendungen die sich zur Laufzeit anpassen.

Das Ergebnis: Software, die nach modernen Standards entwickelt wird – und trotzdem EtherCAT, Profinet und alle gängigen Feldbusse unterstützt.

Für wen ist das relevant?

Wenn Sie mehr als eine Einzelanlage bauen – wenn Sie Maschinenreihen produzieren, Varianten managen, langfristig warten müssen – dann sind Sie hier richtig. Dann zahlen sich diese Methoden aus. Dann ist der Unterschied zwischen "funktioniert irgendwie" und "ist systematisch getestet, modular aufgebaut und wartbar" nicht akademisch – sondern bares Geld.