Herausgeber: LuK GmbH & Co. - schaeffler.com · 19 Codegenerierung contra Manufaktur. 228. LuK...

Herausgeber: LuK GmbH & Co.Industriestrasse 3 • D -77815 Bühl/Baden

Telefon +49 (0) 7223 / 941 - 0 • Telefax +49 (0) 7223 / 2 69 50Internet: www.LuK.de

Redaktion: Ralf Stopp, Christa Siefert

Layout: Vera Westermann

Druck: Konkordia GmbH, BühlDas Medienunternehmen

Printed in Germany

Nachdruck, auch auszugsweise, ohneGenehmigung des Herausgebers untersagt.

Vorwort

Innovationen bestimmen unsereZukunft. Experten sagen voraus,dass sich in den BereichenAntrieb, Elektronik und Sicherheitvon Fahrzeugen in den nächsten15 Jahren mehr verändern wirdals in den 50 Jahren zuvor. DieseInnovationsdynamik stellt Herstel-ler und Zulieferer vor immer neueHerausforderungen und wirdunsere mobile Welt entscheidendverändern.

LuK stellt sich diesen Herausfor-derungen. Mit einer Vielzahl vonVisionen und Entwicklungsleistun-gen stellen unsere Ingenieure ein-mal mehr ihre Innovationskraftunter Beweis.

Der vorliegende Band fasst dieVorträge des 7. LuK Kolloquiumszusammen und stellt unsere Sichtder technischen Entwicklungen dar.

Wir freuen uns auf einen interes-santen Dialog mit Ihnen.

Bühl, im April 2002

Helmut Beier

Vorsitzenderder Geschäftsführung LuK Gruppe

LuK KOLLOQUIUM 2002

Inhalt

1 ZMS – nichts Neues? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Der Drehmomentwandler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Kupplungsausrücksysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Der Interne Kurbelwellendämpfer (ICD) . . . . . . . . . . . . . . . . . . . . 41

5 Neueste Ergebnisse der CVT-Entwicklung . . . . . . . . . . . . . . . . . 51

6 Wirkungsgradoptimiertes CVT-Anpresssystem . . . . . . . . . . . . . 61

7 Das 500 Nm CVT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8 Das Kurbel-CVT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9 Bedarfsorientiert ansteuerbare Pumpen . . . . . . . . . . . . . . . . . . . 99

10 Die temperaturgeregelte Schmierölpumpe spart Sprit . . . . . . . 113

11 Der CO2 Kompressor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

12 Komponenten und Module für Getriebeschaltungen . . . . . . . . 135

13 Die XSG Familie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

14 Neue Chancen für die Kupplung? . . . . . . . . . . . . . . . . . . . . . . . 161

15 Elektromechanische Aktorik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

16 Denken in Systemen – Software von LuK . . . . . . . . . . . . . . . . . 185

17 Das Parallel-Schalt-Getriebe PSG. . . . . . . . . . . . . . . . . . . . . . . . 199

18 Kleiner Startergenerator – große Wirkung. . . . . . . . . . . . . . . . . 213

19 Codegenerierung contra Manufaktur . . . . . . . . . . . . . . . . . . . . . 227

WESTEV

19 Codegenerierung contra Manufaktur . . . . . . . . . . . . . . . . . . . . . 227

227LuK KOLLOQUIUM 2002

Codegenerierung contra Manufaktur Die Software des elektrischen Zentralausrückers

Reinhard Ludes, AFT WerdohlThomas Pfund

19

19 Codegenerierung contra Manufaktur

228 LuK KOLLOQUIUM 2002

Einleitung

Software spielt im Bereich der Fahrzeugtech-nik mittlerweile eine erhebliche Rolle. Beson-ders im Fahrzeug selbst nehmen Anzahl undBedeutung von mechatronischen Systemen,die einen starken Integrationsgrad von me-chanischer und elektronisch / softwarebasier-ter Funktionalität haben, deutlich zu. Die Soft-ware nimmt hier Funktionen im Bereich Steu-ern und Regeln wahr, oder übernimmt als Au-tomatisierungslösung Funktionen, die zuvorvom Fahrer ausgeübt wurden.

Die Funktionalität der Systeme wird zuneh-mend komplexer, und diese Komplexität desSystemverhaltens wird zunehmend auf dieSoftware verlagert. Während im Bereich me-chanischer und elektronischer Hardware,auch markenübergreifend, immer mehr Platt-formen eingesetzt werden, kommt der Soft-ware auch zunehmend die Aufgabe der Indi-vidualisierung der System- und Fahreigen-schaften zu.

Die scheinbar leichte Änderbarkeit der Soft-ware unterstützt diesen Trend. Vorschub lei-sten hier auch leistungsfähige Prozessorsy-steme, die nicht nur immer preiswerter wer-den, sondern immer mehr Funktionalitätenund immer größer werdende Speicherberei-che bieten, eine Versuchung sondergleichenfür ambitionierte Entwicklerteams.

Was jedoch häufig übersehen wird, ist die Tat-sache, dass immer mehr Aufwand in Spezifi-kation, Realisierung und Test der Software so-wie der Validierung des gesamten mechatro-nischen Systems am Prüfstand und im Fahr-zeugeinsatz investiert werden muss.

Grund hierfür ist, dass die verschiedenen Me-thoden der Softwareerstellung nicht Schrittgehalten haben mit den Anforderungen, diean Softwaresysteme gestellt werden. Sie ha-ben auch nicht Schritt gehalten mit den Kom-plexitäten, die tagtäglich von vielköpfigen Ent-wicklungsmannschaften erzeugt bzw. verur-sacht werden.

Zwar gab und gibt es bei den Programmier-sprachen Fortschritte, eine Reihe von Ent-wurfsmethoden haben sich etabliert, um denEntstehungsprozess zu optimieren, Sprach-erweiterungen wie die objektorientierte Pro-grammierung (OOP) etablieren sich auchlangsam im Echtzeitbereich, aber als Faktbleibt: Während die Software erhebliche Bei-träge im Bereich der Steuerung, Regelungund Automatisierung leistet, wird sie selbst inder Regel noch per Hand erstellt. Es handeltsich also bei der Softwareentwicklung nochum eine klassische Manufaktur.

Im vorliegenden Projekt, der Entwicklung derSoftware für einen elektrischen Zentralausrük-ker (EZA), wurde ein alternativer Weg beschrit-ten. Mit Hilfe der Werkzeugkette TDC, der Kurz-name steht für Total Development Chain der

Bild 1: Software in der Automobiltechnik

Software in der Automobiltechnik

Steuerung & Automatisierung von Funktionen

Im Fahrzeug:

• Steuer- / Regelfunktionen Einspritzung, Zündung, Motormanagement, ABS, ASR, ESP, ...

• Automatisierung Kupplung (EKM), Getriebe (ASG)

In Entwicklung & Produktion:

• Methoden & Werkzeuge CAD, CAE, CAM

• Automatisierung Robotik



Firma AFT Atlas Fahrzeugtechnik, wurdedie notwendige Reglersoftware automatischerstellt. Dies wird im Folgenden beschrieben.

Der Standard-Entwicklungsprozess für SoftwareIm Folgenden sei kurz der Standard-Prozessfür die Entwicklung von Software dargestellt.Selbstverständlich gibt es im Detail viele Va-rianten, hier seien nur die wesentlichen undgenerell typischen Schritte erwähnt (Bild 2).

Einer Idee folgend, wird zuerst die Regelstra-tegie formuliert. Dies kann schriftlich in Formeines Lastenheftes erfolgen. Eine fortge-schrittene Vorgehensweise ist die Spezifikati-on und allmähliche Detaillierung des Regler-entwurfs im Rahmen eines Simulationspro-gramms, wo sich modellbasiert seine Strukturund Parametrierung kontinuierlich verbes-sert. Gegenüber schriftlich formulierten Spe-

zifikationen und Entwürfen hat diese Vorge-hensweise den Vorteil, dass das Reglermodellgut zwischen Fachleuten aus Bereichen wie Sy-stemanalyse, Regelung und Simulation kom-muniziert werden kann.

Hat die Regler- bzw. Automatisierungsfunkti-on, zumindest im Bereich der Simulation, ei-nen hinreichenden Stand erreicht, ist es inklassischer Vorgehensweise jetzt der Soft-warefachmann, der im Hinblick auf seine Qua-lifikation aus dem Bereich Echtzeitsoftwareund Mikrocontrollerdesign stammt und letzt-lich für die Implementierung zuständig ist.

Allerdings ist das grundsätzliche Reglerkonzeptfür ihn erst der Beginn der Arbeit. Auch er musserst einmal die an ihn gestellte Aufgabe analy-sieren und ein entsprechendes Designkonzeptfür sein Echtzeitsystem erstellen, ehe über-haupt an die Implementierung, d. h. die Über-tragung von Funktionalitäten, in den konkretenCode zu denken ist. Grund für diesen Bruch, wieer auch in der Darstellung zu sehen ist, sind un-terschiedliche Sichtweisen, die in unterschied-lichen Modellansätzen münden.

Bild 2: Standard-Entwicklungsprozesse für Software



Beim Reglerdesign steht das zu regelnde Ob-jekt, z. B. im aktuellen Fall der Stellmotor alsAktor und die Kupplung als Regelstrecke, imVordergrund. Daran orientieren sich alle Mo-dellierungen. Beim Echtzeit-Softwaredesign,aber auch bei jedem anderen Design von Soft-ware, steht jedoch die Architektur des Rech-ner- bzw. Mikrocontrollersystems im Vorder-grund. Die zugrunde liegenden Modelle ori-entieren sich damit grundsätzlich an der übli-chen Architektur von Rechnerkernen bzw.Prozessoren (Von-Neumann-Maschinen),auch alle üblichen prozeduralen Program-miersprachen sind darauf ausgelegt.

Die Stärke dieses Bruchs ist unterschiedlich undhängt von den verwendeten Sprachen und Me-thoden ab. Der Bruch ist jedoch grundsätzlicherNatur. Lediglich die objektorientierte Program-mierung zeigt Ansätze, diesen zu beheben.

Es gibt mehrere Ansätze, diesen Bruch zuüberbrücken. Vor allem hängen die Auswir-kungen auf den Entwicklungsprozess davonab, wie gut die Kommunikation zwischen die-sen beiden grundsätzlichen Entwicklertypenfunktioniert.

Bei LuK beispielsweise ist es gelungen, beideQualifikationen gleichzeitig im Team oderbeim einzelnen Entwickler zu verankern. Zu-dem werden Codesegmente aus der Offline-Simulation auf Quellcode-Ebene in die Reg-lersoftware übernommen.

Codegenerierung im EntwicklungsprozessIm vorliegenden Projekt wurde der Weg derautomatischen Codegenerierung beschritten.Der verwendete Codegenerator setzt auf dermodell- bzw. simulationsbasierten Spezifika-tion des Reglers auf und erzeugt seriennahenEchtzeitcode für den Mikrocontroller im auto-motiven Steuergerät. Es liegt hier demnachein lückenloser Weg vor, von der Spezifikationder generellen über die detaillierte Strategiebis hin zum Echtzeitcode im Steuergerät(Bild 3).

Der Ansatz fördert die LuK Philosophie, grund-sätzlich nur einen Experten bzw. eine Experten-gruppe einzusetzen, um das Gesamtsystem zuentwerfen und zu implementieren: Es ist der

Bild 3: AFT-TDC im Entwicklungsprozess



Systemingenieur, der auch in der klassischenVorgehensweise den Regler entwirft. Im Co-degenerator ist implizit das Wissen vorhan-den, um einen optimalen Code zu erzeugen.Im Blick sind also von Anfang an die Funktio-nen, die sich auf das Fahrzeug bzw. auf eineseiner Komponenten beziehen. Der konkretverwendete Prozessor, die verwendete Pro-grammiersprache und das verwendete Be-triebssystem treten in den Hintergrund.

Der Bruch in der Spezifikations- bzw. gesam-ten Entwicklungskette ist überwunden.

Einsatz der TDC beim EZA – Methodik:Die geschlossene WerkzeugketteDer Einsatz der AFT-TDC bedeutet mehr als nurden Einsatz eines Codegenerators. TDC reflek-tiert eine heterogene, aber geschlossene Kettevon Werkzeugen, die den gesamten Entwick-lungsprozess unterstützt. Heterogen, weil un-terschiedliche Werkzeuge kombiniert werden,

und zwar jeweils die, die für das jeweilige Projektam besten geeignet sind. Geschlossen, weil dieErgebnisse aus dem Test wieder zurückgekop-pelt werden, um das ursprüngliche Modell evo-lutionär zu verbessern (Bild 4).

Im vorliegenden Projekt wurden eingesetzt:Matlab-Simulink für die Simulation, Tar-getLink für die Codegenerierung, das AFT-PROST als geeignetes Prototyp-Steuergerät,MARC I für die Nachkalibrierung in der Erpro-bungsphase. Bemerkenswert ist auch, dassdie Daten, die zur Kalibration, d. h. zur Fein-abstimmung, eingesetzt werden, schon in derSimulationssoftware festgelegt werden. Fürdas Applikationssystem werden zudem Be-schreibungsdateien (nach ASAP 2) erzeugt,die automatisch in das Applikationssystem ein-gelesen werden. Der Testingenieur brauchtdeshalb keine weiteren Konfigurationen an sei-nem Applikationssystem vorzunehmen.

Die während der Applikation gewonnenenDaten können wiederum in das Simulations-modell zwecks Feinabstimmung des Modellseingepflegt werden. Weiterhin können die imTest gewonnenen Messdaten aus dem Appli-kationssystem oder aus weiteren installierten

Bild 4: Charakteristika der AFT-TDC: Beispiel – LuK EZA



Messsystemen wieder in die Simulation rück-gekoppelt werden. Bei LuK stehen zu diesemZweck grundsätzlich die im Einsatz befindli-chen Datalogger RAMboX™ und TORnadO®

zur Verfügung.

Letztlich war nur der Codegenerator sowieeine Reihe von Erweiterungen im Applikati-onssystem zusätzlich zu installieren, um dieEntwicklungskette wie beschrieben aufzu-bauen. Alle weiteren Tools waren vorhandenund den Entwicklern vertraut.

Das EZA-Projekt im Spiegel des V-ModellsWie schon in der vorhergehenden Abbildungangedeutet, spiegelt die TDC eine Entwick-lungsmethodik wider, die über die reine Co-degenerierung hinausgeht. Es handelt sichum eine simulationsbasierte Entwicklungs-methodik mit ausführbaren Spezifikationen. Diegesamte Kette orientiert sich am V-Modell.Bild 5 zeigt die Umsetzung des V-Modells mitall jenen Komponenten, die bei der AFT in der

Softwareentwicklung für Steuergeräte einge-setzt werden.

Charakteristisch für das V-Modell als Grund-lage der Entwicklungsstrategie ist Folgendes:

� Jedem Entwurfsschritt auf der linken Seitestehen auf der rechten Seite die entspre-chenden Test- und Validierungsschritte ge-genüber.

� Zwischen jedem Schritt auf der linken Seitesind Übergaben und Überprüfungen not-wendig, um festzustellen, dass die im vor-hergehenden Schritt gemachten Vorgabenauch erfüllt werden.

� Daraus folgt auch: Je später ein Fehler er-kannt wird, desto mehr Schritte müssen imRahmen des Redesigns auch wieder durch-laufen werden, d. h. desto aufwändiger undteurer gestaltet sich seine Behebung. Be-sonders kritisch sind damit nicht oder fehler-haft übernommene Basis-Spezifikationen,die dann erst im letzten Glied entdeckt wer-den können.

Auf der linken Seite sind die beiden wesentli-chen Entwurfsschritte zu sehen:

Bild 5: EZA-Projekt im Spiegel des V-Modells



� Lastenheftphase – die Systemspezifikationerfolgt zum Zwecke eindeutiger Definitionenz. T. bereits auf der Basis von Simulations-modellen und Zustandsautomaten.

� Modellbildung – aufbauend auf der System-spezifikation und evtl. bereits bestehendenTeilmodellen wird eine simulierbare Struktur,eingebettet in ein mehr oder weniger genau-es Streckenmodell, erstellt.

In beiden Schritten wird MatLab Simulink ein-gesetzt, zuerst für die groben Systemstruktu-ren und Vorgaben, im zweiten Schritt dann istdas gesamte Modell von Regler und Regel-strecke im Detail definiert.

Der Prozess endet in der Spitze des V-Modellsmit Autocodegenerierung auf dem jeweiligenZielsystem. Damit wird die ursprüngliche Reg-lerspezifikation nicht nur innerhalb einer Si-mulationsumgebung, sondern auch auf ei-nem Steuergerät als Zielsystem ausführbar.Die gesamte Kette ist durchgängig.

Den beiden Entwurfselementen stehen aufder rechten Seite die entsprechenden Test-und Validierungsschritte gegenüber:

� Modell-Verifikation, d. h. Validierung dergrundsätzlichen Reglerfunktion, in der SiL –Simulation (SiL – Software in the Loop) oderggf. in einem HiL-System (HiL - Hardware inthe Loop).

� Gesamt-Systemverifikation auf Prüfstandoder Teststrecke.

Der Regler wird zunächst im Rahmen einerSiL-Simulation getestet. Bei der SiL-Simulati-on werden alle Schnittstellen zur spezifizier-ten Software ebenfalls als Modell abgebildet,so dass die Simulation ohne zusätzlichenHardwareaufwand erfolgen kann. Das Sy-stem unterstützt dieses Vorgehen dadurch,dass die I/O – Schnittstellen zum Controller –Betriebssystem als Targetlink – Blöcke ver-fügbar sind und dass eine Simulation sowohlmit Gleitkomma- als auch mit Festkomma-arithmetik möglich ist.

Ein HiL – System wird zur Modell-Verifikationin dem Fall zum Einsatz kommen, wenn sicheinzelne Komponenten der Regelstrecke

nicht oder nur mit sehr großem Aufwand in derSimulationsumgebung abbilden lassen,gleichzeitig jedoch ein Test im Gesamtsystemz. B. auf Grund zu großen Applikationsauf-wandes nicht bzw. noch nicht wirtschaftlich ist.Von Fall zu Fall ist auch hier zu entscheiden,welche Teile der Regelstrecke physikalischvorliegen müssen und welche als Software-modell abgebildet werden können.

Aus Sicht des Steuergerätes ist kein Unter-schied festzustellen, ob es die reale oder inEchtzeit simulierte Regelstrecke „bedient“. Be-merkenswert ist, dass in diesem simulationsba-sierten Entwicklungsprozess auch das für denHiL-Simulator benötigte Streckenmodell schonweitgehend aus dem Schritt Systemspezifikati-on vorhanden ist. Im beschriebenen Projektwurden die wichtigsten Teilsysteme an einemPrüfstand installiert (EZA gegen nicht rotierendeKupplung, PROST – Steuergerät und überge-ordnetes EKM - Steuergerät).

Die Systemverifikation bezieht sich auf denGesamtsystementwurf. Wird das Verhaltender Kupplung im Fahrzeug festgelegt, somuss auch die Validierung im Fahrzeug oderin einer fahrzeugadäquaten Systemumge-bung enden. Auch im vorliegenden Fall wurdedie abschließende Verifizierung im Fahrzeugvorgenommen.

Damit wurden im vorliegenden Projekt alleStationen des V-Modells durchlaufen.

Zudem wurden Messdaten rückgekoppelt, diein der Modell- und Systemverifizierung sowieim Endtest gewonnen wurden.

Ergebnisse, Teil I:Die ReglerstrukturDie Spezifikation des Reglers bestand zunächstaus ersten groben Blöcken, die dann durch Ver-feinerung und Parametrierung mit „Leben“ ge-füllt wurden. Die Blöcke lassen sich direkt mit ih-ren Verknüpfungen (Signalwegen) als Grafikausgeben und unterstützen damit eine optimaleSpezifikation und Dokumentation:



� die Soll- und Istwertberechnung für denRegler

� der Zustandsregler als Kern

� die Vorsteuerung zur Erhöhung der Verstell-dynamik

� die Logik, die unterschiedliche Grundzu-stände unterscheidet (z. B. Normal-, Not-lauf- und Testbetrieb)

� die Nachlauffunktionen, die verschiedeneEin- und Ausschaltprozeduren umfassen

� der Block „Ausgänge setzen“ zur Grenz-wertüberprüfung und Anpassung an dieHardware

� der Block „Messwerte auf CAN“ als Kontroll-funktion während der Erprobungsphase

Eine grafische Darstellung wird automatischerstellt. Die Einbindung an dieser Stellesprengt jedoch den Rahmen.

In dieser grafischen Darstellung sind prinzipi-ell die Eingänge des Reglers links, die Reg-lerausgänge rechts angeordnet. Jeder Blockkann auf weitere Details heruntergebrochenwerden. Der Regler als Gesamtsystem ist wie-derum ein Block im gesamten Offline-Simula-tionsmodell, in dem die restlichen Komponen-ten der Regelstrecke abgebildet sind: Endstu-fe, E-Motor, das Federbandgetriebe und dieKupplung selbst.

Da die Reglerspezifikation letztlich in einemReglermodell endet, das sowohl in der Simula-tion „gegen“ das Modell der Regelstrecke laufenkann, als auch nach Codegenerierung im Steu-ergerät „gegen“ die reale Regelstrecke, handeltes sich um eine ausführbare Spezifikation.

Befindet sich der Regler nach Codegenerie-rung im realen Steuergerät, so greift die ge-nerierte Software auf die gleichen Ein- undAusgangsschnittstellen zu, wie sie im Modellschon dargestellt wurden. Die Schnittstellezur Systemsoftware bildet dabei dann dasAFT Controller Interface (ACI).

Ergebnisse, Teil II: EinsparpotenzialFür die Erstellung des Reglers für den EZAwaren ursprünglich drei Mannmonate für Ent-wurf, Simulation, Codierung und Ersttest vor-gesehen worden. Das Projekt wurde zwei Wo-chen nach Projektstart auf die neue Methodikumgestellt. Insgesamt fielen mit der neuenMethodik ebenso drei Mannmonate an.

Es wurde keine Kontrollgruppe definiert, diedie gleiche Aufgabenstellung mit der konven-tionellen Methodik löste. Es besteht allerdingshinreichende Erfahrung mit der Definition undDurchführung derartiger Projekte, so dass inetwa von dem gleichen Arbeitsaufwand aus-gegangen werden kann.

Allerdings ist einiger Aufwand durch die Ein-arbeitung in die neuen Werkzeuge geflossen.Der erst nach zwei Wochen gefällte Ent-schluss, auf die Methodik zu wechseln, brach-te auch einige Stunden Mehraufwand, da dieSimulationsmodelle noch an die Echtzeitan-forderungen angepasst werden mussten.

Geschätzt wird, dass sich die Entwicklungs-zeit bei eingearbeiteten Mitarbeitern um ca.50% auf 1,5 Mannmonate reduziert. Dies er-gibt zum einen die Analyse der Stunden-schreibung, zum andern zeigt dies die Gegen-rechung: Erfahrungsgemäß fallen für die Co-dierung des Reglers einschließlich Test sowieKonfiguration des Applikationssystems auch1,5 Mannmonate an, ein Aufwand, der bei derneuen Methodik entfällt.

Der mögliche Ratioeffekt beträgt somit gut50% und ergibt sich aus dem Wegfall der Er-stellung des Reglercodes und durch denWegfall des Aufwands zur Konfiguration desApplikationssystems, das in der Testphasezur Feinabstimmung eingesetzt wird.

Es muss erwähnt werden, dass die für eine Se-rienfreigabe notwendigen Validierungsschritte(Funktionsdauerläufe, Codeinspektion usw.) inder Zeitschätzung nicht berücksichtigt wurden.Bei einer solchen Betrachtungsweise würdesich der Ratioeffekt reduzieren.



Sehr wichtig ist, an dieser Stelle festzustellen,dass es sich nicht um eine reine Funktions-darstellung auf einem automotiven Hochlei-stungs-Testsystem handelt.

Das Prototyp-Steuergerät AFT-PROST be-inhaltet einen üblichen, serientauglichen16-bit Mikrocontroller mit Festkommaarithme-tik. Ebenso ist der generierte Code ohne gro-ßen Aufwand auf ein konventionelles Serien-steuergerät übertragbar. Damit ist diese Kon-zeption auf Grund ihrer Seriennähe gegen-über anderen Systemen, die auf Hochlei-stungs-Fließkomma-Prozessoren beruhenund lediglich eine Funktionsdarstellung imPrototyp-Fahrzeug ermöglichen, weit überle-gen.

Antworten auf häufig gestellte Fragen

Woher kommt die Effektivität des Codegenerators?Worauf bezieht sich diese?Die Effektivität bezieht sich auf die Ausführungs-zeit des generierten Codes. Sie beträgt laut Her-stellerangaben ca. 0,9 bis 1,2 im Vergleich mithanderstelltem Code. Dies ist ein hervorragen-der Wert, da bisherige Codegeneratoren Codemit zweieinhalb- bis dreifacher Laufzeit gene-rierten. Selbst im „worst-case“ sind 20% zusätz-liche Laufzeit absolut akzeptabel. Der Speicher-platzbedarf ist zudem ungefähr vergleichbar mithanderstelltem Code.

Diese Angaben wurden im Rahmen diesesProjektes nicht überprüft, hätte dann dochgleichzeitig die gleiche Aufgabe mit erfahre-nen Programmierern gelöst werden müssen.Laufzeiten und Codegröße liegen jedoch imerwarteten Rahmen.

Ursächlich für die Laufzeiteffektivität sind imWesentlichen drei Punkte.

Zum einen ist es die Benutzung von beson-deren Codes des Zielprozessors, die einemC-Programmierer nicht zur Verfügung stehen.

Zum anderen ist im Codegenerator implizitviel Spezialwissen über die effektive Program-mierung des Zielprozessors und der einge-setzten Betriebssystemumgebung vorhan-den, das von einem Codierer erst mühsam er-arbeitet werden muss. Weiterhin wird beisachgerechter Handhabung der Tools bei denVariablen eine Skalierung auf den verwende-ten Wertebereich vorgenommen. Dies ermög-licht den Einsatz von günstigen Multiplikati-ons- und Divisionsoperationen, die ansonsteneinen hohen Zeitbedarf aufweisen. Die Ska-lierung kann durch Angabe des Werteberei-ches oder automatisch erfolgen.

Ist der generierte Codelesbar?Der Code ist lesbar, Variablennamen werdenebenso in veränderter, jedoch lesbarer Formübernommen. Es wird lediglich ein Pre- oderPostfix angehängt, um die jeweilige Daten-struktur mit der übergeordneten Systemstruk-tur in Verbindung zu bringen.

Allerdings hängt diese Frage sicherlich damitzusammen, dass seitens der Entwickler nochein gewisses Misstrauen gegenüber dem ge-nerierten Code vorhanden ist. Auch die vonHochsprachencompilern erzeugten Codeswerden in der Regel nicht mehr einer Über-prüfung durch den Entwickler unterzogen.

Wie gehe ich mit Projekten um, die auf vorhandenen Code zurückgreifen?Die AFT-TDC ist hier im Vergleich mit anderenEntwicklungswerkzeugen besonders vorteil-haft. Es existieren generell drei Quellen(Bild 6):

1. Die Generierung von Code aus den Si-mulink-Modellen wie oben beschrieben.

2. Die zusätzliche Addition von handge-schriebenem Code.

3. Die Integrationsmöglichkeit von vorhan-denem Code aus anderen Projekten.



In allen Fällen lassen sich, wenn die Konven-tionen eingehalten werden, auch die Parame-trierungen für das Applikationssystem, d. h.die Beschreibungsdaten des Steuergerätes,erzeugen.

Wie weit ist der generierte Code serientauglich?

Wie schon zuvor erwähnt ist der Code serien-nah, da er für übliche 16-bit-Mikroprozessorenals Zielsystem generiert wird. Ebenso ist der ein-gesetzte Funktionsträger, das automotive Pro-totyp-Steuergerät AFT-PROST, seriennah. DieErgebnisse sind somit in der anschließendenSerienentwicklung weitgehend übertragbar.

Zusammenfassung und AusblickBild 7 fasst noch einmal die generellen Vor-teile einer geschlossenen Entwicklungskettesowie die spezifischen Vorteile der AFT-TDC

zusammen. Diese Vorteile entspringen denebenso dargestellten typischen Eigenschaften.

Die Entwicklung der EZA-Software war ein Pi-lotprojekt, das die Leistungsfähigkeit der AFT-TDC für den Entwurf und die Erstellung vonSteuergeräte-Seriencode belegt hat. Bei LuKwird zur Zeit angedacht, nach diesem Vorent-wicklungsprojekt auch ein Pilotprojekt in der Se-rienentwicklung durchzuführen.

Weitere Projekte bei AFT sind in der Vergan-genheit erfolgreich abgeschlossen worden.Dazu gehören Projekte für die DaimlerChrys-ler-Forschung, die die Werkzeuge und Metho-den mittlerweile nach entsprechenden Schu-lungen ihrer Mitarbeiter für die Eigenentwick-lung übernommen hat.

Andere Projekte führt AFT als Dienstleisterdurch, wobei die AFT-TDC als Methode undWerkzeug eingesetzt wird, um Projekte in kur-zer Zeit und kosteneffizient durchzuführen.Hierzu gehört auch die Entwicklung einerSteuergerätesoftware für die LuK Fahrzeug-Hydraulik in Bad Homburg.

Bild 6: Vorteil AFT-TDC: Mischen von Code



Bild 7: Zusammenfassung

Zusammenfassung

Generelle Merkmale TDC: Generelle Vorteile TDC:

• Durchgängiger simulationsbasierter Ent-wicklungsprozess vom Entwurf bis zur Im-plementierung einschließlich aller Testphasen (SiL, HiL, Applikation und Er-probung)

• Entwurf auf hoher Ebene (modellbasierte Grafik)

• Ausführbare Spezifikation• Implizite Dokumentation• Expertise Echtzeitsystem z. T. im Codegene-

rator

• Verkürzung der Entwicklungszeiten• Reduzierung möglicher Fehlerquellen• Reduzierung der Kosten• Verlagerung der notwendigen Expertise

zum Systemingenieur• Getestete Zwischenergebnisse in jedem

Entwicklungsschritt

Grundmerkmale TDC-AFT: Spezifische Vorteile TDC-AFT:

• Heterogenes System• Zusammenstellung der besten Komponen-

ten, die sich als Standard bewährt haben: MATLAB®/Simulink®, Code-Generator von dSPACE, MARC I, RAMboX™, Tornado®

• Anpassbarkeit bei sich ändernden Stan-dards

• Integrationsfähigkeit in bereits bestehende Projekte: Kombination bzw. Mischung von handcodiertem und automatisch erstelltem Code

• Anpassbarkeit an individuelle Bedürfnisse durch Zusammenstellung für den Kunden

• Seriennaher Code

Der vorliegende Band7. LuK Kolloquium 2002ist nur für den persönlichen Gebrauch bestimmt!

Herausgeber: LuK GmbH & Co. - schaeffler.com · 19 Codegenerierung contra Manufaktur. 228. LuK...

Documents

Transcript of Herausgeber: LuK GmbH & Co. - schaeffler.com · 19 Codegenerierung contra Manufaktur. 228. LuK...