Kurz zusammengefasst: Was ist das Wichtigste aus diesem Vergleich?​

Bevor wir ins Detail gehen, hier die wichtigsten Schlussfolgerungen für Entscheidungsträger, die es eilig haben:

• Netzabdeckung: Dank des „New Deal Mobile“ von 2018 decken die vier Netzbetreiber (Orange, SFR, Bouygues, Free) mittlerweile 99 % der Bevölkerung mit 4G ab. Der Unterschied liegt in den ländlichen Gebieten und der Gesamtfläche des Landes, wo Orange weiterhin einen leichten Vorsprung hat.
• Preis: Bouygues und SFR sind in der Regel bei großen Volumina am aggressivsten; Orange berechnet einen Abdeckungsaufschlag.
• Ausfallsicherheit: Keine SIM-Karte eines einzelnen Netzbetreibers deckt 100 % eines Standortverbunds ab. Die Multi-Betreiber-SIM (Multi-IMSI / eUICC) wechselt automatisch zum besten Netz und beseitigt Funklöcher einzelner Netzbetreiber.
• Dringlichkeit 2026–2028: 2G wird abgeschaltet (Orange stellt seinen Dienst zwischen dem 22. September und dem 20. Oktober 2026 ein) und 3G folgt um 2028. Jeder neue Netzausbau muss mindestens LTE-M / NB-IoT / 4G umfassen, da er sonst schnell veraltet.
• Sicherheit: Für kritische Industriezweige (NIS2) ist die private APN + VPN keine Option mehr, sondern eine Voraussetzung.

Was ist eine M2M-SIM-Karte und worin unterscheidet sie sich von einer SIM-Karte für Privatkunden?​

Eine M2M-SIM (Machine-to-Machine), die heute häufiger als IoT-SIM bezeichnet wird, ist eine SIM-Karte, die speziell für industrielle und vernetzte Geräte entwickelt wurde. Sie unterscheidet sich in fast jeder Hinsicht von einer Smartphone-SIM-Karte:

Industrielles SIM-Format: IoT-Gateways und -Router verfügen meist über einen SIM-Steckplatz im Format 2FF (Mini-SIM, 25 × 15 mm) oder 3FF (Micro-SIM), in Umgebungen mit starken Vibrationen sogar eine fest eingelötete eSIM (MFF2). Dies muss vor jeder Bestellung unbedingt überprüft werden – ein falsches Format legt die gesamte Bereitstellung lahm.

Wichtig zu wissen: Eine M2M-SIM-Karte ist nicht nur ein „günstiger Tarif“. Sie ist eine industrielle Komponente, die so konzipiert ist, dass sie genauso lange hält wie die Maschine, in der sie verbaut ist.

Mobilfunkabdeckung in Frankreich 2026: Was die Daten der ARCEP aussagen​

Die Netzabdeckung ist das wichtigste Kriterium für eine M2M-SIM-Karte. Hier wird der tatsächliche Stand des Netzes dargestellt, basierend auf den ARCEP-Daten für das 4. Quartal 2025 (veröffentlicht im März 2026) und nicht auf den werblichen Angaben der Netzbetreiber.

4G: Überall werden mehr als 99 % der Bevölkerung abgedeckt​

Dank der verbindlichen Vorgaben des New Deal Mobile von 2018 decken die vier Netzbetreiber heute mehr als 99 % der französischen Bevölkerung mit 4G ab. Der Wettbewerb dreht sich daher nicht mehr um die Bevölkerungszahl, sondern um:

• Die flächendeckende Versorgung (ländliche Gebiete, Bergregionen, Nebenstraßen), bei der Orange weiterhin die Nase vorn hat.
• Die Abdeckung in Innenräumen / Signalqualität, die von der ARCEP nun in drei Stufen angegeben wird: sehr gut, gut, eingeschränkt.
• Die verbleibenden Funklöcher, die durch das Programm zur gezielten Netzabdeckung (mehrere Tausend gemeinsam genutzte Sendemasten) abgedeckt werden.

Bündelung: die „Crozon“-Vereinbarung zwischen SFR und Bouygues​

Ein wichtiger Aspekt für die Ausfallsicherheit eines Netzes: SFR und Bouygues Telecom nutzen in den weniger dicht besiedelten Gebieten einen Teil ihres Netzes gemeinsam (sogenannte „Crozon“-Vereinbarung zur gemeinsamen Netznutzung). Konkret bedeutet dies, dass die Wahl zwischen SFR und Bouygues in diesen Gebieten darauf hinauslaufen kann, sich mit derselben physischen Antenne zu verbinden – was den Nutzen eines Failovers zwischen diesen beiden Anbietern verringert und den Nutzen einer Umschaltung auf Orange (unabhängiges Netz) einbezieht. Free hingegen profitiert von Roaming im Orange-Netz in den Gebieten, die es noch nicht abdeckt.

Wichtige Frequenzbänder für das IoT​

Für einen Sensor im Untergrund oder in ländlichen Gebieten sind die niedrigen Frequenzbänder (700/800 MHz) entscheidend – nicht das in der Werbung angepriesene 5G in städtischen Gebieten.

⚠️ Das Ende von 2G und 3G: Der Stichtag, der Gerätebestände veralten lässt​

Dies ist der am meisten unterschätzte Aspekt einer IoT-Einführung im Jahr 2026 und verdient einen eigenen Abschnitt.

• 2G: Orange stellt sein 2G-Netz zwischen dem 22. September und dem 20. Oktober 2026 ein. Die anderen Betreiber folgen einem vergleichbaren Zeitplan. Die ARCEP plant sogar, die Verpflichtung zur Kartierung des 2G-Netzes aufzuheben – ein Zeichen dafür, dass die Technologie am Ende ihres Lebenszyklus steht.
• 3G: Die Abschaltung ist für etwa 2028 geplant.

Direkte Folge: Alle **reinen 2G-**Modems oder IoT-Module (die bei älteren Zählern und Alarmanlagen noch weit verbreitet sind) werden ab Herbst 2026 nicht mehr funktionieren. Ein 2G/3G-Modul ohne 4G-Fallback wird gegen 2028 ausfallen.

Was tun?

• Bei jeder neuen Bereitstellung: Modul mit 4G (LTE Cat-1 / Cat-1 bis) oder energiesparendem IoT-Standard LTE-M / NB-IoT vorschreiben, die auch weit über das Jahr 2030 hinaus unterstützt werden.
• Für einen bestehenden 2G/3G-Bestand: Planen Sie einen Hardware-Austausch vor Ablauf der Frist ein. Eine LTE-M/NB-IoT-kompatible SIM-Karte reicht nicht aus, wenn das Modem nicht kompatibel ist.
• Bevorzugen Sie SIM-Karten, bei denen der Netzbetreiber die Unterstützung von LTE-M und NB-IoT langfristig ausdrücklich garantiert.

Tipp von Eziwan: Die Gateways und die Eziwan-SIM-Karte unterstützen 4G/LTE-M mit Fallback und sind so konzipiert, dass sie solche Ausfälle ohne Eingriffe vor Ort überstehen.

M2M-Anbieter in Frankreich: Überblick 2026​

Orange Business (M2M-Datenverkehr / Orange IoT)​

Orange ist der etablierte Netzbetreiber mit der flächendeckendsten Netzabdeckung, insbesondere in ländlichen Gebieten und in den Überseegebieten.

M2M-Angebote:

• Flux M2M Lite: nur Daten, Pakete von 1 MB bis 2 GB/Monat
• Flux M2M Pro: Daten + SMS + Sprache, privater APN verfügbar
• Orange IoT Suite: SIM-Flottenmanagement + Konnektivität + API

Stärken:

• Größte 4G-Abdeckung, Vorsprung in ländlichen Gebieten und flächenmäßig
• Landesweit ausgebautes LTE-M-Netz für das energiesparende IoT
• DOM/COM-Abdeckung (Réunion, Martinique, Guadeloupe, Antillen usw.)
• Unternehmens-SLA mit einer Verfügbarkeit von bis zu 99,9 %
• GSMA-Mitglied für industrielle eSIM-Profile
• Unabhängiges Netz (kein gemeinsam genutztes Netz): geeignet als „zweiter Netzbetreiber“ bei einem Netzwechsel

Schwächen:

• Premium-Tarife: oft +20 bis +40 % im Vergleich zu SFR und Bouygues
• M2M-Vertragslaufzeit häufig 24–36 Monate
• Manchmal hohe Mindestbestellmenge (≈100 SIM-Karten)

Unverbindliche Preisangaben (nur Datenvolumen, ohne Optionen):

SFR Business (SFR IoT)​

SFR bietet wettbewerbsfähige M2M-Angebote mit einem guten Preis-Leistungs-Verhältnis bei groß angelegten Implementierungen und einem beliebten Pooling-System.

M2M-Angebote:

• SFR IoT Connect: M2M-Datenverbindung
• SFR IoT Platform: Flottenmanagement + API + Benachrichtigungen
• Gemeinsam genutzte Angebote (Pooling): ein Gesamtvolumen, das auf alle SIM-Karten des Vertrags aufgeteilt wird

Vorteile:

• Wettbewerbsfähige Tarife (bei durchschnittlichem Datenvolumen oft 15 bis 25 % günstiger als bei Orange)
• Pooling: ideal, wenn der Verbrauch von SIM-Karte zu SIM-Karte variiert
• 4G-Netzausbau vergleichbar mit Orange, leistungsstarkes 5G-Netz in städtischen Gebieten
• Gut dokumentierte API zur Flottenverwaltung

Schwächen:

• In sehr ländlichen Gebieten etwas geringere Netzabdeckung als bei Orange
• Gemeinsam mit Bouygues genutztes Netz („Crozon“) in dünn besiedelten Gebieten: Failover zwischen SFR und Bouygues ist in diesen Gebieten wenig sinnvoll
• Der M2M-Support reagiert manchmal weniger schnell als im Enterprise-Segment

Unverbindliche Preisangaben:

Bouygues Telecom für Unternehmen (IoT)​

Bouygues hat seine Netzabdeckung deutlich verbessert und bietet bei großen Datenvolumina oft die niedrigsten Tarife auf dem Markt an.

M2M-Angebote:

• Bouygues Telecom IoT: Daten-SIM, SMS, Sprachdienste
• FleetMap: Tool zur Flottenverwaltung mit SIM-Karten
• Partnerschaften mit Systemintegratoren für die wichtigsten IoT-Plattformen

Stärken:

• Sehr wettbewerbsfähige Preise, bei großen Stückzahlen oft die niedrigsten
• Lückenlose 4G-Abdeckung, gemeinsame Nutzung des „Crozon“-Netzes mit SFR in dünn besiedelten Gebieten
• Staffelpreise ab ca. 50 SIM-Karten
• Gutes Serviceniveau für kleine und mittelständische Unternehmen

Schwächen:

• Eingeschränktere Präsenz in den französischen Überseegebieten (DOM/COM)
• Gemeinsames Netz mit SFR in dünn besiedelten Gebieten (gleiche Vorbehalte hinsichtlich des Failovers)

Unverbindliche Preisangaben:

Objenious / LoRaWAN (Bouygues)​

Für Anwendungen mit geringem Stromverbrauch und geringer Datenübertragungsrate (Fernablesung von Wasser- und Gaszählern, Geolokalisierung von Anlagen, Umweltsensoren) ist LoRaWAN eine Alternative zum Mobilfunk:

• Landesweites LoRaWAN-Netz, das den Großteil der Bevölkerung abdeckt
• Extrem geringer Stromverbrauch: mehrere Jahre mit einer Batterie
• Einschränkung: ungeeignet für Video, hohe Datenraten oder häufige OTA-Updates

Hinweis: Das LoRaWAN-Ökosystem befindet sich im Wandel (Übernahmen, Neuausrichtung von Akteuren). Vergewissern Sie sich vor einer langfristigen Verpflichtung, dass das Netzwerk und das kommerzielle Angebot langfristig Bestand haben.

MVNOs und spezialisierte IoT-Anbieter​

1NCE – die „lebenslange“ SIM-Karte zum einmaligen Preis​

1NCE bietet ein radikales Modell an: eine einmalige Zahlung von etwa 10 $/12 € für 500 MB Datenvolumen + 250 SMS mit einer Gültigkeit von 10 Jahren, im Netz der Deutschen Telekom und ihrer Partner (darunter Orange in Frankreich), mit Netzabdeckung in über 170 Ländern. Die SIM-Karte unterstützt 2G, 3G, 4G/LTE-M, NB-IoT und wird als „5G-fähig“ beworben.

Geeignet für:

• Anwendungen mit sehr geringem Energieverbrauch (Sensoren, Fernablesung, Asset-Tracking)
• Nahezu keine laufenden Betriebskosten nach dem Kauf; vorhersehbare Kosten über 10 Jahre
• OpenVPN-Tunnel inklusive, Verwaltungsportal und API
• Versionen Industrial (robust) und eSIM/eUICC verfügbar (geringer Aufpreis)

Nachteile:

• Datenlimit von 500 MB über die gesamte Laufzeit: unzureichend für Videos oder häufige OTA-Updates (Aufladung ~12 € pro 500 MB)
• Begrenzte Übertragungsgeschwindigkeit (bis zu 1 Mbit/s)
• Keine eigene private APN wie bei Unternehmensanbietern
• Support außerhalb des Premium-Angebots hauptsächlich schriftlich

1NCE eignet sich hervorragend für einfache und schlichte Anwendungen. Für die industrielle Überwachung, den regelmäßigen VPN-Fernzugriff oder Videoanwendungen ist ein Angebot eines Betreibers oder mehrerer Betreiber erforderlich.

Tele2 IoT / Telenor Connexion​

Auf das IoT spezialisierte europäische Netzbetreiber mit attraktiven länderübergreifenden Angeboten für internationale Implementierungen und einem ausgereiften Flottenmanagement.

Arkessa / ZARIOT / Transatel / Onomondo​

eUICC-/Multi-IMSI-Lösungen, die je nach Netzabdeckung den Wechsel zwischen Netzbetreibern ermöglichen und über einen einheitlichen Netzwerkkern verfügen – besonders geeignet für den Einsatz in mehreren Ländern und zur Vermeidung von Anbieterabhängigkeit (Vendor Lock-in).

Die Multi-Operator-SIM-Karte: die Lösung für kritische Branchen​

Die Multi-Operator-SIM-Karte (Multi-IMSI / eUICC) ist eine Karte, die sich an jedem Standort automatisch mit dem Netzbetreiber verbindet, der das beste Signal bietet, und bei einem Netzausfall auf ein anderes Netz umschaltet.

So funktioniert es​

Vorteile der Multi-Operator-SIM-Karte​

Ideale Anwendungsfälle: Pumpstationen, Wind- und Solarparks, landwirtschaftliche Standorte, Fernablesung an mehreren Standorten, Fahrzeuge im Einsatz, länderübergreifende Implementierungen sowie alle Standorte, an denen eine Überprüfung der Netzabdeckung nach Netzbetreibern vor der Installation zu kostspielig wäre.

Zur Erinnerung „Crozon“: Für eine echte Redundanz muss die Ausfallsicherung Orange (unabhängiges Netz) einschließen und nicht nur SFR + Bouygues, die sich in dünn besiedelten Gebieten das Netz teilen.

Die Eziwan-SIM-Karte​

Die Eziwan-SIM ist eine M2M-SIM-Karte für mehrere Netzbetreiber, die in unsere Angebote integriert ist:

• Automatische Umschaltung zwischen Orange / SFR / Bouygues je nach bester Netzabdeckung
• Gesicherter privater APN (verschlüsselter Datenverkehr zwischen Gateway und Eziwan-Cloud, Rechenzentrum in Frankreich)
• Überwachungs-Dashboard: RSRP, RSRQ, Datenverbrauch in Echtzeit
• Einheitliche Abrechnung: ein einziger Vertrag für die gesamte Flotte
• Keine Mindestabnahmemenge: Bestellen Sie 1 bis 1.000 SIM-Karten
• Kompatibel mit LTE-M und 4G: Entwickelt, um den Auslauf von 2G/3G nahtlos zu bewältigen

Privater APN: Warum er in der Industrie unverzichtbar ist​

Der private APN (Access Point Name) stellt eine dedizierte virtuelle Verbindung zwischen Ihren SIM-Karten und Ihrer Cloud-Infrastruktur her, ohne das öffentliche Internet zu nutzen.

Vorteile des privaten APN:

• Der Datenverkehr wird niemals im öffentlichen Internet offengelegt (reduzierte Angriffsfläche)
• Feste IP-Adressierung möglich (gleiche IP-Adresse pro SIM-Karte, vereinfacht den Fernzugriff)
• Vollständige Netzwerkisolierung gegenüber anderen Kunden des Betreibers
• Wichtiger Baustein für die NIS2-Konformität kritischer und wichtiger Einrichtungen

Öffentlicher APN vs. privater APN:

Verfügbarkeit: Orange, SFR und Bouygues bieten alle private APNs an; bei der Eziwan-SIM ist dies standardmäßig enthalten.

Typischer Datenverbrauch nach Anwendungsfall​

Wenn man das Paket genau auf den Bedarf abstimmt, vermeidet man, zu viel zu bezahlen (oder dass der Vorrat ausgeht). Beobachtete Größenordnungen:

Optimierung durch Edge-Computing: Ein Gateway, das die Daten vor der Übertragung lokal filtert (Totenband, Aggregation, Komprimierung), reduziert den 4G-Verbrauch um 70 bis 95 %. Ein M340-Standort mit 30 Variablen kann von ~150 MB/Monat auf 15–25 MB/Monat sinken — das bedeutet bei 500 Standorten einen Wechsel vom „200-MB“-Tarif zum „50-MB“-Tarif und eine erhebliche Einsparung auf Ebene des gesamten Bestands.

Internationales Roaming: Was Sie beachten sollten​

Für Geräte, die außerhalb Frankreichs eingesetzt werden:

Europäische Union: Bitte beachten Sie, dass M2M-Tarife nicht automatisch von der „Roam Like Home“-Regelung profitieren, die den Privatkundentarifen vorbehalten ist. Für das M2M-Roaming gelten besondere Vertragsbedingungen: Prüfen Sie daher stets die M2M-Klauseln Ihres Anbieters (Datenvolumen, zulässige Dauer des permanenten Roamings, Einschränkungen beim „permanenten Roaming“).

Außerhalb der EU: Die Kosten pro MB können sehr hoch sein (in der Größenordnung von +0,5 bis 2 €/MB). Für einen internationalen Einsatz sollten Sie eine lokale SIM-Karte oder eine globale Multi-IMSI-SIM-Karte (Eziwan, Tele2 IoT, Onomondo) bevorzugen, die den Netzzugang landesweise aushandelt.

Permanentes Roaming: In einigen Ländern (und bei bestimmten Gastnetzbetreibern) wird das permanente Roaming von festen Objekten eingeschränkt oder untersagt. Ein nachhaltiger Einsatz im Ausland muss auf einem Multi-IMSI-Angebot oder einer lokalen SIM-Karte basieren, nicht auf „geduldetem“ Roaming.

Übersichtliche Vergleichstabelle​

★ = Richtwert von Eziwan, der je nach Ihrem Standort und Ihren Mengen angepasst werden sollte.

So treffen Sie die richtige Wahl: Ein kurzer Entscheidungsbaum​

• Einfache Sensoren, sehr geringer Stromverbrauch, festes Budget über 10 Jahre → 1NCE oder LTE-M-Angebot eines Netzbetreibers.
• Nationalpark mit mehreren Standorten, ländliche Gebiete, hohe Kritikalität → Multi-Operator-SIM (Eziwan) mit privatem APN.
• Große städtische Volumina, Kostenoptimierung → Bouygues oder SFR (Pooling).
• Überseegebiete, Anforderung an maximale Netzabdeckung → Orange.
• Internationale / länderübergreifende Bereitstellung → Globale Multi-IMSI-SIM-Karte (Eziwan, Tele2 IoT, Onomondo).
• Video / häufiger Fernzugriff → großzügiger Daten-Tarif eines Betreibers oder mehrerer Betreiber, auf keinen Fall eine „lebenslange“ SIM-Karte mit Datenobergrenze.

In jedem Fall: mindestens 4G/LTE-M-Module (niemals nur 2G/3G) und eigene APN, sobald es sich um sensible Daten handelt.

FAQ – SIM-Karte für industrielles M2M-IoT​

Kann ich eine SIM-Karte für Privatkunden in einem IoT-Gateway verwenden? Technisch gesehen ja, aber es wird nicht empfohlen. SIM-Karten für Privatkunden unterstützen nur einen begrenzten Temperaturbereich (0–40 °C), haben eine kürzere Lebensdauer und bieten weder eine private APN-Adresse noch Flottenüberwachung oder ein industrielles SLA. Bei einer im Feld eingesetzten Geräteflotte werden die Mehrkosten für eine M2M-SIM-Karte durch die Zuverlässigkeit und die zentrale Verwaltung mehr als ausgeglichen.

Werden meine 2G- oder 3G-Geräte weiterhin funktionieren? Nein, auf Dauer nicht. Orange stellt sein 2G-Netz zwischen dem 22. September und dem 20. Oktober 2026 ein, die anderen Betreiber folgen, und 3G wird um das Jahr 2028 abgeschaltet. Alle **reinen 2G-**Module werden ab Herbst 2026 außer Betrieb sein; ein 2G/3G-Modul ohne 4G-Ausweichmöglichkeit wird um das Jahr 2028 herum außer Betrieb sein. Verlangen Sie für alle neuen Projekte 4G / LTE-M / NB-IoT-fähige Geräte.

Wie hoch ist der Mindestdatenverbrauch einer M2M-SIM-Karte im Standby-Modus? Ohne Geschäftsdatenverkehr verbraucht eine M2M-SIM-Karte lediglich die Signale zur Aufrechterhaltung der Netzwerkverbindung (Keep-Alive, Heartbeat): Je nach Netzbetreiber und Konfiguration 1–10 MB/Monat. Bei einem privaten APN und einem permanent aufrechterhaltenen VPN-Tunnel (OpenVPN/IPSec) sollten Sie eher mit 5–15 MB/Monat für Keep-Alive-Daten rechnen, ohne Anwendungsdaten.

Kann man den Anbieter wechseln, ohne alles neu konfigurieren zu müssen? Mit einer eUICC-SIM-Karte (eSIM) ja: Das Anbieterprofil wird aus der Ferne neu konfiguriert, ohne dass ein Eingriff vor Ort erforderlich ist. Bei einer herkömmlichen physischen SIM-Karte für einen einzigen Anbieter muss die Karte physisch ausgetauscht werden. Die Multi-Betreiber-SIM von Eziwan löst dieses Problem: Eine einzige SIM-Karte verwaltet automatisch alle drei französischen Netze.

Was ist der Unterschied zwischen LTE-M und NB-IoT? LTE-M bietet eine höhere Datenübertragungsrate, eine geringe Latenz und unterstützt Mobilität (sich bewegende Objekte, Sprachübertragung möglich) – geeignet für die Bestandsverfolgung und reaktive Telemetrie. NB-IoT zielt auf sehr energiesparende, ortsfeste Objekte (z. B. Zähler im Keller) ab und bietet eine hervorragende Reichweite, jedoch eine geringere Datenübertragungsrate und höhere Latenz. Beide Technologien werden das Ende von 2G/3G überstehen.

Entsprechen M2M-SIM-Karten den französischen Vorschriften? Ja. Die M2M-Angebote der französischen Netzbetreiber werden von der ARCEP reguliert. Für IoT-Daten-SIM-Karten ist keine Identifizierung des Endnutzers erforderlich (kein Ausweis), außer bei Angeboten, die Sprachdienste oder ausgehende SMS an Festnetznummern umfassen.

Wie verwaltet man 500 SIM-Karten, die auf 500 Standorte verteilt sind? Über ein Flottenmanagement-Portal: Datenverbrauch in Echtzeit pro SIM-Karte, Erkennung inaktiver oder übermäßig viel Daten verbrauchender SIM-Karten, Fernaktivierung/-deaktivierung, Anzeige der Signalstärke (RSRP/RSRQ), Warnmeldungen bei Überschreitung von Schwellenwerten. Das Eziwan-Portal integriert diese Verwaltung in dasselbe Dashboard wie die Überwachung Ihrer Geräte, sodass Sie nicht zwischen mehreren Benutzeroberflächen hin- und herwechseln müssen.

Ist eine Multi-Operator-SIM-Karte deutlich teurer? Im Allgemeinen +10 bis +20 % im Vergleich zu einer gleichwertigen SIM-Karte eines einzelnen Anbieters. An einem kritischen Standort sind diese Mehrkosten im Vergleich zu den Kosten eines Ausfalls oder eines technischen Einsatzes aufgrund einer nicht rechtzeitig erkannten Funklücke vernachlässigbar.

Für eine individuelle Empfehlung, die auf Ihren Standortbestand und Ihre geografischen Gebiete zugeschnitten ist, wenden Sie sich bitte an unser Team – wir führen eine kostenlose Netzabdeckungsanalyse für Ihre Standorte durch, und zwar für jeden Netzbetreiber einzeln.

Weiterführende Informationen​

• Blog: LTE-Failover mit zwei SIM-Karten – Sicherung kritischer Verbindungen
• Blog: Überwachung von RSRP/RSRQ im industriellen 4G-Netz – Interpretation der LTE-Kennzahlen
• Blog: Industrieller 4G-LTE-Router – Migration von ADSL vor dem Ende der Kupferkabel
• Blog: 5G-Privatnetz – Anwendungsfälle und ROI für die Fabrik
• Blog: Dual-SIM-Vergleich industrieller Netzbetreiber

Weitere Ressourcen​

• Industrielle Konnektivität – 4G-LTE- und M2M-Konnektivitätslösungen für die Industrie
• Eziwan-Konnektivität – M2M-SIM-Angebote und Managed Connectivity für das industrielle IoT
• Internetverbindung für abgelegene Industriestandorte – Anbindung eines Standorts ohne feste Infrastruktur über 4G/LTE
• Eziwan-Lösungen für die Industrie – umfassendes Angebot für Überwachung und industrielle Konnektivität
• Industrielles IoT-Gateway – operatorunabhängige IoT-Gateways mit integrierter SIM-Verwaltung

Warum Grafana für die industrielle Überwachung?​

Grafana hat sich in der Branche aus mehreren Gründen durchgesetzt:

• Universelle Konnektoren: InfluxDB, TimescaleDB, PostgreSQL, Prometheus, MQTT, REST-API – eine Datenquelle für jeden Stack
• Umfangreiche Dashboards: Zeitreihen, Anzeigen, Statistiken, Tabellen, Heatmaps, Flussdiagramme (mit Plugins)
• Integrierte Warnmeldungen: Benachrichtigungen per SMS, E-Mail, Slack, PagerDuty, Webhook
• Zugriffsverwaltung: Teams, Ordner, Berechtigungen pro Dashboard
• Branchenspezifische Plugins: P&ID (Flussdiagramme), Rohrleitungsdiagramme, Übersichtsdiagramme

Im Vergleich zu einem herkömmlichen SCADA-System:

Architektur: Von Modbus bis Grafana​

Der komplette Stack zur Überwachung von Modbus-SPSen in Grafana:

Alternative bei großen Mengen:

Eziwan-Lösung (All-in-One):

Eziwan umfasst den kompletten Stack (Modbus-/OPC-UA-Erfassung, Cloud-Zeitreihen, vorkonfigurierte Grafana-Dashboards, SMS-/E-Mail-Benachrichtigungen), ohne dass Sie die einzelnen Komponenten selbst installieren und warten müssen.

Grafana + InfluxDB mit Docker installieren​

# docker-compose.yml
version: '3.8'

services:
  influxdb:
    image: influxdb:2.7
    ports:
      - "8086:8086"
    environment:
      DOCKER_INFLUXDB_INIT_MODE: setup
      DOCKER_INFLUXDB_INIT_USERNAME: admin
      DOCKER_INFLUXDB_INIT_PASSWORD: mot_de_passe_securise
      DOCKER_INFLUXDB_INIT_ORG: eziwan
      DOCKER_INFLUXDB_INIT_BUCKET: industrie
      DOCKER_INFLUXDB_INIT_RETENTION: 1825d  # 5 ans
    volumes:
      - influxdb_data:/var/lib/influxdb2

  grafana:
    image: grafana/grafana:10.4.0
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: grafana_securise
    volumes:
      - grafana_data:/var/lib/grafana
    depends_on:
      - influxdb

  telegraf:
    image: telegraf:1.29
    volumes:
      - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
    depends_on:
      - influxdb

volumes:
  influxdb_data:
  grafana_data:

Telegraf-Konfiguration für MQTT​

# telegraf.conf
[[inputs.mqtt_consumer]]
  servers = ["tcp://localhost:1883"]
  topics = ["usine/#"]
  qos = 1
  data_format = "json"
  
  # Parsen des MQTT-Themas: Fabrik/Standort/Station/Variable
  [[inputs.mqtt_consumer.topic_parsing]]
    topic = "usine/+/+/+"
    tags = "_/_/station/_"
    fields = "_/_/_/value"

[[outputs.influxdb_v2]]
  urls = ["http://influxdb:8086"]
  token = "votre_token_influxdb"
  organization = "eziwan"
  bucket = "industrie"

Erstellen Sie Ihr erstes industrielles Dashboard​

Panel 1: Trenddiagramm (Zeitreihe)​

So zeigen Sie die zeitliche Entwicklung des Drucks einer Station an:

InfluxDB-Abfrage (Flux):

from(bucket: "industrie")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "mqtt_consumer")
  |> filter(fn: (r) => r["station"] == "station1")
  |> filter(fn: (r) => r["_field"] == "pression")
  |> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
  |> yield(name: "mean")

Einstellungen im Bedienfeld:

• Typ: Time series
• Einheit der Y-Achse: bar (Druck)
• Linienbreite: 2
• Füllungsopazität: 10
• Schwellenwerte: grün < 8 bar, orange 8–10 bar, rot > 10 bar

Feld 2: Anzeige (Momentanwert)​

So zeigen Sie den aktuellen Wert einer Variablen an:

InfluxDB-Abfrage:

from(bucket: "industrie")
  |> range(start: -1m)
  |> filter(fn: (r) => r["station"] == "station1" and r["_field"] == "pression")
  |> last()

Einstellungen des Panels:

• Typ: Gauge
• Min: 0, Max: 16
• Einheit: bar
• Schwellenwerte: 0=grün, 10=orange, 12=rot

Panel 3: Kennzahlen (KPI)​

So zeigen Sie die Gesamtanlageneffektivität (TRS) oder einen Produktionszähler an:

InfluxDB-Abfrage:

from(bucket: "industrie")
  |> range(start: -24h)
  |> filter(fn: (r) => r["_field"] == "pieces_produites")
  |> sum()

Panel-Einstellungen:

• Typ: Stat
• Einheit: pcs (benutzerdefiniert)
• Farbmodus: Background (rot, wenn < Zielwert)

Panel 4: Tabelle mit mehreren Standorten​

So zeigen Sie den Status all Ihrer Websites in Echtzeit an:

from(bucket: "industrie")
  |> range(start: -5m)
  |> filter(fn: (r) => r["_field"] == "pression" or r["_field"] == "debit" or r["_field"] == "etat")
  |> last()
  |> pivot(rowKey: ["_time", "station"], columnKey: ["_field"], valueColumn: "_value")

Ergebnis: Tabelle mit den Spalten „Station“, „Druck“, „Durchfluss“ und „Status“, eine Zeile pro Standort.

Grafana-Benachrichtigungen einrichten​

Warnung bei Überschreitung des Schwellenwerts​

In Grafana 10+ (Unified Alerting):

1. Das Panel öffnen → Edit → Alert
2. Eine Regel erstellen:

   Condition: WHEN last() OF query(A, 5m, now) IS ABOVE 10
   

3. Die Benachrichtigung konfigurieren:
   • Kontaktpunkt: E-Mail → maintenance@usine.fr
   • Kontaktpunkt: Webhook → SMS über Twilio/OVH SMS
4. Automatische Stummschaltung: 15 Minuten nach Bestätigung

Alarmgruppierung für mehrere Standorte​

Um „Alert Storms“ zu vermeiden, wenn mehrere Standorte gleichzeitig ausfallen:

# alertmanager.yml
route:
  group_by: ['alertname', 'site']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: 'maintenance-team'

receivers:
  - name: 'maintenance-team'
    email_configs:
      - to: 'maintenance@usine.fr'
        send_resolved: true
    webhook_configs:
      - url: 'https://api.sms-provider.fr/send'

Anmerkungen zu Ereignissen​

Bei Alarmen automatische Anmerkungen zu den Diagrammen hinzufügen:

// Bei einem Fehler eine InfluxDB-Anmerkung erstellen
from(bucket: "industrie")
  |> range(start: v.timeRangeStart)
  |> filter(fn: (r) => r["_field"] == "defaut" and r["_value"] == 1)
  |> map(fn: (r) => ({r with _value: "Défaut détecté sur ${r.station}"}))

Grafana-Vorlagen und -Variablen für mehrere Standorte​

Mit den Template-Variablen können Sie ein generisches Dashboard erstellen, das für alle Ihre Websites wiederverwendbar ist.

Eine Variable „site“ erstellen​

Dashboard Settings → Variables → New Variable:

• Name: site
• Typ: Query
• Datenquelle: InfluxDB
• Abfrage:

  import "influxdata/influxdb/schema"
  schema.tagValues(bucket: "industrie", tag: "station")
  

Die Variable in den Panels verwenden​

from(bucket: "industrie")
  |> range(start: v.timeRangeStart)
  |> filter(fn: (r) => r["station"] == "${site}")
  |> filter(fn: (r) => r["_field"] == "pression")

Der Betreiber kann nun den Standort aus einem Dropdown-Menü oben im Dashboard auswählen.

Vorkonfigurierte Grafana-Dashboards für die Industrie​

Dashboard zur Überwachung der Pumpstation​

┌─────────────────────────────────────────────────────────────────┐
│  Messstation: [Dropdown]  │  Zeitraum: [6 Std.|24 Std.|7 Tage|30 Tage] │
├──────────────┬──────────────┬──────────────┬────────────────────┤
│  Druck    │   Durchfluss │  Füllstand │  Pumpenzustand │
│  [gauge]     │   [gauge]    │  [gauge]     │  [stat 🟢/🔴]      │
├──────────────┴──────────────┴──────────────┴────────────────────┤
│  24-Stunden-Trends: Druck / Durchfluss / Füllstand │
│  [time series graph]                                             │
├─────────────────────────────────────────────────────────────────┤
│  Aktive Alarme    │  Letzte Einsätze │
│  [table]            │  [table annotations]                       │
└─────────────────────────────────────────────────────────────────┘

Dashboard für die Produktion an mehreren Standorten​

┌────────────────────────────────────────────────────────────────────┐
│  Vue globale — 15 sites                                            │
├──────────┬──────────┬──────────┬──────────┬──────────┬────────────┤
│ Site 1   │ Site 2   │ Site 3   │ Site 4   │ Site 5   │ ...        │
│ TRS: 87% │ TRS: 91% │ TRS: 73% │ TRS: 94% │ TRS: 82% │            │
│ 🟢 OK    │ 🟢 OK    │ 🔴 Alrm  │ 🟢 OK    │ 🟡 Warn  │            │
├──────────┴──────────┴──────────┴──────────┴──────────┴────────────┤
│  Kumulierte Produktion in 24 Stunden: Ziel vs. Ist [Balkendiagramm] │
└────────────────────────────────────────────────────────────────────┘

Integration von Eziwan in Grafana​

Eziwan bietet zwei Möglichkeiten zur Integration mit Grafana:

Modus 1: Grafana, gehostet bei Eziwan (empfohlen)​

Die Eziwan-Plattform integriert Grafana nativ. Ihre Modbus-/OPC-UA-Daten befinden sich bereits in unserer in Frankreich gehosteten Zeitreihendatenbank. Sie greifen direkt über Ihren Browser auf die Dashboards zu, mit:

• Vorkonfigurierten Dashboards für gängige Anwendungsfälle (Wasser, Energie, Produktion)
• Verwalteten SMS-/E-Mail-Benachrichtigungen
• 5-jähriger Datenhistorie ohne Konfiguration
• Unterstützung für mehrere Standorte und Benutzer sowie Rechteverwaltung

Modus 2: Export in Ihr bestehendes Grafana​

Wenn Sie bereits über ein internes Grafana verfügen:

• Eziwan-REST-API: Rufen Sie Ihre Daten über GET /api/v1/variables/{id}/history ab
• MQTT-Webhook: Eziwan veröffentlicht Ihre Daten auf Ihrem bestehenden MQTT-Broker
• Eziwan-Grafana-Plugin (auf Anfrage erhältlich): Datenquellen-Plugin für die direkte Verbindung

FAQ – Grafana für die industrielle Überwachung​

Kann Grafana ein SCADA-System im Produktivbetrieb ersetzen? Für die Visualisierung und Alarmierung ja, in vielen Fällen. Für die Echtzeitsteuerung (Schreiben an SPS, Steuerungssequenzen) wird weiterhin ein SCADA- oder ein dediziertes HMI-System empfohlen. Grafana zeichnet sich durch Protokollierung, Trendanalyse und standortübergreifendes Monitoring aus.

Welche Datenbank eignet sich zum Speichern von Industriedaten in Grafana? InfluxDB ist die Standardwahl für industrielle Zeitreihen (hohe Frequenz, native Komprimierung, leistungsstarke Flux-Abfragen). TimescaleDB (eine PostgreSQL-Erweiterung) eignet sich, wenn Sie bereits PostgreSQL einsetzen. Prometheus ist für Infrastrukturmetriken geeignet, für Prozessdaten jedoch weniger relevant.

Wie kann man den Zugriff auf Grafana über das Internet sichern? Grafana hinter einem Reverse-Proxy (Nginx/Traefik) mit TLS bereitstellen, die OIDC/LDAP-Authentifizierung aktivieren, den anonymen Zugriff deaktivieren und Warnmeldungen bei fehlgeschlagenen Anmeldeversuchen konfigurieren. InfluxDB niemals direkt im Internet verfügbar machen.

Kann Grafana 1.000 Standorte und 100.000 Variablen verwalten? Ja, mit der richtigen Architektur. InfluxDB 2.x unterstützt Milliarden von Datenpunkten. Grafana Enterprise unterstützt Clustering. Bei sehr großen Datenmengen sollten Sie Apache Kafka als vorgelagerte Lösung für das Streaming sowie differenzierte Aufbewahrungsrichtlinien in Betracht ziehen (1-Sekunden-Daten werden 30 Tage lang aufbewahrt, 1-Minuten-Daten 5 Jahre lang).

Kann ich in Grafana ein P&ID-Übersichtsdiagramm erstellen? Ja, mit dem Plugin Flowcharting (basierend auf draw.io). Sie zeichnen Ihr P&ID-Schema, verknüpfen Grafana-Variablen mit jedem Gerät, und die Werte werden in Echtzeit auf dem Übersichtsdiagramm angezeigt, wobei sich die Farbe je nach Status ändert.

Weiterführende Informationen​

• Blog: Vorausschauende Instandhaltung mit IIoT – von den Sensordaten bis zum Alarm vor Ort
• Blog: Industrielle Fernüberwachung – umfassender Leitfaden 2026
• Blog: Modbus TCP vs. RTU – welches Protokoll soll man wählen?
• Blog: Photovoltaikpark – IoT-Überwachung und -Monitoring
• Dokumente: Modbus-RTU-Konfiguration auf dem Eziwan-Gateway

Möchten Sie Grafana-Dashboards nutzen, ohne sich um die Infrastruktur kümmern zu müssen? Testen Sie Eziwan 30 Tage lang kostenlos – Ihre Modbus-Daten in Grafana in weniger als einer Stunde.

Weitere Ressourcen​

• Modbus RTU in die Cloud – Verbinden Sie Ihre RS-485-Modbus-RTU-Geräte mit der Cloud
• Industrieller Cloud-Datenlogger – Speichern Sie Ihre Modbus-Daten in der Cloud
• Cloud-SCADA – Cloud-SCADA-Plattform mit integrierten Dashboards
• Industrieprotokolle – Modbus, MQTT, OPC UA und andere Protokolle verstehen
• Industrielle Überwachung und Fernwartung — standortübergreifende Überwachung Ihrer Modbus-Geräte

Was ist OPC-UA und warum ist es wichtig?​

OPC-UA (IEC 62541) ist ein plattformunabhängiges Kommunikationsprotokoll, das für den sicheren Austausch industrieller Daten entwickelt wurde. Im Gegensatz zu seinem Vorgänger OPC-DA (nur Windows, DCOM) läuft OPC-UA auf jedem Betriebssystem (Linux, Windows, eingebettete Echtzeit-Betriebssysteme) und in jedem Netzwerk (Ethernet, 4G, WLAN).

Warum OPC-UA in der Industrie 4.0 dominiert​

• Interoperabilität: Ein Siemens S7-1500 OPC-UA-Server kann von jedem konformen Client ohne proprietären Treiber ausgelesen werden
• Informationsmodell: Die Daten haben eine Bedeutung (Einheit, Beschreibung, Historie), nicht nur einen Wert
• Native Sicherheit: Verschlüsselung, Authentifizierung, Zertifikate – im Protokoll integriert
• Konformitätsprofile: eine schlanke Teilmenge für kleine Embedded-Geräte
• Pubsub & MQTT: OPC-UA-Pub/Sub-Erweiterung für Cloud-Architekturen (IEC 62541-14)

OPC-UA-Architektur: Die grundlegenden Konzepte​

Client-Server​

Das OPC-UA-Basismodell ist Client-Server:

• OPC-UA-Server: wird vom Gerät bereitgestellt (SPS, HMI, Datenserver)
• OPC-UA-Client: nutzt die Daten (SCADA, Gateway, Cloud-Anwendung)

Ein und dasselbe Gerät kann gleichzeitig als Server und als Client fungieren (z. B. ein Gateway, das mehrere SPSen bündelt und die konsolidierten Daten bereitstellt).

Adressraum und NodeId​

Der Address Space ist der Informationsbaum, den ein OPC-UA-Server bereitstellt. Jeder Knoten verfügt über eine eindeutige NodeId:

NodeId-Format:

• ns=2;i=1234 — Namespace 2, ganzzahlige Kennung 1234
• ns=2;s=Station_1.Pression — Namespace 2, Kennung als Zeichenfolge
• ns=0;i=2258 — Namespace 0 (Standard), ServerStatus

Namensräume:

• ns=0: Standard-OPC-UA-Namensraum (Typen, Methoden)
• ns=1: häufig der Namensraum des Herstellers
• ns=2+: Anwendungsnamensräume (Ihre Daten)

Kommunikationswege​

Abonnements sind der richtige Ansatz für die Echtzeitüberwachung: Anstatt jede Sekunde abzufragen, abonniert der Client einen Knoten und erhält nur dann eine Benachrichtigung, wenn sich der Wert über einen konfigurierbaren Schwellenwert (DeadbandValue) hinaus ändert.

OPC-UA-Sicherheit: Der umfassende Leitfaden​

Sicherheit ist eine der Stärken von OPC-UA – und zugleich eine der Ursachen für Komplexität. Hier sind die wesentlichen Konzepte.

Sicherheitsmodi​

X.509-Zertifikate​

OPC-UA verwendet X.509-Zertifikate für die gegenseitige Client-Server-Authentifizierung:

Erstellung eines selbstsignierten Zertifikats für Testzwecke:

# Avec OpenSSL
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout client_key.pem -out client_cert.pem \
  -subj "/CN=EziwanGateway/O=Eziwan/C=FR" \
  -extensions v3_req \
  -config <(cat /etc/ssl/openssl.cnf; echo "[v3_req]"; echo "subjectAltName=URI:urn:eziwan:gateway:client")

Im Produktivbetrieb: Verwenden Sie eine interne PKI oder eine anerkannte Zertifizierungsstelle. Die Zertifikate müssen beim ersten Mal manuell zwischen Client und Server ausgetauscht werden.

Benutzerauthentifizierung​

Neben den Maschinenzertifikaten unterstützt OPC-UA die Benutzerauthentifizierung:

• Anonym: keine Authentifizierung (sofern vom Server zugelassen)
• Benutzername/Passwort: Anwendungs-Login
• Zertifikat: X.509-Benutzerzertifikat
• IssuedToken: JWT- oder Kerberos-Token

OPC-UA in Python implementieren​

Die Bibliothek python-opcua (oder ihr Fork asyncua) ist der Standard in Python.

Installation​

pip install asyncua

OPC-UA-Client in Python – Daten lesen​

import asyncio
from asyncua import Client

async def main():
    url = "opc.tcp://192.168.1.10:4840/freeopcua/server/"
    
    async with Client(url=url) as client:
        # Einen Knoten anhand der NodeId abrufen
        node = client.get_node("ns=2;s=Station_1.Pression")
        value = await node.read_value()
        print(f"Pression: {value} bar")
        
        # Mehrere Knoten im Batch-Modus lesen
        nodes = [
            client.get_node("ns=2;s=Station_1.Pression"),
            client.get_node("ns=2;s=Station_1.Debit"),
            client.get_node("ns=2;s=Station_1.Defaut"),
        ]
        values = await client.read_values(nodes)
        for node, val in zip(nodes, values):
            print(f"  {node}: {val}")

asyncio.run(main())

OPC-UA-Client für Python – Abonnement (Subscription)​

import asyncio
from asyncua import Client
from asyncua.common.subscription import SubHandler

class DataChangeHandler(SubHandler):
    def datachange_notification(self, node, val, data):
        print(f"[CHANGE] {node} = {val}")
    
    def event_notification(self, event):
        print(f"[EVENT] {event}")

async def main():
    url = "opc.tcp://192.168.1.10:4840"
    
    async with Client(url=url) as client:
        handler = DataChangeHandler()
        subscription = await client.create_subscription(500, handler)  # 500ms
        
        nodes = [
            client.get_node("ns=2;s=Station_1.Pression"),
            client.get_node("ns=2;s=Station_1.Debit"),
        ]
        
        monitored_items = await subscription.subscribe_data_change(nodes)
        print("Subscriptions actives, attente changements...")
        
        await asyncio.sleep(30)  # 30 Sekunden anhören
        await subscription.unsubscribe(monitored_items)

asyncio.run(main())

Sichere Verbindung mit Zertifikat​

from asyncua.crypto.security_policies import SecurityPolicyBasic256Sha256
from asyncua.crypto.cert_man import CertificateManager

async def connect_secure():
    client = Client("opc.tcp://192.168.1.10:4840")
    
    await client.set_security(
        SecurityPolicyBasic256Sha256,
        certificate="./client_cert.der",
        private_key="./client_key.pem",
        server_certificate="./server_cert.der"
    )
    
    await client.connect()
    # ... Ihre Vorgänge
    await client.disconnect()

OPC-UA in Node.js implementieren​

Die Bibliothek node-opcua ist die Standardbibliothek für JavaScript/TypeScript.

npm install node-opcua

Daten auslesen​

const opcua = require("node-opcua");

const client = opcua.OPCUAClient.create({
    endpointMustExist: false,
    connectionStrategy: { maxRetry: 5, initialDelay: 2000 }
});

const endpointUrl = "opc.tcp://192.168.1.10:4840";

async function main() {
    await client.connect(endpointUrl);
    const session = await client.createSession();
    
    const nodeToRead = {
        nodeId: "ns=2;s=Station_1.Pression",
        attributeId: opcua.AttributeIds.Value
    };
    
    const dataValue = await session.read(nodeToRead);
    console.log(`Pression: ${dataValue.value.value} bar`);
    console.log(`Timestamp: ${dataValue.serverTimestamp}`);
    
    await session.close();
    await client.disconnect();
}

main().catch(console.error);

OPC-UA auf den gängigsten Industrie-SPSen​

Siemens S7-1500 / S7-1200​

Der S7-1500 unterstützt seit Firmware 2.0 nativen OPC-UA-Server:

• Port: 4840 (TCP)
• Konfiguration im TIA Portal: Device Configuration → OPC UA → Server
• Aktivieren Sie die gewünschten Knoten in der Zugriffskonfiguration
• Authentifizierung: Zertifikate oder Benutzername/Passwort

Die S7-1200 unterstützt OPC-UA ab Firmware-Version 4.1.

Schneider Electric M580 / M340​

M580: OPC-UA über das Modul BMENOC0311 (Firmware ≥ V2.0) M340: keine native OPC-UA-Unterstützung → Modbus TCP empfohlen oder OPC-UA-zu-Modbus-Gateway (z. B. Kepware KEPServerEX)

Allen-Bradley / Rockwell (EtherNet/IP)​

Rockwell-Steuerungen unterstützen OPC-UA nicht nativ. Optionen:

• KEPServerEX (Kepware): EtherNet/IP-zu-OPC-UA-Brücke
• FactoryTalk Linx Gateway: OPC-UA-Server für das Rockwell-Ökosystem
• Eziwan Gateway: direkte EtherNet/IP/Modbus-Verbindung, REST-API-Schnittstelle

Beckhoff TwinCAT 3​

TwinCAT 3 verfügt über einen nativen OPC-UA-Server über TF6100 (OPC-UA-Modul). Konfiguration über den TwinCAT System Manager.

Wago / Phoenix Contact / Pilz​

Die meisten modernen SPSen dieser Hersteller unterstützen OPC-UA. Überprüfen Sie die Firmware und aktivieren Sie den Server in der Netzwerkkonfiguration.

OPC-UA PubSub: Die Erweiterung für die Cloud​

OPC-UA PubSub (IEC 62541-14) ist die Erweiterung, die OPC-UA mit Cloud-basierten IoT-Architekturen kompatibel macht:

• Publisher: Das Gerät veröffentlicht seine Daten über eine nachrichtenorientierte Middleware
• Subscriber: Die Cloud oder das SCADA-System abonniert den Datenstrom

Unterstützte Protokolle:

• AMQP (Port 5672)
• MQTT (Port 1883 oder 8883) – das im IoT am häufigsten verwendete Protokoll
• UDP-Multicast (lokales Netzwerk)

Kodierungen:

• JSON (lesbar, einfache Fehlersuche)
• UADP (binär, kompakt, eingebettet)

Beispiel für eine OPC-UA-PubSub-JSON-Nachricht:

{
  "MessageId": "abc123",
  "PublisherId": "urn:station1:plc",
  "DataSetWriterId": 1,
  "MetaDataVersion": {"MajorVersion": 1, "MinorVersion": 0},
  "Timestamp": "2026-08-14T10:30:00.000Z",
  "Payload": {
    "Station_1.Pression": {"Value": 4.2, "StatusCode": 0, "SourceTimestamp": "2026-08-14T10:29:59.950Z"},
    "Station_1.Debit": {"Value": 125.3, "StatusCode": 0, "SourceTimestamp": "2026-08-14T10:29:59.950Z"}
  }
}

Migration von OPC-DA zu OPC-UA​

Wenn Sie Anlagen unter OPC-DA (OPC Classic, Windows DCOM) betreiben, bietet die Migration zu OPC-UA folgende Vorteile:

• Wegfall der Abhängigkeit von Windows/DCOM
• Kompatibilität mit Linux, Raspberry Pi und Linux-SPSen
• Verschlüsselung (in OPC-DA nicht vorhanden)
• Direkter Internetzugang (mit DCOM ohne komplexes VPN nicht möglich)

Migrationswerkzeug: OPC-UA-Wrapper (z. B. Kepware) erstellt einen OPC-UA-Server, der die Daten eines bestehenden OPC-DA-Servers bereitstellt und so eine schrittweise Migration ermöglicht.

OPC-UA mit dem Eziwan-Gateway​

Das Eziwan Gateway verfügt über einen integrierten OPC-UA-Client, der eine Verbindung zu den OPC-UA-Servern Ihrer Geräte herstellen kann:

• Verbindung zu Siemens S7-1500 OPC-UA (Port 4840)
• Verbindung zu jedem OPC-UA-Server gemäß IEC 62541
• Unterstützung der Sicherheitsmodi None, Sign, SignAndEncrypt
• Konfiguration der NodeIDs in der Cloud-Oberfläche (automatische Suche im Adressraum)
• Datenübertragung an die Eziwan-Cloud-Plattform über MQTT/TLS

Hauptvorteil: Sie müssen keinen OPC-UA-Client selbst programmieren. Das Gateway übernimmt diese Aufgabe und stellt eine REST-API für Ihr SCADA- oder ERP-System bereit.

FAQ – OPC-UA​

Ist OPC-UA komplexer als Modbus? Ja, aber bei Anlagen mit Geräten verschiedener Hersteller und bei Industrie-4.0-Projekten ist dies gerechtfertigt. Für eine Anlage mit 2–3 Steuerungen desselben Herstellers kann Modbus TCP ausreichend sein. OPC-UA ist unverzichtbar, wenn Sie heterogene Geräte, Sicherheitsanforderungen oder den Bedarf an ERP/MES-Interoperabilität haben.

Muss Port 4840 in meiner Firewall geöffnet sein? Bei einer „Zero-Inbound-Port“-Architektur (wie bei Eziwan) initiiert das Gateway die Verbindung zum OPC-UA-Server intern. Von außen ist kein Port geöffnet. Der verschlüsselte VPN-Tunnel leitet die Daten in die Cloud weiter.

Kann OPC-UA MQTT in einer IoT-Architektur ersetzen? OPC-UA PubSub mit MQTT-Transport vereint das Beste aus beiden Welten: das semantische Informationsmodell von OPC-UA mit der Leichtigkeit und Skalierbarkeit von MQTT. Dies ist die Richtung, die die Industrie-4.0-Referenzmodelle (Industrie 4.0 Architecture Reference Model, IDS-R) einschlagen.

Welche Leistung kann man von einem eingebetteten OPC-UA-Server erwarten? Eine Siemens S7-1500 CPU 1515 kann pro Sekunde etwa 10.000 OPC-UA-Knoten im Lesemodus verarbeiten. Bei weniger leistungsstarken SPSen (M221, kleine WAGO-Modelle) sollte das OPC-UA-Polling auf 100–500 Knoten/s begrenzt werden. Bei großen Datenmengen sind Abonnements (Subscription) wesentlich effizienter als das Polling.

Gibt es kostenlose OPC-UA-Server zum Testen? Ja: ProsysOPC UA Simulation Server (kostenlos, Windows), Node-RED mit node-red-contrib-opcua (kostenlos, plattformübergreifend), python-opcua im Servermodus (Beispiel in der GitHub-Dokumentation). Damit lässt sich ein Client testen, ohne dass eine physische SPS vorhanden sein muss.

Weiterführende Informationen​

• Blog: OPC-UA und MQTT – wie man beide auf einem industriellen Gateway kombiniert
• Blog: Sicherer Fernzugriff auf SPS und SCADA – VPN, Zero-Trust und NIS2
• Blog: Eine Siemens S7-SPS mit der Cloud verbinden – Technischer Leitfaden
• Blog: IEC 62443 – Praktischer Leitfaden für industrielle Cybersicherheit
• Blog: Modbus TCP vs. RTU – umfassender Vergleich für das industrielle IoT

Benötigen Sie Hilfe bei der Anbindung Ihrer OPC-UA-Server an die Cloud? Fordern Sie eine kostenlose Demo an – unser Team begleitet Sie vom Proof of Concept bis zur Implementierung.

Weitere Ressourcen​

• OPC UA zu MQTT – OPC-UA-Daten an einen MQTT-Cloud-Broker veröffentlichen
• Industrieprotokolle – Vergleich zwischen OPC UA, Modbus, MQTT und anderen Protokollen
• Industrielles IoT-Gateway – Auswahl eines OPC-UA-kompatiblen Gateways
• Modbus TCP in die Cloud – Überwachung von Modbus-TCP-Steuerungen aus der Cloud
• Cloud-SCADA — moderne SCADA-Architektur mit OPC-UA- und Cloud-Anbindung

Warum sollten Sie Ihr M340/M221 mit der Cloud verbinden?​

Die Steuerungen von Schneider Electric aus der Modicon-Reihe kommen in Tausenden von französischen Industrieanlagen zum Einsatz: Wasseraufbereitung, Pumpstationen, Verarbeitungsprozesse in der Lebensmittelindustrie, Verpackungslinien. Sie sind robust und zuverlässig und haben oft eine Lebensdauer von 15 bis 20 Jahren.

Allerdings sind ihre nativen Kommunikationsmöglichkeiten begrenzt:

• Keine native Cloud-Anbindung
• Fernzugriff oft auf ein kostspieliges MPLS-VPN beschränkt
• Keine Langzeitaufzeichnung ohne einen SCADA-Server vor Ort
• Keine oder nur lokale Warnmeldungen (Kontrollleuchten, Signalhörner)

Die Lösung: ein industrielles IoT-Gateway, das die Modbus-Daten Ihres M340/M221 ausliest und an die Cloud weiterleitet, ohne das SPS-Programm zu ändern.

Modbus-Kompatibilität der Schneider Electric-SPSen​

Modicon M221​

Der M221 (TM221CE16R, TM221CE24T, usw.) verfügt über einen nativen Modbus-RTU-Anschluss an seiner RJ45-Buchse (RS-485 über den Adapter TM3TI4 oder ein spezielles Kabel) sowie einen Modbus-TCP-Anschluss an seinem Ethernet-Anschluss.

Zugängliche Register:

• %MW0 bis %MW255 — Speicherwörter
• %QW — Analogausgänge
• %IW — Analogeingänge
• %M — Speicherbits (Spulen 0–255)

Konfiguration des Modbus-Slaves am M221:

In EcoStruxure Machine Expert – Basic:

1. Configuration → Modbus Serial oder Modbus TCP
2. Slave-Adresse: 1 (Standard)
3. „Slave-Funktion“ aktivieren → OK

Modicon M340​

Der M340 (BMX P34 2020, BMX P34 2030, usw.) verfügt über eine serielle Modbus-RTU-Schnittstelle (RS-485, 9-poliger SUB-D-Stecker) und ein ETH-Modul (BMX NOE 0100 oder BMX NOC 0401) für Modbus-TCP.

Über Modbus zugängliche Register:

Modbus-Adresse → Unity Pro-Adresse:

• Register 400001 = %MW0
• Register 400100 = %MW99
• Register 400501 = %MW500

Modicon M580 (ePAC)​

Der M580 verfügt über natives Modbus-TCP an seinem CPU-Ethernet-Anschluss und unterstützt dieselben Registertabellen wie der M340, zusätzlich bietet er:

• Zugriff auf die E/A-Module über BMENOC0311 (Ethernet-Modul)
• EtherNet/IP-Unterstützung
• Data-Exchange-Fähigkeit mit EcoStruxure Plant

Verbindungsarchitektur​

Option 1: Über Modbus TCP (Ethernet) – empfohlen​

Voraussetzungen:

• ETH-Modul im Rack installiert (BMX NOE 0100 für M340)
• IP-Adresse der SPS konfiguriert (z. B. 192.168.1.10)
• Interne Firewall, die Port 502 von der IP-Adresse des Gateways zulässt

Vorteile:

• Keine zusätzliche RS-485-Verkabelung
• Höhere Datenrate (bis zu 30 Abfragen/Sekunde)
• Kompatibilität mit Traffic Unity Pro (nicht-intrusive Messungen)

Option 2: Über Modbus RTU (RS-485)​

Für den M221: Verwenden Sie je nach Baureihe das Kabel TCSMCNAM3M002P (RJ45 auf RS-485) oder den Adapter VW3A8306.

Für den M340: 9-poliger SUB-D-Stecker auf der SPS-Seite, Klemmen 3 (+) und 8 (-) für RS-485.

Serielle Einstellungen M221/M340 (Standardwerte):

• Baudrate: 19200 bps
• Parität: keine (8N1)
• Slave-Adresse: 1

Konfiguration des Eziwan-Gateways für Schneider​

Sobald das Gateway verbunden ist, lässt sich die Konfiguration über die Eziwan-Cloud-Oberfläche mit wenigen Klicks vornehmen.

Ein Modbus-Gerät hinzufügen​

1. Auf Flotte → Site → + Équipement zugreifen
2. Modbus TCP oder Modbus RTU auswählen
3. Folgende Angaben eingeben:
   • IP: 192.168.1.10 (oder die Adresse Ihres M340)
   • Port: 502
   • Slave-ID: 1

Die zu lesenden Variablen konfigurieren​

Umrechnungstechnik: Einen Multiplikationsfaktor anwenden, wenn die SPS einen Rohwert zurückgibt (z. B. ×0.01, um von 1500 auf 15,00 bar umzurechnen).

Empfohlene Abfrageintervalle​

Was Sie in der Cloud erhalten​

Echtzeit-Dashboard​

Sobald das Gateway zum ersten Mal eine Verbindung herstellt, werden die Daten in Echtzeit im Eziwan-Dashboard angezeigt:

• Trendkurven für 1 Stunde, 24 Stunden, 7 Tage, 30 Tage
• Konfigurierbare Anzeigen und Indikatoren
• Standortübergreifende Übersichten zum Vergleich Ihrer Anlagen
• CSV-/Excel-Export für das Reporting

Warnsystem​

Richten Sie für jede Variable präzise Warnmeldungen ein:

Warnung: Füllstand im Behälter
  Condition : %MW10 < 10 (niveau bas)
  Canal : SMS + Email
  Empfänger: equipe@maintenance.fr, astreinte@maintenance.fr
  Acquittement : requis

Warnung: Pumpenfehler
  Bedingung: %M5 = 1 (Fehlerbit aktiv)
  Kanal: Sofort-SMS
  Priorität: Kritisch

Langzeitgeschichtliche Betrachtung​

Alle Daten werden standardmäßig 5 Jahre lang ohne zusätzliche Kosten archiviert. Sie können:

• die Produktionsverläufe der Jahre N-1 und N-2 einsehen
• fortschreitende Verschlechterungen erkennen (Pumpe, die mehr Strom verbraucht)
• Konformitätsberichte erstellen (Wasser, Energie, Pharmazie)

Fallbeispiel: Pumpstation M340​

Hintergrund: Eine Kommune betreibt 12 Pumpstationen, die mit M340 BMX P34 2020 ausgestattet sind. Derzeitige Wartung: 3 Rundgänge vor Ort pro Woche, 2 Techniker.

Eingesetzte Konfiguration:

• 12 × Eziwan Gateway (Modbus TCP, SFR Business-SIM-Karte)
• Pro Station ausgelesene Variablen: Brunnenpegel, Durchfluss, Förderdruck, Motorstrom, Betriebsstunden, Fehler (12 Variablen)
• Abfrageintervall: 5 s für Durchfluss/Druck/Fehler, 1 min für Füllstand/Zähler

Ergebnisse nach 6 Monaten:

• Rundgänge vor Ort: 3/Woche → 1/Woche (-67 %)
• Vor einem Ausfall erkannte Störungen: 4 (überhitzte Pumpe, klemmendes Ventil, festsitzender Schwimmer)
• Berechnete Einsparungen: 41.000 €/Jahr (Einsparungen bei Anfahrtskosten und vermiedenen Korrekturwartungen)
• ROI für Hardware und Abonnement: 5 Monate

Migration von SoMachine / Unity Pro​

Wenn Sie SoMachine (M221) oder Unity Pro (M340/M580) verwenden, sind keine Änderungen am SPS-Programm erforderlich. Das Eziwan-Gateway stellt standardmäßig eine Verbindung im Nur-Lese-Modus her.

Wenn Sie ebenfalls Befehle (Sollwerte, Steuerbefehle) über die Cloud schreiben möchten:

• Verwenden Sie die Funktionscodes FC05 (Write Single Coil) und FC06 (Write Single Register)
• Konfigurieren Sie die Zugriffsrechte im Eziwan-Gateway (Multi-Faktor-Authentifizierung)
• Legen Sie Registrierbereiche an, die speziell für Fernsteuerungen vorgesehen sind (z. B. %MW200-MW220)

EcoStruxure-Kompatibilität​

Das Eziwan-Gateway ist in mehrfacher Hinsicht mit EcoStruxure kompatibel:

Parallel zu EcoStruxure Plant​

Das Gateway liest dieselben Register wie Ihr EcoStruxure-SCADA-System, ohne dass es zu Beeinträchtigungen kommt. Ideal für folgende Erweiterungen:

• Zentralisierte Überwachung mehrerer Standorte
• Mobiler Zugriff für Außendiensttechniker
• SMS-/E-Mail-Benachrichtigungen (die in der Basisversion von EcoStruxure oft fehlen)

Schrittweiser Austausch​

Wenn die Laufzeit Ihrer EcoStruxure Plant-Lizenz bald abläuft, können Sie schrittweise migrieren:

1. Das Eziwan-Gateway parallel einrichten
2. Die Daten 4–8 Wochen lang validieren
3. Die Hauptüberwachung auf Eziwan umstellen
4. Reduzieren Sie den Umfang der EcoStruxure-Lizenz auf das tatsächlich erforderliche Maß

Vergleich der Cloud-Verbindungen: M221 vs. M340 vs. M580​

FAQ – Verbindung des M340/M221 mit der Cloud​

Muss das SoMachine/Unity Pro-Programm geändert werden? Nein. Das Eziwan-Gateway verbindet sich als Modbus-Master mit der Slave-SPS. Es wird keine einzige Zeile Code zur SPS hinzugefügt. Wenn die SPS bereits als Modbus-Slave konfiguriert ist (was standardmäßig der Fall ist), wird die Verbindung sofort hergestellt.

Mein M340 verfügt bereits über ein SCADA Unity Pro – ist das kompatibel? Ja. Mehrere Modbus-TCP-Master können denselben Slave gleichzeitig abfragen. Das Eziwan-Gateway und Ihr SCADA-System können konfliktfrei nebeneinander betrieben werden, sofern eine angemessene Abfragefrequenz (≥ 1 s) konfiguriert wird.

Kann ich analoge Eingangsmodule (BMX AMI 0410) überwachen? Ja. Die Analogmodule sind in den Tabellen %IW (Eingänge) und %QW (Ausgänge) aufgeführt. Informationen zur Registerzuordnung Ihrer spezifischen Module finden Sie in der Unity Pro-Dokumentation.

Funktioniert das Gateway auch, wenn die 4G-Verbindung unterbrochen ist? Ja. Das Eziwan-Gateway verfügt über einen SD-Karten-Puffer: Die Daten werden weiterhin lokal erfasst und nach Wiederherstellung der Verbindung gebündelt übertragen (Store-and-Forward). Lokale Benachrichtigungen (direkte SMS) funktionieren auch ohne Cloud weiterhin.

Ist das Gerät mit der Zelio Logic-Reihe kompatibel? Das Zelio Logic Smart Relay unterstützt Modbus RTU in eingeschränkter Form. Je nach Modell (SR2/SR3) kann der Zugriff auf interne Register eingeschränkt sein. Bitte kontaktieren Sie uns, um die Kompatibilität Ihres konkreten Modells zu überprüfen.

Starten Sie Ihren POC​

Sie haben ein M340-, M221- oder M580-Gerät vor Ort und möchten die Cloud-Verbindung überprüfen?

Eziwan bietet einen kostenlosen 30-tägigen POC an, der Folgendes umfasst:

• 1 vorkonfiguriertes Gateway, das innerhalb von 48 Stunden versandt wird
• Einweisung durch unser Technikteam
• Nach Ihren Vorgaben konfigurierte Dashboards
• Unverbindlich, ohne Kreditkartendaten

Kostenlosen POC starten → | Ihren ROI berechnen →

Weiterführende Informationen​

• Blog: Eine Siemens S7-SPS mit der Cloud verbinden – Technischer Leitfaden
• Blog: Sicherer Fernzugriff auf SPS und SCADA – VPN und NIS2
• Blog: Modbus TCP vs. RTU – welches Protokoll soll man wählen?
• Dokumente: Kompatibilität Siemens S7-1200/S7-1500
• Blog: Vorausschauende Instandhaltung mit IIoT – vom Sensordatenwert bis zur Warnmeldung

Verwenden Sie andere Produktreihen von Schneider Electric (Altivar, Easergy, PowerLogic)? Kontaktieren Sie uns, um die Kompatibilität mit Ihrer spezifischen Anlage zu überprüfen.

Weitere Ressourcen​

• Fernzugriff auf Schneider-SPS – sicherer Fernzugriff auf die Schneider-SPS-Modelle M340, M221 und M580
• SPS mit der Cloud verbinden – jede beliebige industrielle SPS mit der Cloud verbinden
• Modbus TCP in die Cloud – Überwachung über Modbus TCP aus der Cloud
• Industrieller Fernzugriff – VPN- und Zero-Trust-Architektur für Industriestandorte
• Industrielle Überwachung und Fernwartung – zentralisierte Überwachung Ihrer Schneider-SPSen

Dieser Leitfaden vergleicht die vier wichtigsten Funktechnologien, die im industriellen IoT in Frankreich zum Einsatz kommen, und enthält konkrete Empfehlungen für verschiedene Anwendungsfälle.

Überblick: 4 Technologien für 4 unterschiedliche Anforderungen​

Bevor wir ins Detail gehen, hier das Wesentliche in einem Satz pro Technologie:

• LoRaWAN: für batteriebetriebene Sensoren mit geringem Stromverbrauch im Freien über große Entfernungen (1 bis 15 km)
• Zigbee: für dichte Sensornetzwerke in Innenräumen mit Mesh-Struktur über kurze Entfernungen (10 bis 100 m)
• 4G LTE: für abgelegene Standorte, kritische Anlagen, Fern-WAN-Verbindungen, Breitband
• Wi-Fi: für Standorte mit bestehender Netzwerkinfrastruktur, mobile Geräte in abgedeckten Bereichen, lokales Breitband

Detaillierter technischer Vergleich​

LoRaWAN im Detail​

Wann sollte man es verwenden?​

LoRaWAN eignet sich ideal für Anwendungsfälle, bei denen sehr große Reichweiten und ein sehr geringer Stromverbrauch erforderlich sind, die Datenübertragungsrate jedoch gering ist (einige Bytes pro Nachricht im Minutentakt bis stündlichen Intervallen).

Ideale industrielle Anwendungsfälle für LoRa:

• Ablesen von Wasser-, Gas- und Stromzählern in städtischen und vorstädtischen Gebieten
• Überwachung von Umgebungsbedingungen auf großen Flächen (Temperatur, Luftfeuchtigkeit, CO₂ in mehreren Gebäuden)
• Bestandsverfolgung mit langlebigen GPS-/Bewegungssensoren (Paletten, mobile Tanks)
• Überwachung von Sensoren in schwer zugänglichen Bereichen (Kanalisation, unterirdische Infrastruktur, ländliche Gebiete)
• Erkennung des Öffnens/Schließens (Luken, Silotore) über große Gebiete hinweg

Vorteile von LoRaWAN:

• Außergewöhnlich lange Batterielaufzeit (5 bis 10 Jahre mit einer AA-Batterie)
• Sehr einfache Infrastruktur: Ein LoRa-Konzentrator deckt in ländlichen Gebieten einen Umkreis von 5 bis 15 km ab
• Öffentliche Netzwerke in Frankreich verfügbar (Bouygues Telecom LoRa, Objenious, Sewan, CityMesh)
• Sehr geringe Kosten pro Knoten (10 bis 50 € für einen einfachen Sensor)

Einschränkungen von LoRaWAN:

• Sehr geringe Übertragungsrate: Es können keine Bilder, Videostreams oder mehr als einige Bytes pro Nachricht gesendet werden
• Hohe Latenz: Der Downlink (Cloud → Sensor) kann 5 bis 10 Sekunden dauern – daher nicht für die Echtzeitsteuerung geeignet
• Regulatorische Einschränkungen: Das 868-MHz-Band ist auf einen Tastgrad von 1 % begrenzt (ca. 36 Sekunden Sendezeit pro Stunde) – dies schränkt die Sendehäufigkeit ein
• In dichten Innenräumen (dicker Beton, Keller) sinkt die Reichweite auf einige Dutzend Meter

Typische industrielle LoRa-Architektur:

Zigbee im Detail​

Wann sollte man es verwenden?​

Zigbee eignet sich ideal für dichte Sensornetzwerke in Innenräumen mit kurzer Reichweite, insbesondere in Gebäuden (Smart Building) und Fabriken, wo die Entfernungen gering, die Anzahl der Knoten jedoch hoch ist.

Ideale industrielle Anwendungsfälle für Zigbee:

• Gebäudetechnik (GT): Beleuchtung, Jalousien, HLK
• Überwachung der Umgebungsbedingungen in dicht bebauten Bereichen (Lagerhallen, Reinräume)
• Netzwerk aus Präsenzmeldern, Türöffnern und Energiezählern nach Bereichen
• Leichte industrielle Automatisierung als Ersatz für kabelgebundene Systeme in Dienstleistungsgebäuden

Vorteile von Zigbee:

• Mesh-Architektur: Zigbee-Knoten leiten die Daten von entfernten Knoten weiter und beseitigen so Funklöcher
• Geringer Batterieverbrauch (1 bis 5 Jahre)
• Umfangreiches Ökosystem standardisierter und interoperabler Sensoren (Matter-Standard seit 2022)
• Ausreichende Übertragungsrate für Echtzeitmessungen (Alarme, Zustände)
• Sehr hohe Knotendichte (Tausende in einem Netzwerk)

Einschränkungen von Zigbee:

• Begrenzte Reichweite: 10 bis 100 m pro Sprung (wird durch das Mesh-Netzwerk ausgeglichen, erfordert jedoch eine ausreichende Anzahl von Zwischenknoten)
• Koordinator erforderlich: Jedes Zigbee-Netzwerk benötigt einen Koordinator (Zigbee-Hub oder -Gateway)
• 2,4 GHz = Interferenzen mit WLAN, Bluetooth und Mikrowellenherden in dichten industriellen Umgebungen
• Nicht geeignet für Fernverbindungen zwischen weit voneinander entfernten Gebäuden

4G LTE im Detail​

Wann sollte man es verwenden?​

4G LTE ist die Technologie der Wahl für Fern-WAN-Verbindungen, abgelegene Standorte ohne Netzwerkinfrastruktur und Anwendungen, die eine ausreichende Übertragungsrate für die Fernüberwachung und den Fernzugriff erfordern.

Ideale industrielle Anwendungsfälle für 4G:

• Abgelegene Standorte (Pumpstationen, Hütten, Antennen, Wettersensoren) ohne kabelgebundene Verbindung
• Notfallverbindung für kritische Industriestandorte (Failover von Glasfaser auf 4G)
• IoT-Gateways, die Felddaten in die Cloud übertragen (Modbus-Überwachung, OPC-UA)
• VPN-Fernzugriff für die Fernwartung von Industrieanlagen
• Fahrzeuge und mobile Geräte (Kühlwagen, Baumaschinen)
• Schnelle Implementierungen, bei denen die Verlegung eines Netzwerkkabels unmöglich oder zu kostspielig ist

Vorteile von 4G LTE für den industriellen Einsatz:

• Landesweite Abdeckung: 99,2 % der französischen Gemeinden (einschließlich abgelegener ländlicher und Industriegebiete)
• Ausreichende Übertragungsrate: 5 bis 50 Mbit/s reichen für die Überwachung und Fernwartung völlig aus
• Keine lokale Infrastruktur: keine Verkabelung, kein Switch, kein AP, der gewartet werden muss
• Dual-SIM: Automatischer Wechsel zwischen Netzbetreibern zur Maximierung der Verfügbarkeit
• Plug-and-Play: Ein industrielles 4G-Gateway ist in weniger als einer Stunde betriebsbereit

Einschränkungen von 4G LTE:

• Höhere Kosten pro Knoten: Ein industrielles 4G-Gateway kostet 300 bis 600 €, ein SIM-Vertrag 10 bis 20 € pro Monat
• Stromverbrauch: erfordert Netzstrom (nicht geeignet für batteriebetriebene Sensoren)
• Latenz: 30 bis 100 ms (akzeptabel für die Überwachung, nicht für anspruchsvolle Echtzeitsteuerung)
• Funklöcher: einige sehr abgelegene ländliche Gebiete ohne Netzabdeckung (kann mit einer externen Antenne oder über Satellit umgangen werden)
• Abhängigkeit vom Netzbetreiber: Die Verfügbarkeit hängt vom Mobilfunknetz ab (akzeptabel mit Dual-SIM)

WLAN im Detail​

Wann sollte man es verwenden?​

WLAN eignet sich für Standorte mit bestehender Netzwerkinfrastruktur, für Geräte, die eine hohe Bandbreite benötigen, sowie für Bereiche, die vollständig von Zugangspunkten abgedeckt sind.

Ideale industrielle Anwendungsfälle für WLAN:

• Anbindung von Sensoren oder Industrieanlagen in einer Fabrik, die bereits über WLAN abgedeckt ist
• Fahrzeuge oder mobile Geräte vor Ort (Gabelstapler, fahrerlose Transportfahrzeuge) in einem abgedeckten Bereich
• IP-Überwachungskameras (erfordern hohe WLAN-Bandbreite)
• Lokales SCADA-System im Echtzeit-Überwachungsmodus (Latenz < 10 ms)

Vorteile von industriellem WLAN:

• Sehr hohe Übertragungsrate (geeignet für Video-Streaming und schnelle Firmware-Updates)
• Infrastruktur in modernen Fabriken oft bereits vorhanden
• Sehr geringe Latenz (1 bis 10 ms) – für moderate Echtzeitanwendungen geeignet
• Zahlreiche Industriegeräte mit integriertem WLAN (HMIs, kollaborative Roboter)

Einschränkungen von industriellem WLAN:

• Begrenzte Reichweite: 30 bis 150 m pro Access Point (AP); zur Abdeckung großer Flächen ist ein Mesh-Netzwerk erforderlich
• Interferenzen: Das 2,4-GHz-Band ist in dichten industriellen Umgebungen überlastet (Motoren, Funkfrequenzen, CNC-Maschinen)
• Hoher Stromverbrauch: nicht für batteriebetriebene Sensoren geeignet
• Kostspielige Infrastruktur: industrielle Access Points (Cisco, Aruba, Extreme Networks) = 500 bis 3.000 € pro AP
• Komplexe Netzwerkverwaltung: Roaming für mobile Geräte erfordert WLAN-Fachwissen

Entscheidungshilfe: Wie trifft man die richtige Wahl?​

Entscheidungsbaum​

Empfehlungstabelle nach Branchen​

Hybridarchitektur: Das Beste aus beiden Welten​

In der Praxis kommen bei ausgereiften industriellen IoT-Implementierungen mehrere Technologien in Kombination zum Einsatz, die je nach Art der jeweiligen Geräte ausgewählt werden.

Beispiel für eine Hybridarchitektur: 10 Hektar großes Industriegelände

Das Eziwan-Gateway fungiert als Multiprotokoll-Hub: Es kommuniziert über Modbus im lokalen OT-Netzwerk, ist mit LoRa- und Zigbee-Hubs für drahtlose Sensoren kompatibel und überträgt alle Daten über 4G LTE in die Cloud. Ein einziger Vertrag, ein einziges Dashboard.

Kostenvergleich über 5 Jahre (Installation von 100 Sensoren)​

Hinweis: 4G LTE ist pro Knoten deutlich teurer, bietet jedoch eine Fern-WAN-Konnektivität, die LoRa und Zigbee nicht bieten können. Der Vergleich gilt nur für Sensoren zur Datenerfassung, nicht für industrielle Gateways, die die Internetverbindung gewährleisten müssen.

Fazit​

Es gibt keine universell „beste“ IoT-Technologie. Die Wahl hängt von drei grundlegenden Kriterien ab:

1. Reichweite: kurz (Zigbee), mittel bis lang (LoRaWAN), sehr lang oder WAN (4G LTE)
2. Stromverbrauch: lange Batterielaufzeit (LoRaWAN > Zigbee > WLAN), Netzbetrieb (alle)
3. Die Übertragungsrate: Sensordaten (LoRaWAN, Zigbee reichen aus), Überwachung und Fernzugriff (4G LTE, WLAN erforderlich)

Die Eziwan-Lösung ist für 4G LTE als industrielle WAN-Verbindungstechnologie optimiert, da diese am besten für Gateways geeignet ist, die lokale OT-Netzwerke (Modbus, OPC-UA) mit der Überwachungs-Cloud verbinden sollen. Sie kann durch LoRaWAN- oder Zigbee-Konzentratoren für Sensoren mit geringem Stromverbrauch ergänzt werden.

Benötigen Sie Hilfe bei der Auswahl der richtigen Architektur für Ihr Projekt? Kontaktieren Sie unser Ingenieurteam für eine kostenlose Analyse Ihrer Situation.

FAQ​

Kann man LoRaWAN und 4G LTE am selben Standort kombinieren? Ja – das wird sogar empfohlen. Die batteriebetriebenen LoRaWAN-Sensoren (Wasserzähler, Umweltsensoren, Füllstandssensoren) übertragen ihre Daten über einen LoRa-Konzentrator. Das Eziwan 4G-LTE-Gateway bündelt die Daten der lokalen LoRa-Sensoren und der Modbus-Geräte und sendet sie an die Cloud. 4G wird nur für die WAN-Verbindung genutzt, nicht für jeden einzelnen Sensor.

Ist LoRaWAN für die Überwachung kritischer industrieller Anwendungen zuverlässig? LoRaWAN eignet sich für die Überwachung nicht kritischer Anwendungen (Zählerablesungen, Umweltdaten, Anwesenheitserkennung). Für kritische Überwachungsaufgaben (Pumpenalarme, Prozesswerte) ist 4G LTE aufgrund seiner geringen Latenz und seiner Zuverlässigkeit vorzuziehen. Oft werden beide Protokolle parallel eingesetzt: LoRaWAN für Hilfssensoren, 4G für kritische Steuerungen und Bedienoberflächen.

Was ist der Unterschied zwischen LoRa und LoRaWAN? LoRa ist die Funktechnologie (CSS-Modulation von Semtech). LoRaWAN ist das auf LoRa basierende Netzwerkprotokoll: Es definiert die Netzwerkarchitektur (Knoten → Konzentratoren → Network Server → Application Server), die Adressverwaltung, die Sicherheit (AES-128) sowie die Geräteklassen (A, B, C). LoRa ohne LoRaWAN kann im proprietären Punkt-zu-Punkt-Modus betrieben werden – mit geringerer Interoperabilität.

Kann Zigbee in einer industriellen Umgebung mit elektromagnetischen Störungen eingesetzt werden? Zigbee (2,4 GHz) ist anfällig für industrielle Funkstörungen (Motoren, Frequenzumrichter, Schweißgeräte). In stark gestörten Umgebungen sollten Sie Zigbee-Kanäle auf 915 MHz (verfügbar in der Sub-GHz-Version) bevorzugen oder für besonders kritische Geräte eine kabelgebundene Verbindung (RS-485 Modbus) verwenden. Das Zigbee-Mesh-Netzwerk verbessert die Ausfallsicherheit, beseitigt jedoch nicht die physikalischen Einschränkungen.

Ist industrielles WLAN für eine sich bewegende Maschine (AGV, Förderband) geeignet? Für AGVs (automatisch geführte Fahrzeuge) und Förderbänder wird WLAN mit 802.11r-Roaming (Fast Transition) verwendet. Ein Netzwerk aus Access Points, das die gesamte Strecke abdeckt, ermöglicht einen schnellen Handover (<50 ms) zwischen den APs. Die Bereitstellung ist komplexer und kostspieliger als bei einem fest installierten Netzwerk, stellt jedoch die Standardlösung für sich bewegende Maschinen in Innenräumen dar.

Weiterführende Informationen​

• Blog: OPC-UA, MQTT, Modbus – Auswahl des richtigen industriellen Gateways
• Blog: Modbus, MQTT, OPC-UA – Umfassender Vergleich der Industrieprotokolle
• Blog: SIM-Karten für M2M und IoT – Vergleich der französischen Anbieter 2026
• Blog: Auswahl eines industriellen IoT-Gateways – 9 Kriterien
• Blog: Industrielle Fernüberwachung – umfassender Leitfaden 2026

Eziwan ist Experte für industrielle 4G-LTE-IoT-Konnektivität. Unser Multiprotokoll-Gateway (Modbus, OPC-UA, MQTT, LoRaWAN, Zigbee) lässt sich an Ihre bestehende Architektur anpassen. Entdecken Sie das Eziwan-Gateway →

Weitere Ressourcen​

• Industrielle Konnektivität – Multi-Protokoll-Konnektivitätslösungen für das industrielle IoT
• Industrieprotokolle – Leitfaden zu industriellen Kommunikationsprotokollen (Modbus, OPC-UA, MQTT…)
• Industrielles IoT-Gateway – Multi-Protokoll-Gateways (funkbasiert und kabelgebunden) für das IIoT
• Internetverbindung für abgelegene Industriestandorte – Auswahl des richtigen Funkprotokolls für Standorte ohne kabelgebundene Netzabdeckung
• Eziwan-Lösungen für die Industrie – umfassendes Angebot an industriellen Konnektivitäts- und Überwachungslösungen

Für einen Hersteller von Industriemaschinen (OEM) ist die Integration der Fernwartung nicht nur ein Verkaufsargument. Es handelt sich um eine Umgestaltung des Geschäftsmodells. Dieser Artikel vermittelt Ihnen die technischen, wirtschaftlichen und vertraglichen Grundlagen, um diese Umgestaltung erfolgreich umzusetzen.

1. Fernwartung als Differenzierungsmerkmal​

Die Entwicklung der Kundenerwartungen​

Vor zehn Jahren war das Angebot von Fernwartung noch ein Wettbewerbsvorteil. Heute ist es in vielen Branchen eine Voraussetzung für den Zugang zu bestimmten Märkten.

Lebensmittel- und Getränkeindustrie: Moderne Produktionslinien laufen 20 Stunden pro Tag, 6 Tage pro Woche. Ein ungeplanter Stillstand kostet je nach Kapazität zwischen 5.000 und 50.000 € pro Stunde. Die Auftraggeber verlangen eine Wiederaufnahme des Betriebs innerhalb von 2 bis 4 Stunden, was ohne Ferndiagnose unmöglich einzuhalten ist.

Apotheken und Kosmetik: Die Anlagen unterliegen einem Qualifizierungsverfahren (IQ/OQ/PQ). Jede Änderung oder jeder Eingriff muss dokumentiert werden. Die Fernwartung mit lückenloser Rückverfolgbarkeit der Sitzungen entspricht genau dieser Anforderung.

Automobil- und Maschinenbauindustrie: Großkunden beziehen die Vernetzung von Anlagen in ihre Auswahlkriterien für Ausschreibungen ein. Nicht vernetzte Anlagen werden in manchen Leistungsbeschreibungen von vornherein ausgeschlossen.

Erneuerbare Energien: Windkraftanlagen, Solarkraftwerke, industrielle Wärmepumpen – die auf Betriebsdaten basierende vorbeugende Instandhaltung ist ein entscheidender Faktor für die Wettbewerbsfähigkeit.

Was Ihre Konkurrenten bereits tun​

Hersteller, die die Fernwartung in ihr Angebot integriert haben, berichten von erheblichen geschäftlichen Auswirkungen:

• Verlängerungsquote bei Wartungsverträgen: deutlich höher – Kunden, die von der Echtzeit-Überwachung profitieren, verlängern ihre Verträge fast ausnahmslos
• Maschinenverkaufspreis: rechtfertigt einen Aufschlag von 3 bis 8 % auf den Maschinenpreis, der sich durch die Einsparungen bei den Wartungskosten in weniger als einem Jahr amortisiert
• Kundenbindung: Die Vernetzung sorgt für einen regelmäßigen Kontakt zwischen Hersteller und Kunde, was den Wiederkauf oder die Erweiterung des Maschinenparks begünstigt

2. Technische Architektur: Gerät → Gateway → Cloud​

Das Gateway als Bestandteil der Maschine​

Am effektivsten ist es, das Eziwan-Gateway als Standardkomponente der Maschine zu integrieren, genau wie den Frequenzumrichter oder das HMI-Gerät. Es ist in der Stückliste, im Schaltplan und in der Bedienungsanleitung aufgeführt.

Diese Integration bereits in der Planungsphase vermeidet nachträgliche Integrationsprobleme (Anpassung der Verkabelung, Rechtfertigung der Kosten gegenüber dem Käufer) und ermöglicht es, die Fernwartung nahtlos als eine Funktion der Maschine anzubieten.

Vollständiges Architekturdiagramm​

┌──────────────────────────────────────────────────────────────────┐
│  Machine industrielle (OEM)                                      │
│                                                                  │
│  [Capteurs et actionneurs]                                       │
│  ├── Températures, pressions, débits                             │
│  ├── Moteurs, variateurs, servomoteurs                           │
│  └── Codeurs, capteurs de position                               │
│                     ↓ Analogique / TOR                          │
│  [Automate / Motion controller]                                  │
│  ├── Programme de production (protégé Know-How)                  │
│  ├── Variables de process (accessibles supervision)              │
│  ├── Compteurs et historique local                               │
│  └── Codes défaut et diagnostics                                 │
│                     ↓ Modbus TCP ou RS-485                      │
│  [Gateway Eziwan] ← Intégrée en standard dans l'armoire         │
│  ├── Collecte Modbus (poll 1-60s configurable)                   │
│  ├── Bufferisation locale (perte 4G jusqu'à 48h)                 │
│  ├── 4G LTE Dual SIM (SIM multi-opérateurs incluse)             │
│  └── Tunnel OpenVPN sortant → zéro port entrant               │
└──────────────────────────────────────────────────────────────────┘
              │ Tunnel OpenVPN chiffré
              ▼
     [Cloud Eziwan]
          ↙              ↘
  [Espace OEM]       [Espace client]
  - Toutes variables  - Variables autorisées
  - Firmware update   - Supervision process
  - Diagnostics       - Alertes et historique
  - Accès toutes machines  - Ses machines seulement

Trennung der Zugriffsschnittstellen​

Die Trennung zwischen dem OEM-Bereich und dem Kundenbereich ist einer der wichtigsten Aspekte der Architektur. Sie erfüllt zwei gegensätzliche Anforderungen:

• Der OEM benötigt für Diagnose und Wartung uneingeschränkten Zugriff auf die Maschine
• Der Kunde benötigt Einblick in seine Produktion, ohne dass das Know-how des Herstellers offengelegt wird

Geschützte Variablen (nur OEM): Kalibrierungsparameter, Herstellungsrezepte, PID-Regelparameter, interne Schutzschwellenwerte.

Gemeinsam genutzte Variablen (für den Kunden sichtbar): Prozesstemperaturen, Drücke, Durchflussmengen, Maschinenzustände, Produktionszähler, allgemeine Fehlercodes.

3. Sicherheit: Schutz des Kunden und Schutz Ihres Know-hows​

Vertrauen als Verkaufsargument​

Ihre Kunden stellen immer wieder dieselbe Frage: „Wenn Sie per Fernzugriff auf meinen Rechner zugreifen können, wie kann ich dann sicher sein, dass Sie meine vertraulichen Produktionsdaten nicht einsehen können?“

Und manchmal stellen sie auch die umgekehrte Frage: „Wenn ein Hacker Ihren Herstellerzugang kompromittiert, kann er dann auf meinen Rechner zugreifen?“

Die technische Lösung für diese beiden Fragen ist die kryptografische Abschottung.

Kryptografische Isolierung​

Unabhängigkeit der Zugriffsbereiche: Der OEM-Bereich und der Kundenbereich verwenden völlig unterschiedliche Anmeldedaten, die in keiner Verbindung zueinander stehen. Die Kompromittierung von Kunden-Anmeldedaten ermöglicht keinen Zugriff auf den OEM-Bereich und umgekehrt.

Genaue Auswahl der sichtbaren Variablen: In der Konfiguration des Gateways wird explizit festgelegt, welche Variablen für welche Zugriffsebene sichtbar sind:

variables:
  - nom: "Temperature_Etuve"
    modbus_addr: 100
    access_oem: read_write    # OEM peut lire et modifier
    access_client: read       # Client peut lire

  - nom: "PID_Kp_Etuve"
    modbus_addr: 200
    access_oem: read_write
    access_client: hidden     # Client ne voit pas ce paramètre

  - nom: "Compteur_Cycles"
    modbus_addr: 300
    access_oem: read
    access_client: read       # Les deux peuvent lire les compteurs

Nachverfolgbarkeit der OEM-Zugriffe beim Kunden: Der Kunde kann in seinem Dashboard einsehen, wann sich die OEM-Techniker bei seiner Maschine angemeldet haben, wie lange sie dort waren und welche Variablen sie überprüft haben. Diese Transparenz stärkt das Vertrauen.

Schutz Ihres SPS-Programms​

Unabhängig vom Gateway wird empfohlen, die integrierten Schutzfunktionen der Steuerung zu aktivieren:

Siemens S7-1500:

• „Know-How“-Schutz: Verschlüsselung des Programms, verhindert das Auslesen selbst über das TIA Portal
• „Copy“-Schutz: Verknüpfung des Programms mit der Seriennummer der CPU (keine Kopie auf eine andere CPU)
• Zugriffsschutz Stufe 4 (Vollschutz): Jede Änderung erfordert die Eingabe eines Passworts

Schneider M340:

• Passwortgeschützter Zugriff in EcoStruxure
• Verschlüsselte Programmsicherung

4. Betriebsdaten: eine wahre Fundgrube für die Konstruktionsabteilung​

Daten, die nur der Hersteller auswerten kann​

Wenn Ihre Maschine bei 100 Kunden im Einsatz ist, haben Sie Zugang zu etwas Einzigartigem: zu realen Betriebsdaten unter unterschiedlichen Bedingungen über einen langen Zeitraum hinweg. Das ist ein Schatz, für dessen Erfassung die Forschungs- und Entwicklungsabteilungen großer Unternehmen Millionen ausgeben.

Tatsächliche Lebensdauer der Komponenten: Nach wie vielen Betriebsstunden fällt das Kugellager der Y-Achse Ihrer Maschine statistisch gesehen aus? Die Daten Ihres Maschinenparks mit 100 Maschinen geben genau Aufschluss über diese Frage. Was Sie für eine MTBF von 8.000 Stunden gehalten haben, beträgt in der tatsächlichen Produktion vielleicht nur 6.500 Stunden – oder 12.000 Stunden, wenn die Bediener die Schmiervorschriften genau befolgen.

Zusammenhang zwischen Parametern und Störungen: Welche Kombination aus Umgebungstemperatur, Motorlast und Zyklusdauer geht einem Ausfall des Temperaturreglers voraus? Diese Zusammenhänge ermöglichen es, die Algorithmen für die vorbeugende Wartung bei den nächsten Generationen zu verbessern.

Tatsächliche Nutzung vs. vorgesehene Nutzung: Wird Ihre Maschine gemäß den Spezifikationen eingesetzt? Manche Kunden beanspruchen die Maschine über ihre Nennwerte hinaus. Andere nutzen sie weit unterhalb dieser Werte. Diese Informationen fließen in Konstruktionsentscheidungen ein (Überdimensionierung einer Komponente, die systematisch zu 95 % ausgelastet ist).

Segmentierung des Maschinenparks: Bei einigen Kunden liegen die Ausfallraten um das Dreifache über dem Durchschnitt. Warum? Die Analyse der Betriebsdaten kann Zusammenhänge mit den Umgebungsbedingungen (Temperatur, Luftfeuchtigkeit, Vibrationen) oder mit den Arbeitsabläufen des Bedienpersonals aufzeigen.

5. Wiederkehrendes SaaS-Geschäftsmodell​

Von der einmaligen Transaktion zum Abonnement​

Die Fernwartung schafft die Voraussetzungen für ein Jahresabonnement für vernetzte Wartung. Dieses Modell verändert die Geschäftsbeziehung:

Traditionelles Geschäftsmodell:

• Maschinenverkauf: einmalige Einnahme
• Wartungsvertrag: jährliche Neuverhandlung, oft unter Preisdruck
• Ersatzteile: opportunistische Einnahme

Vernetztes Modell:

• Maschinenverkauf: einmaliger Erlös (unverändert oder sogar Premium)
• Konnektivitätsabonnement: wiederkehrende Einnahmen, automatische Verlängerung
• Erweiterter Wartungsvertrag: einhaltbare SLAs dank Ferndiagnose, Premium-Preis
• Flottendaten: Wert für F&E (nicht direkt monetarisierbar, aber starker indirekter ROI)

Typische Tarifstruktur​

──────────────────────────────────────────────────────────────────
OFFRE STANDARD — Supervision opérationnelle
  • Tableau de bord client en temps réel
  • Alertes SMS/email sur défauts machine
  • Historique 1 an
  • 2 utilisateurs client inclus
──────────────────────────────────────────────────────────────────
OFFRE MAINTENANCE CONNECTÉE
  • Tout le Standard +
  • Accès technicien OEM à distance (illimité)
  • SLA : diagnostic à distance sous 4h ouvrées
  • Mise à jour firmware automate à distance
  • Historique 3 ans
  • 5 utilisateurs client inclus
──────────────────────────────────────────────────────────────────
OFFRE PERFORMANCE GARANTIE
  • Tout le Maintenance Connectée +
  • Rapport mensuel de performance machine
  • Analyse prédictive (détection dérive)
  • Engagement disponibilité machine
  • Accès API données pour intégration client
──────────────────────────────────────────────────────────────────

ROI-Berechnung für den OEM​

Für einen OEM mit 150 installierten Maschinen und bei einer geschätzten Anzahl von 1,8 Korrektureinsätzen pro Maschine und Jahr:

Unverbindliche Annahmen. Der tatsächliche ROI hängt vom Standort des Parks, der Art der Störungen und der internen Organisation ab.

6. Integration in den Produktlebenszyklus​

Empfehlungen zur Hardware-Integration​

Spezielle Stromversorgung: Leiten Sie 24 V DC von einer Dauerstromversorgung ab (vor dem Hauptschalter der Maschine). Das Gateway muss auch bei ausgeschalteter Hauptmaschine zugänglich bleiben – gerade in solchen Momenten ist eine Ferndiagnose am nützlichsten.

SPS-Netzwerk: Schließen Sie das Gateway an einen dedizierten Ethernet-Anschluss an (wenn möglich getrennt vom HMI-Anschluss). Bei Steuerungen mit nur einem Anschluss (S7-1200 CPU 1211C, M221...) verwenden Sie einen verwaltbaren Industrie-Switch, um die Datenflüsse zwischen HMI, Gateway und Engineering voneinander zu trennen.

4G-Antenne: Bei Stahlschränken sollte grundsätzlich eine Kabeldurchführung für eine externe Antenne vorgesehen werden. In Innenräumen mit geschlossenem Schrank ist das Signal oft unzureichend. Ein 3 m langes LMR-200-Kabel mit einer Richtantenne außerhalb des Schranks reicht in den allermeisten Fällen aus.

Dokumentation für Maschinenbeschreibungen​

Eziwan stellt OEM-Partnern die folgenden Unterlagen zur Verfügung, die in Ihre Maschinenhandbücher integriert werden können:

• Zertifizierter Schaltplan (im DXF- und PDF-Format)
• Anleitung zum Aktivieren und Deaktivieren der Fernwartung (für den Kundenbetreiber)
• Datenschutzerklärung für Telemetriedaten (DSGVO-konform)
• Anleitung zum Austausch des Gateways (Garantie, Ende der Lebensdauer)

FAQ – Fernwartung für OEM-Hersteller​

Kann der Kunde das Fernwartungs-Gateway auf seinem Rechner deaktivieren?

Technisch gesehen ja – der Kunde kann das Gateway physisch vom Netz trennen. Vertraglich hängt die Antwort vom Wartungsvertrag ab: OEMs, die SLAs mit einer Reaktionszeit von unter 4 Stunden anbieten, können diese SLA an die ständige Aktivierung der Fernwartung knüpfen. In der Praxis deaktivieren Kunden das Gateway selten, da sie über dieses auch Zugriff auf die Überwachung ihrer Produktion haben.

Wie lässt sich das SPS-Programm (OEM-Know-how) schützen und gleichzeitig die Überwachung durch den Kunden ermöglichen?

Zwei sich ergänzende Schutzstufen: (1) Auf SPS-Ebene den Know-how-Schutz (S7-1500) oder den Passwortschutz (M340) aktivieren, um das Auslesen des Programms auch über das TIA-Portal zu verhindern. (2) Auf Eziwan-Ebene die Variablen für vertrauliche Parameter als access_client: hidden konfigurieren. Der Kunde sieht nur die Prozessvariablen, nicht die Einstellparameter.

Wie viele Maschinen lassen sich über ein einziges Eziwan-OEM-Konto verwalten?

Es gibt keine feste Obergrenze – OEM-Konten sind auf industrielle Maschinenflotten ausgelegt (von Dutzenden bis zu Tausenden von Maschinen). Über das OEM-Dashboard können Sie nach Kunde, Maschinenmodell und Status (Warnung, normal, offline) filtern und die Leistung von Maschinen desselben Modells miteinander vergleichen.

Wie wird den Kunden das Fernwartungsabonnement im Falle eines Eziwan-Weiterverkaufs in Rechnung gestellt?

Eziwan bietet ein OEM-Partnerprogramm mit Großhandelspreisen an. Der OEM integriert die Konnektivität in sein eigenes Wartungsabonnement und legt dabei die gewünschte Marge fest. Der Endkunde hat keine Kenntnis von der Beziehung zu Eziwan – er schließt bei dem OEM ein „Wartungsabonnement mit Konnektivität“ ab.

Was passiert nach Ablauf des Wartungsvertrags: Wird der OEM-Zugang gesperrt?

Ja, sofern der Vertrag diese Klausel vorsieht. Über das OEM-Dashboard können die Zugriffsrechte auf das Konto eines Kunden sofort deaktiviert (bei Vertragsende oder im Streitfall) oder auf einen anderen Dienstleister übertragen werden. Die historischen Daten des Kunden verbleiben in seinem Konto und gehören ihm – sie gehen nicht verloren.

Die Fernüberwachung ist für diese Anlagen kein Luxus mehr, sondern eine betriebliche Notwendigkeit und in bestimmten regulierten Bereichen (Trinkwasser, Abwasserentsorgung) eine gesetzliche Vorgabe.

1. Spezifische Herausforderungen bei Pumpstationen​

Der tatsächliche operative Kontext​

Ein Betreiber von Pumpstationen an mehreren Standorten verwaltet in der Regel zwischen 20 und 200 Standorte, wobei ein Team aus einigen Wartungstechnikern ein Gebiet von mehreren hundert Quadratkilometern abdeckt. Die Pumpstationen sind häufig:

• Geografisch abgelegen: ländliche Gebiete, Flussufer, unbebaute Grundstücke, bei schlechtem Wetter manchmal schwer erreichbar
• Unbewacht: kein festes Personal vor Ort, planmäßige Besichtigungen 1 bis 4 Mal pro Monat
• Kritisch für den Betrieb: Eine ausgefallene Hebeanlage kann innerhalb weniger Stunden zu einem Überlaufen des Netzes oder zu einer Unterbrechung der Trinkwasserversorgung führen
• Regulatorischen Auflagen unterworfen: Die Wasser- und Abwasserbetreiber unterliegen dem Umweltgesetzbuch sowie den Verordnungen der Präfektur und müssen Betriebsberichte vorlegen

Ohne Fernüberwachung erfolgt der Betrieb reaktiv: Ein Anruf eines Nutzers, ein lokaler Alarm (Sirene, rote Warnleuchte) oder ein regelmäßiger Kontrollgang signalisiert das Problem. Die Reaktionszeit beträgt mehrere Stunden, bei besonders abgelegenen Standorten manchmal sogar mehrere Tage.

Die Kosten des reaktiven Vorgehens​

Vergebliche Einsätze: Zwischen 30 und 50 % der Einsätze aufgrund eines Alarms sind „vergebliche Einsätze“ – der Techniker trifft vor Ort ein und stellt fest, dass sich das Problem von selbst gelöst hat (automatischer Neustart der Pumpe, vorübergehender Stromausfall) oder dass das Problem keinen sofortigen Einsatz erfordert. Ein Einsatz kostet zwischen 400 und 700 € (Fahrzeug, Zeitaufwand, Aufwandsentschädigungen).

Unzureichend vorbereitete Einsätze: Ohne Ferndiagnose weiß der Techniker nicht, was ihn erwartet, und kann daher nicht die passenden Ersatzteile mitnehmen. Eine zusätzliche Hin- und Rückfahrt, um ein Teil zu holen, kann die Kosten des Einsatzes verdoppeln.

Späte Erkennung von Störungen: Eine Pumpe, bei der Kavitation (Luftansaugung) auftritt, die trocken läuft oder deren Rotor sich allmählich abnutzt, kann mehrere Tage lang in einem beeinträchtigten Zustand laufen, bevor es zu einem vollständigen Ausfall kommt. In dieser Zeit verkürzt sich die Lebensdauer der Pumpe, und das Risiko eines plötzlichen Ausfalls steigt.

Schwierigkeiten bei der Einhaltung gesetzlicher Vorschriften: Die Erstellung der jährlichen Berichte zur Dienstleistungsqualität (RPQS für Trinkwasser, Jahresbericht des Betreibers für die Abwasserentsorgung) erfordert einen erheblichen manuellen Aufwand für die Datenzusammenführung, wenn die Daten nicht automatisch archiviert werden.

2. Typische Architektur: vom Sensor bis zum Armaturenbrett​

Überblick über die Architektur​

┌──────────────────────────────────────────────────────────────────┐
│  Station de pompage SP-42                                        │
│                                                                  │
│  [Capteurs de mesure]                                           │
│  ├── Niveau bâche : sonde à ultrasons ou pression relative 4-20mA │
│  ├── Débit : débitmètre électromagnétique (impulsions ou 4-20mA) │
│  ├── Courant moteur P1 : transformateur de courant (TA)          │
│  ├── Courant moteur P2 : transformateur de courant               │
│  └── Présence alimentation : contact sec sur TGBT               │
│                     ↓                                           │
│  [Coffret de régulation / Automate]                             │
│  ├── Siemens LOGO! 8 / S7-1200                                  │
│  ├── Schneider M221 / M241                                      │
│  ├── Wago PFC200                                                 │
│  └── Coffret "vrai de vrai" relais + télémesure ancienne        │
│                     ↓ Modbus TCP ou RTU                         │
│  [Gateway Eziwan]  ← Rail DIN, 24V DC                           │
│  └── 4G LTE Dual SIM ──────────────────────────────────────────┤
│                                                                  │
└──────────────────────────────────────────────────────────────────┘
                     │ Tunnel OpenVPN
                     ▼
           [Cloud Eziwan]
           ├── Base time-series (données horodatées)
           ├── Moteur d'alertes
           └── Tableau de bord web + app mobile
                     │
                     ▼
           [Salle de conduite — téléopération]
           [Application mobile — astreinte]
           [Email/SMS — responsable exploitation]

Auswahl des Protokolls je nach Steuerung​

Stationsverwaltung ohne Steuerung​

Bei den zahlreichen kleinen Hebeanlagen, die über keine speicherprogrammierbare Steuerung verfügen – sondern lediglich über einen Startschaltkasten mit Schützen und Relais –, kann das Eziwan-Gateway über ein E/A-Erweiterungsmodul für digitale Ein- und Ausgänge direkt an die Feldsignale angeschlossen werden:

[Contact sec "Pompe 1 en marche"] ──→ [Entrée TOR 1 gateway]
[Contact sec "Défaut thermique"]  ──→ [Entrée TOR 2 gateway]
[Sonde niveau 4-20mA]             ──→ [Entrée analogique gateway]

Mit diesem Ansatz lassen sich bestehende Stationen nachrüsten, ohne dass die Verkabelung geändert oder eine Steuerung installiert werden muss.

3. Wesentliche Überwachungsvariablen​

Standard-Überwachungsplan für eine Pumpstation​

Bei einer Anlage mit zwei Pumpenaggregaten (die gängigste Konfiguration) sind folgende Mindestparameter zu überwachen:

Statusvariablen (Boolesche Werte):

%MW300 bits :
  bit 0 : Pompe 1 en marche
  bit 1 : Pompe 2 en marche
  bit 2 : Défaut thermique pompe 1 (disjoncteur déclenché)
  bit 3 : Défaut thermique pompe 2
  bit 4 : Défaut disjoncteur général
  bit 5 : Alimentation électrique présente
  bit 6 : Niveau haut bâche atteint (pré-alarme)
  bit 7 : Niveau très haut bâche (alarme)
  bit 8 : Niveau bas bâche (risque fonctionnement à sec)
  bit 9 : Mode manuel activé (maintenancier sur place)
  bit 10 : Défaut sonde niveau (valeur hors plage ou absence signal)

Analoge Variablen (16- oder 32-Bit-Register):

%MW100 : Niveau bâche (% × 10 → ex. 752 = 75.2%)
%MW101 : Débit instantané (L/min)
%MW102-103 : Volume journalier pompé (m³ × 1000, int32 sur 2 registres)
%MW104 : Courant moteur pompe 1 (A × 10 → ex. 142 = 14.2 A)
%MW105 : Courant moteur pompe 2 (A × 10)
%MW106 : Nombre de démarrages pompe 1 (compteur)
%MW107 : Nombre de démarrages pompe 2 (compteur)
%MW108-109 : Durée de marche cumulée P1 (minutes, int32)
%MW110-111 : Durée de marche cumulée P2 (minutes, int32)
%MW112 : Tension secteur (V × 10)
%MW113 : Code défaut détaillé (bitfield constructeur)

Warum sollte der Motorstrom überwacht werden?​

Die Überwachung des Motorstroms ist der aussagekräftigste Indikator für die vorbeugende Wartung von Pumpen:

Kavitationserkennung: Eine Pumpe, die Luft ansaugt, weist einen geringeren Strömungswiderstand als normal auf (das Medium ist weniger dicht). Dies ist ein Frühindikator für ein Problem mit dem Füllstand oder der Ansaugung.

Erkennung von Trockenlauf: Der Strom fällt plötzlich unter den Nennstrom im Leerlauf ab. Es besteht die Gefahr, dass die Gleitringdichtung innerhalb weniger Minuten zerstört wird.

Verschleiß des Rotors: Ein verschlissener oder verschmutzter Rotor verbraucht bei gleicher Förderleistung mehr Strom. Eine allmähliche Abweichung des Stromverbrauchs bei konstanter Förderleistung deutet darauf hin, dass eine Wartung erforderlich ist.

Problem mit der Stromversorgung: Ein Phasenunsymmetrie (bei einer Drehstrompumpe) kann auf ein defektes Kabel oder ein Problem im Stromnetz des Standorts hindeuten.

4. Konfiguration von mehrstufigen Warnmeldungen​

Hierarchie der Warnmeldungen​

Ein wirksames Alarmsystem für eine Pumpstation muss abgestuft sein, um eine Alarmmüdigkeit zu vermeiden (zu viele Alarme → die Bediener ignorieren sie), und gleichzeitig sicherstellen, dass kritische Vorfälle sofort gemeldet werden.

Stufe 1 – Information (E-Mail an das Führungsteam):

Démarrage pompe 2 alors que pompe 1 est déjà en marche
  → Information uniquement (situation normale en pointe)

Niveau bâche > 75% alors que les deux pompes sont en marche
  → Vérification débit entrant inhabituellement élevé

Stufe 2 – Voralarm (E-Mail + Benachrichtigung über die mobile App):

Niveau bâche > 85%
  → Situation anormale, surveiller l'évolution

Courant moteur > 110% de la valeur de référence pendant > 2 minutes
  → Surcharge légère, vérifier à la prochaine ronde

Aucune mise en marche des pompes depuis > 24h alors que niveau > 30%
  → Pompes peut-être en défaut silencieux

Stufe 3 – Alarm (SMS + E-Mail + Webhook für den Bereitschaftsdienst):

Niveau bâche > 95%
  → Risque de débordement, intervention urgente

Défaut thermique pompe 1 ET pompe 2 simultanément
  → Station hors service, intervention immédiate

Courant moteur < 40% de la valeur nominale pendant > 30 secondes
  → Fonctionnement à sec probable, arrêt automatique conseillé

Perte d'alimentation électrique
  → Toutes les pompes s'arrêtent, vérifier groupe électrogène si disponible

Perte de connectivité gateway > 15 minutes
  → Impossible de savoir l'état de la station

Konfiguration von Zeitfenstern und Eskalation​

Die Warnmeldungen können mit Zeitfenstern und einer Eskalationslogik konfiguriert werden:

Défaut thermique pompe :
  Heure ouvrée (8h-18h) → SMS technicien de service
  Nuit / week-end       → SMS astreinte + email responsable

Si pas d'acquittement en 30 minutes :
  → Appel téléphonique (webhook vers système de téléphonie)
  → SMS responsable de service

5. Historie, Compliance und aufsichtsrechtliche Berichterstattung​

Der Wert historischer Daten​

Die Datenhistorie einer Pumpstation ist ein wertvolles Betriebsgut, das sich im Laufe der Zeit ansammelt:

Analyse langfristiger Trends: Vergleichen Sie die Motorstromkurven von Pumpe 1 im Januar 2024 und im Januar 2025. Eine Abweichung von +8 % deutet auf einen sich abnutzenden Rotor hin – planen Sie die vorbeugende Wartung vor dem Ausfall während der Winterpause ein.

Zusammenhang zwischen Niederschlag und Zufluss: Bei Abwasserhebestationen ermöglicht der Zusammenhang zwischen Niederschlagsereignissen und dem Zufluss die Dimensionierung der Speicherkapazitäten und die Erkennung von Fremdwassereinbrüchen in das Netz.

Optimierung der Regelparameter: Analyse der Ein- und Ausschaltzyklen: Eine Pumpe, die mehr als 15 Mal pro Stunde anläuft, deutet auf ein Problem bei der Dimensionierung (Pumpe zu leistungsstark, Behälter zu klein) oder bei der Regelung hin.

Gesetzlich vorgeschriebene Berichte für die Wasser- und Abwasserwirtschaft​

Für Betreiber im Rahmen einer öffentlichen Dienstleistungskonzession (DSP) oder eines Pachtvertrags gelten mehrere Berichtspflichten:

RPQS – Bericht über Preis und Dienstleistungsqualität: Wird gemäß dem Allgemeinen Gesetz über die Gebietskörperschaften (CGCT) jährlich für Trinkwasser- und Abwasserdienstleistungen vorgeschrieben. Muss Leistungsindikatoren enthalten: Konformitätsrate der Probenahmen, Ausfallrate, erzeugte/verteilte Menge, Netzwirkungsgrad.

Das Eziwan-Dashboard generiert automatisch die Rohdaten für diese Kennzahlen (geförderte Mengen, Ausfallzeiten, Anzahl der Störfälle).

Vorgeschriebene Überwachungsberichte: Für bestimmte Entnahme- oder Einleitungsanlagen sind regelmäßige Berichte an die DREAL (Regionaldirektion für Umwelt, Raumordnung und Wohnungswesen) erforderlich. Die historischen Daten aus Eziwan können als CSV-Datei exportiert werden, um diese Berichte zu erstellen.

Datenaufbewahrung: Für Trinkwasser müssen die Überwachungsdaten mindestens 5 Jahre lang aufbewahrt werden. Mit Eziwan lässt sich die Datenaufbewahrungsdauer je nach Abonnement auf mehrere Jahre einstellen.

6. Konkretes Beispiel: Reduzierung der Dienstreisen​

Hintergrund​

Ein interkommunaler Abwasserverband in der Region Pays de la Loire betreut 65 Hebewerke, die sich über ein Gebiet von 1.500 km² verteilen. Vor der Einführung von Eziwan:

• 3 Wartungstechniker, die das gesamte Gebiet abdeckten
• Etwa 180 Einsätze pro Jahr (2,8 pro Standort)
• Geschätzte Kosten für Dienstreisen und Bereitschaftsdienste: 85.000 € pro Jahr

Nach 12 Monaten mit Eziwan​

Durch Ferndiagnose vermiedene Anfahrten:

• 45 % der Alarme wurden aus der Ferne ohne Anfahrt behoben (Fernrückstellung, bestätigte Diagnose ohne Dringlichkeit)
• 20 % der Einsätze wurden dank Voralarm im Voraus vorbereitet (der Techniker fährt mit dem richtigen Ersatzteil los)

Gemessene Ergebnisse:

• Einsätze: von 180 auf 105 pro Jahr (-42 %)
• Durchschnittliche Einsatzzeit: von 3 Stunden auf 1 Stunde 45 Minuten (verbesserte Vorbereitung)
• Vor einem Ausfall erkannte Störungen: 8 Fälle im Jahr (Pumpen mit Stromabweichung)
• Geschätzte Einsparung: 38.000 € pro Jahr bei den Wartungskosten

Unsere Kunden, die Pumpstationen betreiben, verzeichnen in den ersten 12 Monaten nach der Einführung im Durchschnitt einen Rückgang der Fahrten um 35 bis 55 %.

FAQ – Fernüberwachung von Pumpstationen​

Funktioniert das Gateway auch bei älteren Hebeanlagen ohne SPS?

Ja. Über das Erweiterungsmodul für digitale Ein- und Ausgänge kann das Gateway die potentialfreien Kontakte der elektromechanischen Anlaufschaltkästen direkt auslesen: Pumpenzustand, thermischer Fehler, Vorhandensein der Stromversorgung. Für analoge 4–20-mA-Füllstandssensoren steht ein direkter Analogeingang zur Verfügung. Durch diesen Ansatz entfällt die Installation einer SPS an bestehenden Stationen.

Wie viele Variablen lassen sich an einer kleinen Station (LOGO! 8 oder M221) überwachen?

Der LOGO! 8 von Siemens unterstützt bis zu 64 konfigurierbare Modbus-Blöcke und der M221 von Schneider bis zu 100 %MW-Wörter in Modbus TCP. Für eine Standardstation mit zwei Pumpen liegt der in diesem Artikel beschriebene Überwachungsplan (ca. 20 Variablen) weit innerhalb der Grenzen dieser Steuerungen. Das Eziwan-Gateway selbst unterliegt keiner praktischen Begrenzung hinsichtlich der Anzahl der erfassten Variablen.

Sind die Daten zum Fördervolumen für die RPQS-Berichte ausreichend genau?

Dies hängt von der Genauigkeit des installierten Durchflussmessers ab (typischerweise ±0,5 % bis ±2 % bei einem elektromagnetischen Durchflussmesser). Das Gateway erfasst die Impulse oder den Analogwert des Durchflussmessers und versieht sie mit einem Zeitstempel, wobei die Auflösung konfigurierbar ist (bei Bedarf jede Sekunde). Der Eziwan-Verlauf kann als CSV-Datei mit allen Rohmesswerten exportiert werden, um die vom RPQS geforderten integrierten Volumenberechnungen durchzuführen.

Wie geht man mit den häufigen kurzen Stromausfällen an bestimmten Standorten in ländlichen Gebieten um?

Das Eziwan-Gateway startet nach einem Stromausfall in weniger als 30 Sekunden und stellt den VPN-Tunnel automatisch wieder her. Die vor dem Stromausfall erfassten Daten werden bereits an die Cloud übertragen. Dauert der Stromausfall länger als 30 Sekunden, puffert das Gateway die Daten beim Neustart und überträgt sie erneut. Für Standorte mit sehr häufigen Stromausfällen (mehrmals täglich) reicht eine 24-V-DC-USV mit geringer Kapazität (Autonomie von einigen Minuten) aus, um Mikroausfälle abzufangen.

Ist es möglich, Befehle (Rückstellung, Start) aus der Ferne an die Pumpen zu senden?

Ja, über das Schreiben in Modbus-Register (FC=06 oder FC=16). Diese Funktion muss in der Eziwan-Konfiguration ausdrücklich aktiviert und durch strenge Zugriffsrechte geschützt werden (nur bestimmte Konten dürfen schreiben). Eine lückenlose Rückverfolgbarkeit ist gewährleistet: Jeder Register-Schreibvorgang wird mit der Identität des Bedieners und einem Zeitstempel protokolliert.

Dieser Leitfaden behandelt die wichtigsten Aspekte für den Praktiker: Geschichte, Byte-für-Byte-Struktur des Frames, Funktionscodes, Vergleich mit konkurrierenden Protokollen, Leistungsoptimierung, Sicherheit sowie ein vollständiges und funktionsfähiges Python-Code-Beispiel.

1. Von Modbus RTU zu Modbus TCP: 45 Jahre Entwicklung​

Die Entstehung von Modbus im Jahr 1979​

Modbus wurde 1979 von Modicon (heute Teil von Schneider Electric) entwickelt, um die Kommunikation zwischen den ersten speicherprogrammierbaren Steuerungen vom Typ Modicon 084 zu ermöglichen. Es handelte sich um ein serielles (RS-232, später RS-485) Master-Slave-Protokoll, das für einen einzigen Zweck entwickelt wurde: das Lesen und Schreiben von numerischen Werten auf Feldgeräten.

Einfachheit war das grundlegende Konstruktionsprinzip:

• Keine Netzwerkadressierung – lediglich eine Slave-ID von 1 bis 247 auf dem Bus
• Keine Authentifizierung – jeder Master kann jeden Slave abfragen
• Keine automatische Erkennung – die Liste der Slaves wird manuell konfiguriert
• Keine Sicherheitsmechanismen – das Protokoll setzt eine physisch gesicherte Umgebung voraus

Modbus RTU (Remote Terminal Unit): Kompakte Binärversion für RS-485. Die Daten werden binär übertragen, mit einem 16-Bit-CRC zur Fehlererkennung. Nach wie vor weit verbreitet bei Feldgeräten (Energiezähler, Drucksensoren, Frequenzumrichter).

Modbus ASCII: ASCII-lesbare Version für RS-232-Verbindungen. Weniger effizient (2 Bytes pro Datenbyte), in neuen Anlagen veraltet.

Modbus TCP: Ethernet ohne Protokollrevolution​

Um 1996–1999, als sich Ethernet in Fabriken zunehmend durchsetzte, wurde das Modbus-Protokoll in TCP/IP-Frames gekapselt. Die Überarbeitung erfolgte äußerst präzise:

• Gleiches Datenmodell (Coils, diskrete Eingänge, Eingangsregister, Halteregister)
• Gleiche Funktionscodes
• Gleiche Registeradressierung
• Wegfall des CRC (TCP gewährleistet die Integrität)
• Hinzufügung eines 7-Byte-MBAP-Headers für das Routing und die Korrelation von Anfragen
• Standard-TCP-Port: 502

Der Vorteil: Alle vorhandenen Geräte, die Modbus RTU unterstützten, konnten mit minimalen Änderungen auf Modbus TCP umgestellt werden. Der Nachteil: Die ursprünglichen Sicherheitslücken blieben bestehen.

2. Aufbau eines Modbus-TCP-Frames – Byte-für-Byte-Analyse​

Überblick über das Raster​

┌─────────────────────────────────────────────────────────────────────┐
│                        Trame Modbus TCP                             │
├──────────────────────────────────────────┬──────────────────────────┤
│           MBAP Header (7 octets)         │        PDU               │
├──────────┬──────────┬──────────┬─────────┼────────────┬─────────────┤
│ Trans.ID │ Proto.ID │  Length  │ Unit ID │  Func.Code │    Data     │
│  2 bytes │  2 bytes │  2 bytes │  1 byte │   1 byte   │  n bytes    │
└──────────┴──────────┴──────────┴─────────┴────────────┴─────────────┘

Analyse des MBAP-Headers​

Transaktionskennung (2 Bytes): Eine vom Kunden frei gewählte Nummer, die in der Antwort unverändert zurückgegeben wird. Ermöglicht die Zuordnung der Antworten zu den Anfragen bei persistenten Verbindungen mit mehreren laufenden Anfragen. In der Praxis verwenden die meisten Clients einen einfachen Zähler (00 01, 00 02, 00 03...) oder eine feste Kennung (00 00), wenn sie im sequenziellen Anfrage-Antwort-Modus arbeiten.

Protokollkennung (2 Bytes): Für Modbus immer 00 00. Diese Konstante wurde vorgesehen, um eine eventuelle Erweiterung auf andere Protokolle über denselben Port zu ermöglichen, wurde jedoch nie verwendet.

Länge (2 Byte): Anzahl der folgenden Bytes, im Big-Endian-Format. Beinhaltet die Unit-ID und die PDU, jedoch nicht die ersten 4 Bytes des MBAP-Headers. Bei einer FC=03-Anfrage mit 10 Registern: 6 Bytes (1 Unit-ID + 1 FC + 2 Adressen + 2 Count) → 00 06.

Unit Identifier (1 Byte): Kennung des Modbus-Slaves. Bei direkt angeschlossenen Steuerungen (S7-1200 mit MB_SERVER, M340 mit integriertem Modbus-Server) beträgt der Wert in der Regel 1 oder 255. Bei Modbus-RTU→TCP-Gateways entspricht diese Kennung der Adresse des RTU-Slaves am RS-485-Bus.

Analyse einer vollständigen FC=03-Abfrage​

Auslesen von 10 Holding-Registern ab der Adresse 100 (z. B.: %MW100 beim Schneider M340):

Requête client  (hex) :  00 01  00 00  00 06  FF  03  00 64  00 0A

Décodage byte par byte :
  00 01  → Transaction ID = 1
  00 00  → Protocol ID = 0 (Modbus standard)
  00 06  → Length = 6 (Unit ID + FC + 2 adresse + 2 count)
  FF     → Unit ID = 255 (0xFF = CPU locale M340)
  03     → Function Code = Read Holding Registers
  00 64  → Starting Address = 100 (0x0064 en big-endian)
  00 0A  → Quantity = 10 registres (0x000A)

Réponse automate  (hex) :  00 01  00 00  00 17  FF  03  14  [20 octets]

Décodage :
  00 01  → Transaction ID = 1 (même que la requête — corrélation)
  00 00  → Protocol ID = 0
  00 17  → Length = 23 (1 UID + 1 FC + 1 ByteCount + 20 données)
  FF     → Unit ID = 255
  03     → Function Code = 3 (confirme que c'est une réponse normale)
  14     → Byte Count = 20 (10 registres × 2 octets = 0x14 hex)
  [suivi de 20 octets de données — 10 valeurs uint16 big-endian]

Ausnahmecodes (Fehlermeldungen)​

Wenn der Automat eine Anfrage nicht bearbeiten kann, gibt er einen Ausnahmecode zurück:

Réponse exception (hex) :  00 01  00 00  00 03  FF  83  02

  83 → FC + 0x80 = 3 + 128 = 131 → indique une réponse d'exception sur FC=3
  02 → Exception code : Illegal Data Address

3. Die Funktionscodes im Detail​

FC=01 und FC=02 – Bits auslesen​

FC=01 : Read Coils           → bits de sortie (écriture autorisée)
FC=02 : Read Discrete Inputs → bits d'entrée (lecture seule)

Requête : FC  AddrH  AddrL  QuantH  QuantL
          01  00 00  00 00  00 10   (lecture 16 coils depuis @0)

Réponse : FC  ByteCount  Coil_Data
          01  02         [2 bytes = 16 bits d'état]
          
Note : les coils sont packés en bits, LSB first.
       Byte1 bit0 = Coil@0, Byte1 bit1 = Coil@1, etc.

FC=03 — Lesen der Halteregister (am häufigsten verwendet)​

Lesen und Schreiben von 16-Bit-Registern. Begrenzung: maximal 125 Register pro Anfrage.

FC=04 — Eingangsregister lesen​

Entspricht FC=03, gilt jedoch für die „Eingangsregister“ (nur lesbar). Bei Schneider M340 entspricht dies den %IW. Bei den meisten Steuerungen wird dies selten verwendet, da die analogen Messwerte in die %MW (Holding-Register) kopiert werden.

FC=06 und FC=16 – Schreiben von Registern​

FC=06 : Write Single Register
  Requête : FC  AddrH  AddrL  ValueH  ValueL
            06  00 64  00 64  01 F4     (écriture 500 à l'adresse 100)

FC=16 : Write Multiple Registers (jusqu'à 123 registres par requête)
  Requête : FC  AddrH  AddrL  CountH  CountL  ByteCount  Values...
            10  00 64  00 05  01 2C   [données]

4. Modbus TCP vs. OPC-UA vs. MQTT: Welches Protokoll eignet sich für Ihre Architektur?​

Diese drei Protokolle kommen in modernen IIoT-Architekturen nebeneinander zum Einsatz. Sie bedienen unterschiedliche Schichten und stehen nicht in direktem Wettbewerb zueinander.

Wie soll man sich entscheiden?​

Verwenden Sie Modbus TCP, wenn:

• Die SPS Modbus TCP unterstützt (Siemens S7-1200, Schneider M340/M221/M241, Wago, Allen-Bradley...)
• Sie einfache Messwerte erfassen müssen (16-Bit-Register)
• Die einfache Konfiguration Vorrang vor der Vielseitigkeit des Datenmodells hat

Verwenden Sie OPC-UA, wenn:

• Die SPS OPC-UA-Server nativ unterstützt (S7-1500, B&R, Beckhoff, aktuelle CODESYS 3.x-Versionen)
• Sie komplexe Variablen (Strukturen, Arrays, benutzerdefinierte Typen) überwachen müssen
• Die Interoperabilität mit anderen SCADA- oder MES-Systemen eine Voraussetzung ist

Verwenden Sie MQTT für den Cloud-Transport, wenn:

• Sie über ein Gateway (wie Eziwan) verfügen, das Daten über Modbus/OPC-UA erfasst und über MQTT veröffentlicht
• Sie eine skalierbare Pub/Sub-Architektur für Tausende von Messpunkten benötigen

Die Zielarchitektur für das IIoT in der Cloud:

[Automate] ──Modbus TCP / OPC-UA──→ [Gateway] ──MQTT over TLS──→ [Cloud]

Das Gateway wandelt Daten um und überträgt sie. Es bildet die Brücke zwischen der OT-Welt (Modbus/OPC-UA) und der Cloud-Welt (MQTT/REST).

5. Modbus-TCP-Sicherheit: Das Problem und die Lösungen​

Das völlige Fehlen einer Authentifizierung​

Modbus TCP verfügt über keine nativen Sicherheitsmechanismen:

• Keine Authentifizierung: Jeder im Netzwerk kann Daten lesen und schreiben
• Keine Verschlüsselung: Die Daten werden im Klartext übertragen (mit Wireshark lesbar)
• Keine Autorisierung: Es gibt keine Lese-/Schreibrechte für einzelne Benutzer

Praktische Konsequenz: Wenn Ihre SPS über das Internet erreichbar ist (Port 502 offen), ist sie völlig ungeschützt. Wenn sich jemand in Ihr OT-Netzwerk einloggt (physisch oder über eine Sicherheitslücke), kann er alle Register lesen und ändern.

Mögliche Antworten​

Netzwerksegmentierung (primäre Maßnahme): Den Modbus-TCP-Datenverkehr auf ein isoliertes OT-Netzwerk beschränken. Das Eziwan-Gateway befindet sich in diesem OT-Netzwerk; die Kommunikation mit der Cloud erfolgt über einen VPN-Tunnel und nicht über einen offen zugänglichen Port 502.

IP-Filterung auf der SPS (sekundäre Maßnahme): Bestimmte neuere SPS-Modelle (Schneider M340, Firmware ≥ 2.60; Siemens S7-1200, Firmware V4.x mit FIREWALL-Funktionen) unterstützen eine IP-Filterung: Nur die IP-Adresse des Eziwan-Gateways ist berechtigt, eine Verbindung zum Port 502 herzustellen.

Modbus Security (erweiterte Maßnahme): Die Modbus Organization hat 2018 eine Erweiterung namens „Modbus Security“ (TLS-Transport für Modbus TCP) auf Port 802 veröffentlicht. Diese Erweiterung wird von den auf dem Markt erhältlichen Steuerungen noch nicht flächendeckend unterstützt, ist jedoch auf einigen neueren Geräten verfügbar.

6. Optimierung der Erfassungsleistung​

Zusammenfassung von Anfragen (Batching)​

Die goldene Regel: Lesevorgänge in zusammenhängende Blöcke zusammenfassen. Das Auslesen von 100 zusammenhängenden Registern in einer einzigen Abfrage ist wesentlich effizienter als 100 Abfragen mit jeweils einem Register:

Configuration inefficace (100 requêtes) :
  Lire %MW0  → 1 requête (2 octets de données)
  Lire %MW50 → 1 requête
  Lire %MW99 → 1 requête
  ... 97 requêtes supplémentaires ...
  Latence totale : 100 × (aller-retour réseau) ≈ 100 × 5ms = 500ms

Configuration optimisée (1 requête) :
  Lire %MW0 à %MW99 → 1 requête (200 octets de données)
  Latence totale : 1 × 5ms = 5ms

Das Eziwan-Gateway gruppiert die konfigurierten Variablen automatisch in zusammenhängende Bereiche. Um diese Gruppierung zu optimieren, ordnen Sie Ihre Überwachungsvariablen in benachbarten Speicherbereichen an.

Auswirkungen auf den SPS-Zyklus​

Jede empfangene Modbus-TCP-Anfrage wird von der SPS am Ende des Programmzyklus verarbeitet. Bei einer M340 mit einem Zyklus von 10 ms können 10 gleichzeitige Modbus-Anfragen den Zyklus um 1 bis 3 ms verlängern.

Empfehlung: Bei Anwendungen mit Echtzeitanforderungen sollte pro SPS-Zyklus nicht mehr als eine Modbus-Anfrage gesendet werden. Verringern Sie die Abfragehäufigkeit, wenn sich der Zyklus verlängert.

7. Vollständiges Python-Beispiel mit pymodbus​

"""
Collecte Modbus TCP industrielle avec gestion d'erreurs robuste
Compatible Schneider M340, Siemens S7-1200, Wago, Allen-Bradley...
Testé avec pymodbus >= 3.0

Installation :
    pip install pymodbus loguru
"""

from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ModbusException, ConnectionException
from loguru import logger
import struct
import time
from dataclasses import dataclass
from typing import Optional


# ─── Configuration ────────────────────────────────────────────────────────────

HOST     = "192.168.1.20"  # IP automate Schneider M340
PORT     = 502             # Port Modbus TCP
UNIT_ID  = 255             # 255 pour CPU locale M340, 1 pour S7-1200
TIMEOUT  = 3               # Timeout en secondes
RETRIES  = 3               # Nombre de tentatives avant abandon


# ─── Structure de données ─────────────────────────────────────────────────────

@dataclass
class VariablesProcess:
    temperature_c: float = 0.0
    debit_lmin: int = 0
    pression_bar: float = 0.0
    pompe_1_marche: bool = False
    pompe_2_marche: bool = False
    code_defaut: int = 0
    compteur_production: int = 0
    timestamp: float = 0.0


# ─── Client Modbus avec reconnexion automatique ───────────────────────────────

class ModbusCollecteur:
    """Collecteur Modbus TCP avec gestion de reconnexion et retry."""

    def __init__(self, host: str, port: int = 502, unit_id: int = 1):
        self.host = host
        self.port = port
        self.unit_id = unit_id
        self.client: Optional[ModbusTcpClient] = None
        self._connexions_ok = 0
        self._connexions_echec = 0

    def connecter(self) -> bool:
        """Établit la connexion TCP vers l'automate."""
        try:
            self.client = ModbusTcpClient(
                self.host,
                port=self.port,
                timeout=TIMEOUT,
                retries=1,          # Retries gérés par notre code
                reconnect_delay=0,  # Pas de reconnexion automatique
            )
            if self.client.connect():
                self._connexions_ok += 1
                logger.info(f"Connecté à {self.host}:{self.port}")
                return True
            else:
                self._connexions_echec += 1
                logger.warning(f"Connexion refusée par {self.host}:{self.port}")
                return False
        except Exception as e:
            logger.error(f"Erreur connexion : {e}")
            return False

    def deconnecter(self):
        if self.client:
            self.client.close()
            self.client = None

    def lire_holding_registers(
        self, adresse: int, count: int
    ) -> Optional[list[int]]:
        """Lit des registres avec retry automatique."""
        for tentative in range(1, RETRIES + 1):
            try:
                if not self.client or not self.client.is_socket_open():
                    if not self.connecter():
                        time.sleep(1)
                        continue

                result = self.client.read_holding_registers(
                    address=adresse, count=count, slave=self.unit_id
                )

                if result.isError():
                    exception_code = getattr(result, 'exception_code', '?')
                    logger.warning(
                        f"Erreur Modbus addr={adresse} count={count} "
                        f"exception_code={exception_code}"
                    )
                    # Exception 04 (server busy) → attendre avant retry
                    if exception_code == 6:
                        time.sleep(0.5)
                    self.deconnecter()
                    continue

                return result.registers

            except ConnectionException:
                logger.warning(f"Connexion perdue (tentative {tentative}/{RETRIES})")
                self.deconnecter()
                time.sleep(0.5)
            except Exception as e:
                logger.error(f"Erreur inattendue : {e}")
                self.deconnecter()
                time.sleep(1)

        logger.error(f"Échec lecture après {RETRIES} tentatives — addr={adresse}")
        return None

    @staticmethod
    def registres_to_float32_abcd(reg_high: int, reg_low: int) -> float:
        """Décode 2 registres 16-bit en float32 IEEE754 big-endian (ABCD)."""
        raw = struct.pack(">HH", reg_high, reg_low)
        return struct.unpack(">f", raw)[0]

    @staticmethod
    def registres_to_int32(reg_high: int, reg_low: int) -> int:
        """Décode 2 registres en entier 32-bit signé big-endian."""
        raw = struct.pack(">HH", reg_high, reg_low)
        return struct.unpack(">i", raw)[0]


# ─── Lecture des variables process ───────────────────────────────────────────

def lire_variables(collecteur: ModbusCollecteur) -> Optional[VariablesProcess]:
    """
    Lecture optimisée : 1 seule requête Modbus pour toutes les variables.
    
    Plan mémoire (M340 EcoStruxure) :
      %MW100 : Temperature (int16, ×0.1 → °C)
      %MW101 : Débit (int16, L/min)
      %MW102-103 : Pression (float32 ABCD, bar)
      %MW104 : États machine (bits 0-7)
      %MW105 : Code défaut actif
      %MW106-107 : Compteur production (int32)
    """
    # 1 requête pour %MW100 à %MW107 (8 registres)
    registres = collecteur.lire_holding_registers(adresse=100, count=8)
    if registres is None:
        return None

    vars_process = VariablesProcess(
        temperature_c  = registres[0] * 0.1,                               # %MW100
        debit_lmin     = registres[1],                                      # %MW101
        pression_bar   = ModbusCollecteur.registres_to_float32_abcd(        # %MW102+103
                             registres[2], registres[3]),
        pompe_1_marche = bool(registres[4] & 0x0001),                      # %MW104 bit0
        pompe_2_marche = bool(registres[4] & 0x0002),                      # %MW104 bit1
        code_defaut    = registres[5],                                      # %MW105
        compteur_production = ModbusCollecteur.registres_to_int32(          # %MW106+107
                             registres[6], registres[7]),
        timestamp      = time.time(),
    )

    return vars_process


# ─── Boucle principale ────────────────────────────────────────────────────────

def main():
    collecteur = ModbusCollecteur(HOST, PORT, UNIT_ID)
    INTERVALLE = 5  # secondes entre chaque collecte

    logger.info(f"Démarrage collecte Modbus TCP — {HOST}:{PORT} — cycle {INTERVALLE}s")

    while True:
        try:
            vars_process = lire_variables(collecteur)

            if vars_process:
                logger.info(
                    f"T={vars_process.temperature_c:.1f}°C  "
                    f"Q={vars_process.debit_lmin}L/min  "
                    f"P={vars_process.pression_bar:.2f}bar  "
                    f"P1={'ON' if vars_process.pompe_1_marche else 'OFF'}  "
                    f"Défaut={vars_process.code_defaut}"
                )
                # Ici : publier via MQTT, API REST, ou base time-series
                # mqtt_client.publish("usine/ligne3/variables", vars_process)
            else:
                logger.warning("Collecte échouée — attente 10s avant retry")
                time.sleep(10)
                continue

            time.sleep(INTERVALLE)

        except KeyboardInterrupt:
            logger.info("Arrêt demandé.")
            collecteur.deconnecter()
            break


if __name__ == "__main__":
    main()

FAQ – Modbus-TCP/IP-Protokoll​

Warum ist der Modbus-TCP-Port 502 und kein Standardport wie 80 oder 443?

Der Port 502 wurde Modbus von der IANA (Internet Assigned Numbers Authority) im Zuge der Standardisierung von Modbus TCP in den 1990er Jahren offiziell zugewiesen. Damals gab es keinen Grund, bereits vorhandene IT-Anwendungsports wiederzuverwenden. Da es sich um einen registrierten Port (< 1024) handelt, erfordert seine Nutzung als Server unter Linux Root-Rechte – was industrielle Firmware nativ unterstützt.

Wie viele Register können bei einer einzelnen FC=03-Abfrage gelesen werden?

Die Obergrenze liegt bei 125 Registern pro FC=03-Anfrage (Read Holding Registers), wie in der offiziellen Modbus-Spezifikation festgelegt. Das entspricht maximal 250 Byte Nutzdaten pro Anfrage. Für FC=16 (Write Multiple Registers) liegt die Obergrenze bei 123 Registern pro Anfrage. Das Eziwan-Gateway übernimmt automatisch die Aufteilung, wenn ein angeforderter Bereich diese Grenzen überschreitet.

Unterstützt Modbus TCP mehrere gleichzeitige Client-Verbindungen?

Ja, aber die Obergrenze wird von der Steuerung festgelegt. Die Schneider M340 unterstützt bis zu 16 gleichzeitige Verbindungen, die Siemens S7-1200 bis zu 8 (über MB_SERVER). Darüber hinaus gibt die SPS die Ausnahme 06 (Server Busy) zurück. In der Praxis erreichen ein Erfassungs-Gateway + ein Diagnosetool + ein lokales SCADA-System leicht 3 gleichzeitige Verbindungen – dies ist zu beachten.

Kann Modbus TCP verschlüsselt werden?

Der native Modbus-TCP-Standard (Port 502) ist nicht verschlüsselt. Eine Erweiterung namens „Modbus Security“ auf Port 802 mit TLS gibt es seit 2018, wird jedoch von aktuellen Steuerungen nur selten unterstützt. Die praktische Lösung besteht darin, Modbus TCP auf ein isoliertes OT-Netzwerk zu beschränken und die gesamte Kommunikation nach außen über einen verschlüsselten VPN-Tunnel (wie OpenVPN von Eziwan) zu leiten – die Verschlüsselung erfolgt auf der Transportschicht, nicht durch Modbus selbst.

Ist pymodbus die einzige Python-Bibliothek für Modbus TCP?

Nein. Die wichtigsten Alternativen sind minimalmodbus (einfacher für Modbus RTU), umodbus (schlank, geringer Speicherbedarf) und pyModbusTCP (rein TCP, ohne Abhängigkeiten). Für industrielle Projekte in Python bleibt pymodbus >= 3.0 die umfassendste Wahl mit Ausnahmebehandlung, Wiederverbindungsfunktion und Unterstützung beider Modi (RTU und TCP).

Wie lässt sich ein Modbus-TCP-Datenaustausch ohne Zugriff auf die SPS debuggen?

Verwenden Sie Modbus Slave (Windows) als lokalen SPS-Simulator oder diagslave (Befehlszeile, plattformübergreifend). Diese Tools simulieren einen Modbus-TCP-Server, der auf konfigurierbare Adressen reagiert. Ideal zum Testen einer Datenerfassungskonfiguration, ohne dabei eine SPS im Produktivbetrieb zu beeinträchtigen.

Dieser Leitfaden stellt die wichtigsten Anwendungsfälle des IoT in der Landwirtschaft in Frankreich vor, einschließlich kompatibler Geräte, Kosten und ROI, und erklärt, wie man eine robuste Lösung zur Überwachung landwirtschaftlicher Betriebe in ländlichen Gebieten implementiert – auch ohne Glasfaseranschluss.

Die Landwirtschaft: ein fruchtbarer Boden für das industrielle IoT​

In der modernen Landwirtschaft kommen bereits zahlreiche elektronische und elektromechanische Geräte zum Einsatz: automatisierte Bewässerungssysteme, Ventilatoren in Stallungen, Milchkühltanks, Lagersilos, klimatisierte Gewächshäuser, Brunnenpumpen. Die überwiegende Mehrheit dieser Geräte verfügt über Kommunikationsschnittstellen (Modbus RTU, 4–20 mA, Impulsausgänge), die eine IoT-Anbindung ohne Austausch der Geräte ermöglichen.

Was das IoT der Landwirtschaft bringt:

• Rund-um-die-Uhr-Überwachung ohne ständige Anwesenheit des Landwirts
• Sofortige Warnmeldungen bei Unregelmäßigkeiten (Geräteausfall, Überschreitung von Schwellenwerten)
• Datenhistorie zur Optimierung der Betriebsabläufe und zur Rückverfolgbarkeit
• Reduzierung von Verlusten (nicht konforme Milch, schlechtes Wachstum, Tiersterblichkeit)
• Erleichterte Einhaltung gesetzlicher Vorschriften (Tierschutz, Wasserrichtlinien)

Anwendungsfall 1: Überwachung von Stallgebäuden​

Schweineställe, Hühnerställe, Milchvieh​

Stallungen mit Bodenhaltung (Schweinezuchtställe, Hühnerställe, Milchviehställe) eignen sich besonders gut für die IoT-Überwachung. Die zu überwachenden kritischen Parameter sind:

Klimatische Bedingungen im Stall:

• Temperatur (°C) und relative Luftfeuchtigkeit (%): Erhebliche Schwankungen wirken sich direkt auf das Wachstum und die Gesundheit der Tiere aus
• CO₂-Konzentration (ppm): Indikator für die Luftqualität und die Effizienz der Belüftung
• NH₃-Konzentration (Ammoniak, ppm): gefährliches Gas, das durch Exkremente entsteht und aus Tierschutzgründen reguliert wird

Lüftungsanlagen:

• Ein-/Aus-Zustand jedes Ventilators (Schalteingang)
• Drehzahl oder Position der Klappen (Ausgang 0–10 V oder 4–20 mA)
• Stromverbrauch pro Stromkreis (Stromwandler)

Futter und Wasser:

• Füllstand der Futtersilos (Ultraschall-Füllstandssensor)
• Wasserverbrauch (Impuls-Durchflussmesser)
• Status der automatischen Futterautomaten (TOR)

Kompatible Sensoren und Schnittstellen:

Typische Alarmschwellen für Stallgebäude:

Anwendungsfall 2: Überwachung von Milchtanks​

Das Abkühlen der Milch ist gesetzlich vorgeschrieben (Verordnung vom 15. September 2004 in der geänderten Fassung): Kuhmilch muss innerhalb von zwei Stunden nach dem Melken auf 8 °C abgekühlt und bis zur Abholung bei maximal 4 °C gelagert werden.

Die Nichteinhaltung dieser Temperaturen hat folgende Folgen:

• Irreversibler mikrobiologischer Verderb der Milch
• Verweigerung der Abholung durch die Molkerei (direkter finanzieller Verlust)
• Vertragsstrafen (Qualitätsabzug)

IoT-Überwachung des Milchtanks:

Die meisten neueren Milchtanks (Boumatic, Mueller, DeLaval, GEA, Lemmer-Fullwood) verfügen über einen RS-232- oder RS-485-Modbus-Anschluss zur Überwachung. Zu den abrufbaren Parametern gehören:

• Milchtemperatur (°C) mit einer Auflösung von 0,1 °C
• Status des Kühlkompressors
• Milchmenge (bei Tanks mit Füllstandsanzeige)
• Temperaturverlauf (vollständige Kurve seit dem letzten Melkvorgang)

Das Eziwan-Gateway wird über RS-232 oder RS-485 an den Tank angeschlossen und übermittelt die Daten mit einem konfigurierbaren Abfrageintervall von 5 Minuten an die Cloud. Es wird eine SMS-Benachrichtigung gesendet, wenn die Temperatur länger als 15 Minuten über 8 °C liegt.

Kundenbeispiel: Ein Milchviehhalter aus der Bretagne, der drei Milchtanks betreibt (Betrieb mit 120 Kühen), konnte dank der nächtlichen SMS-Benachrichtigungen innerhalb von sechs Monaten zwei abgelehnte Abholungen vermeiden (Kompressorausfall um 2 Uhr morgens erkannt, Reparatur um 4 Uhr vor der Abholung um 6 Uhr). Einsparung: 2 × 800 l × 0,40 €/l = 640 € vermiedener Verlust, zuzüglich Qualitätsstrafen.

Anwendungsfall 3: Überwachung von Gewächshäusern für Gartenbau und Gemüseanbau​

Gartenbaugewächshäuser stellen eine erhebliche Investition dar (50 bis 300 €/m²), deren Rentabilität von der Aufrechterhaltung optimaler klimatischer Bedingungen abhängt. Mithilfe der IoT-Überwachung lassen sich Störungen (Heizungsausfall, blockierte Belüftung, Riss in der Folie) erkennen, bevor sie irreversible Schäden an den Kulturen verursachen.

Zu überwachende Parameter im Gewächshaus:

Überwachbare Gewächshausanlagen:

• Heizkessel und Wärmepumpen (Heizung): Bosch, Vaillant, Viessmann – über Modbus oder Schaltrelais
• Ventilatoren und Lüftungsklappen: 0–10-V-Steuerung oder Relais
• Bewässerungspumpen: Modbus-Frequenzumrichter
• Wasseraufbereitungsanlage (UVA, Osmoseanlage): digitale Ein-/Ausgänge für Betriebs-/Stoppstatus

ROI der Überwachung eines Gemüsegewächshauses: Bei einem 5.000 m² großen Tomatengewächshaus (Jahresertrag ~500 t, Verkaufspreis ~0,80 €/kg = 400.000 € Jahresumsatz) kann ein in der Nacht im März unentdeckt gebliebener Heizungsausfall die gesamte Ernte vernichten – ein Verlust von 100.000 bis 200.000 €. Die Kosten für ein Eziwan-Gateway mit SMS-Benachrichtigung: 500 € + 100 €/Jahr für das Abonnement. Sofortiger ROI.

Anwendungsfall 4: Bewässerungsmanagement​

Die Bewässerung macht 45 % des industriellen Wasserverbrauchs in Frankreich aus. Die Vorschriften werden immer strenger (Verordnungen zu Einschränkungen bei Niedrigwasser, Wassergebühren), wodurch eine präzise Steuerung der Bewässerung unerlässlich wird.

IoT-Überwachung der Bewässerung:

• Parzellen-Durchflussmesser: Messung der pro Parzelle oder Kultur ausgebrachten Wassermenge (Modbus oder Impuls)
• Bodenfeuchtemessgeräte (Tensiometer, TDR-Sensoren): Messung der volumetrischen Feuchte und der Bodensaugkraft – Datenbasis für die Auslösung des Bewässerungsbedarfs
• Integrierte Wetterstationen: ETP (potenzielle Evapotranspiration) in Echtzeit berechnet, Anbindung an Météo France für die prognostizierte ETP
• Bohrloch-Wasserzähler: Erfassung der entnommenen Wassermengen für die Meldung an die DDT (gesetzliche Verpflichtungen > 1.000 m³/Jahr)
• Bohrlochpumpen und Bewässerungsanlagen: Überwachung des Zustands und des Stromverbrauchs

Einhaltung der gesetzlichen Vorschriften: Betriebe, die mehr als 1.000 m³/Jahr an Grund- oder Oberflächenwasser entnehmen, müssen ihre Entnahmen melden (Artikel L214-1 des Umweltgesetzbuchs). Eziwan erstellt automatisch die monatlichen Entnahmegesichtsberichte zur Übermittlung an die DDT/DREAL.

Anwendungsfall 5: Lagersilos​

Die Lagerung von Getreide ist von großer wirtschaftlicher Bedeutung. Ungeeignete Lagerbedingungen (Temperatur, Feuchtigkeit) können zur Bildung von Mykotoxinen (Aflatoxine, DON) oder Schimmel führen, wodurch die Ware an Qualität verliert oder unverkäuflich wird.

Zu überwachende Parameter:

• Temperatur: Silo-Temperaturmessketten (Rolfes, GSI) mit 4 bis 8 Fühlern pro Silo in unterschiedlichen Höhen
• Feuchtigkeit: Feuchtigkeitssensoren für das Getreide – kontinuierlich oder am Silo-Einlauf (Annahsilo)
• Füllstand: Füllstandssensoren mit Ultraschall- oder Druckmessung zur Ermittlung des Lagervolumens
• Belüftung: Betriebszustand der Absaug- und Kühlventilatoren, Durchfluss (m³/h)
• Stromverbrauch: Automatische Steuerung der Ventilatoren in Abhängigkeit von der Temperatur

Schnittstelle: Die meisten modernen Silo-Steuerungssysteme (Superchief, GSI Fan Controller, Brock NECO) verfügen über einen Modbus-RS-485-Ausgang oder einen RS-232-Anschluss.

4G-Netzabdeckung für landwirtschaftliche Betriebe​

Die überwiegende Mehrheit der französischen landwirtschaftlichen Betriebe verfügt über keinen Glasfaseranschluss. 4G LTE deckt 99,2 % der französischen Gemeinden ab (Quelle: Arcep 2025), doch die Netzabdeckung innerhalb von Gebäuden kann schwach sein.

Lösungen für Gebiete mit schlechter Netzabdeckung:

1. Externe 4G-Richtantenne: Verstärkung von 9 bis 15 dBi, Reichweite bis zu 30 km bei direkter Sichtverbindung, kompatibel mit allen Netzbetreibern. Montage am Giebelende eines Gebäudes oder an einem Mast.

2. Eziwan Multi-Operator-SIM: Testet die drei französischen Netzbetreiber (Orange, SFR, Bouygues) und stellt eine Verbindung zum besten verfügbaren Signal her. Erhöht die Verfügbarkeit in ländlichen Gebieten erheblich.

3. LoRa + 4G-Gateway: Für Sensoren mit sehr geringem Stromverbrauch und großer Reichweite (bis zu 15 km) kann eine LoRaWAN-Architektur mit einem LoRa-Konzentrator, der über das Eziwan-Gateway mit dem 4G-Netz verbunden ist, einen gesamten Betrieb abdecken.

4. Satellitenverbindung (als letzte Möglichkeit): An Standorten ohne jegliche 4G-Abdeckung kann eine Satellitenverbindung (Starlink Low-Latency oder Eutelsat ViaSat) mit dem Eziwan Gateway verbunden werden. Latenzzeit 20–40 ms mit Starlink.

Agrarvorschriften und das Internet der Dinge​

Tierschutz​

Die EU-Richtlinie 2008/120/EG (Schweine), 2007/43/EG (Masthühner) und 1999/74/EG (Legehennen) schreibt Mindestanforderungen hinsichtlich Temperatur, Platzangebot, Belüftung und Beleuchtung vor. Die IoT-Überwachung ermöglicht es:

• die Einhaltung der gesetzlichen Grenzwerte kontinuierlich zu dokumentieren
• bei Kontrollen durch die DDPP (Direction Départementale de la Protection des Populations) Nachweise vorzulegen
• sofort zu alarmieren, wenn ein gesetzlicher Grenzwert überschritten wird

Nitratrichtlinie​

Betriebe in nitratgefährdeten Gebieten unterliegen dem Regionalen Aktionsprogramm (PAR). Die Überwachung der Ausbringung und der Güllebewirtschaftung (Durchflussmesser an der Ausbringungsvorrichtung, Füllstand der Güllegrube) erleichtert die Einhaltung der Sperrfristen und die Berechnung der Ausbringungsmengen.

Rückverfolgbarkeit in der Lieferkette​

Zahlreiche Produktketten (Label Rouge, AOP, IGP, ökologischer Landbau) verlangen eine Rückverfolgbarkeit der Aufzucht- oder Anbaubedingungen. Die IoT-Daten von Eziwan werden archiviert und können exportiert werden, um Rückverfolgbarkeitstools (Bluerex, Kite Consulting, OAD-Systèmes) zu versorgen.

Kosten und ROI für einen landwirtschaftlichen Betrieb​

Typische Investition​

ROI für einen Milchviehbetrieb​

• Kosten bei Verweigerung der Abholung: 600 bis 2.000 € (je nach Volumen + Strafgebühren)
• Jährliches Risiko ohne Überwachung: 1 bis 2 Tankvorfälle pro Jahr bei einer Betriebsdauer von 5 Jahren
• Jährliche Kosten eines Vorfalls: 600 bis 800 €/Jahr
• Kosten für die Überwachung: 250 bis 400 €/Jahr
• Netto-ROI: 200 bis 550 €/Jahr = amortisiert in weniger als 1 Jahr

Verfügbare Fördermittel​

Der Plan France 2030 und die PCAE-Beihilfen (Plan zur Steigerung der Wettbewerbsfähigkeit und Anpassung der landwirtschaftlichen Betriebe) finanzieren teilweise die Ausrüstung für die digitale Modernisierung der Landwirtschaft. Die Fördersätze variieren je nach Region und Förderprogramm (30 bis 50 % der förderfähigen Investitionen). Erkundigen Sie sich bei Ihrer Landwirtschaftskammer oder Ihrem FranceAgriMer-Berater nach den für Ihr Projekt geltenden Förderprogrammen.

Fazit​

Das industrielle Internet der Dinge (IoT) steht französischen landwirtschaftlichen Betrieben nun dank der flächendeckenden 4G-Netzabdeckung, standardisierter Modbus-Sensoren und kostengünstiger Cloud-Plattformen wie Eziwan zur Verfügung. Die technischen und finanziellen Hürden, die die Einführung bisher gebremst haben, sind deutlich gesunken.

Bei einer Anfangsinvestition von 1.000 bis 2.000 € pro Gebäude und einer Abonnementgebühr von weniger als 400 € pro Jahr profitiert ein Landwirt von einer Rund-um-die-Uhr-Überwachung seiner kritischen Anlagen, sofortigen SMS-Benachrichtigungen und einem dokumentierten Verlauf zur Erfüllung seiner gesetzlichen Verpflichtungen.

Nächster Schritt: Wenden Sie sich an das Eziwan-Team, um eine kostenlose Machbarkeitsstudie zu erhalten, die auf Ihren Betrieb und Ihre Produktionsart zugeschnitten ist.

FAQ​

Ist 4G in den ländlichen Agrargebieten Frankreichs verfügbar? Die 4G-Abdeckung im französischen Mutterland umfasst mehr als 99 % der Bevölkerung, aber nur etwa 80 % der Gesamtfläche – einige Betriebe in Funklücken bleiben weiterhin ausgeschlossen. Für diese Gebiete bietet das NB-IoT-Netz (NarrowBand-IoT) eine bessere Durchdringung in Gebäuden und eine größere Reichweite, und für völlig abgelegene Standorte stehen zunehmend Satellitenlösungen (Starlink) zur Verfügung. Vor jeder Bereitstellung ist eine vorherige Überprüfung der Netzabdeckung am genauen Standort unerlässlich.

Kann man einen bestehenden Lagersilo oder eine bestehende Genossenschaftskellerei anschließen, ohne die Anlagen auszutauschen? In den allermeisten Fällen ja. Moderne Silos verfügen über Temperatur- und Feuchtigkeitssensoren mit 4–20-mA- oder RS485-Modbus-Ausgängen – ein IoT-Gateway lässt sich direkt anschließen. Für ältere Anlagen ohne digitale Schnittstelle sind Modbus-RTU-kompatible Ersatzsensoren ab 50 bis 100 € pro Messpunkt erhältlich.

Welche gesetzlichen Auflagen lassen sich mithilfe der IoT-Überwachung dokumentieren? In der Tierhaltung: die Auflagen zur Rückverfolgbarkeit im Bereich der Tiergesundheit (Prophylaxe, Tierkennzeichnung, Transportbedingungen – EU-Verordnung 2016/429), Tierschutz (Temperaturen, Belüftung, Besatzdichte) sowie DPE-/PAC-Kontrollen können sich auf IoT-Datenhistorien als Nachweis stützen. Das automatische Protokoll aller Messungen mit zertifiziertem Zeitstempel ist ein wesentlicher Vorteil bei Kontrollen.

Weiterführende Informationen​

• Blog: 4G-Überwachung von Wasser- und Abwassersystemen – Wassermanagement für Kommunen
• Blog: ROI des industriellen IoT – Berechnung und Optimierung
• Blog: 4G-Signalüberwachung – RSRP, RSRQ und Netzabdeckung im ländlichen Raum
• Blog: M2M-IoT-SIM-Karten – Vergleich der französischen Netzbetreiber 2026

Eziwan unterstützt Landwirte, Genossenschaften und Lagerunternehmen bei der IoT-Überwachung ihrer Anlagen. Unsere Lösung lässt sich ohne Austausch an bestehende Geräte anpassen und verfügt über eine für ländliche Gebiete optimierte 4G-Konnektivität. Entdecken Sie unsere Lösungen →

Weitere Ressourcen​

• Fernüberwachung der Bewässerung – Steuerung und Überwachung von Bewässerungssystemen über das IoT
• Internetverbindung für abgelegene Industriestandorte — 4G-Konnektivität für landwirtschaftliche Betriebe in ländlichen Gebieten
• Überwachung von Industrieanlagen — Überwachung von landwirtschaftlichen Maschinen und Lageranlagen
• Industrielle Konnektivität – robuste Konnektivitätslösungen für ländliche Gebiete
• Eziwan-Lösungen für die Industrie – eine Reihe von IoT-Lösungen, die auf den Primärsektor zugeschnitten sind

Die kurze Antwort: OT-Netzwerke sind keine IT-Netzwerke. Die darin laufenden Steuerungen steuern physische Maschinen – ein Fehler bei der Steuerung oder ein unbefugter Zugriff kann industrielle oder sogar menschliche Folgen haben. Die für den allgemeinen Gebrauch bestimmten Tools wurden für einen völlig anderen Kontext entwickelt.

Dieser Artikel geht über eine kurze Antwort hinaus. Er erläutert das tatsächliche Bedrohungsmodell, beschreibt detailliert die Anforderungen der Norm IEC 62443 und stellt die technischen Kriterien zur Bewertung einer industriellen Fernzugriffslösung vor.

1. Das Purdue-Modell und die OT-Vertrauensstufen​

Um zu verstehen, warum sich Fernzugriffe im OT-Bereich unterscheiden, muss man das Purdue-Modell (Purdue Enterprise Reference Architecture) kennen, das als internationaler Maßstab für die Segmentierung industrieller Netzwerke gilt.

Niveau 5 : Réseau d'entreprise (ERP, email, bureautique)
           ─────────────────────────────────────────────
Niveau 4 : Réseau IT de site (serveurs, SGBD, Active Directory)
           ─────────────────────────────────────────────
Niveau 3 : Réseau supervision (SCADA, MES, historiens)
           ─────────────────────────────────────────────
Niveau 2 : Réseau contrôle (IHM, ingénierie)
           ─────────────────────────────────────────────
Niveau 1 : Réseau terrain (automates, variateurs, capteurs)
           ─────────────────────────────────────────────
Niveau 0 : Process physique (capteurs, actionneurs, moteurs)

Der industrielle Fernzugriff betrifft in der Regel die Ebenen 1 und 2 – die Steuerungen und die Engineering-Tools. Diese Ebenen dürfen niemals ohne Kontrolle direkt von den übergeordneten Ebenen aus zugänglich sein, geschweige denn über das Internet.

Die Segmentierung zwischen den Ebenen ist die erste Verteidigungslinie. Der Fernzugriff durchquert per Definition diese Segmentierung – daher die erhöhten Sicherheitsanforderungen.

2. Die tatsächlichen Risiken eines unkontrollierten Zugriffs auf das OT-Netzwerk​

Was in einem industriellen OT-Netzwerk offengelegt wird​

Ein typisches OT-Netzwerk umfasst:

• SPSen (S7, M340, CompactLogix), die die Maschinen steuern
• Frequenzumrichter, die die Motoren regeln
• industrielle Bediengeräte zur Überwachung und Parametrierung
• SCADA-Systeme, die den gesamten Prozess überwachen
• Messgeräte (Druck-, Temperatur- und Durchflusssensoren)

Diese Geräte wurden für den zuverlässigen Betrieb in isolierten Umgebungen entwickelt, nicht aber, um Netzwerkangriffen standzuhalten. Das Modbus-Protokoll sieht keine Authentifizierung vor. S7Comm (Siemens) verfügte in der Vergangenheit über keinerlei Verschlüsselung. Profinet, EtherNet/IP – die meisten industriellen Protokolle setzen ein vertrauenswürdiges Netzwerk voraus.

Aufbau eines Angriffs auf einen unsicher konfigurierten OT-Fernzugriff​

So verläuft typischerweise ein Angriff auf einen ungesicherten industriellen Fernzugang:

Phase 1 – Erkundung (automatisch, passiv): Ein automatischer Scanner (Shodan, Censys oder ein benutzerdefiniertes Skript) identifiziert die öffentliche IP-Adresse der Anlage und entdeckt einen offenen Port (klassisches VPN auf UDP 1194, Modbus-Port 502, S7Comm-Port 102). Diese Phase erzeugt keine verdächtigen Protokolleinträge und dauert nur wenige Sekunden.

Phase 2 – Ausnutzung des Zugriffs: Wenn das VPN nur durch ein schwaches Passwort geschützt ist (oder wenn die Anmeldedaten durch Phishing gestohlen wurden), verschafft sich der Angreifer Zugang. Handelt es sich um einen direkt exponierten Modbus-Port, kann er ohne jegliche Authentifizierung Daten lesen und schreiben.

Phase 3 – Interne Erkundung: Nachdem sich der Angreifer Zugang verschafft hat, erstellt er eine Übersicht über das OT-Netzwerk: Welche Steuerungen sind zugänglich, welche Variablen können ausgelesen werden, welche Prozessbereiche werden gesteuert?

Phase 4 – Böswillige Handlung: Die Handlungen können unmittelbar erfolgen (Produktionsstillstand, Änderung von Parametern) oder verdeckt (schrittweise Änderung von Sollwerten, um die Produktqualität zu verschlechtern, ohne einen Alarm auszulösen).

Dokumentierte Vorfälle​

Die ANSSI und die CISA (Cybersecurity and Infrastructure Security Agency, USA) dokumentieren regelmäßig Vorfälle im Zusammenhang mit unzureichend gesicherten industriellen Fernzugriffen:

• TeamViewer auf einem Überwachungsrechner einer Wasseraufbereitungsanlage (Florida, 2021): Ein Angreifer hat über TeamViewer, das auf dem SCADA-System einer Trinkwasseraufbereitungsanlage installiert war, die Dosierwerte für die chemische Aufbereitung verändert. Der Angriff wurde vom Bediener in Echtzeit entdeckt, hätte jedoch unbemerkt bleiben können.
• VPN ohne MFA im Energiesektor: Es gibt mehrere dokumentierte Vorfälle, bei denen gestohlene VPN-Zugangsdaten den Zugriff auf regionale Stromnetze in Europa ermöglichten.
• Modbus-Portweiterleitung: Sicherheitsforscher haben wiederholt gezeigt, dass sie in der Lage sind, Parameter von industriellen Steuerungen zu ändern, auf die direkt über das Internet zugegriffen werden kann.

3. Offene Ports vs. ausgehender Tunnel: Der grundlegende Unterschied​

Architektur mit „offenem Eingangsport“​

[Internet] ──→ [Pare-feu usine : port ouvert] ──→ [Réseau OT] ──→ [Automate]

Dieses Modell stellt einen Zugangspunkt zum Internet bereit. Unabhängig davon, ob es sich um einen VPN-Port (UDP 1194 für OpenVPN, UDP 500/4500 für IPsec) oder einen Anwendungsport (502, 102, 443) handelt, wird dieser Port ständig überwacht.

Lebenszyklus eines exponierten Ports:

1. Öffnung des Ports → Erfassung durch Shodan innerhalb von 24–48 Stunden
2. Erste Scan-Versuche → einige Tage nach der Offenlegung
3. Automatisierte Ausnutzungsversuche → sobald eine bekannte Signatur identifiziert wird
4. Gezielte Ausnutzung → wenn die Installation als kritisch oder interessant eingestuft wird

Architektur „nur ausgehender Tunnel“​

[Réseau OT] ──→ [Gateway : connexion sortante] ──→ [Cloud] ←── [Opérateur]

Was sich grundlegend ändert:

• Die Verbindung wird von innen initiiert – genau wie bei einem Webbrowser
• Aus Sicht der Werks-Firewall: ausgehender HTTPS-Datenverkehr zu einer bekannten IP-Adresse
• Es müssen keine eingehenden Ports geöffnet und keine Firewall-Regeln geändert werden
• Keine exponierten Ports = keine Angriffsfläche für Netzwerkangriffe auf Seiten der Fabrik

Sollte die Eziwan-Cloud-Infrastruktur kompromittiert werden (hypothetisches Szenario), könnte ein Angreifer nicht weiter ins Werksnetzwerk vordringen – die Verbindung ist hinsichtlich der Initiierung unidirektional.

Warum TeamViewer nicht „so sicher“ ist wie OpenVPN​

TeamViewer nutzt zwar einen Cloud-Relay (keine direkte Verbindung des Angreifers zur Fabrik), doch die strukturellen Probleme sind andere:

4. Was die Norm IEC 62443 und die ANSSI dazu sagen​

IEC 62443 – die Referenznorm​

Die Norm IEC 62443 legt die Anforderungen an die Cybersicherheit für industrielle Systeme fest. Für den Fernzugriff schreibt die Sicherheitsstufe 2 (SL2) – die für die meisten Industrieanlagen empfohlene Stufe – Folgendes vor:

SR 1.1 – Identifizierung und Authentifizierung von Personen: Jeder Benutzer, der auf das System zugreift, muss individuell identifiziert und authentifiziert werden. Gemeinsame Konten (ein einziges „Wartungs“-Konto für das gesamte Team) sind ausdrücklich ausgeschlossen.

SR 1.7 – Erhöhte Authentifizierung (Enhancement SL2): Für den Fernzugriff auf SL2-Ebene ist eine Zwei-Faktor-Authentifizierung (MFA) erforderlich. Ein Passwort allein reicht nicht aus.

SR 2.6 – Zugriff über unzuverlässige Netzwerke: Jeder Zugriff vom Internet auf das OT-Netzwerk muss verschlüsselt, authentifiziert und protokolliert werden. Diese Anforderung entspricht normativ der Kombination aus ausgehendem Tunnel + MFA + Audit-Protokollen.

SR 6.2 – Kontinuierliche Überwachung: Fernzugriffe müssen kontinuierlich protokolliert werden – wer sich wann, von welcher Adresse aus und für wie lange angemeldet hat.

Empfehlungen der ANSSI​

Die ANSSI veröffentlicht spezifische Leitfäden für industrielle Systeme. Ihre fünf Grundsätze für den industriellen Fernzugriff lauten:

1. Trennung: Fernzugriffe dürfen nicht direkt über das OT-Netzwerk erfolgen – sie müssen über eine industrielle DMZ geleitet werden
2. Starke Authentifizierung: MFA ist für jeden Fernzugriff auf Geräte der Ebene 1 oder 2 obligatorisch
3. Verschlüsselung: Die gesamte Fernkommunikation muss mit aktuellen Verschlüsselungsalgorithmen verschlüsselt werden
4. Protokollierung: Vollständige, exportierbare und mit Zeitstempel versehene Protokolle, die mindestens 3 Monate lang aufbewahrt werden
5. Prinzip der geringsten Berechtigungen: Jeder Techniker hat nur Zugriff auf die Geräte in seinem Zuständigkeitsbereich

5. OpenVPN vs. IPSec vs. L2TP im industriellen Umfeld​

Nicht alle VPNs sind gleich gut geeignet für auf ARM-CPUs integrierte Gateways mit Einschränkungen hinsichtlich der Wiederverbindungsfähigkeit und des Speichers.

Detaillierte Vergleichsanalyse​

OpenVPN: Eziwans Standardwahl für integrierte Gateways​

Der entscheidende Punkt für den Industriekunden: die Durchquerung von Firewalls und die Wiederherstellung der Verbindung nach einem 4G-Ausfall. OpenVPN kapseln den Tunnel in TLS auf dem TCP-Port 443 – dem gleichen wie bei HTTPS –, wodurch er dort durchgelassen wird, wo andere Protokolle blockiert werden (Firewall des Netzbetreibers, Unternehmensproxy). In Kombination mit persist-tun wird der Tunnel nach einem Dual-SIM-Wechsel innerhalb weniger Sekunden wiederhergestellt, ohne dass eine vollständige Neuverhandlung erforderlich ist.

Jeder Techniker verfügt über ein eigenes X.509-Zertifikat, das über das Cloud-Dashboard individuell widerrufen werden kann – eine wichtige Anforderung für die Rückverfolgbarkeit gemäß NIS2.

IPSec (IKEv2) für Umgebungen, in denen dies erforderlich ist​

IPSec ist nach wie vor der Standard in Unternehmen und in regulierten industriellen Umgebungen, in denen FIPS 140-2-zertifizierte Protokolle vorgeschrieben sind. Sein MOBIKE-Mechanismus verwaltet den Wechsel der IP-Adresse nahezu transparent – besonders geeignet für Dual-SIM-Failover. Die Konfiguration ist zwar komplexer (PKI, X.509-Zertifikate, SA-Richtlinien), bietet jedoch maximale Interoperabilität mit bestehenden Netzwerkgeräten. Das Eziwan Gateway unterstützt zudem L2TP, PPTP und GRE für Fälle von Interoperabilität mit älteren Systemen.

6. Wie Eziwan das „Zero-Port-Exposed“-Konzept umsetzt​

Die Eziwan-Architektur wendet die oben genannten Prinzipien systematisch an:

Verbindungsarchitektur​

1. Das Gateway im Werk initiiert die OpenVPN-Verbindung zur Eziwan-Cloud-Infrastruktur über UDP 1194
2. Die Verbindung wird durch X.509-Zertifikate authentifiziert, die bei der Bereitstellung generiert wurden
3. Im Werksnetzwerk ist kein eingehender Port geöffnet
4. Der Betreiberzugang erfolgt über die Eziwan-Cloud mit integrierter MFA (TOTP oder Push-Benachrichtigung)
5. Jede Sitzung wird protokolliert: Benutzer, Zeitstempel, Dauer, durchgeführte Aktionen