Lade Inhalt...

Entwurf und Entwicklung einer universellen und übertragbaren Kalibriermethodik am Beispiel einer Verbrennungsmotorsteuerung

Bachelorarbeit 2013 71 Seiten

Ingenieurwissenschaften - Fahrzeugtechnik

Leseprobe

Inhaltsverzeichnis

1 EINLEITUNG

2 STAND DER TECHNIK
2.1 Rapid-Control-Prototyping
2.2 Entwicklungsprozess zur Seriencodegenerierung
2.2.1 Software in the Loop
2.2.2 Hardware in the Loop
2.3 RCP-Steuergerät
2.4 Motorsteuergerät
2.4.1 Seriensteuergerät
2.4.2 Datenverarbeitung
2.4.2.1 Eingangssignale
2.4.2.2 Ausgangssignale
2.4.2.3 Signalverarbeitung
2.5 Applikationssoftware
2.5.1 dSPACE ControlDesk
2.5.2 ETAS INCA
2.6 Applikationsrichtlinien
2.6.1 ASAM AE MCD 1MC
2.6.2 ASAM AE MCD 2
2.6.3 ASAM AE MCD 3

3 REALISIERUNG
3.1 Ablauf
3.2 Kalibriermethodik
3.3 Automatisierte Datenportierung

4 MESSAUFBAU
4.1 Anbindung des Motors an die Wirbelwasserbremse
4.1.1 Auslegung Verbindungswelle
4.2 Fertigung Kabelbaum RCP-System
4.3 Fertigung Kabelbaum VeRa 3.0
4.4 Prüfstandsmotor

5 ERGEBNIS
5.1 Inbetriebnahme RCP-System
5.1.1 Installation RCP-System
5.1.2 Applikation RCP-System
5.2 Inbetriebnahme VeRa 3.0
5.2.1 Installation VeRa 3.0
5.2.2 Applikation VeRa 3.0
5.3 Validierung

6 ZUSAMMENFASSUNG UND AUSBLICK

7 LITERATURVERZEICHNIS

8 ANHANG

A.1 Konstruktionszeichnungen

A.2 Quellcode Application Data Transformer

A.3 Resonanzberechnung

Abbildungsverzeichnis

Abbildung 2.1: V-Modell

Abbildung 2.2: dSpace MicroAutoBox

Abbildung 2.3: VEMAC VeRa 3.0

Abbildung 2.4: Signalverarbeitung im Steuergerät

Abbildung 2.5: Speichertechnologien

Abbildung 2.6: ASAM Schnittstellen

Abbildung 2.7: Strukturen einer A2L-Beschreibung

Abbildung 3.1: Ablauf Kalibrierung

Abbildung 3.2: Prinzip Datenübertragung

Abbildung 3.3: Auszug einer XML-Datei

Abbildung 3.4: Auszug einer .m-Datei

Abbildung 3.5: Aufbau VeraData.xml

Abbildung 3.6: Data-Dictionary XML-Form

Abbildung 3.7: Übertragungsprogramm

Abbildung 3.8: Einfügen der Dateien

Abbildung 3.9: Meldungen ADT

Abbildung 3.10: VeraData laden

Abbildung 4.1: Prinzip Zweimassenschwinger

Abbildung 4.2: Prinzipskizze Verbindungswelle

Abbildung 4.3: Prinzipskizze RCP-Kabelbaum

Abbildung 4.4: Prinzipskizze VeRa-Kabelbaum

Abbildung 4.5: Deutz TCD 4.1 L4

Abbildung 4.6: Deutz Common Rail System

Abbildung 5.1: Kurbelwellenrad im oberen Totpunkt

Abbildung 5.2: Einspritzdauerkennfeld

Abbildung 5.3: Simulink-Modell PID-Regler VCV

Abbildung 5.4: Änderung Preloadfaktor

Abbildung 5.5: Änderung I-Anteil VCV Regler

Abbildung 5.6: Änderung I-Anteil Leerlaufregelung

Abbildung 5.7: Änderung P-Anteil Leerlaufregelung

Abbildung 5.8: Simulink-Modell Temperaturkorrektur

Abbildung 5.9: Temperaturkorrektur-Kennlinie

Abbildung 5.10: Validierung d Datenübertragung

Tabellenverzeichnis

Tabelle 4.1: Leistungsdaten Deutz TCD 4.1 L4

Tabelle 5.1: Teglereinstellungen nach Ziegler und Nichols

Abkürzungen

Abbildung in dieser Leseprobe nicht enthalten

Symbole

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Bedingt durch den Wettbewerbsdruck in der Automobilindustrie und den daraus resultierenden Forderungen nach einer Reduktion von Entwicklungskosten und Entwicklungszeiten ist es zunehmend wichtiger, den Applikationsprozess effizienter zu gestalten. Ein Aspekt in diesem Zusammenhang ist das Bestreben, die Applikationszeiten zu verringern. Daher wird versucht möglichst viele Applikationsaufgaben auf den Prüfstand oder in frühere Entwicklungsphasen zu verlagern. Eine Möglichkeit schon in frühen Phasen der Applikation Regelungskonzepte zu entwickeln bietet das Rapid-Control-Prototyping.

Rapid-Control-Prototyping (RCP) hat heute einen festen Platz in der Entwicklung automobiler Steuerungssysteme. Dabei steht vor allem die modellbasierte Softwareentwicklung im Vordergrund, die es ermöglicht bereits in frühen Phasen der Entwicklung mit Hilfe von Simulation Regelungskonzepte zu entwickeln und an frühen Funktionsmustern in der Realität zu testen.

Dennoch gibt es häufig einen Bruch in der Entwicklung, wenn Modelle aus der RCPPhase in die Serie übernommen werden, da hier in der Regel andere Codegeneratoren verwendet werden. Damit einher geht häufig auch ein Bruch in der Kalibriermethodik. Während bei typischen RCP-Systemen die Kalibrierung durch proprietäre Werkzeuge mit proprietären Protokollen (z.B. dSPACE ControlDesk) erfolgt, werden in der Kalibrierung von Seriensteuergeräten Werkzeuge eingesetzt, die mit standardisierten Schnittstellen arbeiten (z.B. ETAS INCA, VECTOR CANAPE, ATI Vision).

Inhalt dieser Bachelorarbeit ist es, eine Methodik zu entwerfen, die einen nahtlosen Übergang der Kalibrierung von der RCP-Phase in die Seriensteuergerätentwicklung ermöglicht. Die Kalibrierdaten werden dabei durch automatisierte Skripte vom RCPauf das Seriensteuergerät übertragen. Die Methodik wird am Beispiel einer Dieselmotorsteuerung am Prüfstand validiert. Als typisches RCP-System wird dSPACE MicroAutoBox und als typisches Kleinseriensteuergerät VeRa 3.0 der Fa. VEMAC verwendet.

2 Stand der Technik

2.1 Rapid-Control-Prototyping

In den letzten Jahrzehnten wurden zahlreiche technische Systeme aus den klassischen Ingenieurdisziplinen (mechanische, chemische, thermische, thermodynamische Prozesse) um eine elektronische Komponente erweitert. Das dadurch entstandene Fachgebiet wird mit Mechatronik bezeichnet, einem Kunstwort aus den drei wichtigsten Disziplinen für dieses Gebiet: Mechanik, Elektronik und Informatik. /3/

Diese Entwicklung führte zu neuen Entwurfsmethoden im Bereich der Regelungsund Steuerungstechnik. Mit diesen sollen sowohl der Interdisziplinarität als auch der Forderung nach ganzheitlichen Entwürfen Rechnung getragen werden. Eine dieser Methoden ist das Rapid-Control-Prototyping. /1/

Rapid-Control-Prototyping (RCP) bezeichnet eine rechnergestützte Entwurfsmethode zur Regelungs- und Steuerungsentwicklung.

Rapid Prototyping fasst den Entwurf und die Realisierung von Regelungen zusammen und generiert unter Einsatz sehr leistungsfähiger Hardware/SoftwareUmgebungen einen geschlossenen Entwicklungsprozess. /1/

So können mittels RCP Entwürfe für regelungs- und steuerungstechnische Funktionen schon in frühen Phasen der Entwicklung effizient an der realen Regelstrecke getestet und verifiziert werden. /8/

Im Vergleich zu normalen Steuergeräten haben RCP-Steuergeräte eine hohe Rechen- und Speicherleistung. Dadurch müssen viele Anforderungen, wie Festpunktarithmetik oder die begrenzten Hardware-Ressourcen bei der Applikation nicht berücksichtigt werden, wodurch Änderungen der Software-Funktionen einfacher und vorallem schneller umzusetzen sind. /12/

Bei der Steuergeräteneuentwicklung kann die Steuergerätesoftware auf einen Echtzeitrechner portiert werden, der im sogenannten Fullpass, die gesamte Funktionalität des zu entwickelnden Steuergerätes übernimmt. Auf diese Weise ist es möglich erste Untersuchungen am realen Prozess durchzuführen ohne durch die Rechenleistung und Speicherkapazität des Originalsteuergerätes eingeschränkt zu sein.

Das RCP-System kann auch im Bypass betrieben werden. Diese Methode wird für die Weiterentwicklung bereits bestehender Steuergeräte verwendet. Dabei werden nur die neu zu entwickelnden Teilfunktionen des vorhandenen Steuergerätes auf das RCP-System ausgelagert und parallel berechnet. /9/

2.2 Entwicklungsprozess zur Seriencodegenerierung

Im Entwicklungsprozess zur Seriencodegenerierung ist das sogenannte V-Modell (Abb.2.1) weit verbreitet. Dabei wird auf einem hohen Abstraktionsniveau, wie beispielsweise dem Regler-Entwurf, auf der linken Seite des V-Modells gestartet und dieser Zweig mit immer höherem Detaillierungsgrad nach unten verfolgt (Top-Down). Nach der Funktionsentwicklung folgt an der unteren Spitze die Generierung des Seriencodes. Damit ist die höchste Detaillierung erreicht. Nun folgt der Aufstieg auf dem rechten Zweig des V-Modells, bei dem der Detaillierungsgrad wieder abnimmt (Bottom-Up). Hier werden Tests durchgeführt, die von den einzelnen Komponenten (Hardware-in-the-Loop), über Module aus mehreren Komponenten bis hin zur Inbetriebnahme am Gesamtprozess, bzw. zur Applikation und Kalibrierung führen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung2.1 V-Modell

Mittlerweile stehen viele Softwarepakete zur Verfügung, die den jeweiligen Entwicklungsschritt unterstützen. Problematisch bei diesem Ansatz sind unter anderem die Schnittstellen zwischen den verschiedenen Werkzeugen für die einzelnen Schritte. So ist es nicht immer gewährleistet, dass eine Modellierung, die mit einem branchenüblichen Modellierungswerkzeug entworfen wurde, unmittelbar in eine Umgebung übernommen werden kann, die die Systemanalyse oder den Regelungs- und Steuerungsentwurf unterstützt. /1/

In den Jahren 2003 bis 2005 wurde der Nachfolger des V-Modells, das V-Modell-XT entwickelt. Die Weiterentwicklung beinhaltet als wesentlichste Veränderung das Konzept des Tailorings, mit dem das Modell an unterschiedliche Projekte angepasst werden kann. Somit unterstützt das V-Modell-XT z.B. auch drei verschiedene Vorgehensweisen: Inkrementell, komponentenbasiert und agil. /12/

2.2.1 Software in the Loop

Unter Software-in-the-Loop (SiL) wird die prototypische Implementierung des Regelalgorithmus‘ auf einer Echtzeit-Zielplattform verstanden. Echtzeit bedeutet nach Definition nicht, dass das System verzugsfrei antworten muss. Vielmehr muss es in einer definierten Zeit auf ein bestimmtes Ereignis reagieren. /3/

Bei einer SiL-Simulation wird die Zielplattform i.d.R. mit dem realen Prozess verbunden. Ziel ist es, die Robustheit und Anwendbarkeit der verwendeten Algorithmen am Prozess zu untersuchen und das in der Systemsimulation erzielte Verhalten der Regelung zu verifizieren. Die Zielplattform wird mit sehr leistungsfähigen Komponenten bestückt, so dass in Bezug auf Rechenleistung, Speicherkapazität, Auflösung der Messaufnehmer, usw. keine oder nur geringe Einschränkungen für den verwendeten Algorithmus entstehen. /1/

2.2.2 Hardware in the Loop

Unter Hardware-in-the-Loop (HiL) wird die Untersuchung eines Regelungs- bzw. Steuerungs-Prototypen auf der Zielhardware verstanden. Dieser ist einem simulierten Prozess, der auf einem Echtzeit-Simulationsrechner implementiert ist, verbunden. Ziel ist es, den Prototypen auf seine vollständige Funktionsfähigkeit, Robustheit und Sicherheit hin zu untersuchen. Anhand von automatisierbaren Tests ist dies leichter und risikofreier mit einer Prozesssimulation durchführbar.

In der Automobilindustrie wird von HiL gesprochen, wenn ein Motorsteuergerät durch ein entsprechendes Hard-/Software-Paket auf Funktionstüchtigkeit überprüft wird. /1/

2.3 RCP-Steuergerät

Ein Beispiel für ein RCP Steuergerät ist die dSPACE MicroAutoBox (Abb.2.2). Sie ist ein Echtzeitsystem für schnelles Funktionsprototyping für Fullpass- und Bypassszenarien. Das System arbeitet, wie ein Seriensteuergerät, ohne Eingriffe des Benutzers. Die MicroAutoBox kann für zahlreiche RCP-Anwendungen eingesetzt werden:

- Fahrwerkssteuerung
- Antriebsstrang
- Karosseriesteuerung
- X-by-Wire Anwendungen
- Elektrische Antriebsregelung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2 dSPACE MicroAutoBox /2/

2.4 Motorsteuergerät

Das Steuergerät (Electrical Control Unit: ECU) stellt die zentrale Intelligenz der Motorsteuerung dar. Es hat die Aufgabe, den Antriebsstrang so zu betreiben, dass das vom Fahrer angeforderte Moment optimal an die Antriebsräder abgegeben wird. Die Möglichkeiten zur Steuerung und Regelung der elektronischen Systeme im Kraftfahrzeug nahmen mit der Digitaltechnik erheblich zu. Viele Einflussgrößen können gleichzeitig mit einbezogen werden, sodass sich die Systeme bestmöglich betreiben lassen. Das Steuergerät empfängt die elektronischen Signale der Sensoren, wertet sie aus und berechnet die Ansteuersignale für die Stellglieder (Aktoren). Das Steuerungsprogramm, die sog. Software, ist in einem Datenspeicher abgelegt. Die Ausführung des Programms übernimmt ein Mikrocontroller. /4/ /5/

2.4.1 Seriensteuergerät

Ein typisches Seriensteuergerät für Prototypen und Kleinstserien stellt die VEMAC VeRa 3.0 dar( Abb.2.3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: VEMAC VeRa 3.0 /7/

Das VeRa 3.0 Steuergerät enthält eine leistungs- und serienfähige CPU MPC 5614F mit einem 264Mhz getakteten Mikroprozessor. Durch ein Field Programmable Gate Array (FPGA) und das separate CPU und I/O-Board ist es einfach erweiterbar. Redundante Recheneinheiten, echtzeitfähige Busse sowie die Unterstützung von TargetLink und dem dSPACE Referenzworkflow machen das Steuergerät auch für sicherheitskritische Anwendungen einsetzbar. Das VEMAC Steuergerät ist kompatibel zu allen Applikations- und Kalibrierwerkzeugen und somit individuell anpassbar. /7/

Der Unterschied zwischen einem RCP-Steuergerät und einem Seriensteuergerät liegt vorallem in der größeren Rechen- und Speicherleistung des RCP-Systems. Bei Seriensteuergeräten liegt der Fokus meist auf niedrigen Kosten, die zum Teil zu Lasten der Performance durchgesetzt werden.

2.4.2 Datenverarbeitung

2.4.2.1 Eingangssignale

Sensoren und Aktoren bilden die Schnittstelle zwischen dem Fahrzeug und dem Steuergerät. Die elektrischen Signale der Sensoren werden dem Steuergerät über den Kabelbaum und den Anschlussstecker zugeführt. Diese Signale können analog, digital oder pulsförmig sein.

Analoge Eingangssignale:

Analoge Eingangssignale können jeden beliebigen Spannungswert innerhalb eines bestimmten Bereichs annehmen. Beispiele für analoge Messwerte sind die angesaugte Luftmasse, die Batteriespannung, der Raildruck, sowie die Kühlwasserund Ansauglufttemperatur. Sie werden von einem Analog-Digital-Wandler (ADWandler) im Mikrocontroller des Steuergeräts in digitale Werte umgeformt, welche die zentrale Recheneinheit des Mikrocontrollers verarbeiten kann. Die maximale Auflösung dieser Analogsignale beträgt 5mV. /4/

Digitale Eingangssignale:

Digitale Eingangssignale können vom Mikrocontroller direkt verarbeitet werden. Sie besitzen nur die beiden Zustände High (logisch 1) und Low (logisch 0). Beispiele für digitale Eingangssignale sind Schaltsignale (Ein/Aus) oder digitale Sensorsignale wie Drehzahlimpulse eines Hall- oder Feldplattensensors. /3/

Pulsförmige Eingangssignale:

Pulsförmige Eingangssignale werden von induktiven Sensoren erzeugt. Diese werden meist für Drehzahlinformation und Bezugsmarken verwendet. Das Steuergerät bereitet diese Signale in einem eigenen Schaltungsteil auf. Ein Filter unterdrückt Störimpulse, wandelt die pulsförmigen Signale in digitale Rechtecksignale um und sendet diese an den Mikrocontroller. /5/

2.4.2.2 Ausgangssignale

Der Mikrocontroller steuert mittels Schalt- und PWM-Signalen Endstufen an, die üblicherweise genügend Leistung für den direkten Anschluss der Aktoren liefern.

Schaltsignale

Mit den Schaltsignalen können Stellglieder ein- und ausgeschaltet werden. (z.B. Motorlüfter).

PWM-Signale

Digitale Ausgangssignale können als PWM Signale ausgegeben werden. Diese PulsWeiten-Modulierten Signale sind Rechtecksignale mit konstanter Frequenz und variabler Einschaltzeit. Mit diesen Signalen können verschiedenen Stellglieder in beliebe Arbeitsstellungen gebracht werden (z.B. Abgasrückführventil, Ladedrucksteller, Kraftstoffzumesseinheit). /3/

2.4.2.3 Signalverarbeitung

Das Steuergerät gliedert sich in die Rechen- und Schaltzentrale für die Funktionsabläufe der Motorsteuerung. Im Mikrocontroller laufen die Steuer- und Regelalgorithmen ab. Die Eingangssignale, die von den Sensoren und den Schnittstellen zu anderen Systemen (z.B. CAN-Bus) kommen, dienen dem Steuergerät als Eingangsgrößen, die mit Hilfe des Steuergeräteprogramms in die Ausgangssignale zur Ansteuerung der Aktoren berechnet werden. /4/

Mikrocontroller:

Der Mikrocontroller ist das zentrale Bauelement eines Steuergeräts (Abb.2.4). Er steuert dessen Funktionsablauf. Im Mikrocontroller sind außer der CPU (Central Processing Unit) noch Eingangs- und Ausgangskanäle, Timereinheiten, RAM, ROM, serielle Schnittstellen und weitere periphere Baugruppen auf einem Mikrochip integriert. Ein Quarz taktet den Mikrocontroller. /5/

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4:Signalverarbeitung im Steuergerät /5/ Programm- und Datenspeicher:

Für die Berechnungen benötigt der Mikrocontroller ein Programm, die sogenannte Software, die in Form von binären Zahlenwerten in einem Programmspeicher abgelegt ist. Die CPU liest diese Werte aus, interpretiert sie als Befehle und führt diese der Reihe nach aus. Die Software ist in einem Festwertspeicher (ROM, EPROM oder Flash-EPROM) abgelegt. Dieser Speicher beinhaltet zudem variantenspezifische Daten wie Kennwerte, Kennlinien und Kennfelder. Diese Daten sind unveränderlich und können auch im Fahrzeugbetrieb nicht verändert werden. Eine Ausnahme davon bildet das Laden einer neuen Software-Version im Rahmen eines Software-Updates durch Flash-Programmierung. /4/ /6/

Speichertechnologien:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Speichertechnologien /6/

Die Halbleiterspeicher teilen sich in flüchtige und nichtflüchtige Speicher auf.

Flüchtige Speicher (Schreib-Lese-Speicher), wie das RAM (Random Access Memory), verlieren bei der Trennung des Steuergeräts von der Versorgungsspannung ihren gesamten Datenbestand. Für komplexe Anwendungen reicht die Speicherkapazität nicht aus. In diesem Schreib-Lese-Speicher werden veränderliche Daten, wie z.B. Rechen-, Signal- und Adaptionswerte gespeichert.

Nichtflüchtiger Speicher (Lese-Speicher) kommen als Programm- oder Datenspeicher für Parametersätze in Frage. Das ROM (Read Only Memory) kann nur gelesen, aber nicht beschrieben werden. Das EPROM (Erasable Programmable ROM) kann durch das Bestrahlen mit UV-Licht gelöscht und mit einem Programmiergerät wieder neu beschrieben werden. Flash-EPROM sind auf elektrischem Wege löschbar, wodurch das Steuergerät über eine serielle Schnittstelle umprogrammiert werden kann. Auf dem ROM sind z.B. die Programmierroutinen für die Flash-Programmierung abgelegt. /3//4/

Daten, die auch bei abgeklemmter Batterie nicht verloren gehen dürfen (z.B. wichtige Adaptionswerte, Codes für die Wegfahrsperre) werden im EEPROM dauerhaft gespeichert. Das EEPROM ist ein elektrisch löschbares EPROM, bei dem im Gegensatz zum Flash-EPROM jede Speicherzelle einzeln gelöscht werden kann. Somit ist das EEPROM als nicht flüchtiger Schreib-Lese-Speicher einsetzbar. /4/

2.5 Applikationssoftware

Im Entwicklungsprozess moderner Steuergeräte stellt die Bedatung der Steuergeräte-Software einen wesentlichen Meilenstein dar. Dieser Vorgang wird als Steuergeräte-Applikation oder -Kalibrierung bezeichnet und erfolgt in der Regel erst relativ spät im Entwicklungsprozess, nachdem der Motor bereits als Prototyp zur Verfügung steht. /8/

Neben den eigentlichen Software-Funktionen beeinflusst die Einstellung der jeweiligen Steuer- und Regelparameter (Kennwerte, Kennlinien und Kennfelder) maßgeblich das Gesamtverhalten eines Fahrzeugs. Ziel der Steuergeräte-Applikation ist es, die Software-Funktionen durch Abstimmung dieser Kenngrößen an Motoroder Fahrzeugvarianten anzupassen, so dass das Gesamtverhalten die Lastenheftvorgaben erfüllt.

In der ersten Phase der Applikation erfolgt die Grundbedatung des Steuergeräts. Um einen sicheren und zuverlässigen Betrieb des Motors zu gewährleisten, wird diese sogenannte stationäre Grundabstimmung am Motorprüfstand durchgeführt. Da die Ergebnisse aus der stationären Grundabstimmung zwar häufig hinsichtlich bestimmter Kriterien optimiert sind, aber bezüglich Fahrbarkeit meist noch große Defizite aufweisen, folgt in der zweiten Phase eine Anpassung der Grundbedatung, wodurch zwangsläufig das zuvor gefundene stationäre Optimum verlassen wird. In weiteren Phasen sind das Emissions- und Verbrauchsverhalten des Motors sowie diagnoserelevante Funktionen, z.B. die On-Board-Diagnose (OBD), anzupassen. Abschließend erfolgt die Validierung der Abstimmung im Flottenversuch. /8/

Die Applikation erfolgt mit Hilfe spezifischer Softwaretools, wie z.B. dSPACE ControlDesk (RCP) und ETAS INCA (Serie). Durch diese Mess- und Applikationsprogramme ist es möglich Parameter der Motorsteuerung zu verändern und das Verhalten des Motors im Betrieb aufzuzeichnen.

2.5.1 dSPACE ControlDesk

Das Applikationstool ControlDesk wurde von der Firma dSPACE entwickelt. ControlDesk ist eine Universelle Experimentiersoftware für die Entwicklung elektronischer Steuergeräte. /2/

- Die Aufgaben, die diese Software erfüllt sind:
- Rapid Control Prototyping
- HIL-Simulation
- Steuergeräte-Messung, -Applikation und -Diagnose
- Zugriff auf Bussysteme (LIN, CAN, FlexRay)
- Virtual ECU Testing

ControlDesk vereint Funktionalitäten, die bisher von mehreren Spezialtools abgedeckt werden mussten. So bietet die Software Zugriff auf Simulationsplattformen und abgeschlossene Bussysteme und führt Mess-, Applikations- und Diagnoseaufgaben auf Steuergeräten aus.

2.5.2 ETAS INCA

Das Integrated Calibration and Aquisition System, kurz INCA ist der Industriestandart für Mess- und Applikationssysteme in der Automobilindustrie.

INCA wird für die Entwicklung und beim Test von Steuergeräten, sowie bei der Validierung und Kalibrierung von elektronisch gesteuerten Systemen im Fahrzeug, am Prüfstand oder in einer virtuellen Umgebung am PC eingesetzt. /10/

Mit Hilfe von INCA wird eine Verbindung zwischen Steuergerät und Computer hergestellt, die es ermöglicht sämtliche Signale des Motorsteuergerätes zu erfassen und Kennwerte, Kennlinien und Kennfelder zu verändern.

Der Betrieb von INCA kann sowohl online, als auch offline erfolgen. Online bedeutet in diesem Zusammenhang, dass die Werte während des Motorbetriebs verstellt werden können und somit die Auswirkungen der Änderung der Applikationsdaten direkt erkennbar sind. Beim Offlinebetrieb werden die Daten ohne angeschlossenes Steuergerät verändert und dann auf das Steuergerät geladen.

2.6 Applikationsrichtlinien

In dieser Arbeit wird als Richtlinie für den Applikationsprozess die ASAM AE MCD Vorgabe verwendet.

ASAM ist die Abkürzung für Association for Standardization of Automation and Measuring Systems (früher ASAP). Sie ist eine Initiative europäischer Automobilhersteller und ihrer Zulieferer, die es sich als Ziel gesetzt hat den Applikationsprozess und den Test elektronischer Systeme in der Entwicklungs- und Fertigungsphase zu vereinfachen. MCD steht dabei für die drei Hauptaufgaben der Applikation: Measure, Calibrate und Diagnostic. /11/

ASAM MCD ist eine Zwischenschicht, die eine Kopplung zwischen den Steuergeräten auf der untersten Ebene und den übergeordneten Test- und Diagnoseanwendungen herstellt. Eine wesentliche Rolle bei ASAM MCD spielt die einheitliche, herstellerunabhängige Beschreibung der Steuergeräteeigenschaften in einer Datenbank mit standardisiertem Datenaustauschformat. In dieser Datenbank sind Informationen über die im Steuergerät verfügbaren Funktionen und Variablen, z.B. deren Speicheradresse oder die Parameter der Busschnittstelle.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6 ASAM Schnittstellen /11/

Insgesamt definiert ASAM-MCD drei Schnittstellen:

- ASAM 3: Schnittstelle zu den übergeordneten Test- und Diagnoseanwendungen
- ASAM 2: Schnittstelle zur Steuergeräteschnittstelle
- ASAM 1: Schnittstelle zu den Steuergeräten

2.6.1 ASAM AE MCD 1MC

Die unterste ASAM Schicht, die für Mess- und Kalibrieraufgaben verwendet wird, gliedert sich nochmals in zwei Teile. Der erste Teil (1a) definiert die Busprotokolle CCP und XCP, der zweite Teil (1b) ist das Interface zur übergeordneten Schicht.

Durch die Verwendung von CCP und XCP, das eine Weiterentwicklung von CCP ist, ist es für das Applikationssystem möglich mehrere Verbindungen zu unterschiedlichen Steuergeräten gleichzeitig aufzubauen, während ein einzelnes Steuergerät nur genau eine Verbindung unterstützt.

Beim CAN Calibration Protocol (CCP) wird die gesamte Kommunikation über zwei CAN-Botschaften (Command Receive Object CRO und Data Transmission Object DTO) mit jeweils eigenem CAN-Identifier ausgeführt.

Eine Befehlsbotschaft (CRO) hat ein festes Format und ist immer 8Byte groß. Somit umfasst sie die maximal mögliche Nutzdatenlänge einer CAN Botschaft.

Die Datenbotschaft (DTO) umfasst zwei Formate. Das erste wird für direkte Antworten auf einen Befehl verwendet, das zweite wird für die Messdatenübertragung benutzt.

Das Extended Calibration Protocol (XCP) verwendet dasselbe verbindungsorientierte Request-Response-Kommunikationsschema wie CCP. Das Botschaftsformat und die Befehlscodes sind jedoch unterschiedlich, so dass XCP-Implementierungen nicht kompatibel zu CCP sind. Zur Kommunikation mit dem Steuergerät benutzt XCP zwei fest vorgegebene CAN-Identifier. Einer dient zum Empfangen von Botschaften vom Applikationssystem zum Steuergerät, einer zum Senden von Botschaften vom Steuergerät zum Applikationssystem. Dadurch ist, im Gegensatz zu CCP, für jedes Steuergerät ein festes Paar von CAN -Identifier notwendig. /11/

Wie bei CCP gliedern sich die Botschaften grob in zwei Gruppen. Die Command Transfer Objekte (CTO) senden Befehle vom Applikationssystem an das Steuergerät sowie Antworten vom Steuergerät an das Applikationssystem. Data Transfer Objekte (DTO) sind Datenbotschaften für Messdaten vom Steuergerät zum Applikationssystem.

Der große Vorteil des XCP ist die Zulässigkeit im FlexRay-Kommunikationszyklus. /11/

Um die darüberliegenden Schichten des Applikationssystems vom darunterliegenden Treiber für das Busprotokoll zu entkoppeln, wird eine Zwischenschicht mit standardisierten Funktionen eingesetzt Diese Zwischenschicht initialisiert Messvorgänge, liest Messwerte, greift bei einem Kalibriervorgang auf die Applikationsparameter des Steuergerätes zu und setzt das Steuergerät zurück. Die Mehrzahl der Parameter, z.B. die Speicheradressen, auf die im Steuergerät zugegriffen werden soll oder die Größen und das Datenformat der zugehörigen Variablen erhält der ASAM MCD 1-Treiber aus einer ASAP2 Konfigurationsdatei. /11/

2.6.2 ASAM AE MCD 2

In der ASAM MCD 2, oder A2L-Datei, sind die Beschreibungen, welche internen Größen des Steuergerätes messbar und welche Parameter veränderbar sind, hinterlegt. Die Grundstruktur einer A2L Beschreibung ist in der folgenden Abbildung dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7 Struktur einer A2L Beschreibung /11/

Der Abschnitt MOD_PAR enthält allgemeine Informationen über das Steuergerät wie z.B. den Hersteller.

[...]

Details

Seiten
71
Jahr
2013
ISBN (eBook)
9783656972174
ISBN (Buch)
9783656972181
Dateigröße
2 MB
Sprache
Deutsch
Katalognummer
v300141
Institution / Hochschule
Rheinisch-Westfälische Technische Hochschule Aachen – VKA
Note
1,0
Schlagworte
Rapid Control Prototyping Applikation Übertragungsprogramm für Applikationsdaten MATLAB Verbrennungsmotorsteuerung MicroAutoBox VERA 3.0 ControlDesk Inca Raildruckregelung Dieselmotorsteuerung Seriensteuergeräteapplikation

Autor

Teilen

Zurück

Titel: Entwurf und Entwicklung einer universellen und übertragbaren Kalibriermethodik am Beispiel einer Verbrennungsmotorsteuerung