WinCC Unified: Was der Umstieg wirklich kostet

Die Comfort Panels sind im Produktauslauf, der Nachfolger heißt Unified Comfort Panel — so weit ist die Lage klar. Weniger klar ist, was der Umstieg kostet, und die Schätzung geht fast immer am selben Punkt daneben: Sie orientiert sich an der Anzahl der Bilder.

Die Bilder sind der einfachste Teil. Aufwand entsteht an drei anderen Stellen, und alle drei stehen in Siemens’ eigener Dokumentation: bei den Skripten, bei der Schnittstelle zur Steuerung und bei der Variablenzählung.

Wann der Umstieg überhaupt ansteht, hängt am Panel-Bestand: Die Termine der Comfort-Panel-Reihe stehen in der Termintabelle, der Weg dorthin unter den Migrationspfaden.

Dieser Artikel geht die drei Stellen der Reihe nach durch — mit dem, was Siemens dazu selbst schreibt, und mit dem, was daraus für ein Angebot folgt.

Was das Migrations-Add-in Data2Unified nicht übernimmt

Für den Weg vom Comfort Panel nach Unified gibt es das TIA-Portal-Add-in Data2Unified (Siemens-Beitrag 109770510). Es überträgt Bilder, Variablen, Meldungen, Archive sowie Text- und Grafiklisten und nimmt damit einen Teil der Arbeit ab — Siemens benennt ausdrücklich, wo es aufhört. Vorgeschaltet ist der Modernization Checker, der je Projekt ausweist, was konvertiert wird, was Handarbeit bleibt und was Unified nicht unterstützt; dieser Bericht gehört an den Anfang jeder Aufwandsschätzung.

Damit ist die entscheidende Frage für jedes Angebot beantwortet: Eine Eins-zu-eins-Migration gibt es nicht.

Die Trennung von der alten Architektur ist der Grund, warum Unified mehr kann. Die Aufwandsschätzung muss nur davon ausgehen.

Skripte: JavaScript, aber nicht wie im Browser

Der Wechsel von VBScript zu JavaScript wird meist als Modernisierung gelesen — endlich eine verbreitete Sprache. Dabei geht die wichtigere Eigenschaft unter: Die Skripte laufen serverseitig in einer Node.js-Umgebung, nicht im Browser des Bedieners.

Praktisch heißt das: Aufrufe, die man aus der Webentwicklung kennt, stehen nicht zur Verfügung — insbesondere nicht der direkte Abruf einer REST-Schnittstelle aus einem Bildskript heraus. Wer eine Anbindung an ein übergeordnetes System plant, plant sie an anderer Stelle — Siemens sieht dafür eine eigene Anwendung außerhalb der Runtime vor, auf dem Panel als Edge-App, am PC als beliebiges Programm, deren Ergebnisse über OpenPipe in HMI-Variablen landen. Auch fremde Node.js-Module lassen sich nicht laden; importierbar sind nur die globalen Module des Projekts.

An einem alltäglichen Bildskript lässt sich der Unterschied ablesen. Im Bestand steht es so da:

Sub Sollwert_Uebernehmen()
    Dim sollwert, grenze

    sollwert = SmartTags("HMI_Sollwert")
    grenze = SmartTags("Grenze_Oben")

    If sollwert > grenze Then
        sollwert = grenze
    End If

    SmartTags("SPS_Sollwert") = sollwert
End Sub

Dieselbe Aufgabe in Unified sieht anders aus. Der Unterschied, der die Planung betrifft, ist dabei nicht die Sprache, sondern der Ort der Ausführung:

export function Bild_Sollwert_OnTapped(item, x, y, modifiers, trigger) {
  let sollwert = Tags('HMI_Sollwert').Read();
  const grenze = Tags('Grenze_Oben').Read();

  if (sollwert > grenze) {
    sollwert = grenze;
  }

  Tags('SPS_Sollwert').Write(sollwert);

  // fetch() und XMLHttpRequest stehen hier nicht zur Verfügung:
  //
  //   const antwort = await fetch('http://mes.werk.intern/auftrag');
  //
  // Eine Anbindung an ein übergeordnetes System läuft außerhalb der
  // Runtime (Edge-App, OpenPipe) — nicht im Bild.
}

Zwei weitere Punkte, die Projektpläne kippen können:

Kein Debugger auf der Panel-Hardware. Ein Skript-Debugger existiert für die PC-Runtime und für die Simulation am Programmierrechner; auf der Panel-Hardware ist er nach dem Siemens-Umstiegsleitfaden nicht einsetzbar. Dort bleibt die Auswertung über die Trace-Ausgabe (Trace Viewer). Wer vor Ort ein Panel in Betrieb nimmt und ein Skript nicht zum Laufen bringt, kann sich nicht einfach anhängen — das gehört in die Zeitplanung der Inbetriebnahme.

Bereichszeiger: Was an der Schnittstelle zur Steuerung nachzubilden ist

Hier liegt der Teil, den Angebote regelmäßig übersehen. Die Bereichszeiger, über die Comfort-Projekte mit der Steuerung koordiniert werden, existieren in Unified nicht mehr — Bildnummer, Steuerungsauftrag, Datensatz, Datum/Uhrzeit, Koordinierung, Projektkennung. Siemens vermerkt im Umstiegsleitfaden für mehrere davon, sie ließen sich bei Bedarf auf Anwendungsebene nachbilden; ein Anwendungsbeispiel dafür ist der Siemens-Beitrag 109794243.

„Auf Anwendungsebene nachbilden“ heißt: Skripte und geplante Aufgaben im HMI-Projekt — und überall dort, wo Bausteine bisher die Bereichszeiger-Daten ausgewertet haben (Koordinierungsbits, Statuswort der Datensatzübergabe, Quittierung des Auftragsfachs), Anpassungen im SPS-Programm. Der Aufwand reicht damit aus der Bedienebene hinaus — ausgerechnet dorthin, wo ein Maschinenbauer seinen Standard am wenigsten gern anfasst.

Für die Uhrzeitsynchronisation, die bisher über einen Bereichszeiger lief, ist die saubere Lösung ohnehin eine andere: Zeitsynchronisation über NTP — das Unified Comfort Panel lässt sich als NTP-Client projektieren, Steuerung und Panel holen sich die Zeit von derselben Quelle, statt sie von Hand zwischen Panel und Steuerung zu schieben. Soll die Steuerung Zeitmaster bleiben, lässt sich eine S7-CPU als NTP-Server einrichten; soll das Panel die Zeit vorgeben, gibt es dafür die Systemfunktion SetPLCDateTime (seit V18 Update 2).

PowerTags: Wie WinCC Unified Arrays und Strukturen zählt

Die Variablenzahl wird in Unified anders gezählt — und sie ist beim Panel eine Gerätegrenze, bei der PC-Runtime die Lizenzstufe in PowerTags. Auf dem Comfort Panel zählt ein Array als eine Variable, unabhängig davon, wie viele Elemente es hat. In Unified zählen die Elemente einzeln — bei Arrays wie bei Strukturen: Ein Array mit fünf Elementen sind fünf PowerTags, ein Array aus drei Strukturen mit je zwei Elementen sind sechs.

Siemens führt das im Beitrag 109954953 an einem Rechenbeispiel vor — dort für die PC-Runtime, gezählt wird auf dem Panel nach derselben Regel. Es ist ein Beispiel und keine Formel — die Zahl aus dem eigenen Projekt ist immer das bessere Argument.

Für Strukturen gilt das nur zum Teil: Arrays aus Strukturen zählt schon das Comfort Panel je Element, der Sprung fällt dort kleiner aus. Ein Projekt mit vielen strukturierten Schnittstellen — also genau die saubere Bauweise, die man Maschinenbauern empfiehlt — trifft dafür eine andere Stelle: HMI-Variablen mit UDT-Struktur überträgt das Add-in laut Siemens-Beitrag 109770510 nicht, sie sind in Unified neu anzulegen.

Einen Ausweg gibt es für Arrays, die nur als Ganzes gebraucht werden — etwa Datensatzpuffer: Als Block projektiert („Array als Block“), zählt die Variable wieder als ein PowerTag. Der Preis: Die Elemente sind einzeln nicht mehr adressierbar, der Zugriff läuft blockweise per Skript, und es geht nur an S7-1200/1500.

Konsequenz für die Kalkulation: Die benötigte Variablenzahl lässt sich nicht aus dem bisherigen Projekt ablesen. Sie ist am konkreten Projekt zu zählen — beim Unified Comfort Panel gegen die Gerätegrenze von 8.000 Variablen, bei der PC-Runtime gegen die PowerTag-Stufe der Lizenz — bevor das Angebot rausgeht.

Ab TIA Portal V21 gibt es dagegen eine Variablenoptimierung. Sie hat allerdings eine Bedingung, die ausgerechnet fortgeschrittene Projekte trifft: Wer mit dynamischer Bindung arbeitet, also mit zur Laufzeit gebildeten Variablennamen, darf sie nicht aktivieren — das System erkennt solche Zugriffe nicht. Damit kollidiert die Optimierung mit einer Technik, die Siemens für Faceplate-Schnittstellen selbst anbietet — Variablennamen aus statischen und dynamischen Teilen. Dasselbe gilt für Variablennamen, die als Text an Systemfunktionen übergeben werden, für indirekte Adressierung, Faceplate-Popups und eine Runtime, die als OPC-UA-Server arbeitet; für Energy Suite und MQTT rät Siemens ebenfalls ab. Und: Beim Ein- oder Ausschalten der Optimierung entfällt das Laden von Änderungen, das Projekt wird komplett geladen. Sie gilt für Panel und PC-Runtime gleichermaßen — beim Panel zählt sie gegen die Gerätegrenze. Die Optimierung ist damit ein Hebel für neu aufgesetzte Projekte, kein Schalter, den man nachträglich umlegt.

Systemgrenzen des Unified Comfort Panels vor dem Bildentwurf

Für das Unified Comfort Panel gelten Systemgrenzen, die vor dem Entwurf bekannt sein sollten. Zwei davon überraschen im Projekt regelmäßig — die eine, weil sie je Array und nicht je Projekt gilt, die andere, weil im Datenblatt eine andere Zahl steht als die, mit der sich planen lässt.

Wer Bilder, Schriftarten und Trendpuffer nach der Datenblattzahl plant, plant zu großzügig.

Betriebssystem-Update, E-Mail und Faceplate-Versionen im Betrieb

Das Betriebssystem-Update löscht das Gerät.

E-Mail hängt an der Runtime-Version. Bis V20 gibt es aus der Unified-Anwendung heraus keine Systemfunktion für den Mailversand — das vorinstallierte E-Mail-Programm des Panels ist eine eigene App, Siemens verwies auf eine zusätzliche Edge-App. Seit V21 stellt Unified die Systemfunktion SendEmail bereit: SMTP-Server und Kontakte werden in den Runtime-Einstellungen hinterlegt, Voraussetzung ist ein aktiviertes Reporting, je Aufruf sind höchstens 20 Adressen möglich. Wer die Zeile „Störmeldung per E-Mail“ im Lastenheft hat, klärt also zuerst, welche Runtime auf dem Gerät läuft.

Faceplates hängen an der Geräteversion. Neue Faceplate-Funktionen kommen mit jeder TIA-Version dazu und sind nicht abwärtskompatibel; auf dem Gerät muss die passende Runtime laufen. Der dokumentierte Ausweg ist die „niedrigste Geräteversion“ des Faceplate-Typs: Für ältere Panel-Stände wird eine eigene Version des Typs mit niedrigerer Geräteversion angelegt — ohne die Funktionen der neueren Runtime. Bei Serienmaschinen mit unterschiedlichen Panel-Ständen im Feld wird die Pflege dieser Versionen zu einem eigenen Thema — eines, das man besser vor der ersten Auslieferung klärt.

Was das für die Entscheidung heißt

Der Umstieg lohnt sich dort, wo die Bedienebene ohnehin überarbeitet wird oder wo das Panel der Engpass ist. Er ist kein Wartungsvorgang, sondern ein Projekt mit eigenem Umfang — Siemens beziffert die Handarbeit für die Umstellung im Umstiegsleitfaden (Beitrag 109768002) je nach Projektgröße von mehreren Tagen bis zu mehreren Wochen.

Wer die Entscheidung vorbereitet, klärt am besten die Punkte unten, bevor Zahlen genannt werden. Sie bestimmen den Aufwand stärker als alles, was man auf den Bildern sieht — und sie gehören in dieselbe Betrachtung wie der Rest der Anlage, wenn ohnehin HMI-Engineering ansteht.