Einleitung

Der Modellierungsprozess

Wie das Zitat von Shannon nahelegt ist es im Allgemeinen ein reales System, was wir gerne simulieren würden, aber lediglich das Modell dieses Systems, dass wir simulieren können. Wenn wir also bei der Simulation neue Erkenntnisse gewinnen beziehen sich diese zunächst primär auf das Verhalten des Models. Welche Erkenntnisse sich auf das wirkliche System übertragen lassen ist eine andere Frage, deren Beantwortung unter Umständen viel Wissen über die verwendeten Modelle und das echte System erfordert. Während der Simulation arbeiten wir allerdings zunächst nur mit dem Modell.

Es ist ein langer Weg von dem Wunsch ein reales oder geplantes System zu simulieren bis zu dem Quellcode der schließlich die Grundlage der ausführbaren Software bildet. Die verschiedenen Abstraktionsebenen von Modellen werden in der Zeichnung auf der rechten Seite illustriert. Diese Zeichnung enthält, zu Gunsten der Darstellung, eine Reihe von Vereinfachungen, für die ich um Verständnis bitte. Eine Reihe von Aspekten wie zum Beispiel die Reibung sind auf der mathematischen Ebene und darunter nicht enthalten. Das Ziel ist hier nur grob diese Ebenen zu skizzieren. Als Liste notiert halt man folgende Ebenen:

1. Reales oder mentales System
2. Physikalisches Modell
3. Mathematisches Modell
4. Numerisches Modell
5. Implementierung bzw. Quellcode

In jeder Ebene ist es möglich Entscheidungen zu treffen, die natürlich auswirkungen auf das Ergebnis haben.

Das physikalische Modell

Ganz oben in der Zeichnung steht das System, dass man simulieren möchte. Direkt danach kommt das physikalische Modell. Als physikalisches Modell bezeichne ich in diesem Text den Teil des Modellierungsprozesses in dem zum Beispiel ein Ingenieur primär seinen Bleistift und ein Stück Papier verwendet. In diesem ersten Schritt werden viele Entscheidungen getroffen. Oft ist dies der Moment für die größten Vereinfachungen und der Verarbeitung von Annahmen, die den Unterschied ausmachen zwischen dem realen System und den simulierten Modell. Nehmen wir einmal ein einfaches Pendel als Beispiel. Der Modellierer kann sich entscheiden, dass für seinen Zweck ein sogenanntes mathematisches Pendel ausreicht. Das bedeutet, dass die ganze Masse in einem Gewicht am Ende eines masselosen Fadens konzertiert wird, der von einem Angelpunkt herabhängt. Darüber hinaus wurde keine Reibung in das Modell eingebaut. Das wäre dann ein sehr einfaches Modell des realen Pendels. Lassen Sie und dieses einfache Beispiel für den Rest des Textes im Auge gehalten.

Das mathematische Modell

Wenn er seine Konzept für das physikalische Modell abgeschlossen hat, wird der Modellier damit beginnen eine mathematische Formulierung für dieses Modell zu finden. Die mathematische Modellierung ist im Gegensatz zu einem häufigen Vorurteil nicht eindeutig. Wenn wir wieder an unser Pendel denken kann die Bewegungsgleichungen zum Beispiel basierend auf der Laplace oder dem Newton Ansatz aufbauen. Lassen Sie uns nun einfach annehmen, dass der sicher besser bekannte Newton Ansatz für die Mechanik verwendet wird. Das führt auf die folgende Gleichung für den Auslenkungswinkel:

Damit haben wir zunächst eine Entscheidung gefällt, welchen mathematischen Ansatz zur Darstellung des mechanischen Problems wird verwenden werden. Beide Ansätze würden ohne weiter Vereinfachungen oder Annahmen unser physikalisches Modell in ein mathematisches Modell überführen. Die Entscheidung hat jedoch Auswirkungen auf das Numerische Modell. Der eine Ansatz mag zu steifen Problemen führen, der andere nicht notwendigerweise. Darüber hinaus können wir - was oft sehr nützlich ist - weitere Annahmen oder Vereinfachungen auf diesem Modellierungslevel einführen. Zum Beispiel können wir die Annahme treffen, dass die Maximale Auslenkung des Pendels recht klein sein wird. In diesem Fall ist es gerechtfertigt den Sinus durch eine Taylor Approximation niedriger Ordnung zu ersetzen:

Am Ende steht in jeden Fall ein mathematisches Modell. Falls der Modellier sich entschließt die lineare Version zu verwenden kann er die Gleichung tatsächlich exakt mit Block und Bleistift lösen, bzw. die Lösung direkt in seinem Simulationscode verwenden. Im Fall einer solch einfachen Gleichung ist die Lösung von folgender Struktur:

Das numerische Modell und die Code Generierung

#include <math.h>
#include <stdio.h>

int main()
{
  double g=9.81, l=1,t;
  double v_old=0, phi_old = 2; 
  double v_new=0, phi_new = 2;
  double t_end = 10, deltat=0.001; 
  int i, steps=(int) (t_end/deltat);

  for (i=0;i<=steps;i++)
  {
	t=i*deltat;
	phi_new = phi_old + deltat*v_old;
	v_new = v_old + deltat*(-g/l*sin(phi_old));
	v_old = v_new;
	phi_old = phi_new;
	if ( i%10 == 0 )
		printf("phi_new(%e) : %e\n",t,phi_new);
  }
  return(1);
}

Aber die Chance ein echtes Problem analytisch mit Block und Bleistift lösen zu können ist sehr gering. In den meinsten realen Anwendungsfällen ist der analytische Ansatz nutzlos, zum Beispiel bei der nichtlinearen Version des mathematischen Pendels. In diesen Fällen wird ein numerisches Modell benötigt. Wenn wir das mathematische Modell in ein numerisches Modell transferieren wollen müssen wir erneut Entscheidungen treffen. Wir können zum Beispiel zwischen impliziten und expliziten Integratoren, Runge-Kutta Methoden oder Mehrschritt-Verfahren usw. wählen. Ein sehr einfacher Integrator ist der explizite Euler. In diesem Fall muss man eigentlich nur die Ableitung durch den Differenzenquotienten ersetzen.

Dieser numerische Algorithmus ist nun auch der Ansatzunkt für die Softwareentwicklung. Diese kann entweder von einem Entwickler per Hand oder automatisch durch eine Codegenerierung basierdend auf einer graphischen (z.B. Simulink) oder textuellen (z.B. Modelica) Beschreibung durchgeführt werden. Unabhänge wie dies geschieht und welche Programmiersprache eingestezt wird müssen wir nun mit Effekten rechnen, die sich durch den Einsatz von Gleitkommazahlen im Gegensatz zu realen Zahlen ergeben. Ein Möglicher Einsatz einer Fixpunktdarstellung für reale Zahlen macht natürlich hier nichts besser, sonder eher schlechter.
Ein sehr einfaches Beispiel für den sich möglicherweise ergebenen C-Code finden Sie auf der rechten Seite. Wenn sie diese Code ausführen, werden die Ergebnisse die Berechnet werden nicht denen entsprechen, die Sie bei einem realen Pendel messen würde. Zum Beispiel würden Sie die folgende Ausgaben auf ihrem Bildschirm lesen: phi_new(8)=2.033.... Da 2.03 größer ist als 2 wird augenscheinlich die Energieerhaltung in dieser Simulation verletzt und sie wissen das da irgendwas schief gelaufen ist.

Nun kommt es darauf an herauszufinden wo die Ursache des Fehlers liegt, falls es sich um eine einzelne, isolierbare Ursache handelt. Wir können es zunächst als sehr unwahrscheinlich ansehen, dass er im physikalischen Modell liegt, da in diesem Modell die Erhaltung der Energie trotz der Vereinfachungen noch gültig ist. Auf der Ebene des mathematischen Modells haben wir keine Vereinfachungen gemacht, daher können wir diese Ebene überspringen. Was also übrig bleibt ist das numerische Modell und die Implementierung selbst. Wenn wir die Variable deltat verringern auf 0.0001 sehen wir nun folgendes: phi_new(8)=2.006 Dieses Ergebnis stellt eine wesentliche Verbesserung dar. Man kann also schlussfolgern, dass der Fehler seine Ursache im numerischen Modell hat. Wenn wir eine höhere Genauigkeit und damit eine bessere Einhaltung der Erhaltungssätze benötigen müssen wir deltat weiter verringern oder von dem sehr einfach expliziten Euler auf ein moderneres, der Steifigkeit des Problems angepasstes Verfahren wechseln.

Wenn der Modellierer über ein tiefes Verständnis und Wissen in allen Ebenen verfügt ist eine solche Fehlersuchen noch vergleichsweise einfach. Daher sollte man in diesem Bereich, selbst wenn man lediglich Spezialist auf einer dieser Ebene ist, die anderen nie völlig vernachlässigen. Trotzdem ist der letzte Schritt der eigentlichen Implementierung sehr fehleranfällig und erzeugt durch den damit verbunden Arbeitsaufwand hohe Kosten.

Um diese Kosten zu senken gibt es recht verschiedene Ansätze. Ein sehr naheliegender Ansatz ist soweit wie möglich auf fertige, gut getestete Bibliotheken, wie zum Beispiel LAPACK, FFTW oder die Gnu Scientific Library zu setzen und damit einen hohen Software-Reuse zu ermöglichen. Das verringert die Kosten und erlaubt im Allgemeinen weitere Verbesserungen bzgl. der Qualität der Software.

Model Based Design und Simulation

Alternative kann der Modellierer ein Werkzeug wie Simulink verwenden um direkt aus dem mathematischen Modell heraus mit von Produkten wie dem Real-Time Workshop Code zu erzeugen. Wird aus solch einem abstrakten Modell direkt Code erzeugt spricht man von einem modelbasierten Ansatz ("Model Based Design"). Ein solcher modellbasierter Ansatz auf der mathematischen Ebene erlaubt es ihm auf dieser Ebene zu arbeiten. Dadurch ist es theoretisch möglich z.B. die Hardware-Plattform zu wechseln, also einmal Code für eine PC-Hardware und einem für eine spezielle Embedded Plattform zu generieren. Reine Implementierungsfehler sollten auf diese Weise ebenfalls ausgeschlossen sein. Dadurch sind echte Fehler auf dem mathematischen und physikalischen Modellierungslevel beschränkt. Numerische Effekte müssen allerdings dennoch eingeschätzt werden können und bei der Auswahl diverser Optionen berücksichtigen werden. Entsprechendes Know-how ist also nach wie vor gefordert, zum Beispiel wenn es in Simulink darum geht den richtigen Integrator auszuwählen oder die berechneten Ergebnisse, analog zu unserem Pendel oben, zu interpretieren. Bei den benötigten numerischen Kenntnissen handelt es sich allerdings dann mehr um ein Übersichtswissen und weniger um Details der einzelnen Algorithmen.

Wo Licht ist, ist auch Schatten

Der wichtigsten Frage, die man sich bei der modellbasierten Codegenerierung stellen muss, ist die nach der Performanz. Kann der generierte Code ebenso effizient sein, wie der von einem Menschen geschriebene? Die Antwort hängt natürlich ab von den Fähigkeiten des Entwicklers und der Qualität der generierenden Software, aber darüber hinaus hängt sie primär von dem Abstraktionslevel ab. Je abstrakter das Niveau ist, desto größer ist die Herausforderung daraus eine entsprechende Software zu generieren. Das ist nur natürlich, denn ein höheres Abstraktionsniveau bedeutet mehr Freiheitsgrade für die Software zur Codegenerierung. Diese Freiheitsgrade sinnvoll auszufüllen ist alles andere als leicht. Generell können wir also erwarten, dass ein höheres Abstraktionsniveau bei einer modellbasierten Codegenerierung zu einer schlechteren Performance führen wird. Das ist unzweifelhaft ein Nachteil, aber natürlich gibt es auch Vorteile die ein hohes Abstraktionsniveau mitbringt. An der Analogie zu Programmiersprachen, man denke an Assembler im Vergleich zu C++, wird es einem klar. Unter anderem werden die Entwicklungszeiten verkürzt und die Wiederverwertbarkeit erhöht.

Wir können also zusammenfassen, dass es eine Art Tauschgeschäft gibt zwischen dem Abstraktionsniveau und der Performanz. Ein Modellbasierter Ansatz, besonders wenn er nicht auf spezielle Domänen (E-Technik, Mehrkörpermechanik, Materialstress) festgelegt ist, wird aktuell nicht die gleiche Performanz erreichen können wie ein Experte, der direkt den Code schreibt und den Modellierungsprozess überblickt. Diese Person wird im Allgemeinen deutliche bessere Performanz bzgl. Rechenleistung und Speicherbedarf erreichen, aber ebenso wesentlich mehr Arbeitsstunden benötigen.

A pendulum modelled with the Modelica Standard Library

Physical Modelling

Neben Werkzeugen, wie Simulink die quasi ausschließlich auf der mathematischen Modellierungsebene arbeiten gibt es auch noch Ansätze auf der physikalischen Modellierungsebene zu arbeiten. Das Ziel einer solchen "physical modellings" ist es ohne größere Einschränkungen bzgl. der Domäne den modellierenden Ingenieur einen abstrakten Zugang zu ermöglichen. Dadurch soll es möglich werden, dass sich der Ingenieur auf die Aspekte der physikalischen Modellierung beschränken kann und schnell z.B. Prototypenentwürfe evaluieren kann. Auf den niedrigeren Abstraktionsebenen ist schwieriger auf schnell wechselte Designs und Anforderungen zu reagieren. Gerade in frühen Entwicklungs- und Designphasen sind Änderungen hier die Regel und nicht die Ausnahme. Ein weiterer Aspekt sind natürlich auch hier Programmierfehler, die durch eine Codegenerierung vermieden werden können. Ich kenne allerdings noch kein Tool das wirklich rein auf der physikalischen Ebene operiert. Ansätze wie SimScape oder Modelica versuchen zwar eher auf der physikalischen Ebene anzusetzen, nach meiner Meinung handelt es sich allerdings nicht vollständig um eine physikalische Modellierung, weil die entsprechenden Komponenten fest mit einer mathematischen Beschreibung gekoppelt sind. Da wie oben erwähnt wurde die Zuordnung von physikalischem und mathematischem Modell nicht eindeutig ist, werden ihr auf eine etwas ungünstige Weise beide Modellierungsebenen vermischt. Der nächste Schritt im Bereich "Physical Modelling" ist hier also noch offen.

Weiterführende Links

• Modelica Webpage - Modelica is an object-oriented, declarative, multi-domain modeling language. I think it is somewhere between what I call the physical and the mathematical model
• SimScape - A Modelling language form TheMathWorks
• MapleSim - A high level modelling tool form MapeSoft
• Center for Model-based Product Development in Linköping

last modified by Joerg Frochte on March 1st 2010