Anwenderbezogene Architekturen bei Mehrsprachensimulatoren

02. Veröffentlichung des

Bitte wählen Sie in der Kopfzeile eine Sprachversion, eine der nachfolgenden Internet-Verknüpfungen oder Überschriften aus dem Inhaltsverzeichnis aus!

(«) Erste Veröffentlichung (<) Vorhergehende Veröffentlichung (>) Nachfolgende Veröffentlichung (») Letzte Veröffentlichung (^) Autor (=) Redaktion ($) Bestellung des ausführlichen Textes (&) Liste der Veröffentlichungen (§) Liste der Firmenschriften

Art der Veröffentlichung:
Vortrag auf dem 8. ASIM-Workshop "Simulationsmethoden und -Sprachen für verteilte Systeme und parallele Prozesse" 27./28.04.92 am Fraunhofer Institut für Integrierte Schaltungen in Dresden

Thema:
Anwenderbezogene Architekturen bei Mehrsprachensimulatoren

Autor:
Christian E. Jacob

Inhaltsverzeichnis: (0) Zusammenfassung (1) Einleitung (2) Kopplung von Simulatoren (3) Einschlusskonzept der Modellierung (4) Unterstützung durch das Simulationsprogramm (5) Schlussfolgerungen zur Strukturänderungen (6) Literaturverzeichnis

(0) Zusammenfassung
Viele der vorgestellten Gedanken sind im Zusammenhang mit der Nutzung des Simulationsprogramms IDAS (Interdisziplinäres Analysesystem) entstanden bzw. konnten daran erprobt werden.
Das Simulationsprogramm entstand im Rahmen einer Forschungskooperation zwischen der Elpro AG Berlin und der Technischen Universität Chemnitz, Lehrstuhl Leistungselektronik. Gepflegt und weiterentwickelt wird IDAS von der Firma SIMEC Chemnitz.
Es gestattet die (quasi-) parallele Simulation von block-, netzwerk- und ereignisorientierten Strukturen. Die technische Problemstellung wird in dafür geeigneten Fachsprachen formuliert. Mit Hilfe des Preprozessors von IDAS ist es gelungen, die Modellierung und Notation der Quelltexte weitgehend zu automatisieren (grafische Eingabe). D.h. der Anwender kann, muss aber nicht unbedingt programmieren!
Für den Einsatz des Postprozessor können zusätzlich (mit einer PASCAL-ähnlichen Programmiersprache) Makros programmiert werden. Diese Makros unterstützen den Anwender bei regelmäßig-wiederkehrenden Auswertungen von Messdaten.
Parallele Steuerungsabläufe werden mittels vorgefertigter Programmbausteine (in Form modifizierter B/E-Netze) beschrieben. Einerseits reichen Grundkenntnisse der Automatentheorie (Anwendung von Zustandsgraphen bzw. Petri-Netzen) aus, um Steuerungsabläufe zu beschreiben, andererseits sind, um eine zeitlich richtige Datenübergabe zwischen den einzelnen block, netzwerk- und ereignisorientierten Programmmodulen sicherzustellen, detaillierte Kenntnisse über die Realisierung der Quasiparallelverarbeitung in IDAS (siehe Bild 5 nach /Knorr 1991/) erforderlich.
IDAS wurde und wird vielfach in Forschung, Entwicklung, Erzeugnisapplikation und der Anlagenprojektierung eingesetzt. Auf Grund des modularen Aufbaus kann IDAS an spezielle Aufgabenstellungen (z.B. Mess-, Modellierungs-, Validationsaufgaben, . . . ) angepasst werden. Die IDAS-Fachsprachen eignen sich gut zu Modellierung nebenläufiger Prozesse (im Sinne der Concurrency Logik).

(1) Einleitung
Für die verschiedensten Anwendungen wurden eine Vielzahl verschiedener Simulationsprogramme bzw. -systeme entwickelt. Sie berücksichtigen unterschiedliches Fachwissen, einen differenzierten Erfahrungsstand und spezifische Modellierungsmethoden.
Allein schon auf den artverwandten Gebieten Elektrotechnik, Elektronik und Technische Kybernetik gibt es eine entsprechende Vielfalt (siehe /Klose 1990/ und /MIPH 1990/). In Bild 1 wird versucht, Simulationsprogramme bzw. -systeme, die auf den genannten Gebieten angewendet werden, zu systematisieren. Für die dort genannten Anwendungsgebiete wurden einige Programmnamen beispielgebend für viele andere genannt.
Ein interessanter Trend geht allerdings dahin, sogenannte Mehrsprachen- bzw. Mixed-Mode-Simulatoren zum Einsatz zu bringen. Mit diesen Simulatoren können komplexe, verschiedene Anwendungsgebiete übergreifende, Problemstellungen simuliert werden.
Mit steigender Komplexität gehen die

- programmiertechnischen und
- anwenderbezogenen Aspekte

weiter auseinander (siehe auch /Coy, Bonsiepen 1987/. Mit dem vorliegenden Beitrag sollen allgemeine Anforderungen an einen Mehrsprachensimulator aus Anwendersicht formuliert werden.

(2) Kopplung von Simulatoren
Block-, ereignis- und netzwerkorientierte Simulationen haben unterschiedlichen Philosophien:

a.) Innerhalb der netzwerkorientierte Simulation ist ein Baum der Abarbeitungsreihenfolge nicht möglich, da quasi alle Variablen innerhalb eines Zeitschrittes gleichzeitig berechnet werden ("stimmiges" Netzwerk zu jedem Berechnungszeitpunkt).
b.) Demgegenüber ist es zwingend erforderlich, Abarbeitungsreihenfolgen für Variable in block- und ereignisorientierten Strukturen festzulegen. Die eigentliche Kalamität besteht darin, dass die Abarbeitungsreihenfolge zwischen netzwerk- und ereignisorientierten sowie netzwerk- und blockorientierten Ausdrücken/Gleichungen nicht übergeben werden kann.

Schlussfolgernd stellt sich die Frage so (s. Bild 2):
Welche Variablen müssen in welcher Reihenfolge für die netzwerkorientierte Simulation bereitgestellt werden? Dann erfolgt die netzwerkorientierte Simulation. Wiederum danach stellt sich die Frage, in welcher Reihenfolge werden die Variablen weiter verwendet?
Ereignisorientierte Fachsprachen werden in Zukunft in Mehrsprachensimulatoren für 3 Aufgaben angewendet werden:

1.) Die Steuerung des Simulationsablaufes bezüglich Genauigkeit, Analyseart, Variation der Parameter (Variationsrechnung, Monte-Carlo-Methode, Empfindlichkeitsanalyse), Protokollierungen (Zeitaufwendungen, Speicherplatzbedarf, Fehlermeldungen, Warnungen, erreichte Abbruchschranken, Matrizen- und Variabelenbelegungen, Markenfluss), Ausgabemedien und -formate, Display-Layout u.s.w. (s. ereignisorientierte Steuerung des Simulationsablaufes in Bild 2).
2.) Die Gewinnung von Werten für den Simulationsprozess selbst (s. vor- und nachbereitende ereignisorientierte Simulation in Bild 2) und
3.) die Filterung von Daten für die Auswertung der Simulation anstelle eines Postprocessings (s. ereignisorientierte Auswertung in Bild 2).

Die Gewinnung von Werten für den Simulationsprozess (vor- und nachbereitende ereignisorientierte Simulation gemäß Bild 2) wird vom Anwender in einer Abarbeitungsreihenfolge vorgegeben.
Im Gegensatz dazu darf die Gewinnung von Daten zur Auswertung der Simulation (entsprechend der ereignisorientierte Auswertung in Bild 2) keinerlei Rückwirkungen auf den eigentlichen Simulationsprozess haben. Sie kann nur den Charakter einer "Messung" ohne Eingriff in die Schrittweitensteuerung, Abarbeitungsreihenfolge u.s.w. haben.
Eine weitgehend (ereignisorientierte) Auswertung während des Simulationslaufes ist Voraussetzung für die (konnektionistische) Bewertung der Simulationsergebnisse (siehe Bild 2).

(3) Einschlusskonzept der Modellierung
Das Fach- bzw. Expertenwissen der Modellierung kann unter folgenden Aspekten, die in 3 Stufen aufgeschlüsselt sind, betrachtet werden:

1.) Die stimulierende und filternde Stufe: Wie kann ich ein Modell stimulieren, um Erkenntnisse abzuheben (Methoden der Versuchsplanung und -steuerung, Multisimulation, Monte-Carlo-Methode u.s.w.)? Wie kann ich aus entstehenden Daten meine Informationen herausfiltern?
2.) Die beschreibende Stufe: Wie kann ich ein Modell kalibrieren und Submodelle mit Parametern versorgen (Anfangswerte, Startmarken, Kennlinien, mathematische und logische Ausdrücke, Maßstäbe und Verschiebungen zur Ausgabe u.s.w.)?
3.) Die verändernde Stufe: Wie bilde ich einen Zusammenhang zwischen übertragenden, rückwirkenden, erzeugenden, verbrauchenden, beeinflussenden, umformenden, aktiven, passiven, vergleichenden und rückschließenden Komponenten (block-, netzwerk- und ereignisorientierte, sowie logische Strukturen) ab?

Unter praktischen Gesichtspunkten (aus Anwendersicht) sollten die dargestellten Stufen als eine Hierarchie gesehen werden. Das Einschlusskonzept versteht sich so, dass die Unterstützung bzw. Handhabung der Modellierung der aktuellen Stufe immer die Realisierung der untergeordneten Stufe(n) mit einschließt:
Bild 3 verdeutlicht diese Betrachtungsweise. Eine implementierte Unterstützung bzw. Handhabung der Modellierung auf einem bestimmten Niveau (siehe Stufen 1 bis 3) sollte auf die niedrigere(n) Stufe(n) aufbauen. D.h. z.B. die Implementierung einer Unterstützung bzw. Handhabung der Modellierung zu der beschreibenden Stufe erfordert sinnvoller Weise die Unterstützung bzw. Handhabung der Modellierung zur stimulierenden und filternden Stufe.
Bei Eingaben bzw. Eingriffen auf den Stufen 1 und 2 muss nicht das ganze Simulationsbeispiel neu übersetzt werden. Dies ist ein Vorteil, der vor allem bei komplexen Simulationen zum Tragen kommt.
Ich möchte an dieser Stelle vermerken, dass die meisten Simulationsprogramme bezüglich der Eingabe und der Behandlung des Preprozesses schwerfällig sind. Die Programme sind oft so aufgebaut, dass jede noch so kleine Eingabe eine komplette Neukompilierung im Preprozess erfordert. Das vorgestellte Einschlusskonzept zeigt, dass das nicht erforderlich ist.

(4) Unterstützung durch das Simulationsprogramm
Bleibt die Struktur des Modells während des Simulationslaufes konstant, reicht Bild 3 zur Erklärung der Beeinflussungsmöglichkeiten der Modellierung aus. Der Simulator kann so konzipiert sein, dass Parameteränderungen (Zugriff auf Anfangswerte, Startmarken, Systemvariablen, Kalibrierungen u.s.w.) und deren Weitergabe an Submodelle direkt erfolgen. Wird eine Strukturänderung erforderlich, muss auf jedem Fall über den Preprozess neu kompilieren werden.
Ein völlig anderes Vorgehen wird erforderlich, wenn während der Simulation die Struktur geändert werden muss. Meiner Meinung nach sollte hier vom Arbeitsstil des Ingenieurs - sprich von dem ingenieurmäßigen Vorgehen - ausgegangen werden:
Der Ingenieur überlegt sich sein Vorgehen. Er erarbeitet sich einen Lösungsweg. Dabei baut er auf Fachwissen auf und ist bedacht, für seine Lösung (jederzeit) Akzeptanz zu erreichen. Der Ingenieur entwickelt dabei seinen Lösungsansatz in einer Struktur (z.B. in einem Netzplan). Das Vorgehen unterliegt einem iterativen Prozess bis ein befriedigendes Ergebnis vorliegt. Zu beobachten ist, dass wenn das Vorgehen korrigiert wird - sprich die Struktur verändert wird - der Ingenieur die Ergebnisse der bisherigen Tätigkeit aufbereitet, bewertet und als Notizen ablegt. Wurde anschließend die Vorgehensweise präzisiert oder korrigiert, bezieht der Ingenieur Daten aus seinem Erfahrungsschatz ein. Er ist also in der Lage Daten aus alten in neue Strukturen zu übertragen. Das wird möglich, indem er sich vergewissert, ob eine Zuordnung sinnvoll ist.
Durch einen Analogieschluss, der im Bild 4 erklärt ist, möchte ich Parallelen zwischen dem ingenieurmäßigen Vorgehen und der Methodik der Modellierung aufzeigen. Diese Parallelen sind meiner Meinung nach von Interesse, weil sie

1.) für den Programmierer von Simulationsprogrammen einen Ansatzpunkt enthalten, Strukturänderungen während des Simulationslaufes mit allen Konsequenzen zuzulassen und
2.) für den Anwender ein Entgegenkommen darstellen. Ihm wird ein Werkzeug in die Hand gegeben, dass ihm nicht ganz fremd ist.

(5) Schlussfolgerungen zur Strukturänderungen
Bild 4 verdeutlicht auch die Notwendigkeit, einen Bibliothekar zur Modelldatenverwaltung einzusetzen und der Filterung der entstehenden Simulationsdaten besonderes Augenmerk zu schenken.
Solange die Stufe 3 des Einschlusskonzeptes gemäß Bild 3 über den Preprozess realisiert wird, sind ein Bibliothekar und eine Datenfilterung vorteilhafte Komplettierungen eines Simulationsprogramms.
Soll dagegen der Simulator die Stufe 3 direkt unterstützen, sind ein Bibliothekar zur Modelldatenverwaltung und die Datenfilterung zwingend erforderlich. Dazu kommt dann noch die automatische Zuordnung von Simulationsergebnissen, die in einer ersten Struktur gewonnenen wurden, als geeignete "Parameter" zu einer zweiten. Hier wird der Rechner erst helfen können, wenn es gelingt, dafür von der Struktur unabhängige Kriterien zu vereinbaren. Dazu fehlen sicherlich auch noch theoretisch Voraussetzungen. Trotzdem lohnt es sich meiner Meinung nach, schon jetzt darüber nachzudenken.

(6) Literaturverzeichnis
/Coy Bonsiepen 1987/ Wolfgang Coy, Lena Bonsiepen: Erfahrung und Berechnung - Kritik der Expertensystemtechnik; IFB 229 Springer-Verlag 1987

/Klose 1990/ Oswald Klose, Manfred Leuchs: Simulationswerkzeug für Stromrichter- und Antriebstechnik; Siemens Energie & Automation (1990) 1

/Knorr 1991/ Knorr, Uwe: Beitrag zur Unterstützung der ereignisorientierten Modellierung leistungselektronischer Systeme; Dissertation TU Chemnitz 1991

/MIPH 1990/ Schneider, Mario; Werner, Klaus: Schaltungssimulation
Scheffel, Reinhold: Simulation analoger Schaltungen mit SPICE
Paap, Karl-Ludwig: Trends in der Schaltkreissimulation
Wenzel, Detlev: CAE für Schaltnetzteile
Fritz, Wolfram; Kleiner, Christoph; Palotas, Laszlo: Benutzerdefinierte Modelle für SPICE
Horneber, Ernst-Helmut: Simulation auf Schalterebene
Siegl, Johann: Simulation der Aufbau- und Verbindungstechnik; alle in Mikroelektronik VDE-Verlag 4 (1990) Heft 2 März/April Fachbeilage Mikroperipherik