Drahtlose Bereitstellung von Informationen aus Schalter- Funktionstests

Die Erfindung betrifft eine Schalteranordnung, ein System und ein Verfahren für die drahtlose Bereitstellung von Informati- onen aus Schalter-Funktionstests.

Für Elektroanlagen ist sind in vielen Fällen regelmäßige Tests vorgesehen, um die Funktionsfähigkeit sicherzustellen. Das gilt insbesondere, wenn Schutzschalter in den Anlagen verbaut sind. Fig. 1 zeigt eine exemplarische Tabelle für Testanforderungen bei ortsfesten elektrischen Anlagen und Be- triebsmitteln .

Tests (z.B. Fehlerstrom- und Isolationswiderstandsmessungen) werden dabei zunehmend drahtlos initiiert. In Fig. 2 ist ge- zeigt, wie mehrere Niederspannungselemente (z.B. Niederspan- nungsschutzvorrichtungen bzw. Breaker) EDI, ED2, ED3 und EDn (EN: end device) drahtlos mit einem Datensammler bzw. Daten- konzentrator ZC (ZC steht für Zigbee-Koordinator) verbunden sind. Die Kommunikation läuft dabei über das Zigbee-Proto- koll. Über den Datensammler ZC können dann unmittelbar oder mittelbar Daten für Applikationen in die Cloud gesendet wer- den. Durch den Datenkonzentrator ZC kann die Bereitstellung von Daten in der Cloud flexibel z.B. bzgl. Einstellungen, Da- tenanpassungen und Sendeoptionen gestaltet werden.

Typische Niederspannungsschutzvorrichtungen sind dabei Feh- lerstromschutzschalter (auch bezeichnet als RCD bzw. residual current breaker), Leitungsschutzschalter (auch bezeichnet als MCB bzw. miniature circuit breaker) und Brandschutzschalter (auch bezeichnet als AFDD bzw. arc fault detection device).

Dabei kann ein solcher Schalter auch nicht selbst kommunika- tionsfähig sein. Die Kommunikationsfähigkeit wird dann über die mechanische Kopplung mit einem Kommunikationsmodul (Remo- te Control Auxiliary (RCA)) Gerät realisiert. Ein derartiges Modul ist z.B. in der DE 202021000293 U1 beschrieben. Die Erfindung hat eine verbesserte Analyse des Verhaltens von Schaltern zur Aufgabe. Diese Aufgabe wird durch eine Schalteranordnung nach Anspruch 1, ein System nach Anspruch 5, umfassend eine erfindungsgemä- ße Schalteranordnung und ein Endgerät, bzw. ein Verfahren nach Anspruch 10 gelöst. Erfindungsgemäß wird eine Schalteranordnung vorgeschlagen, die einen Schalter umfasst. Dabei kann die Schalteranordnung mit dem Schalter identisch sein. Alternativ ist möglich, dass z.B. die Schalteranordnung aus einer Kombination aus einem Schalter und einem Zusatzmodul besteht, insb. wenn der Schal- ter selbst nicht für eine drahtlose Kommunikation ausgestal- tet ist. Ein solches Zusatzmodul kann auch für die Durchfüh- rung von Tests des Schalters erforderlich sein, wenn der Schalter nicht für die autarke Durchführung eines Selbsttests ausgestaltet ist. Ein derartiges Zusatzmodul muss nicht per- manent mit dem Schalter gekoppelt sein, sondern kann auch de- zidiert nur für einen Testzeitraum an dem Schalter angebracht werden. Der Schalter selbst kann z.B. ein Niederspannungs- schutzschalter oder ein Niederspannungsleistungsschalter sein. Die erfindungsgemäße Schalteranordnung ist dafür ausgebildet, einen auf einen Aspekt der Funktionsfähigkeit des Schalters gerichteten Test durchzuführen und auf den durchgeführten Test bezogene Daten in einer lokalen Speichervorrichtung (z.B. Ringspeicher) abzuspeichern. Bei einer Kombination aus Schalter und Zusatzmodul kann dabei diese Speichervorrichtung im Schalter oder im Zusatzmodul angeordnet sein. Die Schal- teranordnung ist zudem dafür eingerichtet, auf eine mittels eines ersten Protokolls für drahtlose Kommunikation gesendete Anfrage nach Daten zu einem oder mehreren durchgeführten Tests in der Speichervorrichtung abgespeicherte Daten zu durchgeführten Tests mittels einer oder mehrerer Nachrichten an einen durch die Anfrage spezifizierten Empfänger zu über- mitteln .

Bei dem ersten Protokoll für drahtlose Kommunikation handelt es sich z.B. um das Zigbee-Protokoll. Dann kann die Anfrage nach Daten zu einem oder mehreren durchgeführten Tests und die eine oder mehreren Nachrichten zur Übermittlung von zu durchgeführten Tests abgespeicherten Daten mittels dafür ei- gens kreierten (d.h. in gewisser Weise proprietären) Zigbee- Kommandos erfolgen. Z.B. ist ein Kommando REQUEST____LOG für die Anfrage und eines RESPONSE___LOG für die Übermittlung von Daten durch die Speichereinrichtung vorgesehen. Dabei kann es er- forderlich sein, zur Übermittlung aller angefragten Daten ei- ne Mehrzahl von RESPONSE____LOG-Nachrichten zu schicken. Bei der Übermittlung von LOG-Daten mittels mehrerer Zigbee-Nachrich- ten kann es sinnvoll sein, die im Rahmen einer Anfrage ange- forderten Daten zu durchgeführten Tests mittels Zigbee-Frag- mentierung auf mehrere Nachrichten zur Übermittlung an den Empfänger aufzuteilen.

Die Erfindung ermöglicht so eine effiziente und benutzer- freundliche Bereitstellung von im Zuge von Schaltertests pro- tokollierten Daten (LOG-Daten).

Der Erfindungsgegenstand umfasst auch ein System mit einer erfindungsgemäßen Schalteranordnung nach und einem Endgerät. Dabei umfasst das Endgerät eine Software-App (d.h. eine An- wendungssoftware bzw. ein Computerprogramm, das für den Nut- zer des Endgeräts Funktionen bereitstellt, auf die dieser zu- greifen kann), die dafür ausgestaltet ist, die Daten zu einem oder mehreren durchgeführten Tests zu erhalten und einen Ex- port der Daten in einem File aus der App zu ermöglichen. Die- se App kann dafür ausgestaltet sein, mittels eines zweiten Protokolls für drahtlose Kommunikation eine Anfrage nach Da- ten zu einem oder mehreren durchgeführten Tests in der Spei- chervorrichtung abgespeicherte Daten zu senden und eine oder mehrere mittels des zweiten Protokolls übermittelte Nachrich- ten mit angefragten Daten zu erhalten. Insbesondere folgende zwei Konstellationen können dabei vorkommen: a)Das erste und das zweite Protokoll können identisch sein (Z.B. Bluetooth oder TCP). Die App des Endgeräts ist dann dafür ausgestaltet, mittels dieses Protokolls für drahtlose Kommunikation eine Anfrage nach Daten zu einem oder mehreren durchgeführten Tests in der Speichervor- richtung abgespeicherte Daten direkt an die Schalterano- rdnung zu senden und eine oder mehrere übermittelte Nachrichten mit angefragten Daten direkt von der Schal- teranordnung zu erhalten. Mit „direkt" ist dabei impli- ziert, dass eine entsprechende Adressierung der Nach- richten erfolgt. Diese Ausgestaltung kommt vorzugsweise bei größeren Schaltern zum Einsatz, z.B. Leistungsschal- tern der Niederspannungs- und Mittelspannungstechnik. b) Das System umfasst einen Datenkollektor. Dieser ist da- für ausgestaltet, eine mittels des zweiten Protokolls (z.B. TCP oder Bluetooth) für drahtlose Kommunikation gesendete Anfrage nach Daten zu einem oder mehreren durchgeführten Tests in der Speichervorrichtung abge- speicherte Daten an die Schalteranordnung von der App zu erhalten (bei der Anfrage kann es sich um ein oder meh- rere durch die Schalteranordnung interpretierbare Modbus-Kommandos handeln) und mittels des zweiten Proto- kolls für drahtlose Kommunikation eine oder mehrere Nachrichten mit angefragten Daten von der Schalteranord- nung zu an das Endgerät zu senden. Zudem ist der Daten- kollektor dafür eingerichtet, eine mittels des zweiten Protokolls für drahtlose Kommunikation gesendete Anfrage nach Daten zu einem oder mehreren durchgeführten Tests in der Speichervorrichtung abgespeicherte Daten an die Schalteranordnung für eine Übermittlung mittels des ers- ten Protokolls anzupassen und an die Schalteranordnung zu übermitteln (d.h., der Datenkollektor fungiert als Protokollumsetzer) . Schließlich ist der Datenkollektor auch dafür ausgestaltet, eine oder mehrere mittels des ersten Protokolls übermittelte Nachrichten mit angefrag- ten Daten der Schalter Logbuch-Einträge zu empfangen, die eine oder mehreren Nachrichten für eine Übermittlung mittels des zweiten Protokolls anzupassen und mittels des zweiten Protokolls an ein Endgerät (z.B. Mobiltele- fon) übertragen (evtl, erfolgt im Zuge der Proto- kollumsetzung dabei eine Zusammenfassung von empfangenen Nachrichten für die effizientere Übersendung an das End- gerät) .

Gegenstand der Erfindung ist auch ein Verfahren für die drahtlose Bereitstellung von Informationen aus Schalter- Funktionstests. Dieses beinhaltet die Durchführung eines ei- nen auf einen Aspekt der Funktionsfähigkeit des Schalters ge- richteten Tests, ein Speichern von auf den durchgeführten Test bezogene Daten in einer lokalen Speichervorrichtung ei- ner Schaltervorrichtung und ein Senden einer oder mehrerer Nachrichten, wobei das Senden durch eine mittels eines ersten Protokolls für drahtlose Kommunikation gesendete Anfrage nach in der Speichervorrichtung abgespeicherten Daten getriggert wird und an einen durch die Anfrage spezifizierten Empfänger erfolgt. Die Anfrage nach Daten zu einem oder mehreren durch- geführten Tests und das Senden bzw. die Übermittlung von ei- ner oder mehreren Nachrichten zur mit zu durchgeführten Tests abgespeicherten Daten können dabei mittels dafür kreierten Zigbee-Kommandos erfolgen. Dabei können dann die im Rahmen einer Anfrage angeforderten Daten zu durchgeführten Tests mittels Zigbee-Fragmentierung auf mehrere Nachrichten zur Übermittlung an den Empfänger aufgeteilt werden.

Die Erfindung wird im Folgenden im Rahmen von Ausführungsbei- spielen anhand von Figuren näher erläutert. Es zeigen:

Fig. 1: eine exemplarische Tabelle für Testanforderungen bei ortsfesten elektrischen Anlagen und Betriebsmitteln,

Fig. 2: einen Datensammler und Niederspannungsschutzvorrich- tungen, die drahtlos miteinander verbunden sind, Fig. 3: eine Modbus Map für ein Log-Format eines Schalter- tests,

Fig. 4: ein Datenformat für die Übermittlung von Log-Daten eines Schaltertests,

Fig. 5: Zigbee-Befehle „REQUESTEDOG" und „RESPONSE___LOG" für die Abfrage bzw. Übermittlung von Log-Daten eines Schalter- tests,

Fig. 6: ein Ablaufdiagramm für ein erstes Beispiel für ein erfindungsgemäßes Verfahren (mit Datensammler), und

Fig. 7: ein Ablaufdiagramm für ein zweites Beispiel für ein erfindungsgemäßes Verfahren (ohne Datensammler).

Es werden Tests (z.B. Fehlerstrom- und Isolationswiderstands- messungen) durchgeführt und automatisch protokolliert. Die Durchführung der Tests kann dabei weitgehend automatisiert sein und z.B. regelmäßig in vorgegebenen Zeitintervallen er- folgen. Erfindungsgemäß wird für jeden Test automatisch ein Log-Eintrag mit Informationen zum jeweiligen Test generiert. Es kann dabei für jeden Test eine eigene Logdatei mit dem entsprechenden Log-Eintrag erzeugt werden. Alternativ gibt es eine einzige Logdatei für alle Tests oder zumindest für alle Tests eines Typs, in welche die Testergebnisse der Reihe nach geschrieben werden. Für die Log-Informationen ist z.B. ein persistenter bzw. nichtflüchtiger Ringspeicher vorgesehen.

Mittels Firmware werden Testergebnisse (z.B. von Fehlerstrom- und Isolationswiderstandsmessungen) persistent in einem Ring- puffer gespeichert. Per Modbus-Parameter wird ein automati- sierter Test an einem Zigbee-Endgerät konfiguriert und über ein Modbus-Kommando gestartet. Alternativ kann ein Test auch manuell oder ein einzelner Test über ein Modbus-Kommando ge- startet werden. Nach Ablauf eines Tests wird dann automati- siert ein Log-Eintrag erstellt. Das Log-Format für Tests ist eigens in einer sog. Modbus Map (Datenpunktliste) spezifiziert . Eine Modbus Map ist dabei ein Feature des Modbus

Protokolls . Dabei handelt es sich um eine Liste für ein Sla- ve-Gerät (hier: Zigbee Endgerät) , die beschreibt um welche Daten es sich handelt (z.B. Schaltertest) , wo die Daten gespeichert werden (z.B. Datenadressen) und wie die Daten gespeichert werden (z.B. Datentyp, Byte- und Wort-Anordnung) .

In Fig. 3 ist ein Beispiel für eine Modbus Map für das Log Format für Tests angegeben.

Diese umfasst folgenden Felder:

Event ID DEC: Identifikationskennung den jeweiligen Test

(Dezimalwert)

Event ID HEX: Identifikationskennung den jeweiligen Test

(Hexadezimal wert )

Data Set Versions: unterstützte Softwareversionen

Mnemonic : Texterklärung für Log Informationen

Valency : Klassifizierung des Eintrags

(Information, Warnung, Alarm)

Category : Kategorie des Eintrags (System, Opera tor)

Destination : Übertragungsprotokoll

Type : Attributtyp der testbezogenen Daten

Escort Values: testbezogene Daten

In Fig. 3 sind den einzelnen Feldern folgende Einträge zuge wiesen :

Event ID DEC: 1001

Event ID HEX: 03E9

Data Set Versions: 1 .1 ; 2.0

Mnemonic : REMOTE CONTROL AUXILIARY TEST RESULT

Valency : Information

Category : system

Desination : ModbusTCP Type: U16 bzw. FP32

Escort Values:

RESTDUAL—CURRENT—DEVICE-TEST___STATE

CONF-RESIDUALJTURRENTJDEVICE^TEST—CONTROL

RESTDUAL-CURRENT-DEVICE_TEST_VOLTAGE

RESTDUAL_CURRENT—DEVIGEISELF_TEST___TRIPPING_TIME

RESTDUAL_CURRENT—DEVICE__SELF__TESTJTRIPPING—CURRENT

PARAM—INSULATION__RESISTANGENTEST___STATE

INSULATION__RESISTANGEITEST____VALUE__N___PE

INSULATION-RESISTANCE__TEST~VALUE—L1____PE

INSULATION_RESISTANCE-TEST-VALUE_L2_PE

INSULATION-RESISTANCE_TEST_VALUE-L3-PE

Die "Escort Values" entsprechend dabei während eines Tests bestimmten, testbezogenen Informationen:

RESTDUAL-CURRENT-DEVICE-TEST-STÄTE : Differenzstrom-

Testergebnis (Test bestanden oder nicht, aufgrund von unter- schiedlichen Fehlerursachen)

CONF-RESIDUAL-CURRENT-DEVICE-TEST-CONTROL: Information zur Testkonfiguration (Auslösestrom und Isolationswiderstand) RESIDUAL-CURRENT-DEVICE-TEST-VOLTAGE : TestSpannung

RESIDUAL-CURRENT_DEVICE-SELF_TEST-TRIPPING-TIME : Auslösezeit RESIDUAL_CURRENT-DEVICE-SELF-TEST-TRIPPING_CURRENT : Auslöse- strom (Differenzstrom)

PARAM-INSULATION-RESISTANCE-TEST-STATE : Isolationstest Mes- sergebnis

INSULATION-RESISTANCE-TEST-VALUE-N-PE : Isolationswidersfand N zu PE

INSULATION-RESISTANCE-TEST-VALUE-Ll-PE : Isolationswidersfand LI zu PE

INSULATION-RESISTANCE-TEST-VALUE-L2-PE Isolationswidersfand

L2 zu PE

INSULATION-RESISTANCE-TEST-VALUE-L3-PE Isolationswidersfand L3 zu PE

Dabei sind LI - L3 die Phasenleiter, N ist der Neutralleiter und PE ist der Schutzleiter. Das Testergebnis wird via Zigbee an ein Endgerät (z.B. Mobil- telefon) übertragen und per App angezeigt. Per Dateiexport aus der App zum Testnachweis zur Verfügung gestellt werden.

Fig 4 zeigt das für die Test-Logs spezifizierte Log-Format, mittels dessen Log-Informationen als Datagramme bzw. Daten- frames übertragen werden können.

Jeder Test-Log Eintrag besitzt eine fortlaufende OID (Object ID), einen Zeitstempel (timestamp) und einen Escort- Datenbereich flexibler Länge (bis maximal 32 Byte). Über die Escort-Daten ist es möglich, Details des Testergebnisses im Log zu speichern, beispielsweise Teststatus, Fehlerstrom, Isolationsmesswerte. Im Folgenden ist eine Auflistung aller Felder des Test-Log von Fig. 4 angegeben.

OID (Object ID): Identifikationsnummer des Eintrags

Reference: Referenz auf weiteren Eintrag

Timestamp: Zeitstempel

Flags: Flagregister enthält Valency, Category, etc .

Context: Systemkontext (0x0001) für Drahtlos- system

ID: Event ID (1001 für

REMOTEJZONTROLJVUX ILIARYJTESTJRESULT)

SRC Quellgerät z.B. 7 für RCA Gerät.

LEN: Größe des Feldes „Escort-Data" (Anzahl der Bits)

Escort-Data : testbezogene Daten

Bei den Angaben oberhalb der Felder steht „U" für „unsigned integer" und die Zahl danach (z.B. 8, 16, 32) für die Breite in Bits des jeweiligen Feldes.

Unter Nutzung von selbst kreierten Zigbee Kommandos bzw. Be- fehlen sind die Loginformation via Zigbee übertragbar. Dafür eigens spezifizierte Zigbee Kommandos „REQUEST____LOG" zur An- forderung von Log-Informationen zu einem Test und „RESPONSE_LOG" zur Übermittlung der angeforderten Informatio- nen sind in Fig. 5 dargestellt.

Fig. 6 stellt eine Abfrage von Log-Informationen mit Hilfe dieser Befehle dar. Ausgangspunkt ist dabei eine App (z.B. die PowerConfig App von der Firma Siemens), die über einen Datenkollektor ZC, der wie in Fig. 2 gezeigt über das Zigbee- Protokoll mit Zigbee-Endgeräten ED (z.B. für Kommunikation mit Zigbee ertüchtigte Schutzschalter) Informationen aus- tauscht. Bei dem Datenkollektor ZC kann es sich z.B. um das unter der Bezeichung „Powercenter 1000" kommerzialisierte Produkt der Firma Siemens handeln.

In einem ersten Schritt werden im Zuge eines Tests Log- Informationen entsprechend der Beschreibung in Fig. 4 er- zeugt. Der Test kann dabei lokal (z.B. mittels Knopfdruck) oder aus der Ferne (remote) initiiert sein.

Unter Nutzung von Modbus TCP oder Modbus RTU over BLE Gatt (Bluetooth Low Energy) und eines eigen spezifizierten (proprietären) 0x64 Request Log Kommandos fordert die App bzw. die Hardware, auf welcher die App läuft, auf Tests bezo- gene Log-Informationen von Zigbee-Endgeräten am Datenkollek- tor DC an. Der Datenkollektor übersetzt das Modbus-Kommando auf das „REQUEST___LOG" Zigbee Kommando und sendet es entspre- chend an das von der App selektierte Zigbee Endgerät ED. Das Zigbee Endgerät ED verarbeitet das REQUEST___LOG Zigbee-Komman- do und antwortet mit dem RESPONSE___LOG Kommando und gleicher Zigbee Sequenznummer (Sequence Number) und der maximal mögli- chen Log Einträge „ENTRIES". Unter Nutzung von Zigbee Frag- mentierung können so mehrere Log Einträge auf einmal übermit- telt werden, trotz stark limitierter Zigbee-Paketlänge. Durch die Nutzung von einer fragmentierten RESPONSE___LOG Antwort können z.B. 50 Log-Einträge statt in 30 Sekunden in (mit je- weils einer RESPONSE___LOG Antwort pro Eintrag) in 5 Sekunden (mit durchschnittlich 6 Einträgen pro RESPONSE___LOG) übermit- telt werden. Das Ergebnis vom RESPONSE___LOG Kommando kann im Datenkollektor ZC über eigens dafür definierten Datenpunkt nach erfolgreicher Verarbeitung gelesen bzw. abgefragt wer- den. Die mittels mehrerer RESPONSE___LOG Kommandos übertragenen Daten können für die Weiterübertragung durch den Datenkollek- tor ZC zu einem Datenfeld zusammengesetzt werden. Die durch mehrere RESPONSE___LOG Kommandos erhaltenen Daten werden dann zusammen von dem Datenkollektor ZC an die App übertragen (Nachricht TCP (LOG Daten) in Fig. 6). Diese können sich auch auf mehrere Tests beziehen. Dabei können die LOG-Daten über die OID (Object ID) einzelnen Test zugeordnet werden (z.B. signalisiert die Inkrementierung der OID, dass die darauffol- genden Daten einem neuen Test zuzuordnen sind). Die App ist für die Speicherung eines Testprotokolls um eine Testproto- koll-Export-Funktion erweitert. Diese beinhaltet das Auslesen der Log-Einträge von Tests, sowie das Aufbereiten und Forma- tieren in PDF und CSV Format. Mit der Möglichkeit des Datei- exports wird der Nachweis zur Testdurchführung mit dazugehö- rigem Ergebnis erbracht.

In Fig. 7 ist ein weiteres Ausführungsbeispiel für den Erfin- dungsgegenstand gezeigt. Im Gegensatz zu Fig. 6, die die An- wendung der Erfindung für einen Schutzschalter (z.B. MCB, RCD oder AFDD), der mittels eines Datenkollektors ZC Daten mit einer App austauscht (vgl. auch Fig. 2), zeigt, ist in Fig. 7 exemplarisch die Konstellation für einen Niederspannungsleis- tungsschalter gezeigt. Niederspannungsleistungsschaltertypen sind z.B. offene Leistungsschalter (auch als ACB bzw. air isolated circuit breaker bezeichnet) und geschlossene Leis- tungsschalter (auch als MCCB bzw. molded case circuit breaker bezeichnet) . Diese Schalter kommunizieren häufig direkt und nicht über einen Datenkollektor ZC mit einem Endgerät ED. Ei- ne solche Konstellation ist in Fig. 7 gezeigt. Es wird - z.B. durch Wartungspersonal - ein Test eigeleitet. Dabei handelt es sich z.B. um eine Verlässlichkeitsprüfung für Tripkurven (Leistungsschalter lösen typischerweise gern, einer Auslöse- konfiguration, welche in der Regel als Tripkurve realisiert ist und neben der Stromhöhe auch deren Dauer berücksichtigt, aus). Über eine App (z.B. PowerConfig App der Firma Siemens ) werden Tripkurveneinstellungen für den Test an den Leistungs- schalter (hier: ACB) kommuniziert. Es wird dann eine Testsze- nario (evtl, auf Vorschlag durch die App) ausgewählt und ge- startet. Entsprechend dem Szenario wird eine Wellenform (ty- pischerweise Strom) vorgegeben. Auf dieser Basis startet der ACB dann den Test. Während des Tests kann mit ping-Nachrich- ten überprüft werden, dass keine Kommunikationsstörung zwi- schen App und ACB vorliegt. Der Test beim ACB wird durchge- führt, bis eine Abschlusskriterium erfüllt ist. Dieses ist entweder die Auslösung des Schalters (Tripping) oder der Ab- lauf eines Timers (wenn der Schalter nicht auslöst). Das Tes- tende und ggf. die Tatsache, dass der Schalter ausgelöst hat, werden nacheinander an die App kommuniziert. Während des Tests werden - vergleichbar wie oben beschrieben - LOG-In- formationen zum Test gespeichert und können auch mit den Kom- mandos REQUEST____LOG bzw. RESPONSE_LOG von der App abgefragt werden. Für die Übertragung kommt dabei als Protokoll z.B.

TCP oder Bluetooth zum Einsatz. Ähnlich wie bei Fig. 6 können LOG-Informationen aus der App exportiert werden. Diese können z.B. einen durch die App generierten Bericht umfassen, der evtl, durch die App in der Cloud gespeichert wird.

Die Erfindung wurde oben im Zuge von Ausführungsbeispielen näher erläutert. Diese sind nur illustrativ. Die Erfindung kann über den gesamten Bereich der Niederspannungstechnik und darüber hinaus zum Einsatz kommen. Z.B. kann die Erfindung auch für Tests von Niederspannungsschalter, die für eine Nie- derspannungssteuerung einer Mittelspannungsleistungsschalters zum Einsatz kommen, verwendet werden.