Wer eine gewachsene OT-Landschaft betreibt, kennt das Muster: Ein neues Gerät spricht Modbus-RTU, das bestehende SCADA-System erwartet OPC-DA, und die Lösung heißt wieder einmal “noch ein Gateway”. Was wie eine pragmatische Übergangslösung wirkt, entwickelt sich über Jahre zu einem ernsthaften Beschaffungsrisiko. Jedes zusätzliche Modbus Gateway bedeutet mehr Wartungsaufwand, neue Sicherheitslücken und eine Infrastruktur, die mit jeder weiteren Komponente schwerer zu überblicken ist.

Dabei ist Protokollheterogenität kein unvermeidliches Schicksal, sondern ein lösbares Architekturproblem. Hardware-agnostische IoT-Plattformen mit universellen Protokollbrücken zeigen, wie Modbus-RTU-Geräte, OPC-Server und SCADA-Systeme unter einer einzigen Monitoring-Oberfläche zusammengeführt werden können, ohne die bestehende Infrastruktur zu ersetzen.

Dieser Beitrag erklärt, warum einzelne Gateways langfristig nicht skalieren, wie eine zukunftsfähige Integrationsarchitektur aussieht und welche konkreten Migrationspfade für Industriebetreiber in der Praxis funktionieren. Darüber hinaus werden Compliance-Anforderungen nach IEC 62443, häufige Missverständnisse über OPC UA sowie die tatsächlichen Gesamtkosten einer fragmentierten Gateway-Landschaft beleuchtet.

Das ‘One-more-Gateway’-Problem: Warum Protokollheterogenität ein Beschaffungsrisiko ist

Wer eine gewachsene Industrieanlage betreibt, kennt das Szenario: Ein Frequenzumrichter aus den frühen 2000er Jahren spricht Modbus-RTU, der Leitstand läuft über einen OPC-Classic-Server, und das SCADA-System kommuniziert über eine proprietäre Schnittstelle des damaligen Anlagenlieferanten. Alle drei Komponenten laufen zuverlässig, aber sie sprechen unterschiedliche Sprachen und kein gemeinsames Wort miteinander.

Die scheinbar naheliegende Lösung: ein Modbus-Gateway anschaffen, das die Lücke schließt. Das funktioniert, bis das nächste Gerät dazukommt. Und das übernächste. Jede neue Protokollbrücke bringt ein weiteres Gerät mit, das konfiguriert, dokumentiert, mit Firmware-Updates versorgt und gegen Angriffe abgesichert werden muss. Die Gesamtkomplexität steigt dabei nicht linear, sie wächst überproportional, denn jedes Gateway fügt nicht nur sich selbst zum System hinzu, sondern neue Abhängigkeiten zu allen bereits vorhandenen Komponenten.

Der Lebenszyklus-Konflikt macht dieses Problem strukturell. Industrielle Anlagen laufen durchschnittlich 10 bis 15 Jahre, typische IT-Hardware wird nach 3 bis 5 Jahren ersetzt. Das bedeutet: Ein Betreiber, der heute ein Gateway einbaut, pflegt es unter Umständen durch zwei oder drei IT-Generationszyklen hindurch, mit entsprechend wachsendem Aufwand für Kompatibilitätssicherung und Sicherheitspatches.

Das eigentliche Beschaffungsrisiko ist allerdings weniger sichtbar. Wenn jedes Feldgerät ein eigenes Gateway benötigt, entstehen über Jahre hinweg undokumentierte Abhängigkeiten zwischen Geräten, Firmware-Versionen und Netzwerkkonfigurationen. Beim nächsten Beschaffungszyklus, etwa wenn ein Gateway-Hersteller ein Modell abkündigt, zeigt sich, wie teuer dieses fehlende Wissen werden kann. Das Ergebnis sind teure Notlösungen unter Zeitdruck. Ähnliche Dynamiken entstehen übrigens auch bei der Integration von Smart Metern in IoT-Plattformen, wo Rohdaten ohne gemeinsame Plattformebene ebenfalls in isolierten Systemen versanden.

Eine hardware-agnostische IoT-Plattform mit universeller Protokollunterstützung adressiert genau diesen Punkt. Sie ersetzt nicht jedes Gateway durch ein neues, sondern schafft eine gemeinsame Integrationsebene, auf der Modbus-RTU, OPC und SCADA-Schnittstellen gleichzeitig und strukturiert zusammengeführt werden.

Die Protokolllandschaft in der Praxis: Modbus-RTU, OPC und SCADA im Überblick

Um zu verstehen, warum Protokollheterogenität so hartnäckig ist, lohnt ein kurzer Blick auf die drei wichtigsten Kommunikationsebenen, die in gewachsenen OT-Umgebungen zusammentreffen.

Modbus-RTU wurde in den späten 1970er Jahren entwickelt und ist bis heute in Frequenzumrichtern, Energiezählern und Pumpensteuerungen allgegenwärtig. Seine Stärken sind Einfachheit und Robustheit, seine Schwächen strukturell bedingt: Das Protokoll überträgt Rohdaten aus Registeradressen ohne jede semantische Beschreibung. Register 40001 bedeutet nichts, solange keine externe Dokumentation erklärt, dass es sich um eine Vorlauftemperatur in Grad Celsius handelt. Sicherheitsmechanismen fehlen vollständig, da Modbus nie für vernetzte Umgebungen konzipiert wurde.

OPC Classic (in den Varianten DA, HDA und A&E) löste ab den 1990er Jahren das Problem der SPS-SCADA-Kopplung und war jahrzehntelang der Industriestandard für Leitsysteme. Das zugrunde liegende DCOM-Protokoll von Microsoft macht OPC Classic jedoch zu einem reinen Windows-Produkt, das sich über Netzwerkgrenzen hinweg kaum sauber betreiben lässt. Firewalls, Subnetzgrenzen und moderne Cloud-Infrastrukturen waren beim Design nicht vorgesehen.

OPC UA (standardisiert als IEC 62541) überwindet beide Einschränkungen grundlegend. Es arbeitet plattformunabhängig, verschlüsselt Kommunikation nativ und beschreibt Datenpunkte semantisch: Ein OPC-UA-Server liefert nicht nur einen Messwert, sondern auch Einheit, Grenzwert und Gerätebeschreibung als Teil des Informationsmodells. Bereits im April 2015 wurde OPC UA als standardisierte Kommunikationsschicht in der RAMI-4.0-Referenzarchitektur verankert. Im November 2016 verschärfte die Industrie-4.0-Plattform die Anforderungen weiter: Selbst Produkte der Kategorie „Basic” müssen seither entweder OPC-UA-fähig sein oder über ein entsprechendes Gateway erreichbar sein, um Konformität zu beanspruchen.

Ein verbreitetes Missverständnis hält sich hartnäckig: OPC UA sei ein Protokoll für die Fabrikhalle, nicht für die Cloud. Das Gegenteil ist der Fall. OPC UA wurde explizit für den Einsatz in modernen IT-Infrastrukturen und Cloud-Umgebungen ausgelegt und ist damit das Bindeglied zwischen Feldebene und übergeordneten Analyseplattformen. Wer bei der Wahl einer IoT-Plattform auf OPC-UA-Unterstützung achtet, sichert sich genau diese Anschlussfähigkeit.

SCADA-Systeme stehen in diesem Gesamtbild ganz oben in der Hierarchie: Sie überwachen und steuern ganze Anlagen, nutzen dabei aber intern oft Modbus, OPC Classic und OPC UA gleichzeitig. Das macht SCADA nicht zum Problemverursacher, sondern zum Ort, an dem sich alle Protokollunterschiede als Systemheterogenität bündeln.

Warum einzelne Modbus-Gateways langfristig nicht skalieren

Dass eine Protokolllandschaft heterogen ist, lässt sich noch managen. Das eigentliche Problem entsteht, wenn für jedes neue Gerät oder Protokoll reflexartig ein weiteres einzelnes Modbus-Gateway beschafft wird.

Ein solches Gateway löst das unmittelbare Anschlussproblem eines Geräts, schafft aber weder ein einheitliches Datenmodell noch eine gemeinsame Sicherheitsarchitektur für die gesamte Anlage. Es ist eine punktuelle Lösung, keine strukturelle.

Gateway-Proliferation: Wenn die Lösung zum Problem wird

In der Praxis führt dieser Ansatz zuverlässig zur sogenannten Gateway-Proliferation. Mit jedem neuen IoT-Gerät oder Protokoll wächst die Zahl der Einzelgateways, bis kein verlässlicher Überblick mehr über Datenpfade, Firmware-Versionen und Zugriffsrechte besteht. Was einst überschaubar wirkte, wird zur unkontrollierten Infrastruktur. Für eine strukturierte IoT-Kommunikation und Datenübertragung ist das keine tragfähige Grundlage.

Operative Silos statt gemeinsamer Sicht

Isolierte Gateways erzeugen operative Silos: Modbus-Daten landen in einem System, OPC-Daten in einem anderen, SCADA-Alarme in einem dritten. Eine übergreifende Analyse oder ein einheitliches Alarmmanagement ist unter diesen Bedingungen kaum realisierbar. Betreiber verbringen Zeit damit, Informationen aus mehreren Systemen manuell zusammenzuführen, anstatt auf eine konsolidierte Übersicht zugreifen zu können.

Jedes Gateway ist ein potenzieller Angriffspunkt

Modbus wurde entwickelt, lange bevor vernetzte OT-Umgebungen überhaupt denkbar waren. Das Protokoll kennt keine Authentifizierung, keine Verschlüsselung, keine Zugriffssteuerung. Jedes Gateway, das ein solches Legacy-Protokoll ohne geeignete Middleware ins Netzwerk führt, schafft eine angreifbare Schnittstelle. IEC 62443 adressiert genau dieses Risiko durch das Konzept kontrollierter Sicherheitszonen; ein unkontrolliert gewachsenes Gateway-Geflecht ist mit diesem Ansatz strukturell unvereinbar.

TCO-Eskalation: nicht linear, sondern exponentiell

Die Anschaffungskosten eines einzelnen Gateways wirken überschaubar. Multipliziert man sie jedoch mit Konfigurationsaufwand, Schulungen, individuellen Wartungsverträgen und Sicherheits-Patches für jede Komponente, steigt die Total-Cost-of-Ownership mit jeder weiteren Einheit überproportional. Das ist kein Skalierungsmodell, sondern ein Kostentreiber.

Architektur einer hardware-agnostischen IoT-Plattform als universelle Protokollbrücke

Die beschriebenen Probleme entstehen nicht durch fehlende Einzellösungen, sondern durch eine grundlegende Architekturlücke. Eine hardware-agnostische IoT-Plattform schließt diese Lücke, indem sie auf einer einzigen Integrationsebene zwischen Modbus-RTU, OPC DA/UA, MQTT, REST-APIs und weiteren Protokollen übersetzt, ohne dass Betreiber bestehende Feldgeräte austauschen oder umkonfigurieren müssen.

Das Schichtenmodell: Feldebene und Plattformebene klar getrennt

Das tragende Architekturprinzip ist die saubere Trennung zweier Ebenen. Auf der Feldebene sprechen Geräte weiterhin ihre nativen Protokolle: Eine Pumpensteuerung sendet Modbus-RTU-Registerwerte, ein SPS-System liefert OPC-DA-Daten, ein Frequenzumrichter meldet sich per MQTT. Diese Kommunikation bleibt unverändert.

Auf der Plattformebene werden alle eingehenden Daten in ein einheitliches, semantisch beschriebenes Datenmodell überführt. Jeder Datenpunkt erhält dort einen Namen, eine Einheit, einen Kontext und, wo nötig, einen Grenzwert. Aus einer rohen Modbus-Registeradresse wird ein interpretierbarer Eintrag: statt “Register 40003, Wert 732” erscheint im Dashboard “Pumpe 3, Vorlauftemperatur, 73,2 °C”.

Edge-Adapter als kontrollierter Übergang

Die Übersetzungsarbeit übernehmen Edge-Komponenten oder softwarebasierte Protokolladapter, die lokal in der Anlage platziert werden. Sie greifen auf Feldgeräte zu, übersetzen die Rohwerte und leiten strukturierte Datenpunkte erst dann weiter, wenn die Sicherheitszonengrenze kontrolliert passiert werden kann. Dieser Ansatz ist direkt kompatibel mit den Anforderungen der IEC 62443, die Netzwerke in Sicherheitszonen aufteilt und kontrollierte Übergangspunkte zwischen ihnen vorschreibt. Der Adapter übernimmt genau diese Rolle, ohne dass ein zusätzliches physisches Gateway nötig wird.

Die Rolle von OPC UA als Semantik-Layer

OPC UA ist in dieser Architektur mehr als ein Übertragungsprotokoll. Seine semantische Interoperabilität erlaubt es, Geräte nicht nur zu verbinden, sondern ihre Datenpunkte mit vollständigem Kontext zu versehen: Einheit, Grenzwert, Gerätebeschreibung und granulare Zugriffsrechte. Betreiber können damit präzise steuern, welche Systeme auf welche Informationen zugreifen dürfen.

Sensor-Online von Nodeledge arbeitet nach genau diesem Schichtenmodell und unterstützt LoRaWAN, PLC, SCADA, OPC, Modbus und MQTT in einer gemeinsamen Oberfläche. Wer beim Plattformvergleich systematisch vorgehen möchte, findet in der Checkliste zur Bewertung einer IoT-Monitoring-Plattform konkrete Kriterien für Protokollunterstützung, Deployment-Flexibilität und Datensouveränität.

Drei typische Integrationspfade für gewachsene OT-Landschaften

Diese Architektur funktioniert in der Theorie überzeugend – doch wie sieht sie in der Praxis aus? Drei Szenarien zeigen, wie unterschiedliche OT-Landschaften konkret angebunden werden.

Szenario 1: Rein Modbus-basierte Umgebung

Frequenzumrichter, Energiezähler und Pumpensteuerungen kommunizieren über Modbus-RTU auf einer RS-485-Leitung. Ein Protokolladapter auf Edge-Ebene liest die Registeradressen aus, übersetzt die Rohwerte in benannte, strukturierte Datenpunkte und leitet sie gesichert an die Plattform weiter. Die Feldgeräte selbst bleiben unverändert.

Szenario 2: Gemischte OPC-Classic- und Modbus-Umgebung

Ein vorhandener OPC-DA-Server liefert Daten aus der SPS-Welt; ältere Feldgeräte sprechen weiterhin Modbus. Die Plattform bindet beide Quellen über separate softwarebasierte Adapter an und führt sie in einem gemeinsamen Dashboard zusammen. Ein zusätzliches physisches Gateway entfällt, weil die Protokollübersetzung vollständig auf Softwareebene stattfindet. Das Ergebnis: eine einzige Oberfläche für Daten, die bisher in zwei getrennten Welten lagen. Mehr zu den technischen Möglichkeiten einer solchen Integration mit bestehenden Systemen findet sich in unserem weiterführenden Leitfaden.

Szenario 3: SCADA mit Integrationsbedarf

Das bestehende SCADA-System übernimmt weiterhin Steuerung und Alarmgebung, wie es NIST SP 800-82 für laufende OT-Umgebungen empfiehlt. Die IoT-Plattform wird parallel angebunden, entweder über OPC UA oder eine direkte Datenbankverbindung, und empfängt Prozessdaten ausschließlich lesend. Damit werden übergreifende Analysen, Berichte und Energieauswertungen möglich, ohne das SCADA zu ersetzen oder zu destabilisieren.

Gemeinsame Migrationsprinzipien

In allen drei Szenarien gilt dasselbe Vorgehen: zuerst die kritischsten oder datenintensivsten Quellen anbinden, dann weitere Bereiche in definierten Phasen folgen lassen. Geräte im Feld werden zu keinem Zeitpunkt umkonfiguriert. Ein vorgelagerter Adapter ergänzt die bestehende Kommunikation, ohne sie zu unterbrechen. Die industrielle Kommunikation läuft während der gesamten Migration unterbrechungsfrei weiter.

Sicherheitszonen, IEC 62443 und warum Gateway-Architektur zur Compliance-Pflicht wird

Die drei Integrationspfade lösen das operative Problem. Die Frage, ob die resultierende Architektur auch regulatorischen Anforderungen standhält, ist eine separate Ebene, die Beschaffungsentscheider zunehmend früh stellen.

IEC 62443 als Architekturvorgabe, nicht nur als Prüfkriterium

IEC 62443 ist der internationale Cybersecurity-Standard für industrielle Automatisierungs- und Steuerungssysteme. Sein zentrales Strukturprinzip: Netzwerke müssen in Sicherheitszonen aufgeteilt werden, die ausschließlich über kontrollierte Übergangspunkte, sogenannte Conduits, miteinander kommunizieren. Ein Conduit ist kein optionaler Sicherheitsbaustein, sondern eine formale Voraussetzung dafür, dass Zonen überhaupt als konform gelten.

Modbus ist dabei ein konkretes Problem. Das Protokoll kennt weder Authentifizierung noch verschlüsselte Übertragung. In einer IEC-62443-konformen Architektur darf eine Modbus-Quelle nicht direkt an ein höherwertiges Netzwerksegment angebunden werden. Der Protokolladapter oder Edge-Knoten übernimmt genau diese Funktion: Er sitzt am Zonenübergang, übersetzt das unsichere Protokoll, und stellt sicher, dass ausschließlich strukturierte, validierte Datenpunkte die Zonengrenze passieren. Das entspricht dem Conduit-Konzept innerhalb von IEC 62443 technisch und formal.

Compliance-Doppelnutzen einer integrierten Plattform

Eine hardware-agnostische Plattform mit eingebautem Protokoll-Bridging erfüllt damit zwei Anforderungen gleichzeitig: Sie vereinfacht die Integration und sie dokumentiert jeden Datenpfad automatisch. Regulierte Branchen, etwa Energie, Wasser oder Chemie, benötigen lückenlose Audit-Trails. Eine Plattformlösung erzeugt diese systemisch; eine Einzelgateway-Infrastruktur erfordert dafür manuelle Dokumentation, die in der Praxis selten aktuell gehalten wird.

Aktuelle Forschungsarbeiten, darunter der Josef-Ressel-Ansatz zur TCP-Aggregation auf SigmaServer-Basis, zeigen, dass die Industrie gezielt Methoden entwickelt, um sichere und unsichere OT-Zonen sauber zu trennen und gleichzeitig für übergeordnete Systeme transparent zu halten. Das Thema ist kein akademisches Randphänomen, sondern aktiver Entwicklungsbereich.

Was das für Beschaffungsentscheider bedeutet

IEC-62443-Anforderungen tauchen in Ausschreibungen und externen Audits zunehmend als explizite Kriterien auf. Eine Plattform ohne nachweisbare Sicherheitszonen-Unterstützung und ohne protokollierbare Zonenübergänge ist kein zukunftssicheres Investment, unabhängig davon, wie leistungsfähig ihre Integrationsschicht im Übrigen ist.

Drei verbreitete Missverständnisse über OPC UA, die Betreiber bremsen

Neben den Compliance-Anforderungen aus IEC 62443 gibt es ein weiteres Hindernis, das Betreiber beim Thema OPC UA regelmäßig ausbremst: hartnäckige Missverständnisse über das Protokoll selbst.

„OPC UA funktioniert nicht in der Cloud”

Das Gegenteil ist richtig. OPC UA wurde von Grund auf als plattformunabhängiges, cloud-fähiges Kommunikationsprotokoll entwickelt. Die OPC Foundation betreibt eine eigene Cloud Initiative und dokumentiert explizit Anwendungsfälle wie Retrofit bestehender Maschinen über Cloud-Repositories und die Konfiguration cloud-basierter Analyseanwendungen. OPC UA ist kein Protokoll der Fabrikhalle, sondern das Bindeglied zwischen Feldebene und Cloud-Analyse.

„Wir brauchen OPC UA nicht, wir haben schon Modbus”

Modbus und OPC UA lösen unterschiedliche Probleme. Modbus überträgt Rohwerte aus Registeradressen, ohne Kontext, Einheit oder Zugriffssteuerung. OPC UA arbeitet auf einer darüberliegenden Ebene: Es versieht dieselben Daten mit semantischem Kontext, definiert Zugriffsrechte über rollenbasierte Sicherheit und macht Datenpunkte maschinenlesbar interpretierbar. Beide Protokolle schließen sich nicht aus; OPC UA wertet vorhandene Modbus-Infrastruktur auf.

„OPC UA ist zu komplex für unsere IT-Ressourcen”

Eine integrierende IoT-Plattform abstrahiert die Informationsmodellierung vollständig. Betreiber konfigurieren benannte Datenpunkte mit Einheiten und Grenzwerten, ohne sich mit Adressraumstrukturen oder Zertifikatsverwaltung auseinanderzusetzen. Die Integrationsunterstützung moderner IoT-Plattformen zeigt, dass diese Abstraktionsschicht keine theoretische Idee ist, sondern produktiv einsetzbares Handwerk.

Warum das strategisch wichtig ist: Die OPC Foundation positioniert OPC UA ausdrücklich als nicht verhandelbaren Standard für Industrie-4.0-Konformität. Betreiber, die das Protokoll ignorieren, riskieren mittelfristig die Anschlussfähigkeit an übergeordnete Systeme und Lieferkettennetzwerke.

Für KMU bedeutet das keinen sofortigen Komplettumbau der Feldebene. Ein schrittweiser Einstieg über eine vermittelnde Plattformschicht ist praktikabel: Bestehende Geräte bleiben unangetastet, während OPC-UA-fähige Datenpunkte schrittweise hinzukommen.

TCO-Betrachtung: Was ‘noch ein Gateway’ wirklich kostet

Die Entscheidung für oder gegen eine zentrale Plattform ist letztlich eine Finanzentscheidung. Und dabei unterschätzen Betreiber die wahren Kosten eines einzelnen Modbus-Gateways fast immer.

Die Anschaffung ist nur der Anfang. Der Kaufpreis eines Gateways wirkt überschaubar. Doch dazu kommen initiale Konfiguration, Netzwerkdokumentation, wiederkehrende Firmware-Updates und Sicherheits-Patches, die über eine typische Betriebslebensdauer von zehn Jahren anfallen. Jede dieser Aufgaben bindet Ingenieurszeit, die an anderer Stelle fehlt.

Multipliziert man diesen Aufwand, zeigt sich das eigentliche Problem. In Industrieumgebungen mit 20 bis 50 verschiedenen Gerätetypen entstehen rasch ebenso viele Gateway-Instanzen, jede mit eigenen Zugangsdaten, eigener Netzwerkkonfiguration und eigenem Wartungsrhythmus. Es gibt keine gemeinsame Übersicht, keinen einheitlichen Patch-Prozess und keine konsolidierte Sicherheitsüberwachung. Der Verwaltungsaufwand wächst nicht linear mit der Anzahl der Gateways, sondern überproportional.

Eine zentrale IoT-Plattform bricht diesen Zusammenhang auf. Statt dozens isolierter Systeme verwalten Betreiber ein einziges System mit gemeinsamer Nutzerverwaltung, einem einheitlichen Update-Mechanismus und zentraler Sicherheitsüberwachung. Wie sich dieser Konsolidierungseffekt in realen Betriebsszenarien auf Gesamtkosten auswirkt, zeigt etwa die Kostnadsanalys och ROI für VA-bolag mit konkreten Vergleichswerten.

Der entscheidende TCO-Hebel liegt beim Onboarding neuer Geräte. Jedes weitere IoT-Gerät in einer Gateway-Landschaft erfordert eine individuelle Konfiguration, Tests und Dokumentation. Auf einer zentralen Plattform folgt dieselbe Aufgabe einem standardisierten Onboarding-Prozess, der reproduzierbar und deutlich schneller ist. Die eingesparte Integrationsarbeit summiert sich über Monate und Jahre.

Langfristig schützt der Plattformansatz außerdem vor Integrationsschulden: technischen Altlasten, die entstehen, wenn jede Einzellösung beim nächsten Upgrade separat angepasst werden muss. Wer heute auf Gateway-Proliferation setzt, zahlt diese Schulden bei jeder Erweiterung der industriellen Kommunikation neu.

Sensor-Online in der Praxis: Modbus, OPC und SCADA unter einer Oberfläche

Wo Gateway-Proliferation die TCO in die Höhe treibt, setzt eine konsolidierte Plattform den entscheidenden Kontrapunkt. Sensor-Online von Nodeledge wurde von Grund auf als hardware-agnostische Lösung entwickelt und unterstützt nativ Modbus, OPC Classic und OPC UA, SCADA-Anbindungen, LoRaWAN, MQTT sowie offene APIs, alles über eine gemeinsame Integrationsebene. Betreiber beschaffen keine separate Middleware pro Protokoll, sondern verbinden alle Quellen einmalig mit der Plattform.

Der Gerätekatalog umfasst über 1.200 Sensoren, Datenlogger und Konnektivitätswerkzeuge, die direkt eingebunden werden können. Das bedeutet konkret: Ein Frequenzumrichter aus dem Jahr 2010 und ein neu installiertes drahtloses Raumklimagerät für IoT-Überwachung landen in derselben Verwaltungsoberfläche, ohne Sonderkonfiguration für jedes Einzelgerät.

Unmittelbar nach der Geräteanbindung stehen Dashboards, Alarmmanagement, Energieverbrauchsauswertung und KI-gestützte Analysen bereit. Es gibt keinen separaten Konfigurationsschritt pro System: Wer ein Gerät einbindet, erhält alle Funktionen der Plattform sofort.

Sensor-Online lässt sich On-Premise betreiben, als skalierbare Cloud-Lösung deployen oder als White-Label-Produkt für Systemintegratoren und OEM-Partner nutzen. Diese Flexibilität macht die Plattform sowohl für eigenständige Industriebetreiber mit sensiblen OT-Umgebungen als auch für Partner geeignet, die eigene Monitoring-Angebote aufbauen wollen.

Das tragende Prinzip dahinter ist No-Lock-in. Betreiber bleiben unabhängig von einzelnen Herstellern und Protokollstandards. Wechselt ein Gerätehersteller sein Kommunikationsprotokoll, oder kommt ein neues IoT-Gerät mit anderem Übertragungsweg hinzu, bleibt die Plattform als stabile Mitte bestehen. Das ist das strukturelle Gegenmodell zur Gateway-Proliferation: nicht mehr ein neues Gerät pro Protokoll, sondern ein System für alle.

Migrationsplanung: Wie Industriebetreiber den Übergang strukturiert angehen

Mit einer geeigneten Plattform im Einsatz beginnt die eigentliche Arbeit: die strukturierte Überführung der bestehenden OT-Landschaft. Ein bewährter Fünf-Schritte-Ansatz hält das Risiko gering und den Betrieb unterbrechungsfrei.

Schritt 1: Bestandsaufnahme

Erfassen Sie systematisch alle Feldgeräte, Protokolle und vorhandenen Gateways. Relevant sind Firmware-Versionen, Kommunikationsmedien (RS-485, Ethernet, WLAN) sowie die aktuellen Datenpfade vom Gerät bis zur Auswertung. Diese Dokumentation ist die Grundlage für alle weiteren Schritte und entspricht zugleich der Inventarisierungsanforderung aus der ISA/IEC 62443-Normenreihe.

Schritt 2: Priorisierung

Clustern Sie Geräte nach zwei Kriterien: Datenkritikalität und Integrationsaufwand. Quellen mit dem höchsten Informationswert für den Betrieb oder mit den akutesten Sicherheitsrisiken werden zuerst angebunden. Unsichere Legacy-Geräte an Netzwerksegmentgrenzen stehen dabei typischerweise ganz oben auf der Liste.

Schritt 3: Architekturentscheidung

Abhängig von Netzwerktopologie und Sicherheitsanforderungen wählen Sie zwischen zwei Ansätzen. Ein lokaler Edge-Knoten übernimmt die Protokollübersetzung vor Ort und bleibt innerhalb der Sicherheitszone; eine direkte Cloud-Verbindung eignet sich, wenn das Netzwerk entsprechend abgesichert ist und die Latenzanforderungen es erlauben. Beide Wege lassen sich kombinieren.

Schritt 4: Parallelbetrieb

Während der Migrationsphase läuft das bestehende SCADA-System oder Einzelgateway unverändert weiter. Die neue Plattform empfängt Daten parallel, bis alle Funktionen vollständig validiert und im Produktiveinsatz stabil sind. Dieser Parallelbetrieb ist keine Übergangskomfortlösung, sondern eine gezielte Risikominderungsstrategie, da kein einziger Produktionsprozess von einem ungetesteten System abhängt.

Schritt 5: Schrittweise Ablösung

Nach erfolgreicher Validierung werden einzelne Gateways und Protokollbrücken dekommissioniert. Die Dokumentation wird aktualisiert, Zugangsdaten und Netzwerkkonfigurationen der abgelösten Komponenten werden gesperrt, und der Betrieb geht vollständig auf die zentrale Plattform über. Jede Phase schließt mit einer aktualisierten Anlagendokumentation ab, die auch für zukünftige Audits verwertbar ist.

Fazit: Protokollheterogenität als Chance, nicht als Hindernis

Wer die Migrationsschritte einmal strukturiert durchläuft, stellt meistens fest: Das eigentliche Problem war nie die Technologie im Feld, sondern die fehlende gemeinsame Ebene darüber.

Protokollheterogenität in gewachsenen OT-Umgebungen ist kein unvermeidliches Schicksal. Sie ist ein Beschaffungsproblem, das durch die richtige Plattformwahl ein für alle Mal strukturell gelöst wird, statt mit jedem neuen Gerät neu zu entstehen.

Dieser Ansatz ist kein Großkonzern-Privileg. Mittelständische Industriebetreiber profitieren genauso, weil der Einstieg schrittweise funktioniert: erst die kritischsten Quellen anbinden, dann Schicht für Schicht erweitern, ohne den laufenden Betrieb zu unterbrechen.

Bei der nächsten Beschaffungsentscheidung lohnt es sich, gezielt zu fragen:

• Unterstützt die Plattform Modbus, OPC UA und SCADA-Anbindungen nativ, ohne zusätzliche Middleware?
• Berücksichtigt sie IEC-62443-Sicherheitszonen und liefert sie einen nachvollziehbaren Audit-Trail?
• Gibt es einen standardisierten Onboarding-Prozess, der neue IoT-Geräte ohne individuelle Gateway-Konfiguration integriert?

Wer diese drei Fragen mit Ja beantworten kann, hat eine Plattform gefunden, die langfristig trägt.

Der konkrete erste Schritt ist einfacher als er klingt: Bestehende Protokolllandschaft dokumentieren und prüfen, wo Gateway-Proliferation bereits eingesetzt hat. Genau dort liegt der größte Integrationsaufwand und das höchste Sicherheitsrisiko. Diese Bestandsaufnahme kostet keine Investition, schafft aber sofort Klarheit über Prioritäten.

Sensor-Online von Nodeledge steht als vollständiger IoT-Partner bereit. Die Unterstützung endet nicht bei der Plattform selbst, sondern umfasst Migrationsplanung, Auswahl aus über 1.200 Kataloggeräten und Compliance-Dokumentation für regulierte Umgebungen.

Sprechen Sie uns an: per E-Mail unter info@nodeledge.se oder telefonisch unter +46 (0)500 6000 22. Wir helfen Ihnen, den nächsten Schritt sicher und ohne Umwege zu gehen.

Frequently Asked Questions

Was versteht man unter dem 'One-more-Gateway'-Problem?

Das 'One-more-Gateway'-Problem beschreibt die Situation, dass mit jedem neuen Gerät oder Protokoll reflexartig ein weiteres einzelnes Gateway beschafft wird. Dies führt zur sogenannten Gateway-Proliferation – eine unkontrolliert wachsende Infrastruktur mit zunehmender Komplexität, neuen Sicherheitslücken und exponentiell steigenden Wartungsaufwänden. Jedes Gateway bringt nicht nur sich selbst mit, sondern schafft auch neue Abhängigkeiten zu bereits vorhandenen Komponenten.

Warum ist OPC UA besser geeignet als Modbus für moderne IoT-Umgebungen?

OPC UA überwindet die Limitierungen von Modbus grundlegend. Während Modbus nur Rohwerte aus Registeradressen ohne Kontext überträgt, arbeitet OPC UA auf einer darüberliegenden Ebene mit semantischer Interoperabilität. Es verschlüsselt Kommunikation nativ, beschreibt Datenpunkte mit Einheit, Grenzwert und Gerätebeschreibung, arbeitet plattformunabhängig und wurde explizit für Cloud-Infrastrukturen ausgelegt. Zudem ist OPC UA ein verpflichtender Standard für Industrie-4.0-Konformität nach RAMI-4.0 und der Industrie-4.0-Plattform.

Wie trägt eine hardware-agnostische IoT-Plattform zur IEC-62443-Compliance bei?

Eine hardware-agnostische Plattform erfüllt IEC-62443-Anforderungen durch zwei Mechanismen: Erstens sitzt der Protokolladapter oder Edge-Knoten am Übergang zwischen Sicherheitszonen (Conduit), übersetzt unsichere Protokolle wie Modbus und stellt sicher, dass nur validierte Datenpunkte die Zonengrenze passieren. Zweitens dokumentiert die Plattform automatisch jeden Datenpfad, was die erforderlichen Audit-Trails für regulierte Branchen systemisch erzeugt – im Gegensatz zu Manual-Dokumentation bei Gateway-Einzellösungen.

Welche echten Kosten entstehen durch einzelne Modbus-Gateways über ihre gesamte Lebensdauer?

Die Anschaffungskosten sind nur der Anfang. Über eine typische Betriebslebensdauer von 10 Jahren kommen hinzu: initiale Konfiguration, Netzwerkdokumentation, wiederkehrende Firmware-Updates und Sicherheits-Patches. Mit 20–50 verschiedenen Gerätetypen entstehen ebenso viele Gateway-Instanzen, jede mit eigenen Zugangsdaten und Wartungsrhythmus. Der Verwaltungsaufwand wächst überproportional – nicht linear. Eine zentrale Plattform schafft dagegen gemeinsame Nutzerverwaltung, einheitliche Update-Mechanismen und zentrale Sicherheitsüberwachung, was die TCO erheblich senkt.

Wie funktioniert die schrittweise Migration von einer Gateway-Landschaft zu einer zentralen Plattform?

Der bewährte Fünf-Schritte-Ansatz ist: (1) Bestandsaufnahme aller Geräte und Protokolle dokumentieren, (2) Geräte nach Datenkritikalität und Integrationsaufwand priorisieren, (3) Architekturentscheidung treffen (Edge-Knoten oder Cloud-Verbindung), (4) Parallelbetrieb – das bestehende System läuft unverändert weiter, während die neue Plattform parallel Daten empfängt, (5) schrittweise Ablösung einzelner Gateways nach erfolgreicher Validierung. Während der gesamten Migration bleibt der Produktionsbetrieb unterbrechungsfrei.