TIA Openness: Was sich im TIA Portal automatisieren lässt — und ab wann es sich lohnt

TIA Portal Openness ist eine Programmierschnittstelle, mit der sich Engineering-Aufgaben im TIA Portal automatisieren lassen — Projekte anlegen, Bausteine und Variablen importieren, übersetzen, laden, dokumentieren. Sie ist als Optionspaket im TIA-Portal-Setup enthalten, und die Voraussetzungsliste nennt keinen eigenen Lizenzschlüssel. Wer C# beherrscht, spricht die Schnittstelle direkt an; wer nicht, nutzt TIA Scripting Python. Der Nutzen entsteht ab der Wiederholung — bei der Einzelmaschine nicht.

Was TIA Portal Openness ist — und was es nicht ist

Openness ist eine Schnittstelle in das Engineering, nicht in die laufende Anlage. Das ist der Punkt, an dem die meisten Missverständnisse anfangen.

Über Openness lässt sich ein TIA-Portal-Projekt von außen bearbeiten: öffnen, auslesen, ergänzen, übersetzen, laden. Was Openness nicht tut, ist mit der Steuerung im Betrieb sprechen. Prozesswerte, Rezepte, Produktionsdaten laufen über ganz andere Wege.

Der zweite verbreitete Irrtum: Openness sei ein Werkzeug für Programmierer. Die Schnittstelle selbst schon — sie ist objektorientiert und setzt auf dem .NET Framework 4.8 auf ✓, gesprochen wird sie in C#. Der Weg über TIA Scripting Python macht daraus etwas, das ein Automatisierer mit geringen Programmierkenntnissen bedienen kann ✓. Der Unterschied zwischen beiden Wegen ist kein gradueller, er ist der zwischen einem Entwicklungsprojekt und einem Nachmittag.

Was sich automatisieren lässt

Openness bildet das TIA-Projekt als Objektmodell ab: oben Portal und Projekt, darunter die Geräte, darunter die Steuerungen und Bediengeräte mit allem, was dazugehört ✓.

Auf Projektebene — Projekte anlegen, öffnen, archivieren und aus dem Archiv holen, globale Bibliotheken und Mastercopies verwalten, Projektserver anbinden.

Auf Steuerungsebene — Programmbausteine, Datentypen, Variablentabellen und Technologieobjekte importieren und exportieren, Hardware-Konfiguration lesen und ergänzen, übersetzen, laden, mit dem Online-Stand vergleichen, Beobachtungs- und Forcetabellen erzeugen, Safety-Administration und Safety-Ausdruck.

Auf HMI-Ebene — Bilder, Vorlagen- und Pop-up-Bilder, Variablen, Verbindungen, Zyklen, Meldungen und Meldeklassen, Text- und Grafiklisten, Skripte.

Für Prüfung und Abnahme — die TIA Test Suite hängt an derselben Schnittstelle: Applikationstest, Systemtest und Regelwerksprüfung ✓. Ein Projekt lässt sich damit nicht nur erzeugen, sondern auch automatisiert gegen einen Programmierstyleguide prüfen.

Zwei Austauschformate verdienen eine eigene Erwähnung, weil sie in der Praxis unterschätzt werden. SIMATIC SD — SIMATIC Source Documents — wandelt Bausteine in Textform um: s7dcl für den Programmcode, s7res für die sprachabhängigen Kommentare ✓. Verfügbar ab TIA Portal V20, dort zunächst nur für reine KOP-Bausteine, Datenbausteine und PLC-Datentypen; FUP und SCL kamen mit V20 Update 4 dazu ✓. AWL unterstützt das Format nicht ✓. Wer schon einmal zwei TIA-Projektstände vergleichen musste, weiß, was das wert ist. AutomationML ist der XML-Standard für Hardware- und CAx-Daten, unterstützt von EPLAN Electric P8, dem TIA Selection Tool und dem TIA Portal ✓; der CAx-Import erzeugt darüber Hardware-Konfiguration und Netze ✓. Wer seine Schaltpläne in EPLAN pflegt, tippt die Hardwarekonfiguration also nicht zwingend ein zweites Mal ab.

Wo die Grenzen liegen

Die Grenze verläuft am Objektmodell. Was Openness als Objekt kennt, lässt sich ansprechen — was nicht, bleibt Handarbeit.

Bausteinlogik. Openness importiert und exportiert Bausteine, es schreibt sie nicht. Wer Code erzeugen will, erzeugt ihn außerhalb — als SCL-Quelle oder im XML-Format SimaticML — und lässt Openness ihn hineinreichen.

Alles, was nur in der Oberfläche existiert. Manche Einstellungen und Dialoge haben kein Gegenstück im Objektmodell. Dann hilft kein Skript.

Drei weitere Grenzen stehen in den Siemens-Unterlagen, tauchen aber in keiner Einführung auf. Sie kosten den Nachmittag, an dem man sie im Projekt findet.

Der Bibliothekstyp verschwindet beim Rückimport. Objekttypen aus einer Bibliothek lassen sich über Openness weder exportieren noch importieren. Exportiert man eine Instanz, kommt sie ohne Typinformation heraus; beim Rückimport wird sie überschrieben und ist vom Objekttyp abgelöst ✓ (Openness-Systemhandbuch V21, „Export von Projektierungsdaten“). Wer seinen Bausteinstandard über eine Bibliothek pflegt, zerlegt sich mit einem Skript zum Nachziehen also genau das, was er vereinheitlichen wollte.

Was über den Rand des Exports zeigt, kommt nicht mit. Ein Export bleibt auf seinen Unterbaum beschränkt: Verweise nach außen stehen nur als offene Referenzen in der Datei, die Attribute der referenzierten Objekte fehlen ✓. Lässt sich eine solche Referenz im Zielprojekt nicht auflösen, legt der Import kein Ersatzobjekt an ✓, und fehlende Instanz-Datenbausteine erzeugt er ebenfalls nicht ✓ (Systemhandbuch V21, „Grundlagen zum Import und Export“ sowie „Baustein importieren“). Der Lauf meldet keinen Fehler. Das Ergebnis ist trotzdem unvollständig, und auffallen wird es beim Übersetzen — oder später.

Quelltext gibt es nur für zwei Sprachen. Einen Baustein in eine Quelldatei umwandeln unterstützt Openness ausschließlich für AWL und SCL; bei jeder anderen Programmiersprache wird eine Ausnahme ausgelöst ✓ (Systemhandbuch V21, „Quelle aus Baustein generieren“). KOP, FUP und GRAPH bleiben außen vor. Wer sein Programm textbasiert versionieren oder zwei Stände vergleichen will, merkt das an dem Teil der Bibliothek, der nicht mitkommt.

Vier Wege — welcher zu Ihnen passt

	Manuell	TIA Scripting Python	Openness direkt (C#)	Fertiges Werkzeug
Werkzeug	TIA Portal	beliebiger Python-Editor ✓	Visual Studio 2017+, .NET SDK 4.8 ✓	—
Kenntnisse	TIA-Praxis	Einsteigerniveau, geringe Programmierkenntnisse ✓	fortgeschritten C#/VB.NET und .NET ✓	—
Versionsabhängigkeiten	—	übernimmt die Zwischenschicht ✓	selbst behandeln	Anbieter
Änderungen an der Schnittstelle	—	werden abgefangen ✓	brechen den Code	Anbieter
Einstiegsaufwand	keiner	niedrig	hoch	Auswahl und Einarbeitung
Grenze	die Wiederholung	das Objektmodell	das Objektmodell	der Funktionsumfang

Anforderungen an Werkzeug und Kenntnisse nach TIA Portal Informationssystem V21 und SIOS 109742322.

Die entscheidende Zeile ist die dritte, und sie wird fast immer übersehen: Ein Python-Skript bedient mehrere TIA-Portal-Versionen ✓. Die Zwischenschicht kümmert sich um die Versionsabhängigkeiten und fängt Änderungen an der Openness-Schnittstelle ab ✓. Wer eigene C#-Werkzeuge pflegt, kennt den Gegenfall: Jedes TIA-Release ist ein Wartungstermin.

Der vierte Weg ist oft der vernünftigste Anfang. Siemens stellt eine ganze Reihe fertiger Anwendungen bereit, alle auf Openness aufgebaut ✓ — dazu Open-Source-Projekte auf GitHub unter tia-portal-applications ✓.

Die Reihenfolge, die sich bewährt: erst prüfen, ob es die Aufgabe schon fertig gibt. Dann Python. C# erst, wenn beides nicht reicht. Wer diesen Weg abkürzt, baut ein Werkzeug nach, das er hätte herunterladen können — und pflegt es danach selbst. Wo dabei Unterstützung sinnvoll ist, steht unter SPS-Engineering im TIA Portal.

Fünf Aufgaben, bei denen der Anfang sich lohnt

Variablen aus der Konstruktionsliste ins Projekt. Die Signalliste existiert längst — in Excel, im Schaltplan, im Lastenheft. Sie ein zweites Mal im TIA Portal anzulegen, ist reine Übertragungsarbeit. Der klassische Einstiegsfall, und der mit dem geringsten Risiko.

Projekte aus einer Vorlage erzeugen. Wer Varianten derselben Maschine baut, baut jedes Mal dasselbe Gerüst: Hardware, Netz, Bausteinstruktur, Namensschema. Ein Skript setzt das Gerüst, die Anpassung bleibt beim Menschen.

Standardbausteine über viele Projekte gleich ziehen. Sobald ein Baustein im Standard korrigiert wird, stellt sich die Frage, in welchen Projekten er noch alt liegt. Über Openness lässt sich das prüfen und nachziehen — prüfbar, nicht aus dem Gedächtnis.

Übersetzen, laden, vergleichen in einem Durchlauf. Besonders vor Abnahmen: Projekt öffnen, übersetzen, gegen den Online-Stand vergleichen, Ergebnis protokollieren. Immer gleich, immer dokumentiert.

Dokumentation und Projektstand exportieren. Für FAT, SAT und Übergabe — der Teil der Arbeit, der am Projektende ansteht, also genau dann, wenn niemand mehr Zeit hat.

Was ein Skript wirklich spart

Nehmen Sie eine Anlage mit zwölf Antrieben. Jeder bringt Freigabe, Sollwert, Istwert, Störung und ein halbes Dutzend Statusbits mit — die Variablen stehen längst in der Konstruktionsliste. Im TIA Portal werden sie trotzdem noch einmal angelegt: Zeile für Zeile, Adresse für Adresse, in jedem Projekt neu.

Der Handaufwand wächst mit jeder Maschine. Der Aufwand für ein Skript, das dieselbe Liste einliest, fällt einmal an.

Siemens nennt die Fehleranfälligkeit manueller Anpassungen ausdrücklich als Grund für die Schnittstelle ✓. Dazu kommt ein dritter Punkt, der sich schlecht beziffern lässt und trotzdem zählt: Ein Skript liefert bei jedem Lauf dasselbe Ergebnis. Bei einer Serie, bei einer Abnahme oder bei einem Retrofit, der in zwei Jahren noch einmal genauso durchgeführt werden soll, ist das kein Komfort, sondern die Grundlage.

Zwei Dinge gehen bei dieser Rechnung regelmäßig unter. Der Nenner ist selten null: Auch ein Skript will gestartet, überwacht und im Ergebnis geprüft werden. Und die Pflege gehört in den Zähler — ein Skript, das drei Jahre läuft, wird in diesen drei Jahren angefasst.

Wann Sie die Finger davon lassen sollten

Die Stolpersteine beim Einstieg

Vier Dinge kosten fast jedem den ersten Nachmittag.

Die Benutzergruppe. Bei der Installation legt TIA Portal die Windows-Gruppe Siemens TIA Openness an ✓. Wer nicht — direkt oder über eine andere Gruppe — Mitglied ist, bekommt keine Verbindung. Die häufigste Ursache überhaupt.

Der Sicherheitsdialog. Beim ersten Verbindungsaufbau fragt TIA Portal nach. Eine einmalige Bestätigung gilt für diesen Lauf; die dauerhafte Aufnahme in die Freigabeliste verlangt zusätzlich eine Bestätigung der Benutzerkontensteuerung ✓.

Die Python-Version. TIA Scripting Python läuft mit 3.12.x, 3.13.x und 3.14.x — und ausdrücklich mit nichts anderem ✓. Weder 3.11 noch etwas oberhalb von 3.14 funktioniert.

Der Einbindungsweg. Es gibt zwei: über eine Umgebungsvariable auf das entpackte Verzeichnis oder als Python-Paket ✓. Beide funktionieren — aber Codevervollständigung gibt es nur beim Paket-Weg ✓. Wer sie nicht hat, arbeitet unnötig blind.

Die vollständige Zuordnung von TIA-Portal-Version, Openness, TIA Scripting und Python steht in der TIA Openness Versionsmatrix — dort auch die Fehlerbilder, die Siemens selbst als häufigste Fragen führt.

Die nächste Stufe: das TIA Portal per KI-Agent

Ein Skript kann einen Fall. Es macht ihn schnell, verlässlich und wiederholbar — aber es macht genau den, für den es geschrieben wurde. Jede Abweichung ist ein neues Skript.

Genau dort bleibt Engineering-Automatisierung in der Praxis stehen. Nicht an den großen, wiederkehrenden Aufgaben — die sind längst automatisiert. Sondern an den vielen kleinen, die sich knapp nicht lohnen.

Ein MCP-Server verschiebt diese Grenze: Er stellt die Openness-Funktionen als standardisierte Werkzeuge bereit, die ein KI-Assistent selbst kombiniert. Die Aufgabe wird beschrieben statt programmiert.

→ Ein MCP-Server für das TIA Portal