Rapid Control Prototyping mit Dymola und Matlab für eine ...

Rapid Control Prototyping mit Dymola und Matlab für eine
Modellgestützte Regelung in der Motorsteuerung
F. Richert, BMW AG
K. Hoffmann, A. Bollig, D. Abel, RWTH Aachen
1 Kurzfassung:
In vorliegenden Beitrag wird eine für unterschiedliche Mehrgrößen-Aufgaben der Motorregelung
einsetzbare, Modellgestützte Prädiktive Regelung basierend auf physikalischen Prozessmodellen
vorgestellt. Die Vorteile der physikalischen Prozessmodelle sowie direkt daraus
ableitbare, systematische Erweiterungen werden erläutert.
Eng verknüpft mit einem als Entwicklungsumgebung vorliegenden Simulationsmodell werden
redundante Arbeitsschritte bei der Reglerentwicklung für den verwendeten Ansatz deutlich
reduziert. Es wird die eingesetzte Entwicklungskette vorgestellt, welche einerseits die Prozessmodelle
bestmöglich wieder verwendet, andererseits durch den Einsatz modernder
Software-Werkzeuge die Handhabung auch komplexer Darstellungsformen ermöglicht.
2 Einleitung
Fortschritte in der Motorenentwicklung haben den modernen, aufgeladenen Dieselmotor zu
einem komplexen, vielfach gekoppelten System werden lassen. Getrieben durch das Spannungsfeld
aus dem Wunsch nach mehr Leistung bzw. weniger Verbrauch einerseits und immer
strengeren, einzuhaltenden Emissionsvorschriften andererseits besteht ein moderner
Verbrennungsantrieb neben dem Motorblock mit Kurbel- und Ventiltriebe aus zahlreichen
zusätzlichen Komponenten zur Leistungssteigerung und Emissionsreduktion, die sich gegenseitig
beeinflussen und optimal aufeinander abgestimmt werden müssen. Beim Dieselmotor
betrifft dies insbesondere das „erweiterte Luftsystem“ aus Aufladung, Abgasrückführung
und auch beim Dieselmotor verstärkt eingesetzte Abgasnachbehandlung in Form von
beispielsweise Dieselpartikelfilter und NO x -reduzierenden Maßnahmen. Eine Übersicht über
eine beispielhafte Konfiguration eines modernen Abgasstrangs eines solchen Motors und
damit verbundenen Regelungsaufgaben gibt Bild 1.
Es ist einleuchtend, dass für die Regelung eines solchen Systems eine Mehrgrößenregelung
ideal ist, alleine schon für die gekoppelte Betrachtung zweier Komponenten, beispielsweise
der simultanen Ladedruck- und Abgasrückführratenregelung, wurden die Vorteile solch eines
Ansatzes bereits gezeigt [1]-[4]. Modellgestützte Verfahren bieten dabei die Möglichkeit,
vorhandenes Systemwissen als Teil der Regelung zu integrieren.

Bild 1: Beispiele für Regelungsaufgaben am Dieselmotor
Den Entwurf einer solchen Regelung in einer simulationsgestützten Entwicklungsumgebung
vorzunehmen ist ein seit geraumer Zeit anerkanntes Vorgehen. Häufig kommt es hierbei zu
jedoch zu einem „Bruch“ in der Entwicklungskette: Zur Erstellung des Simulationsmodells
wird eine relativ komplexe, meist physikalisch basierte Modellbildung vorgenommen. Die im
Regler genutzten Modelle sind hingegen bislang meist relativ einfache Ansätze, die beispielsweise
mittels parametrischer Identifikation gewonnen werden. Dies bedeutet folglich
eine erneute vollständige Modellbildung gegenüber der Erstellung des Simulationsmodells,
ohne dass bereits umgesetztes Systemwissen weiter genutzt wird. Darüber hinaus wächst
mit steigender Komplexität des Gesamtsystems der Aufwand immens, der notwendig ist,
solche rein mittels Ein-/Ausgangs-Messung ermittelten Modelle zu erstellen. Wird hingegen
eine physikalisch basierte Modellbildung auch innerhalb solch einer Regelung verwendet,
sind die entsprechenden Größen vollständig vorhanden, lediglich die „Auswahl“ der Systemgrößen,
die als Ausgangsgrößen verwendet werden, wird angepasst.
Im Folgenden wird eine Entwicklungsumgebung vorgestellt, mit deren Hilfe eine Modellgestützte
Prädiktive Regelung (MPR) basierend auf physikalisch basierten Modellen entworfen
werden kann. Insbesondere soll hier die Umsetzung der Modellbildung möglichst einfach zu
handhaben sein, ausgehend von der Beschreibung einfacher Teilsysteme sollen aufwändige
Formelmanipulationen vermieden werden. Darüber hinaus wird beim hier beschriebenen
Vorgehen das vorhandene Systemwissen ideal genutzt, indem die gleichen Ansätze sowohl
in dem als Regelstrecke verwendeten Simulationsmodell als auch in der Regelung Verwendung
finden.
3 Entwicklungsumgebung
Als Kern der Entwicklungsumgebung dient Matlab/Simulink (Bild 2). Hier existiert eine detaillierte
Benutzerführung mit integrierter Versuchsverwaltung sowie einer komfortablen Umge-

ung zur Versuchsauswertung. Die Umsetzung der Regelstrecke als Mittelwertmodell wurde
hingegen in Dymola vorgenommen (Abschnitt 3.1) und anschließend in die Simulink-
Umgebung eingebunden, da dies immens Vorteile bei der Modellbildung bietet.
Die Regelung wurde als C-Code-s-function eingebunden. Als Demonstration für eine mögliche
Hardware-in-the-Loop-Verwendung wurde die Regelung zusätzlich auf automotivetypischer,
moderner Entwicklungshardware appliziert (Abschnitt 3.2).
Engine_out
Demux
T_COOL_BEC
Compressor_out
Turbine_out
P_AMB
P_AT
AirSystem_out
T_COOL_BIC
T_AMB
Ambient_input
Dymola-Engine
Emission_out
Output
S_VGT S_VGT_EDC
S_EGR S_EGR_EDC
MF_FUEL MF_FUEL_EDC
BOI
BOI_EDC
M_LOAD M_LOAD_EDC
Actuators
S_VGT_EDC N_Engine
S_EGR_EDC M_E
MF_FUEL_EDC P_AIC
BOI_EDC controlled_value_1
M_LOAD controlled_value_2
EDC
N_ENGINE Engine_out
M_E
P_AIC AirSystem_out
controled_value_1
controlled_value_2 Emission_out
Sensors
Bild 2: Oberste Ebene der Entwicklungsumgebung: Simulink als gemeinsame Basis
3.1 Umsetzung der Regelstrecke in Dymola
Zur Umsetzung der Regelstrecke wurde das Programm Dymola auswählt, das auf der freien,
objekt-orientierten Modellierungssprache Modelica basiert. Da hier keine gerichtete Umsetzung
der Gleichungen erfolgen muss, ist es zur Modellierung komplexer Systeme besonders
gut geeignet [7]. Der Anwender kann somit weite Teile der notwendigen Gleichungsmanipulation
dem Programm überlassen. Die Motor-Umsetzung in Dymola ist in Bild 3 zu sehen,
einen Code-Auszug der zu Grunde liegenden Modellierungssprache Modelica zeigt Bild 4.
Der Größenaustausch zwischen den einzelnen Elemente geschieht durch die so genannten
Connectoren simultan für beliebig viele Größen gleichzeitig, wobei zwischen Potential- und
Flussvariablen unterschieden wird [7].

Bild 3: Dieselmotor mit Turbolader und AGR in Dymola
In Verbindung mit den Vererbungsmöglichkeiten der Module sind somit die Voraussetzungen
für eine einfache Erweiterung der Modelle gegeben. Wurde die Modellbildung mit lediglich
den drei Größen Druck, Temperatur und Massenstrom begonnen, sind nur durch Modifikation
des Connectors und der allen Elementen zugrunde liegenden Basis-Klasse
(two_gas_pin in Bild 4), die zwei Gas-Schnittstellen zu Verfügung stellt, die strukturellen
Voraussetzungen für die Berücksichtigung der Gaszusammensetzung in allen Elementen
geschaffen. Auch ein „Umbau“ des Systems auf einen Bi-Turbolader ist durch Ergänzen eines
entsprechend parametrierten zweiten Turboladers denkbar, ohne dass der Rest des
Modells umgeschrieben werden muss oder sich die Schnittstellen ändern.
model Volumen;
//Vererbung der Anschlüsse
extends two_gas_pin;
//Parameter und lokale Variablen definieren
parameter Real V;
[…]
equation
//Druckänderung aus 1. Hauptsatz
p=pin1.p;
der(p)=(kappa*R/V)*(pin1.MF*pin1.T+pin2.MF*pin2.T);
//Massenbilanz
der(m) = (pin1.MF + pin2.MF);
//ideale Gasgleichung
p*V = m*R*T;
end Volumen;
Bild 4: Modelica-Code-Auszug eines Volumens
Die schon im Grundgedanken verankerte Kombination von Grafik und Modell-Code erleichtert
auf der einen Seite das Modellieren durch voll grafische Unterstützung; auf der anderen
Seite bleiben auch nicht selbst erstellte Modelle vollständig transparent, da alle Gleichungen

auf Code-Ebene einsehbar sind. Simulink bietet im Gegensatz hierzu zwar die (rein signalorientierten)
s-functions für benutzerdefinierte Blöcke an, ein Zugriff auf den Code aller bestehenden
Simulink-Blöcke ist jedoch nicht gegeben.
Weiterhin bestehen aufgrund der unterschiedlichen Herangehensweise auch deutlich Unterschiede
in der Handhabung. Durch die objekt-orientierte Modellbildung bei Dymola ähneln
die Modelle den realen Komponenten deutlich stärker, was eine intuitive Modellbildung erleichtert.
Auch die Möglichkeit, Gleichungen in beliebiger Form zu implementieren, hilft bei der Verallgemeinerung.
Es wird unabhängig von eventuell bekannten Wirkungsrichtungen modelliert.
Durch die symbolische Analyse und analytische Umformung eines Modells vor der Simulation
werden deutliche Vorteile beim Rechenzeitbedarf und der numerischen Stabilität erzielt.
Das fertige Dymola-Modell wird mittels des als Teil von Dymola verfügbaren Dymola-
Simulink-Interface eingebunden. Zur Laufzeit der Simulation wird somit ein vor-verarbeitetes
Modell simuliert, zur Bearbeitung wird jedoch der direkte Zugriff auf die Dymola-Umgebung
geboten.
Vergangenheit
Zukunft
Sollwert w
Minimierter Regelfehler
Regelgröße y^
freie Regelgröße
S_VTG_EDC
2
3
S_EGR_EDC
4
MF_FUEL
k
k+ N 1 k+
N 2
Prädiktionshorizont 1
1
ZSR_nonlin_Maple_dll
z
2
X_nonlin
Nonlinear ZSR Y_nonlin
t / Ts
1
N_ENGINE
States
Matrix A
3
Stellgröße ZSR_lin_A u
Matrix B
4
ZSR_lin_B
Matrix C
Inputs
Matrix D
k Linear ZSR k+ Nu
Stellhorizont
5
ZSR_lin_C
6
ZSR_lin_D
t / Ts
Bild 5: Hardware-Anbindung
3.2 Hardware-Anbindung
Gerade im Motorbereich ist es interessant, Teile eines Simulationsmodells mit realen Komponenten
zu einer Hardware-in-the-Loop- oder Software-in-the-Loop-Simulation zusammenzuschließen.
Für den vorliegenden Fall ist die nächstliegende Variante, die entwickelten

Regler per Steuergeräte-Emulation am realen Motor zu verifizieren. Hierfür wurde ein dSpace-System
verwendet, für das mittels des Realtime-Workshops eine sehr enge Anbindung an
Matlab existiert, so dass mit automatischer, hardwarespezifischer Code-Generierung eine
durchgängige Werkzeugkette von der grafischen Entwicklungsumgebung Matlab/Simulink
bis hin zur Hardware vorliegt (Bild 5).
4 Regelung
4.1 Modellgestützte Prädiktive Regelung
Die Modellgestützte Prädiktive Regelung nutzt ein Modell der zu regelnden Strecke, um unter
Berücksichtigung des zukünftigen Verhaltens ideale Stellgrößen zu berechnen.
Dazu wird eine Kostenfunktion J minimiert, die die Abweichung zwischen vorhergesagtem
Streckenverhalten und der Sollwerttrajektorie in einem bestimmten Zeitfenster bewertet, das
durch den sog. unteren und oberen Prädiktionshorizont N 1 und N 2 begrenzt wird (Bild 6).
Weiterhin können Änderungen oder Absolutausschläge der Stellgröße durch Aufnahme in
die Kostenfunktion berücksichtigt werden, ebenso wie weitere beliebige Kriterien, die sich
mathematisch formulieren lassen. Stellgrößenänderungen werden üblicherweise nur in einem
begrenzten Zeitraum zugelassen, dem Stellhorizont N u , um die Dimension des Optimierungsproblems
und damit den Rechenaufwand zu beschränken.
In der Grundform stellt sich diese Kostenfunktion im Eingrößenfall wie in Formel 3-1 dar.
J
N 2
Nu
2
2
= λ ⋅ ( w − yˆ)
+ µ ⋅ ∆u
(1)
N1
1
Über die Wichtungsfaktoren λ und µ kann dabei eine stärkere Gewichtung entweder der Regelabweichung
oder der Stellgrößenänderungen berücksichtigt werden. Die Sollwerttrajektorie
w wird dabei als bekannt vorausgesetzt. Die prädizierte Regelgröße y^ (, das „Dach“ in
Gleichung 1 dient dabei als Kennzeichnung, dass es sich um eine geschätzte Größe handelt,)
muss mit Hilfe des Modells der Regelstrecke abhängig von der Eingangsgrößenänderung
∆u ausgedrückt werden. Die Horizonte N 1 , N 2 , N u sowie die Wichtungsfaktoren λ und µ
dienen dabei als fest zu wählende Einstellparameter. Es bleibt eine lediglich von ∆u abhängige
Kostenfunktion J, die mit geeigneten Mitteln minimiert werden kann.
Im Mehrgrößenfall wird üblicherweise auf Matrix-Schreibweise übergegangen, wobei die
Wichtungsfaktoren λ und µ in die Wichtungsmatrizen Γ und Λ übergehen. Sie können hier
zusätzlich auch zur Wichtung der einzelnen Regelgrößen untereinander dienen. Details hierzu
finden sich in der Literatur, z.B. in [4].

Vorgehen bei der Prädiktiven Regelung
1. Aktuellen Systemzustand x k feststellen
(Beobachter mit Modell)
2. Freie Regelgröße berechnen
(Modell für Prädiktion)
3. Aktuelle Trajektorie bestimmen
4. Kostenfunktion für nächste Prädiktion aufstellen
(Modell für Prädiktion, Horizonte)
5. Kostenfunktion abhängig von Stellhorizont
minimieren (Optimierung)
6. Erstes Element des Stellvektors ausgeben
7. Neuer Zeitschritt: Zurückweichen des Horizontes
8. Ab Schritt 1 mit aktualisiertem x k wiederholen
Bild 6: Prinzip der Prädiktiven Regelung
4.2 Umsetzung und Applikation der Regelung
Zur Optimierung der Kostenfunktion stehen prinzipiell mehrere Möglichkeiten zur Verfügung.
Bei Verwendung des linearen Prozessmodells wird die Kostenfunktion J (Gleichung 1) zu
einer konvexen Funktion, deren globales Minimum garantiert werden kann. Im unbeschränkten
Fall ist daher eine analytische Lösung möglich. Sollen Nebenbedingungen berücksichtigt
werden, muss auf ein geeignetes Optimierungsverfahren zurückgegriffen werden. Sind die
Nebenbedingungen wie im vorliegenden Fall als lineare Ungleichungen darstellbar, kann das
Problem mit Hilfe der Quadratischen Programmierung, einem Standard-Algorithmus, gelöst
werden. Im vorliegenden Fall wurden Minimal- und Maximalwerte für Stellgrößen, deren Änderung
sowie der Zustände berücksichtigt.
Werden nichtlineare Streckenmodelle verwendet, wird die Kostenfunktion J beliebig komplex.
Hierfür existieren bislang keine nutzbaren Verfahren, die ein globales Minimum sicher finden
oder globale Konvergenz der Lösung garantieren. Für zahlreiche Spezialfälle existieren Lösungen,
wie z.B. bei Nutzung der Nichtlinearen Zustandsraumdarstellung für das Prozessmodell.
Der Rechenaufwand steigt in jedem Fall erheblich; mit Blick auf die verfügbare Rechenleistung
wurden keine Ansätze mit nichtlinearen Streckenmodellen verfolgt.
Mit sukzessiver Linearisierung des Reglermodells in jedem Teilschritt und Einsatz eines Extended
Kalman-Filters als Beobachter ergibt sich die Struktur der Regelung gemäß Bild 7 .

Bild 7: Struktur der eingesetzten Reglung
Als umzusetzende Teilsysteme ergeben sich folgende Bereiche:
• Nichtlineare Zustandsraumdarstellung des Reglermodells (f und g in Bild 7)
• Linearisierte Zustandsraumdarstellung des Reglermodells (A k bis D k in Bild 7)
• Beobachter-Auslegung, Prädiktion und Optimierung (L k und MPR in Bild 7)
Die beiden erstgenannten Punkte sind in jedem Fall modellspezifisch und müssen systemabhängig
erzeugt werden. Für die sukzessiv linearisierte Struktur sind alle drei Komponenten
des letztgenannten Punktes hingegen generisch umsetzbar. Details zu den Algorithmen der
Komponenten der Regelung sind in [8] zu finden
Um auch hier für die modellspezifischen Komponenten die notwendigen Entwicklungsschritte
weitestgehend zu automatisieren, wird das Formelmanipulationsprogramm Maple verwendet.
Die Umsetzung erfolgt mittels automatischer Formelmanipulation und Code-Generierung:
Die Formeln der Modellansätze werden zunächst in Maple in ihrer jeweiligen Basisform implementiert.
Die Manipulation der Gleichungen bis zur gewünschten Zustandsraumdarstellung
erfordert vom Anwender lediglich die Definition der Zustandsgrößen, die notwendigen Umformungen
werden automatisch vorgenommen. Die allgemeine Linearisierung sowie die C-
Code-Erzeugung erfolgen ebenfalls automatisch, der generierte Code muss lediglich in eine
kapselnde s-function eingebunden werden, um in Simulink verwendet werden zu können
(Bild 8).

Maple – Modellgleichungen
Belegung der Vektoren
> x :=:
u :=:
Matrix A: Linearisieren von f(x,u)
> A := Matrix(L_x,L_x):
for m from 1 by 1 to L_x do
for n from 1 by 1 to L_x do
A[m,n] := diff(f(x,u)[m],x[n]):
end do:
end do:
> A := convert(A,array):
C - CODE FÜR MATRIX A
> code_A :=
C(A,optimize=true,deducetypes=false,
defaulttype=numeric,resultname="A",
output=string):;
Bild 8: Maple-Sheet und kapselnde s-function
C-Code – s-function
static void mdlOutputs([…]){
[…]
// Variablen-Deklaration,
// von Maple erstellt
#include "Variablen.h"
//Matrizen, von Maple erstellt:
#include "ZSR_A.txt"
#include "ZSR_B.txt"
#include "ZSR_C.txt"
#include "ZSR_D.txt"
// Ausgabe Matrix A
for (ii=0; ii

Vergangenheit
k
Zukunft
Sollwert w
k
Stellhorizont
k + N
1 k +
N
2
Prädiktionshorizont
k + N
u
Stellgröße u
Minimierter Regelfehler
Regelgröße y^
freie Regelgröße
t / T
s
t / T
s
Modellbeschreibung
p
q Bp
Hardware-in-the-Loop – Dymola/dSpace
3 3´
Regelstrecke – Dymola
EDC
Pin_AT
q Bv 4
2
1
q A
Pin_BC
Reglerentwicklung –Simulink
Engine_out
Modellbildung
V
ZR-Darstellung und
Linearisierung – Maple
Belegung der Vektoren
> x :=:
u :=:
Matrix A: Linearisieren von f(x,u)
> A := Matrix(L_x,L_x):
for m from 1 by 1 to L_x do
for n from 1 by 1 to L_x do
A[m,n] := diff(f(x,u)[m],x[n]):
end do:
end do:
C-Code – s-function
static void mdlOutputs([…]){
[…]
// Variablen-Deklaration,
// von Maple erstellt
#include "Variablen.h"
//Matrizen, von Maple erstellt:
#include "ZSR_A.txt"
// Ausgabe Matrix A
for (ii=0; ii