[an error occurred while processing this directive]   Suche  
 

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.

Beispiel 1:

Das folgende Modell:

Modell mit enabled subsystem

umfasst ein Subsystem:

Enabled 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':

Sägezahn-Signal

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:

Sinus-Signal

so hat das Ausgangs-Signal die Form:

Ausgangs-Signal

Wenn wir beim Eingangs-Signal die Frequenz 0.5 vorgeben, erhalten wir beim Ausgangs-Signal entsprechend:

Ausgangs-Signal bei geändertem Eingangs-Signal

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.

Subsystem mit Integrator

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.

Integration mit Parameterwert reset

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.

Integration mit Parameterwert held

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.

    Modell mit triggered subsystem

    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:

    square signal

    erhalten wir am Ausgang:

    Ausgangssignal

    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: 

    Modell zum Ruby-Laser Oszillator

    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.

    Startmodell

    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.

    getriggertes Subsystem

    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:

    • das Subsystem mit dem Initialisierungskommando 'tic;' gestartet
    • umfasst die M-Function rubytime das Kommando 'toc;'
         function t = rubytime(u)
         t = toc;

    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,

      Steifigkeitsquotient

    • die Durchlauszeiten bei unterschiedlichen Integrationsverfahren

      Mit dem Adams-Integrator ode113 dauert die Simulation auf einem 200 MHz Pentium-Rechner etwa 10 Sekunden:

      Durchlaufszeit mit Adams-Integrator

      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:

      Durchlaufszeit mit Adams-Integrator

      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.

      Integrationsschritte mit Adams-Integrator

      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.

      Integrationsschritte mit ode15s-Integrator

      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.

      Schrittweiten mit Adams-Integrator

      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.

      Schrittweiten mit Dormand-Prince-Integrator

      Der steife Integrator ode15s benutzt eine mittlere Schrittweite von etwa 1800:

      Schrittweiten mit ode15s-Integrator

      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.

      Schrittweiten mit ode15s-Integrator

    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.

    Laufzeit, gesamtes Intervall

    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.

    Integrationsschritte, gesamtes Intervall

    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.

    Steifigkeitskoeffizient, gesamtes Intervall

    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.

    Schrittweiten, gesamtes Intervall

    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.

    Lösungskomponente y(1), gesamtes Intervall

    Lösungskomponente y(2), gesamtes Intervall

    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.