4.1. Ereignisverarbeitung und -protokollierung
4.1.1. Problemstellung
Neben kontinuierlichen Änderungen der Meßwerte treten im Netzbetrieb unstetige Übergänge und Handlungen auf, die als
Ereignis bezeichnet werden. Beispiele sind die Aussendung von Schaltbefehlen, das Kommen und Gehen von Störmeldungen und Grenzwertüberschreitungen von Meßwerten. Die meisten dieser Ereignisse stellen spontane Netzzustandsänderungen dar. Die Buchführung über den Netzbetrieb erfordert, daß die Ereignisse auf zwei verschiedene Weisen behandelt werden:
sie müssen auf schnellstem Weg in die Datenbank eingetragen werden, damit hier der jeweils aktuelle Netzzustand wiedergegeben wird („Zustandsbuchführung"), und
sie müssen zusammen mit der Zeit ihres Auftretens in chronologischer Folge in einem Speicher hinterlegt werden, um später den Betriebsablauf nachvollziehen zu können („Ereignisbuchführung").
Die Signale von Schalterstellungen werden in Fernwirksystemen typischerweise als Doppelbit (positiv EIN / positiv AUS) übertragen; ferngesteuerte Schalter besitzen darüber hinaus EIN/AUS-Befehle, über die während der Laufzeit buchgeführt werden muß. Andererseits werden die Signale von Stör- und Schutzmeldungen typischerweise als Einfachbit übertragen und besitzen somit nur zwei potentielle Zustände (Meldung gekommen / Meldung gegangen). Schalt- und Steuerbefehle werden vom Betriebsführer über graphische Oberflächen ausgelöst, Rückmeldungen sowie Schutz- und Störmeldungen erfolgen spontan aus dem Prozeß (bzw. im Trainingssimulator aus den entsprechenden Modellen) und werden an der graphischen Oberfläche durch geeignete Symbole dargestellt.
Diese unterschiedlichen Ereignisarten führen in Netzleitsystemen vielfach zu Lösungen, bei denen Schalterstellungsmeldungen einerseits und Stör- und Schutzmeldungen andererseits auf getrennten Wegen behandelt werden; teilweise werden letztere Informationen nicht in die Datenbank aufgenommen, sondern nur während der Zeit ihres Bestehens einer getrennten Zustandsbuchführung unterworfen.
In der GDL-Netzbeschreibung - und demzufolge auch in der Datenbank - werden beide Meldegruppen einheitlich behandelt, so daß zweckmäßigerweise auch in der Ereignisverarbeitung ein einheitlicher Programmweg gefunden werden muß.
Bei einer Zustandsänderung in der Datenbank ist es erforderlich, weiterverarbeitende Programme von diesem Ereignis zu unterrichten. Beispielsweise muß die Schaltanlagenbild-Darstellung den neuen Zustand auch im Bild darstellen. Außerdem kann es erforderlich sein, für höhere Funktionen des Leitsystems (z. B. Netzsicherheitsrechnung) die aktuelle Topologie neu zu bestimmen.
Für die Ereignisbuchführung ist es sinnvoll und üblich, dem Betriebsführer ein
Ereignisprotokoll anzubieten, in dem die eingetroffenen Ereignisse chronologisch aufgelistet werden. Dadurch entsteht aber eine Durchmischung von Ereignissen der verschiedenen Lokationen und Arten. Interessiert sich der Betriebsführer - wie es meist der Fall ist - für spezielle Gruppen von Ereignissen, so muß er sich diese selbst aus einer unter Umständen länglichen Folge zusammensuchen. Um diese Schwierigkeit zu überwinden, wird oft der Weg begangen, mehrere Ereignisspeicher anzulegen und die Ereignisse nach fest programmierten oder parametrierten Vorgaben in diese Puffer zu sortieren. Dadurch wird aber die Aufgabe erschwert, den Betriebsablauf insgesamt zu verfolgen.
In ausgeführten Netzleitsystemen ist vielfach die Möglichkeit gegeben, zu einem Ereignis einen vom Betriebsführer eingegebenen Kommentar zu hinterlegen. Diese Möglichkeit wird genutzt, um über ungewöhnliche Ereignisse näher Bericht erstatten und damit anderen Betriebsführern die Interpretation des Ereignisses erleichtern zu können. Für den Simulator wird ebenfalls ein Kommentarsystem benötigt; insbesondere kann der Trainer dann Fehler eines Trainees, die er während der Sitzung entdeckt, kommentieren und später bei einer Nachbesprechung nochmals darauf eingehen.
4.1.2. Lösungskonzept
Aus den im vorigen Abschnitt geschilderten Problemstellungen ergibt sich der folgende Funktionsumfang der Ereignisverarbeitung:
Bereitstellung einer Eingabeschnittstelle für alle Programme, die Ereignisse erzeugen können,
Eintrag in die Zustandsbuchführung,
Eintrag in die Ereignisbuchführung,
Anstoß weiterverarbeitender Programme und
Protokollierung der Ereignisse.
Zur Entkopplung der einzelnen Teilfunktionen wird die Ereignisverarbeitung in mehrere Programme strukturiert. Insbesondere Wartezeiten von Programmen, die Ereignisse an die Ereignisverarbeitung übergeben, können dadurch reduziert werden.
Sollen Informationen über Ereignisse zwischen Programmen ausgetauscht werden, müssen sie in ein Format gefaßt werden, das von diesen Programmen interpretierbar ist. Bei gleichzeitiger Verwendung unterschiedlicher Formate innerhalb eines Systems wirkt sich die dann notwendige Konvertierung negativ aus, denn einerseits können Fehler in den erforderlichen Umsetzungstabellen vorhanden sein und andererseits wird mehr Rechenzeit benötigt. Um dies zu umgehen, wird in allen Stufen der Erzeugung und Verarbeitung von Ereignissen ein einheitlich strukturiertes Format verwendet, das im folgenden
Ereigniselement genannt wird. Da Ereignisse an Spezies mit unterschiedlichen Wertrahmenlängen behandelt werden müssen, weisen die Ereigniselemente unterschiedliche Längen auf. In den verschiedenen Stadien der Verarbeitung wird die Struktur und Länge des Elements nicht geändert, der Inhalt jedoch variiert (vgl. 4.1.3.5).
Die Ereigniselemente werden nicht in der Ereignisverarbeitung erzeugt, sondern nur weiterverarbeitet. Die Programme, die Ereigniselemente generieren - nachfolgend erzeugende Programme genannt - müssen in der Lage sein, selbst zu entscheiden, welche Bearbeitungsschritte der Ereignisverarbeitung erfolgen müssen bzw. welche Schritte ausgelassen werden können. Diese
Außensteuerbarkeit bietet den Vorteil, bei Einführung neuer Spezies und deren Behandlung nicht entsprechende Programmänderungen in der Ereignisverarbeitung vornehmen zu müssen, sondern nur im erzeugenden Programm die Behandlung des Ereignisses zu implementieren. Die Information über die von der Ereignisverarbeitung durchzuführenden Teilschritte werden im
Itinerarwort des Ereigniselements (siehe 4.1.3.1) hinterlegt. Das für eine Spezies normalerweise zu verwendende Itinerarwort kann dem Diktionar entnommen werden, allerdings ist es dem erzeugenden Programm freigestellt, dieses Itinerarwort zu modifizieren.
Um den Betriebsführer auf einen (z.B. durch Schutzauslösung) ungewollten Zustand eines Schaltgeräts aufmerksam zu machen, wird ein solcher Zustand als „nicht quittiert" in der Datenbank geführt. Durch geeignete Wahl des entsprechenden Symbols im Anlagenbild (z.B. blinkend) wird die Aufmerksamkeit des Betriebsführers erregt. Stellungsmeldungen aus dem Prozeß werden immer mit dem Attribut „nicht quittiert" generiert, da aus einer Stellungsmeldung nicht ersichtlich ist, ob sie aufgrund einer Schutzauslösung oder eines Steuerbefehls aufgetreten ist. Um nicht jede vom Betriebsführer durch Schaltbefehl initiierte Stellungsänderung zusätzlich quittieren zu müssen, wird eine automatische Quittierung aller durch Fernsteuerung erfolgten Stellungsänderungen gefordert.
GDL bietet die Möglichkeit, in Textausdrücken mittels Verwendung von Wildcards (Platzhalter) Bedingungen zu formulieren, mit deren Hilfe Teilmengen eines Ausgangsdatensatzes spezifiziert werden können. Diese Möglichkeit wurde bisher für die Datenbankanfrage verwendet, indem beispielsweise nach dem Zustand aller Leistungsschalter in der Unterstation ADORF durch Eingabe der folgenden Zeichenkette gefragt werden kann:
'''ADORF''?'?[LS=?]
Dieses Prinzip kann mit Hilfe einiger Erweiterungen auch auf einen Ereignisspeicher angewendet werden. Daraus folgt, daß die Unterteilung in verschiedene Ereignisspeicher unterschiedlicher Klassen unterbleiben kann. Statt dessen wird nur ein einziger Ereignisspeicher angelegt, in den alle Ereigniselemente eintragen werden. Der Bediener kann dann durch Eingabe von zur Laufzeit definierten oder vorab gespeicherten
Filterbedingungen die Teile des Ereignisspeichers ausfiltern lassen, die für seine aktuelle Betriebsaufgabe relevant sind.
Die Eingabe und Anzeige von Ereigniskommentaren muß unterstützt werden. Zur Speicherung des Kommentartextes ist die Möglichkeit denkbar, nach jedem Element im Ereignisspeicher Platz für den Eintrag eines Kommentars zu lassen. Dies würde die Größe des Ereignisspeichers stark anwachsen lassen. Da nur wenige Ereignisse kommentiert werden müssen, werden die Kommentare in eine separate Datei geschrieben und im Ereignisspeicher nur die Anfangsadresse des Kommentars im Kommentarspeicher hinterlegt. Die Anzeige bzw. die Eingabe eines Kommentartextes wird sinnvollerweise in die Protokollanzeige integriert.
4.1.3. Realisierung
Für das Verständnis der Funktionsweise der Ereignisverarbeitung und Protokollierung ist zunächst eine Beschreibung des Aufbaus eines Ereigniselements erforderlich. Anschließend werden die Teilprogramme der Ereignisverarbeitung beschrieben und an einem Beispiel das Zusammenwirken der beteiligten Programme geschildert.
4.1.3.1. Aufbau des Ereigniselements
Die Änderung des Zustands einer Spezies läßt sich auf zwei verschiedene Weisen ausdrücken [RUM-83]:
Im
Zustandsmodus wird für jede Attributgruppe ein neues Attribut in die Datenbank eingetragen, d.h. der komplette Wertrahmen der Spezies wird beim Eintrag überschrieben. Für die Quellform wird zusätzlich vereinbart, daß für nicht angegebene Attribute der Grundzustand angenommen wird.
Im
Ereignismodus kann der Zustand einer oder mehrerer Attributgruppen verändert werden. Die übrigen Attributgruppen werden von dem Ereignis nicht betroffen.
Zur Verdeutlichung soll das folgende Beispiel dienen: die einem Leistungsschalter
LS zugeordneten Attribute sind
(ZWI/AUS/EIN/STO)(QIT/-).
In der Quellform wird der Zustandsmodus durch Verwendung von runden Klammern ausgedrückt; fehlen diese Klammern, wird Ereignismodus angenommen.
LS=(EIN QIT-) beschreibt also den vollständigen
Zustand des Leistungsschalters
LS (eingeschaltet und nicht quittiert).
LS=(EIN) beschreibt explizit den Zustand der ersten Attributgruppe. Implizit wird für die zweite Attributgruppe der Grundzustand
QIT gesetzt.
LS=EIN beschreibt im
Ereignismodus, daß der Leistungsschalter eingeschaltet wurde; der Quittierungszustand bleibt unverändert.
Ereignisse aus dem Prozeß (oder der Prozeßsimulation) werden grundsätzlich im Ereignismodus formuliert; der Betriebsführer hingegen hat auch die Möglichkeit, durch Handeingabe Ereignisse im Zustandsmodus zu formulieren.
Da die Ereignisverarbeitung auch in der Lage sein muß, einen Meldeschauer, wie er beispielsweise bei einer Großstörung auftritt, in möglichst kurzer Zeit zu verarbeiten, wird ein Format gewählt, das den Eintrag in die Zustandsbuchführung rechenzeitoptimiert erlaubt. Eine Darstellung der Struktur ist in Bild 4.1 gezeigt.
Folgende Informationen müssen für eine eindeutige Beschreibung eines Ereignisses im Ereigniselement hinterlegt werden:
Zeitpunkt des Ereignisses,
Ort des Ereignisses (Lokation),
Angabe des betroffenen Objekts (Spezies),
Beschreibung der Zustandsänderung (im Zustands- oder Ereignismodus) und
Behandlungsanweisungen an die Ereignisverarbeitung (Aufgrund der Forderung nach Außensteuerbarkeit).
Bedingt durch die verschiedenen Längen der Wertrahmen unterschiedlicher Spezies haben die Elemente unterschiedliche Längen. Um einen Speicherbereich, der Ereigniselemente enthält, von oben nach unten bzw. von unten nach oben lesen zu können, wird die Länge des Elements am Anfang und am Ende eines jeden Elements eingetragen. Unvollständig übertragene Elemente können auf diese Weise ebenfalls leicht identifiziert werden.
Bild 4.1.: Format des Ereigniselements
Im zweiten Wort wird der Datenbankbereich (Bankart, Region und Flur) angegeben, in den das Ereignis eingetragen werden soll. Für eine Beschreibung des genauen Aufbaus des Itinerarwortes, das im dritten Wort des Ereigniselements zu finden ist, sei auf [LIT-95] verwiesen. In den folgenden zwei Worten ist der Zeitpunkt hinterlegt, an dem das Ereignis eingetreten ist.
Um den Eintrag rechenzeitoptimiert zu gestalten, weist das Element für die verschiedenen Stufen des Deskriptors (Lokation und Spezies) unterschiedliche Codierungen (Lokation als ASCII-Text, Spezies als Bitmuster) auf, die aber in der GDL-Datenbank ebenso verwendet werden. Auch das Bitmuster, das die Attribute beschreibt, ist mit der Codierung in der Datenbank identisch. Deshalb entfallen rechenzeitintensive und gegebenenfalls fehlerhafte Umcodierungen des Elements.
Nach der Lokationsangabe findet man im 16. Wort die Speziesnummer, deren Zustand in der Datenbank aktualisiert werden muß. Für die Belegung der folgenden Worte wird eine Fallunterscheidung getroffen:
Im
Ereignismodus werden im Bereich A (vgl. Bild 4.1) die Stellen mit einem Bitmuster belegt, die mit der zu aktualisierenden Attributuntermenge korrespondieren. Welche Stellen im Bereich A gültige Informationen enthalten, wird parallel im Bereich B mit gesetzten Bits gekennzeichnet.
Im
Zustandsmodus wird der vollständige Wertrahmen der Spezies im Bereich A belegt. Der Bereich B wird von dem Programm, das das Element erzeugt, nicht benutzt; dieser Bereich wird für die Hinterlegung des Altzustands genutzt, der aus der Datenbank ausgelesen wird.
Ist das Ereignis an einer relativen Spezies eingetreten, so muß die zugehörige absolute Spezies im drittletzten Wort des Elements angegeben werden, da relative Spezies mehrfach innerhalb einer Lokation eingesetzt werden dürfen und erst durch Angabe der absoluten Spezies eindeutig identifizierbar sind.
Die Belegung der im vorletzten Wort angegebenen Ereignisattribute wurde im Trainingssimulator nicht implementiert. Hier ist für eine Leitsystemanwendung vorgesehen, eine Verknüpfung von Ereignissen zu ermöglichen, z.B. eine Schalterstellungsänderung durch Angabe eines Attributs wie „durch Fernsteuerung" oder „durch Schutzauslösung" genauer klassifizieren zu können.
4.1.3.2. Ereignisverarbeitung
Das Gesamtsystem der Ereignisverarbeitung wird in folgende Teilprozesse gegliedert:
Bereitstellung einer im lokalen Rechnernetz des Simulators erreichbaren Eingabeschnittstelle,
Aktualisierung der Zustandsbuchführung und Anstoß der SchaltarbeitsplatzOberflächen durch die
Primärereignisverarbeitung,
Programmanstoß weiterverarbeitender Programme und Aktualisierung der Ereignisbuchführung durch die
Sekundärereignisverarbeitung und
Darstellung der Ereignisse durch das
Protokollierungssystem mit zentralem Server für Ereignisspeicherzugriff und Kommentarspeicherverwaltung sowie Protokolldarstellungen auf mehreren verteilten Workstations.
Eine Gesamtdarstellung der Programmstruktur ist in Bild 4.2 zu finden.
Das Programm
Primärereignispuffereintrag (PEPE) stellt allen in den Simulator integrierten Programmen die Kommunikationsschnittstelle zur Verfügung, über die Ereigniselemente in den
Primärereignispuffer eingetragen werden können. Vorher werden die Elemente auf Vollständigkeit geprüft und mit einem Zeitstempel versehen, sofern die entsprechenden Stellen im Ereigniselement leer sind. Für die Kommunikation zwischen dem erzeugenden Programm und PEPE wurden die Betriebssystembefehle der Socket-Schnittstelle gewählt, da sie die höchste Übertragungsrate aufweisen. Kurze Antwortzeiten für die Quittierung des Empfangs von Ereigniselementen können aufgrund des geringen Funktionsumfangs erreicht werden.
Die
Primärereignisverarbeitung (PEV) entnimmt die Ereigniselemente aus dem Primärereignispuffer, sucht mit Hilfe des bei der Übersetzung der Quelldaten in Kartuschen angelegten Adreßflurs die im Element angegebene Spezies in der Datenbank und ändert die Attribute dieser Spezies. Weiterhin werden die alten und neuen Attribute der Spezies im Ereigniselement vermerkt.
Beim Eintrag von Elementen im Ereignismodus wird die Ereignisaussage in eine Zustandsaussage umgewandelt, indem der in der Datenbank vorgefundene alte Zustand zwischengespeichert, der neue Zustand durch Eintrag des Ereignisses erzeugt und der so entstehende neue Zustand zusammen mit dem zwischengespeicherten alten Zustand in das Ereigniselement eingetragen wird. Für die Protokollierung der Ereignisse läßt sich die Zustandsaussage alt/neu wieder in eine Ereignisaussage rückverwandeln (siehe 4.1.3.3).
Bild 4.2.: Ereignisverarbeitung und Protokollierung
Außerdem ist in der PEV die automatische Quittierung von Stellungsmeldungen aus dem Prozeß realisiert. Hierzu werden die Attribute der (absoluten) Spezies eines Schaltgeräts mit der (relativen) Spezies der Fernsteuerung verknüpft. Wenn die PEV erkennt, daß der neue Schaltzustand mit dem entsprechenden Zustand der Fernsteuerung korrespondiert, wird zusätzlich das Attribut „quittiert" am Schaltgerät eingetragen. Zum Abschluß der Verarbeitung wird das Element von der PEV in den
Sekundärereignispuffer eingetragen.
Die
Sekundärereignisverarbeitung (SEV) liest aus diesem Ringpuffer das Element, um es einerseits in den Ereignisspeicher einzutragen und andererseits weitere Programme anstoßen zu können. Die SEV überwacht die Laufzeit von Fernsteuerbefehlen, indem in ein Feld zunächst alle eintreffenden Steuerbefehle eingetragen werden. Trifft nun die entsprechende Stellungsmeldung aus dem Prozeß ein, kann der zugehörige Eintrag im Feld wieder gelöscht werden. Steht der Eintrag eines Steuerbefehls länger als dreißig Sekunden in dem Feld, wird am Trainerarbeitsplatz eine entsprechende Warnung ausgegeben.
4.1.3.3. Protokollierung
Zur Selektion bestimmter Ereignisse aus dem gemeinsamen Ereignisspeicher wird zunächst die Leitstellendefinition (siehe 3.5) eingesetzt. Um die Menge der anzuzeigenden Ereignisse in einer Leitstelle weiter einzugrenzen, können vom Bediener Filterbedingungen formuliert werden, mit deren Hilfe zur Laufzeit der vorhandene Speicher durchsucht und nur die der aktuellen Bedingung genügenden Elemente ausgefiltert und zur Anzeige gebracht werden.
Tabelle 4.1 zeigt eine Übersicht über die definierbaren Filterbedingungen.
| Name | betroffene Ereignisse | Beispiel |
| lokal | aus Schaltanlagen/Kraftwerken | MBT |
| Numeral | aus Spannungsebene/Kraftwerksblock | 220 |
| Partial | aus Schaltfeldern | JUKL_N |
| Startzeit | entstanden nach der Startzeit | 08:00 |
| Endezeit | entstanden vor der Endezeit | 16:00 |
| Spezies | innerhalb vordefinierter Speziesgruppen | Leistungsschalter |
Tabelle 4.1.: Definierbare Filterbedingungen
Alle Bedingungen werden UND-verknüpft. In den Feldern Lokal, Numeral und Partial werden Wildcard-Zeichen am Anfang bzw. am Ende der eingegebenen Zeichenkette akzeptiert. Bei geeigneter Namensgebung der Unterstationen und Felder lassen sich so bestimmte Teilbereiche des Netzes bestimmen, aus denen dann die Ereignisse angezeigt werden. Beispiele zeigt Tabelle 4.2:
| Lokal | Numeral | Partial | Start | Ende | Spezies | Bedeutung |
| MBT | ? | ? | 8:00 | 16:00 | alle | alle Ereignisse der Unterstation MBT in der Zeit zwischen 8 Uhr und 16 Uhr |
| ? | 380 | ? | | | Leistungsschalter | alle Leistungsschalter im 380 kV-Netz |
| ? | ? | ?MBT? | | | alle | alle Ereignisse in Feldern, die im Partialnamen die Zeichenfolge MBT enthalten |
Tabelle 4.2.: Beispiele für Filterdefinitionen
In einer weiteren Datei können unterschiedliche Spezies zu sogenannten Speziesgruppen vereinigt werden. Beispielhafte Definitionen sind in Tabelle 4.3 zu finden.
| Gruppenname | Bereich | Beispiele für Verwendung |
| Leistungs- und Lastschalter | (0032-0063), (1056-1087) | Untersuchung umfangreicher Schutzauslösungen |
| Kraftwerke | (1856-1951) | Einsatz des Programms in einem Kraftwerksarbeitsplatz |
| Grenzwertverletzungen | (0448-0449), (1600-1667) | Verfolgung von Überlastwarnungen |
| Frequenzschutzeinrichtungen | (1994) | Auflistung aller betroffenen Lastabgänge |
Tabelle 4.3.: Definitionen von Speziesgruppen>
Die angegebenen Nummern entsprechen den Speziesnummern im Diktionar. Mit der Vergabe dieser Nummern durch den Beschreiber wird eine Klassifizierung der Spezies für alle verarbeitenden Programme vorgenommen. So wird z.B. einem Leistungsschalter - unabhängig von seinem Namen - durch Zuweisung einer Speziesnummer aus dem Bereich von 32 bis 48 eindeutig die Eigenschaften eines Leistungsschalters verliehen. Da die weiterverarbeitenden Programme die Klassifizierung der Spezies kennen, wird ein Leistungsschalter auch als solcher - insbesondere in der Verriegelung (siehe 3.4.3) - behandelt.
Beim Eintrag in die Datenbank werden die Ereigniselemente gegebenenfalls in den Zustandsmodus umgewandelt. Die Ausgabe der Ereignisse kann jedoch nach Vorgabe des Bedieners variiert werden, indem die Elemente im Zustandsmodus verbleiben oder in den Ereignismodus rückverwandelt werden. Außerdem kann angegeben werden, ob nur der neue Zustand angezeigt werden soll und ob der im Diktionar hinterlegte Langname oder statt dessen die betrieblich genutzte Abkürzung verwendet werden soll. Die folgende Tabelle 4.4 gibt - ohne Anspruch auf Vollständigkeit - eine Darstellung mehrerer Möglichkeiten.
| Ereignis (ohne Lokation) | Zustand/Ereignis | nur Neuzustand | Langname |
| LS (AUS QIT)=>(EIN QIT) | Zustand | nein | nein |
| LS (AUS=> EIN) | Ereignis | nein | nein |
| LS = (EIN QIT) | Zustand | ja | nein |
| LS = EIN | Ereignis | ja | nein |
| Leistungsschalter = EIN | Ereignis | ja | ja |
Tabelle 4.4.: Variationen der Ereignisausgabe
Um den gleichzeitigen Zugriff mehrerer Programme auf den Ereignisspeicher zu ermöglichen, ist das Protokollierungssystem in zwei getrennte Prozesse unterteilt, wie schon in Bild 4.2 gezeigt wurde. Für die Anzeige der Ereignisse wurde ein Programm entwickelt, das die graphische Bedienoberfläche zur Verfügung stellt, die in Bild 4.3 dargestellt ist. Über die Mailboxschnittstelle zwischen Server und Anzeigeprogramm werden Teile oder aber auch der gesamte Ereignisspeicher übertragen. Außerdem werden vom Server die Ereigniselemente übermittelt, die während des Ablaufs auftreten, so daß die Anzeige der Elemente auf dem Bildschirm laufend aktualisiert werden kann.
Am oberen Rand der Bedienoberfläche sind mehrere Icons zu erkennen, mit denen die Auswahl der Leitstelle, die Definition eines Filters, die Selektion verschiedener Optionen (u.a. die Darstellung des Ereignisses gemäß Tabelle 4.2) und die Sicherung von Protokollinhalten in Dateien ausgeführt werden kann. Mit den am rechten Rand erkennbaren Pfeiltasten kann man den auf dem Bildschirm dargestellten Ausschnitt verschieben. Außerdem ist im Bild 4.3 das Popup zur Definition der Filterfunktionen dargestellt. In diesem Beispiel erzeugt der Filter eine Unterdrückung aller Ereignisse, die nicht in der der Unterstation SOLIN entstanden sind.
Bild 4.3. Protokoll mit Filtermenue: Ereignisverarbeitung und Oberflächenfunktion
4.1.3.4. Kommentare
Kommentare zu bestimmten Ereignissen werden ebenfalls zentral auf dem Datenbankrechner verwaltet, damit sie in allen Protokollen angezeigt werden können, in denen dasselbe Ereignis erscheint. Zu diesem Zweck müssen die Kommentare den Ereignissen eindeutig zugeordnet werden können. Dazu wird nach jedem Ereigniselement im Ereignisspeicher ein 16bit-Wort angelegt und dazu benutzt, eine Verweisadresse auf den Kommentarspeicher zu hinterlegen.
Im Bild 4.3 erkennt man, daß für zwei Ereignisse ein Kommentar vorliegt, da in den entsprechenden Zeilen das Zeichen „K" vorangestellt ist. Selektiert der Bediener durch Mausklick eine solche Ereigniszeile, wird ein Popup angezeigt (siehe Bild 4.4), in dem der Kommentartext zu lesen und zu editieren ist. Wird ein Ereignis selektiert, zu dem noch kein Kommentar eingetragen wurde, ist der Textbereich im Popup leer.
Bild 4.4.: Kommentar-Popup
Der an einem Arbeitsplatz eingetragene Text wird zum Server übertragen, der ihn einerseits in den Kommentarspeicher kopiert und andererseits die Startadresse des Texts im Kommentarspeicher in den Ereignisspeicher einträgt. Damit ist sichergestellt, daß dem Ereignis der Kommentar wieder eindeutig zugeordnet werden kann.
Weiterführende Informationen sind in [OPG-95] zu finden.
4.1.3.5. Beispiel: Verarbeitung eines Fernsteuerbefehls
Es soll nun abschließend die Behandlung eines Ereignisses durch das erzeugende Programm, die Ereignisverarbeitung und die weiterverarbeitenden Programme geschildert werden. Als Beispiel soll die Einschaltung eines Leistungsschalters durch Fernsteuerung dienen.
Im folgenden wird der Inhalt des Ereigniselements verkürzt in einer an GDL angelehnten Semantik beschrieben. Der Inhalt des Itinerarwortes wird als Textbeschreibung vorangestellt. Die Angabe von Zeit, Bankart, Region und Flur entfallen aus Gründen der Übersichtlichkeit. Mit
LS wird der Leistungsschalter, mit
*F seine Fernsteuerungseinrichtung bezeichnet. Die zugehörigen potentiellen Attribute zeigt Tabelle 4.5.
| | Leistungsschalter (LS)
(ZWI/AUS/EIN/STO) (QIT/-) | | Fernsteuerung (*F)
(INA/EBF/ABF/0)(-/BLC) |
| ZWI | Zwischenstellung | INA | inaktiv, d.h. es läuft kein Befehl |
| AUS | ausgeschaltet | EBF | ein-Befehl läuft |
| EIN | eingschaltet | ABF | aus-Befehl läuft |
| STO | Störstellung | 0 | nicht benutzt |
| QIT | quittiert | BLC- | nicht blockiert |
| QIT- | nicht quittiert | BLC | blockiert |
Tabelle 4.5.: Potentielle Attribute zu LS und *F
Ausgangspunkt der folgenden Betrachtung ist das dreistufigen Bildsystem. Hier wird ein Element mit der Aussage
Ereignis-Modus, nicht in den Ereignisspeicher:
'''ADORF''220'BDORF[LS*F=EBF]
generiert, nachdem der Bediener das entsprechende Symbol im Anlagenbild angeklickt und im daraufhin erscheinenden Schaltfenster den neuen Zustand ausgewählt hat. Dieses Element wird von PEPE entgegengenommen, auf Vollständigkeit geprüft und in den Ringpuffer eingetragen. Ist das Element unvollständig, wird es verworfen und das sendende Programm entsprechend benachrichtigt.
Die PEV entnimmt das Element und sucht die entsprechende Stelle in der Datenbank, an welcher der aktuelle Zustand der Fernsteuerung des Leistungsschalters im Feld BDORF der Schaltanlage ADORF 220kV hinterlegt ist. Das Ereignis wird eingetragen und das Element unter Verwendung des Altzustands vom Ereignis- in den Zustandsmodus umformuliert:
Zustands-Modus, nicht in den Ereignisspeicher:
'''ADORF''220'BDORF[LS*F (INA BLC-) => (EBF BLC-)]
Anschließend wird das so modifizierte Element in den Sekundärereignispuffer eingetragen.
Die SEV übernimmt dieses Element aus dem Puffer. Da im Ereignisspeicher hauptsächlich nur die Ereignisse hinterlegt werden sollen, die einen Einfluß auf den Netzzustand haben, wird vom Programm, das das Ereignis formuliert hat, im Itinerarwort der Eintrag „nicht in den Ereignisspeicher" hinterlegt. Folglich unterbleibt dieser Eintrag. Da das Element eine Fernsteuerung eines Schaltgeräts darstellt, wird dieser Befehl in die von der SEV verwalteten Liste eingetragen, die alle laufenden Fernsteuerbefehle enthält.
Aus dem Itinerarwort entnimmt die SEV die Information, daß das Schaltsimulationsprogramm benachrichtigt werden muß, dessen Aufgabe es ist, die Umsetzung von Fernsteuerbefehlen in Stellungsmeldungen durchzuführen. Dieses Programm simuliert zusätzlich die Laufzeit eines Befehls auf der Fernwirkstrecke und die Laufzeit von Trennschaltern. Das von diesem Programm entsprechend modifizierte Element hat dann folgende Gestalt:
Ereignis-Modus:
'''ADORF''220'BDORF[LS=(EIN QIT-)]
Dabei ist zu beachten, daß alle von der Schaltsimulation bearbeiteten Elemente den Zustand
QIT- (nicht quittiert) enthalten.
Dieses Element wird an PEPE übermittelt, das es in den Primärereignispuffer einträgt. Die PEV sucht den entsprechenden Eintrag in der Datenbank und trägt die neue Stellung sowie den Quittierungszustand ein. Da zu diesem Leistungsschalter die relative Spezies
*F mit dem Zustand
EBF vorhanden ist, wird das Attribut der relativen Spezies auf
INA korrigiert und der neue Schaltzustand durch Veränderung des Attributs
QIT- auf
QIT am Leistungsschalter automatisch quittiert.
Wäre der Zustand der Fernsteuerung nicht entsprechend der Stellungsmeldung, bliebe der Zustand
QIT- unberührt, da die PEV davon ausginge, daß der Betriebsführer keinen entsprechenden Befehl an das Schaltgerät gegeben hat und somit den neuen Zustand selbst quittieren muß.
Anschließend wird das Element in
Zustands-Modus:
'''ADORF''220'BDORF[LS (AUS QIT) => (EIN QIT)]
umgewandelt und an die SEV übertragen. Die SEV durchsucht nun die Liste der laufenden Befehle und löscht nun den entsprechenden Eintrag. Weiterhin wird von der SEV das Element in den Ereignisspeicher eingetragen.
Da der Protokoll-Server von der Sekundärereignisverarbeitung angestoßen wird, kontrolliert er für jede angeschlossene Oberfläche das mit dem Anstoß übermittelte Ereigniselement, ob es aufgrund der an der Oberfläche eingestellten Filterbedingung angezeigt werden muß. Ist dies der Fall, wird es an die entsprechende Protokolloberfläche übertragen und von dieser angezeigt.
Tiefergehende Informationen und weitere Beispiele sind in [LIT-95] dargestellt.
4.2. Anbindung des dynamischen Modells an die Ereignisverarbeitung
4.2.1. Problemstellung
Um Konsistenzprobleme zu vermeiden, muß die Prozeßdatenbank einzige Institution der Zustandsbuchführung sein. Diese Bedingung war in der Prototypversion nicht erfüllt, da die aktuellen Zustände der Kraftwerke und Lasten nur modellintern geführt wurden; die in der Prozeßdatenbank hinterlegten Kraftwerks- und Lastdaten dienten nur zur Definiton des Zustands beim Start der Simulationsrechnung und wurden nicht aktualisiert.
Die Eingabemöglichkeit für Befehle zur Änderung eines Kraftwerks- oder Lastzustands war nur an der Modelloberfläche vorhanden. Der Trainer mußte zusätzlich zu seinen eigentlichen Aufgaben auch die Führung der Kraftwerke übernehmen. Bei großen Netzverbänden mit vielen Kraftwerken und Lasten ergab sich so eine zu hohe Arbeitsbelastung für den Trainer. Außerdem war es nicht möglich, die Kraftwerksführung - wie in der Realität - auf mehrere Leitstellen bzw. Führungsplätze in verschiedenen Leitstellen zu verteilen.
Es war also notwendig,
die Möglichkeit zu schaffen, auch das Personal einer Kraftwerksleitstelle durch eine geeignete Leitstellennachbildung am Training teilnehmen lassen zu können, um damit auch den Trainer zu entlasten, und
die Inkonsistenzen in der Zustandsbuchführung zu überwinden.
4.2.2. Lösungskonzept
Um die für die Leitstellennachbildung notwendigen Oberflächen entwickeln zu können, ist zunächst eine Schnittstelle zum dynamischen Modell vorzusehen, damit Zustandsänderungen, die durch Befehl von einer Oberfläche vorgegeben werden, in der Modellierung berücksichtigt werden können. Über diese Schnittstelle soll in diesem Abschnitt berichtet werden. Eine detaillierte Beschreibung einer im Rahmen dieser Dissertation entwickelten Kraftwerksbedienoberfläche ist in Abschnitt 4.3 zu finden.
Neben der Möglichkeit, Kraftwerksbefehle an das Modell abgeben zu können, müssen weitere Befehle zur Steuerung der Lasten vorgesehen werden, die im Modell an den Grenzen des in der Simulation dargestellten Netzes zu unterlagerten Spannungsebenen auftreten. Ihre Veränderung simuliert Schaltmaßnahmen, die vom Betriebsführer der dargestellten Netzwarte angewiesen, aber von Personal in untergeordneten Leitstellen oder vor Ort vorgenommen werden. Normalerweise soll daher der Ablauf „Anweisung an den Trainer ® Ausführung der Aktion durch den Trainer" erhalten bleiben. Dies ist insbesondere erforderlich, wenn die verbale Kommunikation, die in der Realität über Telefon oder Betriebsfunk abläuft, ebenfalls trainiert werden soll. Falls dies in speziellen Trainingsaufgaben nicht nötig erscheint, kann der Trainer von dieser Aufgabe entlastet werden. Deshalb soll alternativ die Möglichkeit eingeräumt werden, die Lasten außerhalb der Modelloberfläche steuern zu können.
Die Steuerung des dynamischen Modells von außen bezüglich des Verhaltens der Kraftwerke und Lasten läßt sich erreichen, wenn man die Befehlsgabe einheitlich durch Ereigniselemente ausdrückt und über die Ereignisverarbeitung führt. Die sich aus diesem Konzept ergebenden Vorteile sind:
die Aktualisierung der Zustandsbuchführung kann garantiert werden und
die Betriebsabläufe werden im Protokoll sichtbar.
Da mit der Ereignisverarbeitung eine allgemeine Befehls-Schnittstelle zur Verfügung steht, können beliebige Programme zur Formulierung der Befehle eingesetzt werden (in den folgenden Bildern 4.5 und 4.6 PEEG = Primärereigniselement-Generator genannt). Es ergibt sich die in Bild 4.5 gezeigte einfache Kette zur Ausführung eines Befehls. Die Nummer an den Pfeilen gibt den Bearbeitungsschritt an.
Bild 4.5.: Einfache Befehlskette ohne Überprüfung
Die Ausführung eines Befehls an einen Kraftwerksblock erfordert die Erfüllung einer oder mehrerer Bedingungen, die von einer geeigneten Instanz überprüft werden müssen. Diese Überprüfung erfolgt sinnvollerweise im dynamischen Modell, da hier alle notwendigen Daten direkt zur Verfügung stehen. Würde also ein Befehl an einen Kraftwerksblock erteilt, der wegen des aktuellen Zustands nicht ausführbar wäre, müßten die im Schritt 3 bzw. Schritt 5 erfolgten Einträge in die Datenbank bzw. den Ereignisspeicher wieder rückgängig gemacht werden; dieses würde einen erheblichen zusätzlichen Verwaltungsaufwand bedeuten.
Um diese Problematik zu umgehen, wird bei der Übertragung an das dynamische Modell ein Befehl-Ereigniselement zunächst weder in die Datenbank noch in den Ereignisspeicher eingetragen. Erst wenn das Element vom Modell geprüft und als ausführbar akzeptiert worden ist, wird es erneut der Ereignisverarbeitung zugeführt und dann eingetragen. Somit ergibt sich eine Struktur gemäß Bild 4.6:
Bild 4.6.: Vollständige Befehlskette mit Plausibilitätsprüfung
Um einen einheitlichen Weg für alle Kraftwerks- und Laststeuerbefehle zu benutzen, werden die an der Oberfläche des dynamischen Modells eingegebenen Befehle nicht direkt benutzt, sondern auch über die Ereignisverarbeitung geführt; die Oberfläche des Modells wird somit im Sinne von Bild 4.6 als PEEG aufgefaßt.
4.2.3. Realisierung
Um die Abarbeitung des Elements gemäß Bild 4.6 richtig zu steuern, müssen die beteiligten Programme die Elemente mit den folgenden Markierungen im Itinerarwort versehen:
| erzeugendes Programm (PEEG) | dynamisches Modell |
| Eintrag in Datenbank | nein | ja |
| Eintrag ins Protokoll | nein | ja |
| Anstoß von Programmen | ja | nein |
Tabelle 4.6.: Itinierarworte für Kraftwerks- und Lastbefehle
Wegen der sonst unterschiedlichen Behandlung der Befehle an Kraftwerke bzw. Lasten werden beide Bereiche im folgenden in getrennten Abschnitten diskutiert.
4.2.3.1. Befehle zur Kraftwerksführung
Alle im Modell implementierten Befehle an einen Kraftwerksblock müssen durch geeignete Ereigniselemente ausgedrückt werden, damit die Ereignisverarbeitung als universelle Eingabeschnittstelle für alle Befehle des Wartenpersonals verwendet werden kann.
Zwei Varianten sind denkbar:
Für die Befehlsrichtung (Schritte 1 bis 4 in Bild 4.6) werden andere Ereigniselemente verwendet als in Melderichtung (Schritte 5 bis 9 im selben Bild). Dies erfordert eine Umwandlung bzw. Neugenerierung der Ereigniselemente im dynamischen Modell.
Sowohl für Befehls- als auch Melderichtung wird der gleiche Aufbau des Ereigniselements verwendet. Somit entfallen aufwendige Umsetzungen im Modell. Allerdings erfordert dies die eindeutige Abbildung von Befehlen auf einen entsprechenden Zustand in der Datenbank.
Für die meisten Befehle kann die Bedingung der eindeutigen Abbildbarkeit in der zweiten Variante erfüllt werden; somit wurde dieses Verfahren gewählt. Dies gilt allerdings
nicht für die Steuerung des Anfahrvorgangs eines Kraftwerksblocks, da - wie im folgenden geschildert wird - Befehle erteilt werden müssen, die nicht direkt als Zustand in die Datenbank eingetragen werden können; außerdem erfolgen nicht alle Zustandsänderungen aufgrund eines Befehls, sondern automatisch nach Ablauf einer Verzugszeit. Die aus diesen Tatsachen folgende nicht-eindeutige Abbildbarkeit zwischen Befehl und Zustand erfordert die Verwendung unterschiedlicher Spezies mit den zugehörigen Attributen in den verschiedenen Ereigniselementen. Alle anderen Teile des Deskriptors können unverändert aus dem Element der Befehlsrichtung übernommen werden.
Das Anfahrmodell für konventionelle Dampfkraftwerke unterscheidet insgesamt sieben verschiedene Anfahrzustände:
nicht angefahren,
angefahren, aber ohne Kesselspeisepumpe,
Kesselspeisepumpe startbereit,
Kesselspeisepumpe gestartet,
synchronisierbereit,
Synchronisierung läuft und
synchronisiert.
Um nun einen Block vom kalten oder warmen Zustand ans Netz zu bringen, müssen die folgenden Befehle erteilt werden:
anfahren,
Pumpen einschalten und
synchronisieren oder Insel eröffnen.
Bei der Synchronisation eines Kraftwerks wird durch das Synchronisiergerät überprüft, ob die entsprechenden Bedingungen (Spannungs- und Frequenzgleichheit) erfüllt sind. Sollen jedoch mit einem Kraftwerksblock bisher nicht versorgte Netzteile unter Spannung gesetzt werden („Insel eröffnen"), dann muß in praxi das Synchonisiergerät überbrückt werden. Im Simulator wird diese vom Normalfall abweichende Handlung durch einen eigenen Befehl „Insel eröffnen" ausgedrückt.
Tabelle 4.7 zeigt zusammenfassend die verschiedenen Zustände und die dazu korrespondierenden Befehle, die notwendig sind, das Kraftwerk in den nächsten Zustand zu überführen. Auch die Abschaltung eines Blocks wird über die Ereignisverarbeitung vorgenommen. Dazu wird die Vereinbarung getroffen, daß bei einer Abschaltung eines Blocks aus dem Leistungsbetrieb ein Fangen im Eigenbedarf (Zustand „synchronisierbereit") angenommen wird. Will man einen Block vollständig abschalten, muß der Abschaltbefehl nochmals gegeben werden.
| Darstellung des Zustands in der Datenbank | | Befehl zu Fortsetzung des Anfahrvorgangs | |
| Speziesname: ZUSTAND | | Speziesname: KW_BEF | |
| Klartext | Attributname | Klartext | Attributname |
| nicht angefahren | NAF | anfahren | ANF |
| angefahren | ANF | X | |
| Pumpe einschaltbereit | PEB | Pumpen einschalten | PEI |
| Pumpen eingeschaltet | PEI | X | |
| sychronisierbereit | SYB | Synchronisieren
Insel eröffnen | SYN
INS |
| Synchronisierung läuft | SYL | X | |
| Synchronisiert | SYN | (abschalten) | (AUS) |
x: kein Befehl erforderlich, statt dessen Verzugszeit
Tabelle 4.7.: Kraftwerksblockzustände und -befehle
Im dynamischen Modell werden die Ereigniselemente, die mit Hilfe der Spezies
KW_BEF aufgebaut wurden, in die entsprechenden Elemente unter Verwendung der Spezies
ZUSTAND umgewandelt. Die Spezies
ZUSTAND trägt zusätzlich das Attribut (Eigenbedarf versorgt / Eigenbedarf nicht versorgt) mit der Abkürzung
(EBV/-); es wird in der Kraftwerksbedienoberfläche (siehe 4.3) angezeigt, um dem Bediener mitteilen zu können, ob ein Anfahrbefehl erteilt werden kann oder nicht. Bei Änderung des Versorgungszustands des Anfahrtransformators wird ein entsprechendes Ereigniselement vom dynamischen Modell generiert, das dieses Attribut in der Datenbank aktualisiert. Somit kann im Protokoll festgestellt werden, wann der Eigenbedarf eines Kraftwerks versorgt und dann anschließend das Kraftwerk angefahren wurde. Auf diese Weise kann eine unnötige Verzögerung zwischen beiden Ereignissen dokumentiert werden. Weiterhin wird eine Attributgruppe (verfügbar / nicht verfügbar), abgekürzt
(VFB/-), eingeführt, um auf einfache Weise Kraftwerke, die in Revision sind oder durch eine Störung nicht mehr verfügbar sind, von der weiteren Verwendung auszuschließen.
Das Anfahrmodell für Druck- und Siedewasserreaktor-Kernkraftwerke entspricht dem Anfahrmodell der konventionellen Dampfkraftwerke, so daß hier dieselben Spezies mit allen bekannten Attributen verwendet werden können. Für die übrigen Kraftwerksmodelle der Gasturbinen- und Wasserkraftwerke werden ebenfalls dieselben Spezies verwendet, da ihre Zustände eine echte Teilmenge der Zustände der übrigen Kraftwerksmodelle sind. Lediglich der Zustand „Pumpen einschaltbereit" und der Befehl „Pumpen einschalten" entfallen.
Die Tabelle 4.8 gibt Auskunft über die weiteren Befehle, die während des Leistungsbetriebs eines Blocks an das Modell mit Hilfe der Kraftwerksbedienoberfläche erteilt werden können. Hier wird in der Datenbank wie in den Ereigniselementen für die Befehlsgabe dieselbe Spezies verwendet.
| Befehl | Spezies | DKW | WKW | GT | DWR | SWR |
| Wirkleistungs-Sollwert | P.SOLL | x | x | x | x | x |
| Spannungs-Sollwert | U.SOLL | x | x | x | x | x |
| Primärregelungsstatik | STATIK | x | x | x | x | x |
| Normal-/Störfallfahrweise | STOERFW | x | | | x | x |
| Dampferzeuger-Sollwert | P.SOLLKE | x1 | | | x1 | |
| Gleit-/Festdruckfahrweise | DRUCKFW | x | | | | |
| Frischdampfdruck-Sollwert | SOLLDRU | x2 | | | | |
| WT-Gerät ein/aus | GRENZFW | x | x | x | x | |
x: Befehl möglich
x1: Befehl möglich, wenn Störfallfahrweise
x2: Befehl möglich, wenn Festdruckfahrweise
Tabelle 4.8.:Kraftwerksbefehle während des Leistungsbetriebs
4.2.3.2. Befehle zur Laststeuerung
Für die Nachbildung des Lastverhaltens werden zwei verschiedene Lasttypen verwendet. Im ersten Fall handelt es sich um
Stellasten, die vom Trainer zwischen 0% und 100% der in der Netzbeschreibung angegebenen Maximalhöhe verändert werden können. Im zweiten Fall werden
dynamische Lasten simuliert, die sich nach Wiederversorgung in ihrem Lastverhalten selbsttätig ändern. Der Lastgang ist von der Unterbrechungszeit und der Zeit seit der Wiederversorgung abhängig und wird in einer separaten Datei hinterlegt.
An beiden Lasttypen kann ein
frequenzabhängiger Lastabwurf beschrieben werden; für die Funktionsweise und Beschreibung der zugehörigen Parameter in GDL sei hier auf Kapitel 6.2 verwiesen. Um eine abgeworfene Last wiederzuschalten zu können, müssen entsprechende Befehle an das dynamische Modell gesendet werden.
Ebenfalls an beiden Lasttypen kann eine Deaktivierung bzw. Aktivierung der Last erfolgen. Ist eine Last deaktiviert, so wird trotz topologischer Versorgung des Anschlusses keine Leistung dem Netz entnommen. Diese Vorgehensweise ermöglicht die Simulation von Schalthandlungen in nicht mehr auf dem Simulator dargestellten Bereichen wie beispielsweise im Mittelspannungsnetz.
In Analogie zur Steuerung der Kraftwerke soll die Verwendung der Ereignisverarbeitung
eine Steuerung des Lastverhaltens außerhalb der Oberfläche des dynamischen Modells und die Aktualisierung der Lastzustände in der Datenbank ermöglichen. Im Gegensatz zur Kraftwerkssteuerung kann hier der vollständige Befehlssatz eindeutig auf den Lastzustand abgebildet werden; demzufolge kann für Befehls- und Melderichtung dieselbe Spezies verwendet werden.
Tabelle 4.9 gibt Auskunft über die vom Modell akzeptierbaren Last-Steuerbefehle.
| Befehl | Spezies | Lasten | Stell-Lasten |
| Last aktivieren / deaktivieren | (S)LAST | x | x |
| Lasthöhe stellen | *HOEHE | | x |
| Unterfrequenzschutz-Reduktion | *REDUZ | x | x |
Tabelle 4.9.: Lastbefehle
Ansonsten wird der in Bild 4.6 gezeigte Mechanismus der Übertragung und Prüfung der Befehle verwendet.
4.3. Bedienoberfläche für die Kraftwerksführung
4.3.1. Problemstellung
Um die koordinierte Zusammenarbeit des Personals unterschiedlicher Leitstellen trainieren zu können, muß ein Trainingssimulator für die Netzbetriebsführung sowohl einen Schaltarbeitsplatz als auch eine Kraftwerks-Oberfläche anbieten. Für den Schaltingenieur stand schon in der Prototyp-Phase des Simulators ein seiner gewohnten Bedienoberfläche nachgebildeter Schaltarbeitsplatz - wenn auch mit eingeschränkter Funktionalität - zur Verfügung. Die Befehlsgabe an die Kraftwerksblöcke konnte nur an der Trainer-Oberfläche des dynamischen Modells erfolgen.
4.3.2. Lösungskonzept
Mit der Einführung der vollständigen Ereignisverarbeitung (siehe 4.1) und einer entsprechenden Schnittstelle im dynamischen Modell (siehe 4.2) sind die Voraussetzungen geschaffen worden, eine eigenständige Bedienoberfläche zur Steuerung der Kraftwerke zu entwickeln, die es ermöglicht, den Zustand der Kraftwerke zu beobachten und Steuerbefehle an die Erzeugereinheiten abzugeben.
Eine detaillierte vollgraphische Darstellung aller Kraftwerksblöcke erfordert in der Initialisierungsphase des Simulators zusätzliche Aufwendungen; diese Art der Darstellung enthält aber gegenüber einer tabellarischen Auflistung keinerlei zusätzlichen Informationsinhalt. Die Darstellung der Betriebszustände mehrerer Kraftwerksblöcke in einer Tabelle kann aber ohne großen Aufwand automatisch bewältigt werden, so daß in der Initialisierungsphase keinerlei vorbereitende Arbeiten für die Kraftwerks-Bedienoberfläche geleistet werden müssen.
Die für die Verwendung als Teilsystem der Leitstellennachbildung erforderliche Interpretation der Leitstellenzuordnungsdatei (siehe 3.5) muß implementiert werden.
4.3.3. Realisierung
Die implementierte Programmstruktur und die Einbettung in den Simulator zeigt Bild4.7.
Bild 4.7.:Programmstruktur der Kraftwerks-Bedienoberfläche
Folgende Kommunikationswege ergeben sich aus dieser Struktur:
spontane Ereignisse der Kraftwerke (Pumpen einschaltbereit, Kraftwerksblock synchronisiert) werden im dynamischen Modell erzeugt und über die Ereignisverarbeitung in die Datenbank eingetragen. Der sich so ergebende neue Zustand wird im Rahmen der zyklischen Aktualisierung der Bedienoberflächen vom Server ausgelesen und an alle Kraftwerks-Bedienoberflächen übertragen;
die sich gegebenenfalls im Zeittakt verändernden Einspeiseleistungen der einzelnen Kraftwerksblöcke werden über die Meßwertversorgung (siehe 7.2) in die Datenbank eingetragen und ebenfalls mit der zyklischen Aktualisierung an der Oberfläche angezeigt;
Befehlseingaben an der Oberfläche werden gemäß Bild 4.6 über die Ereignisverarbeitung zum dynamische Modell übertragen. Nach Überprüfung der Befehle werden sie wiederum über die Ereignisverarbeitung in die Datenbank eingetragen; der so resultierende neue Zustand wird mit der zyklischen Aktualisierung vom Server an die Oberflächen übertragen.
Bild 4.8. Kraftwerks-Bedienoberfläche
Bild 4.8 zeigt als Beispiel das Aussehen der Bedienoberfläche für alle Kraftwerksblöcke des niederländischen Hoch- und Höchstspannungsnetzes (110...380 kV).
Den Hauptteil der Bedienoberfläche bildet die Darstellung der für den Netzbetrieb relevanten Kraftwerkszustände. Für jeden Block wird sein Name und seine Nennwirkleistung angegeben; weiterhin erkennt man:
sofern der Block nicht im Leistungsbetrieb ist, welcher Anfahrzustand momentan herrscht, und
sofern er im Leistungsbetrieb ist, welche aktuelle Wirkleistung abgegeben wird und welcher Wirkleistungssollwert eingestellt ist. Außerdem läßt sich erkennen, in welche Netzinsel der Block einspeist.
Die Angabe der Netzinsel ist eine Erleichterung für den Kraftwerksführer, damit er erkennen kann, welche Einheiten in dieselbe Insel einspeisen. Zur Steigerung des Schwierigkeitsgrads im Training kann die Angabe der Inselnummer unterdrückt werden.
Auf der rechten Seite der in Bild 4.8 gezeigten Oberfläche erkennt man diverse Tasten und Eingabefelder. Befehle wie „Pumpen starten" oder „Abschalten" sind auf entsprechend beschriftete Tasten gelegt; mit Hilfe der Eingabefelder ist es möglich, verschiedene Sollwerte des Kraftwerks zu sehen und zu verändern. Will man nun einem bestimmten Kraftwerksblock einen Befehl erteilen oder einen Sollwert ändern, so muß der Bediener den Blocknamen auf der linken Seite der Oberfläche anklicken oder mit Hilfe der Cursortasten auswählen; danach wird automatisch die rechte Reihe mit den Befehlen und Sollwerten aktualisiert, indem - abhängig vom Zustand des Kraftwerks - bestimmte Tasten und Eingabefelder aktiviert oder deaktiviert werden und die aus der Datenbank entnommenen Sollwerte in die entsprechenden Eingabefelder eingetragen werden. Die Deaktivierung einzelner Felder dient dazu, unsinnige Befehle wie z.B. der Anfahrbefehl an ein bereits synchronisiertes Kraftwerk zu unterdrücken. Eine Kontrolle der Sollwerte auf Einhaltung des gültigen Wertebereichs hingegen wird nicht innerhalb des Bedienprogramms, sondern im dynamischen Modell durchgeführt, wie schon im Abschnitt 4.2.2 diskutiert wurde
.