|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Praktikum Prozessprogrammierung mit dem Thema: Simulation einer WindradanlageLetztes Update: Freitag, 06. Juli 2012 17:46 UhrAuf 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. Inhaltsverzeichnis2.2 Programminstallation und Programmstart 3 2.3.1 Die grafische Oberfläche. 4 2.3.2 Benutzersteuerung und Ablauf. 4 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 4.1 Original Aufgabenstellung Prozessprogrammierung 1, SS 2003. 11 4.2 Quellcode des Programms. 11
2. Benutzerhandbuch2.1 AblaufbedingungenFür den Ablauf des Programms werden folgende Hard- und Softwarekomponenten vorausgesetzt:
2.2 Programminstallation und ProgrammstartUm 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 BedienungsanleitungBei 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ächeDas 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 AblaufNach 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 ErgebnisprotokollUm 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:
3. Programmierhandbuch3.1 EntwicklungskonfigurationDie Entwicklung von „Fighter“ wurde mit Hilfe folgender Software durchgeführt:
3.2 Problemanalyse und RealisierungDie Realisierung des Simulators stellt mehrere Anforderungen an die Entwickler. Die wichtigsten Bestandteile des Programms sind:
3.3 Übersicht und Beschreibung aller Tasks
3.4 Intertask-Kommunikation und SynchronisationDie 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
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 ISRUm 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ätenvergabeDas 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:
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. Anhang4.1 Original Aufgabenstellung Prozessprogrammierung 1, SS 20034.2 Quellcode des Programms
Zurück zur Programmierung-Übersicht♦ ♦ ♦
11996022 Besucher (37468744 Zugriffe) auf dieser Homepage seit dem 09.10.2005 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||


