Das Siemens TIA Portal und die CI-Frage
Das TIA Portal (Totally Integrated Automation Portal) von Siemens ist die Standardumgebung für die SPS-Programmierung in vielen produzierenden Unternehmen. Millionen von Steuerungen weltweit werden damit programmiert. Und in den meisten Fällen passiert das noch auf dem klassischen Weg: Ein Ingenieur öffnet das Projekt auf seinem Rechner, macht Änderungen, kompiliert, und lädt das Programm auf die SPS.
Versionierung? Oft per Dateiablage auf einem Netzlaufwerk. Automatisierte Tests? Selten. Continuous Integration? Fast nie. Das liegt nicht an mangelndem Willen, sondern an realen technischen Hürden.
Technische Herausforderungen
Projektformat und Versionierung
TIA Portal-Projekte bestehen aus einer Reihe von Dateien, deren Format nicht für Versionskontrollsysteme optimiert ist. Binäre Dateien, verschachtelte Verzeichnisstrukturen und große Dateimengen machen einen einfachen Git-Commit unpraktisch. Siemens hat mit der Option "Exportieren als XML" (TIA Openness) einen Weg geschaffen, Projektinhalte in einem textbasierten Format zu exportieren -- aber das deckt nicht alle Projektbestandteile ab.
In der Praxis hat sich ein hybrider Ansatz bewährt:
- Quellcode der SPS-Programme: Als strukturierten Text (SCL) oder XML exportiert und in Git versioniert
- Gesamtprojekt: Als Archiv gesichert, mit klarer Namenskonvention und Verweis auf den Git-Commit
- Konfiguration und HMI: Wo möglich als Export, sonst als Teil des Projektarchivs
Headless Build
Für CI brauchen Sie einen automatisierten Build-Prozess ohne grafische Oberfläche. TIA Portal bietet über die Openness-API die Möglichkeit, Projekte programmatisch zu öffnen, zu kompilieren und zu exportieren. Das erfordert allerdings eine installierte TIA Portal-Instanz auf dem Build-Server -- inklusive Lizenz.
Ein minimaler Build-Prozess mit TIA Openness in C#:
using Siemens.Engineering;
// TIA Portal im Hintergrund starten
using (TiaPortal tiaPortal = new TiaPortal(TiaPortalMode.WithoutUserInterface))
{
// Projekt öffnen
ProjectBase project = tiaPortal.Projects.OpenWithUpgrade(
new FileInfo(@"C:\Projects\MyPlc\MyPlc.ap17")
);
// Alle PLC-Programme kompilieren
foreach (var device in project.Devices)
{
var software = device.DeviceItems
.SelectMany(di => di.GetService<SoftwareContainer>()?.Software)
.Where(s => s != null);
foreach (var sw in software)
{
var result = sw.Compile();
if (result.State != CompilerResultState.Success)
{
Console.Error.WriteLine($"Kompilierung fehlgeschlagen: {result.Messages}");
Environment.Exit(1);
}
}
}
}
Das funktioniert, hat aber Einschränkungen: TIA Portal-Lizenzen sind teuer, der Startvorgang dauert Minuten, und die API ist nicht für alle Funktionen verfügbar.
Simulation und Test
Für automatisierte Tests von SPS-Programmen gibt es zwei Ansätze:
- PLCSim Advanced: Simuliert eine S7-1500 SPS und kann über eine API angesteuert werden. Damit lassen sich Funktionstests automatisieren, die Signale setzen und Ausgänge prüfen
- Unit-Tests mit Frameworks: Spezialisierte Frameworks wie SIMATIC AX Unit Test erlauben Unit-Tests für SPS-Code, ähnlich wie JUnit für Java
Beide Ansätze erfordern Vorbereitung. Testbare SPS-Programme müssen sauber modularisiert sein -- monolithische Programme mit Tausenden Netzwerken lassen sich nicht sinnvoll automatisch testen.
Eine CI-Pipeline für TIA Portal
Eine realistische CI-Pipeline für TIA Portal-Projekte könnte so aussehen:
- Trigger: Ein Git-Push auf den Feature-Branch löst die Pipeline aus
- Checkout und Projektrekonstruktion: Die exportierten Quellen werden ausgecheckt, das TIA Portal-Projekt wird zusammengesetzt
- Kompilierung: Headless-Build über TIA Openness
- Statische Analyse: Prüfung auf Coding-Standards (Namenskonventionen, nicht genutzte Variablen, Kommentierung)
- Simulation und Test: Automatisierte Tests gegen PLCSim Advanced
- Artefakt-Erstellung: Kompilierte Programme werden als Build-Artefakt archiviert
- Dokumentation: Automatische Generierung von Änderungsprotokollen
Der Build-Server muss Windows mit installiertem TIA Portal sein -- eine Einschränkung, die in Container-basierten CI-Umgebungen Anpassungen erfordert. Dedizierte Windows-Build-Agents mit vorinstalliertem TIA Portal sind hier die pragmatische Lösung.
Organisatorische Voraussetzungen
Technik allein reicht nicht. Für erfolgreiche CI mit TIA Portal brauchen Sie:
- Disziplin bei der Quellcode-Verwaltung: Alle Änderungen müssen über Git laufen, nicht direkt im TIA Portal gespeichert und per Netzlaufwerk geteilt werden
- Modulare Programmierung: SPS-Programme müssen testbar strukturiert sein -- das erfordert oft ein Umdenken bei der Programmarchitektur
- Schulung: Die meisten SPS-Programmierer haben keinen Hintergrund in Versionskontrolle und CI/CD. Training ist essenziell
Fazit
Continuous Integration mit TIA Portal ist machbar, aber es ist kein Plug-and-Play. Die technischen Hürden -- Projektformat, Lizenzanforderungen, Windows-Abhängigkeit -- erfordern Kompromisse. Der Lohn ist eine höhere Softwarequalität, bessere Nachvollziehbarkeit und schnellere Feedback-Zyklen.
Der sinnvollste Einstieg: Versionierung und automatisierte Builds. Automatisierte Tests kommen als zweiter Schritt, wenn die Grundlagen stehen. Unser Git Training für TIA Portal Entwicklung legt genau diese Grundlage und zeigt SPS-Programmierern, wie sie Git in ihren Arbeitsalltag integrieren.
