| |
Subsysteme: Ereignissteuerung
Die Ereigniszeitpunkte zu denen ein Subsystem aktiv ist, lassen sich auf
verschiedene Weise mit Hilfe von Kontrollsignalen steuern und so von den
Ereigniszeitpunkten des Gesamtsystems abkoppeln.
Steuerung durch Vorzeichen des Kontrollsignales
Subsysteme, deren Aktivität durch das Vorzeichen des Kontrollsignales
gesteuert wird, nenn man in der Simulink-Literatur enabled subsystems.
Solche Subsysteme haben immer genau einen Kontrolleingang, der aber auch
vektoriell sein kann. Im vektoriellen Fall gilt:
Das Subsystem ist aktiv, wenn eine der Komponenten des Kontrollsignales
positives Vorzeichen hat, sonst passiv.
Im Subsystem eines Simulink Modelles wird die Steuerung durch einen
speziellen Enable-Block
erreicht, den man in Simulink 3 in der Bibliothek 'Signals & Systems'
findet. Dieser Block kann nur in Subsystemen auftreten. Der Block hat einen
Parameter, der die Werte 'held' oder 'reset' annehme kann, die über
ein pop-up Menu ausgewählt werden können.
Das folgende Modell:
umfasst ein Subsystem:
das lediglich ein Signal weiterleitet oder auch nicht. Gesteuert
wird dieses Subsystem durch einen
Signal
Generator Block.
Wenn das Kontrollsignal 'sawtooth'-Form hat mit 'Amplitude=1' und 'Frequency=1':
so ist das Subsystem leitend in den Zeitintervallen von 0 bis 0.5, 1 bis 1.5,
2 bis 2.5 u.s.w.
Hat nun das Eingangssignal 'sine'-Form hat mit Amplitude und Frequenz ebenfalls 1:
so hat das Ausgangs-Signal die Form:
Wenn wir beim Eingangs-Signal die Frequenz 0.5 vorgeben, erhalten wir beim
Ausgangs-Signal entsprechend:
Der Parameterwert des Enable-Blockes wirkt sich auf dieses Submodell nicht aus, um
seine Wirkung zu demonstrieren, müssen wir mindestens einen Block mit
einem Zustandswert im Subsystem unterbringen. Im folgenden Beispiel ist das ein
Integrator mit dem Anfangswert 0. Das Eingangs-Signal hat wieder 'sine'-Form mit
Amplitude und Frequenz 1, das Kontroll-Signal hat 'sawtooth'-Form mit
derselben Frequenz und Amplitude.
Das Ausgangs-Signal hängt nun vom Parameterwert des Enable-Blockes
ab. Ist dieser 'reset', so erhalten wir ein periodisches Ausgangs-Signal,
da jedesmal, wenn das Subsystem aktiv wird, der Zustandswert des Integrators
auf seinen Anfangswert 0 gesetzt wird.
Hat der Enable-Block dagegen den Parameterwert 'held', so behält der Integrator
währen seiner passiven Phase seinen alten Zustandswert und beginnt seine aktive
Phase mit diesem Wert.
Steuerung durch Richtung des Kontrollsignales
Alternativ zum Vorzeichen des Kontrollsignales kann die Aktivität
eines Subsystems auch durch die Richtung eines Kontrollsignales gesteuert
werden, in der sich dessen Wert ändert. Subsysteme, die in dieser
Weise gesteuert werden, nennt man in der Simulink-Literatur
triggered subsystems.
Im Subsystem eines Simulink Modelles wird die Steuerung durch einen speziellen
Trigger-Block
erreicht, den man in Simulink 3 in der Bibliothek 'Signals & Systems' findet.
Dieser Block kann nur in Subsystemen auftreten. Der Block hat einen Parameter 'Trigger type',
der bestimmt, bei welchen Zuständen des Kontroll-Signales das Subsystem
aktiv ist. Diesr Parameter kann die folgenden, über ein pop-up Menu angebotenen Werte
annehmen:
- rising, das Subsystem ist aktiv, wenn der Wert des Kontroll-Signales steigt,
- falling, das Subsystem ist aktiv, wenn der Wert des Kontroll-Signales fällt,
- either, das Subsystem ist aktiv, wenn der Wert des Kontroll-Signales steigt oder fällt,
- function call, das Subsystem ist ein 'Function-Call Subsystem', solche Subsysteme
sollen hier noch nicht behandelt werden.
Die Anwendungbereiche von enabled und triggered subsystems sind durchais verschieden.
Während ein enabled subsystem in der Regel während eines vorgegebenen Zeitintervalles
aktiv ist, sind triggered subsystems eher zu vorgegebenen Zeitpunkten aktiv. Das führt
dazu, dass in getriggerten Subsystemen keine Blöcke zulässig sind, die ein eigenes
Zeitverhalten mit sich bringen. Zulässig sind nur:
Blöcke, die ihr Zeitverhalten generell aus ihrer Umgebung erben, etwa ein Gain-Block,
diskrete Blöcke, deren 'sample time' den Wert -1 hat, die ihr Zeitverhalten also
aus ihrer Umgebung übernehmen.
Beispiel 2:
Das Modell in diesem Beispiel entspricht dem von Beispiel 1,
jedoch wurde der Enable-Block durch einen Trigger-Block ersetzt. Dem Parameter
'Trigger type' des Trigger-Blockes wurde der Wert 'either' zugewiesen.
Wenn wir am Eingang wie in Beispiel 1 ein Sinus-Signal mit
Frequenz 1 Hertz und Amplitude 1 verwenden, also sin(2*pi*t), und das folgende
Kontroll-Signal (square, Amplitude=1, Frequenz=2 Hertz) verwenden:
erhalten wir am Ausgang:
Das Subsystem leitet den Wert des Eingangssignales nur zu den Zeitpunkten
0.25, 0.50, 0.75, ... weiter, das Ausgangs-Signal hat dementsprechend,
abgesehen vom Startwert 0, der Reihe nach die Werte sin(0.5*pi)=1, sin(pi)=0,
sin(1.5*pi)=-1, ....
Beispiel 3:
Das System:
y1'(t) = -y1(t)*(alpha*y2 + beta) + gamma
y2'(t) = y2*(rho*y1 - sigma) + tau*(1+y1)
mit den Anfangswerten:
y1(0) = -1, y2(0) = 0
und den Parameterwerten:
alpha=1.5e-18, beta=2.5e-6, gamma=2.1e-6,
rho=0.6, sigma=0.18, tau=0.016
beschreibt das Modell eines Ruby Laser Oszillators, wobei y2
die Dichte der Photonen und y1 die dimensionslose 'population
inversion' angibt. Die Integration erfolgt über einem Zeitintervall
von 0 bis mindestens 2.0e+6 nsec.
Ein Simulink-Modell zu diesem Anfangswertproblem ist:
Die Simulation ist mit PCs durchführbar, die Dauer des Simulationslaufes
hängt stark von der Wahl eines geeigneten Integrators ab. Wir wollen
deshalb zunächst einen solchen suchen. Dazu integrieren wir das Problem
zunächst nur bis 4.0e+4 mit dem Dormand-Prince- und dem ODE15s-Verfahren,
also mit den Matlab-Standardverfahren für nicht- steife bzw. steife
Probleme. Wir setzen:
- Relative tolerance = 1.0e-6
- Absolute tolerance = 1.0e-8
und beobachten:
- die Schrittweiten,
- die Anzahl der Schritte,
- den Quotienten der Eigenwerte der Jacobi-Matrix,
- die Durchlaufzeiten
Die beiden ersten Beobachtungen können wir mit schon vorhandenen Bibliotheks-Blöcken
machen. Die beiden letzten wollen wir jeweils nur zu den Zeitpunkten 1e4,
2e4, 3e4 und 4e4 machen, damit der dazu notwendige Aufwand nicht zu groß
wird. Wir erreichen mit dem folgenden Modell, das obiges Modell, jedoch
ohne die beiden Scope-Blöcke, in Form eines Subsystem-Blockes Oszillator
umfasst. Die Schrittweiten und Schrittzahlen werden mit eigenen Subsystem-Blöcken
aufgezeichnet, die zu jedem Ereigniszeitpunkt des Gesamtsystems aktiv sind.

Zusätzlich umfasst das Modell ein getriggertes Subsystem, das anzeigt:
- die Durchlaufzeiten (Echtzeit)
- den Quotienten von betragsgrößtem und betragskleinstem Eigenwert der
Jacobi-Matrix. Diesr Quotient wird nur berechnet, solange die Realteile
beider Eigenwerte negativ sind. Der Quotient wird 'Steifigkeit' oder auch
'Steifigkeitsquotient' des Systems genannt.
Diese Zeitpunkte, zu denen dieses Subsystem aktiv ist, geben wir durch die
Anstiegszeitpunkte eines
diskreten
Puls Generators vor, dessen Parameter wir wie folgt besetzen:
- Amplitude=1
- Period=2
- Pulse width=1
- Phase delay=0
- Sample time=0.5e4
Das Kontrollsignal beginnt dann zum Zeitpunkt 0 mit dem Wert 1 (Amplitude)
und behält diesen Wert
'puls width' * 'sample time' lang, also bis 0.5e4, dann fällt
der Wert auf 0 und bleibt dort bis 'period' * 'sample time', also bis 1.0e4,
zu diesem Zeitpunkt steigt der Wert wieder auf 1 und eine neue Periode
beginnt. Das Subsystem ist dementsprechend zu den Zeitpunkten 1e4, 2e4, 3e4
und 4e4 aktiv.

Das Subsystem umfasst zwei Matlab-Fcn-Blöcke, die die M-Functions aus
den M-Files 'rubytime.m' und 'eigjac.m' aufrufen.
rubytime liefert die Durchlaufszeit in Sekunden. Matlab kennt die beiden
Kommandos tic und toc. Ersteres initialisiert eine interne
Zeitmessung, letzteres liefert die Zeitdifferenz (Echtzeit) zwischen Zeitpunkt
des toc-Kommandos und dem vorangegangenen tic-Kommando. Um diese Zeitmessung zu
ermöglichen, wird:
eigjac liefert den Steifigkeitsquotienten des Systems und
wird nur berechnet, wenn die Realteile beider Eigenwerte kleiner
als 0 sind. Die M-Function lautet:
function q = eigjac(u)
% Jacobi-Matrix
J = [ -(1.5e-18*u(2)+2.5e-6), -1.5e-18*u(1);
0.6*u(2)+0.016, 0.6*u(1)-0.18 ];
% Eigenwerte(J)
w = eig(J);
% wenn alle Realteile < 0
if ( real(w) < 0 )
% Verhaeltnis der Eigenwerte
q = real(w(1))/real(w(2));
if ( q < 1 )
q = 1/q;
end
else
% in diesem Falle ist der Quotient bedeutungslos
q = 0;
end
Ergebnisse des Probelaufes:
Wir wählen als Simulationsparameter für den Probelauf:
-
Relative tolerance = 1.0e-6
-
Absolute tolerance = 1.0e-8
-
Maximale Schrittweite = 0.5e4 (vorgegeben durch die sample time der
diskreten Blöcke)
-
Simulationsintervall von 0 bis 4.0e4
Die Werte der Lösungskomponenten über diesem Simulationsintervall
sind uninteressant, sie weichen kaum von den Anfangswerten ab. Interessant
sind:
- die Werte des Steifigkeitsquotienten, die etwa bei 3e5 liegen,
- die Durchlauszeiten bei unterschiedlichen Integrationsverfahren
Mit dem Adams-Integrator ode113 dauert die Simulation auf einem 200 MHz
Pentium-Rechner etwa 10 Sekunden:
Die Durchlaufszeit beim Dormand-Prince-Verfahren liegt bei etwa 8
Sekunden.
Deutlich darunter liegen die Durchlaufszeiten bei steifen
Integratoren. Das ODE15s-Verfahren benötigt etwa 0.6 Sekunden,
die zu Beginn der Simulation anfallen:
Das modifizierte Rosenbrock-Verfahren benötigt für diese Simulation
etwa 3 Sekunde, die wie beim ode15s-Verfahren, im wesentlichen zu Beginn der
Simulation anfallen.
- die Anzahl der Integrationsschritte bei unterschiedlichen Integrationsverfahren
Der Adams-Integrator ode113 benötigt etwa 18000 Schritte, wobei
diese über das ganze Simulationsintervall etwa gleichverteilt
anfallen.
Das Dormand-Prince Verfahren benötigt etwa 8000 Schritte, die
über das gesamte Intervall etwa gleichverteilt anfallen.
Der steife Integrator ode15s benötigt demgegenüber nur
knapp 50 Iterationsschritte. Auch bei den Iterationsschritten fällt
ein großer Teil zu Beginn der Simulation an, auch wenn das
Verhältnis hier nicht so deutlich ist wie bei der Simulationsdauer.
Das modifizierte Rosenbrock-Verfahren benötigt für das Problem
etwa 300 Schritte, die etwa gleichverteilt über dem gesamten
Simulationsintervall anfallen. Es ähnelt hier eher den nicht-steifen
Integratoren als ode15s.
- die Schrittweiten der unterschiedlichen Integratoren
Der Adams-Integrator ode113 benutzt im gesamten Intervall eine
Schrittweite von etwa 2, wobei die Schrittweite mit der Dauer
der Simulation leicht wächst.
Das Dormand-Prince-Verfahren benutzt eine mittlere Schrittweite von
5, die mit der Simulationsdauer deutlicher wächst als beim
Adams-Verfahren. Die Einbrüche bei 1, 2.5 und 3.5 sind dadurch
verursacht, dass diese Ereigniszeitpunkte durch die diskreten
Blöcke vorgegeben werden und schlecht in das Schrittmuster des
Dormand-Prince-Verfahrens passen.
Der steife Integrator ode15s benutzt eine mittlere Schrittweite von
etwa 1800:
Der Einbruch bei 0.5 und 3.5 ist wieder auf die Vorgabe von Ereigniszeitpunkten durch
diskrete Blöcke zurückzuführen, die ganz schlecht in das
Schrittweitenmuster des ode15s-Verfahrens passen. Man sieht, dass das ode15s-Verfahren
geraume Zeit braucht um sich von solchen Störungen zu erholen.
Das modifizierte Rosenbrock-Verfahren benutzt etwa Schritte der Länge 150,
die im Verlaufe der Simulation erkennbar kürzer werden. Die vorgegebenen
Ereigniszeitpunkte stören das Schrittweitenmuster dieses Verfahrens deutlich.
Insgesamt zeigt dieser kurze Simulationslauf, dass der steife Integrator
ode15s wohl der am besten geeignete Integrator für dieses Problem ist,
der uns zur Verfügung steht. Wir wollen diesen Integrator benutzen,
um unser System von 0 bis 2.0e6 zu simulieren. Extrapoliert man die
beobachteten Laufzeiten, so müsste man mit dem Adams-Integrator
beim gegebenen Rechnersystem mit einer Laufzeit von etwa 500 Sekunden
rechnen, beim ode15s-Verfahren dagegen mit unter 30 Sekunden. Da bei
letzterem Verfahren praktisch die gesamte Laufzeit zum Start des
Verfahrens benötigt wurde, sind diese 30 Sekunden sehr pessimistisch
geschätzt. Allerdings gibt es auch Anzeichen dafür, dass
das Problem mit fortlaufender Simulationsdauer weniger steif wird.
Der Steifigkeitsquotient hatte über dem kurzen Simualationsintervall
eine fallende Tendenz, die Schrittweiten der nicht-steifen Integratoren
dagegen eine steigende.
Wir wollen die Laufzeiten und den Steifigkeitsquotienten auch bei dieser
langen Simulation beobachten, um den Aufwand dafür zu begrenzen,
wollen wir diese Beobachtungen aber nur alle 0.5e6 Zeiteinheiten vornehmen.
Die maximale Schrittweite passen wir dementsprechend an.
Die Integration wird in etwa 11 Sekunden durchgeführt, wobei der
größte Aufwand im Intervall von 0.5e6 bis 1.0e6 getrieben
werden muss.
Insgesamt werden etwas über 20000 Integrationsschritte durchgeführt,
wobei die Verteilung deutlich zwei unterschiedliche Bereiche erkennen lässt.
Bis 0.5e6 hat der Integrator ode15s nur wenig Mühe mit dem Problem,
danach deutlich mehr.
Der Steifigkeitsquotient bestätigt diese beiden unterschiedlichen
Bereiche, auch wenn die Beobachtungen hier viel zu weit gestreut sind,
um brauchbare Aussagen zu machen. Wir sehen, dass dieser Koeffizient
zum Zeitpunkt 0.5e6 einen Wert von etwa 250 hat und bei 1 schon nicht
mehr zu beobachten ist. Zur Erinnerung: der Anfangswert lag bei etwa 3e5.
Dasselbe gilt für die Schrittweiten, die sich im ersten Bereich
zunächst bis zu einer Länge von knapp 10000 aufbauen um
danach kleiner zu werden. Im zweiten Bereich sind die Schrittweiten
extrem kurz, wachsen gegen Ende des Simulationsintervalles aber wieder an.
Die Lösungskurven zeigen ebenfalls zwei unterschiedliche Bereiche.
y(1) steigt im Bereich von 0 bis etwa 0.5e6 monoton von -1 auf etwa +0.3 an
und bleibt danach fast konstant. y(2) bleibt im ersten Bereich dagegen fast
konstant 0 und beginnt danach extrem schnell zu schwingen. Die Schwingung
ist gedämpft und im Mittel steigt y(2) dabei leicht an.
Das betrachtete Problem lässt sich mit dem ode15s-Verfahren
auf neueren Pcs in annehmbarer Zeit lösen. Das ode15s-Verfahren
ist im Bereich bis 0.5e6 sicher auch sehr gut geeignet für
dieses Problem, die Eignung für den Zeitbereich ab 0.5e6 ist
dagegen eher fraglich und man könnte versuchen, ab diesem
Wert die Integration mit einem anderen, nicht-steifen Integrator
fortzusetzen.
Wie man an diesem Beispiel sieht, gilt:
- die Steifigkeit eines Problems kann sich im Verlaufe der
(simulierten) Zeit ändern, dementsprechend können
in unterschiedlichen Bereichen unterschiedliche Integratoren
zur Behandlung des Problems angemessen sein, was hier allerdings
nicht ausprobiert wurde,
- die Lösungskurven steifer Probleme sind meist nicht
sonderlich auffällig. Dort wo y(2) zu schwingen
anfängt, ist das Problem nicht mehr steif.
|