IoT-Interoperabilität zwischen Herstellern

Ein Stromzähler und eine Gebäudeleittechnik (GLT) können beide Modbus TCP unterstützen und sich trotzdem über Registerbasis, Wortreihenfolge eines 32-Bit-Floats, Einheit und Vorzeichen der Einspeisung widersprechen. Die Verbindung steht, im Dashboard erscheint eine Zahl, aber sie ist falsch.

Wenn zwei Produkte dasselbe Protokoll, denselben Transport und zusammenpassende Rollen dokumentieren, gibt es einen Verbindungsweg. Dafür reicht die Bezeichnung protokollkompatibel. Ein allgemeiner Labortest muss das Gerätepaar nicht zuvor nachstellen. Alles Weitere ist Projektarbeit: Punktliste, Einheiten, Zeitstempel, Qualitätsregeln und Verhalten bei Verbindungsabbruch. Herstellerunterlagen belegen den möglichen Weg; die Inbetriebnahme belegt die Richtigkeit der installierten Messpunkte. Dokumentieren Sie beides getrennt.

Beispiel: Wirkleistung eines Zählers

Ein Zähler stellt die dreiphasige Wirkleistung bereit. Die GLT soll sie in kW anzeigen und für einen Lastalarm nutzen. Jeder der folgenden Fehler besteht dennoch eine einfache Prüfung „Wert lesbar“.

• Registerbasis. Die Registerliste nennt Register 3000 für FLOAT32. Sie zählt ab 1, daher steht im Telegramm die Adresse 2999. Ein Client, der 3000 sendet, liest das niederwertige Wort dieses Werts und das höherwertige Wort des nächsten.
• Wortreihenfolge. Der Client setzt die beiden Register in umgekehrter Reihenfolge zusammen. Die Dekodierung unten zeigt das Ergebnis.
• Einheit. Das Register enthält Watt, der GLT-Punkt ist mit kW beschriftet. So werden 42.700 W als 42.700 kW angezeigt.
• Messgröße. Das Register enthält die gesamte Scheinleistung in kVA, nicht Wirkleistung. Bei Leistungsfaktor 0,85 liegt der Wert ungefähr 18 % zu hoch.
• Vorzeichen. Der Zähler meldet Einspeisung negativ. Das Zielsystem behandelt jede Leistung als Bezug und setzt negative Werte auf null; die Einspeisung verschwindet.
• Doppelte Skalierung. Das Stromwandlerverhältnis 400/5 A ist bereits im Zähler konfiguriert; er meldet Primärstrom. Der Integrator multipliziert im Client nochmals mit 80.
• Zeit. Nach Wiederverbindung erhalten gepufferte Messwerte im Gateway dessen Eingangszeit statt der Messzeit. Alte Daten erscheinen aktuell.
• Veraltung. Das Zielsystem hält den letzten Wert ohne Veraltungskennzeichen. Der Lastalarm wird nie ausgelöst.
• Steuerung. Ein Schreibvorgang erhält eine Protokollbestätigung, doch das Gerät lehnt ihn ab, eine lokale Übersteuerung gewinnt oder das Gerät setzt den Wert später zurück.

Wert dekodieren

Ein IEEE-754-Float mit einfacher Genauigkeit für 42,7 besteht aus den vier Bytes 42 2A CC CD. Bei Übertragung des höherwertigen Worts zuerst steht 0x422A im ersten und 0xCCCD im zweiten Register. Die Byte- und Wortreihenfolge des Clients bestimmt das Ergebnis:

Ein extrem großer oder beinahe null liegender Wert deutet meist auf eine falsche Reihenfolge. Hersteller verwenden die ABCD-Bezeichnungen nicht einheitlich. Lesen Sie einen von null verschiedenen Wert, der auch auf dem Gerätedisplay sichtbar ist. Dekodieren Sie ihn in allen Reihenfolgen mit dem IEEE-754-Float-Konverter oder Modbus-Registerdekoder und dokumentieren Sie die passende.

Energiezähler haben zwei weitere Fallen. Ein UINT32-Zähler in Wh läuft bei 4.294.967.295 Wh über, ungefähr 4.295 MWh. Eine Dauerlast von 500 kW erreicht dies nach etwa 358 Tagen. Ein fallender Zählerstand muss als Überlauf oder Zählerreset behandelt werden, nicht als negativer Verbrauch. Ein FLOAT32-Zähler in kWh verliert bei wachsendem Stand an Auflösung. Bei 1.000.000 kWh beträgt die kleinste Stufe 0,0625 kWh. Ein Ein-Minuten-Delta bei 10 kW (0,167 kWh) erscheint dann als 0,125 oder 0,1875 kWh. Nutzen Sie ein Ganzzahlregister für Intervallenergie, wenn der Zähler eines anbietet.

Acht Ebenen der Interoperabilität

Die Ebenen überlappen sich. Ihre Trennung macht Lücken sichtbar.

Die W3C-Architektur für Web of Things trennt diese Themen. Eine Thing Description listet Interaktionen, Datenschemata, Protokollbindungen und Sicherheitsmetadaten eines Geräts in einer maschinenlesbaren Datei. Das senkt den Aufwand für gerätespezifische Erkennung. Der Verbraucher muss dennoch dieselbe Bindung unterstützen und die beschriebene Bedeutung richtig nutzen.

Was Protokolle offenlassen

Jedes Protokoll standardisiert einen Teil des Systems. Herstellerunterlagen und Projektkonfiguration bestimmen den Rest.

Modbus

Die Modbus Application Protocol Specification definiert Funktionscodes und vier Datentabellen: Coils, Discrete Inputs, Input Registers und Holding Registers. Sie legt nicht fest, welcher Wert an welcher Adresse liegt oder welchen Datentyp, Skalierungsfaktor und welche Wortreihenfolge er hat. Das steht in der Registerliste des Herstellers.

Die 4x-Schreibweise schafft eine Adressfalle. Referenz 40001 bezeichnet Holding Register 1 mit Adresse 0 in der Anfrage auf dem Draht. Manche Handbücher zählen Registernummern ab 1, andere Adressen ab 0; Clients erwarten ebenfalls unterschiedliche Konventionen. Edge erwartet die nullbasierte Adresse: Referenz 40001 wird als 0 eingegeben. Der Modbus-Adressumrechner übersetzt zwischen den Konventionen. Die Modbus-Funktions- und Ausnahmecodes helfen beim Dekodieren von Fehlerantworten.

Auch Schreibvorgänge haben Fallen. Funktionscode 06 schreibt ein Register, Funktionscode 16 mehrere Register in einer Anfrage. Zwei FC06-Anfragen für einen 32-Bit-Wert sind nicht atomar: Das erste Wort kann geschrieben werden und das zweite scheitern. Zurück bleibt ein halber Sollwert. Manche Geräte antworten normal auf einen Schreibvorgang, ignorieren oder begrenzen ihn danach aber. Lesen Sie das Zielregister nach jedem Schreiben zurück. Edge pausiert Live-Lesevorgänge auf derselben Verbindung standardmäßig zwei Sekunden nach einem Schreibvorgang, damit ein langsames Gerät den Wert vor dem Rücklesen übernehmen kann.

Bei RS-485 begrenzt die Buszeit die Anzahl der Punkte. Bei 9600 Baud und 11 Bit je Zeichen dauert Anfrage plus Antwort für einen Block mit 60 Registern ungefähr 160 ms auf dem Draht, noch ohne Antwortverzögerung des Geräts. Der Leitfaden zur RS-485-Inbetriebnahme rechnet einen vollständigen Abfragezyklus durch.

BACnet/IP

BACnet definiert Objekte und Eigenschaften. Die Wirkleistung eines Zählers erscheint als Present_Value eines Analog-Input-Objekts, daneben steht eine Units-Eigenschaft. Das beseitigt das Problem der Registerdekodierung. Andere Fragen bleiben: Welche Objektinstanz enthält welche Messgröße? Sind Geräteinstanzen im Netz eindeutig? Erreichen Discovery-Broadcasts (Who-Is auf UDP-Port 47808) andere Subnetze?

Ein BTL-Eintrag deckt Interoperability Building Blocks (BIBBs) und Objekttypen in seinem angegebenen Umfang ab. Er belegt nicht die Objektliste des tatsächlich installierten Geräts.

Bei der Steuerung nutzt BACnet ein Priority Array mit 16 Ebenen. Ein Schreibvorgang auf Priorität 8 bleibt wirksam, bis NULL auf Priorität 8 geschrieben wird, um ihn freizugeben. Vereinbaren Sie, welches System welche Priorität besitzt und wie es die Steuerung wieder freigibt.

MQTT

MQTT 5.0 definiert Topics, Nachrichteneigenschaften, Sitzungen und drei Quality-of-Service-Stufen (QoS). Es legt nicht fest, was ein Payload bedeutet. Zwei Systeme können MQTT unterstützen und sich dennoch über Topichierarchie, Schema, Punktkennung, Einheiten, Zeitstempel, Retain-Verhalten und Duplikate widersprechen.

QoS 1 stellt mindestens einmal zu. Geht eine Bestätigung verloren, sendet der Absender erneut und der Empfänger kann dieselbe Nachricht zweimal erhalten. QoS 2 stellt genau einmal zu, aber nur auf einer Strecke: Client zu Broker oder Broker zu Subscriber. Ein Subscriber mit niedrigerem abonniertem QoS erhält die niedrigere Stufe. Keine QoS-Stufe belegt, dass ein Messwert richtig war, dass aus jeder Messung eine Nachricht wurde oder dass die Datenbank sie genau einmal speicherte. Geben Sie im Payload Quellzeitstempel und Nachrichtenkennung oder Sequenznummer mit, damit der Empfänger Duplikate entfernen kann.

Sparkplug 3.0, als ISO/IEC 20237:2023 veröffentlicht, schließt einen Teil dieser Lücke bei industriellen Daten. Es definiert Topic-Namensraum, typisierten Binärpayload sowie Birth- und Death-Nachrichten. Ein Edge Node veröffentlicht eine NBIRTH-Nachricht mit allen Metriken, die er senden wird. Er registriert NDEATH als MQTT Will; beim Verbindungsabbruch veröffentlicht der Broker diese Nachricht. So erkennen Subscriber veraltete Werte. Einheiten, Vorzeichen und Anlagenidentität bleiben Sache des Projekts.

Transportsicherheit muss gesondert vereinbart werden. Siehe MQTTS, MQTT über TLS.

OPC UA

Der Vergleich von OPC UA, MQTT und Modbus erläutert die drei Protokolle; der Leitfaden zur Knotenidentität erklärt NodeIds und Namensräume.

OPC UA trägt mehr Kontext als ein Register oder eine beliebige Nachricht. Sein DataValue verbindet Wert, StatusCode, Quell- und Serverzeitstempel. Die beiden höchstwertigen Bits des StatusCode bestimmen Good, Uncertain oder Bad. Eine Variable kann auch ihre technische Einheit bereitstellen. Die empfangende Anwendung muss dennoch den richtigen Knoten wählen, den Status vor der Nutzung prüfen, den relevanten Zeitstempel behalten und den Umgang mit Uncertain und Bad festlegen.

Client und Server müssen außerdem Sicherheitsrichtlinie und Nachrichtenmodus vereinbaren, etwa Basic256Sha256 mit SignAndEncrypt, und gegenseitig ihren Anwendungszertifikaten vertrauen. Die Zertifikatsprüfung hängt von der Zeit ab: Eine falsche Uhr auf einer Seite verhindert den Sitzungsaufbau.

Zigbee und LoRaWAN

Zigbee-3.0-Zertifizierung bedeutet, dass ein Gerät einem Netz beitreten und Daten über die Zigbee Cluster Library austauschen kann. Sie bedeutet nicht, dass jeder Messwert einen Standardcluster nutzt. Ein Zähler kann Leistung über den Electrical-Measurement-Cluster (0x0B04) mit eigenen Multiplier- und Divisor-Attributen melden oder über einen herstellerspezifischen Cluster, den nur dessen Konverter dekodiert. Prüfen Sie vor dem Kauf Cluster und Attribute des Modells. Nutzen Sie den vom Gerät gemeldeten Multiplikator und Divisor, keine feste Konstante.

LoRaWAN standardisiert Funkverbindung, MAC-Schicht und Geräteaktivierung. Der Anwendungspayload ist ein eigenes Binärformat des Herstellers. Die Software zur Umwandlung der Bytes in Werte, der Codec, braucht einen Verantwortlichen, eine Version und Updates. Ändert ein Firmwareupdate das Payload-Format, bricht der Codec, obwohl der Network Server Uplinks weiterhin fehlerfrei zustellt. Das Gerät muss außerdem zu regionalen Parametern wie EU868 und zur Aktivierungsmethode des Standorts passen. Zigbee neben LoRaWAN einsetzen vergleicht die Netze.

Syntaktische und semantische Interoperabilität

Syntaktische Interoperabilität heißt, dass der Empfänger Daten lesen und zerlegen kann. Semantische Interoperabilität heißt, dass beide Seiten diesen Daten dieselbe Bedeutung geben.

Dieses JSON ist gültig:

{
  "point": "P_TOTAL",
  "value": 42.7,
  "unit": "kW",
  "time": "2026-09-19T10:15:00Z",
  "quality": "good"
}

Es ist kein vollständiger Vertrag. Dem Empfänger fehlen Standort, Anlage und Messgrenze hinter P_TOTAL. Er weiß nicht, ob der Wert ein Momentanwert oder Intervallmittel ist, ob positiv Bezug oder Einspeisung bedeutet oder wie good bestimmt wurde. time könnte Messzeit, Berechnungszeit oder Eingangszeit im Gateway sein. Auch Stromwandlerverhältnis und Berechnungsrevision fehlen.

ETSI SAREF ist eine Ontologie für dieses Problem; die Leitlinien stehen in ETSI EN 303 760. Jedes System behält sein Datenmodell und bildet es auf gemeinsame Konzepte ab. Ein Projekt muss SAREF nicht übernehmen, um das Verfahren zu nutzen: Definieren Sie jede Bedeutung einmal und bilden Sie dann jedes System darauf ab. Direkte Feldzuordnungen zwischen jedem Systempaar wachsen mit n(n−1)/2. Fünf Systeme brauchen zehn Abbildungen, zehn Systeme 45.

Zeit und Qualität

Legen Sie fest, wo jeder Zeitstempel entsteht. Halten Sie Messzeit und Eingangszeit getrennt; nach einem Ausfall können Stunden dazwischenliegen. OPC UA SourceTimestamp wird von der Quelle gesetzt und soll die letzte Änderung von Wert oder Status angeben. ServerTimestamp bezeichnet den Zeitpunkt, zu dem der Server den Wert empfing oder als korrekt kannte. Keiner kennzeichnet automatisch eine neue physische Messung oder den Datenbankeingang. Prüfen Sie die Zeitstempelbedeutung der Quelle und erhalten Sie sie bei der Nachlieferung; erfassen Sie die Eingangszeit getrennt.

Uhren driften. Eine Zähleruhr, die täglich zwei Sekunden vorgeht, liegt nach einem Monat eine Minute daneben. Damit können Messwerte nahe einer Grenze im falschen 15-Minuten-Intervall landen. Synchronisieren Sie alle Uhren, die Daten stempeln, mit derselben NTP-Quelle und messen Sie die Abweichung bei der Abnahme. Auch TLS- und OPC-UA-Zertifikatsprüfungen scheitern bei stark falscher Uhr; der Fehler sieht dann nach einem Sicherheitsproblem aus.

Definieren Sie eine Frischeregel am Zielsystem. Eine brauchbare Regel sind drei Meldeintervalle: Bei 60 Sekunden Intervall ist ein Wert nach mehr als 180 Sekunden veraltet. Verlassen Sie sich nicht nur auf die Quelle. Edge meldet ein Modbus-Gerät nach zwei ausgefallenen Abfragen als offline, jedoch frühestens nach fünf Minuten. Ein jede Sekunde abgefragter Punkt kann somit bis zu fünf Minuten alt sein, bevor Edge das Gerät kennzeichnet.

Künstlich erzeugte Werte brauchen ein Kennzeichen, das den gesamten Datenpfad überlebt. Edge kann kurze Lücken durch Wiederholung, null oder Interpolation füllen und markiert solche Punkte mit _synthetic: true. Eine nachgelagerte Datenbank, die unbekannte Felder verwirft, entfernt auch das Kennzeichen. Dann sehen ergänzte Werte wie Messungen aus. Lassen Sie Lückenfüllung für Abrechnung, Alarme und Steuerung ausgeschaltet.

Konformität, Zertifizierung und Projektabnahme

Jede Art von Nachweis beantwortet eine andere Frage.

NISTs Smart Grid Interoperability Framework behandelt Konformitäts- und Interoperabilitätstests als Ergänzungen. Das oneM2M-Format für Interoperabilitätstests verlangt für jeden Test Konfiguration, Anfangszustand, Ereignisfolge und erwartete Ergebnisse. Verwenden Sie dieselben vier Überschriften für Standorttests.

Angaben für die Beschaffung

Lassen Sie jeden Lieferanten oder Integrator dieselbe Liste ausfüllen, bevor Geräte bestellt werden.

Kennzeichnen Sie eine unbekannte Antwort als unbekannt. Ein leeres Feld wird auf der einen Seite leicht zur Annahme und auf der anderen zur vermeintlichen Zusage.

Abnahme in zwölf Schritten

Nutzen Sie exakt die Hardware, Firmware, Schnittstellenunterlagen und Zielanwendung des Projekts. Erfassen Sie Rohdaten an der Quelle, jedem Zwischensystem und am endgültigen Ziel.

1. Dokumentieren Sie Identität und Konfiguration: Modell, Seriennummer, Firmware, Revision der Schnittstellenunterlagen, Gateway- und Edge-Versionen, Connector-Version und Konfigurationsfingerabdruck.
2. Belegen Sie den physischen Pfad. Prüfen Sie Verdrahtung und Topologie sowie serielle und Netzeinstellungen. Zeigen Sie, dass die vorgesehenen Endpunkte kommunizieren.
3. Verfolgen Sie jeden Zielpunkt zurück zum Quellregister, Objekt, Kanal oder zur Nachricht und zum physischen Anlagenetikett.
4. Prüfen Sie die Kodierung. Lesen Sie für jeden Punkt zwei bekannte, von null verschiedene Werte. Vergleichen Sie Registerbasis, Datentyp, Vorzeichen, Byte- und Wortreihenfolge, Skalierung und Aufzählungswerte.
5. Prüfen Sie die Bedeutung. Bestätigen Sie Einheit, Richtung, Messgrenze und Berechnung gegen ein Referenzgerät oder eine kontrollierte Quelle.
6. Prüfen Sie die Zeit. Vergleichen Sie Uhren und erzeugen Sie eine bekannte Verzögerung. Nachgelieferte Daten dürfen nicht aktuell erscheinen.
7. Prüfen Sie Qualitäts- und Veraltungszustand. Erzeugen Sie Quellenfehler, ungültigen Wert und ausbleibende Aktualisierung. Die Zielanwendung muss alle drei von einer gültigen null unterscheiden.
8. Prüfen Sie erlaubte Schreibvorgänge: Autorisierung, Grenzen und Verriegelungen. Protokollieren Sie Anfrage, Protokollantwort, beobachtete Gerätewirkung und endgültig gemeldeten Zustand.
9. Unterbrechen Sie jede Verbindung. Trennen Sie Feld- und Weiterleitungsverbindung getrennt. Erfassen Sie Ausfallerkennung, Behandlung des letzten Werts, Pufferung, Alarme und lokales Verhalten.
10. Stellen Sie jede Verbindung wieder her, innerhalb und außerhalb des Pufferfensters. Prüfen Sie Reihenfolge, Duplikate, Lücken, Energiezählerdifferenzen über die Lücke und Rücknahme des Veraltungszustands.
11. Starten Sie jede Komponente einzeln neu und stellen Sie sie anschließend aus der dokumentierten Sicherung wieder her. Prüfen Sie Identitäten, Punktzuordnungen, Uhren, Zugangsdaten und gepufferte Daten.
12. Spielen Sie eine genehmigte Firmware- oder Konfigurationsänderung ein und wiederholen Sie die betroffenen Prüfungen. Schlagen sie fehl, machen Sie die Änderung rückgängig.

Der Abnahmenachweis für jeden Pfad nennt Modell, Firmware, Konfigurationsrevision, Zielanwendung und Version, bestandene Punkte und Fälle, ungeprüfte Optionen, Datum, beobachtende Person und die für jede Abweichung zuständige freigebende Person. Ändern sich später Version, Profil, Punktliste oder Sicherheitsanforderungen, ist damit klar, welche Prüfungen zu wiederholen sind.

Beispiel: PowerLogic PM5000 an Edge

Schneider Electric dokumentiert die Schnittstellen der PM5000-Familie modellbezogen in den Familienunterlagen. PM5110 und PM5330 besitzen RS-485 mit Modbus RTU. PM5560 bietet zusätzlich Ethernet mit Modbus TCP. BACnet/IP ist laut Schneiders BACnet/IP-Hinweis beim PM5560 und PM5563 ab Firmware 2.3.0 verfügbar. Schneider stellt getrennte Modbus-Registerlisten für PM51xx und PM53xx sowie für PM55xx, PM56xx und PM57xx bereit.

Der PM5000-Geräteleitfaden nennt drei Wege zu Edge:

1. Modbus RTU: Verbinden Sie ein RS-485-Modell mit einem ZMB-31. Er arbeitet als Modbus-RTU-Master bei 300 bis 115.200 Baud und liest bis zu 30 Register. Die Werte sendet er über das Zigbee-Mesh; eine Datenleitung bis zum Gateway ist nicht nötig.
2. Modbus TCP: Verbinden Sie ein Ethernet-Modell mit dem Standortnetz. Konfigurieren Sie Edge als Modbus-Client mit IP-Adresse des Zählers, Port 502 und Unit Identifier.
3. BACnet/IP: Konfigurieren Sie bei PM5560 oder PM5563 ab Firmware 2.3.0 den BACnet/IP-Client von Edge, damit er den Zähler erkennt und dessen Objekte liest.

Nehmen Sie zuerst einen Punkt in Betrieb. Dokumentieren Sie vollständige Artikelnummer und Firmware. Wählen Sie die Registerliste für diesen Bereich und prüfen Sie, ob sie einbasierte Registernummern oder nullbasierte Adressen enthält. Ordnen Sie die gesamte Wirkleistung als FLOAT32 zu, lesen Sie sie unter Last und vergleichen Sie mit dem Gerätedisplay. Bei Einspeisung prüfen Sie das Vorzeichen. Danach ergänzen Sie die restlichen Punkte und legen Abfrageintervall und Veraltungsregel für die gesamte Punktliste fest.

Wo das Device Directory für ein Modell ein Edge-Gerätetemplate nennt, ist die Punktliste bereits erstellt. Sonst leitet der Integrator sie aus der Herstellerregisterliste ab.

Interoperabilität bei Steuerbefehlen

Bei Überwachung endet die Abnahme mit einem richtigen, aktuellen Wert am Ziel. Bei Steuerung müssen Sie nach jedem Schreibvorgang zusätzlich den Gerätezustand bestätigen.

Ein Befehl durchläuft diese Stufen:

1. Eine berechtigte Person oder ein berechtigtes System erzeugt einen Befehl mit Kennung, Ziel, Wert und Ablaufzeit.
2. Die Steuerung prüft Bereich, Modus, Verriegelungen und aktuelle Befugnis.
3. Die Steuerung sendet den Protokoll-Schreibvorgang.
4. Das Gerät bestätigt, lehnt ab oder antwortet nicht rechtzeitig.
5. Rücklesen oder eine unabhängige Prozessmessung zeigt, ob die beabsichtigte Wirkung eingetreten ist.
6. Das System protokolliert jede spätere Übersteuerung, Ablösung oder verlorene Befugnis.
7. Ist die anfordernde Seite nicht verfügbar, gilt ein definierter lokaler Zustand.

Ein erfolgreicher TCP-Aufruf, eine MQTT-Veröffentlichung oder eine Modbus-Antwort belegen nicht den beabsichtigten Anlagenzustand. Edge meldet bei einem Modbus-Schreibvorgang die Protokollbestätigung und liest den Wert nicht selbst zurück. Die Integration muss das Rücklesen übernehmen. Bei BACnet sind zusätzlich Priorität und Freigabeverfahren wie oben beschrieben zu vereinbaren.

Sicherheits-, Schutz- und Geräteschutzfunktionen brauchen eine eigene qualifizierte Auslegung. Übertragen Sie sie nicht an einen Überwachungspfad.

Offene Standards und Herstellerbindung

Ein MQTT-Feed ist auf Transportebene offen. Hat er einen undokumentierten Binärpayload oder Topics mit Anlagenkennungen, die nur die Cloud des Lieferanten auflösen kann, muss ein neuer Anbieter die Punktliste neu erschließen. Ein offenes Protokoll mindert die Bindung an einen Anbieter nur, wenn der Käufer zusätzlich erhalten und wiederverwenden kann:

• die vollständige Punkt- und Objektliste;
• Protokoll- und Profilkonfiguration;
• Zertifikate, Identitäten und Verfahren zur Erneuerung von Zugangsdaten;
• Daten- und Ereignisexporte mit Einheiten, Zeitstempeln und Qualität;
• Regeln, Berechnungen und semantische Zuordnungen in dokumentierter Form;
• Sicherungen mit geprüftem Wiederherstellungsverfahren; und
• Support- und Sicherheitsupdatebedingungen für die Lebensdauer der Anlage.

Ein projektspezifischer Adapter kann leicht wartbar sein, wenn Eingabe, Ausgabe, Tests und Verantwortliche dokumentiert sind.

NIST IR 8259 Rev. 1, veröffentlicht im April 2026, erwartet von Herstellern Sicherheitsfunktionen und Informationen, die Kunden zu deren Nutzung brauchen. Halten Sie das Ende der Firmwarepflege und das Verfahren für die Erneuerung von Zugangsdaten je Komponente in der Beschaffungsliste fest. Ohne neue Firmware bleiben bekannte Schwachstellen offen. Läuft ein Zertifikat ohne Erneuerungsverfahren ab, endet die Verbindung an diesem Tag.

EpiSensor-Hardware und Edge

EpiSensor-Sensoren melden über Zigbee an den ZGW-20 Gateway mit Edge. Für Geräte anderer Hersteller übernimmt Edge diese Rollen:

Nachgelagerte Datenflüsse veröffentlichen ausgewählte Punkte über MQTTS oder HTTPS oder schreiben sie in Dateien. Daten und Regeln bleiben auf dem Gateway verfügbar, wenn die Internetverbindung ausfällt.

Beginnen Sie mit dem Leitfaden zur Integration von GLT, SCADA und Zählern. Bringen Sie dann die ausgefüllte Beschaffungsliste und aktuelle Schnittstellenunterlagen zum System Builder oder zu einer technischen Anfrage mit.