Simatic AX: Ein Erfahrungsbericht
Mit der Vorstellung von Simatic AX bringt Siemens die klassische Automatisierung und die moderne Softwareentwicklung zusammen. In diesem ersten Teil meiner Erfahrungsberichte möchte ich meine Eindrücke und Erfahrungen mit dieser neuen Plattform teilen.
Was ist Simatic AX?
Simatic AX besteht hauptsächlich aus zwei Komponenten:
- AX Code: Eine auf Visual Studio Code basierende Entwicklungsumgebung
- Apax: Ein auf NPM basierender Paketmanager und Build-System, beinhaltet auch eine Befehlszeilenschnittstelle
AX Code
AX Code bietet sowohl eine Desktop-Anwendung als auch eine webbasierte Version, die von Siemens gehostet wird. Die IDE überzeugt wie von Visual Studio Code gewohnt mit einer intuitiven Benutzeroberfläche und vereint alle Funktionen von Apax, wie Kompilieren, Ausführen von Tests und Versionsverwaltung, direkt in der Umgebung.
Die Erstellung eines neuen Projekts in AX Code ist denkbar einfach. Betrachtet man Abb. 1, findet man zahlreiche Vorlagen, die eine Projektstruktur samt Standard-Dateien (z.B. .gitignore) liefern. Dabei existieren einsteigerfreundliche Beginner-Vorlagen (@ax/getting-started) aber auch komplexere (@ax/tiax).
Mit Simatic AX schließt Siemens mit der Unterstützung von objektorienterter Programmierung (OOP) endlich zur Konkurrenz auf. Dies ermöglicht eine klarere und wartbarere Code-Struktur und bessere wieder Verwendbarkeit im Vergleich zum klassischen SCL aus dem TIA Portal.
In Simatic AX Projekten, werden im Gegensatz zu herkömmlichen TIA Projekten alle Dateien mit Ausnahme der Softwarepakete, als Klartextdateien gespeichert. Das fördert die Zusammenarbeit und vereinfacht den Austausch von Codeänderungen. Dies erlaubt endlich die Verwendung von moderner Versionsverwaltungssoftware (z.B. Git, SVN) und ersetzt das aufwändige Teilen von Projektständen über z.B. Archive.
Apax
Alle Funktionen von Apax wie z.B. Softwarepakete installieren oder Unit-Tests ausführen können bequem über die grafische Benutzeroberfläche von AX Code gesteuert werden. Für die Automatisierung in Skripten oder CI bietet Siemens zudem ein vollständiges CLI.
Im apax.yml-File werden projektbezogene Konfigurationen definiert, einschließlich der Build-targets und der zu installierende Pakete samt ihren Versionen. Dies gewährleistet, dass alle Benutzer mit einem einfachen "apax install" Befehl die korrekten Versionen für ihr Projekt erhalten.
Apax definiert außerdem Build-Targets. Derzeit stehen drei kompatible Targets zur Verfügung:
- 1500: Standard-Build-Target für 1500-CPUs (derzeit die einzige von Simatic AX unterstützte CPU-Serie)
- plcsim: Standard-Build-Target für die Simulation von Steuerungen auf dem PC
- llvm: LLVM wird zum Ausführen von Unit-Tests benötigt
Es besteht auch die Möglichkeit, benutzerdefinierte Skripte zu erstellen, wie in diesem Beispiel das Laden auf die SPS. Diese Skripte können anschließend mit dem Befehl „apax run <script name>“ ausgeführt werden.
CI
Mit der entsprechenden Lizenz stellt Siemens in der umfangreichen Dokumentation zu Simatic AX ein Dockerfile für die Einrichtung einer CI-Umgebung bereit. Zum Zeitpunkt meiner Tests funktionierte die Kompilierung im Container allerdings nur mit dem LLVM-Target.
Die Ausführung von Unit-Tests war zudem aufgrund fehlender Abhängigkeiten im vorgegebenen Dockerfile nicht möglich. Das könnte daran liegen, dass die VS BuildTools benötigt werden, um Unit-Tests auszuführen.
Workflows
Momentan können durch die zwei von Simatic AX unterstützten Workflows die meisten Bereiche abgedeckt werden. Mit dem “TIAX library workflow” können Bibliotheken für neue oder bestehende TIA Projekte erstellt werden und ohne das Nutzen von Simatic AX vor Ort an der Anlage aufgespielt und getestet werden. Mit dem “TIAX direct loading workflow” in Verbindung mit dem “Simatic AX Hardware Loader” kann das TIA Portal in Zukunft komplett ersetzt werden.
TIAX library workflow
Der TIAX Bibliotheks-Workflow ermöglicht eine Standardisierung, indem Bibliotheken in SIMATIC AX erstellt und im TIA Portal genutzt werden können. Mit Apax lassen sich in SIMATIC AX erstellte Bibliothek in mit TIA benutzbare Bibliotheken konvertieren. Da das TIA Portal keine Objektorientierung unterstützt, muss vor einem Bibliotheksexport händisch eine Konvertierung in ein von TIA unterstütztes Format durchgeführt werden.
Der TIAX Bibliotheks-Workflow besteht im Wesentlichen aus vier Schritten:
Mit SIMATIC AX erstellte Bibliotheken sind Know-how-geschützt, daher kann der Code im TIA Portal nicht angezeigt werden. Allerdings ist das Debuggen und Ändern der erstellten Bibliotheken sehr umständlich, da hierzu Simatic AX verwendet werden muss. Nach Abschluss der Änderungen muss die Bibliothek anschließend neu exportiert werden.
TIAX direct loading workflow
Mit dem TIAX Direct Loading Workflow unterstützt SIMATIC AX jetzt einen effizienteren Arbeitsablauf. Hier kann der Simatic AX Hardware Loader zur Hardwarekonfiguration der SPS verwendet werden, alternativ kann diese auch mit dem TIA Portal konfiguriert und geladen werden. Die restliche Software kann komfortabel mit SIMATIC AX und vollständiger Objektorientierung erstellt werden. In diesem Workflow müssen keine Wrapper-FBs für die einzelnen Klassen erstellt werden, da das Kompilieren, Debuggen und der Software-Download zur SPS direkt mit SIMATIC AX funktionieren.
Fazit
Simatic AX stellt für mich einen spannenden Schritt in der Automatisierungstechnik dar, indem es klassische Automatisierung durch Entwicklungspraktiken wie OOP, CI und Unit-Tests mit modernen Softwareentwicklungsmethoden verbindet. Die Integration in Visual Studio Code und die Nutzung von Apax machen die Plattform leistungsfähig und benutzerfreundlich. Ich bin gespannt zu sehen, wie sich Simatic AX weiterentwickelt und welche neuen Möglichkeiten sich dadurch in der Automatisierung eröffnen.
Besonders interessant finde ich, dass es wöchentlich neue Updates zu Simatic AX gibt. Im nächsten Teil des Erfahrungsberichts schaue ich mir unter anderem den Simatic AX Hardware Loader an durch den man in Zukunft noch weniger abhängig vom TIA Portal ist.
Weitere Informationen:
