Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
DEVICE FOR THE MODEL-BASED DEVELOPMENT OF AN INTERNAL COMBUSTION ENGINE
Document Type and Number:
WIPO Patent Application WO/2010/026086
Kind Code:
A1
Abstract:
The invention relates to a device for the model-based development of an internal combustion engine (2), wherein sub models are assigned to subsystems, and wherein the device has at least one virtual engine test bench (11) for the simulation of the internal combustion engine (2) as well as of an engine test bench (1) including a dynamometric brake (5). In order to reduce the preparatory application requirements for internal combustion engine (2) test processes for engine test benches (1), it is proposed that the real-time capable virtual engine test bench (11) for simulating the real engine test bench (1) including dynamometric brake (5) has at least one dynamics model (16) with a mass inertia model for an internal combustion engine (2) and a dynamometric brake (5).

Inventors:
RAINER ANDREAS (AT)
Application Number:
PCT/EP2009/060971
Publication Date:
March 11, 2010
Filing Date:
August 26, 2009
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
AVL LIST GMBH (AT)
RAINER ANDREAS (AT)
International Classes:
G05B17/02; G01M15/00
Foreign References:
AT9467U22007-10-15
AT8090U22006-01-15
Other References:
HANSELMANN H: "REAL-TIME SIMULATION REPLACES TEST DRIVES", TEST AND MEASUREMENT WORLD, REED BUSINESS INFORMATION, HIGHLANDS RANCH, CO, US, vol. 16, no. 3, 15 February 1996 (1996-02-15), XP000559454, ISSN: 0744-1657
Attorney, Agent or Firm:
BABELUK, Michael (AT)
Download PDF:
Claims:
PATENTANSPRÜCHE

1. Einrichtung zur modellbasierten Entwicklung einer Brennkraftmaschine (2), wobei Teilsystemen Teilmodelle zugeordnet sind, und wobei die Einrichtung zumindest einen virtuellen Motorprüf stand (11) zur Simulation der Brennkraftmaschine (2) sowie eines Motorprüfstandes (1) samt Leistungsbremse (5) aufweist, dadurch gekennzeichnet, dass der echtzeitfähige virtuelle Motorprüfstand (11) zur Simulation des realen Motorprüfstandes (1) samt Leistungsbremse (5) zumindest ein Dynamikmodell (16) mit einem Massenträgheitsmodell für Brennkraftmaschine (2) und Leistungsbremse (5) aufweist.

2. Einrichtung nach Anspruch 1, dadurch gekennzeichnet, dass der virtuelle Motorprüfstand (11) zumindest ein vorzugsweise hybrides Motormodell (12) aufweist, wobei das Motormodell (12) vorzugsweise zumindest ein Saugrohrmodell (13), ein Verbrennungsmodell (14) und/oder ein Emissionsmodell beinhaltet.

3. Einrichtung nach Anspruch 1 oder 2, , dadurch gekennzeichnet, dass das Dynamikmodell (16) in das Motormodell (12) integriert ist.

4. Einrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass virtuelle Motorprüfstand (11) zumindest ein Startermodell (17) aufweist, wobei vorzugsweise das Startermodell (17) in das Dynamikmodell (16) integriert ist.

5. Einrichtung nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der virtuelle Motorprüfstand (11) zur Simulation zumindest eines Motorsteuergerätes (ECU) zumindest ein Motorsteuergerätmodell (18) aufweist, wobei vorzugsweise das Motorsteuergerätmodell (18) in das Motormodell (12) integriert ist.

6. Einrichtung nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass der virtuelle Motorprüfstand (11) zumindest ein Messgerätesimula- tionsmodell (19) aufweist, wobei vorzugsweise das Messgerätsimulations- modell (19) in das Motormodell (12) integriert ist.

7. Einrichtung nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der virtuelle Motorprüfstand (11) zur betriebsparameterbasierten Anpassung des Motormodells (12) an ein reales Motorverhalten zumindest ein Parametrierungsmittel (15) aufweist, wobei vorzugsweise das Parametrie- rungsmittel (15) in das Motormodell (12) integriert ist.

8. Einrichtung nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass zumindest ein Teilmodell ein physikalisches Modell ist.

9. Einrichtung nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass zumindest ein Teilmodell ein datenbasiertes Modell ist.

10. Einrichtung nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass zumindest ein Teilmodell ein hybrides Modell ist.

11. Einrichtung nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass zumindest ein Teilmodell je nach Motortyp modular austauschbar ist.

12. Einrichtung nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Einrichtung zumindest ein Mittel zur vorzugsweise automatischen Veränderung der Motorbetriebsbedingungen aufweist, wobei das Mittel vorzugsweise durch zumindest eine Schnittstelle mit einem Motorprüfstandsystem (3) gebildet ist.

13. Verfahren zur modellbasierten Entwicklung einer Brennkraftmaschine (2), wobei Teilsystemen Teilmodelle zugeordnet werden, dadurch gekennzeichnet, dass die Brennkraftmaschine (2) samt einem Motorprüfstand (1) und Leistungsbremse (5) durch entsprechende Teilmodelle simuliert wird, wobei der Betrieb der Brennkraftmaschine (2) auf einem virtuellen Motorprüfstand (11) durch zumindest ein echtzeitfähiges Motormodell (12), ein Motorsteuergerätmodell (18) und ein Dynamikmodell (16) simuliert wird.

14. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Motorbetriebsbedingungen der simulierten Brennkraftmaschine mittels zumindest eines Motorprüfstandsystems (3) vorzugsweise automatisch verändert werden.

15. Verfahren nach Anspruch 10 oder 11, dadurch gekennzeichnet, dass die Parametrierung und/oder die Software des Motorprüfstandssystems (3), vorzugsweise für einen automatischen Prüflauf an einem realen Motorprüfstand (1), in einer Simulationsumgebung des virtuellen Motorprüfstandes (11) getestet wird.

2009 08 26

Fu/Sc

Description:
55913

Einrichtung zur modellbasierten Entwicklung einer Brennkraftmaschine

Die Erfindung betrifft eine Einrichtung zur modellbasierten Entwicklung einer Brennkraftmaschine, wobei Teilsystemen Teilmodelle zugeordnet sind, und wobei die Einrichtung zumindest einen virtuellen Motorprüf stand zur Simulation der Brennkraftmaschine sowie eines Motorprüfstandes samt Leistungsbremse aufweist.

Zur Parametrierung von Motorsteuergeräten sind in einer frühen Projektphase, der stationären Bedatung, eine erhebliche Anzahl von Messungen auf Motorprüfständen notwendig. Da in modernen Brennkraftmaschinen immer mehr Aktua- toren verbaut werden, erhöht sich auch die Anzahl der Verstellparameter. Damit verbunden steigen die Kombinationsmöglichkeiten und deshalb auch der Kalibrieraufwand exponentiell an. In gleichem Maße steigt die Anzahl der notwendigen Messungen, wodurch neue Applikationswerkzeuge und geänderte Methoden notwendig werden.

Zusätzlich muss sich die Entwicklungszeit verkürzen, um am Markt konkurrenzfähig zu bleiben. Um die kostengünstige Massenproduktion voll ausnutzen zu können, werden wenige Motorenfamilien in verschiedenen Fahrzeugtypen eingesetzt, was den Applikationsaufwand zusätzlich erhöht.

Damit Motorprüfstände voll automatisiert, unbemannt und sicher betrieben werden können, ist ein großer technischer Aufwand notwendig. Ein moderner Motorprüfstand besteht aus zahlreichen Systemen und Programmen, die miteinander über unterschiedliche Schnittstellen kommunizieren. Kritische Messgrößen werden vom P rüfstand System ständig überwacht, um die Gefahr eines Motorschadens möglichst gering zu halten. Um den Motor wirkungsvoll zu schützen, bedarf es intelligenter Routinen, da kritische Betriebspunkte teilweise schon im Voraus berechnet bzw. abgeschätzt werden müssen. In der Praxis stellt sich die Parametrierung von Automatikläufen als sehr schwierig heraus, denn sie hängt wesentlich von der Erfahrung und dem Geschick des Applikationsingenieurs ab. Zusätzlich erschwert wird die Aufgabe durch Flüchtigkeitsfehler und den Umstand, dass in den seltensten Fällen alle Eventualitäten im Voraus bedacht werden können.

So ist es notwendig, dass der automatische Prüflauf nach dem Start vom Ingenieur längere Zeit beobachtet wird und in der Regel mehrere Male abgebrochen und modifiziert werden muss. Da diese Tätigkeiten naturgemäß am Prüfstand durchgeführt werden, ist eine derartige Vorgehensweise mit erheblichen Kosten verbunden und somit unerwünscht. Außerdem sinkt die Akzeptanz, da man in der Zeit der Prüflauferstellung andere, für das Projekt wichtige Tests fahren könnte. Durch die lange Parametrierung verringert sich auch der Zeitgewinn, der durch Automatikläufe im Normalfall erzielt wird.

Die WO 2006/007621 A2 beschreibt ein Verfahren zur Untersuchung des Verhaltens von komplexen Systemen durch Bildung eines Modells, das verschiedene Messgrößen in Abhängigkeit von Eingangsvariablen umfasst. Dabei wird nach Auswahl verschiedener Messpunkte und nach Durchführen von Messungen zur Ermittlung von Messgrößen an einem realen System ein Modell erstellt, das die Abhängigkeit der Messgrößen von den Eingangsvariablen abbildet. Das Modell wird anhand der an den Messpunkten gewonnenen Messwerte des realen Systems kalibriert und zumindest in zwei Teilmodelle unterteilt, wobei ein erstes Teilmodell eine erste Teilmenge der Messgrößen abbildet. Für das erste Teilmodell wird mindestens ein erster Haupteinflussparameter identifiziert und ein optimaler Wert des ersten Haupteinflussparameters in jedem Messpunkt bestimmt. Sodann wird der erste Haupteinflussparameter für alle sinnvollen Konstellationen von Eingangsvariablen zur Kalibrierung des ersten Teilmodells interpoliert. Weiters wird ein weiteres Teilmodell zur Abbildung einer weiteren Teilmenge der Messgrößen in Abhängigkeit der Eingangsvariablen und der zuvor ermittelten ersten Teilmenge der Messgrößen und mindestens ein weiterer Haupteinflussparameter für das weitere Teilmodell identifiziert. Schließlich wird ein optimaler Wert des zweiten Haupteinflussparameters in jedem Messpunkt bestimmt. Dadurch ist es möglich, auch bei einer geringen Anzahl von real ermittelten Daten sinnvolle Modelle zu erstellen, die hohe Prognosequalität aufweisen.

Weiters ist aus der FR 2 788 143 Al ein automatisches Kalibrierverfahren für Steuersoftware bekannt, wobei eine geregelte Brennkraftmaschine samt Umgebung in einer Ausführungsphase simuliert und in einer dieser Ausführungsphase folgenden Analysephase die Resultate durch den Computer analysiert werden.

Die AT 009.467 U2 offenbart eine Vorrichtung zur Simulation einer Entwicklungsanlage für einen Prüfstand für einen Prüfling mit einer realen Automatisierungseinrichtung zum Betrieb des Prüfstandes und mit einer Simulationseinrichtung, wobei der Prüfstand und der Prüfling in der Simulationseinrichtung mittels eines Simulationsdaten erzeugenden Prüfmodells nachgebildet ist und die Automatisierungseinrichtung und die Simulationseinrichtung über die realen Schnittstellen der Entwicklungsanlage verbunden sind und die Automatisierungseinrichtung erzeugte Simulationsdaten verarbeitet. In der Entwicklungsanlage ist eine Anzahl von realen Entwicklungswerkzeugen und in der Simulationseinrichtung sind Entwicklungsdaten erzeugende Gerätemodelle vorgesehen, wobei die Gerätemodelle zumindest teilweise Simulationsdaten aus dem Prüfmodell verarbeiten. Die Entwicklungswerkzeuge sind über reale Schnittstellen mit der Automatisierungsein- richtung und/oder der Simulationseinrichtung verbunden, wobei die Entwicklungswerkzeuge Entwicklungsdaten verarbeiten. Zur Simulation bestimmter Prüf- standshardware, wie zum Beispiel einer Belastungsmaschine, ist in der Simulationseinrichtung ein Hardware-Simulator vorgesehen.

Weiters ist aus der AT 009.536 U2 eine Vorrichtung zum Simulieren einer Prüf- standsumgebung bekannt, wobei die Prüfstandsumgebungshardware als virtueller PC auf einem Simulations-PC implementiert wird, die Systemzeit des virtuellen PCs um einen Faktor, der einem Vielfachen der Zeitbasis des Simulations- PCs entspricht, gedehnt wird und wobei die reale Prüstandssoftware auf dem virtuellen PC unter der verlangsamten Systemzeit betrieben wird.

Aufgabe der Erfindung ist es, den im Vorfeld für Prüfläufe von Brennkraftmaschinen auf Motorprüfständen notwendigen Applikationsaufwand zu vermindern.

Erfindungsgemäß wird dies dadurch erreicht, dass der echtzeitfähige virtuelle Motorprüf stand zur Simulation des realen Motorprüfstandes samt Leistungsbremse zumindest ein Dynamikmodell mit einem Massenträgheitsmodell für Brennkraftmaschine und Leistungsbremse aufweist. Dadurch kann ein Prüf- standsaufbau mit Leistungsbremse simuliert werden. Dabei wird die Brennkraftmaschine samt einem Motorprüfstand durch entsprechende Modelle simuliert, wobei der Betrieb der Brennkraftmaschine auf einem virtuellen Motorprüfstand durch zumindest ein echtzeitfähiges Motormodell, ein Motorsteuergerätmodell und ein Dynamikmodell simuliert wird.

Vorzugsweise ist vorgesehen, dass das Dynamikmodell in das Motormodell integriert ist.

Das Motormodell kann dabei zumindest ein Saugrohrmodell und ein Verbrennungsmodell aufweisen, wobei insbesondere das Motormodell über Betriebsparameter an ein reales Motorverhalten adaptierbar ist. Das Motormodell lässt sich somit über wenige konstruktive Parameter, wie zum Beispiel Hubraum, Zylinderzahl oder dergleichen, an einen neuen Motor anpassen.

Um einen Motorstart realitätsnahe nachzubilden, kann dabei das Dynamikmodell ein Startermodell aufweisen.

Das Motormodell weist zumindest ein Saugrohrmodell und ein Verbrennungsmodell, vorzugsweise auch ein Emissionsmodell, auf.

Um konventionelle Prüfstandssoftware einsetzen zu können, ist es vorteilhaft, wenn zumindest ein Messgerätesimulationsmodell vorgesehen ist. Analog zu einem realen Motorprüfstand können die Motorbetriebsbedingungen des virtuellen Motors automatisch verändert werden, wobei es besonders vorteilhaft ist, wenn die Einrichtung eine Schnittstelle zu einem M otorprüfstand System aufweist.

Die Erfindung wird im Folgenden mittels eines Ausführungsbeispieles anhand der Figuren näher erläutert. Es zeigen schematisch :

Fig. 1 den Aufbau eines realen Motorprüfstandes;

Fig. 2 den Aufbau eines virtuellen Motorprüfstandes; und

Fig. 3 ein Motormodell des virtuellen Motorprüfstandes.

Bei dem in Fig. 1 gezeigten Aufbau eines realen M otorprüfstand es 1 wird eine reale Brennkraftmaschine 2 einer voll automatischen Prüfstandsroutine unterzogen, wobei die Brennkraftmaschine über einen durch ein Motorprüfstandssystems 3 gesteuerten Pedalsimulator 4 in einem vordefinierten Fahrprogramm betrieben wird, und wobei der Pedalsimulator 4 direkt auf das Motorsteuergerät ECU einwirkt. Zur Belastung des Motors ist die Brennkraftmaschine 2 an eine Leistungsbremse 5 gekoppelt. An die Brennkraftmaschine 2 sind weiters zur Abgasmessung eine Abgasmesseinrichtung 6 und zur Verbrauchsmessung eine Verbrauchsmesseinrichtung 7 sowie gegebenenfalls weitere Messsysteme 8 angeschlossen.

Im in Fig. 1 dargestellten Ausführungsbeispiel eines realen Motorprüfstandes 1 beinhaltet als Motorprüfstandssystem 3 ein unter dem Produktnamen EMCON der AVL LIST GMBH bekanntes Regelungsprogramm für die Brennkraftmaschine. Weiters beinhaltet das dargestellten Motorprüfstandsystem 3 eine unter dem Produktnamen PUMA OPEN der AVL LIST GMBH bekannte Prüfstandssystemsoft- ware, welche zur Prüfstandssteuerung, zur Verwaltung der Messgeräte und zur Abspeicherung der Messergebnisse dient. Messkanäle von einfachen Temperatur- und Drucksensoren werden über Analog/Digital-Wandler FFEM (Fast Front End Modules) dem Regelungssystem EMCON eingelesen. Sowohl das Prüfstandssys- tem PUMA OPEN, als auch das Regelungssystem EMCON benötigen ein Echtzeitsystem, um sicherzustellen, dass bestimmte Berechnungen innerhalb einer vordefinierten Maximalzeit abgearbeitet werden.

Eine weitere Aufgabe der Software PUMA OPEN ist die Grenzwertüberwachung. Hier können einzelne Messkanäle mit Warn- und Alarmgrenzen versehen werden, bei deren Auslösung das Prüfstandsystem definierte Prozeduren durchführt. Beim Überschreiten eines Limits kann beispielsweise ein Motorstop oder ein Kaltlauf aktiviert werden. Außerdem ist es möglich, dass erst bei anhaltender Überschreitung nach einer vordefinierten Zeit eine Reaktion ausgelöst wird. Typischerweise werden die Motordrehzahl, die Abgastemperatur und das Blow-By des Motors überwacht, wobei Grenzwerte auch über Kennfelder parametriert werden können. So sind für verschiedene Betriebspunkte unterschiedliche Grenzen möglich.

Um am realen Motorprüfstand 1 automatisiert Vermessungen durchführen zu können, ist ein Parametriersystem 9 notwendig, in dem die gewünschten Prüfläufe parametriert werden können. Während dem Testlauf muss es in der Lage sein, die notwendigen Befehle an das P ruf Standssystem zu übertragen. Ein solches Parametriersystem 9 ist beispielsweise die Software CAMEO der AVL LIST GMBH, die aber auch gleichzeitig ein modular aufgebautes Optimierungswerkzeug für die computergestützte Abstimmung und Optimierung von Motorsteuerungen darstellt. Als erste Funktion vom CAMEO-Arbeitsablauf können beliebige Kennfelder, Kennlinien und Festwerte aus dem Motorsteuerungsgerät ECU geladen und angezeigt werden. Anschließend kann der Benutzer zur Optimierung dieser Daten automatisierte Testläufe erstellen, wobei neben Rastervermessungen auch statistische DoE-Methoden (Design of Experiment) zur Verfügung stehen. Durch DoE-Methoden kann die Zahl der notwendigen Variationen bei gleicher Aussagekraft stark gesenkt werden. Dabei werden Betriebspunkte, deren Ergebnisse aufgrund benachbarter Punkte gut modelliert werden können, bei der Vermessung weggelassen.

Zusätzlich verfügt CAMEO über eine Verbindung zu verschiedenen Applikationssystemen und damit zum Motorsteuergerät ECU. Während der Vermessung von einem Betriebspunkt können dadurch beliebige Motorstellgrößen, wie Nockenwellenposition, EGR-Raten (EGR=Exhaust Gas Recirculation), Zündzeitpunkte, usw. verändert werden. Damit wird ein Vermessen von mehrdimensionalen Versuchsräumen möglich. Die Verbindung zu einem Applikationssystem 10 wird normalerweise über ein standardisiertes ASAP 3-Protokoll hergestellt. Dieses kann aber nur zur Kommunikation zwischen zwei Systemen verwendet werden. Um auch im Prüfstandssystem PUMA OPEN ECU-Kanäle mitmessen und in der Datenbank abspeichern zu können, ist ein sogenannter ASAP 3-Server vorgesehen, der quasi als Schalter zwischen den verschiedenen Systemen PUMA OPEN und CAMEO fungiert. Als Schnittstelle wird jeweils eine TCP/IP-Verbindung (TCP/IP= Transmission Control Protocol/Internet Protocol) genutzt, wobei die Protokolle unterschiedlich sind : während zwischen dem Applikationssystem 10 und dem Server ein ASAP 3-Protokoll (ASAP = Arbeitskreis zur Standardisierung von Applikationssystemen) verwendet wird, wurde für die Anbindung von CAMEO ein eigenes Protokoll mit dem Namen ACI (Automatic Calibration Interface) entwickelt, das auf DCOM (Distributed Component Object Model) und somit internen Komponenten des bekannten MICROSOFT- Betriebssystems WINDOWS beruht. In einem weiteren Arbeitsschritt des CAMEO-Arbeitsablaufes können die erstellten Tests automatisiert am Motorprüf stand 1 abgefahren werden. Dabei werden die Betriebspunkteinstellung und die Messdatenerfassung vom Automatisierungssystem aus gesteuert. Teilweise ist auch eine Grenzwertüberwachung in CAMEO sinnvoll, die vom Applikateur bei der Testlauferstellung parametriert werden kann. Für spezielle Applikationsaufgaben sind sogenannte iProcedures (Intelligent Test Run Procedures, automatischer selbstlernender Testablauf)) verfügbar, in denen sehr spezifische Testabläufe und Berechnungen verwirklicht sind. Damit können spezielle ECU-Funktionen sehr effektiv und mit größtmöglichem Schutz des Prüflings bedatet werden.

Nach einem Automatiklauf werden die Testergebnisse in CAMEO gespeichert und in einem weiteren Modul können diese dann ausgewertet und optimiert werden. Um Messausreißer, die in der Praxis gelegentlich auftreten, erkennen zu können, sind verschiedene Werkzeuge implementiert und schon während des Automatiklaufs können so genannte Wiederholpunkte vermessen werden, die eine Aussage über die Messgüte zulassen. Bei der so genannten Rohdatenplausibilisierung können die Daten vom Benutzer und teilweise auch automatisch von CAMEO beurteilt und verdächtige Messausreißer entfernt werden. Dafür stehen verschiedene grafische Darstellungsmöglichkeiten zur Verfügung, die die Detektion der Ausreißer erleichtern.

Für die automatische Modellbildung sind wiederum statistische Methoden in CA- MEO implementiert, um eine Aussage über den so genannten Vertrauensbereich zu treffen. Dieser zeigt, wie gut das gebildete Modell der Wirklichkeit entspricht und in welchen Bereichen das Modell nur wenig vertrauenswürdig ist. Generell kann gesagt werden, dass bei höherer Messgenauigkeit die Anzahl der Messpunkte reduziert werden kann, ohne dass sich die Modellqualität gravierend verschlechtert. Nach Beendigung des Prüflaufs können die Motoreinstellparameter aufgrund der Messdaten optimiert und hinterher Verifikationsläufe zur Absicherung dieser Daten gefahren werden.

Um die Optimierungen auch in der ECU verwenden zu können, ist in CAMEO ein eigener Kennfeldrechner integriert, mit dem Kennfelder neu erstellt oder abgeändert werden können. Anschließend können diese direkt in das Motorsteuergerät übertragen werden.

Eine weitere Komponente von CAMEO, die auch beim noch zu beschreibenden virtuellen Motorprüf stand eine bedeutende Rolle spielt, ist die CAMEO-Erwei- terung namens RT Extension. Es handelt sich dabei um ein Softwarepaket, mit dem MATLAB-SIMULINK-Modelle kompiliert und anschließend in Echtzeit berechnet werden können (MATLAB-SIMULINK ist eine kommerzielle, plattformunabhängige Software des Unternehmens Mathworks Inc., USA). Zum Ermitteln von Verbrennungskenngrößen und indiziertem Drehmoment ist ein Indiziersystem notwendig. Dabei werden die Druckverläufe im Zylinder über spezielle Sensoren vermessen, die Drucksignale mit einer Bandbreite bis 800 kHz aufzeichnen können. Mit einem genauen Kurbelwinkelsensor (Auflösung von 0,5 0 KW) kann schließlich der Druckverlauf über die Kurbelwinkelstellung im Mess- und Anzeigegerät IndiModul (Indimodul ist ein Produkt der AVL LIST GMBH) berechnet werden.

Aus dem Zylinderdruckverlauf können wiederum der Verbrennungsschwerpunkt und das indizierte Drehmoment abgeleitet werden. Außerdem werden durch die Indizierung Klopfereignisse erkannt und entsprechend ihrer Intensität beurteilt. Alle Ergebnisse können im Programm IndiCOM des Unternehmens AVL LIST GMBH angezeigt und über eine TCP/IP Schnittstelle von diesem an PUMA gesendet werden. Außerdem ist IndiCOM über einen CAN-Bus (Controller Area Network) mit dem Echtzeitsystem RT Extension von CAMEO verbunden, um beispielsweise eine Verbrennungsregelung in Echtzeit zu ermöglichen.

Wie bereits erwähnt, treten bei der Parametrierung von Automatikläufen immer wieder große Probleme auf, die später meist zum Abbruch des Prüflaufs führen.

Die Aufgabe des sogenannten Torquemappings besteht darin, die genauen Einflüsse der einzelnen Motorparameter auf das Drehmoment herauszufinden. Aus diesem Grund werden im gesamten Betriebsbereich Zündwinkelvariationen gefahren, wobei am Prüfstand jeweils ein Betriebspunkt eingestellt und hier anschließend der Zündwinkel variiert wird. In ausgewählten Betriebspunkten werden die Gemischzusammensetzung und nach Bedarf auch zusätzlich verbaute Verstell Systeme des Motors wie variable Nockenwellen, eine Abgasrückführung, Ladungsbewegungsklappen oder ähnliches variiert. Zur schnellen und effektiven Parametrierung der Drehmomentstruktur steht in CAMEO eine spezielle Prozedur namens iProcedure zur Verfügung, die zusätzlich in der Lage ist, den Motor vor kritischen Betriebszuständen zu schützen.

In der Praxis kann festgestellt werden, dass die Parametrierung eines Automatiklaufs nur in den seltensten Fällen fehlerfrei ist. Sehr oft passieren Flüchtigkeitsfehler oder der Applikateur bemerkt während des Laufs einen Motoreinfluss, der ihm zuvor nicht bewusst war. Aus diesem Grund wird ein Automatiklauf beim ersten Start im Normalfall längere Zeit beobachtet und muss meistens mehrere Male abgebrochen werden, um die Parametrierung zu verändern.

Große Probleme bereitet bei der Verwendung der Torquemapping-Procedure von CAMEO sehr oft das Finden der günstigsten Abgastemperaturgrenze im Automatiklauf. Einerseits sollte die Grenze möglichst niedrig gewählt werden, um eine Limitverletzung im Prüfstandssystem und den damit verbundenen Abbruch des Automatiklaufes zu verhindern. Andererseits muss bei der Optimierung aber der gesamte zulässige Temperaturbereich bis an den oberen Grenzwert ausgenützt werden, um ein weiteres Leistungs- und Verbrauchspotential ausschöpfen zu können. Ist die Abgastemperaturgrenze im Automatiklauf zu niedrig parame- triert, kann es vorkommen, dass die Torquemapping-Procedure durch immer weiteres Anfetten des Gemisches versucht, eine ausreichende Temperaturreserve zu erzielen. Da im Steuergerät aber ein anderes Soll-Lambda parametriert ist, sind die Optimierungen für diesen Zustand oft nicht mehr aussagekräftig.

Eine weitere Schwierigkeit stellt das Setzen von Sollwerten während einem Automatiklauf oder das Einregeln von Kanälen durch CAMEO dar. Der Applikateur hat die Möglichkeit, solche Aktionen in unterschiedlichen Stufen des Prüflaufs durchzuführen. Wurde ein ungünstiger Zeitpunkt parametriert, so kann dies ungewollte Motorreaktionen oder sogar einen Testabbruch verursachen.

Die genannten Probleme können weitgehend vermieden werden, wenn Automatikläufe vorab in einer Simulationsumgebung getestet werden können, um so viele Fehler in der Parametrierung schon im Voraus beseitigen zu können. Dadurch kann teure Prüfstandszeit eingespart und ein weiterer Teil der Arbeit ins Büro verlagert werden.

Der Aufbau eines solchen virtuellen Motorprüfstandes 11 ist in Fig. 2 dargestellt. Dabei ist es wesentlich, dass die Simulationsumgebung aus Sicht des Automatisierungssystem möglichst dem realen Prüfstandsaufbau entspricht und dem Applikationsingenieur die gewohnte Arbeitsumgebung geboten werden kann. Der Applikationsingenieur sollte die parametrierten Tests möglichst unverändert vom Simulator übernehmen können.

Die Automatikläufe werden genau wie am realen Motorprüfstand 1 in CAMEO parametriert und auch über dieses Programm abgefahren. CAMEO ist über eine ACI Schnittstelle mit PUMA OPEN verbunden, weshalb die Automatisierung exakt gleich funktioniert wie am realen Motorprüfstand 1.

Auch aus Sicht von PUMA OPEN gibt es in der Simulationsumgebung keinen Unterschied zum Aufbau am realen Motorprüfstand 1. Über EMCON werden Pedalwert und Bremsenmoment berechnet, die dann über den CAN-Bus an ein Motormodell 12 geschickt werden, welches im Erweiterungsmodul RT Extension von CAMEO integriert ist. Lediglich die Schnittstelle ist anders, was aber aus Sicht von PUMA OPEN kein Problem darstellt. Auf der CAMEO RT Extension, die exakt gleich wie beim realen Motorprüfstands 1 eingebunden ist, läuft zusätzlich das Motormodell 12 und berechnet in Echtzeit die Motordynamik. Diese Echtzeitumgebung sendet Werte wie Drehzahl und Wellenmoment über den CAN-Bus zurück an PUMA OPEN. Da in der Simulationsumgebung kein Motorsteuergerät ECU verwendet wird, müssen auch eventuell notwendige ECU-Funktionen im Motormodell 12 nachgebildet und mitberechnet werden. Aus demselben Grund kann in der Simulationsumgebung die Anbindung eines Applikationssystems entfallen, da ja keine reale ECU vorhanden ist.

Da PUMA OPEN am realen Motorprüf stand 1 die Brennkraftmaschine 2 stets über Bremsenmoment und Pedalwert regelt, muss auch das Motormodell 12 beim virtuellen Motorprüfstand 11 über diese beiden Kanäle gesteuert werden. Über eine Momentenbilanz und die simulierte Massenträgheit von Motor und Bremse berechnet das Modell dann die aktuelle Drehzahl, die als Antwortgröße zurück an PUMA OPEN gesendet wird.

Somit handelt es sich beim benötigten Modell eigentlich nicht um ein reines Motormodell, sondern es muss vielmehr der gesamte Prüfstandsaufbau inklusive Leistungsbremse simuliert werden.

Da in der Simulationsumgebung kein reales Motorsteuergerät vorhanden ist, können auch keine Parameter direkt in der ECU verstellt werden. Das Motormodell 12 muss aber trotzdem in der Lage sein, auf die Sollwertvorgaben zu reagieren und plausible Ergebnisse zu liefern. Hierfür ist ein Motorsteuergerätmodell 18 erforderlich, das diese Funktionalitäten erfüllt. Vor allem ist darauf zu achten, dass die Parameter das gleiche Format wie im realen Steuergerät besitzen und dieselben Reaktionen bewirken. Im Besonderen muss man die absolute bzw. relative Verstellung von Werten berücksichtigen. So kann es notwendig sein, komplette oder zumindest teilweise vereinfachte ECU-Funktionen innerhalb des Motormodells 12 nachzubilden.

Ein weiteres Problem ergibt sich bei der Übertragung der in CAMEO vorgegebenen ECU-Sollwerte an das Motormodell 12. Am realen Motorprüfstand 1 werden die Parameter über das Applikationssystem 10 aus dem Motorsteuergerät ECU geladen und anschließend auch genau diese Kanalnamen im Testlauf parame- triert. Um den Ablauf am realen Motorprüfstand 1 am virtuellen Motorprüfstand 11 in der Simulationsumgebung nachzubilden, wäre ein HiL (Hardware in the Loop) Aufbau notwendig. Zum Finden der wesentlichen Parametrierfehler reicht aber in der Regel die deutlich einfachere Lösung mit einem Motorsteuergerätemodell 18 vollkommen aus: Wenn in der Testparametrierung die ECU-Kanäle ersetzt und die Informationen direkt zum Motormodell 12 geschickt werden, lässt sich ein deutlich einfacherer Aufbau realisieren und die Reaktionen des Automatiklaufs bleiben trotzdem dieselben.

Für den Testablauf im Automatisierungssystem werden teilweise Werte von Messgeräten benötigt, die daher auch in der Simulationsumgebung bereitgestellt werden müssen. Somit ist es notwendig, auch diverse Messgeräte im Motormodell 12 zu simulieren, die ihre Größen im richtigen Format an das Motorprüf- standssystem 3 senden. Die Werte müssen von Messgerätesimulationsmodellen 19 berechnet werden, weswegen auch die Nachbildung von Temperaturen, Drücken und Indizierdaten innerhalb vom Motormodell 12 notwendig wird. Für Aufgabenstellungen abweichend vom Torquemapping kann auch die Berechnung der Abgaszusammensetzung notwendig sein.

Es gibt prinzipiell verschiedene Möglichkeiten, ein Motormodell aufzubauen. Bei physikalisch basierten Modellen wird versucht, die physikalischen Gesetzmäßigkeiten mathematisch nachzubilden. Dies hat den großen Vorteil, dass zur Para- metrierung des Modells lediglich konstruktive Größen wie Abmessungen, Materialkonstanten usw. notwendig sind. Allerdings ist zur Erstellung eines solchen Motormodells das Wissen über viele technische Grundlagen wie beispielsweise Strömungslehre, Thermodynamik, Mechanik usw. erforderlich. Vorausgesetzt, dass die Berechnungen stimmen, ist jedoch sichergestellt, dass der Verlauf der einzelnen Messgrößen physikalisch richtig abgebildet wird.

In der Praxis ist es kaum möglich, alle Einflüsse bis ins letzte Detail zu modellieren, da dadurch die Berechnungen immer komplexer werden. Sehr oft ergeben sich Differentialgleichungen, deren Lösungen nur numerisch bestimmt werden können. Da dies viel Rechenzeit beansprucht, ist die Anwendung des Modells in Echtzeit oft nicht mehr möglich. Aus diesem Grund müssen Vereinfachungen gemacht werden, die letztlich das Modellergebnis verfälschen.

Alternativ zu den physikalisch basierten Modellen werden in der Praxis oft datenbasierte Modelle verwendet. Zur Erstellung eines Motormodells ist dabei kein Wissen über die physikalischen Hintergründe notwendig, sondern lediglich die Einflussparameter auf bestimmte Größen müssen bekannt sein. Das genaue Verhalten wird am Motorprüf stand vermessen und die Ergebnisse werden in Kennfeldern abgelegt. Dies hat den großen Vorteil, dass das reale Motorverhalten abgebildet wird, allerdings ist die Parametrierung eines solchen Modells sehr aufwendig, da eine ausreichende Datenbasis erforderlich ist und diese für jeden Motor unterschiedlich ist.

Die gefundenen Modelle können entweder in Form von Polynomfunktionen oder als sogenannte Lookup-Tables hinterlegt werden. Für komplizierte Modelle wird verstärkt versucht, so genannte neuronale Netze einzubinden. Diese sind von ihrem Aufbau her dem menschlichen Gehirn nachempfunden. In neuronalen Netzen werden beliebig viele Eingänge mit verschiedenen Gewichtungsfaktoren versehen und addiert. Die so errechneten Werte der ersten Zwischenschicht werden wiederum gewichtet, addiert und in einer zweiten Zwischenschicht abgelegt. Nach einer definierbaren Anzahl von Zwischenschichten werden schließlich durch neuerliche Gewichtung und Addition die Modellausgänge berechnet. Die Struktur eines neuronalen Netzes, also die Anzahl der Ein- und Ausgänge, sowie die Anzahl der Zwischenschichten und der darin enthaltenen Werte, kann vom Benutzer frei definiert werden. Während dem so genannten Netztraining werden die Gewichtungsfaktoren einem vorhandenen Set an Messdaten angepasst, das sowohl alle Eingänge, als auch die gewünschten Modellausgänge enthält. Beim Training handelt es sich prinzipiell um eine numerische Optimierungsaufgabe, bei der der Fehler zwischen den Modellausgängen und dem vorliegenden Trainingsdatenset minimiert wird. In der Praxis treten dabei aber oft Schwierigkeiten auf, wobei vor allem die Bereiche zwischen den Trainingsdaten Probleme bereiten. Anders als bei Polynomfunktionen ist bei neuronalen Netzen der Modellverlauf nämlich nicht von vorn herein sichergestellt. So kann es in einzelnen Bereichen zu einem sogenannten "Overfitting" kommen und in anderen krümmt sich das Netz aufgrund fehlender Datenpunkte vom tatsächlichen Modellverlauf weg.

In hybriden Modellen werden sowohl physikalisch, als auch datenbasierte Modelle verwendet, wobei die unterschiedlichen Vorteile von beiden Systemen genutzt werden können. Dort, wo es einfach möglich ist, das physikalische Verhalten nachzubilden, werden physikalisch basierte Modelle eingesetzt. Um zusätzliche Einflüsse zu berücksichtigen, werden datenbasierte Korrekturkennfelder erstellt, die das Modell an die realen Messergebnisse anpasst.

Um die prinzipielle Funktion vom Simulationsaufbau und die Kommunikation zwischen den einzelnen Systemen zu testen, ist ein eigenes Motormodell entstanden, das an die Anforderungen der Simulationsumgebung angepasst ist.

Das im Folgenden für einen homogen betriebenen Ottomotor beschriebene eigentliche Motormodell besteht aus mehreren Teilbereichen. Im Saugrohrmodell werden über Drosselklappenwinkel und Motordrehzahl der Saugrohrdruck und die zufließende Luftmasse bestimmt. Das Verbrennungsmodell berechnet in Abhängigkeit von Luftmasse, Kraftstoffmenge und Zündzeitpunkt das abgegebene Drehmoment und die Abgastemperatur. Weiters kann auch ein hier nicht weiter erläutertes Emissionsmodell eingebunden werden. Sauqrohrmodell 13

Das Saugrohrmodell 13 simuliert über physikalische Zusammenhänge den Saugrohrdruck p SR , wobei in einem vereinfachten auf der Massenbilanz basierenden Saugrohrmodell 13 folgender Zusammenhang gilt:

mit v DK ... Strömungsgeschwindigkeit in der Drosselklappe (m / s)

K ... Isentropenexponent (-) p SR ... Saugrohrdruck (Pa)

P 1J ... Umgebungsdruck (Pa) T n ... Umgebungstemperatur (K)

R ... spezifische Gaskonstante (J / kg K) Für den zufließenden Massenstrom gilt:

m zu ... zufließender Massenstrom (kg / s)

Der abfließende Massenstrom aus dem Saugrohrdruck p SR ist gleichzeitig jene Luft, die in den Zylinder des Motors gelangt. Abhängig ist diese Menge vom Saugrohrdruck p SR , vom Hubraum und von der Drehzahl des Motors, sowie von den Strömungsverhältnissen in den Einlasskanälen und den Steuerzeiten des Ventiltriebs. Da die letzten beiden Einflüsse physikalisch nur sehr schwer zu modellieren sind und dies später einen enormen Parametrieraufwand bedeuten würde, stellt ein hybrider Modellansatz in diesem Fall die beste Lösung dar.

Zur Bedatung der Funktion ist vorab die Vermessung einer Volllastkurve am Motorprüfstand notwendig. Hierzu wird der Motor bei voll geöffneter Drosselklappe gefeuert betrieben und die angesaugte Luftmasse bei unterschiedlichen Dreh- zahlen bestimmt. Aus den Ergebnissen wird eine Kennlinie erstellt, die im Saugrohrmodell 13 abgelegt ist.

Die aktuelle Luftmasse für den jeweiligen Saugrohrdruck p SR berechnet sich über die so genannten Schluckgeraden. Am realen Motor zeigt sich ein näherungsweise linearer Zusammenhang zwischen Saugrohrdruck p SR und angesaugter Luftmasse, der recht einfach über zwei Punkte bestimmt werden kann. Dies sind die gemessene Luftmasse bei Volllast und der Partialdruck vom inerten Restgas PIRG im Zylinder, das jenen Saugrohrdruck darstellt, bei dem das im Zylinder verbleibende Restgas ein Einströmen von Frischluft verhindert. Die angesaugte Luftmasse ist bei diesem Druck also 0.

Obwohl die Schluckgerade bei manchen Drehzahlen leicht gebogen sind, wurde im Ausführungsbeispiel innerhalb des hier beschriebenen Motormodells 12 auf eine Korrektur verzichtet, da sich der Fehler in den weiteren Berechnungen kaum auswirkt und für die Anwendung in der Simulationsumgebung nicht relevant ist. Eine weitere Vereinfachung im Motormodell 12 ergibt sich, indem der Unterdruck im Saugrohr bei Volllast vernachlässigt werden kann. Auch der Partialdruck des inerten Restgases PIRG im Zylinder ist in der Realität nicht konstant, wird im Motormodell 12 aber für jede Drehzahl mit 200 mbar angenommen.

Die aktuell aus dem Saugrohr abfließende Luftmasse berechnet sich somit über den Zusammenhang :

P SR -PIRG m ab = m Luft _ VL . - 2Q (5)

m ab ... abfließender Massenstrom (kg / s)

m Luft VL ... Luftmassenstrom unter Volllast (kg / s)

P SR ... Saugrohrdruck (kPa)

PIRG ... Partialdruck Inert Restgas (kPa)

Am Ende der Funktion wird die Luftmasse noch über den Hubraum des Motors skaliert, um mit der gleichen Parametrierung auch ähnlich aufgebaute Motoren mit anderen Hubräumen abbilden zu können.

Die dritte Funktion innerhalb des Saugrohrmodells berechnet über eine Massenbilanz des zu- und abfließenden Massenstroms den Saugrohrdruck. Unter der Annahme von idealem Gasverhalten gilt für die Massen- bzw. Druckänderung im Saugrohr die folgende Gleichung :

Ps R V SR = {m m - m ab )RT SR (6)

p SR ... Änderung des Saugrohrdruckes (Pa / s)

V SR ... Saugrohrvolumen (m 3 ) T SR ... Temperatur im Saugrohr (K)

Für die Temperatur der Luft im Saugrohr wurde im Modell ein Mittelwert von 5 0 C über der Umgebungstemperatur angenommen. Somit berechnet sich der Saugrohrdruck P SR über:

Verbrennunqsmodell 14

Die wohl wichtigste Ausgangsgröße eines Motors stellt die abgegebene Leistung dar. In der Simulation wird diese im Verbrennungsmodell 14 berechnet, wobei wieder ein hybrider Ansatz verwendet wird :

Über die verbrannte Kraftstoffmasse und ein Wirkungsgradkennfeld wird jener Energieanteil berechnet, der an die Kurbelwelle abgegeben wird. Dieser nennt sich PIH (indizierte Leistung in der Hochdruckschleife) und stellt die Fläche in der Arbeitsschleife eines pV-Diagramms (p...Druck, V...Volumen im Arbeitsraum) dar.

Das PIH wird über folgenden Zusammenhang berechnet:

PIH = m κs H σ η PIH (8)

PIH ... indizierte Leistung in der Hochdruckschleife (kW) m κs ... Kraftstoffmassenstrom (kg / s)

H n ... unterer Heizwert (kJ / kg) η PIH ... Wirkungsgrad in der Hochdruckschleife (-)

Der parametrierte Wirkungsgrad berücksichtigt dabei die jeweils optimalen Motoreinstellungen und stellt daher die größtmögliche Leistungsausbeute dar. Für die Kraftstoffmasse muss berücksichtigt werden, dass bei fettem Gemisch nicht die gesamte Menge verbrannt werden kann, da dafür zu wenig Luftsauerstoff vorhanden ist. Die Kraftstoffmasse muss daher begrenzt werden : mLuft / r . \

W-S M 1 = T 1 (9)

m κs ^x ... maximaler Kraftstoffmassenstrom der verbrannt werden kann (kg / s) m Luft ... angesaugter Luftmassenstrom (kg / s)

L St ... stöchiometrisches Luftverhältnis (-)

Der Faktor L St \st kraftstoffabhängig und gibt an, welche Luftmasse benötigt wird, um 1 kg Kraftstoff vollständig zu verbrennen.

Nachdem die maximale Leistung für den jeweiligen Betriebspunkt berechnet wurde, wird diese mit dem so genannten Zündwinkelwirkungsgrad multipliziert. Um diesen Faktor für jeden Betriebszustand physikalisch sinnvoll nachbilden zu können, ohne eine Vielzahl an Daten parametrieren zu müssen, wurde wiederum ein hybrider Modellansatz gewählt. Über den Zündwinkeleinfluss ergibt sich ein parabolischer Verlauf der abgegebenen Leistung. Durch die Verwendung einer dafür geeigneten, quadratischen Gleichung ist dieser prinzipielle Verlauf sichergestellt: η ZZP = -0,5 • ZZPl 1 + ZZP rel + 0,5 (10)

77 2Z p ... Zündwinkelwirkungsgrad (-) ZZP rel ... relativer Zündzeitpunkt (-)

Der für die Gleichung notwendige, relative Zündzeitpunkt berechnet sich über den Zusammenhang :

77 P — 77P

ZZP r r e e l l = 77 Δ p ΔF Z - Z 7 / 7 W p ( V 11) '

^^ 1 maxP ^^ 1 50%P

ZZP ... Zündzeitpunkt (° KW) ZZP 5O%P ... Zündzeitpunkt bei der die halbe Leistung abgegeben wird (° KW)

ZZP m∞ p - Zündzeitpunkt für die maximale Leistungsabgabe (° KW)

Der Zündwinkel für die maximale Leistungsausbeute und jener Zündzeitpunkt, bei dem genau die Hälfte der indizierten Leistung abgegeben wird, sind in zwei Kennfeldern abgelegt. Damit lässt sich die Form der Parabel beeinflussen. Um zu verhindern, dass der Zündwinkelwirkungsgrad negativ wird, wurde im Ausführungsbeispiel eine zusätzliche Korrekturkennlinie implementiert, die ab dem ZZP 5O%P den Verlauf der Kurve ändert und dem Wert 0 annähert.

Der Einfluss der Gemischzusammensetzung auf die indizierte Leistung wurde im hier beschriebenen Verbrennungsmodell 14 vernachlässigt, es könnte jedoch ein Lambdawirkungsgrad als Korrekturfaktor eingefügt werden.

Um die effektive Leistung des Motors berechnen zu können, müssen noch die Ladungswechsel- und Reibungsverluste abgezogen werden. Die Ladungswechselarbeit wird dabei wiederum als hybrides Modell berechnet, indem die Ladungswechselschleife im pV-Diagramm als Rechteck angenommen wird. Somit ist zur Bestimmung dieser Verluste nur mehr die Kenntnis über das Hubvolumen des Motors, den Saugrohrunterdruck und den Abgasgegendruck notwendig. Letzterer ist als Kennlinie abhängig vom durchfließenden Massenstrom parametriert. Diese Näherung funktioniert bei der Modellierung von konventionellen Ottomotoren recht gut. Für die Nachbildung eines variablen Ventiltriebs kann diese Vereinfachung aber nicht mehr verwendet werden.

Die Reibverluste des Motors sind in einer Kennlinie abgelegt, die über die Zylinderanzahl normiert wird. Dies beruht auf der Annahme, dass sich die Reibung mit der Zylinderanzahl linear ändert. So kann nach dem Abzug der einzelnen Verluste die effektive Leistung und damit auch das effektive Drehmoment des Motors berechnet werden.

Zur Simulation des Motorprüfstandes samt Leistungsbremse beinhaltet das Motormodell 12 weiters noch ein Parametrierungsmittel 15, ein Dynamikmodell 16 samt Startermodell 17, ein Motorsteuergerätmodell 18 und ein Messgerätesimu- lationsmodell 19:

Parametrierungsmittel 15

Über die Parametrierungsmittel 15 kann der Benutzer das Motormodell 12 an den realen Motortyp anpassen. Hierzu ist die Kenntnis über Hubraum, Zylinderzahl, Saugrohrvolumen, Drosselklappendurchmesser und Massenträgheit der Brennkraftmaschine und der Leistungsbremse notwendig. Es handelt sich dabei um rein konstruktive Parameter, die im Normalfall für jede Brennkraftmaschine (und Prüfstandsaufbau) bekannt sind. Das gesamte Motormodell 12 wird über diese skaliert, wodurch der Benutzer jederzeit qualitativ richtige Ergebnisse erhält. Zum detaillierten Anpassen des Motormodells 12 an die reale Brennkraftmaschine 2 können innerhalb der einzelnen Funktionen Korrekturkennfelder ver- ändert werden. Hierzu ist allerdings eine Vielzahl von Messwerten von der realen Brennkraftmaschine notwendig.

Weiters kann der Benutzer im Motormodell 12 über Druck und Temperatur die Umgebungsbedingungen vorgeben. Außerdem besteht die Möglichkeit, kraftstoffspezifische Kennwerte anzupassen.

Dvnamikmodell 16

Das Dynamikmodell 16 berechnet über eine Momentenbilanz und die Massenträgheit der Brennkraftmaschine 2 und der Leistungsbremse 5 eine Winkelbeschleunigung. Zusätzlich ist ein Startermodell 17 integriert, das bei gesetztem Startbit in Abhängigkeit von der Drehzahl ein Moment abgibt. Dadurch kann die virtuelle Brennkraftmaschine wie in der Realität bis zur Startdrehzahl beschleunigt werden. Die Kennwerte für den Starter stammen aus dem Datenblatt eines realen Anlassers und müssen bei der Parametrierung einer größeren Brennkraftmaschine angepasst werden.

Für die Berechnung der Drehzahländerung gilt folgender physikalische Grundsatz:

∑M = Θ ώ (1)

M ... Drehmoment (Nm) Θ ... Massenträgheitsmoment (kg m 2 ) ώ ... Winkelbeschleunigung (rad / s 2 )

Daraus lässt sich die Formel für die Motordrehzahl ableiten :

∑M ω =J -dt + ω 0 (2)

Θ ,, + Θ H

ω 0 ... Anfangswinkelgeschwindigkeit (rad / s)

Motorsteuerqerätmodell 18

Im Motorsteuergerätmodell 18 werden alle Funktionen vom Motorsteuergerät ECU, die auch für die Simulationsumgebung notwendig sind, nachgebildet. Wie im realen Motorsteuergerät ECU sind hierfür die Messwerte von der angesaugten Luftmasse, von der Drehzahl und vom Pedalwert als Modelleingänge notwendig. Daraus berechnet das Motorsteuergerätmodell 18 eine relative Zylinderfüllung, einen Drosselklappenwinkel und einen Soll-Lambdawert, der in einem Kennfeld abgelegt ist. Zu Applikationszwecken besteht die Möglichkeit, den Lambdawert zu ändern. In einem weiteren Kennfeld im Motorsteuergerätmodell 18 wird der optimale Zündzeitpunkt bestimmt, der zu Applikationszwecken verstellt werden kann. Außerdem wird die notwendige Kraftstoffmenge berechnet, die bei der aktuellen Luftmasse zum Erreichen des vorgegebenen Lambdawertes notwendig ist.

Messqerätemodell 19

Insbesondere für interne Berechnungen der Torquemapping Procedure der Para- metriersoftware CAMEO sind Messwerte der Abgastemperatur und Klopfwahrscheinlichkeiten erforderlich. Auch diese müssen in der Simulationsumgebung vom Motormodell 12 berechnet und an das Prüfstandssystem 3 übertragen werden.

Zur Modellierung der Abgastemperatur wurde im Beispiel ein hybrider Ansatz gewählt. Die Temperatur für die optimalen Motoreinstellungen, also für die maximale Leistungsausbeute, sind in einem Kennfeld abgelegt. Um den Zündwinkel- einfluss auf die Abgastemperatur nachbilden zu können, wird die Leistungsdifferenz infolge vom Zündwinkelwirkungsgrad in eine Temperaturdifferenz umgerechnet. Die Auswertung von Daten einer realen Brennkraftmaschine zeigt, dass dabei etwa die Hälfte der Energie über das Abgas abgeführt wird. Der physikalische Zusammenhang lässt sich daher annäherungsweise über folgende Gleichung abbilden :

T 31 ... Abgastemperatur (K)

T 3i max i * -- Abgastem peratu r bei maximaler Leistungsabgabe (K) c P ... spezifische Wärme bei konstantem Druck (J / kg K)

Um den Lambdaeinfluss zu modellieren, wird die berechnete Abgastemperatur über eine Kennlinie korrigiert. Am Ende wird sie noch mit der Umgebungstemperatur nach unten begrenzt und die Änderungsgeschwindigkeit eingeschränkt, um die real auftretende Trägheit dieses Systems zu berücksichtigen.

Zur Simulation einer Klopferkennung ist im Motormodell 12 ein Kennfeld mit den Klopfgrenzen parametriert. Für Betriebspunkte, die nicht klopfbegrenzt sind, werden hierbei sehr frühe Zündzeitpunkte angegeben, die in der Praxis niemals eingestellt werden. Generell wird genau an der Klopfgrenze eine Klopfwahrscheinlichkeit von 8 % berechnet. Bei noch früheren Zündwinkeln steigt dieser Wert bis zu 100 % an und bei etwas späterer Zündung sinkt er entsprechend ab.