Neue Möglichkeiten für die Motorsteuergeräte-Software durch Car-to-Cloud-Vernetzung [1. Aufl.] 9783658315641, 9783658315658

Table of contents :
Front Matter ....Pages I-XXIX
Einleitung (Lars Hagen)....Pages 1-3
Stand der Technik (Lars Hagen)....Pages 5-36
Anwendungsfelder im Bereich der Motorsteuerung (Lars Hagen)....Pages 37-50
Anwendungsbeispiel Applikation (Lars Hagen)....Pages 51-75
Anwendungsbeispiel Diagnose (Lars Hagen)....Pages 77-97
Schlussfolgerung und Ausblick (Lars Hagen)....Pages 99-101
Back Matter ....Pages 103-115

Citation preview

Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart

Lars Hagen

Neue Möglichkeiten für die MotorsteuergeräteSoftware durch Car-toCloud-Vernetzung

Wissenschaftliche Reihe ­Fahrzeugtechnik Universität Stuttgart Reihe herausgegeben von Michael Bargende, Stuttgart, Deutschland Hans-Christian Reuss, Stuttgart, Deutschland Jochen Wiedemann, Stuttgart, Deutschland

Das Institut für Fahrzeugtechnik Stuttgart (IFS) an der Universität Stuttgart erforscht, entwickelt, appliziert und erprobt, in enger Zusammenarbeit mit der Industrie, Elemente bzw. Technologien aus dem Bereich moderner Fahrzeugkonzepte. Das Institut gliedert sich in die drei Bereiche Kraftfahrwesen, Fahrzeugantriebe und Kraftfahrzeug-Mechatronik. Aufgabe dieser Bereiche ist die Ausarbeitung des Themengebietes im Prüfstandsbetrieb, in Theorie und Simulation. Schwerpunkte des Kraftfahrwesens sind hierbei die Aerodynamik, Akustik (NVH), Fahrdynamik und Fahrermodellierung, Leichtbau, Sicherheit, Kraftübertragung sowie Energie und Thermomanagement – auch in Verbindung mit hybriden und batterieelektrischen Fahrzeugkonzepten. Der Bereich Fahrzeugantriebe widmet sich den Themen Brennverfahrensentwicklung einschließlich Regelungs- und Steuerungskonzeptionen bei zugleich minimierten Emissionen, komplexe Abgasnachbehandlung, Aufladesysteme und -strategien, Hybridsysteme und Betriebsstrategien sowie mechanisch-akustischen Fragestellungen. The­ men der Kraftfahrzeug-Mechatronik sind die Antriebsstrangregelung/Hybride, Elektromobilität, Bordnetz und Energiemanagement, Funktions- und Softwa­ reentwicklung sowie Test und Diagnose. Die Erfüllung dieser Aufgaben wird prüfstandsseitig neben vielem anderen unterstützt durch 19 Motorenprüfstände, zwei Rollenprüfstände, einen 1:1-Fahrsimulator, einen Antriebsstrangprüfstand, einen Thermowindkanal sowie einen 1:1-Aeroakustikwindkanal. Die wissenschaftliche Reihe „Fahrzeugtechnik Universität Stuttgart“ präsentiert über die am Institut entstandenen Promotionen die hervorragenden Arbeitsergebnisse der Forschungstätigkeiten am IFS. Reihe herausgegeben von Prof. Dr.-Ing. Michael Bargende Lehrstuhl Fahrzeugantriebe Institut für Fahrzeugtechnik Stuttgart Universität Stuttgart Stuttgart, Deutschland

Prof. Dr.-Ing. Hans-Christian Reuss Lehrstuhl Kraftfahrzeugmechatronik Institut für Fahrzeugtechnik Stuttgart Universität Stuttgart Stuttgart, Deutschland

Prof. Dr.-Ing. Jochen Wiedemann Lehrstuhl Kraftfahrwesen Institut für Fahrzeugtechnik Stuttgart Universität Stuttgart Stuttgart, Deutschland

Weitere Bände in der Reihe http://www.springer.com/series/13535

Lars Hagen

Neue Möglichkeiten für die M ­ otorsteuergeräteSoftware durch ­­Car-toCloud-Vernetzung

Lars Hagen Institut für Fahrzeugtechnik Stuttgart (IFS), Lehrstuhl für Fahrzeugantriebe Universität Stuttgart Stuttgart, Deutschland Zugl.: Dissertation Universität Stuttgart, 2020 D93

ISSN 2567-0042 ISSN 2567-0352  (electronic) Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart ISBN 978-3-658-31565-8  (eBook) ISBN 978-3-658-31564-1 https://doi.org/10.1007/978-3-658-31565-8 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen National­ bibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informa­ tionen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Vorwort Die vorliegende Arbeit entstand während meiner Tätigkeit als Doktorand am Institut für Fahrzeugtechnik der Universität Stuttgart sowie meiner Anstellung als Funktionsentwickler bei der Robert Bosch GmbH in den Jahren 2015 bis 2020. Mein besonderer Dank gilt Herrn Prof. Dr.-Ing. Michael Bargende, der mich in diesem Zeitraum hervorragend betreut hat. Die regelmäßigen Rücksprachen und seine Ratschläge haben in besonderem Maße zum Gelingen dieser Arbeit beigetragen. Ich danke ihm auch für die Übernahme des Hauptberichts. Herrn Prof. Dr. techn. Christian Beidl danke ich für das Interesse an dieser Arbeit sowie die freundliche Übernahme des Mitberichts. In besonderem Maße möchte ich meinen beiden Betreuern Herrn Dr.-Ing. Thomas Bleile und Herrn Dr.-Ing. Andreas Walter für ihre fachkundige und lehrreiche Unterstützung danken. Meinem Abteilungsleiter Herrn Dr.-Ing. Alexander Henle gilt ein besonderer Dank, da er mir diese Arbeit ermöglicht hat. Danken möchte ich auch allen weiteren Kollegen, die an dieser Arbeit beteiligt waren, allen voran den Kollegen der zentralen Forschung sowie den involvierten Studenten. Danken möchte ich auch meinen Eltern Christiane und Michael Hagen, die mich schon während des Studiums immer gefördert und in meinem Tun bekräftigt haben. Meinem Bruder Jan danke ich für seine Großzügigkeit und liebevolle Art, die er mir immer entgegengebracht hat. Meiner lieben Frau Luisa möchte ich für ihre unglaubliche Unterstützung und Energie danken, auch während ihres eigenen Jobs und dem Großziehen unserer Kinder Wilhelm und Elise. Stuttgart

Lars Hagen

Inhaltsverzeichnis Vorwort ........................................................................................ V Abbildungsverzeichnis ................................................................... XI Tabellenverzeichnis...................................................................... XIII Abkürzungsverzeichnis.................................................................. XV Symbolverzeichnis ......................................................................XIX Extended Abstract .......................................................................XXI Kurzfassung ............................................................................ XXIX 1

Einleitung ................................................................................ 1

2

Stand der Technik ..................................................................... 5 2.1

2.2

2.3

2.4

2.5

Hardware des vernetzten Fahrzeugs ........................................ 5 2.1.1 Elektronisches Motorsteuergerät .................................. 6 2.1.2 CAN - Bus .............................................................. 8 2.1.3 VCU - Vehicle Control Unit...................................... 11 2.1.4 Mobilfunk............................................................. 12 2.1.5 Car2X-Kommunikation ........................................... 15 2.1.6 Cloud-Computing ................................................... 16 Dieselmotor und Luftsystem................................................ 17 2.2.1 Physikalische Grundlagen und Modellierung ................ 19 2.2.2 Füll- und Entleermethode ......................................... 21 2.2.3 Drosselgleichung.................................................... 21 Applikation von Motorsteuergerätefunktionen ......................... 23 2.3.1 Maximum Likelihood Schätzung ............................... 25 2.3.2 Fisher-Information und Cramér-Rao Ungleichung ......... 27 Diagnose von Verbrennungsmotoren ..................................... 28 2.4.1 Abgasgesetzgebung ................................................ 29 2.4.2 Diagnosemethoden ................................................. 30 Software-Entwicklungsprozess ............................................ 32 2.5.1 V-Modell .............................................................. 32 2.5.2 MiL, SiL und HiL-Testmethoden ............................... 35

VIII 3

Anwendungsfelder im Bereich der Motorsteuerung ..................... 37 3.1 3.2

3.3

3.4 3.5 4

4.4 4.5 4.6 4.7

Messdatenerfassung........................................................... 51 Messdatenreduktion........................................................... 53 Konzept zur vernetzten Applikation ...................................... 56 4.3.1 Ebene Prüfstand ..................................................... 58 4.3.2 Ebene Fahrzeug ..................................................... 58 4.3.3 Ebene Cloud.......................................................... 61 Abgasgegendruckmodell .................................................... 62 Offline Optimierung .......................................................... 64 Online Optimierung........................................................... 68 Zusammenfassung............................................................. 74

Anwendungsbeispiel Diagnose .................................................. 77 5.1

5.2

5.3 5.4 6

Überblick ........................................................................ 37 Entwicklungsprozess ......................................................... 38 3.2.1 Systementwicklung ................................................. 39 3.2.2 Software-Entwicklung ............................................. 41 Applikation/Parametrierung ................................................ 42 3.3.1 Überblick.............................................................. 42 3.3.2 Applikationsstrategien ............................................. 45 Diagnose......................................................................... 47 Sonstige Anwendungsgebiete .............................................. 49

Anwendungsbeispiel Applikation .............................................. 51 4.1 4.2 4.3

5

Inhaltsverzeichnis

Konzept .......................................................................... 77 5.1.1 Ebene Fahrzeug ..................................................... 78 5.1.2 Ebene Cloud.......................................................... 79 Diagnose des Abgaskrümmer-Subsystems .............................. 80 5.2.1 Diesel-Luftsystem in einer SiL-Umgebung................... 81 5.2.2 Fehleridentifikation ................................................. 84 Umsetzung und Auswertung................................................ 88 Zusammenfassung............................................................. 95

Schlussfolgerung und Ausblick.................................................. 99

Inhaltsverzeichnis

IX

Literaturverzeichnis ......................................................................103 Anhang ......................................................................................111 A.1 Lastpunkte WLTC............................................................111 A.2 Motordaten .....................................................................112 A.3 Modellgüte Streckenmodell................................................113

Abbildungsverzeichnis 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11

Mögliche Hardware-Realisierung für Car-to-Cloud ......................... 5 Hauptgrößen der Motorsteuerung des Diesel-Luftsystems................. 6 schematischer Aufbau eines Steuergeräts ...................................... 7 MDG1 Motorsteuergerät (Quelle: Bosch) ...................................... 8 Highspeed-CAN .................................................................... 10 (R)evolution von E/E Architekturen [55] ..................................... 11 VCU-P Domänenrechner (Quelle: Bosch) ................................... 12 LTE Systemarchitektur............................................................ 14 Das Luft- und Abgassystem eines aktuellen Dieselmotors............... 18 Strömung an Drosselelement .................................................... 21 Durchflussfunktion Ψ ............................................................. 23 Parameterschätzung................................................................ 24 Wahrscheinlichkeitsdichtefunktion für den Fehler e ....................... 26 Modellbasierte Diagnose ......................................................... 31 V-Modell ............................................................................. 33 MiL/SiL/HiL-Simulation ......................................................... 36 Übersicht über Anwendungsfelder für Car-to-Cloud 1/2 ................. 37 Übersicht über Anwendungsfelder für Car-to-Cloud 2/2 ................. 38 Anwendungsmöglichkeiten Applikation...................................... 46 Anwendungsmöglichkeiten Diagnose ......................................... 48 Bestimmung des Informationsgehalts von Messdaten..................... 55 Applikationskonzept mit dem vernetzten Fahrzeug ........................ 56 konventionelles Vorgehen zur Basisapplikation............................. 58 konventionelles Vorgehen zur Fahrzeugapplikation........................ 59 Algorithmus auf der VCU........................................................ 60 Algorithmus auf der Cloud....................................................... 61 automatisierte Applikation durch Car-to-Cloud ............................ 62 p3 -Modell in Matlab/Simulink® ................................................ 63 Lastpunktvariation am Prüfstand ............................................... 64 Basis-Kennfeld für Abgasgegendruckmodell................................ 65 Vergleich Modell / Sensor mit stationären Prüfstandsdaten.............. 66

XII 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 A1.1 A1.2 A1.3

Abbildungsverzeichnis Modellgüte anhand stationärer Prüfstandsdaten ............................ 66 Vergleich Modell und Sensor WLTC .......................................... 67 Modellgüte im WLTC ............................................................. 68 Versuchsstrecke rund um Stuttgart ............................................. 69 Kennfeldpunkte Vgl. Prüfstand zu Versuchsfahrten 1+2+3 gesamt .... 70 Versuchsfahrt 1...................................................................... 71 Versuchsfahrt 2...................................................................... 72 Versuchsfahrt 3...................................................................... 72 Kennfeldpunkte Vgl. Prüfstand zu Versuchsfahrten 1+2+3 reduziert .................................................................................... 73 Diagnosekonzept für das vernetzte Fahrzeug ................................ 78 untersuchte Fehler im Abgaskrümmer-Subsystem ......................... 80 SiL Luftsystem-Modell in Matlab/Simulink® ............................... 81 Streckenmodell in Matlab/Simulink® ......................................... 82 GUI für Simulationsmodell ...................................................... 83 Betriebspunkte zur Voruntersuchung der Residuen ........................ 85 Residuen zur Fehleridentifikation .............................................. 85 Blockdiagramm zur Fehlererkennung in Matlab/Simulink® ............. 89 Root Mean Squared Error für den Abgasgegendruck p3 ................. 90 Volumen Abgaskrümmer ......................................................... 91 Sensitivitäten zur Messdatenbewertung....................................... 94 Residuen zur Diagnose des Abgaskrümmer-Subsystems ................. 95 Fahrzeuggeschwindigkeit WLTC..............................................111 Motordrehzahl WLTC............................................................111 Einspritzmenge WLTC...........................................................112

Tabellenverzeichnis 2.1 2.2 2.3 4.1 4.2 5.1 5.2 5.3 A2.1 A3.1 A3.2 A3.3

Leistungsdaten MDG1 Device 4 - Motorsteuergerät von Bosch .......... 8 Leistungsdaten Bosch VCU-Performance.................................... 12 theoretische Übertragungsgeschwindigkeiten des Mobilfunks .......... 13 Bewertungskriterien der Messfenster für Applikationskonzept ......... 70 Gütemaße für die Versuchsfahrten 1,2 und 3 ................................ 74 Fehler-Symptom-Tabelle ......................................................... 87 Fehlererkennung .................................................................... 89 Bewertungskriterien der Messfenster für Diagnose ........................ 94 Daten Diesel - Versuchsmotor..................................................112 441 Betriebspunkte v. Prüfstand, stationär ohne AGR ...................113 416 Betriebspunkte v. Prüfstand, stationär mit AGR .....................114 Modellgüte WLTC ................................................................115

Abkürzungsverzeichnis 3GPP

3rd Generation Partnership Project

ADC AGR ASAM

AUTOSAR

Analog Digital Converter Abgasrückführung Arbeitskreis für die Standardisierung von Automatisierungsund Messsystemen Automotive Software Process Improvement and Capability Determination AUTomotive Open System ARchitecture

CAN CARB CFD CPU

Controller Area Network California Air Resources Board Computational Fluid Dynamics Central Processing Unit

DoE

Design of Experiments

ECU EDGE EEPROM EOBD EPA EPC EU

Electronic Control Unit Enhanced Data Rates for GSM Evolution Electric Erasable Programmable Read-Only Memory European On-Board Diagnostics Environmental Protection Agency Evolved Packet Core Europäische Union

FIM

Fisher-Informationsmatrix

GPRS GPS GSM GUI

General Packet Radio Service Global Positioning System Global System for Mobile Communication Graphical User Interface

ASPICE

XVI

Abkürzungsverzeichnis

HD HFM HSPA

Hochdruck Heißfilm-Luftmassenmesser High-Speed Packet Access

IUMPR

In-Use Monitoring Performance Ratio

LIN LLK LS LTE

Local Interconnect Network Ladeluftkühler Least Squares Long Term Evolution

MiL/SiL/HiL MIMO ML MNEFZ

Model-/Software-/Hardware-in-the-Loop Multiple Input Multiple Output Maximum Likelihood Modifizierter Neuer Europäischer Fahrzyklus

ND NIST

Niederdruck National Institute of Standards and Technology

OBD OFDM

On-Board-Diagnose Orthogonal Frequency Division Multiplexing

RAM RDE RMSE

Random Access Memory Real Driving Emissions Root Mean Squared Error

SAE SENT SIM SW

Society of Automotive Engineers Single Edge Nibble Transmission Subscriber Identity Module Software

UE UMTS

User Equipment Universal Mobile Telecommunication System

V2I

Vehicle to Infrastructure

Abkürzungsverzeichnis V2X VCU VDI VIN VTG

Vehicle to Everything Vehicle Control Unit Verein Deutscher Ingenieure Vehicle Identification Number variable Turbinengeometrie

WLAN WLTC

Wireless Local Area Network Worldwide harmonized Light Duty Test Cycle

XVII

Symbolverzeichnis Lateinische Buchstaben A C cp cv e L m, m˙ n p Q, Q˙ R T t U u V W w y

Fläche Kovarianzmatrix spezifische Wärmekapazität (isobar) spezifische Wärmekapazität (isochor) Modellfehler, Residuum Likelihood-Funktion Masse, Massenstrom Drehzahl Gasdruck, Parameter Wärme, Wärmestrom ideale Gaskonstante Temperatur Zeit innere Energie Eingangssignal Volumen Arbeit Gasgeschwindigkeit Ausgangssignal Griechische Buchstaben

η κ λa Π Ψ ρ σ θ

Wirkungsgrad Isentropenexponent Luftaufwand Druckverhältnis Durchflussfunktion Dichte Standardabweichung Parameter

XX

Symbolverzeichnis

Indizes 3 4 AV B dyn eff EV k t Trbn

nach Auslassventil und vor Turbine nach Turbine Auslassventil Brennstoff dynamisch effektiv Einlassventil diskreter Abtastschritt technisch Turbine

Extended Abstract At present the engine control unit in particular is in the publics’ focus, since it is a high determining factor related to consumption, emissions and power of the powertrain and hence for meeting the overall demand of legal- and customer requirements. At the same time and deriving from the previously outlined conflict of goals as well as the continuously increasing diversity of variants, vehicles and power units, the engine control units’ software is getting samewise steadily more complex. In order to meet this challenge properly, it is of prime importance to have the current available technological framework, such as connecting the vehicle with the help of mobile services, fully applied. The available dissertation elaborates possible utilization scenarios, such as the ”connected car” and notably the linking-up via Car-to-Cloud during software development phase as well as within the launched series, and how to have them implemented within the engine control unit productively. For this purpose and based upon the automotive standard development process, the so called V-model, the individual process steps of the system- and software development are illustrated initially and deriving from it the potential of usage of the connected vehicle reviewed. As a matter of particular interest for the OEM and the supplying industry is the in-use data of the vehicle fleets, since those are providing a high value added for a proper requirements engineering. Available information on part variances, probability of failure or tolerance drifting over lifetime can be used and hence empowers to have improved software functionalities realized. Incorporating further vehicle external information sources like meteorological stations or a feedback on traffic, might help creating new concepts optimizing the engines’ operational mode. The software quality will be improved further based upon e.g. the readiness of updating ”over-the-air” and data back-upping. A powerful instrument to increase the efficiency of the development process on the other hand, can be remote vehicle testing. The high computing- and storage capacity of a cloud provides the possibility of automation for functional parameterization, wherefrom the im-

XXII

Extended Abstract

provement of the development process’ efficiency itself and a cost saving goes hand in hand with. Software - Development Requirements Engineering

Cloud

x New concepts due to: - Informations outside of vehicle (e.g. weather stations, traffic informations) - computing power outside of vehicle x Remote vehicle testing x Data Backup x Remote SW-Updates x ...

x

Knowledge base for: - component analysis - driverr s behaviour - durability prediction - drift across lifetime - probability of failure - tolerance analysis - vehicle-to-vehicle spread -

Besides the outlined advantages of the Car-to-Cloud connectivity during the software development process, a higher degree of potential optimization is also recognized post-development, namely within series operation. In particular advantages for powertrain diagnostics based on higher complex diagnosis algorithms as well as the possibility of field monitoring for the legislator can be observed. Besides expanded and computationally intensive model based approaches, a predictive and knowledge-based diagnosis can be possible also deriving from field information. The legislator is empowered to put non-maintained or defect vehicles out of service, wherefrom an improved field monitoring can be realized. Additionally legal directives such as the IUMPR (In-Use Monitoring Performance Ratio), regulating by law the amount of diagnosis within series operation, can be monitored. Also within the area of functional parameterization from engine control units, the connected vehicle can create an additional value based on automating and individualizing, since vehicle -, driver- or environmental parameter data can be constituted. Additional available functionalities, like downloading Add-on Features (e.g. increased engine power) or application-based insurance tariffs completes the full potential of utilization.

Extended Abstract

XXIII

Parameterization

Diagnosis x x x x

x x x

x

Extended signal-/ modelbased diagnosis Predictive diagnosis Knowledge based diagnosis Decommission defective vehicles (e.g. CARB OBD III) Remote exhaust investigations Remote diagnosis Field monitoring (e.g. IUMPR) ...

x x x x x

Automated parameterization Driver individual parameterization Vehicle individual parameterization Geographic parameterization ...

Series applications x

x x

x

x x

Engine OFF/Stop for wrong-way drivers (driving in pedestrian areas / driving illegally etc.) Usage based insurance tariffs Adjustment engine power (e.g. for novice drivers) via App Download of extended features (e.g. increase in engine power) ...

Since chapter three is highlighting the general possible fields of application of a connected vehicle for the engine control unit, chapter four is dedicated to the parameterization of engine control unit functionalities. Initially the chapters’ key discussion is all about the illustration of the general quality on measured data and further the importance of a reduction of these measured data, which is technically forced by the high amount of existing vehicles and the limited data rate of the mobile services. To reach this overall goal and the reduction of measured data at the connected vehicle respectively, an algorithm based on the so-called Fisher-Information is being developed. That empowers a significant reduction of measured data without losing essential information. A further advantage is to have the entire gathered measured information saved within only one matrix and to have them distributed to several vehicles. That gives base to create with several vehicles one data set without being forced to transfer the entire measured data of each singles’ vehicle. With the help of a DieselAir-System (determination of exhaust gas back-pressure with throttle model), an algorithm for having parameters determined incl. the reduction of measured data will be validated. Therein and based upon a exemplarily measurement campaign, an approval is being highlighted that using only 15% of the prototype vehicles’ derived measured data is sufficient to obtain a similar model quality as if using all data available. It has to be outlined though that the poten-

XXIV

Extended Abstract

tial of data reduction on further functionalities is dependent on different kind of factors and hence cannot be generalized. However the method gives guidance on a general proper mathematic-statistical approved projection on how measured data can be reduced and pre-filtered in an efficient way and hence an approach to contribute to an optimal utilization of the available mobile service capacities. The previously mentioned calibration process automation and the individualization of software data sets is based upon the illustrated method possible.

start ECU

VCU

data

global FIM / parameters

calculate sensitivities / local Fisher-Information

calculate parameter estimation error

no no delete measurement segment

Measurement segment informative?

yes

transmit measurement segment to cloud

quality criterion fulfilled?

optimize parameters, calculate global FIM and model quality

cloud

yes final parameters + trigger to stop

end

In chapter five key focus is set on diagnosis of the combustion engine, since derived from the cloud based solution and its high saving and computing capacity potential respectively, more efficient and more effective diagnostic methods can be applied as so far. Besides knowledge-based and predictive diagnostic methods, the possibility of computationally intensive diagnosis will be furtherly outlined. Herefor a two-staged diagnosis concept is being introduced, which can be generally reduced down to two main pillars: the failure detection and the failure diagnosis. Without an actual error detection, initially and

Extended Abstract

XXV

based on simplified criteria, the vehicles’ present system status is checked on being either error free or if having a faulty state. In case of a reasonable failure suspicion, the measured data will be provided from the vehicle to the cloud while keep applying the Fisher-based algorithm disburdening the mobile service channel. As soon as enough data are transmitted to the cloud, the current vehicle condition is being compared to a state of faultless behavior, supporting to derive from it the final failure root cause. Once the root cause is clear, the result will be re-transferred to the vehicle, empowering the system to initiate immediate specific measures. The described algorithm is being verified by a Software-in-the-Loop (SiL) simulation environment, exemplary with the help of the Diesel-Air-System. Herefor different error states of the exhaust manifold and its surroundings are being investigated: • • • • •

Defect of exhaust gas back pressure sensor Leakage within the exhaust manifold Open sticking HP-EGR valve Open sticking VTG-Actuator Closed sticking VTG-Actuator

To have a general failure impact on the system determined, the first step to go is the residual analysis. This creates the base for generating a Failure-SymptomTable, wherefrom and with the help of different criteria such as exhaust gas back pressure or HP-EGR-Valve position, specific failure cases can be derived. Furthermore the functional capability of the connected diagnosis is being verified, based on a reference measurement in form of a WLTC (Worldwide harmonized Light Duty Test Cycle). Herefor and as a first step respectively, starting from second 200 the closed loop model controlled system is being intentionally confronted with a stuck VTG-Actuator. The error detection takes assuredly place and hence is diagnosed within the illustrated scenario. The developed Fisher-information based algorithm supports consistently bowdlerizing to the necessary informative only.

XXVI

Extended Abstract

start measurement data da

ECU

end

failure detected?

diagnosis result

no

system intact

yes failure in system

reporting of failure

VCU measurement analyser informative measurement segment?

SW-package

no

delete measurement segment

yes

cloud

diagnosis coordinator nominal behaviour

failure identification

residuals

process model

parity equations

storage for informative measurement segments defective behaviour

Concluding, the dissertation points out the big potential and advantages of a connected vehicle with key focus on Car-to-Cloud networking for an engine control units’ software. This is being discussed on the one hand theoretically for the development process and on the other hand technically proven with two practical examples of parameterization and diagnosis. The challenge of having a reduced data rate transfer possibility only, which is today being limited by the condition of mobile services, receives a high degree of special attention by developing an algorithm, ensuring to transmit only the mandatory data. Moreover the examples are pointing out clearly that besides a solely data gathering also applications are conceivable having the need of a permanent

Extended Abstract

XXVII

connection to the mobile services. At the end of the elaboration it is recorded that high number of the well-established control- and diagnostic functionalities have to remain on the vehicle- or rather the engine control unit due to mandatory live data requirements. The latency period and the lack of connectivity of the mobile services are accountable for that. However the Car-to-Cloud connectivity enables to expand the functionalities that have a high potential of optimizing the development and the launched series. The Car-to-Car and the Car-to-Infrastructure communication provide additional potentials for the engine control unit and should be investigated within the scope of further research studies.

Kurzfassung Die Entwicklung von Kraftfahrzeugen wird seit einigen Jahren stetig komplexer und insbesondere in der Motorsteuergeräteentwicklung immer diffiziler. Gründe hierfür liegen unter anderem in der steigenden Anzahl von Modellvarianten und -derivaten, den verkürzten Produktlebenszyklen, den gewachsenen Kundenansprüchen, den gestiegenen Abgas- und Qualitätsanforderungen, dem hohen Kostendruck sowie der aktuell großen Anzahl an konkurrierenden Antriebskonzepten. Um all diesen Herausforderungen nachkommen zu können, müssen die aktuellen Entwicklungsprozesse überarbeitet und die vorhandenen technologischen Möglichkeiten bestmöglich genutzt werden. Dabei sind als große technologische Fortschritte in den letzten Jahrzehnten die Digitalisierung und Vernetzung zu nennen. Während der Rechnereinsatz in der Produktentwicklung ein wesentlicher Bestandteil ist, wird die Vernetzung des Kraftfahrzeugs bisher nur wenig eingesetzt. Aber auch im Serieneinsatz lassen sich Optimierungspotentiale identifizieren, insbesondere durch die Nutzung des Cloud-Computings (Car-to-Cloud). Zunächst werden potentielle Anwendungsgebiete in der Motorsteuergeräteentwicklung anhand des Standard-Entwickungsprozesses für Automotive-Software (V-Modell) abgeleitet. Dabei wird ein Augenmerk auf Themen gelegt, die über das reine Datensammeln hinausgehen und sowohl den Up- als auch Download von Daten am Fahrzeug mit einbeziehen. Die externe Rechenleistung auf einer Cloud soll ebenso Berücksichtigung finden wie die limitierte Datenrate des Fahrzeugbusses und des Mobilfunks. Anschließend werden zwei konkrete Anwendungsbeispiele mit Bezug auf das Diesel Luftsystem dargestellt. Das erste Beispiel zeigt ein Vorgehen, wodurch sich bei Nutzung des Mobilfunks der Applikationsprozess sowohl automatisieren als auch auf einzelne Fahrzeuge individualisieren lässt. Das zweite Beispiel demonstriert, dass durch die hohe Rechenleistung außerhalb des Fahrzeugs rechenintensive Diagnosekonzepte möglich sind. Beide Algorithmen haben gemeinsam, dass auf dem Fahrzeug bereits eine Messdatenreduktion stattfindet, sodass nur die relevanten Daten vom Fahrzeug an die Cloud verschickt werden müssen.

1 Einleitung Die Automobilindustrie sieht sich im Produktentstehungsprozess einer immer größer werdenden Aufgabenvielfalt gegenübergestellt. Neben der stetigen Zunahme von Fahrzeugmodellen und Fahrzeugderivaten, die durch die Märkte verlangt werden, nimmt zusätzlich die Anzahl an Neu- und Weiterentwicklungen von Antriebskonzepten zur Reduzierung von Kraftstoffverbrauch und Abgasemissionen schnell zu. Im Gleichschritt hierzu verkürzen sich die Produktlebenszyklen. Der Kundenwunsch nach mehr Leistung und mehr Komfort muss ebenso in der Entwicklung Berücksichtigung finden, wie der Kostendruck auf dem hoch umkämpften Fahrzeugmarkt. Um dennoch den hohen Qualitätsansprüchen genügen zu können, müssen die Entwicklungsprozesse weiter optimiert und die aktuellen technologischen Rahmenbedingungen bestmöglich genutzt werden. In der Literatur wird das Automobil inzwischen als das komplexeste Konsumgut beschrieben [73]. Am Beispiel heutiger Verbrennungskraftmaschinen spiegeln sich die gestiegenen Anforderungen in sehr starker Weise wieder. So sind bei aktuellen Dieselmotoren mindestens eine einstufige Aufladung, Abgasrückführung sowie eine mehrstufige Abgasnachbehandlung üblich. Durch die steigende Produkt- und Variantenvielfalt leitet sich hieraus für das Motorsteuergerät eine hohe Softwarevarianz und ein steigender Softwareumfang ab, weshalb der Bedarf an schnelleren Microcontrollern und größerem Speicher ungebrochen ist. Gleichzeitig hat der Einsatz von elektronischen Systemen und Software bis heute stetig zugenommen und stellt einen wesentlichen Innovationstreiber heutiger Kraftfahrzeuge dar. Die aktuelle Computertechnik ermöglicht es, den Software-Entwicklungsprozess zu überarbeiten und effizienter zu gestalten. Dabei zählt zu den größten Erfindungen der Neuzeit zweifelsohne das Internet und der Mobilfunk. Der nahezu unbeschränkte Zugriff auf Daten und Informationen sowie die ständige Erreichbarkeit und Vernetzung hat in vielen Gebieten das Leben der Menschen verändert. Dabei wird aktuell unter dem © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 L. Hagen, Neue Möglichkeiten für die Motorsteuergeräte- Software durch Car-to-Cloud-Vernetzung, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-31565-8_1

2

1 Einleitung

Schlagwort IoT – Internet of Things – die Vernetzung von alltäglichen Gegenständen verstanden, wodurch neben den etablierten Produkten wie Mobiltelefon oder PC weitere Produktfelder für die Vernetzung erschlossen werden. Auch in der Automobilindustrie wird die Vernetzung von Kraftfahrzeugen vorangetrieben. Schätzungen zu Folge werden bis 2020 bereits 90 % aller neu zugelassenen Fahrzeuge vernetzt sein [85] und erste vernetzte Funktionen bereitstellen. So informieren etwa Notrufassistenten nach einem Unfall den Rettungsdienst (e-call) oder es lassen sich Medieninhalte wie Videos oder Musik auf das Fahrzeugdisplay “over the air” übertragen. Dennoch schreitet die Digitalisierung und Vernetzung im automobilen Sektor nur schleppend voran [31], obwohl sie auch für die SW-Entwicklung und in Serienapplikationen von (Motor-)steuergeräten eine Fülle von Möglichkeiten bietet, welche bislang nicht oder unzureichend genutzt werden. Die vorliegende Arbeit verfolgt das Ziel, mögliche Anwendungspotentiale für die mobile Vernetzung des Motorsteuergeräts in Entwicklung und Serie aufzudecken und deren Vorteile herauszuarbeiten. Hierbei liegt der Fokus auf Car-to-Cloud, also der Verbindung des Fahrzeugs zu einer Cloud bzw. einem Server. Anhand der zwei Arbeitspakete Applikation/Parametrierung und Diagnose werden entsprechende Beispiele für das Gebiet des Diesel-Luftsystems vorgestellt. In Kapitel 2 werden zunächst die theoretischen Grundlagen dargestellt. Dies umfasst die benötigten Hardwarekomponenten, um die Verbindung von Steuergerät und Mobilfunk herzustellen. Hierbei kommt ein wesentlicher Aspekt dieser Technologie zum Vorschein, welcher aktuell in allen Anwendungsfällen des vernetzten Fahrzeugs Berücksichtigung finden muss: die limitierte Datenrate des Mobilfunks. Es lassen sich nicht beliebig viele Daten in endlicher Zeit transferieren, sodass eine geeignete Vorauswahl entweder auf dem Fahrzeug für den Upload oder auf der Cloud für den Download erfolgen muss. Es wird eine effiziente Methode zur anwendungsspezifischen Datenreduktion zur Entlastung des Mobilfunkkanals gezeigt, ebenso die Grundlagen zum Diesel-Luftsystem. Insbesondere soll auf die Parametrierung von modellbasierten Funktionen und die Diagnose des Luftsystems eingegangen werden. Abschließend wird der StandardEntwicklungsprozess für Software in der Automobilindustrie (V-Modell) dargestellt, um daran Möglichkeiten des vernetzten Fahrzeugs für die SteuergeräteEntwicklung abzuleiten.

1 Einleitung

3

Ein wesentlicher Bestandteil der heutigen Motorsteuergeräte-Entwicklung besteht in der Parametrierung von Funktionsparametern, um die Funktionalitäten für verschiedene Motorenprojekte nutzbar zu machen. Jedoch ist die Parametrierung mittlerweile aufgrund der steigenden Komplexität der Funktionalitäten nur mit dem Einsatz hoch entwickelter Parametriermethoden darstellbar [41]. Durch die Hardware des vernetzten Fahrzeugs lässt sich der Applikationsprozess prinzipiell automatisieren. Somit ist es möglich, die stetig wachsende Anzahl von Applikationsaufgaben besser zu beherrschen. Außerdem besteht die Möglichkeit, Datensätze auf einzelne Fahrzeuge oder Fahrzeuggruppen "maßzuschneidern", da bei einem vernetzten Fahrzeug im Grunde zu jeder Zeit und an jedem Ort auf das Steuergerät zugegriffen werden kann, sofern Mobilfunkkonnektivität gegeben ist. Hierdurch könnte sich die Applikationsgüte verbessern, wodurch weitere Potentiale zur Optimierung des Motorbetriebs erschlossen werden. In Kapitel 4 wird ein Algorithmus vorgestellt, der einerseits die über den Mobilfunk zu übertragende Datenmenge an Messdaten reduziert und andererseits die Parametrierung automatisiert durchführen kann. Der Algorithmus ist für ein oder mehrere Fahrzeuge anwendbar. Die Diagnose des Gesamtsystems Motor macht etwa 50 % des Softwareumfangs eines Motorsteuergeräts aus [52]. Dabei lässt sich die Diagnose hauptsächlich in die On-Board-Diagnose und die Werkstattdiagnose unterteilen. In beiden Gebieten stellt das vernetzte Fahrzeug ebenfalls eine Reihe von Möglichkeiten bereit, sei es durch das Verlagern von Diagnosen von der Werkstatt auf das Fahrzeug oder das Ermöglichen rechenintensiver Diagnosen auf der Cloud. Auch ist der Abgleich von möglichen Fehlfunktionen der gesamten Fahrzeugflotte möglich. In Kapitel 5 wird ein Algorithmus vorgestellt, der die hohe Rechenleistung der Cloud gewinnbringend einsetzt. Abschließend wird ein Fazit gezogen und künftige Forschungsmöglichkeiten aufgezeigt.

2 Stand der Technik

2.1 Hardware des vernetzten Fahrzeugs Zur Datenübertragung zwischen Fahrzeug und Umgebung ist die Verbindung mehrerer Hardwareelemente notwendig. Dabei hat sich auf Fahrzeugseite seit Beginn der 90er Jahre der CAN-Bus insbesondere für zeitkritische Anwendungen etabliert. Hierüber tauschen verschiedene Steuergeräte, etwa das Motorund Fahrdynamik-Steuergerät, Informationen miteinander aus. Durch Integration eines Mobilfunk-Modems an den CAN-Bus (hier in Form eines mobilfunkfähigen Domänenrechners mit fest verbauter SIM-Karte mit dem Namen Vehicle Control Unit (VCU)) kann die Kopplung des Fahrzeugs an den Mobilfunk erfolgen. Im Falle der Vernetzung des Fahrzeugs mit einer IT-Infrastruktur, wird dies oft Car-to-Cloud genannt, Abb. 2.1.

Cloud

CAN ECU VC VCU CU C U



Abbildung 2.1: Mögliche Hardware-Realisierung für Car-to-Cloud © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 L. Hagen, Neue Möglichkeiten für die Motorsteuergeräte- Software durch Car-to-Cloud-Vernetzung, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-31565-8_2

6

2 Stand der Technik

Neben der hier dargestellten Hardware-Konfiguration kann auch eine SIMKarte des Fahrers zur Herstellung der Internetverbindung eingesetzt werden (Tethering [44]). Dafür wird i.d.R. ein Mobiltelefon mit dem Fahrzeug via Bluetooth gekoppelt.

2.1.1 Elektronisches Motorsteuergerät Das Verhalten heutiger Verbrennungsmotoren hängt maßgeblich von dem verbauten elektronischen Motorsteuergerät (Electronic Control Unit (ECU)) ab und beeinflusst den Start, Leer- und Warmlauf sowie normalwarmen Motorbetrieb in Teil- und Volllast [39]. Hierfür empfängt das Steuergerät analoge oder digitale Signale der Sensoren, wertet diese aus und berechnet die Ansteuersignale für die Aktoren. In Abb. 2.2 ist dies exemplarisch für die Hauptgrößen des Diesel-Luftsystems dargestellt. Insgesamt verarbeitet ein Motorsteuergerät bei heutigen Dieselmotoren etwa 15-25 Sensorgrößen und stellt etwa 20-30 Stellgrößen ein [41]. Darüber hinaus gehört die Diagnose des Verbrennungsmotors zu den Grundumfängen der Motorsteuerung [66]. Sensoren

Saugrohrdruck Frischluftmassenstrom Gastemperatur nach LLK Gastemp. nach (ND-)AGR-Kühler Differenzdrucksensor ND-AGR Umgebungstemperatur Umgebungsdruck

Aktoren

Steuergerät

Luftsystem Software (Regelung, Steuerung, Diagnose)

VTG

Aktor

AGR

Ventil

ND-AGR

Ventil

Drosselklappe Abgasklappe Diagnose

Abbildung 2.2: Hauptgrößen der Motorsteuerung des Diesel-Luftsystems Ein Motorsteuergerät besteht im Wesentlichen aus einem Mikroprozessor, verschiedenen Speicherbausteinen, einem Taktgeber (Oszillator) sowie Kommunikationsschnittstellen zu Sensoren, Aktoren und Datenbussen. In Abb. 2.3 ist

2.1 Hardware des vernetzten Fahrzeugs

7

der prinzipielle Aufbau eines Motorsteuergeräts dargestellt. Der Mikroprozessor, welcher aus einem Rechen- und Steuerwerk besteht, ist das Herzstück des Steuergeräts und ist für die Abarbeitung des Steuergeräteprogramms zuständig. Dabei hat er Zugriff auf einen Daten- und Programmspeicher. Der flüchtige Datenspeicher verliert bei Abschalten der Spannungsquelle seine Daten (RAM: Random Access Memory). Der Programmspeicher hingegen ist nichtflüchtig und meist als Flash-EPROM (Erasable Programmable Read-Only Memory) ausgeführt. Im elektrisch wiederbeschreibbaren EEPROM werden Daten gespeichert, die über mehrere Fahrzyklen hinweg benötigt werden, wie z.B. Adaptionswerte. Der Datenaustausch mit Sensoren und Aktoren geschieht über verschiedene Schnittstellen wie beispielsweise A/D-Wandler oder digitale Schnittstellen wie z.B. das SENT - Interface. Außerdem tauscht das Motorsteuergerät Daten mit weiteren Steuergeräten oder sonstiger Peripherie über Datenbusse wie CAN, Flexray oder Ethernet aus.

Mikrocontroller Mikroprozessor

Programmspeicher

Datenspeicher

Rechenwerk

Nichtflüchtiger Lesespeicher (Flash EPROM)

Nichtflüchtiger & flüchtiger Schreib-/ Lesespeicher (RAM / EEPROM)

Steuerwerk

Ein- & Ausgabeeinheiten

Ein-/Ausgabe

Abbildung 2.3: schematischer Aufbau eines Steuergeräts

8

2 Stand der Technik

Abbildung 2.4: MDG1 Motorsteuergerät (Quelle: Bosch)

Zu Beginn der 1990er Jahre hatte ein Motorsteuergerät 32 kByte Programmspeicher, 8 kByte Datenspeicher und 12 Mhz Taktfrequenz [67]. Aufgrund der steigenden Anforderungen hinsichtlich Emission, Verbrauch, Leistung und Komfort nahm und nimmt der Funktionsumfang und damit der Speicherbedarf sowie die Datenverarbeitungsgeschwindigkeit stetig zu. Mittlerweile werden die von den Personal Computern bekannten Mehrkernprozessoren eingesetzt (Multicore CPUs). In Tab. 2.1 sind die Leistungsdaten eines aktuellen MDG1Motorsteuergeräts von Bosch für ein Kompaktklasse-Fahrzeug dargestellt. Tabelle 2.1: Leistungsdaten MDG1 Device 4 - Motorsteuergerät von Bosch Tri Core mit 300 MHz Taktfrequenz 512 kByte RAM (Datenspeicher) 8 MByte Flash-EEPROM (Programmspeicher) 128 kByte EEPROM 5x CAN, 2x Flexray, 60 ADC Inputs, 15x SENT, 1x Ethernet

2.1.2 CAN - Bus Der CAN-Bus (Controller Area Network) ist ein von Bosch entwickelter linearer Datenbus, welcher 1991 erstmals in einem Kraftfahrzeug in Serie eingesetzt wurde [64]. Seither ist er Standard im Automobilbereich und stellt das am

2.1 Hardware des vernetzten Fahrzeugs

9

häufigsten eingesetzte Kommunikationssystem dar [79]. Der Grund für die Entwicklung des CAN-Busses lag in der gestiegenen Anzahl von elektronischen Modulen, dessen Verkabelung mit herkömmlichen Methoden kaum noch zu bewältigen war [40]. Dieser Trend ist bis heute zu beobachten, denn die Anzahl von Steuergeräten auf aktuellen Fahrzeugen geht mittlerweile bis in den dreistelligen Bereich. Beim CAN-Bus handelt es sich um einen seriellen Datenbus, wodurch die Daten auf einer Leitung und nicht parallel auf mehreren Leitungen übertragen werden. Man spricht hierbei auch von einer halb-duplexen Datenübertragung [87]. Dies hat den Vorteil, dass längere Datenleitungen möglich sind und der Kabelaufwand gleichzeitig gering gehalten werden kann [40]. Prinzipiell unterscheidet man zwischen dem so genannten Highspeed- und Lowspeed-CAN. Der Highspeed-CAN (CAN-C) ist in der ISO-Norm 11898-2 festgehalten und mit Übertragungsraten von 125 kBit/s bis zu 1 MBit/s spezifiziert. In der Praxis sinkt die maximale Übertragungsrate jedoch auf 500 kBit/s [8], welche maßgeblich von der Buslänge und der Busauslastung abhängt. Üblicherweise wird der Highspeed-CAN für zeitkritische Anwendungen wie etwa dem Motormanagement oder der Fahrdynamikregelung eingesetzt. Der Lowspeed-CAN (ISO 11898-3) wird hingegen häufig für Anwendungen mit geringeren Zeitanforderungen genutzt, beispielsweise im Karosseriebereich. In Abb. 2.5 ist schematisch ein Highspeed-CAN dargestellt, welcher meist als Zweidrahtleitung mit verdrillten (Twisted-Pair) oder unverdrillten Adern ausgeführt wird [67]. Die beiden Busleitungen werden hierbei als CAN_High und CAN_Low bezeichnet. Über sie können verschiedene Spannungspegel übertragen werden, wodurch eine dominante 0 und eine rezessive 1 darstellbar sind. Der Bus muss an beiden Enden zur Vermeidung von Reflexionen mit dem Wellenwiderstand der Zwei-Draht-Leitung abgeschlossen werden, welcher ca. 120 Ω beträgt [87]. Sollen im zuvor beschriebenen Hardwareverbund Daten des Motorsteuergeräts zur VCU übertragen werden, hängt die Übertragungsgeschwindigkeit maßgeblich von den verwendeten CAN-Controllern und der maximalen Mikrocontrol-

10

2 Stand der Technik

ler- bzw. CPU-Last ab. Aber es spielen auch Faktoren wie Buslast oder Anzahl der Bus-Teilnehmer eine Rolle.

ECU 1

ECU 2

—&

—&

CAN Controller

CAN Controller

Transceiver

Transceiver

120

VCU —& ...

CAN Controller

Transceiver

120

Abbildung 2.5: Highspeed-CAN

Zukünftige Anforderungen werden eine höhere Nutzdatenrate des FahrzeugDatenbusses benötigen. Hierzu ist der CAN-FD (Flexible Data-Rate) entwickelt worden, welcher längere Botschaften und einen höheren Bittakt ermöglicht (ISO 11898-1:2015). Somit werden bis zu 4 MBit/s Datenrate möglich. Der Flexray-Bus stellt ebenfalls eine Alternative für zukünftige Anforderungen dar, aber er konnte bislang noch nicht alle Hoffnungen erfüllen [87]. Ein weiterer Technologiesprung ist über Ethernet-Verbindungen möglich, welche eine weitere Erhöhung der Übertragungsgeschwindigkeit leisten können (>10 MBit/s). Der Datenbus ist ein limitierender Faktor in der Datenübertragung zwischen Motorsteuergerät und Cloud, welcher Beachtung finden muss. Im Vergleich zur Mobilfunkanbindung sind die Datenraten und die Verfügbarkeit aufgrund der Kabelverbindungen aber prinzipbedingt höher.

2.1 Hardware des vernetzten Fahrzeugs

11

2.1.3 VCU - Vehicle Control Unit Bislang sind E/E-Architekturen im Automobilbereich meistens in einer evolutionären Weise mit Fokus auf lokale Lösungen designt worden [80]. Nun jedoch geht der Trend aufgrund neuer Domänen-übergreifender Funktionen - insbesondere in den Bereichen Fahrerassistenz und autonomes Fahren - weg von lokalen Einzelsteuergeräten hin zu Domänen-Steuergeräten [47]. Die Gründe hierfür liegen einerseits im Bedarf an hoher Rechenleistung und Speicherkapazität für neuartige Funktionen. Gleichzeitig möchten Fahrzeughersteller die Anzahl an Steuergeräten möglichst reduzieren, um den höheren Kosten für Einzelsteuergeräte, deren aufwendiger Verkabelung sowie deren Bauraumbedarf entgegenzuwirken. Auch die Standardisierung der Software - Architektur (z.B. durch AUTOSAR) und die hohe Variantenvielfalt sprechen für Domänen-Steuergeräte [78]. Dieser Trend könnte sich in Zukunft zu Domänenübergreifenden Steuergeräten weiter fortsetzen. Nächste Evolutionsstufe stellt ein Zentralrechner auf Fahrzeugebene dar, sowie die Verlegung von Funktionen in die Cloud [55], siehe Abb. 2.6.

Abbildung 2.6: Evolution / Revolution von E/E Architekturen [55]

12

2 Stand der Technik

Die Vehicle Control Unit (VCU) ist eine Neuentwicklung der Robert Bosch GmbH und stellt einen Domänenrechner dar. Im Gegensatz zu einem klassischen Motorsteuergerät bietet eine VCU eine höhere Rechenleistung und Speicherkapazität, eine Vielzahl von Bus-Interfaces sowie eine Mobilfunkanbindung. Durch diese Eigenschaften bietet die VCU weitere Freiheitsgrade für die automobile Software-Entwicklung (z.B. für Software-Architektur oder Funktionalität). Tabelle 2.2: Leistungsdaten Bosch VCU-Performance 4x A53 ARM Cores 1-2 GByte RAM ≥16 GByte Flash LTE, WiFi, Ethernet 1 GBit/s, Flexray, CAN-FD, LIN

Abbildung 2.7: VCU-P Domänenrechner (Quelle: Bosch)

2.1.4 Mobilfunk Der Durchbruch der mobilen Kommunikation gelingt Anfang der 90er Jahre mit GSM (Global System for Mobile Communication), welches im Jahr 2010 mit über 100 Millionen Anschlüssen alleine in Deutschland eine flächendeckende Verbreitung verzeichnen kann [71]. Dabei stellt GSM ein System dar, dessen Fokus auf der Sprachübermittlung liegt und nur begrenzt zur Datenübermittlung geeignet ist. Die Übertragung von Datenpaketen ist jedoch die Grundlage des Internets, wodurch 2001 in Deutschland GPRS (General Packet Radio

2.1 Hardware des vernetzten Fahrzeugs

13

Service) eingeführt wird [86]. Zur weiteren Erhöhung der Datenrate wird kurze Zeit später EDGE (Enhanced Data Rates for GSM Evolution) standardisiert. Parallel hierzu setzt sich zu Beginn des 21. Jahrhunderts in Wirtschaft und Politik die Meinung durch, ein multimediafähiges Mobilfunk-Datennetz zu entwickeln, um den Bedarf an neuen Diensten und Übertragungskapazitäten zu decken [84]. Dieses baut als dritte Mobilfunkgeneration (3G) auf GSM/GPRS auf und trägt den Namen UMTS (Universal Mobile Telecommunication System). Als 3,5G wird HSPA (High-Speed Packet Access) bezeichnet, welches seit 2006 kommerziell verfügbar ist [84] und eine weitere Steigerung der Übertragungsgeschwindigkeit erzielt. Darauf folgend spezifiziert das Relase08 des 3rd Generation Partnership Project (3GPP) das Mobilfunksystem LTE (Long Term Evolution), welches auch langfristig Weiterentwicklungspotential bieten soll [9]. Der 5G-Standard ermöglicht zukünftig eine noch höhere Bandbreite und schnellere Datenübertragung, welche bis zu 100-mal höher als die von LTE-Netzen sein soll (bis zu 10.000 MBit/s) [34]. Tabelle 2.3: theoretische Übertragungsgeschwindigkeiten des Mobilfunks GPRS (2,5G) 53,6 Downlink kBit/s 26,8 Uplink kBit/s

EDGE (2,75G) 236 kBit/s 118 kBit/s

UMTS (3G) 384 kBit/s 128 kBit/s

HSPA (3,5G) 14,4 MBit/s 5,76 MBit/s

LTE (4G) 300 MBit/s 75 MBit/s

Da LTE den heutigen technologischen Standard darstellt, soll dieses kurz beschrieben werden.

14

2 Stand der Technik

Internet

Kernnetzwerk (EPC)

Zelle

eNodeB

Abbildung 2.8: LTE Systemarchitektur

Generell ist LTE ein paketvermittelndes Übertragungsverfahren und basiert als erstes Verfahren ausschließlich auf dem Internet-Protokoll (IP) [71]. Von der Systemarchitektur besteht ein LTE-Netzwerk aus den UEs (User Equipment), also den mobilen Endgeräten (z.B. Mobiltelefone oder vernetzte Fahrzeuge), den Basisstationen (eNodeB) sowie dem daran angeschlossenen Kernnetzwerk (EPC - Evolved Packet Core). Die Basisstationen decken hexagonale Zellen ab, siehe Abb. 2.8. Im Vergleich zu UMTS bietet LTE eine deutlich höhere maximale Übertragungsgeschwindigkeit von bis zu 300 MBit/s im Downlink und 75 MBit/s im Uplink. Dies wird durch das Übertragungsverfahren OFDM (Orthogonal Frequency Division Multiplexing) erzielt, wodurch die gesamte Bandbreite auf mehrere kleine Einheiten aufgesplittet wird [86]. Außerdem muss ein LTE Gerät MIMO (Multiple Input Multiple Output) unterstützen, wodurch mehrere Datenströme über den gleichen Kanal übertragen werden können [71]. Im Release08 des 3GPP sind außerdem eine Latenzzeit von 5 ms, eine UEGeschwindigkeit bis zu 350 km/h sowie ein maximaler Zellenradius von 100 km spezifiziert [2]. In der Praxis werden die theoretischen Übertragungsgeschwindigkeiten aufgrund der folgenden Gründe allerdings selten erreicht:

2.1 Hardware des vernetzten Fahrzeugs

15

• der Anzahl der mobilen Endgeräte in einer Zelle und des damit verbundenen Datenaufkommens. Die Datenleitungen werden bei zellulären Netzwerken geteilt. • der Entfernung zur Basisstation, Hindernissen im Übertragungspfad sowie der Atmosphäre (Regen, Nebel, Schnee) [61] • der Mobilität (z.B. Geschwindigkeit des Fahrzeugs) und Störungen aufgrund Interferenz von Nachbarzellen [71] So wird beispielsweise in einem Feldversuch in der Nähe der deutschen Stadt Dortmund mit LTE auf der A40 eine mittlere Datenrate von 482,1 kBit/s bei freiem Verkehrsfluss erreicht. Diese wird bei Stau auf ein Siebtel reduziert [62]. Die Anforderungen an die Mobilfunkkommunikation sind je nach Anwendung im Automotive-Umfeld sehr unterschiedlich. Die Hauptaspekte, die Berücksichtigung finden müssen, sind die Übertragungsgeschwindigkeit, das Datenvolumen, die Latenzzeit sowie die Verfügbarkeit. So werden in heutigen Kraftfahrzeugen bereits sehr große Datenmengen produziert, denn alleine im Motorsteuergerät werden mehrere tausend Variablen mit einer Abtastrate von wenigen Millisekunden berechnet. Je nach Messumfang können so über ein Gigabyte Daten pro Sekunde generiert werden [3]. Es wäre daher weder praktikabel noch bezahlbar, große Datenmengen permanent bzw. ohne Vorfilterung über die Luftschnittstelle zu verschicken [85]. Somit ist ein wesentlicher Erfolgsfaktor für die Vernetzung des Fahrzeugs die Reduktion der zu übertragenden Daten, die Anwendungsfall-spezifisch ausgewählt und gefiltert werden müssen. Hierfür sind intelligente Datenübertagungsansätze notwendig [35]. Aber auch die Latenzzeit und Verfügbarkeit hat insbesondere für sicherheitskritische Anwendungen einen hohen Stellenwert.

2.1.5 Car2X-Kommunikation Car2X (oder auch V2X (Vehicle-to-Everything) genannt) bezeichnet die Kommunikation eines Fahrzeugs mit seiner Umgebung, wobei das “X” für Car, Infrastruktur oder andere Dinge stehen kann [44]. Im Folgenden werden die typischen Verbindungsarten des Fahrzeugs mit der Umgebung erläutert:

16

2 Stand der Technik

Car-to-Cloud Kommunikation des Fahrzeugs zu einer IT-Infrastruktur (im Sprachgebrauch Cloud), die Daten speichern, verwalten und auswerten kann. Die Cloud stellt auch Informationen von “Content-Providern” zur Verfügung, etwa Verkehrsinformationen oder Wetterdaten [44]. Car-to-Car Kommunikation zwischen zwei oder mehr Fahrzeugen. Car-to-Infrastructure Kommunikation zwischen Fahrzeug und der Infrastruktur, z.B. Ampeln oder Verkehrsleitsystemen. In dieser Arbeit wird der Fokus auf die Car-to-Cloud-Kommunikation gelegt.

2.1.6 Cloud-Computing Um den stetig wachsen Bedarf an Speicherkapazitäten und Rechenleistung zu decken, ist ein möglicher Ansatz im Cloud Computing zu sehen [68]. Dabei gibt es für das Cloud Computing keine einheitliche Beschreibung, aber eine oft zitierte Definition stellt das NIST (National Institute of Standards and Technology) der Vereinigten Staaten von Amerika bereit [51]: Cloud Computing ist ein Modell, welches universellen und komfortablen Zugriff auf einen Pool von IT-Ressourcen ermöglicht (z.B. Netzwerke, Rechenleistung, Speicherplatz, Anwendungen und Dienste) und dabei mehreren Nutzern zur Verfügung steht. Die Ressourcen können schnell und mit minimalem Aufwand skaliert werden, ohne dass hierbei eine menschliche Interaktion notwendig wäre. Wesentlich für das Cloud Computing sind außerdem der “on-demand” - Gedanke, die Skalierbarkeit der IT-Ressourcen nach oben und unten (Elastizität), die Online-Verfügbarkeit sowie die externe Verwaltung der IT-Ressourcen [27]. Außerdem lässt sich das Cloud-Computing klassifizieren in [51]:

2.2 Dieselmotor und Luftsystem

17

• Infrastructure-as-a-Service (IaaS) Bereitstellung von IT-Infrastruktur wie Speicher oder Rechenleistung. Der Nutzer kann selbst über das Betriebssystem und die Anwendersoftware verfügen. • Platform-as-a-Service (PaaS) Bereitstellung einer Entwicklungsplattform. Dem Nutzer (Entwickler) werden Tools, Bibliotheken und Dienste zur Verfügung gestellt. • Software-as-a-Service (SaaS) Bereitstellung einer web-basierten Software. Der Nutzer kann diese direkt anwenden. Weiterhin lässt sich das Cloud Computing durch seine Organisationsform klassifizieren (private, public, hybrid) [51], also ob die Cloud öffentlich, nicht öffentlich oder teilweise öffentlich ist. Das Cloud Computing ermöglicht verschiedene Vorteile zur agilen Entwicklung neuer Mobilitätskonzepte für Automobilhersteller und Zulieferer, welche bereits durch zahlreiche Unternehmen genutzt werden [28].

2.2 Dieselmotor und Luftsystem Der Dieselmotor, erfunden von Rudolf Diesel in den Jahren 1893-1897 unter dem Namen "rationelle Wärmekraftmaschine"[5], ist eine Wärmekraftmaschine und gehört zur Gruppe der Kolbenmaschinen. Hierbei wird die im Kraftstoff gespeicherte chemische Energie durch Verbrennung in mechanische Energie in Form einer Rotationsbewegung der Kurbelwelle umgewandelt [15]. Wesentliche Merkmale für den Dieselmotor sind die Selbstzündung, die innere Gemischaufbereitung und die Qualitätsregelung [4].

18

2 Stand der Technik

Abbildung 2.9: Das Luft- und Abgassystem eines aktuellen Dieselmotors

Das Luftsystem des modernen Dieselmotors umfasst die Strecke vom Luftfilter bis zu den Einlassventilen, wobei die Abgasrückführungen nach bzw. vor Verdichter (Hochdruck- bzw. Niederdruck-AGR) mit zum Luftpfad gezählt werden können, siehe Abb. 2.9. Dementsprechend umfasst das Luftsystem im Wesentlichen den Luftfilter, den Heißfilmluftmassenmesser (HFM), die Verdichterseite des Turboladers, die AGR- und Drosselventile, die Ladeluft- und AGR-Kühler, die Temperatur- bzw. Drucksensoren sowie die Verrohrungen. Das Luftsystem hat einen wesentlichen Einfluss auf Verbrauch, Emissionen und Leistung des Gesamtmotors. Zunächst strömt die angesaugte Frischluft durch den Luftfilter, in dem der Luft Partikel und mineralische Stäube entzogen werden, welche somit nicht in den Motor oder das Motoröl gelangen können [66]. Dies ist notwendig, da neben reduziertem Verschleiß verschiedener Motorbauteile auch Partikelablagerungen auf dem HFM das Messsignal verfälschen können, wodurch sich Emissionen und Motorleistung verschlechtern können [5]. Falls eine Niederdruck Abgasrückführung vorhanden ist, wird der Frischluft vor Verdichtereintritt ein Teil des Abgases beigemischt, wodurch sich die Brennraumtemperatur verringert. Dies hat wiederum zur Folge, dass die Stickoxid-Emissionen reduziert werden. Jedoch verringert sich durch diese Maßnahme auch die maximal mög-

2.2 Dieselmotor und Luftsystem

19

liche Motorleistung, da dem Motor nicht die größtmögliche Sauerstoffmenge zur Verbrennung zur Verfügung steht. Durch Verdichtung des Gasgemisches durch den Kompressor erreicht der Dieselmotor ein höheres Leistungsniveau, da sich die Dichte des Gases in Folge des höheren Drucks erhöht und somit prinzipiell mehr Luftmasse zur Verbrennung in die Zylinder einströmt. Um die damit verbundene Aufheizung des Gases wieder zu verringern, wird dem Verdichter ein Ladeluftkühler nachgeschaltet. Dieser ermöglicht somit vor allem eine größere Lufteinbringung in die Zylinder, bietet aber auch Vorteile hinsichtlich einer geringeren thermischen Belastung der Bauteile und einer verminderten Stickoxidbildung [53]. Die Drosselklappe kann dazu eingesetzt werden, die (Frisch-)luftzufuhr zu verringern oder um die Hochdruck(HD)-AGR-Rate in Folge des höheren Druckgefälles über die HD-AGR-Leitung zu erhöhen. Nach Beimischung eines weiteren Teils des Abgases über die HD-AGR und ggf. einer Verwirbelung durch eine Drallklappe, strömt das Gasgemisch anschließend in die Zylinder, wo es dann mit dem Kraftstoff verbrannt wird.

2.2.1 Physikalische Grundlagen und Modellierung Um die steigende Komplexität heutiger Verbrennungsmotoren beherrschen zu können, werden in der Entwicklung und auf dem Motorsteuergerät mathematische Modelle eingesetzt. Diese dienen zum Systementwurf, zur Automatisierung, Überwachung, Fehlererkennung und Diagnose sowie zum Entwurf von Reglern [11]. Dies hat hauptsächlich zwei Gründe. Einerseits entsteht eine Kostenersparnis, da Sensoren durch entsprechende Modelle ersetzt werden können. Anderseits lassen sich manche Systemgrößen, welche zur Regelung und Steuerung benötigt werden, nur sehr ungenau, gar nicht oder nur indirekt bestimmen. Als Beispiele seien hier der Restgasanteil im Zylinder nach dem Ausschiebe-Takt (innere AGR) oder die Temperaturen der Einlassventile erwähnt. Grundsätzlich lassen sich drei Modellarten unterscheiden: • white-box-Modelle: Bei dieser Modellart wird sich auf z.B. physikalische, chemische, thermodynamische Gesetzmäßigkeiten gestützt, dessen Struktur auf die des Prozesses angepasst ist [11] [13]. Die Modellbildung von whitebox-Modellen wird auch theoretische Modellbildung genannt [41], wobei keine Messdaten notwendig sind [11]. Der wesentliche Vorteil dieser Model-

20

2 Stand der Technik

lart besteht in der guten Verständlichkeit und guten Extrapolationsfähigkeit. Außerdem muss zur Modellbildung kein reales System existieren [13]. Ein Nachteil kann in der aufwendigen Modellbildung gesehen werden, die von der Komplexität des betrachteten Prozesses abhängt. • black-box-Modelle: Der Entwurf von black-box-Modellen wird auch experimentelle Modellbildung oder Identifikation genannt, wobei das System anhand der Ein- und Ausgangssignale beschrieben wird [41]. Die inneren Zusammenhänge des Modells sind hierbei unbekannt. Vorteil dieser Modellart sind die schnelle Modellbildung, jedoch hängt die Modellgüte in starkem Maße vom Messumfang ab. Die Modellgenauigkeit in Bereichen, in denen das Modell nicht angelernt wurde, ist meist eher schlecht. Außerdem muss das zu beschreibende System im Gegensatz zu den white-box Modellen real existieren [37]. • grey-box-Modelle: Grey-box-Modelle stellen eine Kombination der beiden zuvor genannten Modellarten dar. Es kann also Vorwissen über den Prozess in die Modellbildung mit eingebracht werden, wodurch das Modell leichter zu interpretieren ist als ein reines black-box-Modell [60]. Es wird von light-grey-box Modellen gesprochen, wenn nur die Parameter aus Messdaten gewonnen werden, und von dark-grey-box Modellen, wenn die Messdaten unter zur Hilfenahme von Vorwissen erzeugt werden, das Modell selber aber den Prinzipien eines black-box-Modells entspricht [56]. Modelle lassen sich weiterhin in verschiedene Modelltypen unterteilen. Bekannte Vertreter hierfür sind Kennfeldmodelle, Polynommodelle, neuronale Netze oder Gauss-Prozess-Modelle. Zwei weitere Merkmale jedes Modells sind außerdem die Modellstruktur sowie die Modellparameter. Die Struktur eines Modelles beinhaltet die generellen Eigenschaften wie den Typ oder die Ordnung des Modells [11]. Die Parameter gewährleisten die Anpassbarkeit eines Modells für verschiedene Anwendungsfälle. Weitere Kategorien zur Einteilung von Modellen sind die Eigenschaften parametrierbar/nicht parametrierbar, lokal/global gültig sowie stationär/dynamisch [11].

2.2 Dieselmotor und Luftsystem

21

2.2.2 Füll- und Entleermethode 0-dimensionale Modelle, die auf der Füll- und Entleermethode basieren, können zur Simulation transienter Vorgänge eines Diesel-Motors verwendet werden [63]. Charakteristisch für diese Modellart sind die abgegrenzten Volumen, deren Gasmassen über der Zeit ansteigen oder abfallen [32]. Neben den Volumen, welche Energiespeicher darstellen, werden Bauteile wie Ventile oder Filter als Drosselstellen modelliert. Weiterhin gilt als Annahme, dass sich die Gase ideal verhalten [30] und perfekt durchmischen. Mit den Gleichungen zur Massen- und Energieerhaltung, gekoppelt mit Informationen über die ein- und ausfließenden Massenströme (z.B. durch quasi-stationäre Durchflussgleichungen) ist letztlich der Gaszustand (Temperatur und Druck) in den Kontrollvolumina bestimmbar [32]. Modelle der Füll- und Entleermethode haben eine hohe mathematische Komplexität und eine eingeschränkte Berechnungszeit [63]. Somit sind sie zur Berechnung auf dem Steuergerät nur bedingt geeignet. Mittelwertmodelle, die auf der Füll- und Entleermethode basieren, sind in der Praxis seit Jahren weit verbreitet und werden häufig für Fragestellungen im Luft- und Abgassystem eingesetzt (z.B. [19], [24], [76], [77]).

2.2.3 Drosselgleichung Bei der so genannten Drosselgleichung handelt es sich um die mathematische Formulierung der Zustandsänderung eines idealen Gases über ein drosselndes Element wie etwa dem AGR-Ventil, siehe Abb. 2.10. A1

A2

T1 p1 w1

p1 > p2 w2 >> w1

Abbildung 2.10: Strömung an Drosselelement

T2 p2 w2

22

2 Stand der Technik

Basierend auf der Bernoulli-Gleichung in Energieform mit Berücksichtigung von Temperatur- und Dichteänderung für Gase, 0 p w2 >+ cv · T = const.  + + gH ρ 2

Gl. 2.1

der Anwendung des idealen Gasgesetzes, p = RT = (c p − cv ) · T ρ

Gl. 2.2

der Isentropengleichung für ideale Gase T2 = T1



p2 p1

 κ−1 κ

Gl. 2.3

sowie der Kontinuitätsgleichung m˙ = A1 · w1 · ρ1 = A2 · w2 · ρ2 = const. erhält man nach einigen Umformungen die Drosselgleichung:    p2 2 m˙ = Ae f f · p1 · ·Ψ R · T1 p1

Gl. 2.4

Gl. 2.5

In dieser Gleichung ist Ψ die so genannte Durchflussfunktion, welche vom Druckverhältnis Π = pp21 über das drosselnde Element sowie dem Isentropenexponenten κ abhängt, siehe Gl. 2.6.  Ψ

p2 p1



   2   κ+1   κ p2 κ p2 κ · − = κ −1 p1 p1

Gl. 2.6

Die Durchflussfunktion hat ein Maximum bei ΠCrit und ΨCrit :  ΠCrit =

ΨCrit =

2 κ +1

1 1 + κ1





1 1− κ1

2 κ +1

Gl. 2.7 

1 κ−1

Gl. 2.8

2.3 Applikation von Motorsteuergerätefunktionen

23

In Abb. 2.11 ist die Durchflussfunktion für verschiedene Isentropenexponenten dargestellt. Bei Druckverhältnissen kleiner als ΠCrit würde nach Gl. 2.6 der Ψ-Wert wieder sinken. Dies ist aber in der Realität nicht der Fall, sondern bei weiterer Verringerung des Druckverhältnisses bleibt der zugehörige Massenstrom (und damit der Durchflusswert) konstant. Dieses Phänomen wird als Sperren bezeichnet [12]. 1

= 1.4 = 25

0.8 0.6 0.4 0.2 0 0

0.2

0.4

0.6

0.8

1

Abbildung 2.11: Durchflussfunktion Ψ

2.3 Applikation von Motorsteuergerätefunktionen Als Applikation bezeichnet man die Anpassung eines Motors an ein bestimmtes Fahrzeug [52]. Hierzu werden die im Programmcode des Motorsteuergeräts enthaltenen Daten, welche meist in Form von Kennwerten, Kennlinien oder Kennfeldern vorliegen, so parametriert, dass ein gewünschter Fahrbetrieb bestmöglich sichergestellt wird [52]. In der Literatur werden die Applikation und Validierung von Motorsteuergeräten als die wesentlichen Kostentreiber für zukünftige Fahrzeugprojekte gesehen, wobei die Applikation am Fahrzeug

24

2 Stand der Technik

neben der Prüfstands- und virtuellen Applikation unverzichtbar bleiben wird [83]. Das Verlangen nach hoch entwickelten und automatisierten Applikationsverfahren wird wachsen. Störsignale r Eingänge u

ProzessAusgang y

Prozess 

Mathematisches Modell Parameter p

Modellfehler e

ModellAusgang

Parameterschätzer

Abbildung 2.12: Parameterschätzung

Da in dieser Arbeit vorrangig grey-box Modelle zur Anwendung kommen, welche zu Teilen der experimentellen Modellbildung bedürfen, wird das verallgemeinerte Vorgehen zur Parameterbestimmung in Abb. 2.12 veranschaulicht. Mit den Eingangsgrößen u werden der betrachtete Prozess selbst sowie das mathematische Modell angeregt, was einerseits gestört über ein Störsignal r zu dem Prozessausgang y sowie dem Modellausgang y˜ führt. Durch Subtraktion von y und y˜ erhält man den Ausgangsfehler bzw. das Residuum e [37], mit dem man über ein Optimierungs- bzw. Parameterschätzverfahren zu einem Parametersatz für das mathematische Modell gelangt. Das Ziel bei der Modellbildung ist es also, die Parameter p des mathematischen Modells zu finden, die einen möglichst kleinen Fehler zwischen Prozess- und Modellausgang

2.3 Applikation von Motorsteuergerätefunktionen

25

erreichen. Identifikationsverfahren bei denen so vorgegangen wird, bezeichnet man auch als Fehlerminimierungs- oder Modellanpassungsverfahren [13]. Bei Modellen, welche eine lineare Abhängigkeit zu den Parametern aufweisen, wird häufig die Methode der kleinsten Fehlerquadrate (engl.: Least Squares (LS)) eingesetzt, welche gleichzeitig die einfachste Parameterschätzmethode darstellt [37]. Bei Betrachtung der Modellfunktion: y˜ k = p · uk

Gl. 2.9

handelt es sich um einen linearen statischen Prozess, wenn der Prozessausgang y nur von dem aktuellen Abtastschritt k abhängt und die Parameter p und Eingangsgrößen u linear sind. Bei nichtlinearen Eingangsgrößen u spricht man von einem nichtlinearen statischen Prozess (z.B.: Polynommodell) [37]. Bei der LS-Methode wird versucht, ein Minimum für die Quadratsumme des Modellfehlers in allen diskreten Abtastschritten bzw. Messpunkten N zu erzielen. Dies wird durch folgende Gleichung beschrieben: min ΦLS = p

N

∑ e2k

Gl. 2.10

k=1

Φ wird als Verlustfunktion oder Gütefunktion bezeichnet. Zur Bestimmung der unbekannten Parameter p bei Modellen, die nichtlinear in den Parametern sind, müssen iterative Methoden angewendet werden [38]. Darunter zählen gradientenfreie Verfahren (Suchverfahren), Gradientenverfahren erster und zweiter Ordnung (Newton-Verfahren) oder evolutionäre Algorithmen [11]. Im Vergleich zu den Suchverfahren und Gradientenverfahren bieten die evolutionären Algorithmen den Vorteil, dass mehrere Start-Parametersätze genutzt werden, wodurch das Steckenbleiben in lokalen Optima unwahrscheinlicher wird.

2.3.1 Maximum Likelihood Schätzung Bei Annahme von Verteilungsdichten des Fehlersignals können komplexere Modellstrukturen behandelt werden, als es bei Modellen möglich ist, die mit der LS-Methode gelöst werden [38]. Das LS-Verfahren setzt voraus, dass das

26

2 Stand der Technik

Fehlersignal linear in den Parametern ist. Bei dem Maximum Likelihood Schätzung geht man hingegen von einer statistischen Betrachtungsweise aus. Um dies mathematisch zu beschreiben, wird deshalb die so genannte Likelihood Funktion gebildet, bei der die Fehlersignale und Ausgangssignale normalverteilt angenommen werden können (mit Mittelwert 0) [37]. Außerdem seien stochastische Systemstörungen und Messfehler in den Eingangsgrößen vernachlässigt. Fehler zwischen Prozess und Modell können folglich nur Modellierungsungenauigkeiten und Messfehler der Ausgangsgrößen zur Ursache haben. Als weitere Annahme kommt hinzu, dass alle Modellfehler statistisch unabhängig sind. Als Wahrscheinlichkeitsdichtefunktion P für den Ausgangsfehler lässt sich basierend auf der Normalverteilung nach Gauss für N Abtastschritte folgender Ausdruck finden: N

P(e|u, p) = ∏

k=1

1 −1  · exp 2 (2π)σek



ek σek

2

Gl. 2.11

Die Gleichung setzt in der oben beschriebenen Form voraus, dass die Standardabweichung σek aller Fehler ek gleich ist. Die Aufgabe eines ML-Schätzverfahrens ist es nun, die Parameter p zu finden, die den kleinsten Fehler e aufweisen, siehe Abb. 2.13.

P(e|u,p)

Schätzverfahren

i+1 i

Fehler e

Abbildung 2.13: Wahrscheinlichkeitsdichtefunktion für den Fehler e

2.3 Applikation von Motorsteuergerätefunktionen

27

Um das Maximum der Wahrscheinlichkeitsdichtefunktion P aus Gl. 2.11 zu finden, wird die Gleichung logarithmiert, wodurch das Maximum der Funktion nicht verschoben wird und sich das Produkt in eine Summe umschreiben lässt: ⎤ ⎡ N

2 N e 1 − 12 σ k ⎦ Gl. 2.12 ek · ∏ exp L(p) = −ln P(e|u, p) = −ln ⎣  (2π)σek k=1 Und daraus folgt: L(p) = N · ln(σek ) +

1 N e2 N · ln(2π) + ∑ k2 2 2 k=1 σek

Gl. 2.13

Die Gütefunktion eines Maximum-Likelihood-Schätzers ist somit: ΦML =

N

e2

∑ σ k2

k=1

Gl. 2.14

ek

2.3.2 Fisher-Information und Cramér-Rao Ungleichung Für die Definition der Fisher-Informationsmatrix wird die Annahme einer erwartungstreuen Schätzung getroffen. Dann gilt: E{ p} = p∗

Gl. 2.15

Die Gleichung sagt aus, dass der Erwartungswert des geschätzten Modellparameters p dem tatsächlichen, nicht messbaren Wert des Parameters p∗ entspricht. Mit der Cramér-Rao Ungleichung wird gezeigt, dass die Inverse der Fisher - Informationsmatrix eine untere Schranke für die bestmöglich zu erreichende Parameterschätzung darstellt. Mit der Definition der Fisher-Informationsmatrix:     ∂ ln P(p) T ∂ ln P(p)  ∗ FIM( p ) = E Gl. 2.16 ∂ p p∗ ,tk ∂ p p∗ ,tk und der Kovarianzmatrix des Parameterschätzfehlers   Cp = E (p − p∗ )(p − p∗ )T

Gl. 2.17

28

2 Stand der Technik

gilt demnach der folgende Ausdruck: C p ≥ FIM −1 (p∗ ) ↔ σi j ≥ si j mit S = FIM −1 (p∗ )

Gl. 2.18

Die Indizes der einzelnen Matrizen-Einträge seien hier i und j. Die Hauptdiagonale der inversen Fisher-Informationsmatrix gibt also darüber Aufschluss, welche minimale Schätzfehler-Varianz in den einzelnen Parametern gefunden werden kann. Weiterhin kann mit einigen weiteren Umformungen die folgende Gleichung für die Fisher-Informationsmatrix hergeleitet werden, siehe hierzu [50]:   N ∂ y˜ T 1 ∂ y˜  ∗ Gl. 2.19 FIM( p ) = ∑   2 k=1 ∂ p p∗ , tk σek ∂ p p∗ , tk Zur Erläuterung von Gl. 2.19: Die Terme ∂∂ py˜ stellen die Sensitivitäten der Modellparameter auf den Modellausgang dar, σek gibt die Standardabweichung der Modellfehler zum Zeitpunkt k wieder. Dies kann als das weiße Rauschen der Messung interpretiert werden. Ein wesentliches Merkmal der Fisher-Informationsmatrix in Gl. 2.19 stellt die Additivität aus einzelnen diskreten Messzeitpunkten dar. Als weiterführende Literatur mit ausführlichen Herleitungen sei an dieser Stelle auf [37] [56] [70] verwiesen.

2.4 Diagnose von Verbrennungsmotoren Ein Fehler ist grundsätzlich etwas, dass das Systemverhalten derart beeinflusst, dass das System nicht mehr seinen ursprünglichen Zweck erfüllt [10]. Deshalb gehört die Diagnose zum Standardumfang einer elektronischen Motorsteuerung und nimmt dabei etwa 40-50 % des Softwareumfangs ein [7] [41]. Dabei werden die Eingangs- und Ausgangssignale sowie das Gesamtsystem auf fehlerhaftes Verhalten geprüft und erkannte Fehler in einem nichtflüchtigen Fehlerspeicher abgelegt. Über eine serielle Schnittstelle können Fehlercodes

2.4 Diagnose von Verbrennungsmotoren

29

ausgelesen werden und ermöglichen so die Fehlersuche und Reparatur. Übliche Diagnosen des Verbrennungsmotors sind die elektrischen Diagnosen für Sensoren, Aktuatoren und das Steuergerät, Plausibilitäts- und Bauteilprüfungen.

2.4.1 Abgasgesetzgebung Der Ursprung der On-Board-Diagnose (OBD) zur kontinuierlichen Überprüfung emissionsrelevanter Motorkomponenten während des Fahrbetriebs liegt im US-Bundesstaat Kalifornien bei der Behörde CARB (California Air Resources Board). Hier wird Ende der 80er Jahre eine erste verpflichtende Richtlinie mit OBD I erstellt, die Diagnosen und Signalprüfungen elektrischer Komponenten umfasst, die Einfluss auf die Emissionen ausüben. Über Blink-Sequenzen von Warnleuchten im Fahrzeugdisplay lässt sich die defekte Komponente identifizieren. Mit der Einführung von OBD II im Jahre 1994 entwickelte sich das Gesetz weiter und erfordert Prüfungen aller abgasrelevanter Komponenten und Systeme. Dabei muss jeder erkannte Fehler gespeichert, über eine Warnleuchte im Fahrzeugdisplay sichtbar gemacht und über ein Diagnose-Tool ausgelesen werden können. Die Fehlerspeicherinformationen sind gemäß den Richtlinien der SAE (Society of Automotive Engineers) abzulegen. Außerdem muss es möglich sein, innerhalb eines definierten Zyklus (bei Pkw: FTP75) jeden Fehler einmal finden zu können. Die Prüfhäufigkeit während des Realbetriebs wird ebenfalls abgetestet (IUMPR - In Use Monitoring Performance Ratio) [66]. In allen übrigen US-Bundesstaaten gelten die Vorschriften der EPA (Environmental Protection Agency), welche sich an die OBD II Gesetzgebung anlehnen. In Europa gilt die EOBD Richtlinie, welche sich wiederum an der EPA OBD Richtlinie orientiert. Zur Ermittlung der Verbrauchs- und Emissionsangaben in Europa gilt seit September 2017 der Referenzzyklus WLTC (Worldwide harmonized Light-Duty Vehicles Test Cycle) in Verbindung mit RDE (Real Driving Emissions). Das Ziel ist es, realitätsgetreue Angaben für Verbrauch und Emissionen machen zu können.

30

2 Stand der Technik

2.4.2 Diagnosemethoden Die Off-Board-Diagnose ist im Gegensatz zur On-Board-Diagnose außerhalb des Fahrzeugs lokalisiert. Hierbei wird bei speziellen Bedingungen eine Prüfung der Motorkomponenten durchgeführt [16]. Bei der Off-Board-Diagnose spricht man oftmals auch von Werkstattdiagnose, der eine steigende Bedeutung zukommt [65]. Klassische Diagnosemechanismen arbeiten derart, dass direkt (oder indirekt) messbare Größen gegen einen Schwellwert verglichen werden und bei dessen Überschreitung eine Fehlermeldung ausgeben sowie Maßnahmen einleiten, die den weiteren Betrieb erhalten und Unfälle oder Schäden vermeiden [39]. Diese arbeiten jedoch in der Regel nur in stationären Betriebspunkten zuverlässig, wodurch die Diagnosehäufigkeit sowie die Diagnosemöglichkeiten eingeschränkt sind. Auf heutigen Motorsteuergeräten kommt diese Art von Diagnosen, welche sich häufig auf einzelne Komponenten oder kleine Teilsysteme bezieht, häufig zur Anwendung. Die Vorteile sind hierbei der relativ geringe Rechenaufwand und die einfache Verständlichkeit. Für komplexere Diagnosen lassen sich z.B. modellbasierte Lösungen finden. Dabei werden Fehlermerkmale berechnet, daraus Symptome abgeleitet und dann über kausale Zusammenhänge auf die Fehlerursache geschlossen. Entsprechende Beispiele für das Luftsystem finden sich beispielsweise in [22] [29] [58] [74] [75]. Gegenwärtig werden nur wenige modellbasierte Diagnosen in Serienanwendungen eingesetzt [22]. Um die Diagnose aktueller Verbrennungsmotoren zu verbessern, ist es naheliegend, zusätzliche Sensoren einzubauen. Dies ist jedoch nicht immer zielführend, um die Gesamtzuverlässigkeit zu erhöhen, und viele Fehler lassen sich dennoch nicht erfassen [39]. Ein vielversprechenderes Vorgehen ist es, die vorhandenen Messinformationen besser zu nutzen, denn beim Auftreten von vielen Fehlern ändert sich der Zusammenhang der Prozesseingangs- und -ausgangssignale untereinander [36]. Wenn der Prozess über mathematische Modelle beschrieben wird, kann man über dessen Beobachtung auf Fehler zurückschließen [39]. Die Berechnung von umfassenden Prozessmodellen übersteigt jedoch häufig die Kapazität aktueller Steuergeräteressourcen, weshalb

2.4 Diagnose von Verbrennungsmotoren

31

sich die Diagnosen auf der ECU meist auf kleine Teilsysteme des Verbrennungsmotors reduzieren.

Eingänge u

Prozess

ProzessAusgang y

Vorverarbeitung Merkmale

Mathematisches Modell

ModellAusgang

Erkennung von Veränderungen Symptome

Auswertung Fehlerursache

Abbildung 2.14: Modellbasierte Diagnose

Eine modellbasierte Diagnose besteht generell aus drei Teilen: Der Merkmalserkennung, der Merkmal-zu-Fehler Transformation und der Fehlererkennung [22] [42]. Ein Vorgehen zur modellbasierten Diagnose ist in Abb. 2.14 dargestellt. Dabei werden neben dem betrachteten Prozess ein mathematisches Modell mit den Eingängen u (z.B. Aktoren/Sensoren) stimuliert, woraus die Ausgangssignale y bzw. y˜ resultieren. Das mathematische Modell wird dabei so ausgelegt, dass es das intakte Systemverhalten (Nominalzustand) wiedergibt. Durch eine Vorverarbeitungslogik (z.B. Filterung oder Transformation) lassen sich Merkmale berechnen. Ist eine Abweichung vom aktuellen Systemzustand zum nominellen Zustand zu erkennen, lässt sich daraus ein Fehlersymptom ableiten. Über eine entsprechende Auswertelogik (z.B. Klassifikationsoder Interferenzverfahren) ist schließlich eine Schlussfolgerung auf die Fehlerursache möglich. Meistens wird die Fehlererkennung mit gefilterten Werten – also in einem niedrigen Frequenzbereich des Modells – durchgeführt, was zu einem trade-off zwischen Erkennungsgeschwindigkeit und Robustheit gegen Modellfehler und Rauschen führt [56]. Ein Fehlererkennungssystem sollte folgende Eigenschaften aufweisen [33] [39]: • hohe Fehlerempfindlichkeit • Zuverlässigkeit in der Fehlererkennung ohne Fehldiagnosen

32 • • • •

2 Stand der Technik

schnelle Fehlerdetektion geringer on-line Rechenaufwand möglichst keine Zusatzsensorik Erkennung der Fehlerschwere und des Fehlerorts

2.5 Software-Entwicklungsprozess Die Vielschichtigkeit der Steuergerätesoftware im Automobilbereich hat aufgrund der gestiegenen Anzahl an Funktionen sowie deren Vernetzung, der Anforderungen an Zuverlässigkeit, Verfügbarkeit, Skalierbarkeit sowie Variantenhandling stetig zugenommen [73]. Jedes Steuergerät ist hierdurch zu einem Konstrukt hoher Komplexität geworden [15]. Um die Erstellung und Wartung der Software dennoch beherrschbar zu gestalten, erfolgt die Entwicklung mit Hilfe von strukturierten Vorgehens- bzw. Phasen- und Prozessmodellen [23]. Dabei richtet sich der Entwicklungsprozess in der Automobilindustrie nach Prinzipien wie ASPICE (Automotive Software Process Improvement and Capability dEtermination) und dem V-Modell, verwendet Standards wie ASAM (Arbeitskreis für die Standardisierung von Automatisierungs- und Messsystemen) oder AUTOSAR (Automotive Open System Architecture) und sollte möglichst Methoden wie die Simulation und Rapid Prototyping einsetzen [73]. Ein Software-Entwicklungsprozess hat die Aufgabe, alle Arbeitsabläufe während der Software-Entwicklung zu regeln [48]. Hierbei definiert ein Prozess eine wiederkehrende Reihe aufeinander folgender Arbeitsschritte, wobei ein Prozessschritt eine in sich abgeschlossene Folge von Tätigkeiten ist, die als Ergebnis ein Artefakt bzw. Dokument hervorbringt [73].

2.5.1 V-Modell Das V-Modell ist in der Automobilindustrie weit verbreitetet und eignet sich besonders für Systeme mit hohen Zuverlässigkeits- und Sicherheitsanforder-

2.5 Software-Entwicklungsprozess

33

ungen, bei denen Prüfschritte vorgeschrieben sind [73]. Dabei unterteilt das V-Modell die Entwicklung in mehrere Phasen, weshalb es auch zu den Phasenmodellen gezählt wird [72]. Jeder neue Prozessschritt darf hierbei erst angefangen werden, sobald der voran gegangene abgeschlossen ist. Die Kernidee des V-Modells ist die Zerlegung und Spezifikation des zu entwickelnden Systems auf dem absteigenden linken Ast des Modells, während auf dem rechten aufsteigenden Ast ein entsprechender Integrations- und Prüfschritt zugeordnet wird [1]. Diese Darstellung führt zu der Form eines “V”, welche auch namensgebend für das Modell ist.

Systemanforderung

Konzeptentwicklung

System Entwicklung (Steuergerät)

SW-Architektur

System-/Akzeptanztest

Applikation

Implementierungstest Software Entwicklung

Funktionsdesign

Software-Design

Funktionsvalidierung

Verifikationstest

Abbildung 2.15: V-Modell

Das V-Modell für die Entwicklung elektronischer Systeme lässt sich generell in die Systementwicklung (Systems Engineering) und Softwareentwicklung (Software Engineering) unterteilen. Die einzelnen Prozessschritte stellen sich wie folgt dar: Systemanforderungen In diesem Prozessschritt werden die funktionalen Systemanforderungen auf abstrakter Ebene erstellt. Hierbei werden noch keine technischen Realisierungen festgelegt.

34

2 Stand der Technik

Konzeptentwicklung In der Konzeptentwicklung werden Möglichkeiten zum Erfüllen der Systemanforderung auf technischer und ökonomischer Ebene gegeneinander abgewägt. Eine dieser Möglichkeiten wird in der weiteren Entwicklung umgesetzt. SW-Architektur Im Prozessschritt SW-Architektur wird festgelegt, in welchen SW-Komponenten die technische Umsetzung der System- bzw. Softwareanforderungen erfolgen soll. Dabei basiert die SW-Architektur sowohl auf funktionalen und nicht- funktionalen Anforderungen. Außerdem werden die Schnittstellen und die Interaktion der SW-Komponenten spezifiziert. Funktionsdesign In diesem Schritt werden die Software-Komponenten auf technischer, funktionaler Ebene spezifiziert. Hierbei werden Implementierungsdetails (z.B. Datentyp oder Quantisierung) zunächst vernachlässigt. Software-Design Im Software Design werden die Implementierungsdetails festgelegt. Dies sind beispielsweise Datentypen und Quantisierungen von Variablen und Parametern. Verfikationstest Der Verifikationstest überprüft, ob die Umsetzung der Software mit den SWAnforderungen übereinstimmt. Umgangssprachlich wird unter Verifikation verstanden, ob ein korrektes Produkt entwickelt wird [82]. Funktionsvalidierung Bei der Funktionsvalidierung wird geprüft, ob die Software-Funktionalität für ihren Einsatzzweck geeignet ist und die funktionalen Anforderungen erfüllt sind. Nach der VDI-Richtlinie 2206 wird unter Validierung vereinfacht verstanden, ob das richtige Produkt entwickelt wird [82]. Implementierungstest Der Implementierungstest dient der Überprüfung der Integrierbarkeit der geänderten SW-Komponenten in ein Softwaresystem.

2.5 Software-Entwicklungsprozess

35

Applikation Bei der Applikation (oder auch Parametrierung genannt) wird die Einstellung der Parameter der Software-Funktionalitäten vorgenommen. Diese Anpassung erfolgt individuell je nach Art und Variante des Fahrzeugs [73]. Die Parameter einer Software-Funktion sind üblicherweise als Kennwerte, Kennlinien und Kennfelder im Programmspeicher des Steuergeräts abgelegt. System-/Akzeptanztest Der System- bzw. Akzeptanztest prüft im letzten Prozessschritt des V-Modells, ob die System- und Benutzeranforderungen erfüllt werden.

2.5.2 MiL, SiL und HiL-Testmethoden Um die Vorgehensweise einzelner Prozessschritte innerhalb eines Prozessmodells festzulegen, können Methoden definiert werden. Dabei ist in der SoftwareEntwicklung die Simulation in verschiedensten Ausprägungen ein wichtiges Instrument, um Funktionalitäten frühzeitig zu testen, da die finale Hardware oder ein Prototyp häufig nicht zur Verfügung stehen. Grundsätzlich wird zwischen closed-loop und open-loop Simulationen differenziert, wobei der Unterschied im Schließen des Regelkreises liegt. Im Folgenden sind gängige Simulationsalternativen dargestellt. Model-in-the-Loop (MiL) Model-in-the-Loop Simulationen werden in einem frühen Entwicklungsstadium – insbesondere in der Konzeptentwicklung und während der Erstellung des Funktionsdesigns – genutzt, bei dem sowohl die zu entwickelnde Funktion als auch die Umgebung (Strecke) als Modell umgesetzt sind. Die Simulationsumgebungen werden häufig mit Programmen wie ASCET® oder Matlab/Simulink® in Blockschaltdiagrammen aufgebaut. Software-in-the-Loop (SiL) Bei Integration einer Software-Funktion im Target Code in eine simulierte Umgebung, wird von einer Software-in-the-Loop Simulation gesprochen [73]. Für SiL-Simulationen sind keine reale Hardware und Echtzeitfähigkeit erforder-

36

2 Stand der Technik

lich [43]. Als Anwendungsgebiet sei hier beispielsweise der Verifikationstest genannt. Hardware-in-the-Loop (HiL) Unter Hardware-in-the-Loop ist die Integration von realen Hardware-Komponenten und Systemmodellen in eine gemeinsame Simulationsumgebung zu verstehen [82]. Der Vorteil hierdurch ist die Erprobung in der Zielhardware des Steuergerätecodes, ohne kostenintensive Fahrzeuge oder Prüfstande zu benötigen. Die Simulation wird hierzu in Echtzeit ausgeführt, weshalb die HiLSimulation leistungsstarke Rechner benötigt [14]. MiL

SiL

HiL

Motormodell

Motormodell

Echtzeitfähiges Motormodell

Modell der SW-Funktion

SW-Funktion im Target Code

SW-Funktion auf realem Steuergerät

Abbildung 2.16: MiL/SiL/HiL-Simulation

3 Anwendungsfelder im Bereich der Motorsteuerung

3.1 Überblick Dieses Kapitel soll die generellen Möglichkeiten und Vorteile, die das vernetzte Fahrzeug für die Motorsteuerung bietet, während des Entwicklungsprozesses und in Serienanwendungen aufzeigen. Dafür wird zunächst anhand des V-Modells diskutiert, welche Prozessschritte durch den Einsatz der Fahrzeugvernetzung einen Nutzen haben. Der Entwicklungsprozess wird dazu in die Systementwicklung und Softwareentwicklung untergliedert. Anschließend werden Optionen geprüft, die den Motorbetrieb im Serieneinsatz weiter optimieren können. Der Hauptfokus liegt hierbei auf der Car-to-Cloud Kommunikation. In Abb. 3.1 und Abb. 3.2 wird ein Überblick über potentielle Anwendungsgebiete dargestellt.

Software - Entwicklung Requirements Engineering

Cloud

x Neue Konzepte durch: - Informationsquellen außerhalb des Fahrzeugs (z.B. Wetterstationen, Verkehrsinformationen) - Rechenleistung außerhalb des Fahrzeugs x Remote Fahrzeugtest x Daten Backup x Remote SW-Updates x ...

x

Wissensgenerierung für: - Bauteilanalysen - Fahrer-Verhalten - Lebensdaueraussagen - Lebensdauerdrift - Ausfallwahrscheinlichkeiten - Toleranzanalysen - Fahrzeug-FahrzeugStreuungen -

Abbildung 3.1: Übersicht über Anwendungsfelder für Car-to-Cloud in der Entwicklung © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 L. Hagen, Neue Möglichkeiten für die Motorsteuergeräte- Software durch Car-to-Cloud-Vernetzung, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-31565-8_3

38

3 Anwendungsfelder im Bereich der Motorsteuerung

x x x x

x x x x

Erweiterte signal-/ modellbasierte Diagnosen prädiktive Diagnosen Wissensbasierte Diagnosen Stilllegen von defekten Fahrzeugen (z.B. mit OBD III) Remote Abgasuntersuchung Ferndiagnose Feldüberwachungen (z.B. IUMPR) ...

Sonstige Serien Anwendungen

Applikation

Diagnose x x x

x

fahrzeugindividuelle Applikation fahrerindividuelle Applikation umweltspezifische Applikation ...

x

x x x

x x

Motor-AUS/Bremse bei Falschfahrern (Fahren in Fußgängerzonen /entgegen Regeln etc.) Nutzungsbasierte Versicherungstarife Anpassung Motorleistung (z.B. Kindern) via App Download von Zusatzfeatures: (z.B. Steigerung Motorleistung) Remote SW-Updates ...

Abbildung 3.2: Übersicht über Anwendungsfelder für Car-to-Cloud in Serienanwendungen

3.2 Entwicklungsprozess Während sich die Systementwicklung innerhalb des Entwicklungsprozesses für Steuergeräte-Software mit der generellen Anforderung an eine neue Funktionalität beschäftigt und verschiedene Konzepte diskutiert, beschäftigt sich die Softwareentwicklung mit der technischen Realisierung. In allen Prozessschritten spielen dabei der Test und die Absicherung eine tragende Rolle. Die Bedingung für die Einführung des vernetzten Fahrzeugs in den Entwicklungsprozess ist die Erzielung einer erhöhten Software-Qualität, einer verbesserten Funktionalität und/oder verringerten Entwicklungskosten. Prinzipiell ist eine der größten Herausforderungen die Beherrschung der Komplexität der Automobil-Software, denn alleine die Antriebs-Domäne umfasst

3.2 Entwicklungsprozess

39

mehrere Millionen Zeilen an Code. Gleichzeitig ist der Grad der Automatisierung in der Software-Entwicklung niedrig und der Kostendruck im Automobilbereich groß [17]. Außerdem steigen die Kosten für Entwicklung, Wartung und Instandsetzung aufgrund der SW-Komplexität und Variantenvielfalt kontinuierlich. Somit ist die Optimierung des Entwicklungsprozesses automobiler Software von hoher Bedeutung.

3.2.1 Systementwicklung Als Systementwicklung seien hier die Prozessschritte definiert, die eine Entwicklung von neuen Software-Funktionalitäten auf oberster Ebene betrachten und die für die generellen Systemanforderungen und die Konzeptentwicklung verantwortlich sind. Außerdem seien die Applikation sowie der Systemtest Bestandteil der Systementwicklung. Die Applikation bzw. Parametrierung von Steuergeräte-Funktionalitäten wird im Unterkapitel 3.3 separat betrachtet. Systemanforderungen Generell entsteht durch die permanente Möglichkeit der Übertagung von Fahrzeug- und Messdaten auf eine Cloud ein Wissensspeicher, der Erkenntnisse über das Verhalten einzelner Bauteile, einzelner Subsysteme sowie das Gesamtsystem Motor liefern kann. Denn weder die Hersteller noch die Zulieferer haben zuverlässige Daten über die Anwendungspattern von Fahrzeugen im Feld über Lebensdauer [45]. Für das Steuergerät bedeutet dies, dass durch die transferierten Daten neue System- bzw. Steuergeräteanforderungen abgeleitet werden können, die zur Optimierung von Motorverhalten oder Motorbauteilen führen. Dies ist auch insofern hilfreich, denn eines der größten Probleme in der heutigen Software-Entwicklung stellt das Anforderungs-Management dar [17]. Die Menge der generierten Daten und der daraus abgeleiteten Systemanforderungen hängt wesentlich von der Anzahl der involvierten Fahrzeuge sowie der übertragenen Datenmenge ab. Aufgrund der bereits angesprochenen limitierten Übertragungskapazitäten der Mobilfunkschnittstelle, sollten Vorüberlegungen zu interessanten Aspekten des Motors für die Datenübertragung durchgeführt werden. Die anschließende Analyse der teils sehr großen Datenmenge

40

3 Anwendungsfelder im Bereich der Motorsteuerung

(Big Data) kann auf der Cloud mit konventionellen oder neuartigen Methoden erfolgen, die unter Begriffen wie Data Mining oder Data Analytics bekannt sind. Insgesamt können beispielsweise folgende Themen durch die gesammelten Daten von Interesse sein: • • • • • • • • •

Alterungsverhalten von Bauteilen Lebensdauer von Bauteilen Fahrer-Verhalten Ausfallwahrscheinlichkeiten Toleranzanalysen Fahrzeug-Fahrzeug-Streuungen System-/Reglerperformance Lebensdauerdrift ...

Die Erkenntnisse, die das vernetzte Fahrzeug für die Systemanforderungen liefert, entstehen durch den Upload von Daten auf die Cloud und deren anschließender Auswertung. Außerdem ist die Übertragung der Daten nicht zeitkritisch, sodass die limitierte und teure Nutzung des Mobilfunknetzes durch eine deutlich günstigere WLAN-Verbindung ersetzbar ist, beispielsweise bei parkendem Fahrzeug. In diesem Fall könnte jedoch ein zusätzliches Speichermedium im Fahrzeug notwendig sein, um die Daten während der Fahrt zwischenzuspeichern. Konzeptentwicklung Für die Konzeptentwicklung bringt die Vernetzung des Fahrzeugs bedeutende Unterschiede mit sich, denn durch die großen Speicher- und Rechenkapazitäten sowie Informationsquellen außerhalb des Fahrzeugs werden neue Konzepte möglich, die bislang nicht realisierbar waren. Diese neuen Konzepte können sowohl funktionale als auch ökonomische Vorteile bewirken. Wie diese Konzepte im Einzelnen aussehen, hängt vom Anwendungsfall ab. Systemtest Durch die permanente und weltweite Verfügbarkeit und Erreichbarkeit von Entwicklungsfahrzeugen, könnte sich der Engpass von fehlenden oder zu we-

3.2 Entwicklungsprozess

41

nigen Fahrzeug-Prototypen auflösen. So ist es denkbar, dass ein Entwicklungsfahrzeug hauptsächlich von einem geschulten Testfahrer bewegt wird, der notwendige Systemtests von Entwicklungsingenieuren ausführt. Über Telefonie und eine Remote-Verbindung können einzelne Testfälle besprochen und online mitverfolgt werden. Dabei können in Zukunft die am Fahrzeug verbauten Kamerasysteme zusammen mit schnelleren Mobilfunknetzen zu einer weiteren Visualisierung führen. Eine geeignete Umschreibung dieser Methode ist Remote Fahrzeugtest.

3.2.2 Software-Entwicklung Zwei wesentliche Prozessschritte der Funktionsentwicklung sind im Funktionsdesign und der Funktionsvalidierung zu sehen. Das Funktionsdesign wird sich in vielen Aspekten durch das vernetzte Fahrzeug nicht ändern, jedoch schafft es auch neue Möglichkeiten, z.B. durch • Entfall von Sensoren durch Nutzung von Umgebungsinformationen (z.B. Umgebungstemperatur) • Nutzung von zusätzlichen Umgebungsinformationen (z.B. Umgebungsfeuchte) • adaptive Regelungskonzepte durch Fahrzeug/-Flotteninformation und externe Rechenkapazitäten • prädiktive Anpassung der Motorbetriebsart basierend auf Verkehrsinformationen • erweiterte Diagnosestrategien (siehe Kapitel 3.4) • ... Die Funktionsvalidierung am Fahrzeug kann ebenfalls über den bereits beschriebenen Remote-Fahrzeugtest erfolgen. Der Kern der Software-Entwicklung mit den Prozessschritten SW-Design und Verifikationstest hat wenige Vorteile durch die Vernetzung des Fahrzeugs. Die Programmiersprachen wie C/C++ bleiben unverändert und statische Softwaretests sind durch die Vernetzung nicht beeinflusst. Jedoch ist es denkbar, dass die Sicherung von Fahrzyklus-übergreifenden Daten (z.B. Adaptionswerte),

42

3 Anwendungsfelder im Bereich der Motorsteuerung

die bisher durch nichtflüchtige Speicher wie das EEPROM erfolgen, nun durch die Cloud stattfindet. Somit kann die Dimensionierung der steuergeräteseitigen nichtflüchtigen Speicher reduziert und geringere Hardwarekosten je Steuergerät erzielt werden. Eine weitere Option ist das Erzeugen eines Backups auf der Cloud, welches bei Fehlfunktion oder Defekt des Steuergeräts nutzbar ist. Des Weiteren ist es denkbar, die Software auf unerlaubte Tuningaktivitäten remote zu überprüfen. Jedoch kann das Thema Sicherheit für die Softwarearchitektur und die Implementierung der Software einen erheblichen Einfluss haben. Es muss garantiert werden, dass kein externer unbefugter Zugriff auf ein Fahrzeug erfolgt. Dazu müssen Authentifizierung, Autorisierung und Datenschutz in ein ganzheitliches Konzept eingebettet sein [21] [69]. Insgesamt lassen sich durch die zusätzlichen Speicher- und Rechenressourcen sowie externen Informationsquellen verbesserte SW-Funktionalitäten realisieren, die durch den Remote-Fahrzeugtest zusätzlich unterstützt werden können. Dies spart Entwicklungskosten ein. Durch die Auslagerung von Fahrzyklusübergreifenden Daten auf die Cloud ist ebenfalls eine Kostenreduktion in der Steuergeräte-Hardware sowie eine Absicherung von nichtflüchtigen Daten denkbar.

3.3 Applikation/Parametrierung 3.3.1 Überblick Aufgrund der steigenden Komplexität zur Parametrierung von MotorsteuerungsSoftware sind wirtschaftliche, hochentwickelte Methoden zur Applikation von Verbrennungsmotoren notwendig, die für verschiedene Motorkonzepte eingesetzt werden können [11][41]. Die Vernetzung des Fahrzeugs bietet für den Applikationsprozess einige Vorteile, um die steigenden Anforderungen in der Fahrzeugentwicklung erfüllen zu können:

3.3 Applikation/Parametrierung • • • • •

43

Zugriff auf Fahrzeug- und Messdaten zu jeder Zeit an jedem Ort automatisierte oder teilautomatisierte Applikation Remote Flashing angepasste Applikation an Fahrzeug, Fahrer, Standort oder Verkehrslage optimiertes Flottenmanagement

Im Folgenden sollen die einzelnen Punkte erläutert werden: Zugriff auf Fahrzeug- und Messdaten zu jeder Zeit an jedem Ort Heutzutage werden Messdaten vom Fahrzeug oftmals auf einen Zwischenspeicher (etwa einen USB-Speicher) kopiert und zwischen Standorten physisch übertragen, wodurch ein Zeitverzug von Tagen oder Wochen entsteht [3]. Das vernetzte Fahrzeug bietet einen wesentlichen Vorteil im Datenhandling und steigert die Flexibilität für die Funktionsapplikation. Durch die örtliche Entkopplung von Datenaufzeichnung und Datenzugriff wird eine Zeitersparnis im Applikationsprozess ermöglicht. Die früher zur Verfügung stehende, breitere Datenbasis trägt dazu bei, die Applikationsqualität zu verbessern. Da mit dem vernetzten Fahrzeug Mess- und Fahrzeugdaten zentral auf der Cloud gespeichert werden können, stehen dem gesamten Entwicklungsteam die gleichen Daten weltweit zur Verfügung. So können Inkonsistenzen in den Messdaten der Entwicklungsingenieure aufgelöst und die Applikationsgüte insgesamt verbessert werden. Möglichkeit zur automatisierten oder teilautomatisierten Applikation Die Effizienz des Applikationsprozesses muss sich aufgrund der großen Vielzahl von Applikationsaufgaben erhöhen. Dafür ist die Automatisierung der Steuergeräte-Applikation durch das vernetzte Fahrzeug ein geeignetes Mittel, ohne aufwändige Zusatz-Hardware im Fahrzeug (abgesehen von der notwendigen Sensorik) verbauen zu müssen. Die Parametrierung bzw. Optimierung, welche im Grunde die Suche nach einem Minimum oder Maximum einer Gütefunktion darstellt, und die je nach verwendetem Algorithmus (z.B. Evolutionäre Algorithmen) sehr rechenintensiv sein kann, ist auf der Cloud automatisierbar.

44

3 Anwendungsfelder im Bereich der Motorsteuerung

Remote Flashing Das Beschreiben des Flash-Speichers eines Steuergeräts mit neuem Programmcode (auch “Flashen” genannt) kann durch die Anbindung des Fahrzeugs an externe Datenquellen über den Mobilfunk getriggert und ausgeführt werden. Hierdurch ist es möglich, alle Fahrzeuge auf dem aktuellsten SW-Programmstand zu halten, wodurch die Robustheit des Applikationsprozesses gesteigert wird. Die Fehlerquelle eines inkorrekten oder veralteten Programmstands ist somit eliminiert. angepasste Applikation Um weitere Optimierungen in Bezug auf Komfort, Leistung, Emissionen oder Verbrauch zu erzielen, ist eine individuelle Applikation an Fahrzeug, Fahrer, Standort oder Verkehrslage denkbar. Dies setzt jedoch oftmals zusätzliche Sensorik am Fahrzeug voraus. Denkbar ist auch die Bildung von Fahrzeug- oder Fahrerclustern (siehe Kapitel 3.3.2), wodurch nicht jedes Fahrzeug die ZusatzSensorik benötigt. Der Datenstand könnte sich so beispielsweise aufgrund des Aufenthaltsorts des Fahrzeugs (z.B.: Nord-Schweden oder Süd-Spanien) ändern. optimiertes Flottenmanagement Aufgrund der Anbindung des vernetzten Fahrzeugs an die Cloud und damit auf Fahrzeug- und Messdaten anderer Flottenfahrzeuge können Plausibilitätsprüfungen der Messdaten erfolgen. Die Problematik eines fehlerhaften, inkorrekten oder veralteten Programmstands könnte durch Software-Plausibilisierung ebenfalls der Vergangenheit angehören. Somit ist ein weiterer Beitrag zur Effizienzsteigerung und Fehlerminimierung im Produktentwicklungsprozess möglich. Zusammenfassend ist ein Manko des heutigen Applikationsprozesses die Verallgemeinerung der gefundenen Funktionsparameter. So ist es üblich die erstellte Applikation eines oder weniger Referenzmotoren für die Gesamtheit aller Serienfahrzeuge zu übernehmen, die je nach Projekt mehrere hunderttausend Einheiten umfassen kann. Dabei ist schnell ersichtlich, dass durch beispielsweise Umgebungsbedingungen, Fahrstil, Aufenthaltsort oder auch Fahrzeug-Fahrzeug-Streuungen unterschiedliche Bedatungen gefordert sind, um das Motorverhalten weiter zu optimieren. Die Individualisierung der Appli-

3.3 Applikation/Parametrierung

45

kation auf einzelne Fahrzeuge oder Fahrer und die Anpassung auf aktuelle Situationen ist eine Möglichkeit, die Vernetzung gewinnbringend einzusetzen, da durch die Kommunikation zur Cloud praktisch jederzeit genügend Rechenkapazität zur Erstellung einer neuen Bedatung bereitsteht. Ein weiteres Problem ist im großen Aufwand zur Applikationserstellung zu erkennen, die ein nicht unerheblicher Kostentreiber in der Motorsteuergeräteentwicklung darstellt. Auch hier kann das vernetzte Fahrzeug zu einer Effizienzverbesserung beitragen, da der Applikationsprozess prinzipiell automatisiert werden kann.

3.3.2 Applikationsstrategien In Abbildung 3.3 sind Applikationsstrategien mit Hilfe der Cloud dargestellt. Der Fall 1 entspricht der konventionellen Vorgehensweise, also der Streuung des Applikationsergebnisses eines oder sehr weniger Fahrzeuge über die gesamte Fahrzeugflotte, wobei jedoch die Applikationserstellung automatisiert auf der Cloud durchgeführt wird. Im Fall 2 wird über eine Vielzahl von Fahrzeugen Messdaten gesammelt und basierend darauf ein Masterdatensatz erstellt. Dieser soll einen guten Mittelwert über alle Fahrzeuge darstellen. Im Fall 3 ist der Optimalfall zur Individualisierung einer Applikation gezeigt. Jedes Fahrzeug wird als Individuum angesehen, sammelt einzeln Messdaten und bekommt eine eigene Applikation zur Verfügung gestellt. Jedoch sind hierzu in jedem Fahrzeug auch entsprechende Referenzgrößen notwendig, die für viele Anwendungsfälle nicht zur Verfügung stehen, da diese mit zusätzlicher Sensorik verbunden sind. Eine Möglichkeit diese Problematik teilweise zu umgehen, ist in Fall 4 gezeigt. Mehrere Fahrzeuge werden zu Clustern gleicher Eigenschaften zusammengefasst, beispielsweise gleicher geografischer Lage. Nun würde es genügen, eines oder wenige Fahrzeuge mit Zusatzsensorik auszustatten, welches die Referenz für das gesamte Cluster darstellt. Hierbei müssen die Referenzfahrzeuge auf Plausibilität gegenüber anderen Clustern geprüft werden, um Fehlapplikationen zu vermeiden, beispielsweise bei defekten Referenzsensoren.

46

3 Anwendungsfelder im Bereich der Motorsteuerung

1)

2)

Cloud

Cloud .a2l

.a2l

.hex

.hex

3)

4)

A .a2l .hex

.a2l .hex

.a2l .hex

Cloud

Cloud .a2l .hex

.a2l

.a2l

.hex

.hex

B

Abbildung 3.3: Anwendungsmöglichkeiten Applikation

3.4 Diagnose

47

3.4 Diagnose Das vernetzte Fahrzeug bietet für den Themenkomplex der Diagnose einen weitreichenden Anwendungshorizont. Dies liegt grundsätzlich daran, dass etwa die Hälfte des Softwareumfanges auf einem Motorsteuergerät für die Diagnose verwendet wird. Obwohl ein Teil hiervon permanent auf dem Motorsteuergerät genutzt und benötigt wird (z.B. elektrische Diagnosen), sind dennoch Möglichkeiten zur Optimierung vorhanden, um die Fehlererkennung und Fehlerdiagnose zu verbessern. Denn es bleiben mit den aktuell implementierten Diagnoseansätzen viele Potentiale ungenutzt, da die Rechen- und Speicherkapazitäten auf dem Steuergerät für komplexe Diagnosestrategien nicht ausreichen oder die zusätzlich benötigten Informationen nicht zur Verfügung stehen. Grundsätzlich sind mit Hilfe des Connected Car erweiterte oder neue Diagnosemethoden anwendbar, die neben komplexeren modell- oder signalbasierten Methoden als bisher auch wissensbasierte oder prädiktive Prinzipien umfassen können. Außerdem sind Diagnosen mit Hilfe von Umgebungsinformationen darstellbar, beispielsweise das Plausibilisieren des Umgebungstemperatursensors gegen eine sich in der Nähe befindende Wetterstation. Außerdem ist der Ort der Berechnung zur Fehlerdiagnose nicht mehr zwangsweise das Fahrzeug selbst, siehe Abb. 3.4. In Fall 1 findet lediglich die Fehlererkennung auf dem Fahrzeug statt, die eigentliche Diagnose hingegen wird auf der Cloud durchgeführt. Dazu sind allerdings genügend informative Messdaten vom Fahrzeug zur Cloud zu transferieren. Die Cloud übermittelt abschließend das Diagnoseergebnis zurück zum Fahrzeug. Ein entsprechendes Beispiel wird in Kapitel 5 aufgezeigt. Im Fall 2 ist ein triggerbasiertes Prinzip dargestellt. Hierbei würde das Fahrzeug einen Fehler erkennen und der Cloud melden. Daraufhin stellt die Cloud eine passende Diagnose-Software bereit, die auf dem Fahrzeug ausgeführt wird. Bei diesem Vorgehen sind jedoch nicht so komplexe Algorithmen wie in Fall 1 möglich, dafür kann aber auch hier die grundsätzliche Hardware-Auslastung des Steuergeräts verringert werden. Im Fall 3 wird ein Fehler durch Fahrer oder Fahrzeug an die Cloud gemeldet, welche hier einen Diagnose + Support Service darstellt. Ein geschulter Service-Mitarbeiter kann dann auf die Messdaten des Fahrzeugs zugreifen und

48

3 Anwendungsfelder im Bereich der Motorsteuerung

geeignete Maßnahmen einleiten. Im Pannenfall kann so auch entschieden werden, ob überhaupt Hilfe vor Ort erforderlich ist (beispielsweise nicht nur der Tank leer ist), ob ein Pannenhelfer oder Abschleppwagen benötigt wird oder auch welche Ersatzteile der Pannenhelfer sofort mitnehmen kann [6]. c) Diagnose

1) b) Messdaten + Fahrzeugdaten

Cloud

2) b) Meldung des Fehlers

Cloud

d) Diagnoseergebnis

c) DiagnoseSoftware

a) Fehlererkennung

a) Fehlererkennung

d) Diagnose

3) b) Meldung des Fehlers a) Fahrer oder Fzg. erkenntt Fehler

Cloud

d) Diagnose + Support Service

c) Zugriff auf Fahrzeug

Abbildung 3.4: Anwendungsmöglichkeiten Diagnose

Insgesamt kann auch die On- und Offboard Diagnose mehr verschmelzen, da zur genauen Diagnose einer Fehlerursache der Besuch in der Werkstatt nicht mehr zwingend erforderlich sein kann. So werden beispielsweise in der Werkstatt Diagnosen über den Diagnosetester angefordert, die Fehler erkennen sollen, die die On-Board Diagnose nicht erkennen konnte [65]. Diese speziellen Diagnosen können in Zukunft per Ferndiagnose stattfinden. Ein in der Literatur häufig zitiertes Thema ist das der prädiktiven Diagnose, also das Vorhersagen von in Zukunft eintretenden Fehlern, wodurch Pannen

3.5 Sonstige Anwendungsgebiete

49

oder Fehlverhalten vermieden werden sollen. Mit Hilfe des vernetzten Fahrzeugs können Fehler- und Schadensverläufe analysiert, ausgewertet und somit zur Fehlervorhersage genutzt werden. Darüber hinaus kann das vernetzte Fahrzeug auch für den Gesetzgeber von Nutzen sein. So soll mit OBD III in den Vereinigten Staaten von Amerika bei emissionsrelevanten Defekten die Fehlercodes sowie die Fahrgestellnummer (VIN) selbstständig an die Behörde übermittelt und der Fahrzeughalter innerhalb einer Frist dazu aufgefordert werden, das Fahrzeug zu reparieren [59]. Falls dies nicht geschieht, behält sich der Gesetzgeber ein Stilllegen des Fahrzeuges vor. Außerdem lassen sich beispielsweise Größen wie das In-Use Monitor Performance Ratio (IUMPR), welches einen Indikator für die Überwachungshäufigkeit von Diagnosefunktionen darstellt, über den Mobilfunk für jedes Fahrzeug oder die gesamte Fahrzeugflotte mitverfolgen und überprüfen. Auch nach bereits erfolgter Markteinführung können vernetzte Fahrzeuge neue Gesetzgebungen erfüllen, sofern durch SW-Updates die neuen Anforderungen eingehalten werden können. Allgemein kann eine verbesserte Diagnosequalität die Kundenzufriedenheit steigern, die letztlich Zeit und Kosten einsparen. Der Fahrzeughersteller kann sich durch einen überdurchschnittlichen Service von der Konkurrenz abheben. Der Gesetzgeber kann eine verbesserte Feldüberwachung durchführen.

3.5 Sonstige Anwendungsgebiete Remote Software Updates haben beim Kraftfahrzeug eine hohe Priorität erlangt [21], denn sie ermöglichen Optimierungen, Qualitätsverbesserungen sowie ein flexibles Lifecycle Management [80]. Werkstattbesuche und Rückrufaktionen, die als einzige Aufgabe das Flashen einer neuen Software-Version haben, können somit der Vergangenheit angehören. Gleichzeitig sind Upda-

50

3 Anwendungsfelder im Bereich der Motorsteuerung

tes für die Cyber-Sicherheit des vernetzten Fahrzeugs von hoher Bedeutung [69], um kontinuierlich neu auftretende Sicherheitslücken zu schließen. Jedoch muss eine hohe Robustheit beim Aufspielen der neuen Software sichergestellt sein, sodass auch bei fehlerhaftem Update eine Wiederherstellung der vorherigen Version möglich ist. Der ideale Zeitpunkt für ein Software-Update ist bei parkendem Fahrzeug am Wohnort des Fahrzeughalters, der das Update per Mobiltelefon bestätigen muss. So kann auch eine WiFi Verbindung genutzt werden, die neben dem Wegfall der Mobilfunkkosten auch die Zeitdauer des Software-Updates reduzieren kann [20]. Neben Software-Updates können auch Zusatzfeatures over-the-air bereitgestellt werden. So ist eine Leistungssteigerung des Motors per Software-Update ebenso denkbar wie eine Drosselung der Motorleistung für einen Fahranfänger. Es sind also Individualisierungen bzw. Personalisierungen der Motor-Software darstellbar. Ebenso sind nicht alle Funktionalitäten eines heutigen Motorsteuergeräts immer notwendig. So benötigt ein Fahrzeug, welches sich ausschließlich in den Niederlanden aufhält, sicherlich keine Höhenkorrekturen. Verändert das Fahrzeug seinen Standort, welcher per GPS feststellbar ist, können eventuell benötigte Funktionen zum Download bereitgestellt werden. Eine weitere Anwendung liegt in den Nutzungsdaten eines Fahrzeugs, woraus sich Versicherungsbeiträge oder Leasingkosten ableiten lassen. Auch für den Gebrauchtwagenmarkt sind diese Daten ein wertvoller Indikator für die Beurteilung des Fahrzeugwerts oder der Abnutzung des Motors, aber auch für die Abschätzung der Restlebensdauer. Für Sicherheitsaspekte kann das vernetzte Fahrzeug ebenfalls einen Beitrag leisten. Prinzipiell kann ein gestohlenes Fahrzeug geortet und im Zweifelsfall stillgelegt, Falschfahrern durch erzwungene Fahrmanöver beigekommen werden. Durch vernetzte Navigation ist eine deutliche Verbesserung für ökonomisches und ökologisches Fahren erzielbar (Green Driving), beispielsweise durch Nutzung der Verkehrsinformationen oder Hinweisen an den Fahrer zu verbrauchsreduziertem Fahren [57].

4 Anwendungsbeispiel Applikation

4.1 Messdatenerfassung Mit dem vernetzten Fahrzeug ist es technisch nicht möglich, Messdaten in unbegrenzter Weise zu verschicken und zu empfangen. Dies liegt einerseits an den limitierten Datenraten des Mobilfunknetzes und des Datenbusses (siehe Kapitel 2), andererseits an der enormen Datenmenge, die an modernen Fahrzeugen generiert wird. Ein Auto im unteren Mittelklasse-Segment erzeugt mit den verbauten Sensoren 25 Gigabyte Daten pro Stunde [85]. In einem autonom fahrenden Kraftfahrzeug werden pro Sekunde gar etwa ein Gigabyte Rohdatenstrom anfallen [3]. Außerdem sollen bis zum Jahr 2020 etwa 90 Millionen Fahrzeuge vernetzt sein, wodurch insgesamt Datenmengen im Terra- und Petabyte Bereich entstehen [26], die theoretisch ausgewertet werden können. Die so gesammelten Daten haben für Serien- und Entwicklungsaufgaben ein sehr vielfältiges Anwendungsspektrum, jedoch müssen diese auch sinnvoll gefiltert, plausibilisiert und ausgewertet werden. Je nach Anwendungsfall kann die Datenreduktion sehr unterschiedlich aussehen, wobei verschiedene Methoden zur Verfügung stehen. Aber selbst, wenn es möglich wäre, unbegrenzt Daten zu übermitteln und zu speichern, ist der Nutzen dieser Daten stets zu hinterfragen. Oft entsteht eine Art Datensättigung, wodurch neue gewonnene Daten keinen Mehrwert für die verfolgte Aufgabe darstellen. Am Beispiel des Applikationsprozesses für ein physikalisches Modell ist nach einiger Zeit der Punkt erreicht, in der die Parametrierung nicht mehr oder nur noch sehr geringfügig verbessert werden kann. Weitere Messdaten bieten dann keine hinreichend neue Information, um die Modellanpassung weiter zu optimieren. Jedoch muss auch berücksichtigt werden, dass es keine Messdaten gänzlich ohne Information gibt oder sich neue Informationen erst durch spezielle Randbedingungen ergeben (z.B. Höhenerprobung). Auch ist der Zeitstempel ein wichtiges Kriterium zur Beurteilung von Messsignalen. Daten, die heute noch Gültigkeit besitzen, können © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 L. Hagen, Neue Möglichkeiten für die Motorsteuergeräte- Software durch Car-to-Cloud-Vernetzung, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-31565-8_4

52

4 Anwendungsbeispiel Applikation

morgen schon veraltet sein. Auch hier kann das Beispiel des Applikationsprozesses sehr gut herangezogen werden: Basiert eine SW-Funktion A auf einer SW-Funktion B, so kann durch die Querabhängigkeit eine bereits als zufriedenstellend angesehene Parametrierung von Funktion A durch eine späte SWAnpassung in Funktion B ihre Gültigkeit verlieren. Um eine effiziente Datenfilterung gewährleisten zu können, muss ein tiefes Systemverständnis in all seinen technischen Querwirkungen vorhanden sein. Das Expertenwissen von erfahrenen Entwicklungsingenieuren hat hier eine eminente Bedeutung, das durch die neu zugänglichen Felddaten durch das vernetzte Fahrzeug unterstützt werden kann. Im Folgenden sind Merkmale für Messdaten dargestellt, die sehr vielfältig sind und denen im Zuge des vernetzten Fahrzeugs besondere Bedeutung zukommen. • • • • • • • • • • • • •

Messgenauigkeit (z.B. Zeitraster, Quantisierung, Wertebereich) Zeit (z.B. Zeit der Aufzeichnung, Änderung von Randbedingungen) Ort (z.B. Stadt, Land, Region) Fahrzeugzustand (z.B. Kilometerstand) Fahrzeugnutzung (z.B. “Stadtfahrzeug”, “Autobahnfahrzeug”) Fahrzeug (z.B. Entwicklungsfahrzeug oder Serienfahrzeug) Fahrer (z.B. Testfahrer, aggressiver Fahrer, passiver Fahrer) Umgebungsbedingungen (z.B. Temperatur, Druck, Feuchte) Umfang (z.B. Messsignale, Programmstand) Vielfalt (z.B. Leerlauf, Teil-, und Volllast) Art (z.B. Rohdaten, komprimierte oder aggregierte Daten) Verfügbarkeit (z.B. Echtzeitdaten, mit Verzögerung) ...

Die Messgenauigkeit mit ihren Ausprägungen wie Zeitraster, Quantisierung oder Wertebereich stellt eine sehr wichtige Eigenschaft von Messdaten dar. So können Messdaten, die zu gering abgetastet werden, für eine Anwendung unbrauchbar sein. Wie im vorherigen Abschnitt erwähnt, ist die Zeit einer Aufzeichnung ebenfalls von hoher Wichtigkeit. So kann die Bewertung einer Messung innerhalb des Entwicklungsprozesses ihre Gültigkeit verlieren, falls Quer-

4.2 Messdatenreduktion

53

wirkungen bestehen oder sich Randbedingungen geändert haben (z.B. der Entfall eines Sensors). Der Ort gibt Aufschluss über beispielsweise Luftqualität oder Höhenprofil, welche zur Interpretation von Signalverläufen wichtig sein können. Fahrzeugzustand, Entwicklungszeitpunkt und Fahrer haben Einfluss auf die Nutzbarkeit von Messungen, genauso wie die Umgebungsbedingungen (Temperatur, Druck, Feuchte). Bei der Analyse von Signalverläufen ist auch der Messumfang ein wichtiges Kriterium, ob die Messung überhaupt für eine Anwendung nutzbar ist oder benötigte Signale fehlen. Ebenfalls hat die Vielfalt der Daten entscheidenden Einfluss: Es hilft nicht, wenn beispielsweise 10 Stunden Leerlauf, aber kein Volllastpunkt gemessen wird. Prinzipiell sind Rohdaten in ihrer Qualität immer besser als komprimierte oder aggregierte Daten, da in ihnen noch alle Informationen vorliegen. Jedoch muss dies mit einem erhöhten Speicher- und Datenaufkommen erkauft werden. Die Verfügbarkeit von Daten ist für Online-Anwendungen wichtig. Insgesamt kann festgehalten werden, dass die Datenauswahl mit anschließender Datenfilterung bzw. Messdatenreduktion anwendungsspezifisch erfolgen muss und ein Erfolgskriterium für den Einsatz des vernetzten Fahrzeugs in der Motorsteuerung darstellt.

4.2 Messdatenreduktion Die Reduktion von Messdaten ist also notwendig, um den Mobilfunkkanal und den Fahrzeugbus zu entlasten. Die Devise hierbei lautet: “So wenige Daten wie möglich, aber so viele wie nötig”. Die Selektion von relevanten Messdaten kann in zwei Schritten erfolgen. Zunächst müssen die benötigten Messgrößen identifiziert werden, also die Definition der Merkmale aus Abschnitt 4.1, beispielsweise: • Welche Messgrößen mit welcher Messgenauigkeit? • Zu welcher Zeit, an welchem Ort? • ...

54

4 Anwendungsbeispiel Applikation

Um die Messdaten in einem weiteren Schritt im Fahrbetrieb zu filtern, lassen sich diese komprimieren, aggregieren oder über mathematische Methoden nach deren aktueller Relevanz klassifizieren. Zum Beispiel kann das Auftreten bestimmter Betriebszustände akkumuliert werden, sodass nicht jeder einzelne Datenpunkt über die Luftschnittstelle übertragen wird. Da sich diese Arbeit vorrangig mit modellbasierten Ansätzen beschäftigt, wird nun ein Algorithmus zur Datenreduktion basierend auf der Fisher-Information und Cramér-Rao Ungleichung (siehe Kapitel 2.3) beschrieben. Gegeben sei ein mathematisches Modell mit den Parametern p und der ModellAusgangsgröße y˜ k , wobei k einen diskreten Abtastschritt darstellt. Des Weiteren werden N Messzeitpunkte zu einem Messabschnitt q zusammengefasst, siehe Abb. 4.1. Für einen Messabschnitt q wird außerdem die Fisher-Information FIM(q) berechnet. Über einen Abgleich mit bereits verfügbaren informativen Messabschnitten, deren Informationsgehalt gesammelt in der globalen FisherInformation FIMglobal vorliegt, kann eine Beurteilung des Informationsgehalts des aktuellen Messabschnitts q erfolgen. Dies geschieht anhand der Reduktion der Parameter-Schätzfehler σ p , welche sich über die Cramér-Rao Ungleichung bestimmen lassen. Die einzelnen Berechnungsschritte des Algorithmus sind im Folgenden dargestellt: 1. Initialisierung der globalen Messinformation, falls noch keine Messung vorhanden gilt ⎛ ⎞ 0 ... 0 ⎜ ⎟ FIMglobal = ⎝ ... . . . ... ⎠ 0

... 0

2. Berechnung der FIM des aktuellen Messabschnitts q   ∂ y˜ T −1 ∂ y˜  FIM(q) = ∑  Ctk ∂ p  tk k=1 ∂ p tk Nq

Gl. 4.1

3. Berechnung einer temporären FIM FIMtemp = FIMglobal + FIM(q)

Gl. 4.2

4.2 Messdatenreduktion

55

4. Berechnung der Parameter-Schätzfehler σ p (FIMtemp ) und σ p (FIMglobal )

Gl. 4.3

5. Bestimmung des Informationsgehalts des aktuellen Messabschnitts   I f σ p (FIMtemp ) < σ p (FIMglobal ) · Faktor , Faktor ∈ [0...1] Gl. 4.4 FIMglobal = FIMtemp ⇒ aktueller Messabschnitt ist in f ormativ   Else i f σ p (FIMtemp ) ≥ σ p (FIMglobal ) · Faktor FIMglobal = FIMglobal

Gl. 4.5

Gl. 4.6 Gl. 4.7

⇒ aktueller Messabschnitt ist nicht in f ormativ

Abbildung 4.1: Bestimmung des Informationsgehalts von Messdaten

Somit lässt sich für jeden neuen Messabschnitt eine Aussage zu dessen Informationsgehalt treffen. Außerdem sind die Berechnungsschritte 2 bis 5 für jeden neuen Messabschnitt auszuführen und in einer Schleife automatisierbar.

56

4 Anwendungsbeispiel Applikation

Durch die Fisher-Information ist es also möglich, in einer einzigen Matrix die gesammelten Messinformationen zur Parameteridentifikation zusammenzufassen. Dies ist hilfreich, um über mehrere Fahrzyklen hinweg oder zwischen verschiedenen Fahrzeugen, die bereits vorliegenden Messinformationen mathematisch darzustellen.

4.3 Konzept zur vernetzten Applikation

Fahrzeug

Cloud

pme

Vermessung

n

Flashen des Applikationsstands

y xn 

xn 

f  xn f  xn

Optimierung

Referenz

Modell t

Basis-Applikation

Auswertung der Messabschnitte + Bestimmung Informationssgehalt der Messabschnittee

Übertragung der informativen Messabschnitte

Prüfstand

xn 

xn 

f  xn f  xn

Parameteroptimierung

Auf Fahrzeug(e) zugeschnittener Applikationsstand sen ü Wissen über vorhandene Messungen

Abbildung 4.2: Applikationskonzept mit dem vernetzten Fahrzeug

Der Aufwand zur Abstimmung aller Steuer-, Regel- und Diagnosefunktionalitäten auf ein Motorkonzept hat stark zugenommen [11]. Ein unbestrittenes Ziel in der Automobilindustrie ist es daher, den Applikationsprozess möglichst zu automatisieren, um Kosten und Zeit einzusparen. In der Literatur wird das Thema Automatisierung aber hauptsächlich mit Bezug auf die Versuchsdurchführung und Parameteroptimierung am Prüfstand betrachtet, z.B. in [54] [81] [11].

4.3 Konzept zur vernetzten Applikation

57

Das vernetzte Fahrzeug bietet nun durch die Anbindung an den Mobilfunk die Möglichkeit, Daten vom Fahrzeug heraus und in das Fahrzeug hinein zu übertragen, wodurch prinzipiell eine Automatisierung des Applikationsprozesses am Fahrzeug ermöglicht wird. Dies liegt einerseits an der Speichermöglichkeit von Messdaten des Applikationsfahrzeugs auf der Cloud, welche zur Erstellung einer Applikation notwendig sind, andererseits an der hohen externen Rechenkapazität zur Nutzung von entsprechenden Optimierungsalgorithmen. Folglich kann durch die Vernetzung des Fahrzeugs der Applikationsprozess vom Fahrzeug auf die Cloud verlagert werden. In Abb. 4.2 ist ein Konzept dargestellt, wie der Applikationsprozess zukünftig unter Einbeziehung der Fahrzeugvernetzung aussehen könnte. Die drei Hauptebenen Prüfstand, Fahrzeug und Cloud spannen hierbei den Raum der einzelnen Arbeitsschritte auf. Der konventionelle Applikationsprozess findet zunächst oftmals überwiegend am Prüfstand statt und wird als Basisapplikation bezeichnet. Diese Applikation kann anschließend am Fahrzeug erprobt und validiert sowie weiterhin an speziellen, nicht oder nur unter hohem Aufwand am Prüfstand realisierbaren Fahrszenarien optimiert werden (Fahrbarkeitsapplikation). Dieses Prozedere wird solange durchgeführt, bis ein Gütekriterium erfüllt ist. Das beschriebene konventionelle Vorgehen lässt sich durch die Hinzunahme des Mobilfunkkanals erweitern, indem der Arbeitsschritt der weiteren Optimierung am Fahrzeug auf die Ebene Cloud ausgelagert wird. Hierfür werden Messdaten, die zur Erstellung eines neuen Applikationsstands erforderlich sind, vom Fahrzeug auf die Cloud übertragen. Dies sollte jedoch nur dann geschehen, wenn ein Messabschnitt genügend Informationen liefert, sodass die Mobilfunkanbindung entlastet wird. Der neu erstellte Applikationsstand, welcher durch einen Optimierer auf der Cloud entstanden ist, kann anschließend auf das Applikationsfahrzeug rückübertragen und verwendet werden. Prinzipiell lässt sich der Algorithmus auch auf eine ganze Fahrzeugflotte erweitern, wodurch mehrere Fahrzeuge einen gemeinsamen Datenstand erzeugen oder eine individuelle Applikation entsteht, siehe hierzu Kapitel 3.3. Im Folgenden werden die einzelnen Ebenen des Algorithmus detaillierter betrachtet.

58

4 Anwendungsbeispiel Applikation

4.3.1 Ebene Prüfstand Die Grundlage zur Erstellung einer Basisapplikation für eine Vielzahl von Funktionalitäten auf dem Motorsteuergerät sind die Messergebnisse eines Motorenprüfstands. Die anzufahrenden Messpunkte werden hierfür durch eine entsprechende Versuchsplanung ausgewählt, wie etwa der statistischen Versuchsplanung (auch als Design of Experiments (DoE) bekannt). Die so gesammelten Daten werden aufbereitet, plausibilisiert und anschließend zur Parameterbestimmung verwendet, um einen neuen Datenstand zu generieren, der ein definiertes Gütemaß bestmöglich erfüllen soll. Falls mit den aufgezeichneten Daten dieses Ziel nicht erreicht wird, ist das Prozedere in einer oder mehreren Iterationsschleifen zu wiederholen, um noch fehlende oder neu geforderte Datenpunkte zu vermessen. Ist das Gütekriterium zufriedenstellend erreicht, ist der erzeugte Datenstand in Form von Kennwerten, Kennlinien oder Kennfeldern anschließend auf dem Steuergerät nutzbar. Die entsprechenden Daten werden üblicherweise in einer Textdatei (z.B. .dcm) gesichert und auf den Programmcode übertragen. Versuchsplanung

Start

- stationäre Rastervermessung - statistische Versuchsplanung (DoE) - quasistationäre Vermessung - dynamische Vermessung ...

Iteration i=1...n

Vermessung

- manuell - halb-automatisiert - vollautomatisiert ...

Auswertung

- Datenaufbereitung - Datenplausibilisierung - manuelle Bedatung - Modellanalyse - Parameteroptimierung - Parameterschätzung ...

Gütekriterium erfüllt?

ja

Ende .a2l .hex

nein

Abbildung 4.3: konventionelles Vorgehen zur Basisapplikation

4.3.2 Ebene Fahrzeug Daraufhin wird der Basis-Applikationsstand vom Prüfstand oder ein Datenstand von einem Vorgängerprojekt auf die Fahrzeugflotte übertragen, indem

4.3 Konzept zur vernetzten Applikation

59

der Flash-Speicher des Steuergeräts mit diesen Daten beschrieben wird. Am Fahrzeug findet zunächst eine Plausibilisierung statt, d.h. liefert die Bedatung vom Prüfstand auch plausible Ergebnisse während der Erprobung am Fahrzeug. Darauf aufbauend können Anpassungen des Datensatzes notwendig sein. Dies ist dann der Fall, wenn die Erwartungen an die Applikation am Fahrzeug nicht erfüllt oder weitere Parameter zu bedaten sind, welche sich am Prüfstand nicht oder nur schwierig bestimmen lassen. Als Beispiel seien hier hochdynamische Vorgänge genannt, welche sich nur am Zielfahrzeug realisieren lassen oder Komfortfunktionen, welche das subjektive Fahrempfinden erfordern. Im Fahrzeug werden so lange Iterationen aus neuen Messungen und neuen Datenständen durchgeführt, bis das Applikationsergebnis als zufriedenstellend angesehen wird. Im konventionellen Applikationsprozess wäre nun die Bedatung einer Funktionalität abgeschlossen, siehe Abb. 4.4. Start

Auswertung

Erprobung am Fahrzeug

Applikation Prüfstand oder Projekt .a2l .hex - Datenaufbereitung - Datenplausibilisierung - Modellanalyse - Modellgüte ...

- Straßenerprobung - Rollenprüfstand - Höhenerprobung - Kälteerprobung - Hitzeerprobung ...

Gütekriterium erfüllt?

ja

Ende .a2l .hex

Optimierung optimierte Applikation vom Fahrzeug

xn 

xn 

- manuell - numerisch ...

f  xn f  xn

nein

Abbildung 4.4: konventionelles Vorgehen zur Fahrzeugapplikation

Um die Cloud in den Applikationsprozess einzubeziehen, müssen dieser Messdaten vom Applikationsfahrzeug zur Verfügung gestellt werden. Um die Auslastung des Mobilfunks dabei optimal zu gestalten, ist bereits auf dem Fahrzeug eine Vorfilterung der Messdaten notwendig. Dies kann durch die Bewer-

60

4 Anwendungsbeispiel Applikation

tung des Informationsgehalts eines Messabschnitts erfolgen. Ist der Informationsgehalt eines Messabschnitts groß genug, wird dieser über den Mobilfunk auf die Cloud übertragen, andernfalls wird er auf dem Fahrzeug gelöscht. Die Echtzeitanbindung ist für den Algorithmus nicht von übergeordneter Bedeutung, daher werden die gefundenen Messabschnitte in einem Zwischenspeicher gesammelt. Um den Informationsgehalt eines Messabschnitts zu beurteilen, können Parameter-Schätzverfahren angewendet werden. Hierfür bietet sich bei modellbasierten, zeitdiskreten Modellen in besonderem Maße die so genannte Fisher-Information an, welche in Verbindung mit der Cramér-Rao Ungleichung Auskunft über den minimal zu erreichenden Parameterschätzfehler liefern kann (vgl. Kapitel 4.2). VCU ECU Signale

Parametersensitivitäten des Modells

Berechnung FIM des aktuellen Messabschnitts Beurteilung des Informationsgehalts des aktuellen Messabschnitts

Cloud

Zwischenspeicher für Upload

Abbildung 4.5: Algorithmus auf der VCU

Aufgrund der erhöhten Rechenleistung einer VCU im Vergleich zu einer ECU, erfolgt die Bestimmung des Informationsgehalts eines Messabschnitts auf dem Domänenrechner, siehe Abb. 4.5. Hierzu sind die Parametersensitivitäten des Modells zu berechnen, welche dann zu den Schätzfehlern der Parameter führen. Falls ein Messabschnitt genügend Informationen zur Parameterbestimmung liefert, wird dieser in einen Zwischenspeicher übertragen und bei vorhande-

4.3 Konzept zur vernetzten Applikation

61

ner Mobilfunkkonnektivität auf die Cloud übertragen. Ist die Messinformation hingegen zu gering, wird der Messabschnitt auf dem Fahrzeug gelöscht.

4.3.3 Ebene Cloud Messdaten Fzg. 1 . . . . .

Sammler von Messdaten

Trigger

Auswertung

Optimierung xn 1

Messdaten Fzg. n

xn 

f ( xn ) f ' ( xn )

- numerisch - manuell

- Modellanalyse - Modellgüte ...

Gütekriterium erfüllt?

nein

Globale FIM + Parameter

Trigger für weitere Messdaten

ja

Trigger zum Beenden des Algorithmus und Übertragung der Parameter auf ECU

Ende

Übertragung auf Fzg. 1...n

Abbildung 4.6: Algorithmus auf der Cloud

Auf der Cloud werden die Messdaten der involvierten Fahrzeuge in einem Datencontainer gesammelt, auf dessen Basis eine numerische Parameteroptimierung eingeleitet wird, beispielsweise am Ende einer Messfahrt oder nach einer Mindestanzahl von Messabschnitten. Außerdem wird die globale Messinformation (globale FIM) berechnet und an die Fahrzeuge verteilt (Abb. 4.6). Schließlich wird der gefundene Datensatz ausgewertet und dessen Güte beurteilt. Ist das Applikationsergebnis zufriedenstellend, ist die Applikation der betrachteten Funktion beendet. Falls nein, werden neue Messabschnitte zur Parameteroptimierung benötigt. Es finden so lange Iterationen aus neuen Messdaten und optimierten Datensätzen statt, bis ein Güte- oder Abbruchkriterium erreicht ist. In Abb. 4.7 ist der Signalfluss zwischen Fahrzeug und Cloud zusammenfassend dargestellt.

62

4 Anwendungsbeispiel Applikation Start ECU

VCU

Messdaten en

globale FIM / Parameter

Berechne Sensitivitäten / lokale Fisher-Information

Berechne Parameterschätzfehler

nein nein

Messabschnitt informativ?

Lösche Messabschnitt

ja Übertrage Messabschnitt auf Cloud

Gütekriterium erfüllt? Finale Parameter + Trigger Ende

Optimiere Parameter, Berechne globale FIM und Modellgüte

Cloud

ja

Ende

Abbildung 4.7: automatisierte Applikation durch Car-to-Cloud

4.4 Abgasgegendruckmodell Um das in Kapitel 4.3 beschriebene Konzept zu validieren, wird der Algorithmus am Beispiel einer Modellfunktion für den Abgasgegendruck (p3 ) getestet. Der Abgasgegendruck, also der Druck nach den Auslassventilen und vor der Turbinenseite des Abgasturboladers, ist eine auf dem Motorsteuergerät wichtige, physikalische Eingangsgröße für Regelfunktionen wie etwa die AGR-Regelung, um den AGR-Massenstrom zu erfassen. Aber auch für Diagnosefunktionen, beispielsweise Überwachungen des Turboladers, hat der Abgasgegendruck einen entscheidenden Einfluss [18]. Die Erfassung des Abgasgegendrucks kann entweder über einen Sensor oder ein mathematisches Modell erfolgen.

4.4 Abgasgegendruckmodell

63

Um ein Modell für verschiedene Motoren und Projekte einsetzen zu können, ist dieses entsprechend zu applizieren. Ein möglicher Ansatz zur Modellierung des Abgasgegendrucks auf dem Motorsteuergerät ist die Drosselgleichung, siehe Kap. 2.2.3. Hierfür wird die Gl. 2.5 bei gegebenem Turbinenmassenstrom m˙ Trb , der Temperatur im Auslasskrümmer T3 und dem Druck nach Turbine p4 entsprechend nach p3 umgeformt: p4 Gl. 4.8 p3 =  κ  1−κ   2 m ˙ ·R·T 1 1 1 3 Trb 2+ 4 + 2·A 2 ·p 2 · 1 − κ ef f

4

Die einzige zu parametrierende Größe ist in dieser Gleichung die effektive Turbinenfläche Ae f f . Bei einem VTG-Turbolader, wie in dem hier betrachteten Beispiel, hat das Tastverhältnis der VTG-Position sowie die Gasgeschwindigkeit entscheidenden Einfluss auf die durchströmte Querschnittsfläche der Turbine. Zur Bestimmung der Fläche sollte jedoch die Gasgeschwindigkeit nicht verwendet werden, da diese wiederum vom Abgasgegendruck abhängt. Als adäquate Ersatzgröße wird deshalb der Turbinenmassenstrom verwendet. Auf dem Steuergerät wird folglich die Turbinenfläche über ein Kennfeld mit den Eingangsgrößen VTG-Tastverhältnis sowie Turbinenmassenstrom abgelegt (hier: 16x16 Stützstellen). Das Blockdiagramm zu diesem Modell, welches in grafischen Entwicklungstools wie beispielsweise The Mathworks Matlab/Simulink® oder ETAS ASCET® entwickelt wird, zeigt Abb. 4.8.

Abbildung 4.8: p3 -Modell in Matlab/Simulink®

64

4 Anwendungsbeispiel Applikation

4.5 Offline Optimierung Das zuvor beschriebene Abgasgegendruckmodell wird zunächst mit stationären Messdaten vom Prüfstand bedatet. Hierzu wird eine für das Luftsystem übliche Rastervermessung verwendet, in der in äquidistanten Abständen die Motordrehzahl und die Kraftstoff-Einspritzmenge variiert wird, vgl. Abb. 4.9. Neben Steuergerätemessgrößen werden hierbei Zusatzsensoren des Prüfstands vermessen. Zur Applikation des Abgasgegendruckmodells ist ein Drucksensor im Auslasskrümmer zwingend erforderlich, welcher die Referenzgröße darstellt. Die Sensor- und Bauteilstreuungen werden nach Information des Autors bei der Applikationserstellung bei nahezu allen Anwendungen vernachlässigt. Somit stellt der betrachtete Prüfstandsmotor (oft auch goldener Motor genannt) das ideale System dar, dessen Messergebnisse sowohl für die Entwicklung als auch die Serie Bestand haben muss.

Abbildung 4.9: Lastpunktvariation am Prüfstand

4.5 Offline Optimierung

65

Abbildung 4.10: Basis-Kennfeld für Abgasgegendruckmodell

Auf Basis der so gewonnenen Daten berechnet nun ein Kennfeld-Optimierer die optimalen Werte und Stützstellen des Kennfelds, siehe Abb. 4.10. Zur Erstellung des Kennfelds wurde ein MATLAB-basierter Optimierungsalgorithmus der Robert-Bosch GmbH verwendet, welcher auf der LS-Methode basiert. Dabei kann über einen Faktor die Glattheit des Kennfelds bestimmt werden. Die Glattheit eines Kennfelds kann beispielsweise aus regelungstechnischer Sicht gefordert sein, um das System vor Instabilitäten zu bewahren. In dem hier betrachteten Beispiel des Abgasgegendruckmodells wird die Glattheit des Flächenkennfelds von der Luftmassenregelung gefordert. In Abb. 4.11 ist der Vergleich zwischen den Stationärpunkten aus bedatetem Abgasgegendruckmodell und -sensor dargestellt. Es ist ersichtlich, dass das Modell in nahezu allen Betriebspunkten den Referenzwert sehr gut wiedergibt.

66

4 Anwendungsbeispiel Applikation

Abbildung 4.11: Vergleich Modell / Sensor mit stationären Prüfstandsdaten

Abbildung 4.12: Modellgüte anhand stationärer Prüfstandsdaten

4.5 Offline Optimierung

67

In Abb. 4.12 werden verschiedene Kennwerte zur Beurteilung der Modellgüte sowie die Gauß-Verteilung des Modellfehlers dargestellt. Wichtige Beurteilungsgrößen sind der 3σ -Wert sowie der Mittelwert des Modellfehlers. In dem hier gezeigten Beispiel liegen also etwa 99,7 % aller Modellwerte in einem Intervall von ca. 92 hPa um den Mittelwert des Modellfehlers. Letzt genannter liegt bei etwa +20 hPa, dass so zu interpretieren ist, dass der modellierte Abgasgegendruck gegenüber dem Sensor im Mittel etwas zu hoch liegt. Da bei den hier beschriebenen Beurteilungskriterien die Trainingsdaten zur Applikationserstellung mit den Validierungsdaten übereinstimmen, ist davon auszugehen, dass die Modellgenauigkeit in weiteren Validierungsmessungen abnehmen wird. Zunächst wird der gefundene Datenstand aber noch im WLTC (Worldwide harmonized Light vehicles Test Cycle) betrachtet. In Abb. 4.13 sind die Abgasgegendruckverläufe für Sensor und Modell dargestellt. Wie schon für die stationären Prüfstandsdaten zeigt das Modell eine zufriedenstellende Modellgenauigkeit. Auffällig ist jedoch das umgekehrte Vorzeichen des Modellfehlers. In der gezeigten Zyklusmessung ist nun der Sensorwert im Allgemeinen etwas höher als der Modellwert, was besonders in den Sekunden 1200 bis 1300 zu erkennen ist.

Abbildung 4.13: Vergleich Modell und Sensor im WLTC

68

4 Anwendungsbeispiel Applikation

Abbildung 4.14: Modellgüte im WLTC

Bei Betrachtung der Modell-Kennwerte bestätigt sich der optische Eindruck. Der Mittelwert des Modellfehlers ist nun negativ mit einem Wert von etwa -72 hPa. Der Betrag des RMSE-Werts liegt bei etwa 97 hPa.

4.6 Online Optimierung Der erstellte Datenstand soll nun dazu verwendet werden, das Konzept zur Applikation mit dem vernetzten Fahrzeug aus Kapitel 4.3 zu validieren. In Abb. 4.15 ist die Versuchsstrecke dargestellt, welche rund um Stuttgart führt und eine Länge von circa 30 Kilometern hat. Diese startet auf dem Werksgelände der Robert Bosch GmbH in Schwieberdingen, führt über die B10 nach Stuttgart und von dort über die B295 zur Autobahn 81 zurück nach Schwieberdingen. Somit sind Autobahn, Land- und Stadtfahrt exemplarisch zur Applikationserstellung berücksichtigt.

4.6 Online Optimierung

69

NP

/XGZLJVEXUJ

5REHUW%RVFK6WUD‰H 6FKZLHEHUGLQJHQ

$

%

%

$6=XIIHQKDXVHQ 9HUVXFKVVWUHFNH NP %

$

'LW]LQJHQ

3RUVFKH0XVHXP

%

)HXHUEDFKHU :HLOLPGRUI 7XQQHO %

$

=XIIHQKDXVHQ

$6)HXHUEDFK %

)HXHUEDFK

%

%

%DG &DQQVWDWW

Abbildung 4.15: Versuchsstrecke rund um Stuttgart

Die Versuchsstrecke wird in Summe dreimal hintereinander gefahren, um die Datenreduktion beurteilen zu können. Nach jedem dieser drei Versuche wird im Anschluss ein Kennfeldoptimierer genutzt, um die Bedatung an die neu gefundenen, reduzierten Messdaten anzupassen. Zur Voruntersuchung werden in Abb. 4.16 die angefahrenen Kennfeldbereiche während der drei Versuchsfahrten veranschaulicht. Es ist zu erkennen, dass am Fahrzeug nahezu alle Kennfeldbereiche abgedeckt werden, die auch am Prüfstand zur Basisbedatung geführt haben. Lediglich bei Tastverhältnissen des VTG-Stellers zwischen 60 - 70 % und Turbinenmassenströmen größer 200 kg\h sind Betriebspunkte erkennbar, die in den Versuchsfahrten nicht abgedeckt sind. Hierfür waren die Lastpunkte während den Messfahrten nicht hoch genug. Eine entsprechen Messvorschrift für den Fahrer könnte dies jedoch erzielen, zum Beispiel durch eine Meldung auf dem Fahrzeugdisplay. Es gibt auch Kennfeldbereiche, die nur vom Fahrzeug angefahren werden. Dies sind dynamische Messpunkte, die beispielsweise während Beschleunigungsvorgängen auftreten.

70

4 Anwendungsbeispiel Applikation

Abbildung 4.16: Kennfeldpunkte Vgl. Prüfstand zu Versuchsfahrten 1+2+3 gesamt Per Parameterstudie werden die Bewertungskriterien zur Bestimmung des Informationsgehalts eines Messfensters ermittelt. Das Ziel ist es, so viele Daten wie nötig, aber so wenige wie möglich zu finden. Die folgende Parameterkombination hat sich für das betrachtete Abgasgegendruckmodell als zielführend erwiesen. Tabelle 4.1: Bewertungskriterien der Messfenster für Applikationskonzept Kriterium Messabschnittslänge tq Mindestanzahl informative Parameter je Messabschnitt Reduktion der Parameter-Schätzfehler je Messabschnitt

Ausprägung 50 Sekunden ≥8 > 20 %

Das Resultat der Messdatenreduktion von Versuchsfahrt 1 ist in Abb. 4.17 dargestellt. In der Abbildung ist in grün der Modellwert und in schwarz der Sensorwert für den Abgasgegendruck dargestellt. Die grau hinterlegten Bereiche stellen Messabschnitte dar, die nicht genügend Informationen beinhalten. Im Zielsystem würden diese Messabschnitte somit als “nicht relevant” klassifiziert und bereits auf dem Fahrzeug gelöscht. Es ist zu erkennen, dass zu Beginn

4.6 Online Optimierung

71

der Messfahrt sehr viele Messabschnitte durch den Algorithmus als informativ bewertet werden. Dies macht insofern Sinn, da der Wissensspeicher von Messdaten zu Beginn noch leer ist. Danach werden immer weniger relevante Messabschnitte gefunden, bis schließlich ab Sekunde 1900 bis Messungsende keine weiteren informativen Messbereiche mehr gefunden werden. Bei Betrachtung der Abgasgegendruckverläufe von Versuchsfahrt 2 in Abb. 4.18 werden schon deutlich weniger relevante Messabschnitte gefunden. Lediglich drei Messabschnitte, also in Summe 150 Sekunden, hatten einen ausreichend hohen Informationsgehalt, um das Kriterium in Tab. 4.1 zu erfüllen. In Versuchsfahrt 2 werden so etwa 93 % der Messdaten als nicht informativ klassifiziert.

Abbildung 4.17: Versuchsfahrt 1

72

4 Anwendungsbeispiel Applikation

Abbildung 4.18: Versuchsfahrt 2

Die Versuchsfahrt 3 wird in Abb. 4.19 dargestellt. Die Messdaten werden bis auf einen einzigen Messabschnitt als irrelevant klassifiziert, womit so gut wie keine weiteren Daten über die Mobilfunkleitung versendet werden und somit eine elementare Reduktion der anfallenden Messdaten erzielt wird. Das dies tatsächlich keinen Informationsverlust bedeutet, wird im Folgenden erläutert.

Abbildung 4.19: Versuchsfahrt 3

4.6 Online Optimierung

73

Abbildung 4.20: Kennfeldpunkte Vgl. Prüfstand zu Versuchsfahrten 1+2+3 reduziert

In Abb. 4.20 sind die angefahrenen Kennfeldpunkte für die reduzierten Messdaten dargestellt. Bei Vergleich mit Abb. 4.16 fällt auf, dass keine wesentliche Messinformation durch die Reduktion der Messdaten verloren geht. Nach wie vor ist der Bereich, indem die Prüfstandspunkte angesiedelt sind mit Ausnahme der höherlastigen Punkte, sehr gut abgedeckt. Bei Vergleich zweier wesentlicher Gütemaße zur Modellbewertung (Mittelwertfehler und Root Mean Squared Error (RMSE)) wird dieser Eindruck bestätigt. Die Basisapplikation vom Prüfstand erreicht im Vergleich zu den am Fahrzeug erstellten Applikationsständen nicht die gleiche Güte, siehe Tab. 4.2. Dies ist nicht weiter verwunderlich, da sowohl der Motor als auch die Messdaten zur Applikationserstellung unterschiedlich sind. Auffällig ist aber der geringe Unterschied der Applikationsgüte bei Vergleich zwischen allen verwendeten Daten (Zeile 2) und den reduzierten Messdaten, die sich durch Anwendung des Fisher-Algorithmus ergeben (Zeile 3). Bei Verwendung von nur 15 % der Messdaten ist ein ähnlich gutes Applikationsergebnis erzielbar, wie wenn alle Messdaten verwendet worden wären. Dieses Ergebnis wird in einer Validierungsmessung mit einer Dauer von etwa 3h bestätigt.

74

4 Anwendungsbeispiel Applikation

Tabelle 4.2: Gütemaße für die Versuchsfahrten 1,2 und 3

Basisapplikation Prüfstand Applikation mit allen Daten Applikation mit red. Daten

Mittelwertfehler

RMSE

Messdatenreduktion

-24,9 hPa

95,58 hPa

-

2,75 hPa

82,25 hPa

-

-7,79 hPa

83,97 hPa

85 %

4.7 Zusammenfassung Der Umfang und Zeitbedarf zur Applikation von Motorsteuergeräten ist aufgrund der gestiegenen Anzahl von Funktionen, Stellgrößen und variablen Parametern exponentiell gewachsen [54]. Gleichzeitig steigt die Bedeutung der Applikation, da der Einfluss auf Verbrauch, Emissionen und Leistung sehr hoch ist. Bei Betrachtung des heutigen Applikationsprozesses fällt auf, dass gerade am Fahrzeug ein hohes Optimierungspotential in Hinblick auf Effizienz und Flexibilität zu sehen ist. So geschieht die Applikation am Fahrzeug häufig manuell, wodurch das subjektive Empfinden des Ingenieurs einen hohen Einfluss auf die Applikationsgüte nimmt [46]. Zudem wird der erstellte Datenstand basierend auf den Messdaten von nur einem oder wenigen Fahrzeugen erzeugt, wodurch Effekte wie Bauteilstreuungen, Sensortoleranzen, Fahrzeugoder Motorstreuungen sowie Alterungserscheinungen häufig außer Acht gelassen werden. Die sinkende Anzahl an teuren Versuchsträgern trägt außerdem dazu bei, dass die Erzeugung von Messdaten immer schwieriger wird. Aber auch die Flexibilität innerhalb des Applikationsprozesses ist limitiert, da der externe Zugriff auf Fahrzeugmessgrößen bislang nicht möglich ist. In diesem Kapitel werden Eigenschaften von Messdaten diskutiert und Möglichkeiten zur Reduktion dieser Daten genannt. Es wird außerdem ein Algorithmus basierend auf der Fisher-Information zur Datenreduktion mit Hilfe der

4.7 Zusammenfassung

75

Parameterschätzung gezeigt. Denn die Qualität und Aussagekraft von Messdaten ist beim vernetzten Fahrzeug von übergeordneter Bedeutung, da die limitierte Datenrate des Mobilfunkkanals berücksichtigt werden muss. Es ist sicherzustellen, dass so wenige Messdaten wie möglich aber so viele wie nötig übertragen werden. Anhand eines konkreten Beispiels wird der heutige Applikationsprozess sowie eine Erweiterung mit dem vernetzten Fahrzeug aufgezeigt. Die Basisapplikation eines Drosselmodells für den Abgasgegendruck (p3 ) wird zunächst offline am Prüfstand erstellt. Darauf aufbauend wird dieser Applikationsstand in Versuchsfahrten auf ein Fahrzeug zugeschnitten. Um die Messdaten zu reduzieren, werden auf dem Fahrzeug vor dem Upload die informativen Daten zur Applikationserstellung vorgefiltert. Dies geschieht mit Hilfe eines sensitivitätsbasierten Algorithmus zur Parameterschätzung. Dabei ist es möglich mit nur 15 % der anfallenden Messdaten eine ähnlich gute Applikationsgüte zu erzielen, wie wenn alle Messdaten verwendet worden wären. Das Beispiel zeigt, dass eine erhebliche Datenreduktion möglich ist. Wie hoch die Datenreduktion in anderen Anwendungen ist, hängt von der Funktion, der Parametrierung des Algorithmus sowie den Messfahrten ab. Aber generell bietet das Verfahren einen mathematisch begründeten Ansatz, wie gezielt Messdaten vorgefiltert und reduziert werden können. Der gezeigte Algorithmus hat außerdem mehrere Anwendungsmöglichkeiten: Einerseits kann er in der Entwicklung zur automatisierten Erstellung eines Applikationsstands genutzt werden. Andererseits ist es aber auch denkbar, die Applikation auf Fahrer, Fahrzeug, Standort oder Verkehrslage in Serienanwendungen “maßzuschneidern”. Die Vernetzung des Fahrzeugs schafft die Möglichkeit, den Applikationsprozess zu verbessern, wobei insbesondere die Automatisierung und die Individualisierung von Datenständen hervorzuheben sind. Somit lassen sich die Applikationsqualität erhöhen, aber auch Entwicklungszeit und -kosten senken.

5 Anwendungsbeispiel Diagnose

5.1 Konzept Im Folgenden wird ein Konzept vorgestellt, welches die hohe Rechenleistung der Cloud durch einen modellbasierten Diagnoseansatz ausnutzt und gleichzeitig die zu übertragende Datenmenge über den Mobilfunk durch einen Algorithmus zur Parameterschätzung reduziert. Somit ist eine effektive und effiziente Fehlerdiagnose darstellbar. Vorteile sind eine genauere Lokalisierung der Fehlerursache und Fehlerschwere gegenüber heutigen Diagnoseverfahren. In Abb. 5.1 ist das Flussdiagramm zum erstellten Diagnosekonzept dargestellt. Auf der ECU werden zunächst Merkmale ausgewertet, die zur Fehlererkennung am Motor genutzt werden. Ist ein Fehler detektiert, wird dieser ohne die genaue Fehlerursache zu kennen über den CAN-Bus an die VCU gemeldet. Diese Botschaft wird an die Cloud weitervermittelt, woraufhin ein Diagnosekoordinator dem Fahrzeug ein Software-Paket zur Analyse der Messdaten bereitstellt. Mit dieser Software kann das Fahrzeug die relevanten Daten herausfiltern, welche zur Diagnose benötigt werden. Dies dient dazu, nur die informativsten Messdaten zur Diagnose über den Mobilfunk verschicken zu müssen. Anschließend wird ein physikalisches Prozessmodell auf der Cloud stimuliert, welches den Nominalzustand des Systems darstellt. Über Abgleich mit den Sensordaten des Fahrzeugs ist schließlich über ein Modellreferenzverfahren die Fehleridentifikation möglich. Das Diagnoseergebnis wird anschließend an das Fahrzeug zurückgemeldet. Das Fahrzeug interpretiert dieses Ergebnis und könnte nun verschiedene Aktionen ausführen, z.B.: • • • •

Meldung des Fehlers über das Fahrzeugdisplay Anweisung an den Fahrer Motor-Ersatzreaktion Anruf / Terminvereinbarung Werkstatt

© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 L. Hagen, Neue Möglichkeiten für die Motorsteuergeräte- Software durch Car-to-Cloud-Vernetzung, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-31565-8_5

78

5 Anwendungsbeispiel Diagnose

Start Messdaten M

ECU

Ende Fehler erkannt?

Diagnoseergebnis

System intakt

nein

ja Fehler in System! Meldung des Fehlers

VCU MessungsAnalysierer

SW-Paket

Informativer Messabschnitt ?

nein

Lösche Messabschnitt

ja Diagnosekoordinator

Cloud

nominales Verhalten

Fehleridentifikation Residuen

Prozessmodell

Paritätsgleichungen

Speicher für sensitive Messabschnitte

fehlerhaftes Verhalten

Abbildung 5.1: Diagnosekonzept für das vernetzte Fahrzeug

5.1.1 Ebene Fahrzeug Im Fahrbetrieb werden auf dem Motorsteuergerät (ECU) kontinuierlich ein oder mehrere Kriterien berechnet, welche den Motor auf Unplausibilitäten in den Sensordaten überprüfen sollen. Dabei wird das aktuelle, über Sensoren erfasste Prozessverhalten mit einem bekannten Nominalzustand verglichen. Da-

5.1 Konzept

79

bei kann das Referenzverhalten über physikalische Gesetzmäßigkeiten oder Expertenwissen bekannt sein. Mögliche Ansätze sind zum Beispiel: • Direkte Messwertbetrachtung, z.B. Grenzwertüberschreitung • Signalmodellbasierte Betrachtung, z.B. Amplituden-/Phasenverschiebung • Modellbasierte Betrachtung, z.B. Parameterschätzung Um die Robustheit zur Erkennung eines Fehlers zu erhöhen, ist ein üblicher Ansatz die Kriterien über einen längeren Zeitraum auszuwerten (Entprellung). Dies kann durch Filterung der Daten erfolgen, die in definierten Zeitintervallen zurückgesetzt werden. Im Falle eines erkannten Fehlers wird diese Information über die VCU an die Cloud gemeldet, woraufhin eine Messdaten-AnalyseSoftware auf das Fahrzeug heruntergeladen wird. Die Analyse der Messdaten erfolgt dann mit Hilfe eines (Fehler-)Parameterschätzverfahrens einzelner Messabschnitte (vgl. hierzu Kap. 4.2), d.h. sinkt die Varianz der Schätzung eines oder mehrerer (Fehler-)parameter um einen definierten Betrag, wird ein Messabschnitt als relevant klassifiziert. Anschließend werden die Messdaten in einem Upload-Speicher auf der VCU zwischengespeichert, die bei ausreichender Mobilfunkkonnektivität automatisch an die Cloud zu übertragen sind. Wenn im aktuellen Messabschnitt die Parameterschätzfehler-Varianz nicht ausreichend absinkt, wird der entsprechende Messabschnitt auf der VCU gelöscht.

5.1.2 Ebene Cloud Die zur Cloud übertragenen Messabschnitte enthalten Messgrößen zur Stimulation eines mathematischen Prozessmodells und zur Überwachung des Motorzustands (Prozessgrößen/Sensorgrößen). Das Prozessmodell kann dabei nahezu beliebig komplex ausgeführt sein, wodurch die hohen computertechnischen Ressourcen der Cloud gewinnbringend einsetzbar sind. Mit Bezug auf das Luftsystem sind beispielsweise auch 2D oder 3D - Strömungssimulationen (CFD-Simulationen) denkbar, die auf dem Steuergerät die Ressourcen bei weitem überlasten würden. Nach Auswahl eines geeigneten Prozessmodells kann somit das Intakt-Verhalten simuliert und dem aktuellen Zustand gegenübergestellt werden. Man spricht hierbei auch von Parität [33]. Die Differenz zwischen Intakt- und Ist-Verhalten wird als Residuum bezeichnet. Für ein Residuum ≈ 0 gilt das betrachtete System als intakt, bei Werten ungleich null als

80

5 Anwendungsbeispiel Diagnose

defekt. Bei Abgleich mehrerer Residuen bzw. Symptome ist es möglich, über bekannte Fehlerbilder auf deren Fehlerursachen zu schließen. Hierfür ist ein möglicher Ansatz die Darstellung über Fehler-Symptom-Tabellen, mit denen sich die kausalen Zusammenhänge zwischen Fehlern und Symptomen zeigen lassen [25].

5.2 Diagnose des Abgaskrümmer-Subsystems Das beschriebene Konzept aus Abschnitt 5.1 wird im Folgenden anhand eines Beispiels aus dem Diesel-Luftsystem simulativ validiert. Betrachtet werden hierbei Fehler im Bereich des Abgaskrümmers, also solchen die zwischen den Auslassventilen und dem VTG-Turbolader sowie der HD-AGR Leitung auftreten können, siehe Abb. 5.2

Leckage

Sensor Abgasgegendruck Auslass -Ventil

VTG Aktuator

HD-AGR Ventil

Abbildung 5.2: untersuchte Fehler im Abgaskrümmer-Subsystem

Die untersuchten Fehlerfälle sind im Einzelnen: • • • • •

defekter Abgasgegendrucksensor (pos./neg. Offset 500 hPa) Leckage im Abgaskrümmer (1 cm2 ) offen klemmendes HD-AGR Ventil offen klemmender VTG-Aktuator geschlossen klemmender VTG-Aktuator

5.2 Diagnose des Abgaskrümmer-Subsystems

81

Ein Offset-Fehler des Abgasgegendrucksensors kann beispielsweise durch Verschmutzung bzw. Ablagerungen der Verbrennungsprodukte auf der Sensormembran entstehen. Leckagen im Bereich des Abgaskrümmers treten seltener auf, entstehen aber beispielsweise durch fehlerhafte Montage des Abgaskrümmers an den Turbolader. Geschlossen klemmende HD-AGR Ventile, welche für aktuelle Applikationen verstärkt elektrisch betätigt werden [5], haben häufig Versottungen oder elektrische Fehler zur Ursache. Bei klemmenden VTGAktuatoren sind die Fehlerursachen ähnlich denen eines HD-AGR-Ventils.

5.2.1 Diesel-Luftsystem in einer SiL-Umgebung   

?(

/12 '04 #


      


    

  

, 

 

   6

# 8-   ! " #  $%%



  2 /:048-   #47    8-

#  $ #  4  $  $04



  '*-   '8-

4  $

,&(

,/

 

 $  9

'/

 

 

 $04

 

 

4  $

  

,/ &3(

'/

&(  

'*

--,4

4 '8-

&3(

#  $  9 #  4  9

    #$ '*-

,/

 

 9

/12 '&.(

  4 

, #

#$ #47 

/- 0'&.(

/12 '

/12 '04 #

# 2 /:048-

/- &.(

4  5   

 

,- &.(

,-

,- #

&$ '

 

,-#&>?(

,- #

 

'/ &(

  --,4&=36(

--,4 #  *' 

 4  $

Abbildung 5.3: SiL Luftsystem-Modell in Matlab/Simulink® Zur Konzeptvalidierung wird eine Simulationsumgebung in Matlab/Simulink® verwendet, siehe Abb. 5.3. Dieses besteht aus einem Regelstreckenmodell (Luft/Abgassystem), einem daran gekoppelten Regler sowie einer extern aufgeprägten Last und den Umgebungsbedingungen. Außerdem enthält das Modell eine GUI (Graphical User Interface).

82

5 Anwendungsbeispiel Diagnose

Das Regelstreckenmodell basiert auf der Füll- und Entleermethode und ist daher ein 0D-Modell. Es bildet aufgrund des Anwendungsbeispiels hauptsächlich das Luft-/Abgassystem ab und besteht im Wesentlichen aus Volumina (z.B. Verrohrungen), Aktuatoren (z.B. AGR-Ventile, Drosselklappe), Kühlermodellen (z.B. Ladeluftkühler), einem kennfeldbasierten Turboladermodell sowie einem Ladungswechsel- und Verbrennungsmodell, siehe Abb. 5.4. Das Regelstreckenmodell liefert an allen wichtigen Positionen des Luft- und Abgassystems thermodynamische Größen wie Drücke, Temperaturen, Massenströme oder Gaszusammensetzungen. Die Parametrierung des Streckenmodells erfolgt auf Basis von Prüfstands- und Fahrzeugmessdaten, die sowohl in stationären als auch dynamischen Betriebspunkten erfasst sind. Kenngrößen zur Modellgüte sind im Anhang A.3 dargestellt.

Abbildung 5.4: Streckenmodell in Matlab/Simulink® Das zuvor dargestellte Streckenmodell ist mit einem Füllungs- und Ladedruckregler verknüpft. Der Füllungsregler hat die Aufgabe die gewünschte Menge an Luft-/Abgasgemisch in die Zylinder einzuregeln. Der Ladedruckregler regelt entsprechend seiner Sollwerte den Druck nach Verdichter. Die Software der beiden genannten Regler werden von ihrem Steuergeräte-Code in eine für Windows ausführbare Datei (.dll) umgewandelt. Da der Simulationscode dem Steuergerätecode entspricht, spricht man hierbei auch von einem SiL-Modell (Software-in-the Loop). Die Regler liefern die Stellsignale der von ihnen geregelten Aktuatoren. Dies sind für Ladedruck- und Füllungsregler hauptsächlich die Drosselklappe, das HD- und ND-AGR Ventil, die Abgasklappe und die VTG-Position der Turbine.

5.2 Diagnose des Abgaskrümmer-Subsystems

83

Die Simulationsumgebung benötigt als Anregung von außen (Stimulus) den Lastpunkt in Form von Motordrehzahl und Einspritzmenge sowie die Umgebungsbedingungen (Temperatur, Druck, Feuchte und Gaszusammensetzung). Die GUI soll das Bedienen der Simulationsumgebung vereinfachen. Sie kann dazu genutzt werden, die Umgebungsbedingungen anzupassen oder zwischen vordefinierten Fahrzyklen (MNEFZ, WLTC und RTS95) und manuellen Lastpunkten zu wählen. Außerdem ist das Starten und Stoppen einer Simulation möglich. Die Simulationszeit sowie die entsprechende Realzeit werden ebenfalls dargestellt.

(QYLURQPHQWDO&RQGLWLRQV S(QY>K3D@

7(QY>.@

S(QY

7(QY

6WLPXOXV 0DQXDOYLD*8,

2WKHU

'ULYLQJ&\FOHV 576

01()=

:/7&

6LPXODWLRQ&RQWURO 6WRS7LPH>V@ 6WDUWB6LP

6WRSB6LP

6LPXODWHGWLPHLVVHFRQGV (ODSVHGUHDOWLPHLVVHFRQGV

Abbildung 5.5: GUI für Simulationsmodell



84

5 Anwendungsbeispiel Diagnose

5.2.2 Fehleridentifikation Die Fehleridentifikation wird für das betrachtete Konzept analytisch in Form von Paritätsgleichungen durchgeführt. Der Ansatz hierbei ist es, einen bekannten Nominalzustand mit dem Istzustand zu vergleichen. Um dies zu tun, sind Merkmale bzw. Systemgrößen auszuwählen, bei deren Kombination sich im Fehlerfall die Fehlerursache bestmöglich identifizieren lässt. Um dies graphisch darzustellen, werden Fehler-Symptom-Tabellen genutzt. Der einfachste Fall liegt vor, wenn die Kombination verschiedener Symptome genau zu einer Fehlerursache führt. Für den Fall, dass die Kombination verschiedener Symptome zu mehreren Fehlerursachen führen kann, ist die Fehleridentifikation nicht möglich. Dann muss die Diagnose um mindestens ein Merkmal erweitert werden. Um geeignete Merkmale auszuwählen, muss dies entweder über Expertenwissen bekannt sein oder experimentell bestimmt werden. Hier dienen zur Analyse verschiedene Stationärpunkte, die in weiten Teilen das Motorkennfeld abdecken, siehe Abb. 5.6. Jeder Punkt wird vier Sekunden konstant gehalten, sodass sich stationäre Bedingungen einstellen können. Insgesamt werden so 27 Motorbetriebspunkte ausgewertet. Zur Diagnose der Fehler aus Abschnitt 5.2 haben sich folgende Merkmale als aussichtsreich herausgestellt: Der Abgasgegendruck p3 , der Saugrohrdruck p22 , die Position des ND-AGR Ventils, die Position der Abgasklappe sowie der HD-AGR Massenstrom. Die letztgenannte Größe wird am Fahrzeug nicht direkt erfasst, sondern über eine Massenbilanz an der Mischstelle zwischen Drosselklappen- und HD-AGR-Massenstrom ermittelt.

5.2 Diagnose des Abgaskrümmer-Subsystems

85

Abbildung 5.6: Betriebspunkte zur Voruntersuchung der Residuen

Abbildung 5.7: Residuen zur Fehleridentifikation

In Abb. 5.7 sind die Residuen für die fünf Merkmale und die untersuchten Fehlerfälle dargestellt. Die Residuen berechnen sich hier nach der folgenden

86

5 Anwendungsbeispiel Diagnose

Formel: Residuum = Merkmalde f ekt − Merkmalintakt

Gl. 5.1

Im Intaktfall sind die Residuen null, da für diesen Fall in der Simulation keine Differenz zwischen Referenzmodell und Ist-Modell dargestellt wird. Für ein offen klemmendes HD-AGR Ventil zeigt sich, dass insbesondere das Residuum zur ND-AGR Ventilposition sensitiv ist. Dies ist nachvollziehbar, da der Füllungsregler die zu große Abgasmasse über die HD-AGR Leitung wieder auszugleichen versucht, wodurch das ND-AGR Ventil geschlossen wird. Das Residuum zum bilanzierten HD-AGR Massenstrom spricht ebenfalls an, da die Massenbilanz an der HD-AGR Einlassstelle im Defektfall korrekt ausgewertet wird. Ein geschlossen klemmender VTG-Aktuator spiegelt sich signifikant in einem zu großen Abgasgegendruck sowie Saugrohrdruck wieder. Außerdem öffnet sich das ND-AGR Ventil weiter und die Abgasklappe schließt sich, um die geforderte Frischluftsollmasse weiterhin einzuregeln. Der HD-AGR Massenstrom zeigt nur kurzzeitig in den Lastwechselsprüngen eine Änderung. Bei einem offen klemmenden VTG-Aktuator ist die Logik zum zuvor genannten Defekt invers. Nur der bilanzierte HD-AGR Massenstrom zeigt in beiden Fällen keinen nennenswerten Effekt. Eine Leckage von 1 cm2 bewirkt ein leichtes Absinken des Abgasgegendrucks sowie einen teils stark erniedrigten Saugrohrdruck. Die ND-AGR Ventilposition ist in den relevanten Punkten (Mittel- bis Volllast, da hier Einfluss auf den Messungsklassifikator p3 besteht) mehr geschlossen, um mit dem verminderten Saugrohrdruck die Frischluftmasse einzuregeln. Der HD-AGR Massenstrom ist, wie bei allen Fehlerfällen außer einem offen klemmendem HD-AGR Ventil, nahezu unbeeinflusst. Ein positiver bzw. negativer Offset von 500 hPa im Abgasgegendrucksensor beeinflusst das Gesamtsystem gering. Lediglich das Residuum für den Abgasgegendruck schlägt in positiver bzw. negativer Richtung aus.

5.2 Diagnose des Abgaskrümmer-Subsystems

87

In Tab. 5.1 ist die aus den dargestellten Erkenntnissen zu folgernde FehlerSymptom-Tabelle gezeigt. Auf eine genaue Schwellwert-Festlegung, d.h. wann die Klassifikatoren konkret anschlagen, wird hier verzichtet. Dies sollte am Zielsystem (also am Versuchsmotor) genauer untersucht werden. Ein “+” kennzeichnet eine positive Tendenz im Residuum (also Defektwert ist größer als Intaktwert), “++” eine stark positive Tendenz, “-” eine negative Tendenz und “- - “ eine stark negative Tendenz. Ein “+ / - “ - Zeichen bedeutet, dass je nach Betriebspunkt ein positiver oder negativer Einfluss ersichtlich ist. Eine 0 zeigt an, dass kein bzw. ein sehr geringer Einfluss des Fehlers auf das Residuum vorliegt. Tabelle 5.1: Fehler-Symptom-Tabelle

HD-AGR klemmt offen VTG klemmt geschlossen VTG klemmt offen Leckage p3 -Offset positiv p3 -Offset negativ

Abgasgegendruck

Saugrohrdruck

NDAGR Ventilposition

Abgasklappenposition

HDAGR Massenstrom

-

-

--

-

+

++

+

+

+

0

-

-

-

+/-

0

-

-

+/-

++

0

-

0

0

0

0

+

0

0

0

0

Da sich jede Zeile in mindestens einem Kriterium unterscheidet, ist die Fehleridentifikation für die Beispielanwendung möglich.

88

5 Anwendungsbeispiel Diagnose

5.3 Umsetzung und Auswertung Das Konzept wird im Folgendem an einem Beispiel-Fahrszenario umgesetzt und validiert. Dazu wird als Referenzmessung ein WLTC-Zyklus vom Motorenprüfstand verwendet. Der WLTC-Zyklus hat eine Länge von etwa einer halben Stunde (Geschwindigkeits-, Motordrehzahl, und Einspritzmengenverlauf im Anhang A1.1, A1.2 und A1.3). In der Simulation wird der Motor zunächst im Intaktfall betrieben, ab Sekunde 200 wird daraufhin ein geschlossen klemmender VTG-Aktuator aufgeprägt. Zunächst sieht das Konzept vor, einen Fehler am Motor durch die ECU zu erkennen, ohne die eigentliche Fehlerursache zu diagnostizieren. Die Fehlererkennung geschieht dabei über eine modellbasierte Betrachtungsweise, in dem ein Abgasgegendruckmodell mit dem Abgasgegendrucksensor (hier Ausgang des Regelstreckenmodells) verglichen wird. Dazu wird zunächst der Root Mean Squared Error des Abgasgegendrucks berechnet, welcher sich nach folgender Formel ergibt:

1 n Gl. 5.2 RMSE = ∑ (p3,Modell,k − p3,Sensor,k )2 n k=1 Der RMSE gewichtet durch die Quadrierung größere Ausreißer mehr als kleinere Abweichungen. Außerdem wird durch die anschließende Wurzel die ursprüngliche Einheit wiederhergestellt sowie eine Skalierung über die Messpunkte n vorgenommen. Der RMSE wird zur Glättung des Signals tiefpassgefiltert und dann mit einem festen Schwellwert verglichen. Es gibt auch Ansätze den Schwellwert adaptiv zu verändern [33], welche hier nicht weiterverfolgt werden. Außerdem wird der RMSE nach festen Intervallen wieder zurückgesetzt, um Änderungen (Eintreten des Fehlers) kurzzeitig erkennen zu können. In Abb. 5.8 ist das Blockdiagramm für den Signalpfad der Fehlererkennung wiedergegeben.

5.3 Umsetzung und Auswertung

89


       

$

  

  

% 


 

 



!

"




 



#!
  

  






 







Abbildung 5.8: Blockdiagramm zur Fehlererkennung in Matlab/Simulink®

In Abb. 5.9 ist für das beschriebene Szenario der PT1-gefilterte RMSE für den Abgasgegendruck dargestellt. Es ist zu erkennen, dass im Intaktfall während der ersten 200 Sekunden die Erkennungsschwelle deutlich unterschritten wird, d.h. die Abweichung zwischen Modell- und Sensorwert ist gering. Durch das Klemmen des VTG-Aktuators wird die Fehlerschwelle dann überschritten, wodurch die Fehlererkennung ausgelöst wird. Es ist ersichtlich, dass in manchen Bereichen trotz Einsetzen des Fehlers der RMSE den Schwellwert unterschreitet (etwa bei Sekunde 500). Bei Leerlaufpunkten wirkt sich der VTG-Fehler nicht aus, weshalb diese Betriebspunkte zur Fehlererkennung ausgeklammert werden können. Umso höher der Lastpunkt, umso leichter ist die Fehlererkennung, was besonders ab Sekunde 1600 ersichtlich ist. Für das Beispiel ist der Algorithmus zur Fehlererkennung wie folgt kalibriert: Tabelle 5.2: Fehlererkennung Parameter Filterzeitkonstante Tiefpass Rücksetzzeit Erkennungsschwelle

Wert 5 Sekunden 10 Sekunden 200 hPa

90

5 Anwendungsbeispiel Diagnose

Abbildung 5.9: Root Mean Squared Error für den Abgasgegendruck p3 Nachdem ein Fehler im System erkannt ist, wird im Zielsystem eine MessdatenAnalysesoftware von der Cloud heruntergeladen. Diese dient dazu, die erforderlichen Messdaten zur Diagnose zu ermitteln. Um den Speicherplatz auf dem Fahrzeug bestmöglich auszunutzen, wird der Download von der Cloud nur im Fehlerfall getriggert. Die Analyse der Messdaten geschieht dann über ein Parameterschätzverfahren, welches Auskunft über den Informationsgehalt einzelner Messabschnitte zur Diagnose geben kann. Dafür wird ein geeignetes Modell mit entsprechenden (Fehler-)parametern benötigt, woraus die Fehlersensitivitäten und die Fisher-Information abgeleitet werden können. Für das betrachtete Beispiel ist ein Modell basierend auf der Füll- und Entleermethode einsetzbar. Dieses umfasst ein Behältermodell für den Abgaskrümmer selbst, ein Turbinenmodell sowie Drosselmodelle für das HD-AGR Ventil sowie eine Leckage. Die Annahme für die Fehlerbetrachtung ist, dass alle Fehler einen Einfluss auf den Abgasgegendruck bewirken. Um eine physikalische Gleichung für den Abgasgegendruck zu erhalten, werden die zu- und abfließenden Gasströme des Abgaskrümmervolumens betrachtet, siehe Abb. 5.10. Zunächst besagt der Massenerhaltungssatz, dass die zeitli-

5.3 Umsetzung und Auswertung

91

che Änderung der gespeicherten Gasmasse eines Volumens gleich der Summe der ein- und ausfließenden Massenströme ist: d m(t) = ∑ m˙ i,ein (t) − ∑ m˙ j,aus (t) Gl. 5.3 dt i j Über den Energieerhaltungssatz (1.Hauptsatz der Thermodynamik) erhält man außerdem für ein offenes System [49]: d ˙ +Wt (t) U(t) = H˙ ein (t) − H˙ aus (t) + Q(t) Gl. 5.4 dt Das ideale Gasgesetz liefert: p(t)V = m(t)RT (t)

Gl. 5.5

Die innere Energie eines idealen Gases in einem abgeschlossenen System ergibt sich aus: 1 U(t) = cv · T (t) · m(t) = · p(t) ·V Gl. 5.6 κ −1

Leckage (t), Leck (t),T (t)

Leck

Trbn

Turbine (t), Trbn (t), T(t)

Abgaskrümmer m(t), T(t), p(t),

AV

Auslassventil (t), AV (t), T(t)

U(t)

4ࡆ:W AGR

HD-AGR (t), AGR (t), T(t)

Abbildung 5.10: Volumen Abgaskrümmer Bei Vernachlässigung von Wärmeübertragung zwischen dem Gas im Volumen und der Umgebung sowie mechanischer Arbeit gilt: d 1 d U(t) = H˙ ein (t) − H˙ aus (t) = · p(t) ·V Gl. 5.7 dt κ − 1 dt

92

5 Anwendungsbeispiel Diagnose

Somit beschreibt sich die Druckänderung des Gases über der Zeit durch:  (κ − 1) · c p d p(t) = ∑ m˙ i,ein (t) · Tein (t) − ∑ m˙ j,aus (t) · Taus (t) Gl. 5.8 dt V j i Als weitere Annahme gilt, dass die Temperatur des einströmenden Gases, die Temperatur des Gases im Volumen sowie des ausströmenden Gases gleich ist: Tein (t) = TVolumen (t) = Taus (t)

Gl. 5.9

Für die Änderung des Abgasgegendrucks im Volumen gilt somit: (κ − 1) · c p d p(t) = · T3 (t) · (m˙ AV (t) − m˙ Trbn (t) − m˙ AGR (t) − m˙ Leckage (t)) dt V Gl. 5.10 Der Massenstrom über das Auslassventil ergibt sich aus der Summe des Massenstroms über Einlassventil und des Brennstoffmassenstroms: m˙ AV (t) = m˙ EV (t) + m˙ B (t) =

p22 (t) ·VHub nMot (t) · λa · + R · T22 (t) 2 nMot (t) · nZyl mB (t) · 2

Gl. 5.11

Der Turbinenmassenstrom berechnet sich durch Gl. 5.12, wobei m˙ red (t) eine Funktion aus Druckverhältnis über Turbine, Laderdrehzahl und VTG-Position darstellt:

Tre f p3 (t) m˙ Trbn (t) = m˙ red (t) · Gl. 5.12 · pre f T3 (t) Der HD-AGR Massenstrom lässt sich über die Drosselgleichung bestimmen:

  p4 (t) 2 m˙ AGR (t) = Ae f f ,AGR · p3 (t) · ·Ψ Gl. 5.13 R · T3 (t) p3 (t) Ebenso ein möglicher Leckage-Massenstrom im Abgaskrümmer:

  pUmg (t) 2 m˙ Leck (t) = Ae f f ,Leck · p3 (t) · ·Ψ R · T3 (t) p3 (t)

Gl. 5.14

5.3 Umsetzung und Auswertung

93

Die Fehlersensitivitäten des Abgasgegendrucks ergeben sich außerdem zu: SFehler =

p3,de f ekt − p3,Nominal ∂ p3 = ∂θ θde f ekt − θNominal

Gl. 5.15

Die Gl. 5.10 mit den Massenströmen aus Gl. 5.11 bis Gl. 5.14 stellt eine inhomogene, nichtlineare Differentialgleichung erster Ordnung dar, wobei die Berechnung der Sensitivitäten über Differenzengleichungen erfolgt. Die zu schätzenden Parameter sind das Tastverhältnis des VTG-Stellers, die eff. Querschnittsfläche des HD-AGR-Ventils und die eff. Querschnittsfläche der Leckage. Somit berechnen sich die Sensitivitäten zu: ∂ p3 ∂ rV T G

Gl. 5.16

SAGR =

∂ p3 ∂ Ae f f ,AGR

Gl. 5.17

SLeck =

∂ p3 ∂ Ae f f ,Leck

Gl. 5.18

STrbn =

Die Sensitivitäten der Sensorfehler werden hier nicht gesondert betrachtet, da diese Fehler relativ einfach zu identifizieren sind und auch kein spezieller Sensorparameter im Modell existiert. Somit ergibt sich als Sensitivitätsvektor der Fehlerparameter:   SError = STrbn SAGR SLeck

Gl. 5.19

Und daraus die Fisher-Information: FIM =

N

T

∑ SError tk

k=1

 1 SError t 2 k σek

Gl. 5.20

Mit der Fisher-Information können nun über die Cramér-Rao Ungleichung einzelne Messabschnitte durch deren Parameterschätzfehlerreduktion bewertet werden. Der Algorithmus wird hier wie folgt bedatet:

94

5 Anwendungsbeispiel Diagnose

Tabelle 5.3: Bewertungskriterien der Messfenster für Diagnose Kriterium Messfensterlänge Mindestanzahl informative Parameter je Messabschnitt Reduktion der Parameter-Schätzfehler je Messabschnitt

Ausprägung 5 Sekunden 2 ≥5%

Die Interpretation ist, dass je besser ein Fehlerparameter (Tastverhältnis VTGSteller, eff. Querschnittsfläche HD-AGR-Ventil, eff. Querschnittsfläche Leckage) bestimmt werden kann, umso informativer kann ein Messabschnitt zur Diagnose bewertet werden. In Abb. 5.11 sind die Sensitivitätsverläufe mit den jeweils informativen Messabschnitten in grün dargestellt.

Abbildung 5.11: Sensitivitäten zur Messdatenbewertung

Die zugehörigen Residuen, die den Vergleich zwischen Intakt- und Defektverhalten charakterisieren, sind in Abb. 5.12 dargestellt. Da in den ersten 200 Sekunden der Fehler noch nicht aufgeprägt ist, sind Referenz- und Defektmodell identisch, weshalb die Residuen null sind. Sobald der VTG-Aktuator klemmt, schlagen die Residuen an. Die Messdatenreduktion hat die Aufgabe, Messbereiche zu identifizieren, wo die Residuen möglichst prägnant erschei-

5.4 Zusammenfassung

95

nen. Dies scheint hier zu funktionieren, denn in den grün dargestellten Messfenstern schlagen die Residuen optisch gesehen signifikant an. Bei Vergleich der Zeile “VTG klemmt geschlossen” aus Tab. 5.1 und den Residuen des Beispielszenarios in Abb. 5.12 zeigt sich, dass diese gut zueinander passen. Alle Tendenzen treten wie vorhergesagt ein. Der Abgasgegendruck und Saugrohrdruck sind im Fehlerfall höher als erwartet, das ND-AGR Ventil öffnet sich, während die Abgasklappe schließt. Der HD-AGR Massenstrom bleibt im Fehlerfall nahezu unverändert. Somit wäre ein klemmender VTGSteller mit einer reduzierten Messdatenanzahl diagnostizierbar.

Abbildung 5.12: Residuen zur Diagnose des Abgaskrümmer-Subsystems

5.4 Zusammenfassung Das vernetzte Fahrzeug eröffnet für die Diagnose des (Verbrennungs-)motors aufgrund der hohen verfügbaren Rechen- und Speicherkapazität sowie der verschiedenen externen Informationsquellen eine Vielzahl an neuen Möglichkeiten. So lassen sich nun neben wissensbasierten und prädiktiven Diagnosealgorithmen auch komplexe modellbasierte Methoden effizient anwenden. Dabei

96

5 Anwendungsbeispiel Diagnose

kann die eigentliche Diagnose auf die Cloud ausgelagert werden, sofern die hierzu notwendigen Mess- und Fahrzeugdaten per Mobilfunk zur Verfügung stehen. Aber auch der Pannen- oder Fehlerservice kann durch die Vernetzung des Fahrzeugs eine Revolution erfahren, da ein Servicemitarbeiter jederzeit auf die Fahrzeugmessgrößen zugreifen und geeignete Maßnahmen einleiten kann. Für die Umweltbehörden bzw. Gesetzgeber ist darüber hinaus eine bessere Kontrolle der zugelassenen Fahrzeuge im Bereich des Möglichen. So können Fahrzeugführer zur termingerechten Abgasuntersuchung oder zur Reparatur emissionsrelevanter Fehler verpflichtet werden. Bei Nichtbeachtung der Vorschriften innerhalb eines vorgegeben Zeitfensters könnte sich die Behörde das Stilllegen von Fahrzeugen vorbehalten. Das Remote-Update der SteuergeräteSoftware stellt auch für die Diagnose einen beachtenswerten Aspekt dar, da auch nach Markteinführung eines Fahrzeugs neue Gesetzgebungsvorschriften durch SW-Updates eingehalten werden könnten. Die genannten Beispiele sollen einen Einblick in die Variantenvielfalt zur “vernetzten Diagnose” liefern. Das in diesem Kapitel dargestellte Beispiel aus dem Luftsystem zur Diagnose eines Fehlers im Bereich des Abgaskrümmers greift zwei Vorteile des Connected Car auf: Einerseits wird die hohe Rechenleistung außerhalb des Fahrzeugs genutzt, um effektive und robuste Diagnosealgorithmen nutzen zu können. Andererseits wird durch das Auslagern von Algorithmen aus dem Fahrzeug heraus die Ressourcenauslastung des Motorsteuergeräts reduziert. Grundvoraussetzung hierfür ist das gezielte Detektieren relevanter Messdaten bereits auf dem Fahrzeug, um den Mobilfunk möglichst wenig zu belasten. Die Rechenkapazität zur Datenfilterung kann die VCU im Bedarfsfall liefern, da sie gegenüber der ECU eine deutlich höhere Rechenleistung aufweist. Der erarbeitete Algorithmus besteht aus den Hauptbestandteilen Fehlererkennung und Fehlerdiagnose. Dabei geschieht die Fehlererkennung auf dem Motorsteuergerät, ohne bereits die Fehlerursache zu diagnostizieren. Damit nun erkannt werden kann, welche Messdaten zur Diagnose von Relevanz sind, stellt die Cloud einen Algorithmus zur Reduktion der Messdaten bereit. So kann die Auslastung des Mobilfunks signifikant reduziert werden. Auf der Cloud findet anschließend die eigentliche Diagnose statt, indem der Fehler lokalisiert und gegebenenfalls die Fehlerschwere ermittelt wird. Im letzten Schritt wird das Diagnoseergebnis an das Fahrzeug zurückgemeldet. Insgesamt ist durch

5.4 Zusammenfassung

97

die Vernetzung des Fahrzeugs eine bessere Diagnose möglich. Es können Diagnosemethoden angewendet werden, die bislang aufgrund fehlender Informationen oder Rechenleistungen nicht realisierbar waren. Die Fehldetektion von mutmaßlichen Fehlern wird somit reduziert, sowie die Wahrscheinlichkeit zur korrekten Lokalisierung eines Fehlers (Pinpointing) erhöht. Gleichzeitig ist eine robustere Aussage zur Fehlerschwere möglich. Die Kosten für den Fahrzeughalter können sich durch das Vermeiden unnötiger Werkstattbesuche reduzieren. Bei verbesserten Diagnoseergebnissen können zudem auch Ersatzreaktionen ausgelöst werden, die zu besseren Fahreigenschaften im Fehlerfall führen oder Pannen vermeiden können. Der Fahrzeughersteller kann sich durch einen überdurchschnittlichen Diagnoseservice von der Konkurrenz abheben, wodurch die Kundenzufriedenheit steigt.

6 Schlussfolgerung und Ausblick Die Vernetzung des Fahrzeugs stellt für das Motorsteuergerät sowohl im Entwicklungsprozess als auch in Serienanwendungen eine Fülle von Möglichkeiten bereit. Denn durch die Implementierung eines Datenkanals vom Fahrzeug zur Umgebung ergeben sich einerseits neue Informationsquellen zur Optimierung des Motorbetriebs. Anderseits erlaubt es dem Fahrzeug den Zugriff auf eine IT-Infrastruktur, die die Rechen- und Speicherkapazitäten des Motorsteuergeräts um ein Vielfaches übersteigt. Somit ist generell ein Effizienzgewinn im Entwicklungsprozess möglich, der aufgrund der steigenden Komplexität und Variantenvielfalt im Motorsteuerungsumfeld besonders im Fokus steht. Außerdem ist durch die Realisierung erweiterter Funktionalitäten ein positiver Effekt auf Verbrauch, Emission, Leistung und Komfort erzielbar. In Anlehnung an das V-Modell lassen sich Anwendungen zur Nutzung des vernetzten Fahrzeugs im Entwicklungsprozess ableiten. Neben einem verbesserten Requirements Engineering durch die gewonnenen Daten, lassen sich insbesondere beim Testen der Software Vorteile identifizieren. So ist eine Verbesserung bei der Nutzung und Auslastung von kostenintensiven Fahrzeugprototypen durch Remote-Fahrzeugtest oder Remote Rapid-Prototyping sowie eine optimierte Flottenverwaltung (z.B. Remote SW-Update) denkbar. Auch im Applikationsprozess ist eine Einsparung von Zeit und Kosten durch eine fortschreitende Automatisierung möglich. Darüber hinaus ermöglicht das vernetzte Fahrzeug im Bereich der Serienanwendungen neue Funktionalitäten. Durch Nutzung von Umgebungsdaten wie Wetter- oder Verkehrsmeldungen kann der Motorbetrieb weitere Optimierungen erfahren. Außerdem ist der Applikationsdatenstand durch den RemoteZugriff jederzeit anpassbar und ermöglicht spezifische Parametrierungen, beispielsweise an Ort oder Verkehrslage. Ein weiteres großes Anwendungsfeld ist das der Diagnose, denn durch das vernetzte Fahrzeug sind neben neuen Methoden für On- und Off-Board-Diagnose auch neue Servicekonzepte denkbar. Auch dem Gesetzgeber eröffnen sich weitere Möglichkeiten zur Feldüberwa© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 L. Hagen, Neue Möglichkeiten für die Motorsteuergeräte- Software durch Car-to-Cloud-Vernetzung, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-31565-8_6

100

6 Schlussfolgerung und Ausblick

chung. Jedoch produzieren bereits heutige Fahrzeuge enorme Datenmengen, die beispielsweise durch das autonome Fahren noch weiter zunehmen werden. Deshalb ist eine der Hauptaufgaben für Anwendungen rund um das vernetzte Fahrzeug, die limitierten Datenraten sowohl fahrzeugseitig als auch über die Luftschnittstelle möglichst effizient zu nutzen. Das Motto sollte hierbei lauten: “Die richtigen Daten zur richtigen Zeit am richtigen Ort”, wobei dies je nach Anwendungsszenario sehr unterschiedlich sein kann. Die Aufgabe besteht darin, die Daten möglichst früh nach deren Informationsgehalt bzw. dem Nutzen für eine bestimmte Anwendung zu filtern. Eine Möglichkeit zur fahrzeugseitigen Datenreduktion besteht beispielsweise in der Nutzung der FisherInformation, die in dieser Arbeit vorrangig Verwendung findet. In Kapitel 4 wird ein Applikationsalgorithmus zur Bedatung eines Abgasgegendruckmodells vorgestellt, der verschiedene Vorteile des vernetzten Fahrzeugs kombiniert. Durch die Verwendung der Cloud zur Durchführung einer Parameteroptimierung ist eine Automatisierung des Applikationsprozesses möglich, ohne einen Experten oder eine hohe computertechnische Rechenleistung on-board verfügbar haben zu müssen. Somit lassen sich Individualisierungen des Datenstands erzeugen, welche auf verschiedene Randbedingungen (Fahrer, Fahrzeug, Umwelt) zugeschnitten sein können. Außerdem wird durch die gezielte Reduktion der anfallenden Messdaten die limitierte Luftschnittstelle möglichst effizient genutzt. Es wird außerdem gezeigt, dass mit einem geringen Anteil der Messdaten eine Parametrierung erzeugt werden kann, die eine ähnliche Güte aufweist, wie wenn alle Daten verwendet worden wären. Im zweiten Anwendungsbeispiel dieser Arbeit wird eine Verbesserung der Diagnose im Abgaskrümmer vorgestellt. Aufgrund der Auslagerung des eigentlichen Diagnosealgorithmus auf die Cloud können wesentlich effektivere und komplexere Methoden als bisher Anwendung finden. Im gezeigten Beispiel wird dies durch ein modellbasiertes Verfahren unter zur Hilfenahme von Paritätsgleichungen realisiert. Hierdurch wird eine verbesserte Fehleridentifikation ermöglicht und erleichtert so die Fehlersuche und Fehlerbehebung. Auch in diesem Verfahren wird bereits auf dem Fahrzeug eine Daten-Vorfilterung durchgeführt, um nur die notwendigsten Daten over-the-air verschicken zu müssen. Durch den Zustand, dass ein Teil der Algorithmik vom Fahrzeug auf

6 Schlussfolgerung und Ausblick

101

die Cloud ausgelagert wird, werden außerdem ECU-Ressourcen frei, die für echtzeitkritische Anwendungen genutzt werden können. Diese Arbeit hat das Ziel, die Anwendungsmöglichkeiten des vernetzten Fahrzeugs für die Motorsteuergeräte-Software in Entwicklung und Serie mit Fokus auf Car-to-Cloud aufzuzeigen. Dabei ist sichtbar geworden, dass das Anwendungsspektrum über das reine Datensammeln hinausgeht, wobei dennoch der Großteil der heutigen Motorsteuergeräte-Funktionalitäten auf Fahrzeugseite verbleiben wird. Permanent benötigte und echtzeitkritische Anwendungen sind für ein Auslagern auf eine Cloud prinzipiell ungeeignet. Trotzdem werden in dieser Arbeit Möglichkeiten vorgestellt, die den Einsatz von Car-to-Cloud rechtfertigen und Optimierungspotentiale erschließen.

Literaturverzeichnis [1] V-Modell XT: Das deutsche Referenzmodell für Systementwicklungsprojekte, Version: 2.2. https://www.cio.bund.de/Web/DE/Architekturen-undStandards/V-Modell-XT/. – Online; Stand 07. August 2018 [2] Overview of 3rd Generation Partnership Project (3GPP) Release 8 V0.3.3 (2014-09). http://www.3gpp.org/specifications/specifications. 2014. – Online; Stand 30. Juli 2018 [3] A BTHOFF, Tobias: Big-Data-Technologien in der Fahrzeugentwicklung. In: Automobiltechnische Zeitschrift Elektronik (ATZ Elektronik) 05/2016 [4] BARGENDE, Michael: Vorlesungsumdruck: Grundlagen der Fahrzeugantriebe, Band I. 2. Auflage. Universität Stuttgart, 2018 [5] BASSHUYSEN, Richard van ; S CHÄFER, Fred: Handbuch Verbrennungsmotor - Grundlagen, Komponenten, Systeme, Perspektiven. 7. Auflage. Springer Vieweg Verlag, 2015 [6] BAUER, Norbert: Mobilfunkgestützte Ferndiagnose von Kfz mittels WAP-Technologie. In: 22. Tagung „Elektronik im Kfz“, Haus der Technik - Essen, 2002 [7] B ERGER, Joachim ; F EGER, Johannes ; F INK, Lutz-Martin u. a.: Elektronische Dieselregelung EDC. Robert Bosch GmbH, 2001 [8] B ERNS, Karsten ; S CHÜRMANN, Bernd ; T RAPP, Mario: Eingebettete Systeme. Vieweg Teubner Verlag, 2010 [9] B EUTH, Klaus ; B REIDE, Stephan ; L ÜDERS, C.-F. u. a.: Nachrichtentechnik. 4. Auflage. Vogel Buisness Media Verlag, 2016 [10] B LANKE, Mogens ; K INNAERT, Michel ; L UNZE, Jan u. a.: Diagnosis and Fault-Tolerant Control. 3. Auflage. Springer Verlag, 2016

© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 L. Hagen, Neue Möglichkeiten für die Motorsteuergeräte- Software durch Car-to-Cloud-Vernetzung, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-31565-8

104

Literaturverzeichnis

[11] B OEHME, Dominik: Methoden zur effizienten Basisapplikation für Luftpfad- und Abgastemperaturmodell von Ottomotoren, TU Darmstadt, Dissertation, 2012 [12] B OHL, Willi ; E LMENDORF, Wolfgang: Technische Strömungslehre. 15. Auflage. Vogel Buchverlag, 2015 [13] B OHN, Christian ; U NBEHAUEN, Heinz: Identifikation dynamischer Systeme. Springer Vieweg Verlag, 2016 [14] B ORGEEST, Kai: Elektronik in der Fahrzeugtechnik. 2. Auflage. Vieweg Teubner Verlag, 2010 [15] B RAESS, Hans-Hermann ; S EIFFERT, Ulrich: Vieweg Handbuch Kraftfahrzeugtechnik. 7. Auflage. Springer Vieweg Verlag, 2013 [16] B RAITSCHINK, Peter: Diagnose als integraler Bestandteil der Funktion Methodiken für Softwaresysteme im Kraftfahrzeug, Universität Stuttgart, Dissertation, 2006 [17] B ROY, Manfred: Challenges in Automotive Software Engineering. In: International Conference on Software Engineering (ICSE), 20.-28. Mai 2006, Shanghai [18] C ECCARELLI, Riccardo ; M OULIN, Philippe ; W IT, Carlos C. de: Turbine Efficiency Estimation for Fault Detection Application. In: SAE International Paper (2010) [19] C HUNG, Namhoon ; K IM, Sunwoo ; S UNWOO, Myoungho: Nonlinear Dynamic Model of a Turbocharged Diesel Engine. In: SAE Technical Paper (2005) [20] DAKROUB, Husein ; C ADENA, Robert: Analysis of Software Update in Connected Vehicles. In: SAE International J. Passeng. Cars – Electron. Electr. Syst. Volume 7, Issue 2 (August 2014) [21] DAKROUB, Husein ; S HAOUT, Adnan ; AWAJAN, Arafat: Connected Car Architecture and Virtualization. In: SAE International J. Passeng. Cars – Electron. Electr. Syst. Volume 9 (Mai 2016)

Literaturverzeichnis

105

[22] E CK, Christopher ; S IDOROW, Andreas ; KONIGORSKI, Ulrich u. a.: Fault Detection for Common Rail Diesel Engines with Low and High Pressure Exhaust Gas Recirculation. In: SAE International Paper (2011) [23] E IGNER, Martin ; ROUBANOV, Daniil ; Z AFIROV, Radoslav: Modellbasierte virtuelle Produktentwicklung. Springer Vieweg Verlag, 2014 [24] F IORANI, Paolo ; G AMBAROTTA, Agostino ; T ONETTI, Marco u. a.: A Real-Time Model for the Simulation of Transient Behaviour of Automotive Diesel Engines. In: SAE International Paper (2006) [25] F REYERMUTH, Bernd: Wissensbasierte Fehlerdiagnose am Beispiel eines Industrieroboters. VDI Verlag, 1993 [26] G ERKE, Thorsten ; M ARTYNENKO, Dmytrij ; H OSAGRAHARA, Arvind: Big Engineering Data - Wertschöpfendes Kapital. In: Automobiltechnische Zeitschrift Elektronik (ATZ Elektronik) 03/2016 [27] G OLDING, Paul: Connected Services. John Wiley & Sons Ltd., 2011 [28] G ONZALEZ, Constantin: Connected Automobiles - The Cloud drives with you. In: Automobiltechnische Zeitschrift Elektronik (ATZ Elektronik) (März 2018) [29] G RONDIN, Olivier ; C HAUVIN, Jonathan: Intake System Diagnosis for Diesel Engine with Dual-Loop EGR. In: SAE International Paper (2012) [30] G UZZELLA, Lino ; O NDER, Christopher H.: Introduction to Modeling and Control of Internal Combustion Engine Systems. Springer Verlag, 2010 [31] H ERCHET, Heiko ; B IEN, Torsten ; P OLLNER, Michael: Car IT - Die Revolution in der Softwareentwicklung. In: Automobiltechnische Zeitschrift Elektronik (ATZ Elektronik) 06/2015 [32] H EYWOOD, John B.: Internal Combustion Engine Fundamentals. McGraw-Hill Book Company, 1988 [33] H ÖFLING, Thomas: Methoden zur Fehlererkennung mit Parameterschätzung und Paritätsgleichungen, Technische Universität Darmstadt, Dissertation, 1996

106

Literaturverzeichnis

[34] H OBERG, Fabian: Stau auf der Datenautobahn. In: Automobiltechnische Zeitschrift (ATZ) 02/2016 [35] I DE, Christoph: Resource-Efficient LTE Machine-Type Communication in Vehicular Environments, TU Dortmund, Dissertation, 2015 [36] I SERMANN, Rolf: Methoden zur Fehlererkennung für die Überwachung technischer Prozesse. In: Regelungstechnische Praxis 22 (1980) [37] I SERMANN, Rolf: Identifikation dynamischer Systeme I. 2. Auflage. Springer Verlag, 1992 [38] I SERMANN, Rolf: Identifikation dynamischer Systeme II. 2. Auflage. Springer Verlag, 1992 [39] I SERMANN, Rolf (Hrsg.): Modellgestützte Steuerung, Regelung und Diagnose von Verbrennungsmotoren. Springer Verlag, 2003 [40] I SERMANN, Rolf: Mechatronische Systeme. Springer Verlag, 2008 [41] I SERMANN, Rolf: Elektronisches Management motorischer Fahrzeugantriebe. Vieweg Teubner Verlag, 2010 [42] I SERMANN, Rolf: Fault-Diagnosis Application. Springer Verlag, 2011 [43] I SERMANN, Rolf: Engine Modeling and Control. Springer Verlag, 2014 [44] J OHANNING, Volker ; M ILDNER, Roman: Car IT kompakt - Das Auto der Zukunft - Vernetzt und autonom fahren. Springer Vieweg Verlag, 2015 [45] K LAUSNER, Markus ; D IETRICH, Arne ; H ATHOUT, Jean-Pierre: Vehicle Data Management system with remote access to electronic control unit internal states. In: International Conference on Advanced Driver Assistance Systems, Birmingham, 17.-19.09.2001 [46] KÖRTGEN, Christopher ; M ORANDI, Gabriele ; JACOBS, Georg u. a.: Automated calibration of a tractor transmission control unit. In: 10th International Fluid Power Conference. Dresden, 2016

Literaturverzeichnis

107

[47] L ANG, Marc: Der Trend geht zu zentralen Domänen-ECUs. In: Automobil Elektronik (06/2016) [48] L IGGESMEYER, Peter: Software Qualität: Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum Akademischer Verlag Heidelberg, 2009 [49] L UCAS, Klaus: Thermodynamik - Die Grundgesetze der Energie- und Stoffumwandlungen. Springer Verlag, 2008 [50] M AJER, Clemens: Parameterschätzung, Versuchsplanung und Trajektorienoptimierung für verfahrenstechnische Prozesse. VDI Verlag, 1998 [51] M ELL, Peter ; G RANCE, Timothy: The NIST Definition of Cloud Computing. https://csrc.nist.gov/publications/detail/sp/800-145/final. 2011. – Online; Stand 31. Juli 2018 [52] M ENCHER, Bernhard u. a.: Ottomotor-Management: Motronic -Systeme. Robert Bosch GmbH, 2003 [53] M ERKER, Günter ; T EICHMANN, Rüdiger: Grundlagen Verbrennungsmotoren - Funktionsweise, Simulation, Messtechnik. 7. Auflage. Springer Vieweg Verlag, 2014 [54] M ITTERER, Alexander ; Z UBER -G OOS, Frank: Modellgestützte Kennfeldoptimierung – Ein neuer Ansatz zur Steigerung der Effizienz in der Steuergeräteapplikation. In: Automobiltechnische Zeitschrift (ATZ) 102 (2010) [55] NAVALE, Varun ; W ILLIAMS, Kyle ; L AGOSPRIS, Athanassios u. a.: (R)evolution of E/E Architectures. In: SAE International J. Passeng. Cars – Electron. Electr. Syst. Volume 8, Issue 2 (August 2015) [56] N ELLES, Oliver: Nonlinear System Identification. Springer Verlag, 2001 [57] N OBE, Tsuguo: Connected Vehicle Accelerates Green Driving. In: SAE International Paper (2010) [58] N YBERG, Mattias ; P ERKOVIC, Andrej ; N IELSEN, Lars: Model Based Diagnosis of Leaks in the Air-Intake System of an SI-Engine. In: SAE Technical Paper (1998)

108

Literaturverzeichnis

[59] PALOCZ -A NDRESEN, Michael: On-Board-Diagnose und On-BoardMeasurement. expert Verlag, 2008 [60] P FEIL, Karl ; Z IMMERSCHIED, Ralf ; I SERMANN, Rolf: Nichtlineare Identifikation des Luftpfads von aufgeladenen Dieselmotoren und automatisierter AGR-/VTG-Reglerentwurf. In: Automatisierungstechnik (at) 07/2007 [61] P ÖGEL, Tobias: 2014

Connectivity Map, TU Braunschweig, Dissertation,

[62] P ILLMANN, Johannes ; S LIWA, Bejamin ; S CHMUTZLER, Jens u. a.: CarTo-Cloud Communication Traffic Analysis based on the Common Vehicle Information Model. In: IEEE Paper (2017) [63] R AKOPOULOS, C. ; G IAKOUMIS, E.: Diesel Engine Transient Operation. Springer Verlag, 2009 [64] R EIF, Konrad: Bosch Autoelektrik und Autoelektronik. Vieweg Teubner Verlag, 2011 [65] R EIF, Konrad: Dieselmotor - Management - Systeme, Komponenten, Steuerung und Regelung. 5. Auflage. Springer Vieweg Verlag, 2012 [66] R EIF, Konrad: Dieselmotor - Management im Überblick. 2. Auflage. Springer Vieweg Verlag, 2014 [67] R EIF, Konrad ; D IETSCHE, Karl-Heinz ; ROBERT B OSCH G MB H (Hrsg.): Kraftfahrtechnisches Taschenbuch. Springer Vieweg, 2014 [68] R EINHEIMER, Stefan: Cloud Computing - Die Infrastruktur der Digitalisierung. Springer Vieweg Verlag, 2018 [69] RÖMMELE, Stefan ; Z IMMERMANN, Jörg-Michael: Software sicher und aktuell halten. In: Automobil-Elektronik 12/2017 [70] RÜSCHENDORF, Ludger: Mathematische Statistik. Springer Verlag, 2014 [71] S AUTER, Martin: Grundkurs Mobile Kommunikationssysteme. 4. Auflage. Vieweg Teubner Verlag, 2011

Literaturverzeichnis

109

[72] S CHOLZ, Peter: Softwareentwicklung eingebetteter Systeme. Springer Verlag, 2005 [73] S CHÄUFFELE, Jörg ; Z URAWKA, Thomas: Automotive Software Engineering. 5. Auflage. Springer Vieweg Verlag, 2013 [74] S CHWARTE, Anselm ; I SERMANN, Rolf: Model-Based Fault Detection of Diesel Intake with Common Production Sensors. In: SAE Technical Paper (2002) [75] S CHWARTE, Anselm ; K IMMICH, Frank ; I SERMANN, Rolf: ModelBased Fault Detection and Diagnosis for Diesel Engines. In: Motortechnische Zeitrschrift (MTZ) 63 (2002) [76] S CHWARZMANN, Dieter ; N ITSCHE, Rainer ; L UNZE, Jan: Diesel Boost Pressure Control using Flatness-Based Internal Model Control. In: SAE Technical Paper (2006) [77] S TEIGERWALD, Kay ; Z ELENKA, Barbara ; H OHENBERG, Günter u. a.: Development of an Intake Flow Based Model Calculating Real Time Exhaust Flow by Accounting for Filling and Emptying of the Engine Manifolds. In: SAE Technical Paper (2007) [78] S TOLZ, Wolfgang ; KORNHAAS, Robert ; K RAUSE, Ralph u. a.: Domain Control Units - the Solution for Future E/E Architectures? In: SAE International Paper (2010) [79] S TREICHERT, Thilo ; T RAUB, Matthias: Elektrik/Elektronik - Architekturen im Kraftfahrzeug. Springer Vieweg Verlag, 2012 [80] T RAUB, Matthias ; M AIER, Alexander ; BARBEHÖN, Kai: Future Automotive Architecture and the Impact of IT Trends. In: AutomobilElektronik (06/2017) [81] U NLAND, Stefan ; S TUHLER, Harald ; S TUBER, Axel: Neue effiziente Applikationsverfahren für die physikalisch basierte Motorsteuerung ME7. In: Motortechnische Zeitschrift (MTZ) 58 (1998) [82] VDI: Richtlinie 2206: Entwicklungsmethodik für mechatronische Systeme. 2004

110

Literaturverzeichnis

[83] VOGEL, Michael: CaliAV: An Escape from the ECU Parameter Trap. In: P REDELLI, Oliver (Hrsg.): On-Board Diagnostics (OBD) IV. expert Verlag, 2011, Kap. 3, S. 23–33 [84] W ERNER, Martin: Nachrichtentechnik. 8. Springer Vieweg Verlag, 2017 [85] W OLLSCHLÄGER, Dirk: Das vernetzte Fahrzeug - Voraussetzungen, Anforderungen und Perspektiven. In: Automobiltechnische Zeitschrift Elektronik (ATZ Elektronik) 04/2014 [86] Z AKI, Yasir: Future Mobile Communications. Springer Vieweg Verlag, 2013 [87] Z IMMERMANN, Werner ; S CHMIDGALL, Ralf: Bussysteme in der Fahrzeugtechnik. Springer Vieweg Verlag, 2014

Anhang A.1 Lastpunkte WLTC

140

Fahrzeuggeschwindigkeit [km/h]

120

100

80

60

40

20

0

0

200

400

600

800

1000

1200

1400

1600

1800

1400

1600

1800

Zeit [s]

Abbildung A1.1: Fahrzeuggeschwindigkeit WLTC

3500

Motordrehzahl [min-1]

3000

2500

2000

1500

1000

500

0

0

200

400

600

800

1000

1200

Zeit [s]

Abbildung A1.2: Motordrehzahl WLTC © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 L. Hagen, Neue Möglichkeiten für die Motorsteuergeräte- Software durch Car-to-Cloud-Vernetzung, Wissenschaftliche Reihe Fahrzeugtechnik Universität Stuttgart, https://doi.org/10.1007/978-3-658-31565-8

112

Anhang

70

Einspritzmenge [mg/Hub]

60

50

40

30

20

10

0

0

200

400

600

800

1000

1200

1400

1600

1800

Zeit [s]

Abbildung A1.3: Einspritzmenge WLTC

A.2 Motordaten Tabelle A2.1: Daten Diesel - Versuchsmotor Zylinderanzahl Hubraum Nennleistung Max. Drehmoment Verdichtungsverhältnis Abgasrückführungen Aufladung

4 1,7 Liter 100 kW @ 3500 - 4000 U/min 300 Nm @ 1600 - 3000 U/min 16,2 HD + ND - AGR einstufiger ATL mit VTG

Modellgüte Streckenmodell

113

A.3 Modellgüte Streckenmodell Tabelle A3.1: 441 Betriebspunkte v. Prüfstand, stationär ohne AGR Modellgröße Saugrohrdruck p22 Abgasgegendruck p3 Druck nach Turbine p4 Druck vor Abgasklappe p5 Temperatur n. Verdichter Temperatur n. LLK Temperatur im Abgaskrümmer Temperatur n. Turbine Temperatur v. Abgasklappe HFM - Massenstrom Massenstrom über Einlassventil

Mittelwertfehler 21,3 hPa 34,9 hPa 8,3 hPa -6,3 hPa 2,1 K 0,3 K

Standardabweichung 62,5 hPa 121,3 hPa 33,5 hPa 6,2 hPa 7,9 K 0,6 K

66,1 hPa 126,2 hPa 34,5 hPa 8,9 hPa 8,1 K 0,7 K

-5,4 K

29,1 K

29,6 K

16 K

26,4 K

30,9 K

0,4 K

38,5 K

38,5 K

1,4 kg/h

11,9 kg/h

12 kg/h

-5,6 kg/h

9,7 kg/h

11,2 kg/h

RMSE

114

Anhang

Tabelle A3.2: 416 Betriebspunkte v. Prüfstand, stationär mit AGR Modellgröße Saugrohrdruck p22 Abgasgegendruck p3 Druck nach Turbine p4 Druck vor Abgasklappe p5 Differenzdruck ND-AGR Temperatur n. Verdichter Temperatur n. LLK Temperatur im Abgaskrümmer Temperatur n. Turbine Temperatur v. Abgasklappe HFM - Massenstrom Massenstrom über Einlassventil Massenstrom ND-AGR

Mittelwertfehler 16,2 hPa 69,3 hPa -26,0 hPa -12,4 hPa -0,2 hPa 3,3 K 0,4 K

Standardabweichung 53,3 hPa 144,8 hPa 25,5 hPa 8,4 hPa 8,3 hPa 8,2 K 0,4 K

55,7 hPa 160,5 hPa 36,4 hPa 15,0 hPa 8,3 hPa 8,9 K 0,6 K

-28,6 K

38,7 K

48,1 K

-8,5 K

34,9 K

35,9 K

-24,5 K

51 K

56,6 K

-14,1 kg/h

16,8 kg/h

22 kg/h

-5,8 kg/h

7,1 kg/h

9,1 kg/h

11,3 kg/h

14,2 kg/h

18,1 kg/h

RMSE

Modellgüte Streckenmodell

115

Tabelle A3.3: Modellgüte WLTC Modellgröße Saugrohrdruck p22 Abgasgegendruck p3 Druck nach Turbine p4 Druck vor Abgasklappe p5 Differenzdruck ND-AGR Temperatur n. Verdichter Temperatur n. LLK Temperatur im Abgaskrümmer Temperatur n. Turbine Temperatur v. Abgasklappe HFM - Massenstrom Massenstrom über Einlassventil Massenstrom ND-AGR

Mittelwertfehler -15,9 hPa 0,0 hPa -25,4 hPa 2,4 hPa 4,1 hPa 2,5 K 0,3 K

Standardabweichung 62,8 hPa 149,1 hPa 12,9 hPa 2,8 hPa 2,3 hPa 19,8 K 1,4 K

64,7 hPa 149,1 hPa 28,5 hPa 3,7 hPa 4,7 hPa 19,9 K 1,5 K

-15,3 K

90,2 K

91,5 K

7,9 K

90,1 K

90,4 K

3,8 K

110,1 K

110,1 K

-4,9 kg/h

18,3 kg/h

18,9 kg/h

-1,2 kg/h

5,6 kg/h

5,7 kg/h

-5,4 kg/h

16,1 kg/h

17 kg/h

RMSE