Protokolle und Daten

BACnet COV, Polling und Datenaktualität

Wie BACnet-COV-Abonnements und Polling sich unterscheiden: COV-Inkrement, Laufzeit und Erneuerung, Netzlast und Prüfung, ob ein Wert noch aktuell ist.

Ein BACnet-Client erhält Werte auf zwei Arten. Bei Polling liest er sie nach eigenem Zeitplan mit ReadProperty oder ReadPropertyMultiple. Bei Change of Value (COV) bittet er das Gerät, bei einer Änderung ab einem festgelegten Betrag eine Meldung zu senden. Die Wahl beeinflusst Netzlast, Meldeverzögerung und die Bedeutung ausbleibender Nachrichten.

Dieser Leitfaden gehört zur Reihe über BACnet und Gebäudeprotokolle.

So funktioniert COV

Ein Client sendet SubscribeCOV für ein Objekt im Gerät. Die Anfrage nennt eine Kennung des abonnierenden Prozesses, wählt bestätigte oder unbestätigte Meldungen und gibt eine Laufzeit in Sekunden an. Anschließend sendet das Gerät eine Meldung mit Present_Value und Status_Flags:

  • einmal beim Annehmen des Abonnements, damit der Client einen ersten Wert hat;
  • bei einem Analogobjekt, wenn sich Present_Value seit der letzten Meldung um mindestens sein COV_Increment geändert hat;
  • bei einem Binär- oder Multi-State-Objekt bei jeder Zustandsänderung;
  • wenn sich Status_Flags ändern, etwa bei Alarm oder Außer-Betrieb-Status.

Nehmen wir ein Inkrement von 0,5 °C und einen zuletzt gemeldeten Wert von 20,0 °C. Messwerte von 20,2 °C und 20,4 °C lösen nichts aus; bei 20,6 °C folgt eine Meldung. Obwohl jeder einzelne Schritt nur 0,2 °C betrug, vergleicht das Gerät mit dem zuletzt gemeldeten Wert, nicht mit der vorherigen Messung. Langsame Drift wird also gemeldet, sobald sie sich zum Inkrement summiert. Eine kleinere Änderung bleibt ungemeldet. Der Client kann dadurch beliebig lange einen Wert halten, der fast 0,5 °C vom tatsächlichen Wert abweicht.

SubscribeCOVProperty abonniert eine einzelne Eigenschaft und erlaubt dem Client ein eigenes Inkrement. Damit können Sie eine andere Eigenschaft als Present_Value, etwa High_Limit, beobachten oder COV_Increment des Objekts übersteuern, ohne den Controller zu beschreiben.

Das Inkrement bestimmt auch die Netzlast. Tastet ein Controller einen verrauschten Analogeingang jede Sekunde ab und ist das Inkrement 0,01, kann er jedem Abonnenten jede Sekunde eine Meldung senden: 3.600 pro Stunde für einen Punkt. Newmans Bericht über das Cornell-Campusnetz nennt ein zu kleines Inkrement als einen der Controllerfehler, deren Auswirkungen Cornell durch die Trennung der Gebäudenetze vom zentralen Verkehr begrenzt.

Bestätigte und unbestätigte Meldungen

Eine bestätigte Meldung erfordert eine Quittung des Clients. Bleibt sie während des APDU-Timeouts des Geräts aus, wiederholt das Gerät die Meldung bis zur eingestellten Höchstzahl. Eine unbestätigte Meldung wird nur einmal gesendet. Verwirft ein Router sie oder ist der Client beschäftigt, geht die Änderung verloren, ohne dass eine Seite es merkt.

Nutzen Sie bestätigte Meldungen für Alarme und Anlagenzustände. Die Quittung kostet eine kurze Nachricht je Änderung. Unbestätigte Meldungen eignen sich für schnell wechselnde Analogwerte, bei denen die nächste Änderung eine verlorene ersetzt, aber nur mit einer Kontrollabfrage (siehe Was Stille bedeutet).

Laufzeit und Erneuerung

Die Laufzeit gibt an, wie lange das Gerät ein Abonnement ohne Erneuerung hält. Der Client erneuert es durch dieselbe SubscribeCOV-Anfrage vor Ablauf. Üblicherweise ist die Laufzeit eine Client-Einstellung. Bei Beckhoff TF8020 heißt sie im Einstellungsdialog „Subscriptions Lifetime“.

Versuchen Sie die Erneuerung nach der halben Laufzeit und wiederholen Sie einen fehlgeschlagenen Versuch vor Ablauf. Bei einer Laufzeit von 600 s lässt ein Versuch nach 300 s Zeit für einen weiteren Versuch; wer nach einem verlorenen Versuch bis 600 s wartet, erreicht bereits die Ablaufgrenze. Die Richtlinien der BACnet Testing Laboratories (BTL) verlangen, dass jeder COV-Server Laufzeiten von 1 bis 28.800 s (8 Stunden) akzeptiert; Werte in diesem Bereich sollten daher nicht abgewiesen werden (Abschnitte 7.24 und 7.25).

Laufzeit 0 bedeutet ein unbegrenztes Abonnement. Verwenden Sie sie nicht. BTL-Abschnitt 7.6 nennt die Gründe: Ein Gerät muss seine Abonnementliste bei Reset oder Stromausfall nicht behalten; ein ausgetauschter Controller beginnt mit leerer Liste; ein entfernter Client würde seinen Eintrag sonst für immer belegen. SubscribeCOVProperty erlaubt Laufzeit 0 nicht.

Abonnementplätze sind begrenzt. Der Standard verlangt von einem COV-Server nur fünf gleichzeitige Abonnements (BTL-Abschnitt 7.7 mit Verweis auf ASHRAE 135, K.1.12 und K.1.13). Der quelloffene BACnet Stack reserviert standardmäßig 128. Ist die Tabelle voll, schlägt eine Abonnementanfrage fehl; im BACnet Stack lautet die Fehlerklasse RESOURCES und der Code NO_SPACE_TO_ADD_LIST_ELEMENT. Die Eigenschaft Active_COV_Subscriptions des Device-Objekts listet die vom Gerät gehaltenen Abonnements. Lesen Sie sie bei der Inbetriebnahme, um bereits belegte Plätze der BMS-Zentrale und anderer Clients zu erkennen.

Ein fehlgeschlagenes Abonnement darf nicht unbemerkt bleiben. BTL-Abschnitt 7.7 sieht vor, diesen Punkt stattdessen abzufragen, den Bediener zu informieren oder beides zu tun.

Polling und COV im Vergleich

PollingCOV
Wer jede Nachricht beginntClient nach ZeitplanGerät bei Wertänderung
Verkehr bei konstantem WertAnfrage und Antwort in jedem IntervallNur Erneuerungen, etwa ein Austausch alle 300 s
Zeit bis zur Meldung einer ÄnderungBis zu einem Abfrageintervall plus LesezeitCOV-Abtastzyklus des Geräts plus Übertragung; bei MS/TP auch Wartezeit auf das Token
Kleine ÄnderungenBei jeder Abfrage sichtbarUnsichtbar, bis sie sich zum Inkrement summieren
Erforderliche UnterstützungReadProperty, das jedes BACnet-Gerät ausführen mussSubscribeCOV in Gerät und Client
Belegte Ressourcen im GerätKeineEin Platz je Punkt und Client; fünf sind das geforderte Minimum
Nach GeräteneustartNächste Abfrage funktioniertAbonnements können verloren sein; sie kehren bei der nächsten Erneuerung zurück
Nachweis aktueller DatenZeitstempel jeder erfolgreichen AbfrageLetzte Erneuerung, letzte Meldung und Kontrollabfrage

Abfragebudget auf MS/TP

Bei BACnet/IP sind einige Hundert Punkte einmal pro Minute nur eine geringe Last. Auf MS/TP müssen Sie rechnen. MS/TP sendet 10 Bit je Oktett. Eine ReadProperty-Anfrage für Present_Value eines Analogeingangs umfasst in ihrem MS/TP-Frame etwa 23 Oktette; die Antwort mit einem REAL-Wert etwa 29. Bei 38.400 Bit/s sind das rund 14 ms pro Punkt, noch ohne Umkehrpausen, Antwortverzögerung des Controllers und Tokenumlauf zwischen den anderen Mastern.

Berechnen Sie die Lesevorgänge pro Sekunde, bevor Sie ein Intervall festlegen. 300 Punkte alle 60 s bedeuten fünf Lesevorgänge pro Sekunde oder etwa 70 ms Sendezeit je Sekunde. 300 Punkte alle 5 s bedeuten 60 Lesevorgänge pro Sekunde, etwa 0,8 s Sendezeit je Sekunde. Dann bleibt kaum Raum für den eigenen Verkehr der Controller. ReadPropertyMultiple überträgt mehrere Punkte in einem Austausch, wenn das Gerät es unterstützt, und reduziert den Aufwand pro Punkt. Der Vergleich von BACnet/IP und MS/TP erklärt Tokenumlauf und Baudraten.

Was Stille bedeutet

Bei Polling ist ein fehlgeschlagenes Lesen sichtbar: Die Anfrage läuft in einen Timeout. Bei COV hat Stille zwei Bedeutungen. Der Wert kann unverändert sein. Oder das Abonnement ist nach Neustart, Ablauf oder Verlust einer Meldung nicht mehr wirksam. Konstanter Wert und totes Abonnement sehen gleich aus.

Halten Sie für jeden COV-Punkt drei Zeitstempel fest:

  1. Letzte Änderung: wann sich der Wert zuletzt verändert hat.
  2. Letzte Nachricht: wann zuletzt eine Meldung oder erfolgreiche Abfrage einging.
  3. Letzte Erneuerung: wann ein SubscribeCOV für den Punkt zuletzt bestätigt wurde.

Lesen Sie jeden COV-Punkt alle 15 Minuten zur Kontrolle. Weicht die Abfrage vom zuletzt gemeldeten Wert um mindestens das Inkrement ab, ist eine Meldung verloren gegangen: Abonnieren Sie erneut und melden Sie einen Fehler. Markieren Sie den Punkt als veraltet, wenn die letzte Erneuerung länger als die Laufzeit zurückliegt oder die letzte Nachricht älter ist als das Kontrollintervall plus eine Minute. Bei 600 s Laufzeit und 15 Minuten Kontrollintervall sind das 600 s und 960 s. Der Leitfaden zu veralteten Daten erklärt die Darstellung und Behandlung nicht mehr aktueller Werte.

Auch Polling braucht Prüfung in anderer Form. Ein Scheduler, der jede Minute startet, belegt noch nicht, dass jede Minute ein gültiger Wert ankommt. Messen Sie die Zeit zwischen erfolgreichen Lesevorgängen.

Je Punkt entscheiden

PunktÜbliche Wahl
Energie und Leistung für Analysen alle 1 bis 15 MinutenIm Analyseintervall abfragen, mit der Uhr synchronisiert
Raumtemperaturen für KomfortberichteAlle 5 Minuten abfragen oder COV mit einem Inkrement von 0,2 bis 0,5 °C
Anlagenstatus und Alarme, die binnen Sekunden eintreffen müssenCOV mit bestätigten Meldungen, 600 s Laufzeit, Erneuerung alle 300 s und Kontrollabfrage alle 15 Minuten
Viele Punkte auf einem MS/TP-BusNur benötigte Punkte abfragen, mit ReadPropertyMultiple, wenn unterstützt, oder von der BMS-Zentrale auf BACnet/IP lesen

Testen Sie die Wahl vor Ort anhand des Client-Protokolls und des eigenen Controllertrends:

  1. Halten Sie den Punkt 30 Minuten konstant. Bestanden: Erneuerungen werden alle 300 s bestätigt, es kommen keine Meldungen und Kontrollabfragen stimmen mit dem letzten Wert überein.
  2. Erzeugen Sie eine Änderung unterhalb des Inkrements. Bestanden: keine Meldung; die nächste Kontrollabfrage zeigt den neuen Wert.
  3. Erzeugen Sie eine Änderung oberhalb des Inkrements. Bestanden: eine Meldung. Dokumentieren Sie die Zeit von der Änderung bis zum Eingang als Standortlatenz.
  4. Starten Sie den Controller neu. Bestanden: Meldungen laufen innerhalb eines Erneuerungsintervalls wieder; sonst erscheint der Punkt als veraltet.
  5. Starten Sie den Client neu. Bestanden: Er abonniert erneut, bevor er einen Punkt als aktuell markiert.
  6. Lesen Sie Active_COV_Subscriptions. Bestanden: Das Gerät hält die erwarteten Abonnements und hat freie Plätze.

Polling mit Edge

Edge auf dem ZGW-20 Gateway liest BACnet/IP durch Abfragen von Present_Value. Es abonniert kein COV. Jeder Punkt läuft nach einem an der Uhr ausgerichteten Zeitplan, etwa alle 60 oder 300 Sekunden, oder im Live-Modus, der ebenfalls einmal pro Minute liest. Jeder erfolgreiche Lesevorgang hat einen eigenen Zeitstempel. Ein fehlgeschlagener Lesevorgang erzeugt keinen neuen Wert; ein ausgefallener Controller erscheint als Lücke. Edge verbindet sich nicht direkt mit MS/TP. Lesen Sie solche Controller über einen BACnet/IP-Router oder die BMS-Zentrale. Fragen Sie Energie- und langsam wechselnde Umgebungswerte so ab; Alarme, die binnen Sekunden ankommen müssen, bleiben beim BMS.

Häufige Fragen

Was bedeutet COV bei BACnet?

Change of Value: Ein Client abonniert ein Objekt. Das Gerät meldet, wenn sich Present_Value seit der letzten Meldung mindestens um COV_Increment ändert oder Status_Flags wechseln. Bei selten veränderten Punkten ersetzt das wiederholte Abfragen.

Was ist ein COV-Inkrement?

Die Mindeständerung von Present_Value eines Analogobjekts, die eine COV-Meldung auslöst. Bei 0,5 °C und einem zuletzt gemeldeten Wert von 20,0 °C lösen 20,2 und 20,4 °C nichts aus; 20,5 °C oder mehr lösen eine Meldung aus. Binär- und Multi-State-Objekte melden jede Zustandsänderung.

Wie lange sollte ein COV-Abonnement gelten?

Nutzen Sie eine endliche Laufzeit und erneuern Sie nach etwa der Hälfte, zum Beispiel 600 s Laufzeit mit Erneuerung alle 300 s. BTL verlangt von COV-Servern die Annahme jeder Laufzeit von 1 bis 28.800 s. Laufzeit 0 bedeutet unbegrenzt; die BTL-Richtlinien raten Clients davon ab.

Ist COV besser als Polling?

Bei seltenen Änderungen reduziert COV den Verkehr und meldet Zustandswechsel schnell. Es erfordert Unterstützung in Gerät und Client, belegt einen Abonnementplatz und braucht Erneuerung sowie Kontrollabfragen. Polling ist einfacher und liefert für jedes Intervall einen Zeitstempel.