MQTT, OPC UA oder direkte Kommunikation mit der PLC – wie wählt man das passende Datenaustauschmodell für ein Industrieprojekt?

Die Wahl zwischen MQTT, OPC UA und direkter Kommunikation mit der PLC ist längst keine rein technische Entscheidung mehr. Heute wirkt sich diese Wahl zugleich auf die Systemarchitektur, die Inbetriebnahmekosten, den Verantwortungsbereich der Lieferanten und die Geschwindigkeit der Abnahmen aus. In der Praxis geht es nicht darum, welches Protokoll „besser“ ist, sondern welches Modell des Datenaustauschs der tatsächlichen Funktion des Projekts entspricht: ob eine einfache Signalintegration einer einzelnen Maschine benötigt wird, die Überwachung einer Linie, der Datenaustausch mit übergeordneten Systemen oder eine verteilte Steuerung, die in den kommenden Jahren weiter ausgebaut werden soll. Ein Fehler in dieser Phase zeigt sich meist nicht sofort im Labor, sondern erst später: bei der Inbetriebnahme, bei der Validierung, beim Wechsel des PLC-Lieferanten oder dann, wenn die Instandhaltung die Ursache einer Störung nachvollziehen will und sich herausstellt, dass die Daten inkonsistent, verzögert oder ohne Kontext sind.

Aus Projektsicht ist es am riskantesten, ein Kommunikationsmodell „aus Gewohnheit“ zu übernehmen. Die direkte Kommunikation mit der PLC wirkt oft attraktiv, weil sie schnellen Zugriff auf Register bietet und die erste Phase der Implementierung häufig verkürzt. Allerdings bindet eine solche Entscheidung die übergeordnete Anwendung leicht an eine konkrete Steuerung, an die Speicheradressierung und an die herstellerspezifische Implementierung. Bei einer Programmversionsänderung, einer Hardwaremigration oder einer Erweiterung der Linie kehren die Kosten dann in Form von Anpassungen, Regressionstests und Streitigkeiten über die Verantwortung für Prozessdaten zurück. MQTT eignet sich dagegen dort gut, wo eine schlanke Verteilung von Informationen und die Entkopplung von Sendern und Empfängern im Vordergrund stehen, erfordert aber eine bewusste Definition der Datensemantik, der Zustellqualität und der Regeln für den Betrieb des Brokers. OPC UA wird häufig als Kompromiss zwischen Interoperabilität und Informationsstruktur gewählt, löst die Probleme jedoch ebenfalls nicht von selbst: Ist das Datenmodell schlecht, liefert auch eine formal korrekte Kommunikation weiterhin die Grundlage für falsche operative Entscheidungen.

Ein praktisches Entscheidungskriterium ist einfach, wird aber oft übergangen: Zuerst muss geklärt werden, ob der jeweilige Austausch Informationen, Steuerung oder eine Funktion betrifft, die Einfluss auf die Sicherheit des Maschinenbetriebs hat. Dient der Kanal ausschließlich der Überwachung, dem Reporting oder der Übermittlung von Rezepturen in einem kontrollierten Modus, lassen sich die Lösungen unter dem Gesichtspunkt von Wartbarkeit, Skalierbarkeit und Integration vergleichen. Sollen über denselben Pfad jedoch Befehle laufen, die Bewegung, Arbeitsablauf, Verriegelungen oder den Bereitschaftszustand der Anlage beeinflussen, ist das Thema sofort nicht mehr nur eine IT-Frage. Dann sind nicht nur Verzögerung und Übertragungszuverlässigkeit zu bewerten, sondern auch die Vorhersehbarkeit des Verhaltens bei Verbindungsverlust, nach einem Systemneustart, nach einer Softwareversionsänderung und bei einer Fehlinterpretation des Zustands durch ein externes System. An diesem Punkt geht die Fragestellung ganz natürlich in eine praktische Risikobeurteilung für Projektentscheidungen über und teilweise auch in den Bereich der Absicherung gegen unerwartetes Anlaufen.

Ein typisches Beispiel aus Produktionsbetrieben sieht ähnlich aus: Anfangs geht es nur darum, Maschinendaten für die Visualisierung oder ein Berichtssystem auszulesen, daher entscheidet sich das Team für eine schnelle Verbindung direkt mit der PLC. Nach einigen Monaten wird über denselben Kanal das Schreiben von Sollwerten, das Quittieren von Alarmen und später auch das Auslösen von Fernservice-Befehlen abgewickelt. Formal „funktioniert“ das System weiterhin, aber die Architektur entspricht nicht mehr der tatsächlichen Verantwortung. Es ist nicht mehr klar, welche Ebene die maßgebliche Quelle für den Maschinenzustand ist, wer die Autorisierung von Änderungen verantwortet und wie nachgewiesen werden kann, dass die externe Kommunikation keinen Weg zu einem unbeabsichtigten Anlauf eröffnet. An diesem Punkt stellen sich nicht nur Fragen zum Protokoll, sondern auch zur Aufteilung der Funktionen zwischen Steuerungs-, Überwachungs- und Sicherheitsebene sowie – in Szenarien mit direkter Kommunikation zur PLC – zu den Folgen für die elektrische Ebene und die Verbindungen in der Maschine.

Die normative und konformitätsbezogene Bedeutung dieser Wahl zeigt sich also dann, wenn das Modell des Datenaustauschs das Verhalten der Maschine im Normalbetrieb und bei Störungen beeinflusst. Nicht jede Integration fällt sofort in den Bereich der Anforderungen an Sicherheitsfunktionen, aber jede sollte im Hinblick auf die Folgen eines Fehlers, eines Kommunikationsausfalls und einer fehlerhaften Handlungssequenz bewertet werden. Wenn über eine externe Schnittstelle der Maschinenzustand geändert, eine Verriegelung aufgehoben, ein Zyklus wieder aufgenommen oder die lokal vorgesehene Logik umgangen werden kann, muss die Kommunikationsentscheidung mit der Risikobeurteilung verknüpft werden und in geeigneten Fällen auch mit den Anforderungen zur Vermeidung eines unerwarteten Anlaufs. Deshalb muss dieses Thema jetzt, in der Phase der Annahmen und der Architektur, entschieden werden und nicht erst bei der Inbetriebnahme. Genau dann lassen sich noch messbare Kriterien festlegen: wer Eigentümer des Datenmodells ist, welche Folgen eines Verbindungsverlusts zulässig sind, wie viele Integrationspunkte nach einem PLC-Wechsel weiter zu pflegen sind und wie nachgewiesen wird, dass die Kommunikation keine Verantwortung über den geplanten Systemumfang hinaus verlagert.

Wo Kosten oder Risiken am häufigsten steigen

Die meisten Probleme entstehen nicht aus der Wahl zwischen MQTT, OPC UA und direkter Kommunikation mit der PLC selbst, sondern aus einer falschen Zuordnung der Rolle dieser Kommunikation in der Architektur der Maschine oder Anlage. Ein Projekt wird dann teuer, wenn ein Kanal, der für den Austausch von Hilfsdaten vorgesehen war, plötzlich operative Entscheidungen trägt, von denen die Prozesskontinuität, der Zustand der Anlage oder das Verhalten des Bedieners abhängen. In der Praxis bedeutet das: Das Team führt eine Lösung ein, die zunächst günstiger und schneller wirkt, und ergänzt später Umgehungslösungen: zusätzliche Hardwaresignale, lokale Verriegelungen, Ausnahmen in der Steuerungslogik, separate Mechanismen für Quittierungen und zur Wiederherstellung des Zustands nach einem Kommunikationsausfall. Genau diese späten Korrekturen verursachen Kosten, Verzögerungen und Streit über die Verantwortlichkeiten zwischen Integrator, Softwarelieferant und Endanwender. Ein praxisnahes Bewertungskriterium ist einfach: Es muss geklärt werden, ob das System bei Kommunikationsverlust lediglich „nicht mehr meldet“ oder ob es in einen gefährlichen, verfahrenstechnisch falschen oder produktionstechnisch kostspieligen Zustand geraten kann.

Bei Modellen mit direkter Kommunikation zur PLC steigt das Risiko meist dort, wo die Schnittstelle von einem bestimmten Hersteller, einer Softwareversion und der Speicherstruktur der Steuerung abhängig wird. Bei der Inbetriebnahme funktioniert das oft gut, die Kosten zeigen sich jedoch bei einem Steuerungswechsel, einer Modernisierung der Linie oder der Anbindung eines weiteren übergeordneten Systems. Jede solche Änderung erfordert ein erneutes Datenmapping, die Prüfung von Datentypen, Adressen, Berechtigungen und des Verhaltens bei Übertragungsfehlern. Aus Sicht des Produkteigentümers ist das wesentlich, weil die Instandhaltung nicht mehr planbar ist: Die Dokumentation verliert schnell ihre Aktualität, das Wissen verbleibt beim Auftragnehmer, und die Verantwortung für die Datenrichtigkeit verteilt sich auf mehrere Stellen. Wenn das Team keinen Verantwortlichen für das Datenmodell und kein Verfahren für dessen Änderung nach einem PLC-Update benennen kann, sind die Kosten künftiger Integration bereits im Projekt angelegt, auch wenn sie heute noch nicht sichtbar sind.

Bei MQTT und OPC UA liegt der häufigste Fehler anders: Es wird angenommen, dass die Kommunikationsebene das Problem der Datensemantik und der Zuverlässigkeit von Entscheidungen von selbst löst. MQTT eignet sich gut für die Übertragung von Ereignissen und Telemetriedaten, doch ohne eine saubere Definition von Topics, Zustellqualität, Retention und Quellenidentifikation entsteht leicht eine Situation, in der der Empfänger formal korrekte, aber unbrauchbare oder im Verhältnis zum Prozess verspätete Daten erhält. OPC UA wiederum strukturiert das Informationsmodell und erleichtert die Interoperabilität, doch seine Einführung wird oft unterschätzt, wenn die Geräte keine konsistent vorbereitete Struktur aus Objekten, Zuständen und Methoden haben. Ein praktisches Beispiel sind Rezepturen, Chargenquittierungen oder das ferngesteuerte Wiederanlaufen eines Zyklus: Wenn nicht eindeutig festgelegt ist, welche Seite den Eingang eines Befehls bestätigt, welche die Ausführung und welche nur den Eintrag ins Register, lässt sich nach dem ersten Vorfall nur schwer nachweisen, ob der Fehler in der Anwendungsebene, der Kommunikationsebene oder in der Maschinenlogik entstanden ist. Ein gutes Entscheidungskriterium ist hier nicht die „Modernität“ des Protokolls, sondern ob sich Zustand, Befehlsquelle, Gültigkeitsbedingungen und die Art der Wiederaufnahme des Betriebs nach einer Störung eindeutig beschreiben lassen. Im Kontext der Architektur der Kommunikation in der Industrieautomatisierung ist genau das der entscheidende Maßstab.

Eine weitere Kostenquelle ist die Vermischung von Betriebsanforderungen mit Anforderungen an Sicherheit und Konformität. Wenn über MQTT, OPC UA oder den direkten Zugriff auf die PLC Einfluss auf Maschinenbewegungen, das Lösen von Verriegelungen, die Anlaufsequenz oder auf Parameter mit Schutzfunktion genommen werden kann, ist das Thema nicht mehr nur informationstechnischer Natur. An diesem Punkt geht die Fragestellung unmittelbar in eine praktische Risikobeurteilung für Konstruktionsentscheidungen über: Zu bewerten ist nicht das Protokoll an sich, sondern die Auswirkung eines fehlerhaften Befehls, veralteter Daten, unbefugter Sollwertänderungen und von Inkonsistenzen zwischen lokalem und externem Zustand. In Aktoriksystemen, auch in hydraulischen, kann die Kommunikationsentscheidung die Umsetzung von Stoppfunktionen, Entlastung, Bewegungsblockierung und sicherer Wiederaufnahme des Betriebs beeinflussen und ist daher mitunter mit Konstruktionsanforderungen verknüpft, die bei der Konformitätsbewertung angewendet werden. Wenn eine externe Schnittstelle beginnt, auf Schutzfunktionen oder auf Verhaltensweisen einzuwirken, die der Bediener als Teil der Schutzeinrichtung wahrnimmt, muss sie als Bestandteil der Sicherheitsarchitektur behandelt werden und nicht als bloße komfortable Integrationsfunktion. In solchen Fällen kann auch der Bezug zur CE-Zertifizierung von Maschinen relevant werden.

Aus Sicht des Projektmanagements ist die sicherste Entscheidung diejenige, die sich nicht nur technisch, sondern auch organisatorisch begründen lässt. Deshalb sollten vor der Wahl des Modells für den Datenaustausch einige messbare Kriterien festgelegt werden: die Zeit bis zur Wiederherstellung des korrekten Betriebs nach einem Kommunikationsausfall, die Anzahl der Stellen, an denen Datenmapping gepflegt werden muss, die Art der Versionierung des Informationsmodells, der Umfang der Regressionstests nach einer PLC-Änderung sowie der Nachweis, dass die externe Kommunikation lokale Schutzmechanismen nicht umgeht. Wenn die Antworten auf diese Fragen unklar bleiben, bewegt sich das Projekt in der Regel bereits in einem Bereich, in dem die Kommunikationsentscheidung selbst einer formelleren Risikobeurteilung unterzogen werden sollte und in einem Teil der Anwendungen zudem mit den Konstruktionsanforderungen für Aktorik und Verriegelungsmittel abgestimmt werden muss. Das ist der Moment, in dem die Wahl zwischen MQTT, OPC UA und direkter Kommunikation keine Frage technischer Präferenz mehr ist, sondern eine Entscheidung über Instandhaltungskosten, Verantwortungsgrenzen und die Fehlertoleranz der gesamten Lösung. Für solche Projektentscheidungen in der Architekturphase ist eine frühzeitige Festlegung der Zuständigkeiten besonders wichtig.

Wie man das Thema praktisch angeht

In der Praxis sollte die Entscheidung zwischen MQTT, OPC UA und direkter Kommunikation mit der PLC nicht bei der Technologie beginnen, sondern mit der Frage, welche operative Wirkung der Datenaustausch erzielen soll und wer die Verantwortung für das Ergebnis trägt. Dienen die Daten ausschließlich der Überwachung, dem Reporting oder der Anbindung übergeordneter Systeme, haben die Änderungsrobustheit der Integration und ein klar verständliches Informationsmodell Priorität. Sobald auf der Gegenseite jedoch Befehle ins Spiel kommen, die den Zyklusablauf, Rezepte, Betriebszustände oder Freigabebedingungen beeinflussen, ist die Entscheidung nicht mehr nur eine IT-Frage. Dann wirkt sich die Art der Kommunikation unmittelbar auf die Verantwortungsgrenze zwischen Integrator, Maschinenhersteller, Instandhaltung und Prozesseigner aus. Das hat direkte Folgen für das Projekt: ein anderer Umfang der Abnahmetests, eine andere Änderungsdokumentation, ein anderer Umfang von Regressionen nach Änderungen am Steuerungsprogramm und andere Betriebskosten nach der Inbetriebnahme.

Ein gutes Entscheidungskriterium ist die Frage, wo sich die maßgebliche Quelle für den Maschinenzustand und die Freigabelogik befinden soll. Direkte Kommunikation mit der PLC kann dort sinnvoll sein, wo ein einfacher Ausführungspfad, wenige Zwischeninstanzen und ein vollständig vorhersehbares Verhalten auf Seiten der Steuerung zählen. Der Preis dafür ist meist eine enge Bindung der Lösung an ein konkretes PLC-Programm, an Datenadressen und an die Praxis eines einzelnen Anbieters. OPC UA ist sinnvoll, wenn das Projekt ein stabileres Datenmodell, eine bessere Trennung der Anwendungsebene vom Steuerungsprogramm und eine klarere Semantik der Signale erfordert. MQTT eignet sich vor allem dann, wenn Daten an mehrere Empfänger verteilt werden sollen, also über eine einzelne System-Steuerungs-Beziehung hinaus, und wenn ein mittelbares Kommunikationsmodell akzeptabel ist. Diese Wahl ist jedoch nicht neutral: Je mehr Zwischenschichten, Broker, Translatoren und Mappings vorhanden sind, desto größer ist die Fehlerfläche und desto schwieriger wird der Nachweis, dass eine Änderung auf der Integrationsseite die für die lokale Steuerung getroffenen Annahmen nicht verletzt.

Ein typischer Planungsfehler besteht darin, dass das Team ein für die Integration während der Inbetriebnahme bequemes Modell wählt und die Instandhaltungskosten erst später erkennt. Ein Praxisbeispiel: Ein übergeordnetes System soll Rezepte speichern und die Betriebsarten mehrerer Stationen umschalten. Erfolgt dies durch direktes Schreiben in Speicherbereiche der PLC, ist die Lösung anfangs schnell umgesetzt, aber jede Änderung der Datenstruktur in der Steuerung löst Tests auf beiden Seiten der Schnittstelle aus, und die Verantwortung für die Konsistenz der Rezepte beginnt zu verschwimmen. Wird derselbe Anwendungsfall stattdessen auf eindeutig definierten Objekten und Zuständen auf OPC UA-Seite aufgebaut, lassen sich Änderungen am Maschinenprogramm leichter von Änderungen im übergeordneten System trennen, allerdings müssen dann das Informationsmodell und seine Versionierung gepflegt werden. Der Einsatz von MQTT ist in einem solchen Szenario wiederum erst dann sinnvoll, wenn die Verteilung der Daten an mehrere Systeme tatsächlich erforderlich ist und die Kontrolle über Verzögerungen, Zustellbestätigung sowie die Wiederherstellung des Zustands nach einem Verbindungsverlust beschrieben und in Tests überprüft wurde. Andernfalls erkauft sich das Team eine Flexibilität, die es nicht nutzt, und bleibt auf zusätzlichen Ausfallpunkten sitzen.

Das ist auch der Punkt, an dem das Thema ganz natürlich in eine praktische Risikoanalyse für Projektentscheidungen übergeht. Wenn ein Kommunikationskanal den Maschinenzustand verändern, eine Sequenz freigeben, den Betrieb nach einem Verbindungsverlust wieder aufnehmen oder mittelbar auf Aktoren einwirken kann, muss nicht nur die Zuverlässigkeit der Übertragung bewertet werden, sondern auch die Folgen eines fehlerhaften oder verspäteten Befehls. In einem Teil der Anwendungen berührt das bereits Anforderungen zum Schutz vor unerwartetem Anlauf, denn selbst eine technisch korrekte Integration darf keinen Umgehungsweg an lokalen Verriegelungen oder Verfahren zur Energieabschaltung schaffen. In diesem Umfang sollte die Wahl der Kommunikation mit der Steuerungsarchitektur, der elektrischen Ebene und den Regeln für Softwareänderungen abgestimmt werden und nicht als isolierte Integrationsentscheidung getroffen werden. Aus Sicht eines Managers bedeutet das eine einfache Regel: Das Modell des Datenaustauschs ist nur dann geeignet, wenn sich nachweisen lässt, wer eine Änderung freigibt, wie nach einer Störung ein sicherer Zustand wiederhergestellt wird und welche KPI nach der Inbetriebnahme gemessen werden, zum Beispiel die Wiederanlaufzeit, die Anzahl der Vorfälle nach Änderungen und die Anzahl der Stellen, an denen Datenmappings gepflegt werden.

Worauf bei der Implementierung zu achten ist

Bei der Implementierung entsteht das größte Risiko nicht durch die Wahl zwischen MQTT, OPC UA und direkter Kommunikation mit der PLC selbst, sondern durch verdeckte Annahmen, die das Team ohne formale Bestätigung trifft. In der Projektpraxis sind die teuersten Situationen jene, in denen das Modell des Datenaustauschs auf eine Funktionsdemonstration und nicht auf den tatsächlichen Betriebs-, Instandhaltungs- und Änderungsverantwortungsmodus ausgelegt wird. MQTT wird mitunter mit der Annahme einer einfachen Datenübertragung an übergeordnete Systeme eingeführt und beginnt nach einigen Monaten plötzlich, operative Befehle zu transportieren. OPC UA wird als „universelle“ Lösung gewählt, ohne festzulegen, welche Dienste, Datenmodelle und Berechtigungsmechanismen tatsächlich genutzt werden. Direkte Kommunikation mit der PLC erscheint als der kürzeste Weg, bis sich herausstellt, dass jeder weitere Datenempfänger ein eigenes Mapping, Regressionstests und Abstimmungen mit dem Steuerungslieferanten erfordert. Für den Manager hat das eine einfache Konsequenz: Die Implementierungskosten enden nicht mit der Inbetriebnahme der Verbindung, sondern erstrecken sich über den gesamten Zyklus aus Änderungen, Störungen und technischen Abnahmen.

Die entscheidende Frage sollte daher nicht lauten: „Was können wir am schnellsten in Betrieb nehmen?“, sondern: „Wo endet die Verantwortung für die Bedeutung der Daten und für die Folgen ihrer Verwendung?“ Dient die Kommunikation ausschließlich der Prozessbeobachtung, gelten andere Bewertungskriterien als dann, wenn derselbe Kommunikationspfad Rezepturen, Betriebsparameter, Verriegelungen oder Steuerungsabläufe beeinflussen soll. An diesem Punkt geht das Thema ganz natürlich in eine praktische Risikobewertung für Projektentscheidungen in der Architekturphase über: Zu bewerten ist nicht nur die Wahrscheinlichkeit eines Kommunikationsausfalls, sondern auch, ob ein fehlerhafter Wert, eine verspätete Aktualisierung oder ein uneindeutiges Variablen-Mapping eine Fehlfunktion der Maschine oder Linie auslösen kann. Wenn die Antwort darauf ja lautet, ist die Kommunikationsarchitektur nicht mehr nur eine Integrationsfrage. Sie wird zu einem Element, das die Steuerungsfunktion, die Abnahme des Systems und die Verantwortung des Integrators bei der Kopplung von Teilsystemen beeinflusst.

In der Praxis zeigt sich das gut an einem einfachen Szenario: Ein übergeordnetes System soll Zustände aus mehreren Steuerungen einlesen, und nach dem Projektstart bittet der Anwender zusätzlich um eine Fernänderung von Sollwerten. Bei der Kommunikation direkt mit der PLC endet das häufig damit, dass weitere Register, Ausnahmen und herstellerspezifische Umgehungslösungen ergänzt werden. Bei MQTT besteht das Problem oft im Verlust der Eindeutigkeit: Die Nachricht kommt an, aber ohne klar definierten Kontext weiß der Empfänger nicht, ob der Wert aktuell ist, bestätigt wurde und aus welcher Betriebsart er stammt. Bei OPC UA liegt die Falle nicht im Protokoll selbst, sondern in der zu optimistischen Annahme, dass das Informationsmodell auf Geräteseite dem entspricht, was die übergeordnete Anwendung verlangt. Deshalb sollte ein praxisgerechtes Bewertungskriterium drei Punkte umfassen: Wer ist Eigentümer der Datensemantik, wie werden Gültigkeit und Aktualität der Werte bestätigt und wie sieht das Änderungsverfahren nach der Inbetriebnahme aus? Wenn das Team auf eine dieser Fragen nur allgemein oder abhängig vom Lieferanten antwortet, bedeutet das, dass die Kosten künftiger Änderungen gerade in die Phase der Instandhaltung verlagert wurden.

Eine weitere Falle ist die Unterschätzung der physischen und installationstechnischen Auswirkungen. In Projekten, in denen die Wahl des Datenaustauschmodells die Positionierung von Zwischengeräten, zusätzliche Stromversorgung, Leitungsführung oder die Netztrennung beeinflusst, berührt das Thema bereits die Auslegung der elektrischen Ebene und der Verbindungen in der Maschine. Das gilt insbesondere für Lösungen mit zusätzlichen Kommunikations-Gateways, Industrie-PCs oder Switches, die in der Dokumentation harmlos wirken, im Schaltschrank jedoch Platz, Kühlung, Schutz, Service und weitere Ausfallpunkte bedeuten. Dann darf die Kommunikationsentscheidung nicht vom Ausführungsprojekt getrennt betrachtet werden. Das Team sollte darlegen können, was beim Ausfall der Versorgung eines Zwischengeräts geschieht, wie der Kommunikationszustand wiederhergestellt wird und ob ein Fehler in der Übertragungsebene nicht zu einem uneindeutigen Bild des Maschinenzustands für den Bediener oder das übergeordnete System führt.

Der Bezug zu Konformitätsanforderungen entsteht erst dann, wenn der Datenkanal die Steuerungsfunktion, die Art der Maschinennutzung oder die Verantwortungsgrenzen zwischen Lieferanten beeinflusst. In diesem Umfang reicht die Feststellung nicht aus, dass ein Protokoll „industrietauglich“ oder weit verbreitet ist. Es muss nachgewiesen werden, dass die gewählte Kommunikationsarchitektur in der Industrieautomatisierung im Kontext vorhersehbarer Fehlerzustände, betrieblicher Änderungen und der Schnittstellen zwischen Teilsystemen bewertet wurde, was in der Praxis zu einer methodischen Risikobewertung entsprechend dem festgelegten Projektumfang führt. Wird das System aus fertigen Modulen, Steuerungen und Kommunikationsebenen verschiedener Beteiligter zusammengesetzt, gewinnt auch die formale Zuordnung der Verantwortung des Integrators an Bedeutung. Das ist in der Regel der Moment, in dem es sinnvoll ist, das Projekt anzuhalten und nicht nur das Datenaustauschschema zu prüfen, sondern auch die Grenzen von Änderungen nach der Abnahme, die Regeln zur Validierung von Änderungen sowie die Instandhaltungs-KPI: die Zeit bis zur Wiederherstellung der Kommunikation, die Anzahl der Vorfälle nach Updates und die Anzahl der Schnittstellen, die ein manuelles Mapping erfordern.