Simulation einer Windrad­anlage als Echtzeitsystem

Auf dieser Seite findest du die Dokumentation zum Praktikum Prozessprogrammierung mit dem Thema: "Simulation einer Windradanlage".

Im Jahr 2003 habe ich zusammen mit einem Kommilitonen an diesem Projekt gearbeitet und eine Simulation für den Betrieb eines Windrads entwickelt, basierend auf dem Multi-Threading-Echtzeitsystem RTKERNEL (FH-Wedel, SS2003).
 

1. Inhalts­verzeichnis

1. Inhaltsverzeichnis. 2

2. Benutzerhandbuch. 3

2.1 Ablaufbedingungen. 3

2.2 Programminstallation und Programmstart 3

2.3 Bedienungsanleitung. 3

2.3.1 Die grafische Oberfläche. 4

2.3.2 Benutzersteuerung und Ablauf. 4

2.4 Ergebnisprotokoll 5

3. Programmierhandbuch. 5

3.1 Entwicklungskonfiguration. 5

3.2 Problemanalyse und Realisierung. 6

3.3 Übersicht und Beschreibung aller Tasks. 6

3.4 Intertask-Kommunikation und Synchronisation. 7

3.5 Die Verwendeten Datenstrukturen. 7

3.6 Grobe Ablaufbeschreibung. 9

3.7 Ablauf der ISR.. 10

3.8 Prioritätenvergabe. 10

4. Anhang. 11

4.1 Original Aufgabenstellung Prozessprogrammierung 1, SS 2003. 11

4.2 Quellcode des Programms. 11

 

2. Benutzer­handbuch

2.1 Ablauf­bedingungen

Für den Ablauf des Programms werden folgende Hard- und Softwarekomponenten vorausgesetzt:

Hardware

IBM-kompatibler PC Ca 1 MB freier Festplattenspeicher VGA-Grafikkarte, die eine Auflösung von 640x480 unterstützt CD-ROM-Laufwerk zur Installation

Software

Betriebssystem: MS-DOS (echtes DOS – keine Windowsemulation)

 

2.2 Programminstallation und Programmstart

Um die Simulation starten zu können, muss das Programm zuerst installiert werden.

Zur Installation des Programms muss das komplette Verzeichnis „Windrad“ von der Installations-CD auf die Festplatte kopiert werden. Dort kann dann das Programm durch Aufruf von „RADK.EXE“ gestartet werden. Ggf. muss noch das Schreibschutzattribut der Datei „log.txt“ entfernt werden, falls der Dateimanager dies nicht schon automatisch beim Kopieren erledigt hat.

Durch Löschen des kopierten Verzeichnisses (inkl. aller Unterdateien) kann das Programm einfach wieder deinstalliert werden.

Der Programmstart direkt von CD ist nicht möglich, da auf diesem Medium kein Schreibzugriff (zum Erstellen der Logdatei) gestattet ist.

2.3 Bedienungsanleitung

Bei dieser Simulation einer Windradanlage wird auf dem Bildschirm eine komplette Ansicht aller relevanten Daten sowie die Buttons zur Windrad- und Verbrauchersteuerung bereitgestellt.

 

2.3.1 Die grafische Oberfläche

Das untenstehende Bild zeigt die grafische Oberfläche des Programms, nach erfolgreichem Start. Das Hauptfenster ist in elf kleinere Fenster mit blauen Rand unterteilt, wobei jedes Fenster die jeweils beschriebenen Informationen darstellt, so dass der Lauf der Simulation zu jedem Zeitpunkt mitverfolgt werden kann.

2.3.2 Benutzersteuerung und Ablauf

Nach Aufruf und Start des Programms („RADK.EXE“) wird die Simulation der Windradanlage automatisch gestartet. Durch Drücken der „Escape“-Taste kann sie zu jedem Zeitpunkt wieder beendet werden. Nach vier Simulationstagen bleibt das Programm stehen und zeigt die zuletzt ermittelten Daten bis zum Programmende an.

Mit Hilfe der Maus kann durch Klicken der Buttons sowohl jeder einzelne Verbraucher als auch das Windrad an- und ausgeschaltet werden. Die jeweilige Beschriftung der Buttons zeigt den aktuellen Zustand. Außerdem ist es möglich mit Hilfe der „Print“-Taste das Windrad sofort stillzulegen. Dieser Notaus-Schalter hat höchste Prioriät und wird umgehend nach Druck der Taste wirksam. Ein erneutes Drücken setzt den Notaus-Schalter zurück.

2.4 Ergebnisprotokoll

Um das Ergebnis der Simulation zu sehen, genügt ein Blick in das Logfile. Während der gesamten Simulation werden alle wichtigen Zustände protokolliert und sind anschließend im Logfile zu finden. Für jede Minute ist der Status des Windrads zu sehen (ob es an-/ausgeschaltet war bzw. ob es durch den Notaus-Schalter deaktiviert wurde). Anhand der angegebenen Differenz erkennt man zu jedem Zeitpunkt, ob das Windrad Energie in das öffentliche Netz eingespeist oder Energie daraus bezogen hat. Die Gesamtdifferenz zeigt dann den kumulierten Wert und gibt Auskunft darüber, ob der Einsatz des Windrads ökonomisch ist oder nicht. Außerdem enthält das Logfile den jeweiligen Status (eingeschaltet/ausgeschaltet) der drei Verbraucher (V1, V2 und V3) zu jedem Zeitpunkt der Simulation. Das folgende Bild zeigt einen Auszug der Logdatei:

Tag: █ Status: █ Differenz: █ Gesdifferenz: █ V1 █ V2 █ V3
____________________________________________________________________
1 0:49 Uhr █ Rad aus █ 0.00 kW █ 37.32 kWh █ Aus █ Aus █ Aus
1 0:50 Uhr █ Rad aus █ 0.00 kW █ 37.32 kWh █ Aus █ Aus █ Aus
1 0:51 Uhr █ Rad aus █ 0.00 kW █ 37.32 kWh █ Aus █ An █ Aus
1 0:52 Uhr █ Rad aus █ 0.00 kW █ 37.32 kWh █ Aus █ An █ Aus
1 0:53 Uhr █ Rad aus █ 0.00 kW █ 37.32 kWh █ Aus █ An █ Aus
1 0:54 Uhr █ Rad aus █ 0.00 kW █ 37.32 kWh █ Aus █ An █ Aus
1 0:55 Uhr █ Rad aus █ 0.00 kW █ 37.32 kWh █ Aus █ An █ Aus
1 0:56 Uhr █ Rad aus █ 0.00 kW █ 37.32 kWh █ Aus █ An █ Aus
1 0:57 Uhr █ Rad aktiv █ 116.48 kW █ 39.26 kWh █ Aus █ An █ Aus
1 0:58 Uhr █ Rad aktiv █ 115.05 kW █ 41.17 kWh █ Aus █ An █ Aus
1 0:59 Uhr █ Rad aktiv █ 125.26 kW █ 43.26 kWh █ Aus █ An █ Aus
1 1: 0 Uhr █ Rad aktiv █ 64.01 kW █ 44.33 kWh █ Aus █ An █ Aus
1 1: 1 Uhr █ Rad aktiv █ 68.07 kW █ 45.46 kWh █ Aus █ An █ Aus
1 1: 2 Uhr █ Rad aktiv █ 70.58 kW █ 46.64 kWh █ Aus █ An █ Aus
1 1: 3 Uhr █ Rad aus █ 0.00 kW █ 46.64 kWh █ Aus █ An █ Aus
1 1: 4 Uhr █ Rad aus █ 0.00 kW █ 46.64 kWh █ Aus █ An █ Aus
1 1: 5 Uhr █ Rad aus █ 0.00 kW █ 46.64 kWh █ Aus █ An █ Aus
1 1: 6 Uhr █ Rad aus █ 0.00 kW █ 46.64 kWh █ Aus █ An █ Aus
1 1: 7 Uhr █ Rad aus █ 0.00 kW █ 46.64 kWh █ Aus █ An █ Aus
1 1: 8 Uhr █ Rad aus █ 0.00 kW █ 46.64 kWh █ Aus █ An █ Aus
1 1: 9 Uhr █ Rad aktiv █ 75.15 kW █ 47.89 kWh █ Aus █ An █ Aus
1 1:10 Uhr █ Rad aktiv █ 133.58 kW █ 50.12 kWh █ Aus █ An █ Aus
1 1:11 Uhr █ Rad aktiv █ 92.99 kW █ 51.67 kWh █ Aus █ An █ Aus
1 1:12 Uhr █ Rad aktiv █ 118.64 kW █ 53.65 kWh █ Aus █ Aus █ Aus

3. Programmier­handbuch

3.1 Entwicklungskonfiguration

Die Entwicklung von „Fighter“ wurde mit Hilfe folgender Software durchgeführt:

• Betriebssystem: MS-DOS
• Programmierumgebung: Borland Pascal 7 unter Einbeziehung der Echtzeitumgebung RTKernel
• UltraEdit-32 Version 10.0 zum Bearbeiten der Quellcodes

3.2 Problemanalyse und Realisierung

Die Realisierung des Simulators stellt mehrere Anforderungen an die Entwickler. Die wichtigsten Bestandteile des Programms sind:

• Die sinnvolle Einteilung der verschiedenen Programmanteile in parallel ablaufende Prozesse (Tasks)

• Die Synchronisation und Kommunikation der Tasks untereinander (Intertask-Kommunikation)
• Die grafische Darstellung der Prozesswarte mithilfe der RTGraphics-Toolbox.
• Die Realisation des „Notausschalters“ durch eine Interrupt- Service- Routine
• Eine sinnvoll aufgebaute und gegliederte Logdatei

3.3 Übersicht und Beschreibung aller Tasks

Task_Wind

Diese Task stellt aktuelle Windgeschwindigkeit bereit. Dabei wird zunächst die aktuelle Simulationszeit von der Zeit-Task abgeholt. Anschließend wird die aktuelle Nominalwindgeschwindigkeit mithilfe linearer Interpolation der (in der Aufgabenstelung) vorgegebenen Werten der letzten und nächsten vollen Stunde errechnet, die dann um eine zufällige Abweichung von ±10% auf den tatsächlichen Wert geändert wird.

Task_Zeit

Diese Task stellt die aktuelle Simulationszeit zur Verfügung. Hier wird auch die Dauer der Simulation festgelegt, indem die Taskschleife genau 5760 Minuten (4 Tage) durchlaufen wird. Da die Synchronisation von dieser Task ausgeht, ist ein vernünftiger Abschluss der Simulation und eine korrekte Beendigung aller anderen Tasks gewährleistet. Die Zeit selbst wird aus der Anzahl der RTKernel-System-Ticks seit Simulationsstart errechnet. Das Timerintervall wurde bei der Programminitialisierung auf einen Wert von 10ms gesetzt, was in der Simulationszeit 0,1 Minute entspricht. Daraus folgt, dass am Ende jedes Schleifendurchlaufs ein Delay von 10 Ticks erfolgen muss, damit die korrekte Simulationsdauer eingehalten wird.

Task_Windrad

Steuerung des Windrades → Ermittlung der momentan erzeugten Leistung. In dieser Task wird am Anfang jedes Schleifendurchlaufs zunächst geprüft, ob die Notaus-Mailbox voll ist. Anschließend wird der Status des „regulären“ Schalters abgeholt. Ist Notaus aktiv oder der reguläre Schalte off, liefert die Task den Leistungswert 0. Anderenfalls wird geprüft, ob die Windgeschwindigkeit zu hoch oder zu niedrig ist, sodass ebenfalls 0 geliefert werden würde. Im Normalfall wird die Momentan erzeugte Leistung in kW geliefert.

Task_Verbraucher

Ermittlung der Leistung für jeden einzelnen Verbraucher. Das besondere an den Verbrauchern ist, dass für jeden die selbe Taskroutine verwendet wird. Damit trotzdem jeder Verbraucher eindeutig identifiziert werden kann, wird beim Initialisieren aus dem Tasknamen die Verbrauchernummer extrahiert und in der Variable ‚Index’ gespeichert. Jeder Verbraucher besitzt ein Intervall von Zeiten, in der die Energieanforderung konstant ist. Diese Zeit und die Leistung selbst wird per Zufall ermittelt. Ist die Zeit abgelaufen, wird beim nächsten Schleifendurchlauf Zeit und Leistung neu berechnet.

Task_Verteiler

Koordination von Erzeuger- und Verbraucherleistung und Berechnung der Gesamtenergie. In dieser Task wird hauptsächlich zunächst die Energieanforderung jedes einzelnen Verbrauchers bearbeitet. Dabei muss darauf geachtet werden, dass die Reihenfolge, in der die Messages von den drei Verbrauchern gesendet werden, nicht festgelegt ist. Deshalb wird in dieser Message diese Information mitgeliefert. Weiterhin werden die meisten Informationen, die auf dem Bildschirm angezeigt werden in dieser Task berechnet.

Task_Warte

Stellt Benutzerinteraktion und Bildschirmausgabe zur Verfügung. Diese Task stellt sozusagen die Schnittstelle zwischen der Benutzersteuerung und restlichen Programm dar, da alle Benutzereingaben in dieser Task verarbeitet werden. (Nur die Notausfunktion wird direkt von der Windradtask verarbeitet und der Status anschließend vom Windrad zur Warte gesendet.) Auch wird das Handling der Logdatei ausschließlich in dieser Task geregelt. Am Ende jeden Durchlaufs werden sämtliche Grafikfenster aktualisiert, indem den Zeichenroutinen die jeweils neuen anzuzeigenden Werte übergeben werden.

3.4 Intertask-Kommunikation und Synchronisation

Die Intertask-Kommunikation wurde im Wesentlichen mit zwei Konzepten realisiert: Mailboxen und Message-passing.

Beim Message-passing müssen Sender- und Empfängertask synchronisiert sein, d.h., beide Tasks müssen zum gleichen Zeitpunkt zum Senden und Empfang bereit sein. Ist dies nicht der Fall, blockiert die schon bereite Task, solange bis die andere auch bereit ist, so dass der Transfer stattfinden kann.

Das Mailboxkonzept ist so aufgebaut, dass die Tasks beim Datentransfer nicht unbedingt synchronisiert sein müssen, da eine (frei definierbare) Menge von ‚Slots’ (im vorliegenden Programm bei jeder Mailbox immer nur ein Slot) zur Verfügung steht – Speicherplatz passend zu dem Datentypen, von dem die zu verschickenden Daten sind. Soll ein Datensatz versendet werden, so wird dieser von der Sendertask in der Mailbox abgelegt. Die Empfängertask liest diesen Datensatz aus der Mailbox aus und löscht ihn anschließend dort wieder. Soll ein Datensatz empfangen werden, obwohl die Mailbox leer ist, blockiert die Empfängertask solange bis die Mailbox mit einem Datensatz gefüllt ist. Genauso verhält es sich mit der Sendertask und voller Mailbox.

Es kann jedoch bei beiden Konzepten die Synchronisation insofern etwas „gelockert“ werden, indem man spezifizieren kann, dass eine Task nicht blockiert, wenn die andere Task nicht zum Transfer bereit ist oder eine Mailbox leer, bzw. voll ist. Es besteht bei dieser Methode die Möglichkeit abzufragen, ob ein Transfer stattgefunden hat oder nicht. Im vorliegenden Programm wurde diese Methode bei der Entnahme aus der Notaus-Mailbox verwendet, da nur beim Aufruf der ISR von Int5 diese Mailbox gefüllt wird.

 

3.5 Die Verwendeten Datenstrukturen

 

3.6 Grobe Ablaufbeschreibung

Legende der Objekte:

Im Folgenden wird grob der Ablauf einer Simulationsminute beschrieben:

Im vorliegenden Programm geht die Synchronisation von der Zeittask aus, die ja die Simulationsgeschwindigkeit vorgibt. Von ihr aus werden Messages mit den aktuellen Zeitinformationen zur Windfeldtask, zu allen Verbrauchern und zur Prozesswarte gesendet. Von der Windfeldtask wird eine Message mit der Windgeschwindigkeit zur Windradtask gesendet, dies geschieht aber erst nachdem die Zeit von der Windfeldtask empfangen worden ist. Die Windradtask wiederum sendet eine Message mit der erzeugten Energie an die Verteilertask. Die Verbraucher senden jeweils nach dem Zeitempfang und Statusabfrage der Prozesswarte auch eine Message an den Verteiler mit der angeforderten Energie. Nachdem der Verteiler alle Messages empfangen hat, werden in dieser Task aller erforderlichen Daten errechnet und per Mailbox an die Prozesswarte geschickt. Ebenso werden die Informationen der Windradtask per Mailbox an die Warte geschickt. Bei der Intertask-Kommunikation mit der Prozesswarte bieten sich Mailboxen an, da sich die Programmierung bei gleicher Effektivität etwas flexibler gestaltet, da es sonst u.U. evtl. durch Benutzereingaben zu Deadlocks kommen könnte.

Die Windradtask empfängt ggf. eine Mail von der ISR des Notausschalters. Wird eine Mail empfangen, wird der Notausschalter getoggelt.

3.7 Ablauf der ISR

Um dem Benutzer eine sichere und schnelle Möglichkeit zu bieten, dass Windrad (z.B. im Störfall) auszuschalten, löst das Programm bei Druck auf die „Print“-Taste einen Interrupt aus, der höchste Priorität besitzt.

Damit das Programm auf den Interrupt reagieren kann, besitzt es eine eigene Interrupt Service Routine, die bei Auslösen des Interrupts abgearbeitet wird. Damit DOS diese Routine kennt und auf sie reagieren kann, wird zu Beginn unseres Programms zunächst der alte Interruptvektor 5 gesichert und anschließend auf unsere ISR umgebogen. Um Deadlocks beim Verbiegen des Vektors zu vermeiden geschieht dies in einem durch eine Semaphore abgesicherten Bereich. Wird die Taste gedrückt und dadurch der Interrupt ausgelöst, so kommt unsere ISR zum Aufruf. Die ISR beendet zunächst den kritischen Abschnitt bzw. die Semaphore, anschließend schickt die Routine mit Hilfe einer Mailbox eine Nachricht an die Windradtask, welche daraufhin sofort die Berechnung einstellt bzw. das Windrad stilllegt (es wird der Wert Null für die erzeugte Energie an die Energieverteilung gesendet).

Beim Beenden des Programms wird der alte, gesicherte Interruptvektor 5 wiederhergestellt, da unsere ISR nicht länger existiert.

3.8 Prioritätenvergabe

Das Programm verwendet insgesamt acht Tasks. Damit die Synchronisation untereinander ordnungsgemäß funktioniert, ist es wichtig, dass die einzelnen Tasks unterschiedliche Prioritäten besitzen. Andernfalls würden einige Tasks blockieren und das Programm in einer Endlosschleife anhalten. Die folgende Tabelle zeigt die verschiedenen Prioritäten aller verwendeten Tasks und beschreibt warum diese Vorgabe wichtig ist:

Task	Priorität	Beschreibung
Zeitgeber	MainPriority+2	Um einen sicheren und synchronen Simulationstakt zu gewährleisten muss gewährleistet sein, dass der Zeitgeber-Task immer aufgerufen wird, da er die aktuelle Zeit bereitstellt.
Prozeß-Warte	MainPriority+1	Die Prozesswarte besitzt eine höhere Priorität, da sie die Steuerfunktion und Ausgabe auf dem Bildschirm übernimmt. Sie muss die Daten vom Windrad und Energieverteiler annehmen können, damit diese nicht zu lange blockieren und die Simulation somit anhalten.
Wind	MainPriority	Diese Tasks haben alle dieselbe Priorität, da aufgrund des implementierten Message-Passing in einer Kette immer gewährleistet ist, dass diese Kette aus Tasks auf die Daten des „Vorgängers“ wartet und anschließend sendet.
Windrad	MainPriority
Energie-Verteiler	MainPriority
Verbraucher 1,2,3	MainPriority

Da es beim Betrieb eines Windrades zu plötzlich auftretenden Störungen kommen kann, ist es für die Sicherheit sehr wichtig, dass es immer eine Möglichkeit gibt, dass Windrad sofort anzuhalten. Diese Funktion übernimmt in unserer Simulation der „interruptgesteuerte“ Notaus-Schalter. Da ein Interrupt immer eine sofortige Unterbrechung des laufenden Programms bedeutet, ist das Abschalten auf diesem Wege eine sichere Option. Der „Notaus-Interrupt“ hat somit eigentlich die höchste Priorität!

 

4. Anhang

4.1 Original Aufgabenstellung Prozessprogrammierung 1, SS 2003

4.2 Quellcode des Programms

 

Kommentare 0