Metering-Daten per Drahtlosnetzwerk übertragen DLMS über ZigBee

Als eines der gängigsten Smart-Metering-Protokolle unterstützt DLMS mit »Power Line Communication«, serieller Kommunikation und IP-Kommunikation drei verschiedene Kommunikationsmedien. In Entwicklungsländern mit mangelnder Stromnetzqualität ist PLC jedoch keine brauchbare Option. ZigBee bietet hier durch einen Tunneling-Mechanismus einen alternativen Kommunikationskanal für DLMS-Protokolldaten.

Getrieben durch Regulierungsaktivitäten und kommerzielle Faktoren unterliegt der Energieversorgungssektor massiven Veränderungen. Weltweit haben sich Regierungen verpflichtet, die Emissionen bis 2020 deutlich zu reduzieren – und dazu können Smart-Grid-Techniken einen wesentlichen Beitrag leisten, denn sie verbessern den Wirkungsgrad innerhalb eines Versorgungsnetzes, eröffnen neue Umsatzquellen und bieten besseren Kundenservice. Kein Wunder also, dass die flächendeckende Verbreitung von Smart Metern und die »Advanced Metering Infrastructure« (AMI), welche die Anbindung und den bidirektionalen Datenfluss unterstützt, als eine der meistversprechenden Domänen für die Modernisierung des Energiesektors gelten.

Triebfeder für den prognostizierten Anstieg der Zahl weltweit installierter Smart Meter von 93 Mio. in 2013 auf mehr als 450 Mio. bis 2018 sind die Informationen, die ein Smart Meter zum Energieverbrauch zur Verfügung stellt. Eine Verarbeitung dieser Informationen nahezu in Echtzeit kann wertvolle Einblicke bieten – Smart Meter, die beispielsweise jede Minute den Verbrauch erfassen, können dabei helfen, die größten Energiefresser schnell zu identifizieren.

Dieser Beitrag stellt das beliebte Smart-Metering-Protokoll DLMS (Device Language Message Specification) vor und untersucht anschließend dessen bestehende Kommunikationsmechanismen.

Er stellt einige inhärente Vorteile heraus, die der Drahtlos-Kommunikationsstandard ZigBee für die Smart-Meter-Kommunikation bieten kann, diskutiert im Detail den Einsatz von »ZigBee Generic Tunneling Cluster« (CTG) für die Übertragung von DLMS-PDUs (Protocol Data Units, Protokolldateneinheiten) über ein ZigBee-Netzwerk und schließt mit einer kurzen Untersuchung, wie sich ein DLMS-spezifischer Tunneling-Cluster als eine Erweiterung des Smart-Energy-Profils (SEP) erzeugen lässt.

Metering-Standard DLMS

Bei DLMS handelt es sich um ein objektorientiertes Metering-Protokoll für Energie wie Elektrizität, Gas und Wärme. Die Kommunikation mit dem Metering-Equipment verwendet den Client/Server-Ansatz, dabei spielt das Metering-Equipment die Rolle des Servers und bietet der Client-Anwendung Remote-Services durch den Austausch von Nachrichten. DLMS ist ein internationaler Standard, der von der DLMS User Association (DLMS/UA [2]) gepflegt wird und zweifach standardisiert ist, sowohl unter den »DLMS Colored Books« als auch in den IEC-62056-Protokollstandards [3].

IEC 62056 und DLMS sind nicht das Gleiche – die IEC-62056-Familie umfasst weitere Protokolle wie zum Beispiel 62056-31 (EURIDIS), 62056-21 usw. Die DLMS/UA umfasst etwa 200 Mitglieder aus fast 50 Ländern und arbeitet eng mit internationalen Normungskomitees wie IEC und CEN [4] zusammen.

Den grundlegenden Systemüberblick eines DLMS-kompatiblen Systems zeigt Bild 1.

Wie dort dargestellt, sind Smart Meter mit einem Meter-Datenkonzentrator (MDC) verbunden. Sie kommunizieren über verschiedene Kommunikationskanäle wie GPRS, GSM, HDLC/optisch oder PLC (Bild 2): 

  • serielle Kommunikation: RS-232/485, 
  • PLC-Kommunikation: Power-Line-Träger, 
  • IP-Kommunikation: Ethernet, GPRS und PPP, 
  • zukünftige Kommunikationsmedien. 

Der MDC kommuniziert wiederum mit einem Meter- Datenmanagementsystem (MDM). Dieses MDM ist der AMI-Unterprozess, der Meter-Daten validiert, editiert, abschätzt, an einer zentralen Stelle in einer Meter-Datenbank abspeichert und sie im jeweils erforderlichen Format an übergeordnete Systeme der Energieversorger zur Rechnungsstellung, für das Netzmanagement usw. weiterleitet.

DLMS verwendet COSEM-Objekte (Companion Specifications for Energy Metering) in den PDUs. COSEM beinhaltet einen Satz von Spezifikationen, der die Transport- und die Anwendungsschicht des DLMS-Protokolls definiert. Mithilfe der COSEM-Spezifikation werden die Smart-Energy-Zähler modelliert. Das DLMS-Protokoll ist kompatibel zur OSI-Modellarchitektur; wie in Bild 3 gezeigt, sind die Client- und die Serveranwendung auf unterschiedlichen Geräten lokalisiert. Nur die Anwendungsschicht verwendet COSEM-Objekte, alle anderen Protokollschichten sind vom COSEM-Modell unabhängig. Damit lässt sich die COSEM-Anwendungsschicht oberhalb einer breiten Vielfalt von niedrigeren Protokollschicht-Stacks platzieren. Also lässt sich ZigBee zusätzlich zu den Standard-Kommunikationskanälen – HDLC-basierte Sicherungsschicht, IPv4-Netzwerk und PLC – für den Austausch zwischen Client und Server einsetzen.

Als Teil der DLMS-APDU (Application Protocol Data Unit, Protokolleinheit auf Anwendungsebene) dienen die COSEM-Objekte dem Austausch von Nachrichten für die Bereitstellung von Diensten an den DLMS-Server/Client. Die DLMS-APDU hat ein sehr einfaches Format und wird nur in der Anwendungsschicht verwendet. Sie ist einfach zu erstellen und lässt sich problemlos mithilfe des darunterliegenden Kommunikationskanals übertragen. Die APDU-Struktur für verschiedene Dienste/Anfragen wie »Get/Set/Execute« in DLMS ist unterschiedlich.

Nachfolgend wird die PDU-Struktur für den »Get«-Dienst mit »Logical Name Referencing« in Smart Metern näher erklärt. »Get« liest den Wert eines oder mehrerer COSEM-Interface-Objektattribute und liefert das Ergebnis entweder in einer einzelnen Antwort zurück oder – falls es für eine einfache Antwort zu lang ist – in mehrfachen Antworten mit Blockübertragung.

Bild 4 zeigt ein Beispiel einer Get-PDU-Struktur. Wie im Bild dargestellt, enthält die PDU die folgenden Parameter: 

  • Invoke_Id: Bezeichnet die Instanz des Dienstaufrufs. 
  • Priority: Gibt die mit der Instanz des Dienstaufrufs verbundene Prioritätsebene an. Der Wert kann normal (FALSE) oder high (TRUE) sein. 
  • Request_Type: Bezeichnet den Übertragungstyp. 
  • COSEM_Attribute_Descriptor: Bezeichnet das im Datenmodell einmalige COSEM-Objekt. Spezifiziert den OBIS-Code (Object Identification System) und den abzurufenden Attributindex. 

In der Praxis werden Invoke_Id und Priority allerdings selten in Smart Metern angewandt. Analog lassen sich die PDUs für andere Aktionen und Dienste im von der DLMS Association veröffentlichten »Green Book« [5] finden. Die Übertragung dieser PDUs über ZigBee kann in AMI-Netzwerken von erheblichem Nutzen sein.

ZigBee-Smart-Energy- Profil

Auf Basis des Kurzstreckenfunk-Protokollstacks gemäß dem IEEE-Standard 802.15.4 hat die ZigBee Alliance eine Spezifikation entwickelt, um drahtlose Ad-hoc-Netzwerke aus Low-Power- und Low-Cost-ZigBee-Bausteinen aufzubauen. Jeder ZigBee-Knoten kann Daten über eine kurze Distanz übertragen. Aus mehreren ZigBee-Bausteinen entsteht ein vermaschtes Netzwerk (Mesh Network), so kann das Netzwerk Daten durch Routing- und Sprungmechanismen über weite Distanzen übertragen. In einem Netzwerk gibt es drei Arten von ZigBee-Geräten: einen Koordinator, um das Netzwerk zu initiieren, Router für die Übertragung und Verteilung von Nachrichten auf die richtigen Pfade sowie ZigBee-Endgeräte, die Nachrichten über das Netzwerk versenden und empfangen.

Ein ZigBee-Endgerät unterstützt bis zu 240 verschiedene Komponenten. Jede solche Komponente wird als Endpunkt bezeichnet, und die in diesem Endpunkt implementierte Funktion ist als Cluster definiert. In der »ZigBee Cluster Library Specification« [7] sind alle von der ZigBee Alliance entwickelten Clusterfunktionen hinterleg. Cluster, die zu einer gemeinsamen Domäne gehören, sind in einem Profil zusammengefasst.

Die ZigBee-Profilspezifikation »Smart Energy« wurde entwickelt, um den Energieverbrauch in Heimnetzwerken (HAN), bestehend aus Smart Metern und Geräten, zu überwachen, zu steuern und zu regulieren. Dieses Profil dient als Schnittstelle für die Zwei-Wege-Kommunikation zwischen Smart Metern und den Haushaltsgeräten im HAN. Außerdem sind die Fragmentierung von Nachrichten und die Sicherheit Gegenstand des Profils. Mehrere Smart-Meter-bezogene Leistungsmerkmale wie die Preiskalkulation, das Lastmanagement (Demand Response and Load Control, DRLC), die Nachrichtenübertragung, Vorauskasse oder das Tunnelling sind als individuelle Cluster im Profil definiert. Der in diesem Profil enthaltene Generic Tunnelling Cluster (GTC) lässt sich verwenden, um DLMS-spezifische Daten über ein ZigBee-Netzwerk zu tunneln.

Das ZigBee-Smart-Energy-Profil definiert eine Energiedienstschnittstelle (Energy Service Interface, ESI), die als Gateway zwischen der AMI und dem ZigBee-Netzwerk fungiert. Dieses Gateway (ein ZigBee-Device mit mehreren Netzwerkschnittstellen) soll Anforderungen von der AMI erleichtern und Antworten von DLMS-Metern entgegennehmen. Alle Anforderungen an DLMS-Meter werden an diese Schnittstelle geschickt. Das ESI identifiziert das mit dem angesprochenen DLMS-Meter verbundene ZigBee-Endgerät und stellt die Anforderung zu. Dann verarbeitet das DLMS-Meter die Anforderung, generiert eine entsprechende Antwort und sendet diese an das ESI zurück, das sie wiederum dem AMI zustellt. Im ESI lassen sich Cluster implementieren, und es kann als Clientgerät im Cluster dienen, das mit den dazugehörigen Servergeräten kommuniziert.

Cluster baut Tunnel

Im ZigBee-Standard [6] ist eine Sammlung von Attributen und Befehl/Antwort-Nachrichten gemeinsam als ein Cluster definiert. Über Cluster lassen sich verschiedene Funktionen wie Nachrichtenaustausch, Preisgestaltung oder Vorauszahlung implementieren. Zum Beispiel steht für die Kommunikation von Textnachrichten an ZigBee-Geräten der »Messaging Cluster« zur Verfügung. Cluster verwenden das Client/Server-Kommunikationsmodell. Das Servergerät, das einen Cluster implementiert, verwaltet bestimmte Attribute, und der Client kommuniziert mit dem Server durch für diesen Cluster definierte Nachrichten.

Um Daten für ein beliebiges Protokoll über ZigBee zu tunneln, ist im Standard der »Generic Tunnelling Cluster« (GTC [8]) definiert. Dabei ist der GTC an einem mit dem DLMS-Gerät verbundenen ZigBee-Endpunkt implementiert und beinhaltet die Attribute »MaximumIncomingTransferSize«, »MaximumOutgoingTransferSize« und »ProtocolAddress« sowie den Befehl »Match Protocol Address«.

Die ersten beiden Attribute spezifizieren die maximale Größe der Dateneinheit, die von bzw. zu diesem Endpunkt übertragen werden kann, während das ProtocolAddress-Attribut eine einmalige Kennung speichert, die dem verbundenen DLMS-Gerät entspricht. Der ZigBee-Knoten, der diesen Cluster implementiert, kann den »Match Protocol Address«-Befehl empfangen und generiert die entsprechende Antwort. Das ESI kann diesen Befehl nutzen, um einen Tunnel in Richtung des DLMS-Geräts anzulegen.

Wie in Bild 5 gezeigt, sendet das Meter-Datenmanagement (MDM) Anfragen an den Meter-Datenkonzentrator (MDC), der mit dem ESI verbunden ist. Wenn der MDC eine DLMS-Anforderung empfängt, extrahiert er die Seriennummer des DLMS-Geräts gemäß dem Ziel der Nachricht und informiert das ESI. Das ESI baut einen Tunnel mit dem DLMS-Gerät dieser Seriennummer auf. Sobald der Tunnel steht, werden durch ihn weitere Nachrichten gesendet. Dabei wird die DLMS-PDU als Nutzdaten in die ZigBee-Smart-Energy-PDU [8] eingefügt und an den seriell mit dem DLMS-Gerät verbundene ZigBee-Knoten geschickt. Anstatt für diesen »End-to-end«-Nachrichtenfluss jeden einzelnen Zähler über eine Punkt-zu-Punkt-Kommunikation anzusprechen, wird das Hauptsystem (Head End System, HES) in einem Smart-Grid-Layout mit dem MDC des MDM kommunizieren. Dieses Gerät ist mit einer Reihe von Smart Metern in der näheren Umgebung verbunden, stößt periodisch eine Sammlung der Daten der Zähler an und speichert die Information, die bei Bedarf an das HES weitergegeben wird. Nun kann der MDC über die oben beschriebenen Kommunikationskanäle mit den anderen Smart Metern in dem Bereich verbunden sein. Da sich diese Zähler in unmittelbarer Nähe befinden werden, kann der MDC mit ihnen aber auch über das ZigBee-Netzwerk kommunizieren.

Der MDC dient als Ein-Punkt-Kontakt für alle Smart Meter, mit denen er über ZigBee verbunden ist. Um die Daten für jeden Zähler zu bekommen, kommuniziert das HES mit dem MDC, der wiederum periodisch Daten von den Smart Metern einsammelt. Daher agiert der MDC sowohl als DLMS-Server als auch -Client. Bild 6 zeigt das Architekturlayout für den MDC und seine Verbindung mit den Smart Metern. Der MDC wird mit denselben Spezifikationen modelliert wie die Smart Meter. Jedes verbundene Meter wird als ein separates und unterschiedliches logisches Gerät (Logical Device, LD) modelliert. Im MDC ist die Zuordnung der LD-Nummer und der einmaligen Kennung des Smart Meters – hier die Seriennummer – abgelegt, mit deren Hilfe der MDC periodisch Daten von den Metern über das ZigBee-Netzwerk einsammelt, als COSEM-Daten intern speichert und wann immer erforderlich an das HES weiterkommuniziert.

Protokolladressen abgleichen

Anstatt die DLMS-Anforderungen direkt an ein DLMS-Gerät zu senden, schickt der MDC diese Anforderung an das ESI im ZigBee-Netzwerk. Dieses Gateway implementiert den GTC ebenso wie jeder mit einem DLMS-Gerät verbundene ZigBee-Knoten.

Dabei agiert das ESI als Generic-Tunnel-Client und der Knoten als Generic-Tunnel-Servercluster, der die Seriennummer des mit ihm verbundenen DLMS-Meters im Attribut ProtocolAddress speichert (Bild 7). Wenn das ESI eine DLMS-Anforderung erhält, erzeugt es den »Match Protocol Address«-Befehl, spezifiziert die ProtocolAddress des DLMS-Geräts, für das diese Anforderung bestimmt ist, und sendet diesen Befehl per »Multicast« an die Gruppe der Generic-Tunnel-Cluster. Nach dem Empfang des Befehls vergleicht der Generic-Tunnel-Server die ProtocolAddress im Befehl mit seinem ProtocolAddress-Attribut und erzeugt bei Übereinstimmung eine »Match Protocol Address Response«. Diese wird zum Gateway zurückgesandt und ein Tunnel zu diesem Gerät für weitere DLMS-Anforderungen aufgebaut. Jetzt geht die DLMS-Anforderung als Nutzdaten in der ZigBee-Smart-Energy-PDU an das ZigBee-Zielgerät, das diese Nutzdaten an das DLMS-Gerät zustellt, und eine entsprechende Antwort wird durch diesen Tunnel an das MDC zurückgeschickt.

Über die Autoren:

Sandeep Akhouri, Sumeer Gargi und Sohil Mahajan sind bei Ericsson India in der BUSS-Organisation in Forschung und Entwicklung tätig.