Was ist ein HMI? Bedienebene, Web-HMI und Anbindung an die IT

Ein HMI besteht aus Anzeige, Eingabe und Schnittstelle. Für die Anbindung an die IT zählt die Schnittstelle.

Die Anzeige zeigt Werte, Zustände und Alarme, meist als Kombination aus Anlagenbild, Zahlenfeldern und Verlaufskurven. Die Eingabe erfolgt über Touch, Tasten oder beides. Die Schnittstelle verbindet das Panel mit der Steuerung, früher seriell über RS232 oder RS485, heute überwiegend über Ethernet.

Für die Anbindung an die IT zählt vor allem, ob das Panel selbst netzwerkfähig ist oder nur an der Steuerung hängt. Im zweiten Fall führt der Weg in die IT über die Steuerung dahinter. Das ist oft die sauberere Lösung: Die Steuerung hält den Zustand ohnehin, und das Panel ist nur eine Sicht darauf. Eine Anbindung, die stattdessen am Panel ansetzt, hängt an einem Anzeigegerät, das beim nächsten Umbau ausgetauscht wird, und damit an der kurzlebigsten Stelle der Anlage.

Was ein HMI fachlich leistet und welche Darstellungsformen üblich sind, behandelt Was ist ein HMI auf manubes.

Ein HMI bedient eine Maschine oder einen Bereich, ein SCADA führt viele davon zusammen. Das HMI am Extruder zeigt den Extruder, das SCADA alle Extruder mit ihren Alarmen und ihrer Historie und stellt ihre Werte gegeneinander. Ein HMI kann Bestandteil eines SCADA sein. Unterscheiden lassen sich beide am Umfang: Eine Oberfläche, die eine Anlage bedient, ist ein HMI, eine, die einen Anlagenverbund überwacht, ein SCADA.

Für die Anbindung heißt das: Historie und Vergleich über mehrere Anlagen liegen beim SCADA, nicht am Panel. Werte für eine Auswertung kommen deshalb aus der Steuerung oder aus dem SCADA und selten aus dem HMI selbst, aus demselben Grund wie oben bei einer Anbindung, die am Panel ansetzt.

Die ausführliche Abgrenzung steht im Artikel Was ist SCADA? Aufbau, Abgrenzung zu HMI, MES und DCS.

Das HMI sitzt auf der Prozessleitebene der Automatisierungspyramide, gemeinsam mit SCADA. Unter ihm liegen die Steuerungen, über ihm das MES. Bei ISA-95 kommt das HMI nicht vor.

Diese Ordnung beschreibt Zuständigkeiten, nicht mehr die Datenwege. Ein ERP kann deshalb direkt Daten mit dieser Ebene austauschen, wenn die Werte dort bereits gesammelt und für Menschen aufbereitet vorliegen.

Mehr dazu: Was ist ISA-95? Fünf Ebenen, IEC 62264 und die Automatisierungspyramide

Ein HMI, dessen Oberfläche im Browser läuft statt auf einem fest verbauten Panel. Damit ändern sich Zugriff, Aktualisierung und Verfügbarkeit.

Der Zugriff ist nicht mehr an den Ort gebunden. Mit den nötigen Berechtigungen ist die Anlage vom Büro, vom Tablet oder aus dem Bereitschaftsdienst sichtbar. Darin liegt der Nutzen, und damit wird Sicherheit zur Voraussetzung.

Die Aktualisierung wird zentral. Ein Panel wird vor Ort aktualisiert, eine Weboberfläche einmal auf dem Server. Bei zwanzig Anlagen ist das ein anderer Aufwand.

Die Verfügbarkeit verschiebt sich. Ein lokales Panel funktioniert, solange die Maschine läuft. Ein Web-HMI braucht zusätzlich das Netz und den Server dahinter. Deshalb ist es sinnvoll, eine lokale Bedienebene zu behalten, auch wenn daneben eine Weboberfläche existiert. Das Web-HMI löst das Panel dann nicht ab, beide teilen sich die Arbeit: Das Eingreifen in die Maschine bleibt am Panel, weil es auch bei gestörtem Netz funktionieren muss. Beobachten, Vergleichen und Auswerten wandern ins Web, weil sie dort für mehr Menschen erreichbar sind und nicht jeder dafür in die Halle laufen muss. Abläufe lassen sich an beiden Stellen anstoßen.

Für die Weboberfläche daneben gibt es Web-HMIs aus der Cloud. Die Cloud-Plattform manubes etwa bietet eine grafische Prozessvisualisierung: Anlagen, Stationen oder Materialflüsse als dynamische Bilder, die Zustände in Echtzeit aus Live-Daten der Produktion zeigen, mit mobilem Zugriff auf die Visualisierungen. Schaltflächen im Prozessbild lassen sich mit Workflow-Automatisierungen verbinden und starten dann aus dem Bild heraus einen Workflow.

Ein Fall aus der Praxis: Laut einem Anwenderbericht von 2019 hatte bei STIHL jede Montagelinie einen eigenen lokalen SQL-Server, darüber lagen zentrale Datenbanken, die alle Linien zusammenfassten. Teile, Stücklisten und Produktionszeiträume standen lange vor Auftragsstart lokal bereit. „Dadurch kann man bei Verbindungsausfall den aktuellen und den Folgeauftrag noch fertigen“, sagte Dominik Feil, der damals bei STIHL seitens der IT die Produktion betreute. Der Bericht nennt für Deutschland 16 Installationen, dazu weitere in den Werken in den USA und China. Dahinter steht dieselbe Überlegung wie bei der lokalen Bedienebene, eine Schicht höher: Die Daten, die eine Linie bei einem Verbindungsausfall braucht, liegen an der Linie.

Ein Bediener drückt am Panel eine Schaltfläche, etwa Auftrag abschließen. Diese Schaltfläche setzt einen Wert in der Steuerung. Ein externes System liest die Steuerung zyklisch, in einem eingestellten Leseintervall. Dabei entsteht das Problem: Ein kurzer Tastendruck kann zwischen zwei Lesezyklen komplett verschwinden.

Die Lösung ist ein Handshake mit Antwortbit. Auf den Tastendruck hin setzt die Steuerung ein Trigger-Bit, das gesetzt bleibt. Das lesende System erkennt es, holt die zugehörigen Werte und setzt danach ein Antwortbit. Erst wenn die Steuerung dieses Antwortbit sieht, setzt sie den Trigger zurück und gibt die Schaltfläche wieder frei.

Damit ist der Vorgang quittiert. Bleibt das Antwortbit aus, kann die Steuerung das erkennen, vorausgesetzt, sie überwacht die Antwort mit einer eigenen Frist. Dann kann sie den Fehlschlag anzeigen, statt ihn stillschweigend zu verlieren. Ohne diesen Rückweg kann eine fehlende Rückmeldung erst auffallen, wenn am Monatsende die Zahlen nicht stimmen.

Ein Fall aus der Praxis, in dem die Eingabe ganz entfällt: Ein Traditionsunternehmen für Spezialchemikalien hat seine Abfüllanlage erneuert. Vorher meldete ein Mitarbeiter die Anzahl der abgefüllten Gebinde von Hand an das System zurück, klebte das Palettenetikett auf und tippte anschließend den Transportauftrag ein. „Bei der manuellen Eingabe der Daten zur Rückmeldung kam es vorher oft zu Tipp- und Eingabefehlern“, heißt es im Anwenderbericht. Mit der Inbetriebnahme am 1. Mai 2019 übernahm laut Bericht der OPC Router: Er fragte die angebundenen Systeme laufend ab, griff auf ein Telegramm hin die Gebindeanzahl und die Prozessauftragsnummer aus der Siemens-Steuerung ab und buchte sie per Remote Function Call in SAP, wo das Etikett entstand und maschinell angebracht wurde. Am Ende des Ablaufs gab der OPC Router die vollständige Meldung an die SPS zurück. Statt Daten von Hand einzugeben, kontrollierte laut Bericht nun ein Mitarbeiter die Arbeitsschritte der Maschine über ein Terminal. Einen Tastendruck, der verloren gehen könnte, gibt es damit nicht mehr. Wird das Telegramm, das die Buchung anstößt, zyklisch gelesen, bleibt die Frage nach der Quittung trotzdem bestehen; sie wandert vom Bediener in die Steuerung.

Wenn eine Anbindung Werte puffert und später nachliefert, kommen sie mit Verzögerung an. Für eine Datenbank ist das richtig: Der Wert von vorhin gehört in die Historie, auch wenn er erst jetzt geschrieben wird.

Für eine Anzeige des aktuellen Zustands ist es falsch. Ein Anlagenbild soll den Zustand von jetzt zeigen. Ein nachgelieferter Messwert von vor zwanzig Minuten ist dort eine Falschanzeige, und wenn das Bild keinen Zeitstempel zeigt, sieht ihm niemand an, wie alt er ist.

Für die Projektierung heißt das: Werte, die einen aktuellen Zustand anzeigen, puffert man nicht, damit sie nach einer Störung nicht verspätet nachgeliefert werden. Ereignisse und Zählwerte, die in eine Historie gehören, puffert man und liefert sie nach. Eine Verlaufskurve auf dem Panel gehört dabei zur Historie, nicht zum Zustand.

Ob ein Wert zum Zustand oder zur Historie gehört, ist schon bei der Projektierung festzulegen.

Was beim Betrieb liegt. Die Zuordnung „dieser Wert gehört auf ein Bild, jener in eine Historie“ trifft keine Software von selbst. Beim OPC Router sitzt der Puffer je Ablauf, dort Flow genannt. Laufen Zustandswerte und Historienwerte im selben Ablauf, lassen sie sich beim Puffern nicht mehr trennen. Die Trennung entsteht deshalb im Zuschnitt: getrennte Abläufe für getrennte Empfängerarten. Zu prüfen ist außerdem die Voreinstellung, denn es gibt eine Option, die den Puffer bei neu erstellten Abläufen automatisch mitbringt. Dort, wo gepuffert wird, sollte jeder Datensatz einen Zeitstempel tragen: Nachgereichte und aktuelle Werte kommen nicht zwingend in ihrer ursprünglichen Reihenfolge an, weil die Nachlieferung parallel zum laufenden Betrieb abgearbeitet wird.

Im OPC Router. Das Handbuch des OPC Routers nennt im Abschnitt darüber, wann Store and Forward nicht verwendet werden sollte, als ersten Ausschlussgrund den Fall, dass nur der aktuelle Wert zählt, mit dem Messwert auf einer Visualisierung und dem OPC-Tag als Beispielen. Die Funktion ist zweistufig und muss global und je Ablauf eingeschaltet werden. Je Ablauf gibt es dafür mehrere Wege: von Hand in den Einstellungen des Ablaufs oder über dessen Kontextmenü, über die Voreinstellung für neu erstellte Abläufe oder über eine Vorlage, deren Einstellung dann für alle daraus erstellten Abläufe gilt. Für einen Ablauf mit Zustandswerten ist diese Einstellung zu prüfen. Global stehen unter „Extras > Einstellungen“ außerdem die Vorhaltezeit in Stunden, die Speicherkapazität in Gigabyte und das Verhalten bei erreichter Kapazität: den Ablauf auf Fehler laufen lassen oder weitere Daten ignorieren.

Die Grenzen des Puffers: Nach Ablauf der Vorhaltezeit werden zu alte Werte verworfen, bei erreichter Speichergrenze greift das eingestellte Verhalten, und eine Übertragung, die wiederholt fehlschlägt, wird nach einigen Versuchen nicht weiter ausgeführt. Ein Nachweis, dass ein einzelner Wert angekommen ist, braucht deshalb einen eigenen Mechanismus; der Puffer liefert ihn nicht.

Ja. Ein HMI oder SCADA-System kann als Client auftreten und in einer Middleware eine Funktion aufrufen. Ein Bediener drückt auf Etikett drucken oder Charge abschließen, und damit startet ein ganzer Ablauf statt eines einzelnen Schreibvorgangs in die Steuerung: Daten aus dem ERP holen, Beleg erzeugen, Drucker ansteuern, Ergebnis zurückmelden.

Der Unterschied zum reinen Datenaustausch ist die Richtung der Initiative. Nicht die IT fragt die Anlage in kurzen Abständen ab, ob etwas passiert ist, sondern die Bedienebene meldet sich, wenn etwas passiert ist. Für Vorgänge, die ein Mensch auslöst, ist das der natürliche Weg. Er spart die Umwege über Merkerbits und Abfrageschleifen, und die beim Aufruf übergebenen Parameter stehen im Ablauf zur Verfügung: Sie lassen sich weiterverarbeiten und gezielt mitschreiben, statt dass jemand später eine Bitänderung interpretieren muss.

Ein Fall aus der Praxis: Beim Haftmaterial-Hersteller HERMA löste der Mitarbeiter am Schneidsystem einen Transportauftrag aus. Daraufhin benachrichtigte das System über den OPC Router einen Transportwagen, der die Rolle zur zentralen Verpackungsstation fuhr. Dort liefen Verpacken, Palettieren und Einschweißen aus den mitgelieferten Auftragsdaten, und die eingebundene Waage schickte das Gewicht an SAP, das daraus die Verlade- und Zollpapiere erzeugte. Der Anwenderbericht auf opc-router.de, dessen Firmenangaben sich auf das Geschäftsjahr 2017 beziehen, nennt 14 Maschinen und 35 Verbindungen zwischen Steuerungen und SAP, die über einen OPC Router gekoppelt waren, und rund 15.000 Telegramme pro Tag. Abgesichert war die Kommunikation mit SAP durch Remote Function Calls mit Handshake, nach demselben Prinzip wie das Antwortbit weiter oben.

Ein Bediener druckt ein Etikett, das Panel meldet einen Fehler, und das Etikett kommt trotzdem aus dem Drucker. Solche Fälle entstehen an der Grenze zwischen dem, was ein Mensch am Panel sieht, und dem, was im System passiert. An dieser Grenze gibt es keine gemeinsame Sicherung, und die folgenden Fehler liegen deshalb in der Bauart der Anbindung.

Der Bediener sieht einen Fehler, und die Aktion ist trotzdem gelaufen

Ein Panel löst einen Vorgang aus, etwa einen Etikettendruck. Die Zeitgrenze des Aufrufs läuft ab, bevor der Ablauf fertig ist. Das Panel meldet einen Fehlschlag, der Ablauf läuft weiter und tut, was er soll. Das Etikett wird gedruckt.

Die Ursache: Es gibt keine Transaktionsklammer zwischen Aufruf und Ablauf, nur zwei unabhängige Zeitgrenzen. Die eine begrenzt, wie lange der Aufrufer wartet, die andere, wie lange der Ablauf laufen darf. Ein Abbruch am Panel ist deshalb keine Aussage darüber, ob die Handlung stattgefunden hat, und kann es bauartbedingt auch nicht sein.

Das Symptom: Doppelte Etiketten, doppelte Buchungen, doppelte Mengenrückmeldungen nach einer Störung, weil jemand nach der Fehlermeldung noch einmal gedrückt hat.

Was beim Betrieb liegt. Die Zeitgrenzen müssen in der Projektierung aufeinander abgestimmt werden. Beim OPC Router sind es zwei getrennte Werte: die Wartezeit des aufrufenden Clients im Trigger-Dialog und das Flow-Timeout in den Flow-Einstellungen (im Handbuch auch Timeout der Verbindung), das ohne eigene Angabe bei 300 Sekunden liegt. Damit der Bediener das echte Ergebnis sieht, muss die Wartezeit die längste erwartete Laufzeit des Ablaufs überdecken. Die Bedienlogik am Panel darf aus einer Zeitüberschreitung keinen Schluss auf das Ergebnis ziehen. Ob die Maske daraufhin die Schaltfläche sperrt, zurückfragt oder den Zustand aus einem Ergebnis-Datenpunkt nachliest, steht im HMI-Projekt und nirgends sonst. Der Vorgang braucht außerdem einen fachlichen Schlüssel – Auftragsnummer, Chargennummer, Zählerstand –, den das Zielsystem vor dem Schreiben prüft. Ein bereits gelaufener Ablauf wird vom OPC Router nicht zurückgenommen.

Im OPC Router. Er kann die Bedienhandlung als OPC-UA-Methode bereitstellen, die das HMI oder SCADA als OPC-UA-Client aufruft. Der Aufruf arbeitet synchron, und der Statuscode der Antwort entsteht aus dem Transferergebnis: Erfolg wird zu Good, ein Abbruch zu Bad_OperationAbandoned, ein Fehler zu Bad mit dem Abbruchtext. Damit kann das Panel im Normalfall das echte Ergebnis sehen statt nur eine abgelaufene Wartezeit. Eingestellt wird das im Dialog des OPC-Methoden-Triggers. Das dortige Feld Timeout begrenzt ausschließlich, wie lange der Aufrufer wartet; es beendet den Transfer nicht. Einen laufenden Transfer beendet allein das Flow-Timeout.

Die Grenze beschreibt das Handbuch: Die beiden Zeitgrenzen sind unabhängig, eine Klammer, die Aufruf und Ablauf zu einer Transaktion macht, gibt es nicht. Der OPC Router macht die Grenzen benannt und einstellbar, aufeinander abstimmen muss sie die Projektierung.

Aus dem offenen Ausgang einen definierten machen. Ein Fehlschlag lässt sich einklammern. Das Transferobjekt zur Fehlerbehandlung legt einen Teilablauf in einen TRY-Zweig und stellt das Ergebnis als auswertbaren Status bereit: Succeeded als Wahrheitswert, AttemptCount als Zahl der Versuche, Recovered für einen behandelten Fehler und LastErrorMessage als Fehlertext des letzten Versuchs. Diese Ausgänge lassen sich im selben Ablauf an ein weiteres Transferobjekt verdrahten und damit an die Steuerung oder das Panel zurückschreiben. Der CATCH-Zweig kann zusätzlich melden, etwa per E-Mail an den Schichtleiter. So wird aus „irgendetwas ist schiefgegangen“ ein Satz, den das HMI anzeigen kann.

Die automatische Wiederholung: Sie ist voreingestellt ausgeschaltet. Sie führt den kompletten TRY-Zweig erneut aus, auch die Schritte, die vorher schon erfolgreich waren. Eingeschaltet für einen Ablauf, der nicht mehrfach laufen darf, erzeugt sie die doppelte Buchung, die oben als Symptom steht. Einstellbar sind bis zu 4 Wiederholungen, voreingestellt 3, mit einer Wartezeit von voreingestellt 1 Sekunde; für den Aufruf eines Zweigs gilt ein Zeitlimit von 30 Sekunden, was länger läuft, zählt als fehlgeschlagener Versuch. Und ohne CATCH-Zweig wird ein endgültiger Fehlschlag verschluckt: Der Transfer bleibt grün. Damit nachfolgende Schritte darauf reagieren, müssen die Status-Ausgänge ausgewertet werden, etwa Succeeded = false und der Fehlertext in LastErrorMessage.

Zweimal gedrückt heißt nicht zweimal übertragen

Der Handshake mit Antwortbit hat selbst ein Loch. Ändert sich das Trigger-Bit innerhalb eines Lesezyklus zweimal, bemerkt der Leser die zweite Änderung nicht. Der Transfer unterbleibt, und damit auch das Antwortbit. Das ist der Fall bei einem schnellen zweiten Tastendruck, zu sehen im unteren Teil des Bildes oben.

Die Ursache: Zwischen Steuerung und lesendem System wird abgetastet, nicht benachrichtigt. Die Anbindung meldet den Stand zum Lesezeitpunkt, keine Flankenfolge. Was zwischen zwei Zyklen passiert, existiert für den Leser nicht, weil es nirgends aufgehoben wird. Kein Empfänger kann den verlorenen Druck zurückholen, auch nicht im Nachhinein.

Wie groß das Zeitfenster ist, hängt am eingestellten Leseintervall. Einen Richtwert gibt das Handbuch des OPC Routers dafür nicht vor: Der Wert ist projektierbar, „0“ steht für die schnellstmögliche Rate des Servers, und in einem Leistungstest des Handbuchs steht er auf 1.000 Millisekunden, in einem anderen auf 250. Ein Bediener schafft zwei Tastendrücke in deutlich weniger als einer Sekunde, und eine Steuerung, die ein Bit setzt und im nächsten Zyklus zurücknimmt, erst recht, sobald ihr Zyklus kürzer ist als das Leseintervall: Dann kann das Bit vollständig zwischen zwei Lesezeitpunkte fallen.

Deshalb ist die Frist aus dem Handshake weiter oben Pflicht: Der einzige Ort, an dem das Ausbleiben bemerkt werden kann, ist die Seite, die den Vorgang angestoßen hat. Beim verlorenen zweiten Druck kommt keine Quittung, die man sehen könnte. Bemerkt wird nur, dass sie ausbleibt, und auch das erst, wenn die Steuerung das Antwortbit mit einer eigenen Zeitüberwachung verfolgt, die nach der Frist eskaliert, statt weiter zu warten.

Was beim Betrieb liegt. Das Handbuch des OPC Routers schreibt der Steuerung drei Pflichten im SPS-Programm ausdrücklich zu. Eine Zeitüberwachung auf das Antwortbit, die den Sendevorgang nach einer festgelegten Frist erneut anstößt und nach mehreren erfolglosen Wiederholungen als Fehler behandelt, also meldet oder eskaliert. Das Handshake-Bit nur von einer Seite beschreiben: Die Steuerung setzt den Trigger-Datenpunkt selbst zurück, nachdem sie die Antwort erhalten hat. Und den Trigger zuletzt schreiben: erst alle zusammengehörenden Werte, dann das Bit.

Im OPC Router. Der Handshake selbst liegt als fertige Projektierung vor. Der Bit-Trigger löst aus, sobald der Trigger-Datenpunkt einen von 0 verschiedenen Wert annimmt. Dazu gehören mehrere Einstellungen, die zusammen gesetzt werden: „Bit zurücksetzen“ bleibt deaktiviert, weil ein Handshake-Bit nur von einer Seite beschrieben werden soll; „Antwortbit aktiv“ wird eingeschaltet und bekommt einen logischen Bit-Datenpunkt; „Antwortbit zurücksetzen nach“ legt die Zeitspanne fest, nach der der OPC Router dieses Bit selbst wieder auf 0 setzt. Optional kommt ein Fehlerbit dazu, das bei fehlerhaftem Transfer gesetzt wird. Für ein Trigger-Bit, das gesetzt bleibt, gibt es außerdem „Warten auf fallende Flanke“: Eingeschaltet löst der Trigger einmal aus und berücksichtigt das Bit erst nach einem Wechsel von 1 auf 0 wieder, statt in jedem Lesezyklus erneut auszulösen. Ohne dass es eingestellt werden muss, wartet der OPC Router nach dem Auslösen einen zusätzlichen Lesezyklus, damit die Steuerung alle zusammengehörenden Werte schreiben konnte. Das Leseintervall selbst steht als Sample Rate im Reiter „Erweitert“ der OPC-UA-Anbindung.

Die zweite bewährte Form ist der Message-Trigger, ein Zähler statt eines Bits. Statt ein Bit zu setzen, erhöht die Steuerung bei jedem neuen Datensatz einen Zähler um 1, und der Message-Trigger löst bei jeder Änderung dieses numerischen Datenpunkts aus. Damit ist jeder Vorgang durchnummeriert statt nur gesetzt oder nicht gesetzt. Der Antwort-Datenpunkt darf dann ebenfalls ein Zähler sein, sodass die Steuerung Message-ID und Antwort-ID vergleicht, statt auf ein Bit zu warten. Dazu kommt ein Feld, das der Bit-Trigger nicht hat. Beim Start auslösen kennt die Einstellung nur bei ungleichen Message- und Antwort-IDs: Nach einem Neustart löst der Trigger dann aus, wenn die letzte Antwort noch fehlt.

Was auch der Zähler nicht leistet. Er macht den Verlust nachweisbar, nicht unmöglich. Springt der Zähler zwischen zwei Lesezeitpunkten um 2, etwa von 5 auf 7, entsteht nur ein Transfer. Das ist ein Fehler der Sendeseite: Die Steuerung hat den nächsten Datensatz geschrieben, bevor die Antwort auf den vorigen kam. Am Zählerstand ist die Lücke zu sehen, beim Bit bliebe sie spurlos. Wird der Zählerstand mitgeschrieben, wie es das Handbuch empfiehlt, lässt sich nachvollziehen, ob Datensätze fehlen oder doppelt übertragen wurden. Ausgewertet wird das außerhalb der Middleware. Die Lücke vermeiden muss die Steuerung: Sie schreibt den nächsten Datensatz erst nach der Antwort, und auch die Zeitüberwachung auf den Antwortzähler bleibt in der Steuerung.

Nach einem Verbindungsabriss fehlen die anstehenden Alarme

Ein System, das Alarme abonniert, um sie weiterzuleiten, bekommt nach einem Verbindungsaufbau nur noch neue Zustandswechsel zu sehen. Alarme, die bereits aktiv und unquittiert anstehen, erscheinen nicht.

Die Ursache: Ein Abonnement ist ein Änderungsstrom, keine Zustandsabfrage. Ein stehender Alarm erzeugt kein Ereignis, weil sich nichts ändert, und der Strom hat keine Vergangenheit: Er beginnt im Augenblick des Abonnierens. Für diesen Fall gibt es in OPC UA einen gesonderten Aufruf, der den Bestand einmal nachreicht. Wo er nicht ausgelöst wird, zeigt die Übersicht bauartbedingt nur Zustandswechsel, nicht den Bestand.

Das Symptom: Nach einem Neustart ist die Alarmübersicht leer, obwohl am Panel rote Meldungen stehen. Ein Alarm erscheint in der Weiterleitung erst mit seiner Quittierung, also inhaltlich verkehrt herum.

Was beim Betrieb liegt. Hier liegt die Last fast vollständig beim Betreiber, weil die Lücke aus der Bauart des Abonnements folgt. Eine Alarmweiterleitung darf nicht die einzige Quelle sein, solange der Bestand nicht abgeglichen wird. Der Bestandsabgleich gehört projektiert, entweder über einen Methodenaufruf, dessen Funktionieren im konkreten Projekt vorher getestet wird, oder über ein zyklisches Lesen auf Zustandsdatenpunkte, die die Steuerung ohnehin führt, also über Werte statt über Ereignisse. Was der OPC-UA-Server der Anlage anbietet, entscheidet mit: Welche Knoten welche Ereignisse bereitstellen, steht in dessen eigener Dokumentation, nicht in der der Middleware.

Im OPC Router. Er bringt einen Alarm- und Event-Trigger mit, der auf Ereignisse eines OPC-UA-Servers reagiert. Jeder Zustandswechsel ist dabei ein eigenes Ereignis und löst einen Transfer aus, auch Quittieren und Bestätigen; die Middleware selbst quittiert nichts. Den Bestand nachzureichen ist dagegen keine Eigenschaft eines Abonnements. Der gesonderte Aufruf, den OPC UA dafür vorsieht, muss ausgelöst werden, er passiert nicht von allein. Für eine Alarmweiterleitung gehört deshalb ins Projekt, wie der Bestand nach einem Wiederanlauf abgeglichen wird, und die Prüfung, ob der eingesetzte OPC-UA-Server diesen Aufruf anbietet. Bausteine, mit denen sich ein solcher Abgleich anstoßen ließe, gibt es: ein Transferobjekt für OPC-Methodenaufrufe und Trigger, die zeitgesteuert auslösen. Ob sie im konkreten Fall tragen, zeigt ein Test im Projekt.