System-Dynamics-Diagramme als “Physical Modeling” -eine Frage der Kausalität

Peter Junglas1

1 FHWT Vechta/Diepholz/Oldenburgpeter@peter-junglas.de

System-Dynamics-Diagramme gelten als sehr einfaches Modellierungswerkzeug, das sich leicht mit tra-ditionellen Methoden nachbilden lässt. Wie einige Beispiele zeigen, ist die Situation jedoch komplizierter:Die Kausalität - also die Frage, welche Anschlüsse eines Blocks Ein- oder Ausgänge sind - ist in manchenFällen vom Zustand des Systems abhängig. Die Entwicklung der hier vorgestellten Modelica-Bibliothekerforderte daher einige Vorüberlegungen, die im weiteren ausführlich dargelegt werden.

1 Einleitung

Die System-Dynamics-Methode ist ein Modellie-rungsverfahren, das vor allem in nicht-technischenGebieten wie der Ökonomie oder der Ökologieverwendet wird [1]. Kommerzielle Programme zurErstellung und Simulation von System-Dynamics-Diagrammen sind weit verbreitet (z. B. Stella von iseesystems [2]), es gibt aber auch eine frei verfügbareImplementation, die auf Modelica basiert [3].

Angesichts der grundsätzlich sehr einfachen Strukturder Diagramme könnte man annehmen, dass sie sichleicht durch geeignete Blöcke etwa in Simulink im-plementieren lassen. Es stellt sich aber heraus, dassin einigen Situationen die Signalflussmethode nichtgut zur Nachbildung geeignet ist. Der Grund dafürist, dass die Kausalität der Blöcke - also die Frage,welche Anschlüsse Eingänge bzw. Ausgänge sind -nicht immer durch das Diagramm festgelegt ist, son-dern sich abhängig vom Zustand des betrachteten Sys-tems ändern kann. Für die Erstellung einer System-Dynamics-Bibliothek eignen sich daher auf “PhysicalModeling” basierende Methoden besser, bei denen dieKausalität eines Blocks sich erst dynamisch im Kon-text des gesamten Systems ergibt.

Im Folgenden wird das grundlegende Problem aneinfachen Beispielen erläutert und eine in Modelicaprogrammierte System-Dynamics-Bibliothek vorge-stellt. Sie wurde für das Lehrbuch [4] erstellt und

kann von der Homepage des Autors frei herunterge-laden werden [5]. Die bereits vorhandene Modelica-Implementierung von Cellier et al. [3] beachtet diehier betrachteten Effekte nicht, da sie vor allem imHinblick auf die bekannten Weltmodelle erstellt wor-den ist, bei denen keine Kausalitätprobleme auftreten.

2 Grundlegende System-Dynamics-Diagramme

System-Dynamics-Diagramme setzen sich i. W. ausnur drei verschiedenen, aber sehr allgemeinen Grund-bausteinen zusammen: Die Zustandsgrößen werdenals Speicherelemente (Reservoirs) dargestellt, die ih-ren Wert durch Zufluss bzw. Abfluss ändern. Ven-tilbausteine (Flows) bestimmen die Stärke der Flüs-se, sie verlaufen zwischen Reservoiren oder externenQuellen und Senken. Zur Berechnung können sie aufdie Werte von Zwischengrößen zurückgreifen, die mitConvertern bestimmt werden. Abb. 1 zeigt diese Blö-cke im Zusammenhang.

Als Beispiel werde ein einfaches Modell zur Bevölke-rungsentwicklung betrachtet: Die BevölkerungsgrößeN ändert sich durch die Zahl G der Geburten pro Zeitund die Zahl T der Todesfälle pro Zeit. Für G wirdeine konstante Rate g angenommen, während T zu-

203

System-Dynamics-Diagramme als “Physical Modeling” - eine Frage der Kausalität

Abbildung 1: System-Dynamics-Basisblöcke

sätzlich eine feste Kapazitätsgrenze Nk enthält:

G = gN

T = tN mit t =t0

1−N/Nk

Im fertigen Modell (s. Abb. 2) werden die Parameterg, t0 und Nk jeweils in Convertern bereitgestellt, einweiterer Converter berechnet daraus die Rate t. DieFlows schließlich multiplizieren einfach ihre beidenEingänge, um die Flüsse G bzw. T zu erhalten. DasDiagramm zeigt nur die grundsätzlichen Zusammen-hänge zwischen den Größen, die konkreten Formelnsind implizit in den Blöcken enthalten.

Abbildung 2: Modell bevoelkerung

Die Kausalität der Bausteine ist hier ganz klar: Con-verter haben mehrere Eingänge und einen Ausgang,die untereinander oder mit entsprechenden Eingängender Flows verbunden werden. Ein Flow berechnet dar-aus den Wert des Flusses und gibt ihn als Ausgangan die angeschlossenen Reservoire weiter. Dabei darfman sich durch die Pfeile im Diagramm nicht verwir-ren lassen: Diese zeigen nur die (positive) Richtungder Flüsse an, die Signalflüsse dagegen verlaufen im-mer von den Flows zu den Reservoiren. Diese subtra-hieren schließlich ihre beiden Eingangswerte und be-stimmen durch einfache Integration den Wert der Zu-standsgröße, der zusätzlich als Ausgangswert bereit-gestellt wird. Dieses Prinzip wurde bei der Modelica-

Bibliothek von [3] verwendet und lässt sich leichtauch in Simulink implementieren.

3 Modelle mit variabler Kausali-tät

3.1 Reservoir mit Sättigung

Ein Reservoir-Baustein kann optional einen Minimal-und einen Maximalwert angeben. Im Beispielmodellabfluss (s. Abb. 3) hat das erste Reservoir S1 einenMinimalwert von 0 und einen Startwert von 4, der ab-gehende Fluss ist konstant 0.5. Das Ergebnis der Si-

Abbildung 3: Modell abfluss

mulation zeigt Abb. 4: Aufgrund des konstanten Ab-flusses nimmt der Wert von S1 linear ab, bis bei t = 8der Minimalwert 0 erreicht ist, und bleibt dann kon-stant. Das nachgeschaltete Reservoir S2 verhält sichgegenläufig, insbesondere bleibt auch sein Wert ab t =8 konstant.

Abbildung 4: Ergebnis von abfluss

Auf den ersten Blick scheint es, als ließe sich diesesModell leicht in Simulink nachbilden, indem man beiden Integratoren Saturation limits einführt. Aber

204

System-Dynamics-Diagramme als “Physical Modeling” - eine Frage der Kausalität

das Problem liegt tiefer: Zwar lässt sich der Wert vonS1 leicht auf 0 beschränken, aber das folgende Reser-voir S2 steigt trotzdem immer weiter an. Man mussvielmehr dafür sorgen, dass ab t = 8 der Fluss aus S1und damit auch in S2 verschwindet. Es liegt hier einKausalitätsproblem vor: Bis t = 8 bestimmt der Flow-Baustein die Größe des Flusses, danach aber legt S1den Fluss auf 0 fest.

3.2 Modellierung einer Fertigungsma-schine mit Oven

Besonders deutlich wird das Problem beim BlockOven, einem diskreten Modell für eine generi-sche Fertigungsmaschine. Er hat die drei Parame-ter initialLoad, capacity und cookingTime undverhält sich wie ein einfaches Backblech: Er wirdzunächst gemäß seines Eingangsflusses beladen, bisdie Kapazität erreicht wurde. Anschließend beginntdie Verarbeitungszeit, an deren Ende der gesamteInhalt als Ausgangsfluss erscheint. Das grundsätzli-che Verhalten des Blocks zeigt das Modell oven1(s. Abb. 5) mit den Parametern initialLoad = 0,capacity = 3 und cookingTime = 2. Der Ein-gangsfluss ist auf den konstanten Wert 2 eingestellt,der Ausgangsfluss auf den Wert 1.

Abbildung 5: Modell oven1

Der Plot in Abb. 6 zeigt oben den Eingangs- und Aus-gangsfluss, unten den Beladungszustand des Oven.Zur Zeit t = 2 gelangen zunächst zwei Einheiten, dannnur noch eine in den Oven. Bei t = 3 ist er voll be-laden, die Verarbeitungszeit beginnt. Danach, bei t =5, werden drei Einheiten herausgegeben, gleichzeitigkommen schon die ersten zwei neuen Teile an. Dasgenaue Timing, insbesondere die Überlappung, sindnatürlich diskutabel. Als Vorbild diente das Verhaltendes entsprechenden Blocks im Programm Stella.

Die Größe des Eingangsflusses hängt hier in kompli-zierter Weise vom vorgeschalteten Flow-Baustein undvom Zustand des Ovens ab: Während der Beladungs-

Abbildung 6: Ergebnis von oven1

phase gibt der Flow den Wert vor, bei Erreichen derKapazität arbeiten Zustand des Ovens und Flow-Wertzusammen, während der Bearbeitungsphase setzt derOven den Eingangsfluss auf Null. Der Ausgangsflowwird dagegen komplett vom Zustand des Oven be-stimmt: Während der Beladungs- und Bearbeitungs-phase ist er Null und steigt nur während des Ausla-dens auf den Wert capacity. Der im nachgeschalte-ten Flow-Baustein vorgegebene Wert wird völlig igno-riert.

Noch komplizierter wird es, wenn man das Modelloven1 um Reservoir-Blöcke S1 und S2 an Ein- bzw.Ausgang erweitert: Wenn S1 leer läuft – und nach un-ten auf Null beschränkt ist –, ergibt sich sein Aus-gangsfluss durch seinen Inhalt, die (Maximal-)Größedes Flusses und den Beladungszustand des Ovens. Er-gebnisse eines solchen Simulationslaufs zeigt Abb. 7.

Und sollte das Ausgangsreservoir nach oben be-schränkt sein, bricht die Simulation zusammen: DerOven will seinen Inhalt abgeben, aber das Ausgangs-lager hat nicht mehr genug Platz. Natürlich ist das ei-ne Situation, die man nicht nur im Modell vermeidenwill.

3.3 Modellierung von Oven in Simulink

Dass die Kausalität der Verbindungen sich mit demZustand ändern kann, heißt natürlich nicht, dass sichein solches Modell mit der Signalflussmethode, al-so etwa in Simulink, nicht erstellen ließe. Allerdings

205

System-Dynamics-Diagramme als “Physical Modeling” - eine Frage der Kausalität

Abbildung 7: Ergebnis von oven2

muss man die Kausalitätsprobleme hier selbst lösen.Dazu erhält der Flow-Block neben seinem Eingangfür den gewünschten Flow-Wert zwei weitere Ein-gänge, die die maximal möglichen Flüsse der beidenbenachbarten Reservoire bekommen. Durch einfacheBildung des Minimums wird daraus der tatsächlicheFluss bestimmt. Auch der Block Oven lässt sich mitetwas Mühe mit Bausteinen der Standardbibliothekaufbauen, z. B. indem man seinen Modelica-Codenachbildet. Er hat einen Eingang für den Eingangs-fluss sowie zwei Ausgänge für den Ausgangsflussund den aktuellen Beladungszustand. Dazu kommt einweiterer Ausgang, der den momentan möglichen ma-ximalen Eingangsfluss angibt. Daraus lässt sich leichtdas Modell oven1 erstellen (s. Abb. 8), das die obigenWerte reproduziert.

Abbildung 8: Modell oven1 in Simulink

Das Modell lässt sich leicht um zwei Standard-Reservoire erweitern, wobei das Eingangslager in ana-loger Weise seinen Restbestand an den nachgeschal-teten Flow meldet. Allerdings tritt hier ein Problemam Ausgang des Oven-Blocks auf: Er gibt seinen

Ausgangsfluss in voller Größe ab, auch wenn derFlow einen kleineren Wert vorgesehen hat. Um diesnachzubilden, enthält der Flow-Baustein als Parame-ter die Option, bei der Berechnung des Flusses seinen“Wunschwert” einfach zu ignorieren. Das fertige Mo-dell (s. Abb. 9) reproduziert wieder die Ergebnisse vonoben.

Abbildung 9: Modell oven2 in Simulink

Trotz dieser Erfolge erscheinen die Simulink-Modellesehr adhoc, sie lassen die Einfachheit und Flexibili-tät der ursprünglichen System-Dynamics-Diagrammevermissen. Außerdem entsteht aufgrund der starrenRegeln für die Anordnung von Ein- und Ausgängenam Block ein ziemlicher “Drahtverhau” an Signallei-tungen. Eine etwas einfachere, aber weniger flexibleImplementierung der hier betrachteten Beispiele wirdin [4] beschrieben.

4 Modelica als Basis einerSystem-Dynamics-Bibliothek

4.1 Bibliotheken in Modelica

Die Frage der Kausalität stellt sich in auf Modelicabasierenden Physical-Modeling-Systemen in ganz an-derer Weise [6]: Statt festzulegen, welche Größen alsEingangswerte verwendet werden, um damit andereals Ausgangswerte zu berechnen, werden für jedenBlock nur die verknüpfenden Gleichungen angege-ben, ohne dass sie nach bestimmten Größen aufge-löst sind. Zusätzliche Gleichungen ergeben sich beiVerbindungen der Blöcke. Dazu unterscheidet manzwei Typen von Größen: Flow-Variable addieren sichan Verbindungspunkten zu Null – sie entsprechen oftZeitableitungen von Erhaltungsgrößen –, Potential-Variable haben an einer Verbindung einen konstantenWert.

206

System-Dynamics-Diagramme als “Physical Modeling” - eine Frage der Kausalität

Wie sich das aus diesen Gleichungen schließlich erge-bende System – häufig ein DAE-System – simulierenlässt, ist ein schwieriges Problem, das zum Glück in-zwischen gut verstanden ist [7]. Die dazu entwickeltenAlgorithmen wurden in Modelica-basierten Simulati-onsprogrammen wie Dymola oder MapleSim imple-mentiert.

Die in Modelica erreichte hohe Flexibilität hat al-lerdings vor allem bei der Entwicklung von Block-Bibliotheken ihren Preis: Da nicht festgelegt wird,welche Größe wo berechnet wird, ist nicht auto-matisch gewährleistet, dass die Verknüpfung belie-biger Blöcke zu einem geschlossenen System führt,bei dem die Zahl der Gleichungen und Variablengleich groß sind. Abhilfe schafft das in [8] vorge-stellte Verfahren: Man definiert an den Verbindungs-punkten (Connectoren) jeweils gleich viele Variablevom Flow- und Potential-Typ und gibt jedem Blockso viele Gleichungen, wie er externe Flow-Variablehat. Darüber hinaus kann man noch “gewöhnliche” Si-gnalleitungen definieren, die als Ein- oder Ausgängegekennzeichnet sind. Hier benötigt jede Ausgangsgrö-ße natürlich eine entsprechende Gleichung im Block.

4.2 Konzeption des Connectors

Diese Überlegungen sollen nun beim Aufbau einerSystem-Dynamics-Bibliothek in Modelica angewen-det werden. Startpunkt ist dabei die Definition einesgeeigneten Connectors MassPort, der die Größe ei-nes Flows als Modelica-Flow-Variable dm enthält, ent-sprechend der integrierten Zustandsgröße m. Zwei Fra-gen müssen nun geklärt werden:

1. Welche Größe kommt als dm begleitendePotential-Variable in Frage?

2. Wie werden die Gleichungen auf die Blöcke, ins-besondere auf Reservoirs und Flows, aufgeteilt?

Motiviert von der in Abschnitt 2 vorgestellten Grund-systematik von System-Dynamics-Modellen soll dieIntegration des Flusses im Reservoir geschehen, dasdazu folgende Gleichung enthält:

der(m) = inflow.dm + outflow.dm;

Dabei ist, wie in Modelica üblich, eine Flow-Variablepositiv, wenn der Fluss in den Block einströmt.

Ein Flow-Block dagegen berechnet den Wert von dmmit Hilfe seiner Eingangsgrößen. Dabei muss er aber,wie in Abschnitt 3 deutlich wurde, auch die Zustän-de der angeschlossenen Reservoire berücksichtigen.Daher schicken diese die benötigten Informationenals reelle Variable data, die die Rolle der Potential-Variablen übernimmt. Angesichts der oben vorgestell-ten Beispiele gibt es drei Möglichkeiten, wie der Wertvon data verwendet werden kann:

1. gar nicht, das Reservoir übernimmt den vomFlow vorgegebenen Wert,

2. der Flow wird auf data gesetzt,

3. der Flow wird durch data begrenzt.

Fall 1 entspricht der “Standard-Situation”, Fall 2 z. B.dem Ausgang des Oven, Fall 3 tritt bei Reservoirenmit Sättigung oder bei der Beladung eines Oven auf.

Dieses Verhalten ließe sich implementieren, indemman im 1. Fall data = 0 setzt und die beiden ande-ren Fälle durch das Vorzeichen von data unterschei-det. Dies verhindert aber die Möglichkeit, in zukünfti-gen Erweiterungen neue Verwendungsmöglichkeitenvon data vorzusehen. Außerdem ist der Test auf Nullbei reellen Variablen generell eine schlechte Idee. Da-her wird der Connector um eine ganzzahlige Varia-ble info erweitert, mit der ein Reservoir den entspre-chenden Fall anzeigt. Diese Größe hat eine fest vor-gegebene Kausalität: Sie wird im Reservoir berech-net und im Flow verwendet. Es müssen also zwei Va-rianten des Connectors verwendet werden, bei deneninfo als output bzw. input gekennzeichnet ist:

connector MassPortR"mass port of reservoirs"flow Real dm;Real data;output Integer info;

end MassPortR;

connector MassPortF"mass port of flows"flow Real dm;Real data;input Integer info;

end MassPortF;

207

System-Dynamics-Diagramme als “Physical Modeling” - eine Frage der Kausalität

4.3 Aufbau der System-Dynamics-Bibliothek

Nach diesen Vorüberlegungen lässt sich nun eineSystem-Dynamics-Bibliothek ohne Probleme aufbau-en. Sie enthält die vier Unterpakete:

• Interfaces

• Reservoirs

• Converters

• Flows

In Interfaces befinden sich die Definitionender Connectoren, Basisklassen und Hilfsfunk-tionen. Sie enthält insbesondere die FunktionconstrainedRate, die den von einem Fluss vor-gegebenen Wert mit den data- und info-Wertenzweier MassPorts kombiniert, um den tatsächlichenFluss zu bestimmen. Diese Berechnung wird überdie Basisklasse GenericFlow in alle Flow-Bausteineintegriert.

Reservoirs enthält als Standard-Reservoiredie Blöcke Stock und SaturatedStock sowieCloudSource und CloudSink für externe Quellenbzw Senken. Zum besprochenen Block Oven kommtnoch Conveyor hinzu, der ein einfaches Modell fürein Transportband darstellt. Beide sind zeitdiskret,sie arbeiten mit vorgegebener Samplerate. Ergän-zend gibt es auch diskrete Versionen StockD undSaturatedStockD.

Die Blöcke in Flows enthalten neben zweiMassPorts ggf. zusätzliche Signal-Eingänge zurBerechnung der Flüsse aus Hilfsgrößen. Die Blöckein Converters sind ausschließlich mit Signal-Anschlüssen versehen, sie sind daher in Modelica alsblock definiert worden. In auf System-Dynamics-Diagramme spezialisierten Programmen gibt es in derRegel nur je einen Converter- und Flow-Block. Diebenutzten Beziehungen werden als Parameter der Blö-cke definiert und die Zahl der Eingänge entsprechendangepasst. Leider bieten die auf Modelica basierendenProgramme keine solche Möglichkeit. Daher wurdenfür die häufigsten Verknüpfungen fertige Blöcke inden entsprechenden Unterbibliotheken bereitgestellt.Eine Besonderheit stellen SwitchedConverter undTimeSwitchedConverter dar, die in Abhängigkeit

von der Eingangsgröße oder der Zeit zwischen zweiWerten umschalten, sowie der GraphConverter,der einen funktionalen Zusammenhang durch Inter-polation von Tabellenwerten herstellt, die aus einerDatei eingelesen werden. Weitere Blöcke lassen sichdurch Ableiten von Basisblöcken mit wenigen ZeilenModelica-Code erstellen.

5 Schlussfolgerungen

Für die Entwicklung einer flexiblen System-Dynamics-Bibliothek sind die im Physical Modelinggegebenen Möglichkeiten einer variablen Kausalitätzumindest sehr hilfreich. Allerdings hätte man die imConnector verwendeten Flow- und Potential-Größenauch komplett als Signalgrößen definieren können.Die Frage der Kausalität hängt also auch davon ab,was man als “eine” Signalleitung auffasst. Auf jedenFall eignen sich die hier vorgestellten Ideen gut dazu,in der Lehre den Studierenden einen ersten Einblickin die Problematik der Kausalität zu geben.

Die konkrete Umsetzung leidet momentan an Be-schränkungen der Tools, es fehlt insbesondere dieMöglichkeit, einen funktionalen Zusammenhang alsParameter eines Blocks einzugeben. Auch das im De-tail unterschiedliche Verhalten des pre-Operators inDymola und MapleSim und des 1/z-Blocks in Simu-link erschwerte die Arbeit nicht unerheblich. Hier be-steht wohl noch ein gewisser Klärungs- bzw. Verbes-serungsbedarf.

Zwar sind für die wichtigsten Zusammenhänge ferti-ge Blöcke in der System-Dynamics-Bibliothek vor-handen, weitere lassen sich durch Ableiten vorhan-dener Blöcke mit wenigen Zeilen Modelica-Codeleicht erstellen. Der typische Anwender von System-Dynamics-Software hat aber wenig bis gar keine Pro-grammiererfahrung und ist von anderen Tools ein ein-facheres Vorgehen gewöhnt. Für den Einsatz in derLehre, speziell im Kontext verschiedener Modellie-rungsverfahren, ist diese Einschränkung aber nichtgravierend.

208

System-Dynamics-Diagramme als “Physical Modeling” - eine Frage der Kausalität

Literatur

[1] B. Hannon und M. Ruth. Dynamic Modeling.Springer, New York, 2. Auflage 2001.

[2] B. Richmond, S. Peterson und P. Vescuso. AnAcademic User’s Guide to STELLA. High Per-formance Systems, Inc., Lyme, N.H., 1987.

[3] F. E. Cellier. World3 in Modelica: Creating Sys-tem Dynamics Models in the Modelica Fra-mework. Proceedings of the 6th InternationalModelica Conference, Bielefeld, Germany, S.393 – 400, 2008.

[4] P. Junglas. Praxis der Simulationstechnik.Europa-Lehrmittel, Haan-Gruiten, 2014.

[5] P. Junglas. Homepage von “Praxis der Si-mulationstechnik”. Online: http://www.peter-junglas.de/fh/publications/simulation/index.html(Aufruf 2014-06-13).

[6] P. A. Fritzson. Principles of Object-OrientedModeling and Simulation with Modelica 2.1.Wiley & Sons, New York, 2004.

[7] F. E. Cellier und E. Kofman. Continuous SystemSimulation. Springer, New York, 2010.

[8] H. Olsson, M. Otter, S. E. Mattsson und H. Elm-qvist. Balanced Models in Modelica 3.0 for In-creased Model Quality. Proceedings of the 6thInternational Modelica Conference, Bielefeld,Germany, S. 21 –33, 2008.

209

210