TIA Portal Openness V21: Was sich für Werkzeuge ändert

Wer im TIA Portal Arbeit automatisiert — Bausteine exportieren, Projekte vergleichen, Hardware aus einer Liste erzeugen —, tut das über Openness. Und wer das seit ein paar Jahren tut, hat sich auf eine Regel verlassen, die es ab Version 21 nicht mehr gibt: Openness war vier Versionen abwärtskompatibel.

Bis einschließlich V20 brachte jede TIA-Installation ein rollierendes Fenster von vier API-Versionen mit. Eine gegen V17 gebaute Anwendung lief unverändert auf einem V19- oder V20-Rechner. V21 liefert ausschließlich V21-APIs. Siemens formuliert es unmissverständlich: Anwendungen und Add-ins müssen gegen V21 neu gebaut werden, und was auf V21 zielt, läuft nicht mehr auf früheren Versionen.

Für den Betrieb heißt das: Jedes Openness-Werkzeug, das vor Dezember 2025 entstanden ist, steht auf einer V21-Installation still — bis es jemand neu baut. Dieser Artikel sammelt, was dabei zu beachten ist, welche Fallstricke unabhängig von der Version gelten und was die viel diskutierte KI-Anbindung technisch überhaupt kann.

Vorweg zur Einordnung: Openness automatisiert das Engineering, nicht die Anlage. Was am Ende in der Steuerung läuft, entsteht weiterhin in der SPS-Programmierung — Openness nimmt einem die Wiederholarbeit drumherum ab.

Was sich mit V21 technisch ändert

Die monolithische Assembly zerfällt in Teile: eine Basis-Assembly und getrennte Bibliotheken für Steuerungen, die WinCC-Linien und die Antriebsprojektierung. Wer nur die Basis referenziert, bekommt beim ersten Zugriff auf Steuerungsobjekte einen Ladefehler — die Steuerungs-Namensräume liegen jetzt woanders.

Zwei der Änderungen kosten erfahrungsgemäß die meiste Suchzeit, und sie verhalten sich gegensätzlich. Die Umstellung auf das Dienst-Muster und die umbenannten Schnittstellen sind Fleißarbeit beim Portieren, aber der Übersetzer findet sie und zeigt jede Stelle an. Der geänderte Referenzpfad dagegen bricht erst zur Laufzeit — und meldet sich als fehlende Datei, nicht als Versionsproblem.

// Die Openness-Assemblies liegen nicht im Ausgabeordner der eigenen Anwendung.
// Sie werden zur Laufzeit nachgeladen — üblicherweise in einer Auflösungs-
// routine, die den Pfad aus Installationsordner und Version zusammensetzt.
// Genau diese Routine ist die Stelle, die beim Wechsel auf V21 bricht.

AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
{
    // BIS V20 — die Datei lag unmittelbar im Versionsordner:
    // var pfad = Path.Combine(BASIS_ORDNER, TIA_VERSION, ASSEMBLY_DATEI);

    // AB V21 — eine Ebene mehr für das .NET-Framework-Ziel:
    var pfad = Path.Combine(BASIS_ORDNER, TIA_VERSION, ZIEL_FRAMEWORK, ASSEMBLY_DATEI);

    // Fehlt die Datei, meldet .NET eine fehlende Assembly und kein Wort zur
    // Version. Deshalb hier selbst prüfen und die Ursache benennen.
    if (!File.Exists(pfad))
        throw new FileNotFoundException(
            "Openness-Assembly nicht gefunden: " + pfad + ". Ab V21 liegt sie " +
            "in einem Unterordner für das .NET-Framework-Ziel.");

    return Assembly.LoadFrom(pfad);
};

Betroffen ist auch der niederschwellige Einstieg: Der von Siemens bereitgestellte Openness-Scripter, mit dem viele ohne eigene .NET-Entwicklungsumgebung gearbeitet haben, stammt aus der V18-Zeit und lief zuletzt unter V20. Für V21 liegen dazu Anwenderberichte vor, aber keine offizielle Aussage — wer darauf aufbaut, sollte das vor einer V21-Migration prüfen.

Welche Datei welche Version trägt

Hier steckt ein Fehler, der erst Wochen später auffällt. Das XML-Exportformat richtet sich nach der installierten TIA-Version, nicht nach der verwendeten API-Version. Ein altes Exportwerkzeug, das auf einem neueren Rechner läuft, erzeugt Dateien im neueren Format.

Der Import geht nur abwärts: Eine neuere Installation liest ältere Dateien, umgekehrt nicht. V21 importiert das Fenster von V18 bis V21.

Der typische Ablauf im Betrieb: Das Exportwerkzeug wird auf dem neuen Engineering-Rechner betrieben, die erzeugten Dateien sollen aber auf dem älteren Anlagenrechner eingespielt werden — und lassen sich dort nicht mehr importieren. Die Versionsmarke steht sichtbar im Kopf jeder Datei; ein Blick in die erste Zeile klärt den Fall in Sekunden.

Warum das Skript auf dem anderen Rechner scheitert

Wenn ein Openness-Werkzeug auf einem fremden Rechner nicht läuft, wird meist zuerst die Sicherheitsabfrage verdächtigt. Der häufigste Grund ist ein anderer: Openness kennt keinen Kompatibilitätsmodus.

Was der Weg von V20 auf V21 umfasst

Der Weg ist keine Übersetzungsarbeit an einer einzigen Stelle, sondern eine Kette aus fünf Schritten. Die Reihenfolge spart Arbeit, weil jeder Schritt voraussetzt, dass der vorige stimmt.

Was Openness nicht kann

Für die Einschätzung jedes Automatisierungsvorhabens — und jeder KI-Diskussion — ist das der wichtigste Punkt.

Logik gelangt auf genau vier Wegen ins Projekt:

1. Import einer XML-Datei,
2. externe Quelldatei mit anschließender Bausteinerzeugung (SCL, AWL),
3. Instanziierung eines Bibliothekstyps,
4. seit V20/V21 über textbasierte Quelldokumente.

Das neue Quellformat — und warum es für Git gedacht ist

XML als Versionierungsformat hat ein bekanntes Problem: interne Kennungen, Verdrahtungsinformationen und Metadaten erzeugen Änderungsvergleiche, in denen niemand mehr erkennt, was sich fachlich geändert hat. Dazu kommt die Bindung an die Engineering-Version.

V21 führt dafür ein textbasiertes Quellformat ein, das laut Siemens versionsunabhängig ist und für Kontaktsprache, Funktionsplan, SCL, gemischte Bausteine, Datenbausteine und Bibliotheken funktioniert — ausdrücklich mit dem Ziel, es mit Git, SVN und externen Vergleichswerkzeugen nutzbar zu machen.

Wer jetzt eine Versionsverwaltung für SPS-Projekte aufbaut, sollte diese Entscheidung bewusst treffen.

Für Bestandsprojekte hat das einen praktischen Nebeneffekt: Ein nachvollziehbarer Softwarestand ist eine der Grundlagen, ohne die eine Migration von Altsteuerungen mit Unsicherheiten startet — und er entsteht nicht von selbst, sondern mit der Entscheidung für ein Format.

Und die KI-Anbindung?

Der folgende Abschnitt beschreibt einen Stand, der sich schnell ändert. Recherchestand: 26. August 2026.

Zu diesem Zeitpunkt gibt es keinen offiziellen Siemens-Server für die Anbindung von Sprachmodellen an das TIA Portal. Was existiert, sind einige quelloffene Community-Projekte im niedrigen zwei- bis dreistelligen Sternebereich — und alle, die sich prüfen ließen, zielen auf V20 oder älter. Wegen des oben beschriebenen Bruchs laufen sie auf einer V21-Installation nicht.

Drei Punkte sind unabhängig vom Reifegrad dieser Projekte belastbar.

Erstens: Jede Anbindung erbt sämtliche Openness-Voraussetzungen. Ein lizenziertes TIA Portal auf demselben Rechner, die Windows-Gruppe, die Whitelist, die Optionspakete. Auch Siemens’ eigener Engineering-Assistent ist ein Openness-Client mit genau diesen Voraussetzungen — er hat keine privilegierte interne Schnittstelle. Damit gibt es auch keine Variante „KI ohne TIA-Lizenz“.

Zweitens: Ein Sprachmodell kann über Openness nichts direkt programmieren. Es erzeugt Text — SCL oder XML — und der einzige belastbare Prüfer danach ist der TIA-Übersetzer. Wie weit das trägt, zeigt eine Untersuchung aus dem Umfeld verifizierten Codes.

Ohne diese Schleife scheitert also etwa jeder zweite Versuch schon vor der inhaltlichen Prüfung. Und auch mit ihr lautet die Aussage am Ende „übersetzbar“, nicht „richtig“.

Drittens — und das ist der Punkt für die Freigabe: Openness kann Hardware und Software in eine CPU laden. Eine Anbindung, die Openness-Funktionen ungefiltert an ein Sprachmodell durchreicht, kann damit grundsätzlich in eine laufende Anlage schreiben. Wer so etwas freigibt, sollte die Liste der freigegebenen Funktionen kennen und den Zugriff auf lesende Operationen begrenzen, solange kein belastbarer Prüfweg dahintersteht.

Wer die Entwicklung verfolgt, prüft am besten zwei Dinge regelmäßig: ob eines der Projekte auf V21 portiert wurde, und ob das neue textbasierte Quellformat dort unterstützt wird — es ist für Sprachmodelle deutlich besser geeignet als XML mit internen Kennungen.