-
Die Erfindung betrifft ein Verfahren zum Durchführen einer Testfahrt eines Fahrzeugs, insbesondere ein Verfahren zum Überprüfen eines Softwarestands beziehungsweise einer Softwareversion des Fahrzeugs im Hinblick auf eine durchzuführende Testfahrt.
-
Heutige Fahrzeuge verfügen bereits über eine Vielzahl von Assistenzsystemen, die den Fahrer in einer Vielzahl von Fahrsituationen computerbasiert unterstützen. Solche Assistenzsysteme können auf Sensoren zum Erfassen einer Vielzahl von Messdaten zurückgreifen, welche die Sinnesfähigkeiten des Menschen bei weitem übersteigen. Zudem übertrifft die Geschwindigkeit dieser Assistenzsysteme die menschliche Reaktionszeit signifikant. Bekannte Fahrerassistenzsysteme sind beispielsweise Spurhalteassistenten, Bremsassistenten bei Fußgängererkennung und Abstandsregeltempomaten, insbesondere für Stausituationen.
-
Durch Anwendung solcher Assistenzsysteme geht die Autonomie des Fahrers bezüglich seiner Fahrentscheidungen zunehmend auf das Fahrzeug beziehungsweise in diesem operierende Steuereinheiten über. Am Ende dieser Entwicklungen steht ein automatisch fahrendes Fahrzeug, welches vollständig ohne Eingriffe eines Menschen manövrieren kann. Als Projektion von Fahrerassistenzsystemen führt dies zum vollautomatisierten Personentransport.
-
Darüber hinaus rücken Assistenzsysteme als Mittel zur Information und Unterhaltung (Infotainment) der Fahrzeugnutzer in den Fokus, insbesondere da die Nutzer eines automatisch fahrenden Fahrzeugs weniger Aufmerksamkeit auf die eigentliche Fahraufgabe verwenden. Das durch ein Assistenzsystem bereitgestellte Infotainment umfasst dabei die audiovisuelle Ausgabe von Informationen, insbesondere in Reaktion auf spezifische Nutzereingaben.
-
Auch darüber hinaus verfügen moderne Fahrzeuge natürlich über eine Vielzahl rechnergestützter Assistenzsysteme, wie beispielsweise zur Motorensteuerung, als Sicherheitssysteme, wie beispielsweise ABS, ESP und dergleichen oder zur Abgasreinigung. Diese Funktionen sind in der Regel auf im Fahrzeug verbauten Steuergeräten lokalisiert.
-
Jedes der vorgenannten Assistenzsysteme ist vor allem durch die zugrunde liegende Software, weniger durch die eigentliche Hardware des Fahrzeugs bestimmt. Der Wert moderner Fahrzeuge wird somit zunehmend auch durch die Qualität und Funktionalität der in dem Fahrzeug verwendeten Software bestimmt, wodurch die Software-Entwicklung auch in der Herstellung des Fahrzeugs eine immer größere Rolle spielt. Die Software-Entwicklung umfasst dabei Testfahrten, bei denen Software-gestützte Funktionalitäten im Fahrzeug geprüft werden.
-
Für diese Testfahrten werden in der Regel Versuchsfahrzeuge eingesetzt, die von mehreren Software-Entwicklern genutzt werden. Dabei können verschiedene Software-Entwickler an verschiedenen Funktionalitäten also an verschiedenen Teilen einer Fahrzeugsoftware arbeiten. Somit kann es zu Situationen kommen, in denen beispielsweise ein erster Entwickler ein Sprachassistenzsystem innerhalb einer Fahrzeugsoftware weiterentwickelt, die auch ein Navigationssystem enthält. Während der erste Entwickler die zum Sprachassistenzsystem gehörigen Teile der Systemsoftware überarbeitet, führt er in der Regel an den zu dem Navigationssystem gehörenden Teilen der Software keine Änderungen durch. Ein zweiter Software-Entwickler, der hingegen an dem Navigationssystem arbeitet, belässt die zu dem Sprachassistenzsystem gehörende Software in der Regel ohne größere Veränderungen.
-
Führt nun der erste Software-Entwickler eine Testfahrt durch, um das Sprachassistenzsystem während der Fahrt zu erproben, lädt er die aktuellste, von ihm entwickelte Softwarefassung in das Fahrzeug. Diese Softwarefassung enthält dabei gegebenenfalls eine veraltete Fassung des Navigationssystems. Möchte nun der zweite Software-Entwickler den neuesten Stand des Navigationssystems im Fahrzeug prüfen, muss er eine andere Softwarefassung aufspielen.
-
Folglich kommt es im Entwicklungsprozess einer Fahrzeugfunktion häufig zu verschiedenen Softwareständen in einem Testfahrzeug. Insbesondere, wenn mehrere Entwickler auf ein Testfahrzeug zugreifen, kann es zu Situationen kommen, in denen eine vom Entwickler bearbeitete Softwarekomponente fehlerhaft nicht an das Testfahrzeug übertragen wurde. Somit besteht die Gefahr, dass Testfahrten mit falschem Softwarestand durchgeführt werden.
-
Der Erfindung liegt nun die Aufgabe zugrunde, die Nachteile des Standes der Technik zu überwinden oder zumindest zu verringern und ein Verfahren zum Durchführen beziehungsweise Vorbereiten einer Testfahrt bereitzustellen, das die Gefahr fehlerhafter Testfahrten verringert.
-
Diese Aufgabe wird gelöst durch die Gegenstände der unabhängigen Patentansprüche. Bevorzugte Weiterbildungen sind Gegenstand der rückbezogenen Unteransprüche.
-
Ein Aspekt der vorliegenden Erfindung betrifft ein Verfahren zum Durchführen beziehungsweise zum Vorbereiten einer Testfahrt mit einem Fahrzeug, beispielsweise einem Testfahrzeug. Das Verfahren wird dabei, zumindest teilweise, von einem Fahrzeug, insbesondere dem Testfahrzeug, und bevorzugt von einer Steuereinheit des Fahrzeugs durchgeführt. Das Verfahren wird ferner bevorzugt in einem System durchgeführt, das zumindest einen Netzwerkserver enthält, mit dem das Fahrzeug über eine Netzwerkverbindung kommuniziert.
-
In dem erfindungsgemäßen Verfahren wird zunächst eine bevorstehende Testfahrt ermittelt. Das Ermitteln der Testfahrt erfolgt bevorzugt vollautomatisch und stellt den Startpunkt des erfindungsgemäßen Verfahrens dar, welches mithin vor der eigentlichen Testfahrt erfolgt. Der Zeitpunkt, zu dem die bevorstehende Testfahrt vor der Testfahrt ermittelt wird, ist dabei variabel.
-
In einer bevorzugten Durchführungsform des Verfahrens wird die bevorstehende Testfahrt ermittelt, indem ein für die Testfahrt verantwortlicher Entwickler in oder nahe dem Fahrzeug detektiert wird. Das Ermitteln des Entwicklers erfolgt dabei beispielsweise anhand von biometrischen Daten, beispielsweise Gesichtserkennung, oder anhand eines personalisierten Schlüssels des Entwicklers oder dergleichen. In einer alternativ bevorzugten Durchführungsform sind die Testfahrten in einem Buchungssystem des Fahrzeugs eingetragen. Dabei kann das Buchungssystem in dem Fahrzeug oder dem Netzwerkserver lokalisiert sein. Das Ermitteln der bevorstehenden Testfahrt entspricht dann einem Auslesen eines Eintrags des Buchungssystems. In einer ebenfalls bevorzugten Durchführungsform wird das Bevorstehen einer Testfahrt ermittelt, sobald das Fahrzeug (beziehungsweise dessen Zündung) eingeschaltet wird. Ebenfalls bevorzugt wird eine bevorstehende Testfahrt ermittelt, sofern ein entsprechender Betriebsmodus des Fahrzeugs für Testfahrten, in dem beispielsweise alle Aktivitäten des Fahrzeugs aufgezeichnet werden, aktiviert wird.
-
Sofern in dem erfindungsgemäßen Verfahren eine bevorstehende Testfahrt ermittelt wurde, wird ferner ein aktueller Softwarestand des Fahrzeugs ermittelt. Mit anderen Worten wird geprüft, welche Fahrzeugsoftware auf dem Fahrzeug lokal geladen beziehungsweise installiert ist. Der aktuelle Softwarestand betrifft dabei die gesamte Fahrzeugsoftware oder einzelne Module davon. Beispielsweise können verschiedene Module der Fahrzeugsoftware mit unterschiedlichem Softwarestand vorliegen. Der Softwarestand ist dabei beispielsweise durch einen Zeitstempel einer letzten Aktualisierung definiert. Ebenfalls bevorzugt ist der Softwarestand durch eine Versionsnummer oder dergleichen definiert. Das Ermitteln des aktuellen Softwarestands erfolgt beispielsweise durch Auslesen eines solchen Zeitstempels beziehungsweise einer solchen Versionsnummer und/oder Laden in einen Arbeitsspeicher.
-
In einem weiteren Schritt des erfindungsgemäßen Verfahrens wird zumindest eine charakteristische Eigenschaft der bevorstehenden Testfahrt ermittelt. Das Ermitteln dieser charakteristischen Eigenschaft erfolgt ebenfalls bevorzugt vollautomatisch und in Reaktion auf das Ermitteln einer bevorstehenden Testfahrt. Die charakteristische Eigenschaft der Testfahrt ist insbesondere eine für den zur Testfahrt benötigten Softwarestand charakteristische Eigenschaft. Mit anderen Worten definiert die charakteristische Eigenschaft einen für die Testfahrt benötigten Softwarestand der Fahrzeugsoftware oder eines Moduls davon. Verschiedene bevorzugte Durchführungsformen des Verfahrensschritts des Ermittelns der charakteristischen Eigenschaft der Testfahrt werden im Folgenden noch im Detail erläutert.
-
Sofern die charakteristische Eigenschaft der Testfahrt ermittelt ist, wird im erfindungsgemäßen Verfahren ferner ein zu der charakteristischen Eigenschaft korrespondierender Softwarestand des Fahrzeugs ermittelt. Wie bereits ausgeführt, ist die charakteristische Eigenschaft der Testfahrt eine für den zur Testfahrt benötigten Softwarestand charakteristische Eigenschaft. Somit ist der korrespondierende Softwarestand mit anderen Worten ein für die Testfahrt benötigter Softwarestand. Der korrespondierende Softwarestand kann sich dabei wiederum auf die gesamte Fahrzeugsoftware oder auf ein Modul der Fahrzeugsoftware beziehen. Der korrespondierende Softwarestand ist analog zum aktuellen Softwarestand ebenfalls bevorzugt durch einen Zeitstempel eine Versionsnummer oder dergleichen eindeutig charakterisiert.
-
Im erfindungsgemäßen Verfahren erfolgt ferner ein Vergleich des ermittelten aktuellen Softwarestands und des ermittelten korrespondierenden Softwarestands des Fahrzeugs. Mit anderen Worten wird im erfindungsgemäßen verfahren geprüft, ob der aktuelle Softwarestand des Fahrzeugs ganz oder zumindest teilweise (modulweise) dem für die Testfahrt benötigten Softwarestand entspricht. Zumindest sofern eine Inkompatibilität zwischen dem aktuellen Softwarestand und dem korrespondierenden Softwarestand des Fahrzeugs ermittelt wird, erfolgt ferner die Ausgabe einer Mitteilung, insbesondere an einen Nutzer des Fahrzeugs beziehungsweise einen Entwickler, insbesondere einen für die bevorstehende Testfahrt verantwortlichen Entwickler, der Fahrzeugsoftware. Ebenfalls bevorzugt erfolgt auch im Fall der Kompatibilität eine Bestätigung der Kompatibilität in Form einer Nachricht an den Entwickler.
-
Das erfindungsgemäße Verfahren ermöglicht vorteilhaft eine vollautomatische Überprüfung, ob eine in einem Fahrzeug geladene Fahrzeugsoftware für eine bevorstehende Testfahrt geeignet ist. Die Eignung kann dabei beispielsweise darin bestehen, dass die Software für den Testzweck geeignet ist, beispielsweise indem sie die zu testende Funktionalität erst zur Verfügung stellt. Somit entfallen beim Anwenden des erfindungsgemäßen Verfahrens fehlerhafte Testfahrten mit falscher Fahrzeugsoftware. Ebenso vorteilhaft kann das zeitaufwendige Nachladen von Fahrzeugsoftware kurz vor der Testfahrt vermieden werden, wie noch im Detail erläutert.
-
Wie bereits obenstehend ausgeführt, ist das Ermitteln der charakteristischen Eigenschaft für das Ermitteln der korrespondierenden für die Testfahrt notwendigen Software essentiell. Gemäß einer bevorzugten Durchführungsform handelt es sich bei der charakteristischen Eigenschaft um einen für die bevorstehende Testfahrt verantwortlichen Entwickler. Mit anderen Worten wird die für die Testfahrt benötigte Software anhand der Kenntnis des für die Testfahrt verantwortlichen Entwicklers ermittelt. In einer alternativen Durchführungsform handelt es sich bei der zu ermittelnden charakteristischen Eigenschaft um eine mit der bevorstehenden Testfahrt zu testende Softwareversion oder eine mit der bevorstehenden Testfahrt zu testende Funktionalität der Fahrzeugsoftware. Ebenso bevorzugt handelt es sich um ein für die bevorstehende Testfahrt zu verwendendes Testgerät. Anhand dieser Informationen wird folglich der korrespondierende, also der für die Testfahrt notwendige Softwarestand ermittelt.
-
In einer besonders bevorzugten Durchführungsform des erfindungsgemäßen Verfahrens wird als charakteristische Eigenschaft ein für die bevorstehende Testfahrt verantwortlicher Entwickler ermittelt. Das Ermitteln des verantwortlichen Entwicklers erfolgt bevorzugt anhand von mit fahrzeugeigenen Sensoren ermittelten biometrischen Daten des Entwicklers. Beispielsweise wird mittels fahrzeuginternen Kameras und Gesichtserkennung auf den Entwickler geschlossen. Alternativ können Fingerabdrucksensoren oder beliebige andere Sensoren zum Erfassen biometrischer Daten zum Einsatz kommen. Ebenfalls bevorzugt wird der verantwortliche Entwickler anhand eines personalisierten Fahrzeug(funk)-Schlüssels ermittelt. Ebenfalls bevorzugt wird nicht der Ermittler selbst, sondern ein mit dem Entwickler verknüpftes mobiles Endgerät, beispielsweise ein Smartphone oder Laptop, erkannt und davon auf den Ermittler geschlossen. Das Smartphone oder der Laptop werden beispielsweise erkannt, wenn diese eine Verbindung, wie Bluetooth oder über OBDII, mit dem Fahrzeug eingehen. Ebenfalls bevorzugt ist der Name des Entwicklers in dem bereits erwähnten Buchungssystem des Fahrzeugs im Zusammenhang mit der bevorstehenden Testfahrt hinterlegt.
-
Gemäß dieser Durchführungsform wird ferner ein mit dem verantwortlichen Entwickler verknüpfter korrespondierender Softwarestand ermittelt. Dies erfolgt bevorzugt online, das heißt über zumindest eine Netzwerkverbindung, durch Zugriff des Fahrzeugs auf ein Versionenkontrollsystem (Softwareartefakte-Verzeichnis) der Fahrzeugsoftware. In diesem Versionenkontrollsystem werden alle an der Fahrzeugsoftware vorgenommenen Änderungen protokolliert, so dass dieses System ferner das Wiederherstellen beziehungsweise Abrufen von beliebigen Versionen der Fahrzeugsoftware ermöglicht. In diesem Versionenkontrollsystem vorgenommene Änderungen sind mit dem verantwortlichen, das heißt die Veränderung vornehmenden, Entwickler eindeutig verknüpft. Durch Kenntnis des für die Testfahrt verantwortlichen Entwicklers kann somit unmittelbar auf den mit diesem verknüpften aktuellsten Softwarestand geschlossen werden. Ebenso bevorzugt erfolgt das Ermitteln des mit dem verantwortlichen Entwickler verknüpften Softwarestands nicht durch Zugriff auf einen das Versionenkontrollsystem beherbergenden Server, sondern durch lokalen Zugriff auf ein mit dem Fahrzeug verbundenes mobiles Endgerät (Smartphone, Tablet) des Entwicklers. Dieses mobile Endgerät kann dabei eine Kopie des Versionenkontrollsystems oder eines Teils davon beherbergen. Ebenso bevorzugt enthält das mobile Endgerät ausschließlich mit dem Entwickler assoziierte Softwarestände auf, so dass der korrespondierende Softwarestand der aktuellste ist.
-
Gemäß dieser bevorzugten Durchführungsform des erfindungsgemäßen Verfahrens wird automatisch festgestellt, ob die im Fahrzeug geladene Fahrzeugsoftware die aktuellste mit dem jeweiligen Entwickler verknüpfte Software ist. Besonders bevorzugt weist das System über die Mitteilung auf eine fehlende Kompatibilität von aktueller und korrespondierender Software hin. Ausgestaltungen der Mitteilung und Reaktionsmöglichkeiten werden untenstehend erläutert.
-
In einer ebenfalls bevorzugten Durchführungsform des erfindungsgemäßen Verfahrens wird eine in der bevorstehenden Testfahrt zu testende Software als charakteristische Eigenschaft der Testfahrt ermittelt. Das Ermitteln erfolgt dabei bevorzugt anhand eines Eintrags in einem Buchungssystem des Fahrzeugs, welches lokal im Fahrzeug vorliegt oder servergebunden ausgebildet ist. Gemäß dieser Durchführungsform handelt es sich bei der zu der charakteristischen Eigenschaft korrespondierenden Software ebenfalls um die in der bevorstehend Testfahrt zu testende Software. Diese Durchführungsform benötigt die korrekte Verwendung des Buchungssystems und ist somit gegenüber der Erkennung des verantwortlichen Entwicklers im Fahrzeug selbst nachteilig. Vorteilhaft kann diese Durchführungsform jedoch zeitlich weiter vor dem Beginn der geplanten Testfahrt erfolgen.
-
In einer ferner bevorzugten Durchführungsform des erfindungsgemäßen Verfahrens wird als charakteristische Eigenschaft eine in der bevorstehenden Testfahrt zu testende Funktionalität des Fahrzeugs ermittelt. Die zu testende Funktionalität wird dabei bevorzugt ebenfalls aus dem Buchungssystem des Testfahrzeugs ausgelesen. Dieses weist beispielsweise verschiedene Möglichkeiten zur Auswahl einer Funktionalität auf, neben der Möglichkeit der freien Eingabe auch die Möglichkeit einer Auswahl aus einer vordefinierten Liste von Funktionalitäten. Derartige vordefinierte Funktionalitäten umfassen beispielsweise Kategorien von Funktionalitäten, wie beispielsweise Spracherkennung, Navigation, Motorsteuerung, Abgas etc.
-
Der zu der testenden Funktionalität korrespondierende Softwarestand wird bevorzugt anhand einer Dokumentation der Software des Fahrzeugs ermittelt. Beispielsweise werden in dem Versionenkontrollsystem oder dergleichen verschiedene Module der Fahrzeugsoftware verschiedenen Fahrzeugfunktionalitäten zugeordnet. Somit wird im erfindungsgemäßen Verfahren anhand der zu testenden Funktionalität zunächst ein entsprechendes Modul der Fahrzeugsoftware ermittelt. Ferner wird ermittelt, ob dieses Fahrzeugsoftwaremodul in der aktuellsten Version auf dem Fahrzeug geladen ist. Ist dies nicht der Fall, wird bevorzugt eine aktuellste Version der Fahrzeugsoftware aus dem Versionenkontrollsystem geladen. Somit ist auch gemäß dieser Durchführungsform bei korrekter Nutzung des Buchungssystems vorteilhaft stets die für die bevorstehende Testfahrt notwendige Software im Fahrzeug vorhanden.
-
In einer ebenfalls bevorzugten Durchführungsform des erfindungsgemäßen Verfahrens wird als charakteristische Eigenschaft ein für die bevorstehende Testfahrt zu verwendendes Testgerät ermittelt. Das Testgerät wird bevorzugt über einen Anschluss an das Fahrzeug detektiert, beispielsweise über WLAN, Bluetooth, Mobilfunk, USB oder OBDII. Alternativ bevorzugt wird das für die bevorstehende Testfahrt zu verwendende Testgerät anhand eines Eintrags in das Buchungssystem des Fahrzeugs verwendet. Bei dem Testgerät handelt es sich beispielsweise um ein Abgastestgerät, um ein mit einem Batteriesystem des Fahrzeugs verbundenes Messgerät oder dergleichen. Sofern ein für die Testfahrt verwendetes Testgerät an das Fahrzeug angeschlossen wird, ist gegebenenfalls eine bestimmte Software in dem Fahrzeug für die korrekte Funktion des Testgeräts notwendig. Diese für das Testgerät spezifische Software, beziehungsweise der typische Softwarestand, wird gemäß dieser Durchführungsform bevorzugt als korrespondierender Softwarestand ermittelt. Durch Ermitteln des Testgeräts wird im erfindungsgemäßen Verfahren die Voraussetzung geschaffen, vor der Testfahrt zu prüfen, ob der benötigte Softwarestand oder die benötigte Software überhaupt im Fahrzeug vorliegt.
-
Gemäß dem erfindungsgemäßen Verfahren wird bei dem Ermitteln einer Inkompatibilität des aktuellen Softwarestands und des korrespondierenden Softwarestands eine Mitteilung ausgegeben. Gemäß einer bevorzugten Durchführungsform wird bei einer Inkompatibilität zwischen dem aktuellen Softwarestand und dem korrespondierenden Softwarestand des Fahrzeugs ferner der korrespondierende Softwarestand in das Fahrzeug geladen. Das Laden erfolgt dabei von einem Netzwerkserver, beispielsweise dem das Versionenkontrollsystem aufweisenden Netzwerkserver oder einem mobilen Endgerät des Entwicklers. Somit wird sichergestellt, dass die zur Testfahrt benötigte Software im Fahrzeug vorhanden ist.
-
In einer besonders bevorzugten Durchführungsform, in der die charakteristische Eigenschaft der Testfahrt wie oben beschrieben anhand eines Buchungssystems des Fahrzeugs ermittelt wird, erfolgt das Laden des korrespondierenden Softwarestands bevorzugt zeitlich vor einem geplanten Beginn der Testfahrt in das Fahrzeug. Insbesondere bevorzugt erfolgt das Laden um einen Zeitabschnitt vor der geplanten Testfahrt, der einen zum Laden des korrespondierenden Softwarestands benötigten Zeitabschnitt übersteigt. Somit kann die geplante Testfahrt vorteilhaft mit dem richtigen Softwarestand und ohne Verzögerungen durchgeführt werden. Der Beginn der Testfahrt wird dabei bevorzugt aus dem Buchungssystem des Fahrzeugs ermittelt. Ebenfalls bevorzugt wird das Verfahren am Abend für einen darauffolgenden Tag durchgeführt.
-
Ferner bevorzugt wird die zumindest bei Inkompatibilität der Softwarestände ausgegebene Mitteilung vor dem Laden des korrespondierenden Softwarestands an einen für die Testfahrt verantwortlichen Entwickler ausgegeben. Die Mitteilung erfolgt bevorzugt optisch auf einem Bildschirm des Fahrzeugs oder eines mobilen Endgeräts oder über eine akustische Mitteilung. Ferner enthält die Mitteilung bevorzugt eine Eingabeaufforderung an den Nutzer oder Entwickler, dass dieser das Laden der korrespondierenden Software in das Fahrzeug bestätigt.
-
Ferner bevorzugt werden in der Mitteilung die den verschiedenen Entwicklern zugeordneten Softwarestände und/oder der aktuelle Softwarestand visualisiert. Eine derartige Visualisierung erfolgt bevorzugt mit Darstellung der an der Software vorgenommenen Änderungen, gegebenenfalls in Verbindung mit (aggregierten) Commit-Nachrichten und/oder einer grafischen Darstellung der Baumstruktur der Softwareversionen. Die Eingabe zur Bestätigung des Ladens weist dabei ferner eine Auswahl einer der visualisierten Softwarestände auf. Ferner bevorzugt sind dabei nur einige der Softwarestände zum Laden in das Fahrzeug wählbar, beispielsweise nur solche Softwarestände, die als „Developer“ gekennzeichnet sind. Hingegen werden als „Experimental“ gekennzeichnete Softwarestände bevorzugt nicht angezeigt und/oder sind durch den Nutzer nicht zum Laden in das testfahrzeug auswählbar.
-
Weitere bevorzugte Ausgestaltungen der Erfindung ergeben sich aus den übrigen, in den Unteransprüchen genannten Merkmalen.
-
Die verschiedenen, in dieser Anmeldung genannten Ausführungsformen der Erfindung sind, sofern im Einzelfall nicht anders ausgeführt, mit Vorteil miteinander kombinierbar.
-
Die Erfindung wird nachfolgend in Ausführungsbeispielen anhand der zugehörigen Zeichnungen erläutert. Es zeigen:
- 1 eine schematische Darstellung eines Systems aus einem Kraftfahrzeug und einem Netzwerkserver zum Durchführen des erfindungsgemäßen Verfahrens; und
- 2 eine schematische Darstellung eines erfindungsgemäßen Verfahrens gemäß einer Durchführungsform.
-
1 zeigt eine schematische Darstellung eines Systems 100 aus einem Fahrzeug 10 und einem Netzwerkserver 70 zum Durchführen des erfindungsgemäßen Verfahrens.
-
1 zeigt insbesondere ein Blockdiagram eines beispielhaften zweispurigen Fahrzeugs 10 mit Verbrennungs-, Elektro- oder Hybridmotor. Das Fahrzeug 10 umfasst eine Vielzahl erster Sensoren, insbesondere einen ersten Sensor 11, einen zweiten Sensor 12, und einen dritten Sensor 13. Die ersten Sensoren 11, 12, 13 sind eingerichtet zum Erfassen von Umgebungsdaten des Fahrzeugs 10 und umfassen beispielsweise eine Kamera zum Erfassen eines Bildes einer das Fahrzeug 10 unmittelbar umgebenden Umwelt, Abstandssensoren, wie Ultraschallsensoren oder LIDAR, zum Erfassen von Abständen zu das Fahrzeug 10 umgebenden Objekten. Die ersten Sensoren 11, 12, 13 übertragen die von ihnen erfassten Umgebungssignale an eine erste Steuereinheit 40 des Fahrzeugs 10.
-
Das Fahrzeug 10 weist ferner eine Mehrzahl zweiter Sensoren, insbesondere einen vierten Sensor 51, einen fünften Sensor 52, und einen sechsten Sensor 53 auf. Bei den zweiten Sensoren 51, 52 ,53 handelt es sich um Sensoren zum Ermitteln von das Fahrzeug 10 selbst betreffenden Zustandsdaten, wie beispielsweise aktuelle Lage- und Bewegungsinformationen des Fahrzeugs. Bei den zweiten Sensoren handelt es sich zum Beispiel um Geschwindigkeitssensoren, Beschleunigungssensoren, Neigungssensoren, Sensoren zum Messen einer Eintauchtiefe eines Stoßdämpfers, Raddrehzahlsensoren oder dergleichen. Ferner weisen die zweiten Sensoren Innenraumsensoren, wie beispielsweise eine Innenraumkamera oder dergleichen auf. Die zweiten Sensoren 51, 52, 53 übermitteln die von ihnen erfassten Zustandssignale an die erste Steuereinheit 40 des Fahrzeugs 10. Darüber hinaus übermitteln die zweiten Sensoren 51, 52, 53 Messergebnisse an ein Fahrsystem 30.
-
Das Fahrzeug 10 weist ferner ein erstes Kommunikationsmodul 20 mit einem Speicher 21 und einem oder mehreren Transpondern beziehungsweise Sendeempfängern 22 auf. Bei den Transpondern 22 handelt es sich um einen Funk-, WLAN-, GPS- oder Bluetooth-Sendeempfänger oder dergleichen. Der Transponder 22 kommuniziert mit dem internen Speicher 21 des ersten Kommunikationsmoduls 20, beispielsweise über einen geeigneten Datenbus. Mittels des Transponders 22 kann beispielsweise die aktuelle Position des Fahrzeugs 10 durch Kommunikation mit einem GPS-Satelliten 61 ermittelt werden. Das erste Kommunikationsmodul 20 kommuniziert auch mit der ersten Steuereinheit 40.
-
Darüber hinaus ist das erste Kommunikationsmodul 20 dafür eingerichtet, mit einem mobilen Netzwerkserver 70, insbesondere einem Backendserver eines Fahrzeugherstellers, Vertragspartners oder Flottenbetreibers zu kommunizieren. Die Kommunikation erfolgt dabei insbesondere mit einem zweiten Kommunikationsmodul 90 des Netzwerkservers 70. Bevorzugt ist das erste Kommunikationsmodul 20 dazu eingerichtet, über ein Mobilfunknetz, beispielsweise ein 4G oder 5G Mobilfunknetz, zu kommunizieren. Das Kommunikationsmodul 20 ist ferner zum Ermitteln einer Signalstärke des Mobilfunknetzes ausgebildet. Die ermittelten Signalstärken werden bevorzugt mit einer (GPS) Position des Fahrzeugs 10 verknüpft.
-
Das Fahrzeug 10 weist ferner das Fahrsystem 30 auf, das zum vollständig automatischen Fahrbetrieb, insbesondere zur Längs- und Querführung, des Fahrzeugs 10 eingerichtet ist. Das Fahrsystem 30 weist ein Navigationsmodul 32 auf, das zum Berechnen von Routen zwischen einem Start- und einem Zielpunkt und zum Ermitteln der entlang dieser Route vom Kraftfahrzeug 10 durchzuführenden Manöver eingerichtet ist. Darüber hinaus umfasst das Fahrsystem 30 einen internen Speicher 31, beispielsweise für Kartenmaterialien, der mit dem Navigationsmodul 32 kommuniziert, beispielsweise über einen geeigneten Datenbus. Ferner kommuniziert das Fahrsystem 30 mit der Steuereinheit 40 und empfängt von der Steuereinheit 40 mittels des ersten Kommunikationsmoduls 20 von dem Netzwerkserver 70 empfangene Trajektorieinformationen. Bevorzugt ist das Navigationsmodul 32 dazu eingerichtet, anhand dieser Trajektorieinformationen eine Route des Fahrzeugs 10 zu ermitteln.
-
Zumindest ein Teil der zweiten Sensoren 51, 52, 53 des Kraftfahrzeugs 10 übermittelt seine Messergebnisse direkt an das Fahrsystem 30. Bei diesen unmittelbar an das Fahrsystem 30 übermittelten Daten handelt es sich insbesondere um aktuelle Lage- und Bewegungsinformationen des Kraftfahrzeugs. Diese werden bevorzugt von Geschwindigkeitssensoren, Beschleunigungssensoren, Neigungssensoren, etc. erfasst.
-
Das Kraftfahrzeug 10 weist ferner eine erste Steuereinheit 40 auf, die über einen internen Speicher 41 und eine CPU 42 verfügt, welche miteinander kommunizieren, beispielsweise über einen geeigneten Datenbus. Darüber hinaus steht die erste Steuereinheit 40 in Kommunikationsverbindung mit zumindest den ersten Sensoren 11, 12, 13, den zweiten Sensoren 51, 52, 53, dem ersten Kommunikationsmodul 20 und dem Fahrsystem 30, beispielsweise über eine oder mehrere jeweilige CAN-Verbindungen, eine oder mehrere jeweilige SPI-Verbindungen oder andere geeignete Datenverbindungen.
-
Das Kraftfahrzeug 10 weist ferner zumindest eine Benutzerschnittstelle 35 auf, die eine Interaktion zwischen zumindest einem Nutzer 1 des Fahrzeugs 10 und dem Fahrzeug 10, insbesondere dessen Steuereinheit 40, ermöglicht. Die Benutzerschnittstelle weist hierfür zumindest ein Eingabemittel 35 zum Empfangen von Nutzereingaben und zumindest ein Ausgabemittel 37 zum Ausgeben von Informationen an einen Nutzer auf. Das zumindest eine Eingabemittel weist zumindest ein Mikrofon zum Erfassen einer Spracheingabe eines Nutzers sowie ein Modul zur Spracherkennung auf. Das Modul zur Spracherkennung kann dabei Teil des Eingabemittels 36 oder der Steuereinheit 40 sein. Das zumindest eine Eingabemittel 36 kann darüber hinaus ein Touchscreen oder dergleichen umfassen. Das zumindest eine Ausgabemittel 37 weist zumindest einen Lautsprecher sowie ein Modul zur Sprachausgabe auf. Das Modul zur Sprachausgabe kann dabei Teil des Ausgabemittels 37 oder der Steuereinheit 40 sein. Das zumindest eine Ausgabemittel 37 kann darüber hinaus einen Bildschirm umfassen.
-
Der Netzwerkserver 70 weist eine zweite Steuereinheit 80 auf, welche einen internen Speicher 81 und eine CPU 82 aufweist, die über einen geeigneten Datenbus miteinander kommunizieren. Der Netzwerkserver 70 weist ferner ein zweites Kommunikationsmodul 90 auf. Das zweite Kommunikationsmodul 90 weist einen Speicher 92 und einen oder mehrere Transponder beziehungsweise Sendeempfänger 91 auf. Bei den Transpondern 91 handelt es sich um einen Funk-, WLAN-, GPS- oder Bluetooth-Sendeempfänger oder dergleichen. Der Transponder 91 kommuniziert mit dem internen Speicher 92 des zweiten Kommunikationsmoduls 90 über einen geeigneten Datenbus. Bevorzugt ist das zweite Kommunikationsmodul 90 dazu eingerichtet, über ein LTE-Mobilfunknetz zu kommunizieren.
-
Der Netzwerkserver 70 des Systems 100 weist bevorzugt ein Versionenkontrollsystem einer Fahrzeugsoftware auf, in dem verschiedene Softwarestände der Fahrzeugsoftware oder Komponenten davon gespeichert sind. Alle in dem Versionenkontrollsystem gespeicherten Softwarestände sind dabei über entsprechende Identifikatoren eindeutig bestimmt. Ferner sind alle Softwarestände in der Regel auch wiederherstellbar beziehungsweise ausführbar. Der Netzwerkserver 70 weist ferner bevorzugt ein Buchungssystem des Fahrzeugs 10 auf, wobei das Buchungssystem dem Buchen des Fahrzeugs 10 für Testfahrten dient. Bei einer Buchung wird dabei bevorzugt das Fahrzeug 10, der die Testfahrt durchführende Entwickler, Datum und Uhrzeit der Testfahrt, der Grund der Testfahrt und gegebenenfalls weitere Informationen, zum Beispiel zu für die Testfahrt verwendeten Testgeräten, in das Buchungssystem eingetragen.
-
Die erste Steuereinheit 40 des Fahrzeugs 10, das Kommunikationsmodul 20, das Fahrsystem 30, die Benutzerschnittstelle 35 sowie die ersten Sensoren 11, 12, 13, und zweiten Sensoren 51, 52, 53 benötigen für ihren Betrieb eine bestimmte Software, wobei verschiedene Softwarestände mit verschiedenen Funktionalitäten verknüpft sind. Diese Funktionalitäten und somit die Softwarestände unterliegen während der Entwicklung des Fahrzeugs 10 einem stetigen Wandel. Bei Testfahrten mit dem Fahrzeug 10 besteht somit die Gefahr, dass in der jeweiligen Komponente nicht der für die geplante Testfahrt korrekte Softwarestand geladen ist.
-
Durch das Durchführen des erfindungsgemäßen Verfahrens wird vorteilhaft sichergestellt, dass vor dem Beginn der Testfahrt der richtige Softwarestand in der Komponente geladen ist, um die Testfahrt sinnvoll durchführen zu können. 2 zeigt ein schematisches Ablaufdiagramm eines von dem erfindungsgemäßen System 100 durchgeführten erfindungsgemäßen Verfahrens. Das erfindungsgemäße Verfahren weist im Wesentlichen die folgenden Verfahrensschritte auf, welche von dem Fahrzeug 10, von dem Netzwerkserver 70 oder von dem System 100 aus Fahrzeug 10 und Netzwerkserver 70 durchgeführt werden.
-
In einem ersten Schritt S100 des erfindungsgemäßen Verfahrens detektiert das Fahrzeug 10 das eine Testfahrt bevorsteht. Dies erfolgt beispielsweise, indem ein Öffnen des Fahrzeugs mittels eines zweiten Sensors, detektiert wird, der Empfang eines Funksignals eines Funkschlüssels mittels des Transponders 21 empfangen wird oder eine entsprechende Eingabe über das Eingabemittel 36 erfolgt. Alternativ empfängt das Fahrzeug 10 mittels des ersten Kommunikationsmoduls 20 eine Nachricht eines Netzwerkservers 70, mit der auf eine bevorstehende Testfahrt hingewiesen wird. Diese Nachricht wird bevorzugt von dem auf dem Netzwerkserver, insbesondere in dessen zweiter Steuereinheit 80, installierten und ausgeführten Buchungssystem erzeugt und mittels des zweiten Kommunikationsmoduls 90 an das Fahrzeug 10 übermittelt und dort von der ersten Steuereinheit 40 ausgewertet.
-
In einem Schritt S200 des erfindungsgemäßen Verfahrens wird zumindest eine charakteristische Eigenschaft der bevorstehenden Testfahrt ermittelt. Dabei kann es sich beispielsweise um eine Angabe zu dem Grund der Testfahrt, beispielsweise zu einem zu testenden Softwarestand oder zu einer zu testenden Funktionalität, handeln. Eine solche Angabe ist dabei bevorzugt bereits in der zuvor von dem Netzwerkserver 70 empfangenen Nachricht enthalten und dem Buchungssystem des Netzwerkservers 70 für das Fahrzeug 10 entnommen. Alternativ wird, beispielsweise in Reaktion auf das Empfangen eines Funksignals eines Funkschlüssels, mittels einer Außenkamera 11 ein Bild einer sich dem Fahrzeug nähernden Person aufgenommen oder wird, beispielsweise in Reaktion auf das Öffnen einer Fahrzeugtür oder ein Signal eines Sitzdrucksensors, mit einer Innenkamera 51 ein Bildsignal einer sich in dem Fahrzeug befindlichen Person aufgenommen wird. Ein solches Bildsignal wird an die Steuereinheit 40 übermittelt, um mittels Gesichtserkennung einen die Testfahrt durchführenden (verantwortlichen) Entwickler zu identifizieren. Alternativ kann der Entwickler bereits anhand des Funksignals des Funkschlüssels identifiziert werden oder anhand einem mit dem Fahrzeug verbundenen mobilen Endgerät, beispielsweise anhand dessen MAC Adresse.
-
In Schritt S200 wird die charakteristische Eigenschaft der bevorstehenden Testfahrt von der Steuereinheit 40 des Fahrzeugs 10 ermittelt. Ferner ermittelt die Steuereinheit 40 in Schritt S300 einen zu der charakteristischen Eigenschaft korrespondierenden Softwarestand der Fahrzeugsoftware oder zumindest von Modulen der Fahrzeugsoftware. Dies erfolgt beispielsweise, indem durch Kommunikation mit dem Versionenkontrollsystem auf dem Netzwerkserver 70 ein zu dem zuvor identifizierten für die Testfahrt verantwortlichen Entwickler korrespondierender aktuellster Softwarestand ermittelt wird. Alternativ enthielt die zuvor von dem Buchungssystem des Fahrzeugs 10 auf dem Netzwerkserver 70 empfangene Nachricht eine Angabe zu einem in der bevorstehenden Testfahrt zu testenden Softwarestand, so dass dieser unmittelbar als korrespondierender Softwarestand gesetzt werden kann.
-
In Schritt S400 wird der ermittelte zu der charakteristischen Eigenschaft der bevorstehenden Testfahrt korrespondierende Softwarestand mit einem aktuellen Softwarestand von Fahrzeugsoftware des Fahrzeugs 10 verbunden. Dabei kann es sich um einen Softwarestand der Fahrzeugsoftware als Ganzes oder um einen Softwarestand von Modulen der Fahrzeugsoftware handeln. Soll in der Testfahrt beispielsweise die Funktion der Benutzerschnittstelle 35 geprüft werden, betrifft der korrespondierende Softwarestand eine Software der Benutzerschnittstelle 35 und somit ist ein aktueller Softwarestand der Software der Benutzerschnittstelle zu ermitteln. Ebenso kann die zu testende Funktionalität von der Software der Steuereinheit 40 oder von Software des Fahrsystems 30 verursacht sein, so dass entsprechend die aktuellen Softwarestände dieser Komponenten zu ermitteln sind.
-
In Schritt S500 wird die Kompatibilität des korrespondierenden und des aktuellen Softwarestandes ermittelt. Sofern der korrespondierende Softwarestand von dem ermittelten aktuellen Softwarestand des Fahrzeugs 10 oder der entsprechenden Komponente verschieden ist, wird eine Mitteilung an einen Nutzer des Fahrzeugs 10, beispielsweise den verantwortlichen Entwickler ausgegeben. Diese Mitteilung wird beispielsweise mittels des Ausgabemittels 37 der Benutzerschnittstelle 35 ausgegeben. Alternativ wird die Mitteilung mittels des Kommunikationsmoduls 20 an ein mobiles Endgerät des Nutzers übermittelt und durch dieses ausgegeben. Die Mitteilung enthält dabei eine Eingabeaufforderung an den Nutzer zu spezifizieren, ob der ermittelte korrespondierende Softwarestand in das Fahrzeug geladen werden soll. Gibt der Nutzer, über das Eingabemittel 36 oder sein mobiles Endgerät, eine entsprechende Eingabe ab, lädt das Fahrzeug 10 in Schritt S600 den korrespondierenden Softwarestand aus dem Versionenkontrollsystem des Netzwerkservers 70 in die Steuereinheit 40 oder in die entsprechende Fahrzeugkomponente (beispielsweise die Benutzerschnittstelle 35 oder das Fahrsystem 30). Somit liegt vor dem Beginn der Testfahrt vorteilhaft der richtige Softwarestand im Fahrzeug 10 beziehungsweise der jeweiligen Fahrzeugkomponente vor.
-
Bezugszeichenliste
-
- 10
- Kraftfahrzeug
- 11
- erster Sensor
- 12
- zweiter Sensor
- 13
- dritter Sensor
- 20
- Kommunikationsmodul
- 21
- Speicher
- 22
- Transponder
- 30
- Fahrsystem
- 31
- Speicher
- 32
- Navigationsmodul
- 35
- Benutzerschnittstelle
- 36
- Eingabemittel
- 37
- Ausgabemittel
- 40
- Steuereinheit
- 41
- Speicher
- 42
- CPU
- 51
- vierter Sensor
- 52
- fünfter Sensor
- 53
- sechster Sensor
- 61
- Satellit
- 62
- Basisstation
- 63
- anderes Fahrzeug
- 70
- Netzwerkserver
- 80
- Steuereinheit
- 81
- Speicher
- 82
- CPU
- 90
- Kommunikationsmodul
- 91
- Transponder
- 92
- Speicher
- 100
- System
