Konzept für die Validierung und Prüfung von Kommunikationsnetzen

Einführung

Da das Hauptziel von Arbeitspaket 3 (AP3) die Erprobung und Bewertung der intelligenten, dezentralen Regelungslösungen für das Wirk- und Blindleistungsmanagement dezentraler Anlagen im Netz ist, trägt OFFIS mit dem Aufbau einer Simulationsinfrastruktur im SESA-Labor zur Abbildung des elektrischen Netzes einschließlich der Integration der Reglerkomponenten und des Kommunikationsnetzes bei. Des Weiteren erfolgt die Untersuchung der Auswirkungen der Kommunikationstechnik auf die Netzregelung unter Berücksichtigung relevanter Szenarien (Technologien, Störungen...). Um dieses Ziel zu erreichen, muss das dedizierte Kommunikationsnetz für den Netzbetrieb in AP3 modelliert und das Basismodell mit empirischen Daten validiert werden. Anschließend kann die Leistung des Kommunikationsnetzes unter verschiedenen Szenarien (ohne Hintergrundnetzwerkverkehr oder stark belastet mit Smart-Meter-Netzwerkverkehr) und Technologien (CDMA (Code-division Multiple Access) oder Glasfaser) getestet und die Dienstgüte (QoS) der Kommunikation gesammelt werden. Danach kann die Leistung der Steuerungssysteme (Phoenix) unter den verschiedenen, gesammelten Kommunikations-QoS durch Wiedergabe der simulierten QoS-Daten hinsichtlich ihrer Performanz unter begrenzter Verfügbarkeit und Datenverlusten des Kommunikationsnetzwerks geprüft werden.

Modellierung des Kommunikationsnetzes für den Netzbetrieb

Wie bereits erwähnt, wurde in einem ersten Schritt die Kommunikationsnetzinfrastruktur der EWE NETZ GmbH für den Netzbetrieb modelliert und das Modell simuliert, um es anhand empirischer Daten (z.B. Verzögerung) zu validieren. Anschließend kann die Leistung des Kommunikationsnetzes unter verschiedenen Szenarien und Technologien getestet und die Daten zur Kommunikationsqualität gesammelt werden, um diese für die Prüfung der Leistung der Regelsysteme zu verwenden.

Das synthetische Netzwerk, das auf dem tatsächlichen Netzwerk im Labor aufbaut, um die Charakteristik des Netzwerks zu testen und zu validieren, besteht aus einer Basisstation, die mit 16 CDMA-Routern (Code-division Multiple Access) und RTUs (Remote Terminal Unit) verbunden ist, die sich an verschiedenen Standorten befinden. Die Basisstation ist über einen Backbone-Router und über Glasfaserverbindungen mit dem Kontrollzentrum verbunden. Die Eigenschaften des Netzwerkmodells sind in Abbildung 1 dargestellt. Die Router sind auf der Grundlage der Sterntopologie verbunden, und es wird das Protokoll IP over ppp (Punkt-zu-Punkt) verwendet. Alle 5 Sekunden wird ein Paket an das Kontrollzentrum gesendet, wobei das IEC 60870-5-104 over TCP (Transmission Control Protocol) mit 117 Byte als Paketgröße verwendet wird. Weitere Spezifikationen und Anforderungen des Modells sind in Tabelle 1 aufgeführt.

Abbildung 1 - Infrastruktur des Kommunikationsnetzes der EWE NETZ GmbH

Das Modell wurde mit dem Netzwerk-Emulator EXata simuliert. EXata simuliert das Verhalten des Netzwerks unter einer Vielzahl von Benutzer-definierten Szenarien in Echtzeit und ermöglicht die Visualisierung von Statistiken und des Datenflusses in Echtzeit. Das in EXata modellierte Netz der EWE NETZ GmbH ist in Abbildung 2 zu sehen. Wie in der Abbildung dargestellt, senden die 16 RTUs über die Basisstation Daten an die Leitstelle. Gemessen wird die Ende-zu-Ende-Verzögerung zwischen dem Senden der Messungen von der RTU und dem Empfang in der Leitstelle.

Router	Topologie	Sternförmig
	Routing Protokol	IP over ppp
	Gerätetyp	Garderos R-3677 Digi WR31-D52A-DE1-TB
Funkverbindung	Trägerfrequenz	450/460 MHz
	Signalstärke	-89 dBm
	Antennenhöhe	1,5m über Grund 10cm über dem Dach
Netzwerk-verkehr	Bitrate	DL: 4,8 Kbit/s – 4,9 Mbit/s UL: 4,8 Kbit/s – 1,8 Mbit/s
	Protokol	IEC 60870-5-104 over TCP
	Paketgröße	117 byte
	Paketrate	0,2 pkt/s

Tabelle 1 - Spezifikationen und Anforderungen

Die simulierten Werte werden gesammelt und mit den empirischen Daten verglichen. Abbildung 3 zeigt die Verzögerung sowohl für die empirischen als auch für die simulierten Daten in Sekunden.  Die Ergebnisse zeigen, dass die realen und simulierten Werte nahe beieinanderliegen. In einigen Zeitintervallen kann man sehen, dass der Wert der Verzögerung im realen Netz den Wert der Verzögerung im simulierten Netz übersteigt. Dies könnte darauf zurückzuführen sein, dass im realen Netz Hintergrundverkehr vorhanden war oder dass in der Umgebung Hindernisse vorhanden waren, die Signale schwächen und die Verzögerung erhöhen. Die maximale Verzögerung, die minimale Verzögerung und der Mittelwert sind in Tabelle 2 dargestellt. Die mittlere Abweichung ist mit 0,01s sehr gering, sodass das Basismodell mit den empirischen Daten als validiert angenommen wird, und verschiedene Szenarien und Technologien getestet werden können, um die QoS-Daten zu erfassen. In weiteren Schritten werden die gesammelten QoS-Daten in der im nächsten Abschnitt beschriebenen Plattform verwendet, um die Leistung von Steuerungssystemen zu testen.

Abbildung 2 - Modell des Kommunikationsnetzes in EXata

Abbildung 3 - Verzögerung im realen und simulierten Netzwerk

Min (s)	Real	0,329
	Simulation	0,334
Max (s)	Real	0,479
	Simulation	0,479
Mean (s)	Real	0,387
	Simulation	0,377

Tabelle 2 – Minimale (Min), maximale (Max) und mittlere (Mean) Verzögerung  für reales und simuliertes Netzwerk

Prüfung der Leistungsfähigkeit der Kontrollsysteme

Das Ziel des Testens verteilter Controller ist es, die Kommunikationscharakteristik zwischen diesen Geräten zu bewerten und Hinweise zubekommen, ob ein bestimmter Controller für eine bestimmte Anwendung geeignet ist, basierend auf der für eine solche Anwendung erforderlichen QoS.

Als Teil des im OFFIS geschaffenen Lösungsartefakts wird eine Plattform und Methodik vorgeschlagen, um die Kommunikationsfähigkeiten von Controller-Geräten zu testen. Zur Validierung dieser Plattform wird ein Kommunikationstest mit zwei physikalischen Remote Terminal Units (RTU) "mauell ME 4012 PA-N" der Firma PHOENIX CONTACT Energy Automation GmbH durchgeführt. Das Hauptziel dieses Tests besteht darin, Informationen von einem dieser Geräte an das andere zu senden und die QoS der Datenübertragung zu messen. Konkret liegt der Schwerpunkt auf der Bestimmung der Zeit, die die Informationspakete von einem Gerät zum anderen benötigen, wobei die rechnerischen Verzögerungen, die sich aus der Informationsverarbeitung ergeben, berücksichtigt werden.

Der Aufbau des Tests ist in Abbildung 4 dargestellt. Ein Hardware-in-the-Loop (HIL)-Test wird durchgeführt, indem eine physikalische Ethernet-Verbindung zwischen dem Echtzeitsimulator OPAL-RT und den Geräten hergestellt wird. Diese Geräte sind ebenfalls über eine Ethernet-Verbindung verbunden. Der Test besteht darin, die im Echtzeitsimulator erzeugten Informationen über das Protokoll MODBUS TCP an eines der Geräte (als Unterstation bezeichnet) zu senden. Diese Informationen werden dann von der RTU "Unterstation" an die RTU "Zentrale" über das Protokoll IEC 60870-5-104 übertragen, das üblicherweise in Fernwirkanwendungen verwendet wird. Schließlich wird das Informationspaket von der RTU "Zentrale" zurück an den Echtzeitsimulator gesendet. Mit dieser Verbindung kann die Gesamt-Roundtrip-Zeit eines Informationspakets gemessen werden. Um eine Verbindung zwischen dem Simulator und den realen Geräten herzustellen, werden zwei Modbus-Server in OPAL-RT modelliert und so konfiguriert, dass sie jeweils mit einer RTU kommunizieren.

Abbildung 4 - Test-Aufbau

Um die Fähigkeiten der RTUs und die Roundtrip-Zeit zu bestimmen, ist es wichtig, ein geeignetes Informationsmerkmal zu definieren (Abbildung 5). Der Einfachheit halber besteht die Information aus ganzzahligen Zahlen (die eine 16-Bit-Datenstruktur repräsentieren), beginnend bei 1 und immer schneller ansteigend bis zum Wert 30. Als Beispiel wird der Wert "1" für eine Zeit von 20 Sekunden gesendet, dann wird der Wert "2" für eine Zeit von 16 Sekunden gesendet, was 20% schneller als der vorhergehende Wert ist. Der Zweck dieser progressiv schnelleren Kennlinie besteht darin, die Fähigkeit der Geräte zur schnellen transienten Kommunikation zu bestimmen. Dies ist möglich, indem bestimmt wird, bis zu welchem Wert eine 100% erfolgreiche Datenübertragung stattfindet. Dies wird verwendet, um eine Grenzfrequenz zu bestimmen, bis zu der die Information zu 100% übertragen wird.

Abbildung 5 – Datenübertragungscharakteristik

In Anbetracht der stochastischen Natur von Kommunikationsverzögerungen wird dieses Merkmal 500-mal hintereinander wiederholt, um die Wahrscheinlichkeitsverteilung der Hin- und Rücklaufzeit der Informationspakete zu bestimmen. Theoretisch kann eine Verzögerung erwartet werden, die sich entsprechend einer Normalverteilung verhält, und deshalb ist es das Ziel, die durchschnittliche Verzögerung und ihre Standardabweichung zu berechnen.

Die Ergebnisse des Tests sind in Abbildung 6 dargestellt. Das linke Diagramm zeigt in der horizontalen Achse die Zeitdauer der einzelnen Datenwerte. Dieses Diagramm zeigt, dass der höhere Wert, der erfolgreich übertragen wurde, derjenige ist, dessen Zeitdauer 340 Millisekunden betrug, was dem Wert "19" des in der vorherigen Folie gezeigten Zeitmerkmals entspricht. In diesem Fall sehen wir zum Beispiel, dass der Wert "20" in 90,7% der 500 Mal, die das Merkmal übertragen wurde, erfolgreich übertragen wurde, die Werte "21" und "22" in etwa 70% der Fälle, und dann progressiv abnehmend bis zum Wert "30", mit einer erfolgreichen Übertragungsrate von nur 4%. Dieses Ergebnis zeigt, dass die Ausschlussperiode 340ms (f=3 Hz) beträgt.

Die Grafik rechts zeigt die resultierende Normalverteilung der Zeitverzögerung, die sich aus allen erfolgreich übertragenen Daten ergibt. Daraus ergibt sich ein durchschnittlicher Echtzeit-Roundtrip von 1,028 Sekunden mit einer Standardabweichung von 0,132s. Das bedeutet, dass die Wahrscheinlichkeit, dass die Zeitverzögerung im Bereich der durchschnittlichen 1,028s plus minus einer Standardabweichung (0,132s) liegt, 68,2% beträgt.

Abbildung 6 - Ergebnisse des Kommunikationstests