Software-In-The-Loop Software-In-The-Loop - neue

THEMA
Entwicklungs-Tools
MODELLEXPORT VON MATLAB-MODELLEN IN SABER
Software-In-The-Loop
DIE AUTOREN
Michael Seibt schloß 1993 sein Studium an der FH München Fahrzeugtechnik mit dem Schwerpunkt Luftfahrzeuge ab. Nach verschiedenen EntwicklerTätigkeiten in der Luftfahrtindustrie trat er 1997 als Applikationsingenieur bei der
Firma Avant! ein. Seit 1998
arbeitet er als Consultant im
Automobil-Sektor (E-Mail:
Michael_ Seibt@avanticorp.
com)
Manfred Thanner studierte an der FH
Ulm und der University of Plymouth
Elektronik. Nach einer Tätigkeit als Entwickler für Smart
Power Devices bei der
Robert Bosch GmbH fing er
1997 als Systemingenieur
bei Motorola im Bereich
Halbleiter in München an.
Zur Zeit ist Herr Thanner in
der Virtual Garage von Motorola mit der kundenspezifischen Umsetzung von Simulationslösungen im Bereich der Systemsimulation für HW und SW tätig. (E-Mail:
[email protected])
50
Um die miitlerweile sehr komplexen Systeme unterschiedlicher Technologien überhaupt noch beherrschen zu können und um die Entwicklungszyklen zu optimieren, wird gerade in der Automobilindustrie immer mehr auf Simulationstools zurückgegriffen. Dabei wird aufgrund
des Einsatzes von sämtlichen Ingenieursdisziplinen wie Mechanik,
Elektronik, Hydraulik und auch Software in der Fahrzeugentwicklung
von den Simulatoren eine möglichst hohe Abdeckung gefordert.
m heutigen Fahrzeug ist nicht
nur ein zunehmender Einsatz
von Elektronik festzustellen,
auch der Software-Anteil spielt
eine immer größere Rolle. So
werden im aktuellen 7er BMW
in der Standardausstattung etwa
20, in der Maximalausstattung
sogar bis zu etwa 40 Steuergeräte
eingesetzt. Herzstück eines jeden
Steuergerätes ist dabei mindestens ein Mikrocontroller.
Durch die geschickte Kombination verschiedener Technologien
erreicht man zum einen eine
I
höhere Funktionalität und zugleich größere Integrationsdichte, zum anderen
steigt jedoch die Komplexität erheblich
(Bild 1).
Simulationswerkzeuge für die
Systemsimulation
Unter den heutigen Simulationswerkzeugen für die Systementwicklung können
grundsätzlich zwei Arten identifiziert werden.
Zum einen die Hardware-Entwicklungstools, von denen die mechatronischen Anteile abgedeckt werden und zum anderen
die Software-Designtools zur Entwicklung
Auto & Elektronik 1/2001
Entwicklungs-Tools THEMA
von Prozessor-/Controller-Algorithmen. Beide Toolgattungen decken Ihre Domaine ab; teilweise kommt es in
ihrer Funktionsabdeckung sogar zu Überlappungen.
So werden in typischen SW-Design-Tools die SoftwareAlgorithmen zunächst in Form eines Simulationsmodells als Zustandsautomat oder in der s- bzw. z-Ebene
abgebildet und in der Simulation getestet. Danach wird
über einen Code-Generator, je nach Verwendungszweck, target-abhängiger oder –unabhängiger Code erzeugt. Auf der HW-Seite kann man ebenfalls auf einem
sehr hohen Abstraktionslevel wie der Zustands- oder sEbene beginnen. Über den "Top-Down-Ansatz” erreicht
man schließlich die physikalische Ebene.
Dabei sind jedoch auf Simulationsebene der Softwareund Hardware-Designflow völlig voneinander isoliert.
Dies rührt zum einem daher, dass Hardware und Software oft separat von verschiedenen Entwicklungsgruppen oder Abteilungen mit den entsprechenden Tools erarbeitet wird und zum anderen, dass die Simulationstools meist keine geeigneten Schnittstellen aufweisen (Bild 2).
Dies bedeutet jedoch, dass Wechselwirkungen zwischen
Software und Hardware, wie sie in einem typischen
Steuergerät vorkommen, bei der Simulation nicht oder
nur ungenügend berücksichtigt werden können.
Bild 1: Prinzipieller Aufbau eines herkömmlichen Steuergerätes
Bild 2: Hardware-/Software-Designflow
Auto & Elektronik 1/2001
51
THEMA
Entwicklungs-Tools
Daher liegt es nahe, beide Funktionalitäten
miteinander zu kombinieren, um somit das
Gesamtsystem betrachten zu können. Zwei
Lösungsansätze kommen dabei in Frage:
tor bedienen. Als Nachteil ist hier der zusätzliche Konvertierungsprozess zu nennen.
Workflow Modellexport
1) Co-Simulation
Beide Tools kommunizieren miteinander
über IPC-Methoden (Inter-Process-Communication). Im allgemeinen wird zur Synchronisation beider Simulatoren der LockStep-Algorithmus oder der Fixed-TimeStep-Algorithmus verwendet. Ein Simulator, der Master, übernimmt dabei immer
die Führung. Der Slave antwortet auf die
Anfragen des Masters (Bild 3).
Bild 3: Co-Simulation
Bild 4: Modell-Export
52
Diese Ansätze haben jedoch allgemein
Nachteile bzgl. Genauigkeit und Performance. Effizientere Synchronisationsalgorithmen sind meist sehr aufwendig in der
Implementierung und setzen zu deren Nutzung entsprechende Simulatorschnittstellen voraus. Co-Simulations-Lösungen sind
außerdem meist umständlicher in ihrer Bedienung und der Anwender muss beide
Tools beherrschen.
2) Modell-Export
Das im Quell-Simulator entwickelte Modell wird in ein Format konvertiert, das
kompatibel zur Modellierungssprache des
Target-Simulators ist und anschließend in
diesen importiert
wird (Bild 4). Die
Vorteile liegen hier
in der Notwendigkeit von nur einem
Simulator bei der
Gesamtsimulation.
Dadurch
entfällt
die Synchronisation
zwischen verschiedenen Simulatoren
und man erhält eine
bessere Performance. Außerdem muss
der Anwender nur
noch einen Simula-
Am Beispiel der Gesamtsimulation eines
Schiebedachsystems mit Einklemmschutz
(EKS) soll die hier gewählte Methode des
Modell-Exports dargestellt werden. Dabei
wurde der EKS als Software implementiert.
Hierbei wurden als Hardware-Entwicklungstool der Schaltungs-Simulator SABER der Firma Avant! verwendet, der aufgrund seiner Mixed-Technology-Fähigkeit
(Elektronik analog und digital, Mechanik,
Hydraulik, Pneumatik, Magnetik, Optik,
Regelungstechnik) und seiner umfassenden Modell-Bibliotheken hohe Akzeptanz
in der Automobilindustrie gefunden hat.
Für die Software-Seite wurde mit MatlabSimulink/Stateflow einschließlich des RealTime-Workshops (RTW) und StateflowCoder der Firma MathWorks ein weit verbreitetes Tool für Software-Code-Entwicklung/-Generierung gewählt.
Für den Modellexport wurde die ANSI-CCode-Generation in den Matlab-Tools sowie das C-Interface der SABER-Modellierungssprache MAST genutzt. Der Prozess
des Modellexports beginnt mit der Modellerstellung in Simulink und/oder Stateflow.
Anschließend wird über den RTW (RealTime-Workshop) und/oder Stateflow-Coder ein Target-unabhängiger C-Code generiert. Mittels eines vom RTW gestarteten
TLC-Skripts wird außerdem aus dem CCode eine DLL, welche das Matlab-Modell
beinhaltet, und eine MAST-Schale (Wrapper) automatisch erzeugt. Anschließend
wird das fertige SABER-Modell in das Gesamtmodell eingebunden (Bild 5).
Beispiel Schiebedach mit Einklemmschutz
In Bild 6 ist das gesamte Schiebedachsystem dargestellt, wobei die Hardware in
MAST implementiert ist; hinter dem Controller steckt das konvertierte Matlab-Modell. In den Probes ist das Schaltprofil des
"Fahrers”, der Positionsverlauf des Fensters
sowie das aus dem Motorstrom gewonnene
Signal zur Einklemmbewertung zu sehen.
Bzgl. des Einklemmschutzes sind vom Gesetzgeber her sehr strenge Auflagen gesetzt.
Die maximal auftretende Einklemmkraft
darf nicht mehr als 100 N betragen, was somit sehr hohe Anforderungen an den Einklemmschutz stellt (Bild 7).
Auto & Elektronik 1/2001
THEMA
Entwicklungs-Tools
um einen definierten Wert zurück, indem
ein Signal erzeugt wird, welches die HBrücke "umpolt” und somit den Motorstrom umkehrt. Bei Erreichen der Endposition erzeugt der Controller ein zweites Signal, das den Motor kurzschließt und dadurch den Motor zum Stehen bringt.
Nutzen der Gesamtsimulation
Bild 5: Workflow - MatlabSABER-Modellexport
54
Über einen Schalter wird der Stromkreis
geschlossen und es fließt Strom über die HBrücke durch den Motor. Dadurch fährt
der Motor an und das Schiebedach fährt
über eine vom Elektromotor angetriebene
Mechanik zu. Findet während des
Schließvorgangs ein Einklemmen statt, so
wird dies durch einen erhöhten Motorstrom und der aktuellen Fensterposition
detektiert. Der im Controller implementierte Algorithmus fährt das Schiebedach
Um diesen Auflagen gerecht zu werden,
muss das Gesamtsystem, die Software und
auch die Hardware gemeinsam betrachtet
werden. Dadurch können über die Simulation des Gesamtsystems verschiedene Einflüsse auf den Einklemmschutz untersucht,
bewertet und optimiert werden:
컄 Toleranzen
Bauteiltoleranzen spielen nicht nur eine
wesentliche Rolle in der Erfüllung der
Funktionsspezifikation, sondern sind
auch ein wesentlicher Kostenfaktor.
Über die Vergabe von Toleranzen und
Auto & Elektronik 1/2001
THEMA
Entwicklungs-Tools
Bild 6: Schiebedach-Gesamtmodell mit Einklemmschutz
Toleranzverteilungen an den Modellparametern kann über eine anschließende
Monte-Carlo-Analyse der Einfluß der Toleranzen auf die Performance des Systems gemacht werden.
In Bild 8 ist zu erkennen, dass bei ungünstigen Kombinationen von Paramtern in
Ihrem Toleranzbereich die max. Zulässige
Einklemmkraft überschritten werden kann.
컄 Antriebsauslegung
Bei zu hoch gewählter Motorkonstante kt
kann die gesetzlich maximal zulässige
Einklemmkraft ebenfalls überschritten
wird (Bild 9). Der Einklemmschutz ist in
diesem Fall zu träge, um auf das hohe
Motormoment zu reagieren.
컄 Alterungs- und Temperatureffekte
Durch die Abbildung von Alterungsmodellen und Temperaturabhängigkeiten
können deren Einflüsse ebenfalls berücksichtigt werden. Dabei hat der Entwickler
die Freiheit, lokale Temperaturen oder
sogar Temperaturprofile zu definieren.
컄 Sensorauflösung
Nur bei einer ausreichend hoch gewählten Sensorauflösung kann garantiert
werden, daß der Einklemmfall rechtzeitig
detektiert wird. Dabei ist die Auswahl des
Bild 8: Maximale Einklemmkraft aufgrund von Bauteiltoleranzen
56
Sensors stets ein Kompromiss aus Funktion und Preis. Durch Parametervariation sind solche Aussagen in der Simulation leicht erhältlich.
컄 Reaktionszeit
Die Gesamt-Reaktionszeit des Einlemmschutzes und damit die maximale Einklemmkraft wird durch die Summe der
Todzeitglieder sämtlicher Komponenten
zwischen Sensor und Stellglied bestimmt.
Anhand einer Transient-Analyse kann
beispielsweise sehr leicht der Anteil jeder
einzelnen Komponente ermittelt werden.
컄 Fehlfunktionen (FMEA)
Ein Einklemmschutz muß ebenfalls eine
gewisse Robustheit gegenüber äußeren
Störungen aufweisen. Durch den Einsatz
Bild 7: Einklemmschutz-Algorithmus in Simulink
geeigneter Toolboxen zur FMEA-Analyse
wie FMEA/Testify können in ein Simulations-Gesamtmodell gezielt Fehler wie
Kurzschlüsse, Unterbrechungen, Masseversatz, Klemmen injiziert und deren
Auswirkungen analysiert werden.
Auch für den Controller kann mit Hilfe der
Gesamtsimulation ein genaueres Anforderungsprofil erstellt werden (Bild 10). Aussagen zu Prozessortakt, Verarbeitungsgeschwindigkeit, nötige Controller-Peripherie, Speicherbedarf und Fixed-Point-Einfluß helfen dem Entwickler bei der späteren
Auswahl eines geeigneten Mikrocontroller.
Die vorgestellte Methode ermöglicht es sogar unter Verwendung des VC++-Debuggers das Debuggen des Controller-Codes
während der Simulation. Es stehen dabei
natürlich die für den Debug-Prozess üblichen Mittel wie Breakpoints, (Single-)
Auto & Elektronik 1/2001
Entwicklungs-Tools THEMA
Bild 9: Einklemmkraft als Funktion der Motorkonstante
Bild 10: Maximale Einklemmkraft in Abhängigkeit vom Prozessortakt
Stepping und Variablendisplay zur Verfügung.
Die Betrachtung der Hardware und der Software für
sich liefert nur die halbe Wahrheit. Oft werden deswegen
Unzulänglichkeiten im Gesamtsystem erst im Hardware-Versuch oder sogar erst im Feldeinsatz identifiziert. Dies kann im "harmlosesten” Fall zu zeit- und kostenaufwendigen Re-Designs führt, im schlimmsten Fall
zu Rückrufaktionen.
Durch die Möglichkeit der Simulation des Gesamtsystems -Software und Hardware- steht den Entwicklern
der unterschiedlichen Fachbereichen schon in der Konzeptphase eine gemeinsame "Kommunikationsplattform” zur Verfügung. Somit können früh im Designzyklus Schwachstellen im System erkannt und korrigiert
werden was letztendlich die vielzitierte "Time-to-Market” erheblich reduziert.
Literatur
[1] Motor Control Electronics Handbook, Richard Valentine, McGraw-Hill
[2] Halbleiter-Schaltungenstechnik, Tietze Schenk, Springer-Verlag
[3] Präsentation Joachim Langenwalter, System Simulation in the Automotiv Industry
[4] Real-Time Workshop User’s Guide, The MathWorks
[5] Simulink User’s Guide, The MathWorks
[6] Präsentation Automatischer Modell-Export von Matlab/Simulink Modellen nach Saber, Manfred Thanner
466
Auto & Elektronik 1/2001
57