Ist REST API immer für die Industrie geeignet? Wann sind Warteschlangen, Broker und ereignisgesteuerte Kommunikation die bessere Wahl?

Die Frage, ob sich ein REST API für die Industrie eignet, ist heute keine Debatte mehr über einen bevorzugten Integrationsstil, sondern eine Entscheidung darüber, an welcher Stelle ein Projekt Kosten, Verzögerungen und operative Verantwortung in Kauf nimmt. In industriellen Umgebungen hört eine Kommunikationsschnittstelle sehr schnell auf, nur eine „technische Schicht“ zu sein, und beeinflusst stattdessen die Prozesskontinuität, die Reproduzierbarkeit von Abläufen, die Auditierbarkeit und den Umgang mit Störungen. REST funktioniert dort gut, wo ein einfacher Aufruf, eine eindeutige Antwort und eine klare Kontrolle über den Status der Anfrage erwartet werden. Problematisch wird es, wenn das System trotz einer vorübergehenden Nichtverfügbarkeit eines Beteiligten weiterarbeiten muss, wenn Nachrichten mit Bestätigung zugestellt werden müssen oder wenn ein einzelnes Ereignis Auswirkungen in mehreren unabhängigen Bereichen auslösen soll. Dann ist die Wahl zwischen synchroner Anfrage und Warteschlange, Broker oder ereignisgesteuerter Kommunikation technisch nicht mehr neutral.

Gerade jetzt ist das relevant, weil immer mehr Industrieprojekte Steuerung, Instandhaltung, Qualitätssysteme, Produktionsreporting und externe Dienste zu einer einzigen Abhängigkeitskette verbinden. Wenn die Architektur ausschließlich auf synchronen Aufrufen basiert, erhält das Team oft ein System, das nur scheinbar einfach ist, bei wachsender Zahl von Integrationen, instabilen Netzen oder der Anforderung eines lückenlosen Ereignisnachweises jedoch fragil wird. Die Kosten einer solchen Entscheidung zeigen sich nicht in der Funktionsdemo, sondern später: wenn Prozesse durch eine nicht verfügbare Komponente blockiert werden, wenn sich der Ablauf eines Vorfalls nur schwer rekonstruieren lässt, wenn Zustände zwischen Systemen manuell abgeglichen werden müssen und wenn darüber gestritten wird, ob eine Operation tatsächlich ausgeführt oder nur angestoßen wurde. Für Product Owner und Projektleiter ist das praktische Kriterium einfach: Es muss geklärt werden, ob ein bestimmter Datenaustausch den Charakter von „Frage–Antwort hier und jetzt“ hat oder eher „einen Sachverhalt erfassen und seine weitere Verarbeitung auch bei Störungen sicherstellen“ bedeutet. Davon hängt nicht nur die Technologie ab, sondern auch das Verantwortungsmodell zwischen den Teams.

In der Praxis zeigt sich das besonders deutlich in Maschinensystemen, in denen eine einzelne Bedienhandlung oder ein einzelnes Prozessereignis an mehreren Stellen erfasst, weitergegeben und bestätigt werden muss. Wenn eine übergeordnete Anwendung synchrone Anfragen an nachgelagerte Dienste sendet und auf alle Antworten wartet, kann ein kurzfristiges Problem in nur einem Element die gesamte Sequenz anhalten, obwohl ein Teil der geschäftlichen Auswirkungen unabhängig eintreten sollte. Ein Broker oder eine Warteschlange ermöglicht es dagegen, den Zeitpunkt der Informationsannahme vom Zeitpunkt ihrer Verarbeitung zu entkoppeln, die Ereignisspur zu erhalten und Wiederholungen nach einem Fehler leichter zu steuern. Das bedeutet nicht, dass ereignisgesteuerte Kommunikation immer besser ist: Wenn eine sofortige Entscheidung erforderlich ist, die die weitere Bewegung der Maschine blockiert, oder wenn der Bediener umgehend eine verbindliche Antwort erhalten muss, kann ein asynchrones Modell ohne sauber definierte Zwischenzustände die Unsicherheit erhöhen. Deshalb sollte bereits zu Beginn des Projekts nicht nur die Antwortzeit gemessen werden, sondern auch die Zahl verlorener oder duplizierter Nachrichten, die Zeit für den Abgleich widersprüchlicher Zustände und die Möglichkeit, die Ereignisfolge nach einem Vorfall zu rekonstruieren.

Dieses Thema berührt ganz natürlich die Risikobeurteilung in Industrieprojekten, denn die Wahl der Kommunikationsart beeinflusst die Auswirkung eines Fehlers, die Erkennbarkeit von Unregelmäßigkeiten und die Möglichkeit, wirksame Maßnahmen zur Risikominderung einzuführen. Wenn über die Schnittstelle Funktionen laufen, deren fehlerhafte Ausführung zu einem unbeabsichtigten Anlauf, einer gefährlichen Zustandsänderung oder zum Verlust der Kontrolle über Energie führen kann, ist das Thema nicht mehr ausschließlich IT-bezogen, sondern gehört in den Bereich der Auslegung des Maschinensystems und der Bewertung von Schutzmaßnahmen. An diesem Punkt verläuft auch die Grenze, ab der verwandte Fragestellungen betrachtet werden müssen, darunter Schutz vor unerwartetem Anlauf sowie die praktische Risikobeurteilung nach DIN EN ISO 12100. Anders gesagt: Die Entscheidung für REST, eine Warteschlange oder einen Broker sollte nicht nach einer Integrationsdemo fallen, sondern dann, wenn das Team die Folgen einer fehlerhaften oder verzögerten Nachricht für Prozess, Sicherheit und Nachvollziehbarkeit benennen kann.

Wo Kosten oder Risiken am häufigsten steigen

Die meisten Fehlentscheidungen entstehen nicht durch die Wahl der „falschen Technologie“, sondern dadurch, dass ein REST API Aufgaben zugewiesen wird, für die es nicht ausgelegt ist. In der Industrie steigen die Kosten dann, wenn eine Anfrage-Antwort-Schnittstelle Kommunikation tragen soll, die empfindlich auf kurzfristige Nichtverfügbarkeit, die Reihenfolge von Ereignissen oder die Notwendigkeit einer zuverlässigen Ausführungsbestätigung reagiert. Wenn ein System lediglich den aktuellen Zustand eines Geräts auslesen oder einen Befehl annehmen soll, dessen Ausbleiben sich leicht erkennen und ohne Nebenwirkungen erneut auslösen lässt, kann REST ausreichend sein. Hängt das Ergebnis jedoch davon ab, dass eine Nachricht genau einmal, in der richtigen Reihenfolge und mit der Möglichkeit zur Rekonstruktion der Historie nach einem Vorfall ankommt, übersteigen die Kosten zur Umgehung der Grenzen von REST schnell die scheinbare Einfachheit der Implementierung. In der Praxis bedeutet das zusätzliche Wiederhollogik, eigene Puffermechanismen, den Abgleich voneinander abweichender Zustände und eine schwierigere Klärung von Verantwortlichkeiten, wenn ein Gerät eine Operation später als erwartet oder sogar doppelt ausgeführt hat.

In der Entwurfsphase wirkt das Problem meist harmlos: Das Team geht von einem stabilen Netzwerk, der ständigen Verfügbarkeit von Diensten und einem eindeutigen Zustand auf beiden Seiten der Integration aus. In industriellen Umgebungen halten diese Annahmen jedoch selten lange stand. Es kommt zu Verbindungsunterbrechungen, einem Neustart des Geräts, einem Update eines zwischengeschalteten Systems oder schlicht zu Überlastung während eines Produktionswechsels. Dann beginnt eine Architektur, die ausschließlich auf synchronen Aufrufen basiert, das Risiko auf Anwendungen und Bedienpersonal zu verlagern. Die Projektkosten steigen nicht nur durch Programmkorrekturen, sondern auch durch Wiederherstellungstests, zusätzliche Betriebsabläufe und Diskussionen darüber, welche Seite „hätte wissen müssen“, dass die Anforderung nicht ausgeführt wurde. Das praktische Entscheidungskriterium ist einfach: Wenn die Nichtverfügbarkeit des Empfängers den Sender nicht stoppen darf und die Nachricht sicher gespeichert und später verarbeitet werden muss, sollten Queue, Broker oder ereignisgesteuerte Kommunikation anstelle eines reinen REST-Ansatzes ernsthaft geprüft werden.

Ein gutes Beispiel ist die Integration eines Leitsystems mit einer Linie, bei der ein System eine Rezepturänderung anstößt und mehrere andere diese Änderung übernehmen, bestätigen und zum richtigen Zeitpunkt im Zyklus anwenden müssen. Mit REST lässt sich ein Aufruf wie „Parameter setzen“ leicht umsetzen, schwieriger ist es jedoch sicherzustellen, dass alle betroffenen Komponenten dieselbe Information erhalten haben, dass eine ältere Nachricht keine neuere überschreibt und dass sich nach einer Störung nachvollziehen lässt, wer welche Anweisung gesehen hat. Ein Event-Broker oder eine Queue ordnet dieses Problem anders: Die Nachricht wird zu einer dauerhaften Tatsache im System, die sich nachverfolgen, erneut verarbeiten und von mehreren Empfängern unabhängig abrufen lässt. Das ist keine rein technische Entscheidung. Davon hängt ab, ob sich bei einer Chargenreklamation, einem Stillstand oder einem Vorfall der Entscheidungsverlauf des Systems nachweisen lässt und damit auch vertragliche, operative oder interne Verantwortung zugeordnet werden kann. Wo Nachvollziehbarkeit wichtig ist, sollte man nicht nur die Antwortlatenz messen, sondern auch die Anzahl der Nachrichten, die erneut gesendet werden müssen, die Zeit für den Abgleich des Zustands nach einer Störung sowie die Möglichkeit, die Ereignisfolge ohne manuelle Rekonstruktion aus mehreren Protokollen wiederherzustellen.

Dieses Thema geht in den Bereich der Risikobeurteilung nach DIN EN ISO 12100 über, wenn eine fehlerhafte oder verspätete Nachricht das Verhalten einer Maschine, eines Prozesses oder einer Schutzeinrichtung verändern kann. Dann reicht die Frage nach dem Integrationskomfort nicht mehr aus; vielmehr müssen Auswirkung, Erkennbarkeit und die Möglichkeit zur Begrenzung der Folgen bewertet werden, was mit der aus ISO 12100 bekannten Praxis übereinstimmt. Wenn die Kommunikation sicherheitsbezogene Funktionen, Verriegelungen, Startbedingungen oder Bestätigungen des Energiezustands betrifft, verschiebt sich die Grenze der Konstruktionsverantwortung von der Anwendungsebene auf die Ebene des gesamten Maschinensystems. Ähnlich kann in Aktorsystemen, auch in hydraulischen, die falsche Annahme einer rechtzeitigen Informationsübertragung mit den Grundsätzen für die Auslegung von Schutzeinrichtungen und sicheren Zuständen kollidieren, was folgerichtig zu Fragestellungen führt, die mit DIN EN ISO 4413 verbunden sind. Mit anderen Worten: Queues und Broker sind nicht „per Definition besser“, werden aber dort zur richtigen Wahl, wo ein Projekt einen Kommunikationsausfall verkraften muss, ohne die Kontrolle, die Historie und die Verantwortung für ausgeführte Aktionen zu verlieren.

Wie man das Thema praktisch angeht

In der Praxis lautet die Frage nicht, ob eine REST API gut oder schlecht ist, sondern ob sie zu den Folgen von Fehlern, Verzögerungen und ausbleibenden Antworten im jeweiligen industriellen Prozess passt. Dient die Kommunikation vor allem dem Auslesen von Daten, dem Auslösen administrativer Vorgänge oder der Integration mit Geschäftssystemen, ist eine Anfrage-Antwort-Schnittstelle oft die einfachste und kostengünstigste Lösung. Problematisch wird es dann, wenn das Projekt einen kontinuierlichen Informationsaustausch trotz vorübergehender Nichtverfügbarkeit einer Seite, die geordnete Verarbeitung von Ereignissen oder die Pflicht voraussetzt, nachvollziehen zu können, wer wann und auf welcher Grundlage eine bestimmte Zustandsänderung ausgelöst hat. In einem solchen Fall senkt die Wahl von REST als Standardmechanismus häufig die Einstiegskosten, erhöht aber die Kosten für die Störungsbehandlung, den Zustandsabgleich nach einer Unterbrechung und die Aufklärung eines Vorfalls. Genau an diesem Punkt sind Queues, Broker und ereignisgesteuerte Kommunikation kein „architektonischer Zusatz“ mehr, sondern ein Instrument zur Begrenzung von Projektrisiken und operativer Verantwortung.

Für das Team und den Manager bedeutet das, eine Architekturentscheidung anhand mehrerer messbarer Prozesseigenschaften zu treffen und nicht nach den Vorlieben des Auftragnehmers. Das nützlichste Kriterium ist einfach: Es muss festgelegt werden, was mit einer Nachricht geschehen soll, wenn der Empfänger zum Zeitpunkt des Sendens nicht antwortet. Lautet die richtige Antwort „nichts Kritisches, der Vorgang kann sicher wiederholt oder verworfen werden“, reicht REST in der Regel aus. Muss die Nachricht dagegen erhalten bleiben, nach Wiederaufnahme des Betriebs zugestellt, genau einmal oder in einer nachweisbaren Reihenfolge verarbeitet werden, dann passt eine synchrone Architektur nicht mehr zu den Anforderungen des Prozesses. Es ist sinnvoll, dies bereits in der Konzeptphase als Abnahmekriterien festzuhalten: zulässige Dauer der Nichtverfügbarkeit des Partners, Verfahren für Wiederholungen, Regeln zur Deduplizierung, Möglichkeit zur Nachverfolgung der Ereigniskorrelation und Vorgehen zur Wiederherstellung des Zustands nach einer Störung. Ohne solche Festlegungen startet das Projekt scheinbar schneller, kehrt später jedoch in Form kostspieliger Integrationsänderungen, Streitigkeiten über den Verantwortungsumfang und schwer zu schließender betrieblicher Abweichungen zurück.

Ein gutes Beispiel ist eine Linie oder Fertigungszelle, in der das Leitsystem Aufträge übergibt und Steuerungen sowie Arbeitsstationen die Ausführung, Ausschuss, Sperren oder Wechsel zwischen Betriebsarten zurückmelden. Wenn jedes Ereignis per REST sofort „abgefragt“ wird, entsteht bei einem kurzzeitigen Verbindungsverlust sehr schnell eine Abweichung zwischen dem tatsächlichen Zustand und dem in der Anwendung sichtbaren Zustand. Aus Sicht der Produktion führt das zu manuellen Abstimmungen, aus Sicht der Qualität zu Lücken in der Chargenhistorie und aus Sicht der Instandhaltung zu Unsicherheit darüber, ob ein bestimmter Befehl ausgeführt oder nur gesendet wurde. Ein Broker mit persistenter Nachrichtenspeicherung löst nicht jedes Problem, schafft aber klare Zuständigkeiten: Der Sender hat das Ereignis übergeben, das vermittelnde System hat es gespeichert, der Empfänger hat es bestätigt – oder eben nicht. Das ist ein grundlegender Unterschied bei der Analyse von Stillstandsursachen und bei der Klärung, ob ein Fehler aus der Prozesslogik, einem Netzwerkausfall oder einer fehlerhaften Handlungsreihenfolge des Bedieners resultierte. Genau deshalb beeinflusst die Entscheidung für ein Kommunikationsmodell nicht nur die Implementierungskosten, sondern auch den Zeitaufwand für Inbetriebnahme, Service und Audit.

Dieses Thema geht in den Bereich der praktischen Risikobewertung über, sobald eine Nachricht nicht mehr nur Information ist, sondern Voraussetzung für das Verhalten einer Maschine, eines Prozesses oder einer Schutzeinrichtung. Wenn die Möglichkeit zum Starten, zum Wiederanlauf nach einem Stopp, zum Freigeben einer Sequenz oder zur Bestätigung eines sicheren Energiezustands von der korrekten Übertragung eines Zustands abhängt, wird die Integrationsentscheidung Teil einer Projektentscheidung mit deutlich größerem Gewicht. In einem solchen Fall ist nicht nur die Verfügbarkeit der Kommunikation zu bewerten, sondern auch die Auswirkung von Ausfall, Verzögerung, Duplikation und Fehlinterpretation; hier liegt die Methodik der Risikobeurteilung nach DIN EN ISO 12100 nahe. Dort wiederum, wo die Kommunikation Bedingungen zur Vermeidung eines unerwarteten Anlaufs berührt, darf die Informationsebene nicht als Ersatz für Lösungen betrachtet werden, die für Energieabschaltung und sicheren Zustand vorgesehen sind. Hier liegt die Grenze, an der das Thema bereits die Analyse des Schutzes gegen unerwartetes Anlaufen und darüber hinaus die Auslegung des Maschinensystems jenseits der reinen Funktionalität berührt. Anders gesagt: REST ist für die Industrie dann geeignet, wenn seine Grenzen vom Prozess bewusst akzeptiert werden; ist das nicht der Fall, sind Queueing-Mechanismen und ereignisbasierte Kommunikation meist die passendere Wahl, weil sie den Anforderungen an Kontinuität, Nachvollziehbarkeit und Beherrschung von Ausfallfolgen besser entsprechen.

Worauf bei der Umsetzung zu achten ist

Der häufigste Fehler bei der Umsetzung besteht darin, die Wahl zwischen REST API und ereignisbasierter Kommunikation als rein technische Entscheidung zu behandeln, obwohl sie in der Industrie operative und organisatorische Folgen hat. REST funktioniert nicht plötzlich nicht mehr, nur weil es in der Produktion eingesetzt wird, aber seine Grenzen zeigen sich sehr schnell dort, wo ein System Verbindungsunterbrechungen, ungleichmäßige Last, vorübergehende Nichtverfügbarkeit von Diensten und die spätere Rekonstruktion von Ereignisabläufen abfangen muss. Wenn die Architektur voraussetzt, dass jede Antwort sofort und beim ersten Versuch eintreffen muss, wird das Projekt fragil. Die Folge ist meist vorhersehbar: Die Integrationskosten steigen, Umgehungslösungen nehmen zu und die Verantwortung für einen fehlerhaften Prozesszustand verschwimmt zwischen den Systemlieferanten. Umgekehrt lösen Queues und Broker das Problem nicht automatisch; sie bringen eigene Risiken mit sich, etwa verzögerte Verarbeitung, doppelte Nachrichten, die Notwendigkeit der Sequenzierung und ein komplexeres Monitoring. Die Frage lautet daher nicht, ob REST grundsätzlich für die Industrie geeignet ist, sondern ob ein konkreter Prozess die Eigenschaften dieser Kommunikationsform toleriert, ohne das Risiko auf Produktion, Instandhaltung und Compliance zu verlagern.

In der Entwurfsphase empfiehlt sich ein einfaches Bewertungskriterium: Was genau passiert mit dem Prozess, wenn eine Nachricht nicht ankommt, zweimal ankommt oder zu spät ankommt? Wenn die Folge lediglich eine verzögerte Aktualisierung von Daten in einem Berichtssystem ist, kann REST ausreichend sein. Wenn jedoch das Ausbleiben einer Antwort eine Sequenz blockiert, einen manuellen Eingriff erzwingt, zum Verlust der Ausführungshistorie von Vorgängen führt oder die Klärung erschwert, wer auf welcher Grundlage eine Entscheidung getroffen hat, erzeugt eine synchrone Architektur bereits in der Inbetriebnahme Kosten. In einer solchen Situation schafft eine auf Queue oder Broker basierende Kommunikation die Verantwortlichkeiten in der Regel besser: Der Sender bestätigt die Übergabe, der Empfänger verarbeitet im eigenen Tempo, und das Team kann Rückstände, Wiederholungen und Fehler beobachten. Für den Projektleiter bedeutet das, nicht nur die Verfügbarkeit des Dienstes zu messen, sondern auch Kennzahlen wie Liegezeit der Nachricht, Anteil der Wiederholungen, Anzahl nicht abgeschlossener Nachrichten und die Zeit, die nach einem Vorfall für die Rekonstruktion der Ereignishistorie benötigt wird.

In der Praxis zeigt sich das Problem besonders dort, wo eine einzelne Integration mehrere Rollen gleichzeitig übernimmt. Zum Beispiel: Das Leitsystem sendet einen Auftrag an eine Station, empfängt die Ausführungsbestätigung und speichert nebenbei einen Zustand, der den weiteren Anlauf der Linie bedingt. Solange es um den Austausch von Geschäftsdaten geht, kann eine Verzögerung von einigen Sekunden akzeptabel sein. Wenn derselbe Kommunikationspfad jedoch die Ausführungsentscheidung im Prozess beeinflusst, ist er kein neutraler IT-Zusatz mehr. Dann wirkt sich die falsche Wahl des Mechanismus nicht nur auf die Kosten von Stillständen aus, sondern auch auf die Verantwortung dafür, ob das System bei fehlender Verbindung, einem Neustart des Dienstes oder einem Nachrichten-Duplikat vorhersehbar reagiert. Das ist der Punkt, an dem das Thema folgerichtig in den Bereich der Auslegung des Maschinensystems über die reine Funktionalität hinaus übergeht: Es muss entschieden werden, welche Ausfallfolgen tolerierbar sind und welche von der Integrationsebene getrennt werden müssen.

Diese Abgrenzung wird noch wichtiger, sobald die Kommunikation Bedingungen berührt, die mit der funktionalen Sicherheit oder der Risikobeurteilung zusammenhängen. Wenn die Erfüllung einer Bedingung für den sicheren Zustand, die Freigabe zum Wiederanlauf, die Bestätigung des Wegfalls gefährlicher Energie oder eine andere Schutzfunktion von der korrekten Datenübertragung abhängt, reicht eine gute Integrationspraxis nicht aus. Dann muss klar festgelegt werden, ob das betrachtete Element ausschließlich auf der Informationsebene bleibt oder bereits in den Bereich der Auslegung von Steuerungsteilen fällt, die für Sicherheitsfunktionen verantwortlich sind. An dieser Stelle stellen sich die eigentlichen Fragen aus dem Bereich der DIN EN ISO 13849-1 sowie der praktischen Risikobeurteilung nach ISO 12100, allerdings erst dann, wenn die Funktion und die Auswirkungen eines Fehlers definiert wurden. Für das Team bedeutet das, klar zu trennen zwischen dem, was über eine Queue, einen Broker oder REST abgewickelt werden kann, und dem, was keinesfalls ausschließlich auf allgemeiner Kommunikation basieren darf. Wird diese Grenze nicht zu Beginn festgelegt, zeigt sich der Aufwand später in Form von Projektänderungen, Abnahmekonflikten und einer schwer vertretbaren Entscheidungsverantwortung.