Redundante Echtzeit-Kommunikation für ein zuverlässiges Stromnetz

Das Stromnetz ist für die Welt von heute eine lebenswichtige Ressource. Die Zuverlässigkeit des Stromnetzes ist von größter Bedeutung, insbesondere angesichts der zunehmenden Nutzung dezentraler Energieerzeugung und der Einführung von Micro Grids, die mehr lokale Intelligenz im Hinblick auf die Überwachung und Steuerung erfordern. Alle Systeme im Netz müssen zusammenwirken, um zu gewährleisten, dass das Netz stabilen und konsistenten Wechselstrom liefern kann. Dazu bedarf es der regelmäßigen Analyse von Spannung, Frequenz und Status der Schaltanlagen. Verbunden hiermit ist die Nutzung erweiterter Überwachungsfunktionen und einer leicht verfügbaren Kommunikation mit geringer Latenz zwischen den Leitstellen und hochwertiger Knoten wie Schaltanlagen, um eine engmaschige Statusüberwachung jedes Subsystems sicherzustellen.

Um die Verwaltung der Netzinfrastruktur zu erleichtern und für das notwendige Maß an Steuerung und Kommunikation zu sorgen, hat sich die Stromverteilungsindustrie auf die Norm IEC 61580 verständigt. Gemäß IEC 61580 übertragen digitale Signale über ein Ethernet-basiertes Netzwerk Informationen zum Stromstatus zwischen Schaltanlagen und elektrischen Subsystemen. Um den zunehmend komplexen Anforderungen der Netzbetreiber gerecht zu werden, wurden im Laufe der Zeit eine Reihe von zeitkritischen Diensten in den Standard IEC 61580 aufgenommen, wie etwa die IEEE 1588-Synchronisation, das echtzeitfähige Netzwerkprotokoll GOOSE (Generic Object Oriented System Events) und das SV-Messaging (Sampled Value).

Abbildung 1: Hauptelemente von IEC 61580 und deren Beziehung zu Ethernet

Das GOOSE-Protokoll unterstützt das Publish-Subscribe-Messaging, das für verteilte Steuerungsanwendungen besser geeignet ist als das herkömmliche Client-Server-Kommunikationsmodell, das in vielen IT-Systemen genutzt wird. IEC 61580 ermöglicht eine separate Bereitstellung des Client-Server-Messaging und unterstützt damit die Geräteverwaltung durch Remote-Stationen oder in anderen Situationen, in denen ein Direktzugriff auf einen Knoten innerhalb einer Schaltanlage oder eines Micro Grid notwendig ist.

GOOSE wiederum ermöglicht die Übertragung von Echtzeitnachrichten zum Status der verschiedenen elektrischen Elemente zu allen Geräten, die diese Informationen benötigen. Zum Beispiel veröffentlicht jedes Relais Informationen mit einer einzigen Kennung für jeden in ihm enthaltenen Objekttyp, für den es den Status melden muss. Andere Relais und Geräte können den Stream der Statusnachricht abonnieren, der durch das Zielrelais ausgesendet wird. Dazu wird eine Kombination von Multicasting über das Netzwerk und Filterung auf den empfangenden Knoten verwendet – die veröffentlichende Stelle muss nicht wissen, wer die Abonnenten sind oder ob sie die Nachrichten empfangen. Zur Erzielung einer maximalen Leistung nutzt GOOSE nicht das üblicherweise verwendete TCP/IP-Protokoll. Stattdessen werden die GOOSE-Nachrichten direkt in Ethernet-Frames integriert. Ebenso bietet das SV-Messaging eine Möglichkeit zum Multicasting von Daten für Werte, die sich schnell ändern (z. B. Spannungswerte), zu den Abonnenten.

Zu den im Rahmen von IEC 61580 vorgesehenen Diensten zählen die Zeitsynchronisation nach dem IEEE 1588-Standard. Dieser Standard verteilt Zeitsignale, die von einem hochpräzisen Oszillator abgeleitet werden, dem so genannten Grandmaster-Taktgeber. In vielen der heute genutzten Systeme verwendet dieser Grandmaster-Taktgeber die Zeitsignale, die von GPS-Satelliten (Global Positioning System) gesendet werden, von denen jeder eine Atomuhr enthält. Der Grandmaster-Taktgeber speist eine Reihe von Slave-Taktgebern. Diese sind entweder als Boundary-Taktgeber klassifiziert – diese befinden sich in Gateways, die als temporäre Master fungieren können, wenn das GPS-Signal ausfällt – oder als normale Taktgeber, die sich in jedem der Systeme befinden, die synchronisiert werden müssen. Die Zeitinformationen werden über die gesamte Struktur verteilt, wozu eine Reihe von Nachrichten ausgetauscht werden, die in regelmäßigen Intervallen wiederholt werden müssen. So wird sichergestellt, dass alle Systeme synchronisiert bleiben.

Das Protokoll basiert darauf, dass ein Master-Taktgeber eine Synchronisierungsnachricht mit einem Zeitstempel an die Slaves sendet. Kurz danach sendet er eine Folgenachricht, die einen späteren Zeitstempel enthält. Der Slave antwortet mit einer Nachricht, in der er vom Master eine Abschätzung der Verzögerung anfordert. Der Master sendet eine weitere Antwort, die ihren Sendezeitpunkt enthält. Am Ende dieses Prozesses verfügt der Slave über vier Zeitstempel, von denen drei durch den Master gesendet wurden. Anhand der Zeitinformationen in ihrer Reihenfolge ermittelt der Slave die nötige Änderung an seiner internen Uhr, um eine möglichst genaue Übereinstimmung mit dem Master zu erzielen. Das Protokoll führt zu einer zeitlichen Synchronisierung, die in einem lokalen Netzwerk (LAN) in der Regel eine Genauigkeit in Höhe eines zweistelligen Nanosekunden-Werts erreicht.

Andere wichtige Teile der IEC 61580 Infrastruktur sind redundante Datenübertragungsprotokolle. Das in IEC 62439 standardisierte Parallel Redundancy Protocol (PRP) unterstützt eine Dual-Port-Vollduplex-Kommunikation. Das Protokoll stellt zwei Ströme mit redundanter Paketbehandlung unterhalb der MAC-Ebenen-Schnittstelle bereit, die für Anwendungsprotokolle höherer Ebenen wie GOOSE und SV sichtbar sind. Typischerweise erfolgen die Ethernet-Verbindungen über verschiedene Ethernet-Switches und gehen von einer sternförmigen Netzwerktopologie aus.

Abbildung 2: Das PRP-Redundanzprotokoll geht von einer sternförmigen Topologie aus.

Eine Alternative ist das HSR-Protokoll (High-availability Seamless Redundancy), das ebenfalls in IEC 62439 definiert ist. HSR nutzt eine Ringtopologie, wobei jedes Paket dupliziert und in entgegengesetzten Richtungen im Ring auf das Ziel zu übermittelt wird. Durch die ringförmige Architektur entfällt die Notwendigkeit zusätzlicher Switches/Router – allerdings auf Kosten einer erhöhten Verzögerung, wenn Pakete erst mehrere Knoten passieren müssen, um zu ihrem Ziel zu gelangen. Moderne Kommunikations-Controller können diese Verzögerung durch Nutzung der Cut-Through-Weiterleitung minimieren. Bei diesem Ansatz muss ein Paket nicht erst vollständig decodiert werden, bevor die Weiterleitung zum Ziel beginnt.

Abbildung 3: Das HSR-Redundanzprotokoll ist für eine Ringtopologie ausgelegt.

Wegen der Notwendigkeit einer umfassenden Filterung der eingehenden Ethernet-Nachrichten setzt IEC 61580 eine sehr leistungsstarke Prozessorverarbeitung voraus. Das kann sich negativ auf das Maß der verfügbaren Rechenleistung auswirken, die für Steuerungsalgorithmen verfügbar ist. Ein Lösungsansatz hierfür ist es, einen möglichst großen Anteil der Analyse auf Netzwerkebene auszulagern, sodass sich der Host-Prozessor nur mit den Nachrichten befassen muss, die seine Aufmerksamkeit erfordern. Erreicht werden kann dies auf Multicore-SoCs, von denen einige spezielle intelligente Netzwerkprozessoren enthalten. Ein Beispiel hierfür ist der eingebettete Mikroprozessor AM572x Sitara von Texas Instruments. Für den Baustein ist eine Evaluierungskarte verfügbar, die eine einfache Erkundung seiner Netzwerkfunktionen ermöglicht.

Der AM572x basiert auf dem ARM® Cortex®-A15-Prozessor. Die Multicore-Komponente unterstützt den Host-Prozessor durch einen Cortex-M4, der zur Auslagerung der E/A-intensiven Aufgaben verwendet werden kann. Ebenfalls enthalten ist ein Paar von Netzwerkrozessoren sowie ein digitaler Signalprozessor auf Basis der C66x-Architektur zur Durchführung der Datenanalyse. Das PRU-ICSS-Subsystem auf dem AM572x ermöglicht eine getrennte Verarbeitung zusätzlich zu der, die auf dem ARM-Kern verfügbar ist. Der Baustein enthält zwei PRUs, von denen jede einen 32-Bit-RISC-Prozessor enthält, der mit bis zu 200 MHz arbeiten kann, sowie eine Netzwerkschnittstelle. Die Verfügbarkeit von zwei unabhängigen intelligenten Kernen ermöglicht die Unterstützung von PRP und HSR.

Der RISC-Prozessor im PRU-Kern weist keine Universal-Architektur auf. Stattdessen ist dieser Kern speziell für die Manipulation der Arten von gepackten speicher-abgebildeten Datenstrukturen ausgelegt, wie sie in Netzwerk-Frames auftreten. Er enthält eine Reihe von Funktionen zur Unterstützung von Anwendungen mit strengen Echtzeiterfordernissen. Ein gewisses Maß an Paketfilterung kann auf den PRU-Prozessoren durchgeführt werden. Auf dem AM572x stehen durch den Cortex-M4 mehr Reserven für Protokolle wie IEEE 1588, GOOSE und SV zur Verfügung.

Der Cortex-M4 kann verwendet werden, um alle eingehenden Multicast-Pakete zu analysieren und ihre APPID-Adressen (Anwendungs-ID) mit gültigen Abonnements zu vergleichen, die durch die auf dem Cortex-A15 ausgeführte Software bereitgestellt werden. Daraus kann der M4 ermitteln, welche Nachrichten stromaufwärts weitergeleitet werden müssen. Die anderen Pakete können fallen gelassen und aus dem Speicher gelöscht werden.

Abbildung 4: Shared-Memory-IPC ermöglicht die Entlastung der IEC-61580-Verarbeitung zum Cortex-M4 und anderen Prozessoren.

Eine wichtige Überlegung bei dieser Prozessor-entlastenden Architektur ist die Kommunikationsweise der einzelnen Prozessoren miteinander. Der AM572x bietet gemeinsam genutzten Speicher (Shared Memory), um die Weitergabe von Nachrichten von einem Prozessor zu einem anderen zu erleichtern. Pakete lassen sich einfach zu Warteschlangen formieren, sodass sie in der vorgegebenen Reihenfolge gelesen und geschrieben werden können. Die entscheidende Frage ist das zu verwendende Protokoll. Eine Option ist der Einsatz von Linux auf dem Cortex-A15. Dies ermöglicht die Verwendung von Standard-APIs (Application Programming Interfaces), die das Betriebssystem für die prozessübergreifende Kommunikation bieten, z. B. remoteproc und rpmsg.

Beim rpmsg-Messaging-System wird ein virtuelles Gerät bereitgestellt, das jedem Kommunikationskanal entspricht, der mit einem Remote-Prozess verknüpft ist. Die Kanäle werden durch einen alphanumerischen Namen identifiziert und besitzen eine lokale rpmsg-Adresse sowie eine Remote-rpmsg-Adresse. Wenn ein Treiber das Abhören eines Kanals beginnt, ist die zum Empfang verwendete Callback-Funktion an eine eindeutige lokale 32-Bit-rpmsg-Adresse gebunden. Kommen eingehende Nachrichten an, verteilt der rpmsg-Kern diese entsprechend ihrer Zieladresse an die entsprechenden Treiber. Die Weiterleitung der Meldungen erfolgt durch Aufrufen des Empfangs-Handlers bei gleichzeitiger Bereitstellung der Nutzdaten der eingehenden Nachricht. Durch dieses Schema kann der Filterungscode für GOOSE- und SV-Nachrichten mit bestimmten APPID-Adressen an verschiedene Handler übergeben werden, die auf dem Cortex-A15 ausgeführt werden. Alternativ können sie auch alle zu Gruppen zusammengefasst werden, die dann an einen gemeinsamen Nachrichtenprozessor weitergeleitet und auf dem Host-Prozessor sortiert werden.

Die Open-Source-IPC3.x-Bibliothek, verfügbar im Git Repository von TI, implementiert die Software zur Verwendung von rpmsg zwischen der Linux-Umgebung und dem TI RTOS, der für die Cortex-M4- und DSP-Kerne verfügbar ist. Durch Bereitstellung der gleichen APIs über verschiedene TI-Bausteine hinweg abstrahiert das IPC-Produkt eine gerätespezifische Unterstützung für Hardware-Spinlocks, prozessorübergreifende Mailbox und rpmsg-kompatible Nachrichtenweitergabe durch die MessageQ-API.

Fazit

Durch Multiprocessing mit Unterstützung von Nachrichtenübergabe können Bausteine wie der AM572x komplexe Echtzeitsteuerungsprotokolle effizient unterstützen, wie sie z. B. für die missionskritische Aufgabe der Verwaltung der Stromnetzinfrastruktur entwickelt wurden.