-
Die vorliegende Erfindung betrifft ein Verfahren und ein entsprechendes System zum Testen von Software und/oder Hardware eines oder mehrerer in ein Kraftfahrzeug einzubauender Bauteile bzw. Steuergeräte.
-
Zur Verbesserung einer laufenden Produktion, bspw. im Kfz-Bereich, sind entwicklungsbegleitend Hardware- und Softwareänderungen erforderlich. Derartige Hardware- und Softwareänderungen stellen nach ihrer Überprüfung und Verifikation zusammen eine vollständige Qualifikation eines neuen Verbundes als Basislinie bzw. Grundlage für eine darauf aufbauende weitere Entwicklung dar. Bis zur endgültigen Umsetzung einer neuen Software oder Hardware sind dabei verschiedene Abläufe durchzuführen.
-
Im Kfz-Bereich hat sich dabei eine sukzessive Vorgehensweise von aufeinanderfolgenden Test- und Integrationsverfahren etabliert. Zunächst wird hier ein Softwaremodultest durchgeführt, gefolgt von einer Softwaremodulintegration und einem Softwarekomponententest. Sind diese zunächst isoliert für die Software durchgeführten Tests erfolgreich abgeschlossen, so schließt sich daran eine Software- und Hardwareintegration in ein spezifisches Gerät an, gefolgt von einem Geräteeinzeltest, in welchem die Software bzw. Hardware integriert wurde. Bei dem Gerät handelt es sich in der Regel um eine Art Steuergerät. Wenn dies erfolgreich getestet wurde, erfolgt im Anschluss daran eine System- bzw. Bus-Segmentintegration, so dass ein sogenannter Teilverbundtest durchgeführt werden kann. Anschließend erfolgt eine sogenannte Gesamtverbundintegration, ein Gesamtverbundtest und darauffolgend eine Fahrzeugintegration, ein Fahrzeugtest sowie letztendlich ein Gesamtfahrzeugtest.
-
Die einzelnen durchzuführenden Tests werden hierbei üblicherweise aufgelistet und schalten bspw. in einer internen Darstellung von rot auf grün, wenn der jeweilige Test erfolgreich durchgeführt werden konnte.
-
DE 100 42 559 A1 beschreibt ein Simulationssystem zur Entwicklung von elektronischen sowie ggf. auch teilweise mechanischen Fahrzeugkomponenten. Dieses Simulationssystem umfasst einen oder mehrere Arbeitsstationen mit Simulationsprogrammen, mindestens einen in der oder den Arbeitsstationen zumindest teilweise als Programm ablaufenden Fahrzeugsimulator und mindestens eine simulierte Fahrzeugkomponente. Dabei umfasst die simulierte Fahrzeugkomponente einen Emulator zum Testen eines endfertigen Anwendungsprogramms für die zu entwickelnde Fahrzeugkomponente. Ferner wird die Verwendung des beschriebenen Systems zur Entwicklung und Fertigung von elektronischen Bremssystemen und Einrichtungen zur Regelung der Fahrdynamik beschrieben.
-
DE 10 2005 026 040 A1 beschreibt ein Verfahren zur Parametrierung eines in Software implementierten Arbeitsmodells einer Simulationsumgebung, welches eine Vielzahl von Simulations-Modellkomponenten umfasst und auf eine Simulationshardware geladen wird. Dieses Verfahren dient dazu, eine Anpassung und Optimierung einer Parametrierung eines Simulationsmodells aufgrund geänderter Zusammensetzung von Modellkomponenten automatisch zu bewerkstelligen.
-
DE 103 03 489 A1 beschreibt ein Verfahren zum Testen von Software einer Steuereinheit eines Fahrzeugs, wobei durch ein Testsystem eine von der Steuereinheit steuerbare Regelstrecke wenigstens teilweise simuliert wird. Ausgangssignale von der Steuereinheit werden dabei erzeugt, und diese Ausgangssignale der Steuereinheit werden zu ersten Hardware-Bausteinen über eine erste Verbindung übertragen, und Signale von zweiten Hardware-Bausteinen werden als Eingangssignale zur Steuereinheit über eine zweite Verbindung übertragen. Dabei werden die Ausgangssignale als erster Steuerwert in der Software bereitgestellt und zusätzlich über eine Kommunikationsschnittstelle in Echtzeit bezogen auf die Regelstrecke zum Testsystem übertragen.
-
Es war nunmehr eine Aufgabe der vorliegenden Erfindung, eine Möglichkeit vorzusehen, in einem Schnellverfahren zu implementierende Software zu testen, so dass dadurch bereits eine erste Absicherung der zu implementierenden Software und Daten inklusive ungewollter Quereffekte erreicht werden kann, ohne dass das beschriebene zeit- und kostenaufwändige Durchlaufen der genannten Tests und Integrationsverfahren zwingend notwendig wäre.
-
Vor diesem Hintergrund werden ein Verfahren und ein System mit den Merkmalen der unabhängigen Patentansprüche vorgestellt. Weitere Ausgestaltungen der Erfindung ergeben sich aus den abhängigen Patentansprüchen und der Beschreibung.
-
Es wird ein Verfahren zum Testen von Software und/oder Hardware eines in ein Kraftfahrzeug einzubauenden Bauteils vorgeschlagen, wobei ein erster Teil von durch die Software zu beeinflussenden Funktionen des Bauteils in einem Testsystem, in welchem das Bauteil mindestens bis zu einem für die zu testenden Funktionen benötigten Grad nachgebildet wird, getestet wird, und ein zweiter Teil, der durch die Software zu beeinflussenden Funktionen des Bauteils durch temporären Einbau des Bauteils in ein reales entsprechendes Kraftfahrzeug überprüft wird.
-
Das erfindungsgemäß vorgeschlagene Verfahren gewährleistet eine erste grobe Absicherung von Software eines in ein Kraftfahrzeug einzubauenden Bauteils und gewährt bereits eine sehr gute Übersicht darüber, ob Änderungen am entsprechenden Kraftfahrzeug möglichst fehlerlos umgesetzt werden können.
-
Gemäß einer Ausführungsform des erfindungsgemäß vorgeschlagenen Verfahrens werden der erste Teil und der zweite Teil der durch die Software zu beeinflussenden Funktionen des Bauteils im wesentlichen zeitgleich getestet.
-
Es ist ferner denkbar, dass der erste Teil und der zweite Teil der durch die Software zu beeinflussenden Funktionen des Bauteils zusammen die Gesamtheit der zu testenden Funktionen des Bauteils darstellen. Dabei ist es ferner denkbar, dass der erste Teil und der zweite Teil der durch die Software zu beeinflussenden Funktionen identisch sind. Das bedeutet, dass die zu testenden Funktionen des Bauteils jeweils unter verschiedenen Bedingungen, d. h. im Testsystem und im realen Kraftfahrzeug, getestet werden, so dass hierüber aussagekräftige Ergebnisse erhalten werden können.
-
Es ist jedoch auch denkbar, dass der erste Teil und der zweite Teil der durch die Software zu beeinflussenden Funktion nur teilweise oder gar nicht überlappen und sich entsprechend zu der Gesamtheit der zu testenden Funktionen des Bauteils ergänzen. Das bedeutet, dass gewisse Funktionen nur in dem Testsystem, andere Funktionen wiederum nur bei temporärem Einbau des Bauteils in das reale entsprechende Kraftfahrzeug überprüft werden.
-
Gemäß einer weiteren Ausführungsform des erfindungsgemäß vorgesehenen Verfahrens wird für den ersten Teil im Testsystem und/oder für den zweiten Teil am eingebauten Bauteil mindestens ein Regressionstest für die jeweils zu testenden Funktionen durchgeführt. In der Regel werden hierbei mehrere Regressionstests durchgeführt.
-
Unter einem Regressionstest versteht man in der Softwaretechnik eine Wiederholung aller oder einer Teilmenge durchzuführender Testfälle, um Nebenwirkungen von Modifikationen, d. h. Änderungen, in bereits getesteten Teilen der zu überprüfenden Software aufzuspüren. Wie bereits eingangs erwähnt, entstehen solche Änderungen regelmäßig, bspw. aufgrund Pflege, Änderungen und Korrektur der jeweiligen Software.
-
Ein Regressionstest gehört zu den sogenannten dynamischen Testtechniken. Aufgrund des Wiederholungscharakters und der Häufigkeit dieser Wiederholungen ist es sinnvoll, wenn für Regressionstests eine Testautomatisierung zum Einsatz kommt, wie sie auch gemäß einer weiteren Ausführungsform bei dem erfindungsgemäßen Verfahren zum Einsatz kommt.
-
Gemäß einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens werden Testergebnisse für den ersten Teil und Testergebnisse für den zweiten Teil der durch die Software zu beeinflussenden Funktion des Bauteils konsolidiert und ausgewertet. Die Auswertung erfolgt in der Regel unter Zusammenschau aller erhaltenen Testergebnisse. Die Testergebnisse können ferner einem Anwender visualisiert dargestellt werden, so dass schnell und unverzüglich erkannt werden kann, an welchen Stellen die zu implementierende Software ggf. nachzubessern ist.
-
Die vorliegende Erfindung betrifft ferner ein System zum Testen von Software und/oder Software zumindest eines in ein Kraftfahrzeug einzubauenden Bauteils. Das erfindungsgemäße System umfasst ein Testsystem, in welchem ein erster Teil von durch die Software zu beeinflussenden Funktionen des Bauteils zu testen ist. Dabei ist das Bauteil in dem Testsystem mindestens bis zu einem für die zu testenden Funktionen benötigten Grad nachgebildet. Ferner umfasst das erfindungsgemäße System ein reales Kraftfahrzeug, in welchem durch temporären Einbau des Bauteils ein zweiter Teil der durch die Software zu beeinflussenden Funktionen des Bauteils zu überprüfen ist. Darüber hinaus umfasst das System eine Auswerteeinheit, welche dazu konfiguriert ist, Testergebnisse für den ersten Teil und Testergebnisse für den zweiten Teil der durch die Software zu beeinflussenden Funktionen des Bauteils zu konsolidieren und auszuwerten.
-
Die Auswerteeinheit kann ferner eine Visualisierungseinheit umfassen, mit Hilfe derer es möglich ist, die ausgewerteten Testergebnisse in geeigneter Form anzuzeigen. Neben einer Visualisierungseinheit ist es jedoch auch möglich, eine andere Einheit vorzusehen, mit welcher die Auswertung in geeigneter Weise einem Anwender kommuniziert werden kann; denkbar ist bspw. auch eine Audioeinheit.
-
In einer möglichen Ausführungsform des erfindungsgemäßen Systems können der erste Teil und der zweite Teil der durch die Software zu beeinflussenden Funktionen des Bauteils im wesentlichen zeitgleich getestet werden.
-
Es ist denkbar, dass der erste Teil und der zweite Teil der durch die Software zu beeinflussenden Funktionen des Bauteils zusammen die Gesamtheit der zu testenden Funktionen des Bauteils darstellen.
-
Dabei ist es ferner denkbar, dass der erste Teil und der zweite Teil der durch die Software zu beeinflussenden Funktionen des Bauteils identisch sind, so dass jeder Teil für sich quasi die Gesamtheit der zu testenden Funktionen darstellt. Allerdings ist hier anzumerken, dass die jeweiligen zu testenden Funktionen hier in dem Testsystem und in dem realen Fahrzeug unter verschiedenen Bedingungen getestet werden können.
-
Andererseits können aber auch der erste Teil und der zweite Teil der durch die Software zu beeinflussenden Funktionen des Bauteils teilweise oder gar nicht überlappen und sich demnach zu der Gesamtheit der zu testenden Funktionen des Bauteils ergänzen.
-
Ferner kann in dem System vorgesehen sein, dass für den ersten Teil im Testsystem und/oder für den zweiten Teil am eingebauten Bauteil mindestens ein Regressionstest für die jeweilig zu testenden Funktionen durchgeführt werden kann.
-
Dabei ist denkbar, dass für den mindestens einen Regressionstest eine Testautomatisierung vorgesehen ist.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
-
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
-
1 zeigt eine Übersicht von möglichen Integrationsmethoden, wobei eine Ausführungsform des erfindungsgemäßen Verfahrens hier als ”Quickscan” bezeichnet ist.
-
2 zeigt einen möglichen Ablauf von sukzessiv durchzuführenden Arbeitsschritten beim Testen einer zu implementierenden Software in ein Bauteil eines Kraftfahrzeugs.
-
3 zeigt einen möglichen zeitlichen Ablauf einer Nachintegration.
-
4 zeigt einen möglichen Ablauf eines Datenrelease.
-
5 zeigt in skizzierter Darstellung den Ablauf einer Ausführungsform des erfindungsgemäßen Verfahrens.
-
1 stellt vier Integrationsmethoden mit ihrem jeweiligen Ziel 10, Einsatz 11, Absicherung 12 und Dauer/Aufwand 13 gegenüber. In der obersten Zeile 100_1 wird ein Verbundrelease VR, in Zeile 100_2 eine Nachintegration NI, in Zeile 100_3 ein Datenrelease DR und in Zeile 100_4 eine Ausführungsform eines erfindungsgemäßen Verfahrens ”Quickscan” vorgestellt.
-
Eine Funktionsverteilung in einem Fahrzeugverbund erfordert eine iterative Vorgehensweise bei einer entsprechenden Verbundintegration. Aus diesem Grund sind häufiger Softwareänderungen und damit verbundene Qualifikationstests jeweiliger Steuergerätesoftware sowie eine Aktualisierung von vorgesehenen Versuchsfahrzeugen notwendig. Entwicklungsschritte für einen Funktionssprung werden als Verbundrelease bezeichnet. Das Ziel derartiger Entwicklungsschritte bzw. des Verbundrelease ist es, eine vollständige Qualifikation eines neuen Verbundes als Basislinie für eine weitere Entwicklung, d. h. hinsichtlich Hardware- bzw. Softwareänderungen, zu erhalten. Der Einsatz eines derartigen Verbundrelease ist mindestens zu allen Aufbauterminen inklusive aller sogenannter Synchropunkte zu gewährleisten. Die bei einem Funktionssprung in der jeweiligen Software zu integrierenden Funktionen werden in einer Verbundreleaseplanung festgelegt. Diese Verbundreleaseplanung wird in der Regel synchronisiert mit den Entwicklungsschritten von angrenzenden Entwicklungsbereichen, wie bspw. Antrieb- und Karosserieentwicklung. Zu festdefinierten Zeitpunkten fließen die jeweiligen Entwicklungen synchron in die vorgesehenen Entwicklungsfahrzeuge ein Dieser Zeitpunkt wird als Synchropunkt bezeichnet. Eine vollständig funktionale Absicherung wird durch Prüfkataloge und explizite Erprobung erreicht. Ferner wird eine vollständige Qualifizierung von Querschnittsumfängen durchgeführt. Allerdings ist die Dauer eines derartigen Verbundrelease vergleichsweise lang, in der Regel etwa vier Wochen. Eine Erprobungsfreigabe nach Inbetriebnahme erfolgt in der Regel erst während der dritten Woche.
-
Eine Nachintegration NI, wie in Zeile 100_2 beschrieben, hat zum Ziel eine Reifegradsteigerung und eine gezielte Fehlerbehebung für einzelne Steuergeräte auf Basis eines zuvor durchgeführten Verbundrelease. Zum Einsatz kommt eine derartige Nachintegration für alle Aufbautermine und Erprobungen. Ferner ergänzt eine derartige Nachintegration ein vorhandenes Verbundrelease nach Freigabe in einem sogenannten Change Control Board (CCB). Eine Nachintegration wird durch eine gezielte Qualifikation von Änderungen sowie wesentliche Regressionstests in Funktion und Querschnitt gemäß einem Prüfkatalog abgesichert. Eine Nachintegration hat in der Regel eine zwei-wöchige Dauer.
-
Ein weiterer Schritt, Zeile 100_3, nämlich ein Datenrelease DR, hat zum Ziel eine Optimierung von Applikationsdaten. Auch hier soll der Reifegrad, bspw. eine Fahrbarkeit, weiter optimiert werden. Zum Einsatz kommt ein Datenrelease für alle Aufbautermine und Erprobungen. Ein Datenrelease ergänzt ferner ein vorhandenes Verbundrelease nach Freigabe im CCB. Ein Datenrelease ermöglicht eine funktionale Absicherung von Änderungen durch einzelne Fachbereiche, ferner auch eine Querschnitt-Absicherung durch einen sogenannten Software Hex-(Hexadezimal) Vergleich. Ein Datenrelease kann in der Regel innerhalb einer Woche durchgeführt werden.
-
Das erfindungsgemäße Verfahren, hier als Quickscan bezeichnet und in Zeile 100_4 beschrieben, ermöglicht eine grobe Absicherung von Software- und Datenänderungen inklusive ungewollter Quereffekte. Letzteres kann insbesondere durch gemäß einer möglichen Ausführungsform des erfindungsgemäßen Verfahrens vorzusehenden Regressionstests erzielt werden. Ein Quickscan kann bei einer spezifischen Erprobung eingesetzt werden, welcher bspw. terminlich begrenzt ist. Dabei können spezifische Umbauvorschriften für Erprobungsfahrten erzeugt werden. Ein Quickscan ermöglicht einen Funktionskurztest unmittelbar am realen Fahrzeug. Ferner sind automatisierte Regressionstests im Testhaus und am realen Fahrzeug möglich. Die Dauer eines erfindungsgemäßen Verfahrens beträgt in der Regel vier Tage, so dass ggf. ein derartiger Quickscan auch über ein verlängertes Wochenende, d. h. von Donnerstag bis Montag, inklusive vollautomatisierter Tests erfolgen kann.
-
2 zeigt einen systematischen chronologischen Ablauf von durchzuführenden Arbeitsschritten beim Testen einer in ein Bauteil eines Kraftfahrzeugs zu implementierenden Software. An unterster Stufe 1 wird zunächst ein Software-Modultest 200_1 durchgeführt. Falls dieser Software-Modultest 200_1 erfolgreich ist, so erfolgt im Anschluss daran entsprechend in Pfeilrichtung in Stufe 2 eine Software-Modulintegration und ein Software-Komponententest einer entsprechenden Softwarekomponente 200_2. Ist dieser Software-Komponententest wiederum erfolgreich, so erfolgt in Stufe 3 entsprechend der Pfeilrichtung nach oben eine Software-/Hardwareintegration und ein jeweiliger Steuergeräte-Einzeltest eines entsprechenden Steuergeräts 200_3, in welches die Softwarekomponente 200_2 eingebaut wurde. Ist auch hier wiederum der Einbau der Software-Komponente 200_2 in ein jeweiliges Steuergerät 200_3 erfolgreich hinsichtlich seiner zu erfüllenden Funktionen, so erfolgt in Stufe 4 eine System- bzw. Bussegment-Integration und ein Teilverbundtest. Das Steuergerät 200_3 wird demnach in ein übergeordnetes System 200_4 implementiert, so dass es hier neben anderen Steuergeräten zum Einsatz kommt. Ist auch nach dieser Teilimplementierung das Steuergerät 200_3 nach wie vor in seiner Funktion wunschgemäß, d. h. ist der Teilverbundtest erfolgreich, so erfolgt in Stufe 5 eine Gesamtverbund-Integration und ein damit verbundener Gesamt-Verbundtest. Das heißt, das zuvor erhaltene Bussegment 200_4 umfassend eine Anzahl von Steuergeräten wird als Bussegment 200_4 in ein wiederum übergeordnetes System 200_5 integriert, in welchem neben dem Bussystem 200_4 andere Bussegmente oder Teilsysteme enthalten sind, welche sich zu einem Steuergeräte-Gesamtverbund 200_5 zusammenfügen. Ist hier auch wiederum der Gesamtverbundtest erfolgreich, so erfolgt in Stufe 6 entsprechend der Pfeilrichtung eine Fahrzeugintegration und ein entsprechender Fahrzeugtest. Hier wird der Steuergeräte-Gesamtverbund 200_5 in ein reales Fahrzeug 200_6 integriert, um so quasi in realer Umgebung innerhalb des Fahrzeugs seine Funktionstauglichkeit zu testen. In dem Fahrzeug 200_6 sind neben dem nunmehr integrierten Steuergeräte-Gesamtverbund 200_5 andere Teilsysteme enthalten, wie bspw. Sensorik, Aktorik oder weitere Steuergeräte-Verbünde. Ist auch hier wiederum der Fahrzeugtest erfolgreich, so erfolgt in einer weiteren Stufe ein Gesamtfahrzeugtest in einem realen Fahrzeug 200_7, welches dann als Ganzes in einer realen Umgebung und gemäß einer kundennahen Nutzung geprüft wird.
-
Dieser sieben-stufige Ablauf ist in der Regel bei Einführung von Softwareänderungen durchzuführen und erfordert demnach einen vergleichsweise hohen Zeitaufwand, verbunden mit relativ hohen Kosten.
-
3 zeigt in detaillierter Darstellung den Schritt einer Nachintegration NI, d. h. als ein Teil der durchzuführenden Arbeitsschritte bei Implementierung von Softwareänderungen. Eine Voraussetzung 300_1 zur Durchführung einer Nachintegration NI ist, dass keine Änderungen an jeweiligen Schnittstellen durchgeführt werden. Die Softwareänderungen basieren vielmehr auf einem qualifizierten Stand aus einem zuvor durchgeführten Verbundrelease. Ferner sind die Softwareänderungen im CCB zu genehmigen. Darüber hinaus wurde bereits im Vorfeld eine Risikobewertung der Änderungen durchgeführt. Demnach liegt eine Freigabe vor, und die Software liegt in der Regel als sogenannter Flash-Container vor. Die Durchführung 300_2 einer Nachintegration bedarf in der Regel etwa zwei Wochen. Bei der Nachintegration ist eine Querschnittsabsicherung 300_21 möglich, was bedeutet, dass ein Einzeltest nur für geänderte Steuergeräte durchgeführt wird. Ferner werden ausgewählte Fahrzeuggesamtruhestromprüfungen durchgeführt. EMV-Prüfungen werden nur bei Hardware-Änderungen durchgeführt. Eine Vernetzungsprüfung anhand Änderungsumfang SG bzw. segmentspezifisch wird festgelegt. Ferner erfolgt eine zielgerichtete Diagnoseprüfung auf aufbau- und betriebsrelevante Funktionen und eine Fehlerspeicheranalyse. Teil einer Nachintegration ist es ferner, Funktionstests 300_22 zur Absicherung der zu testenden Steuergeräte, bspw. durch Nutzung von Testautomaten, in einem Testhaus durchzuführen. Eine Dokumentation erfolgt in der Regel anhand von Prüfkatalogen.
-
Ferner umfasst eine Nachintegration Funktionserprobungen 300_23, was eine Fachbereichserprobung sowie eine Intensiverprobung aus Gesamtsicht beinhaltet und einen jeweiligen Bericht aus den ändernden Bereichen.
-
Eine Nachintegration kommt bei allen Aufbauterminen und Erprobungen zum Einsatz 300_3 und ergänzt ein vorhandenes Verbundrelease nach Freigabe im CCB.
-
4 zeigt den Arbeitsschritt eines Datenrelease DR mit Voraussetzung 400_1, Dauer 400_2 und Einsatz 400_3. Voraussetzung 400_1 eines Datenrelease DR ist, dass keine Programmstandsänderungen, sondern nur funktionale Datenoptimierungen erfolgen. Ferner sollten die Änderungen im CCB genehmigt und eine Risikobewertung der Änderungen durchgeführt worden sein. Entsprechend der Nachintegration ist auch hier eine Freigabe erforderlich. Datenänderungen sollen nur applikativer Natur sein. Kodierung, Diagnose und Vernetzung sind dabei unverändert. Die Datenänderungen lassen sich über einen Hex-Vergleich bestätigen, d. h. es gibt keine Code-Verschiebung. Ein Flashablauf ist im jeweiligen Fachbereich bereits getestet worden. Eine Datenänderung liegt als sogenannter Flash-Container oder als korrigierte MCR vor.
-
Ein Datenrelease dauert in der Regel eine Woche. Dabei erfolgt eine Querschnittsabsicherung 400_21 durch Hex-Vergleich der Datenänderungen und Prüfung der Flash-Fähigkeit. Ferner werden Funktionstests 400_22 durchgeführt zur Absicherung von Datenänderungen, bspw. durch Nutzung der Testautomaten im Testhaus. Ferner erfolgen auch hier Funktionserprobungen 400_23 analog zu der bereits beschriebenen Nachintegration.
-
Ein Datenrelease kommt bspw. zur Absicherung eines Einsatzes von neuen Datensätzen in Vor- bzw. Serie zum Einsatz, bspw. bei Einführung eines neuen Derivats. Ferner kommt es bei Absicherung von Datenänderungen für spezifische Erprobungen zum Einsatz.
-
5 beschreibt nunmehr schematisch eine mögliche Ausführungsform des erfindungsgemäßen Verfahrens. Dabei ist im oberen Bereich von 5, nämlich in. 5a, der Gesamtablauf der Ausführungsform des erfindungsgemäßen Verfahrens von links nach rechts chronologisch schematisch dargestellt. Im unteren Bereich, d. h. in 5b, ist dargestellt, wie gemäß der hier dargestellten Ausführungsform des erfindungsgemäßen Verfahrens ein erster Teil von durch die Software zu beeinflussenden Funktionen eines Bauteils in einem Testsystem und elf zweiter Teil der durch die Software zu beeinflussenden Funktionen eines Bauteils durch temporären Einbau des Bauteils in ein reales Kraftfahrzeug überprüft werden.
-
5a beschreibt nunmehr, dass in Schritt 500_1 zunächst formal eine Anmeldung zum Durchführen des erfindungsgemäßen Verfahrens, im folgenden als Quickscan bezeichnet, durchgeführt wird. Sodann erfolgen in Schritt 500_2 Prüfungen im jeweiligen Fachbereich nach Bedarf des Durchführens eines derartigen Quickscans. In einem darauffolgenden Schritt 500_3 wird die zu prüfende Software bzw. die jeweils damit kompatible Hardware inklusive eines sogenannten Flash-Containers übergeben. Sodann wird das erfindungsgemäße Verfahren durchgeführt, d. h. ein erster Teil von durch die Software zu beeinflussenden Funktionen des Bauteils wird in einem Testsystem 500_10 getestet, während ein zweiter Teil der von der Software zu beeinflussenden Funktionen des Bauteils in einem realen Kraftfahrzeug 500_20 überprüft wird. In einem nachfolgenden Schritt 500_4 werden sodann die sich daraus ergebenden Testergebnisse konsolidiert und zusammen ausgewertet. Diese Auswertung wird dann in einem Endschritt 500_5 entsprechend angezeigt als Zustand bzw. Status. Auf Grundlage eines damit erzielten Status kann weiter entschieden werden, wie weiter vorzugehen ist, was dann bspw. in einem sogenannten Change Control Board (CCB) erfolgen kann.
-
5b erläutert die im Zusammenhang mit 5a beschriebenen Schritte nun im Detail. Im oberen Teil von 5b ist dargestellt, wie der zweite Teil der durch die zu implementierende Software zu beeinflussenden Funktionen eines entsprechenden Bauteils getestet wird, nämlich durch temporären Einbau des Bauteils mit der implementierten Software in ein reales Kraftfahrzeug, was in Stufe 5_10 dargestellt ist. Hier wird das Kraftfahrzeug in einer Werkstatt 5_1 in einer entsprechenden Box 5_2 umgebaut und dabei entsprechende Testgeräte zusammen mit der zum implementierenden Software temporär in das Kraftfahrzeug eingebaut. Das Kraftfahrzeug wird dann einerseits einem manuellen Kurztest im ”Stand” in Schritt 5_11 unterzogen. Dabei wird in Schritt 5_12 eine Konditionierung einer vorzunehmenden Testautomatisierung vorgenommen. In Schritt 5_13 erfolgen dann automatisierte Tests, wie bspw. eine Überprüfung eines Fahrzeuggesamtruhestroms und eine im Fahrzeug vorgenommene Vernetzung. Andererseits erfolgt in Schritt 5_14 auf einem Prüfgelände 5_3 in einer Fahrtsituation ein manueller Kurztest ”Fahrt”. Nach Durchführung aller. automatisierten Tests erfolgt letztlich in Schritt 5_15 ein. Kurztest auf einer Prüfstrecke innerhalb des Prüfgeländes 5_3.
-
Der erste Teil der durch die Software zu beeinflussenden Funktionen eines entsprechenden Bauteils für ein Kraftfahrzeug wird in einem Testhaus 5_4 getestet. Hierbei erfolgt zunächst ein des Umbau HiL-Testers (Hardware in the Loop) in einem Schritt 5_16, gefolgt von einer Konditionierung einer Testautomatisierung in Schritt 5_17. Nach Konditionierung der Testautomatisierung erfolgt ein Funktionskurztest im Testsystem 5_4 in Schritt 5_18. Die gewonnenen Testresultate aus dem Testsystem 5_4 in Schritt 5_18 zusammen mit den Testresultaten der automatisierten Tests in Schritt 5_13 und den Testresultaten aufgrund der Testfahrt in Schritt 5_15 werden nunmehr konsolidiert und in geeigneter Weise ausgewertet und letztlich, wie in 5a gezeigt, als Status der Entwicklung angezeigt, der wiederum einem entsprechenden Gremium (CCB) mitgeteilt werden kann. In Abhängigkeit von dem Status wird seitens des Gremiums letztlich festgelegt, ob die Software im aktuellen Zustand letztendlich in das Fahrzeug integriert werden kann.
-
Unter einer Testautomatisierung versteht man im allgemeinen eine Automatisierung von Aktivitäten im Test, insbesondere bei Tests von Software. Dabei erfolgen zu definierten Zeiten Testläufe der zu testenden Software, so dass die Software dadurch bezüglich ihrer Qualität messbar wird und mögliche Nebeneffekte von vorgenommenen Änderungen direkt und leicht erkennbar sind. Eine Testautomatisierung liefert eine Art Metrik, eine Anzahl von erfolgreichen Testfällen pro Testlauf. Dadurch wird die Software messbar, und es kann relativ leicht beantwortet werden, ob eine neue Anforderung, d. h. eine zu beeinflussende Funktion des jeweiligen Bauteils durch die Software vollständig erfüllt werden kann. Ferner kann auch ein Maß für die Qualität der Softwareversion erlangt werden. Es kann beurteilt werden, ob die neue Softwareversion qualitativ besser ist als die vorangegangene Softwareversion. Durch die Testautomatisierung kann der Entwicklungsprozess erheblich beschleunigt werden.
-
HiL bezeichnet Hardware in the Loop, was ein Verfahren bezeichnet, bei dem ein eingebettetes System, bspw. ein reales elektronisches Steuergerät oder eine reale mechatronische Komponente über seine Ein- und Ausgänge an ein angepasstes Gegenstück, das im allgemeinen HiL-Simulator genannt wird und als Nachbildung der realen Umgebung des Systems dient, angeschlossen wird. Hardware in the Loop ist eine Methode zum Testen und Absichern von eingebetteten Systemen, zur Unterstützung während der Entwicklung wie zur vorzeitigen Inbetriebnahme von Maschinen und Anlagen. Dabei wird das zu steuernde System, bspw. das Kraftfahrzeug, über Modelle simuliert, um die korrekte Funktion des zu entwickelnden Steuergeräts zu testen. Die Eingänge des Steuergeräts werden mit Sensordaten aus dem Modell stimuliert. Um die Reglerschleife (Loop) zu schließen, wird die Reaktion der Ausgänge des Steuergeräts, bspw. das Ansteuern eines Elektromotors, in das Modell zurückgelesen. Bei Durchführung von Tests im HiL werden die in der Anfangsphase manuell durchgeführten Tests durch automatische Testabläufe ersetzt (Testautomatisierung). Dadurch lassen sich Tests, wie bereits erwähnt, nahezu beliebig parametrieren und präzise wiederholen. Eine Kontrolle einer Fehlerabstellung ist somit wesentlich besser möglich. Die HiL-Simulation ist demnach eine Vereinfachung der Realität und kann den Test am realen System nicht ersetzen. Demnach ist es sehr vorteilhaft, wie erfindungsgemäß vorgeschlagen, parallel sowohl Tests durch die HiL-Simulation im Testsystem 5_4 wie auch Tests am realen Fahrzeug vorzunehmen. Eine Zusammenschau der so erhaltenen Testergebnisse liefert eine zuverlässige erste Aussage über die zu testende Software.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 10042559 A1 [0005]
- DE 102005026040 A1 [0006]
- DE 10303489 A1 [0007]
