Phone: +45(45)3618-1000
Email:
Magnus.Rimvall@FLSmidth.Com
Wenn man die von vielen Autoren beschriebenen Beispiele für Simulationsstudien betrachtet, gleichgültig ob im zeitdiskreten oder kontinuierlichen Bereich, dann stellt man fest, dass diese Darstellungen vorwiegend aus einer sehr eingehenden Beschreibung eines detailliert ausgearbeiteten Modells bestehen, an dem allerdings relativ einfache Experimente durchgeführt werden. Auch die Fallstudien im letzten Teil dieses Buches folgen im Wesentlichen diesem Aufbau. Das Experimentieren besteht immer darin, dass, ausgehend von einem vollständigen und konsistenten Satz von Anfangsbedingungen, die zeitlichen Verläufe einzelner Systemgrößen registriert werden. Dieses Vorgehen wird als Ermittlung des Übergangsverhaltens oder des trajektoriellen Verhaltens des Modells bezeichnet. Man kann den Begriff "Simulation" ja tatsächlich recht einfach der Ermittlung des Übergangsverhaltens gleichsetzen, was auch sehr oft getan wird. Dies ist aber nur solange möglich, als eine reine Lösungsfindung gemeint ist und weniger die Gesamtheit aller modellbezogenen Vorgänge. In der Tat sind auch die meisten der gängigen Simulationspakete kaum mehr als wirkungsvolle Werkzeuge zur Berechnung des Übergangsverhaltens.
Leider stellen sich nur sehr wenige praktische Probleme als reine Simulationsaufgaben dar. So sind z.B. die Anfangswerte sehr häufig nicht alle zum selben Zeitpunkt definiert. Solche Probleme werden allgemein als Randwertprobleme bezeichnet im Gegensatz zu den vorher erwähnten Anfangswertproblemen. Randwertprobleme sind im Sinne des Wortes natürlich keine Simulationsprobleme, obwohl sie durch die Methode des invariant embedding in Anfangswertprobleme umgeformt werden können. Allgemein wird aber für diese Problemklasse eher die sog. shooting technique angewandt bei der man so vorgeht:
Nehmen wir nun an, um ein anders geartetes Beispiel zu besprechen, die Dynamik eines elektrischen Netzes soll simuliert werden. Die einzelnen elektrischen Komponenten dieses Netzes hätten verschiedene Toleranzen, und es sollte ermittelt werden, wie sich das Verhalten des Netzes in Abhängigkeit von diesen Toleranzen ändert. Ein Algorithmus für dieses Problem könnte etwa so lauten:
Diese beiden Beispiele zeigen, dass die Simulation nicht in einer abgeschlossenen Welt existiert. Eine wissenschaftliche oder technische Studie kann unzählige verschiedene Simulationsläufe und noch vieles andere mehr beinhalten. Leider werden die wenigsten der heute verfügbaren Simulationspakete diesem Bedarf an ausgedehntem Experimentieren gerecht. Wenn auch die Möglichkeiten zur Modellrepräsentation (im Sinne des obigen ersten Absatzes) im Laufe der letzten Jahre ständig verbessert und wirkungsvoller wurden, wurde doch sehr wenig getan, um die softwaremäßigen Möglichkeiten zur Experimentrepräsentation der Simulation auszuweiten (Cellier, 1986). Einige Simulationssprachen, wie z.B. ACSL (Mitchell und Gauthier, 1986) bieten zwar Routinen zur Linearisierung und zur Arbeitspunktbestimmung. Andere, wie etwa DSL/VS (IBM, 1984) bieten eingeschränkte Möglichkeiten zur Frequenzbereichsanalyse wie z.B. die Berechnung des Fourier Spektrums einer zeitlichen Systemantwort. Uns ist aber kein dzt. verfügbares Simulationssystem bekannt, das ein allgemein anwendbares nichtlineares Programmpaket z.B. für Trajektorienapproximation, Arbeitspunktbestimmung, einen Randwertproblemleser, usw. als integralen Teil der Software enthält. Ein solches Paket wäre ja auch nur eines von vielen denkbaren nutzbringenden Werkzeugen. Übrigens sind die wenigen verfügbaren, experimentorientierten Softwarewerkzeuge oft auch wenig benützerfreundlich und sehr spezialisiert, d.h. ihre Anwendbarkeit ist doch eingeschränkt.
Immer wenn wir Softwareingenieure einer solchen Situation begegnen, stellen wir fest, dass mit den Datenstrukturen in der betreffenden Simulationssprache doch etwas nicht in Ordnung sein muss. Tatsächlich führten ja alle Verbesserungen der Modellrepräsentation, wie z.B. die Behandlung von Unstetigkeiten oder die Möglichkeit zur Submodell- (Macro-) Deklaration, zu erweiterten Programmstrukturen, wohingegen die verfügbaren Datenstrukturen immer noch beinahe unverändert sind gegenüber 1967, als die CSSL Spezifikationen (Augustin et al., 1967) zum ersten Mal formuliert wurden.
Wenn wir im Gegensatz zur Simulationssoftware von CAD Software sprechen, dann denken wir genau an diese erweiterten und verbesserten Möglichkeiten zur Experimentbeschreibung. Die Simulation ist heute einfach nicht mehr der zentrale Teil einer Studie sondern schlicht eines unter den vielen aufrufbaren Softwerkzeugen, die gemeinsam die zum Experimentieren nötige Software bilden. Von nun an wollen wir diese "computer-aided design software" oder abgekürzt CAD-Software nennen. Algorithmen für spezielle Anwendungen sollen CAD-Techniken, und Programme, in denen solche Algorithmen eingebunden werden können, sollen CAD-Werkzeuge (CAD tools) heißen. Da viele der Entwurfswerkzeuge von den jeweiligen Anwendungen abhängen, wollen wir uns hier auf eine spezielle Anwendung konzentrieren. Entsprechend der Zielsetzung dieses Buches, im Wesentlichen die Simulation als Werkzeug zum Reglerentwurf darzustellen, wollen wir uns auf den Entwurf von Regelungssystemen festlegen.
Bis vor sehr kurzer Zeit waren die Datenstrukturen innerhalb der Software zum rechnerunterstützten Regelungssystementwurf (Computer-Aided Control System Design, CACSD) ebenso verbesserungswürdig wie jene der reinen Simulationssoftware. Jedoch auch die Programmstrukturen dieser Werkzeuge waren sehr mangelhaft. Der Benutzer wurde durch ein unflexibles Frage-Antwort Protokoll hindurchgeführt. Sobald irrtümlich eine nicht korrekte Spezifikation eingegeben worden war, gab es keine Chance, die Folgen dieses Fehlers zu beseitigen. Die entstandene Abweichung vom entworfenen Weg führte im ungünstigsten Fall zu einem völligen Softwarezusammenbruch, nach dem der Benützer alle vorher eingetragenen Daten verloren geben musste und gezwungen war, neu zu beginnen.
Ein wesentlicher Durchbruch konnte mit der Entwicklung von MATLAB (Moler, 1980) erzielt werden. MATLAB ist ein universelles Werkzeug zur Matrix-Manipulation unter einfachster Datenstruktur, die einzige Datenstruktur ist eben jene von Matrizen, und mit einfachster Kodierung. APL bot zwar schon viel früher dieselben Möglichkeiten wie MATLAB, war aber durch eine sehr unzugängliche Syntax gekennzeichnet. Der Benutzer musste beinahe in derselben Weise denken wie der Rechner das APL Programm abarbeitete. Bei MATLAB hingegen "denkt" der Rechner ebenso wie der Benutzer. Natürlich war MATLAB als einfache interaktive Sprache für die Matrix-Algebra nicht dazu entwickelt worden, CACSD Probleme zu lösen, es ist aber offensichtlich jene Art von Werkzeugen, die der Regelungstechniker für die Lösung seiner Probleme braucht. So ist z.B. das Standard Regulator Problem als "Riccati-Entwurf" in wenigen Zeilen eines übersichtlichen Codes formulierbar. Es dauerte daher gar nicht lange, bis etliche CACSD Experten den für sie relevanten Wert dieses zunächst gar nicht für CACSD entworfenen Werkzeugs als Basis für ihre Probleme erkannten. Als Folge entstanden sehr rasch CTRL-C (Systems Control Technology, 1984; Little et al., 1984) MATRIXx (Integrated Systems, 1984; Shah et al., 1985), IMPACT (Rimvall, 1983; Rimvall und Bomholt, 1985; Cellier und Rimvall, 1989), PC MATLAB (Little, 1985), MATLAB SC (Vanbegin und Van Dooren, 1985).
Es wäre einerseits sehr zweckmäßig, wenn eine Matrixnotation, ähnlich wie in MATLAB, innerhalb einer Simulationssprache für die Beschreibung linearer Systeme bzw. Subsysteme verwendet werden könnte. Auch wäre es für Simulationssoftware sehr vorteilhaft, effektivere Integrationsalgorithmen zu verwenden als die konventionellen expliziten Runge-Kutta-, Adams-Bashforth oder Gear-Algorithmen. Dies konnte z.B. ein impliziter Adams-Moulton Algorithmus sein. Lineare (sub)-systeme könnten durch den Compiler auf Grund einer Matrixnotation sofort automatisch erkannt werden. Andererseits ist es sicher zutreffend, dass die meisten aktuellen CACSD Programme nur eingeschränkte Simulationsmöglichkeiten bieten. Es wäre daher außerordentlich nützlich, das verfügbare Know-how über die Simulation dynamischer Systeme und Prozesse in die CACSD Software einzubringen. Ein Entwurfsvorgang umfasst natürlich wesentlich mehr als nur Simulationen, er benötigt diese aber unbedingt neben anderen Möglichkeiten. Daher sollte ein flexibles Interface zwischen CACSD Programm und Simulationssprache vorhanden sein, so dass innerhalb einer komplexen Entwurfsstudie aussagekräftige Simulationsläufe an bestimmten Stufen des Entwurfs diesen wirkungsvoller machen könnten.
Wir befassen uns nachfolgend nur mit digitaler Simulation. Jedoch sind CACSD Algorithmen in unveränderter Weise auch auf die im Beitrag von Troch und Breitenecker besprochene klassische hybride Simulation anwendbar. Der dynamische Prozess wird als Modellrepräsentation am Analogteil verschaltet, wogegen die Experimentrepräsentation am Digitalteil der Hybridanlage programmiert wird. Die eingangs zitierte Definition des Begriffes der Simulation (Experimentieren mit Modellen) wird am klassischen Hybridrechner besonders deutlich.
Möchten Sie die vollständige Publikation lesen? (17 Seiten, 984,390 bytes, pdf)