-
Die vorliegende Erfindung betrifft ein Verfahren zum Warten eines Fahrzeuges. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
-
Stand der Technik
-
Zur Wartung von Fahrzeugen werden nach dem Stand der Technik zunehmend Fahrzeugdiagnosesysteme eingesetzt. Diese Gattung umfasst unterschiedlichste aus Hard- und Software bestehende Analysewerkzeuge, die im Allgemeinen Funktionalität zum Auslesen von Steuergerätedaten und zum Aufzeichnen von Datenbuskommunikation bieten. Bekannte Fahrzeugdiagnosesysteme stellen neben der reinen Fahrzeugdiagnose auch Funktionen zum Aktualisieren der Steuergeräte bereit.
-
Die Offenlegungsschrift
DE 10 2007 050 994 A1 beschreibt ein solches Service-Diagnosegerät für Kraftfahrzeuge, insbesondere für den Werkstatteinsatz, zum Auslesen von Daten eines Bordcomputers eines Kraftfahrzeugs mit mindestens einer Logikeinheit. Hier ist vorgesehen, dass das Service-Diagnosegerät eine RFID-Leseeinheit aufweist, die signalleitend mit der Logikeinheit verbunden oder verbindbar ist.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Verfahren zum Warten eines Fahrzeuges, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
-
Ein Vorzug dieser Lösung liegt in der hierdurch eröffneten Möglichkeit, dringende Wartungsaufgaben wie Steuergerät-Softwareupdates oder Steuergerät-Kalibrierungen unmittelbar durch den Erstausrüster (original equipment manufacturer, OEM), Nutzer oder Fahrer ausführen zu lassen. Das Aufsuchen einer Reparaturwerkstatt wird somit verzichtbar.
-
Wartungsaufgaben lassen sich auf diese Weise jederzeit und überall vor Ort – etwa über die Benutzerschnittstelle einer Haupteinheit (head unit) – und selbst aus der Ferne bewältigen. Zu denken ist in letzterer Hinsicht beispielsweise an eine Heimschnittstelle des Fahrzeuges oder ein entsprechendes Backend des Erstausrüsters.
-
Andere Dienste und Programme können die ständig verfügbare Diagnosefähigkeit etwa für neue Geschäftsmodelle wie die Fernaktivierung von Funktionen nutzen.
-
Etablierte – insbesondere auf einem offenen diagnostischen Datenaustausch (open diagnostic data exchange, ODX) basierende – Abläufe zur Konfektionierung und Verwendung der Steuergerätesoftware lassen sich ohne nennenswerte Änderung wiederverwenden, da die vorgeschlagene Wartungssoftware sich wie ein herkömmliches externes Fahrzeugdiagnosesystem verhält.
-
Die Abwärtskompatibilität zu bestehenden Diagnoseansätzen bleibt gewährleistet, sodass Werkstattpersonal mit einem externen Fahrzeugdiagnosesystem Wartungsaufgaben wie gewohnt ausführen kann.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass das Einleiten und Prüfen der Bearbeitung des Wartungsauftrages durch ein Steuergerät des Fahrzeuges mittels eines vereinheitlichten Diagnosedienstes (unified diagnostic services, UDS) gemäß ISO 14229 über einen CAN-Bus erfolgt. Da dieses Kommunikationsprotokoll bei fast allen Neuentwicklungen der Fahrzeughersteller verwendet wird und kein firmenspezifischer Standard ist, lassen sich auf diese Weise alle im Fahrzeug verbauten Steuergeräte kontaktieren.
-
Gemäß einem weiteren Aspekt kann vorgesehen sein, dass die Wartungssoftware unter einem Hypervisor (virtual machine monitor, VMM) neben einer Altsoftware des Zentralgateways auf letzterem betrieben wird. Möglicherweise negative Auswirkungen auf die Altsoftware lassen sich auf diesem Wege weitgehend vermeiden.
-
Kurze Beschreibung der Zeichnungen
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:
-
1 das Blockdiagramm einer zur Ausführung des Verfahrens geeigneten Systemarchitektur.
-
2 ein Flussdiagramm des Verfahrens gemäß einer beispielhaften Ausführungsform.
-
3 eine mögliche fahrzeuginterne Softwarearchitektur zur Ausführung des Verfahrens.
-
Ausführungsformen der Erfindung
-
1 illustriert den Grundgedanken der vorgeschlagenen Lösung, wonach ein herkömmliches externes, in der Fahrzeugtechnik als „Tester“ bezeichnetes Fahrzeugdiagnosesystem gleichsam durch die ständig verfügbare Wartungssoftware 10 der vorliegenden Ausführungsform ersetzt wurde. Die Wartungssoftware 10 wird hierzu unter einem Hypervisor 14 neben einer Altsoftware 12 des Zentralgateways 16 auf letzterem betrieben.
-
Abbildungsgemäß lässt sich das auf diese Weise ausgerüstete Fahrzeug 18 über alternative Übertragungskanäle 22 – wahlweise über die Cloud 28 – mit einem Backend 20 verbinden. Zur Verfügung steht einerseits ein drahtgebundener (24), etwa auf Borddiagnose (on-board diagnosis, OBD), DVD oder einen universellen seriellen Bus (universal serial bus, USB) 26 basierender Übertragungskanal 22. Andererseits kann die Wartungssoftware drahtlos (30), beispielsweise per GSM, LTE oder WLAN 32 mit dem Backend 20 kommunizieren.
-
Das Backend 20 selbst umfasst eine bidirektional mit einem Update-Manager 34 verbundene Update-Datenbank 36, die ein anzuwendendes Update 38 über einen Over-the-Air-Server 40 an die Wartungssoftware 10 übertragen kann. Die Wartungssoftware 10 spielt sodann durch die Altsoftware 12 über ein gemeinsames Netz 42 des Fahrzeuges 18 das Update 38 auf den Steuergeräten 44, 46 ein. Einmal auf der Steuergerätehardware 48 gespeichert kann das Update 38 durch die zugehörige Steuergerätesoftware 49 aktiviert werden.
-
Das hierzu angewendete Verfahren 50 sei nunmehr im Einzelnen anhand 2 erläutert. Der Eigner oder Ausrüster 51 des Fahrzeuges 18 erzeugt (53) in der optionalen Cloud 28 über eine Website 52 zunächst den Auftrag zum Einspielen des Updates 38 im Backend 20. Die Wartungssoftware 10 des Fahrzeuges 18 empfängt (54) diesen Wartungsauftrag, etwa über LTE oder ein drahtloses Netzwerk, von dem Backend 30. Falls eine drahtlose Übertragung nicht möglich ist, kann der Fahrer 56 den Auftrag vorzugsweise auf einen Flash-Speicher kopieren, der dann im Fahrzeug 18 über einen universellen seriellen Bus 26 beispielsweise mit der Haupteinheit 55 verbunden wird. Dort lässt sich der Auftrag von der Wartungssoftware 10 genauso bearbeiten, als wäre er über die Mobilschnittstelle eingegangen.
-
An dieser Stelle sei bemerkt, dass in einer alternativen Konfiguration das Wartungsprogramm 10 den Auftrag über die Haupteinheit 55 des Fahrzeuges 18 ebenso durch jedes andere „digitale Transportmedium“ wie eine SD-Karte, CD/DVD oder ein Mobiltelefon mit Bluetooth empfangen (54) mag, ohne den Rahmen der Erfindung zu verlassen.
-
Die Wartungssoftware 10 prüft (57) sodann den Wartungsauftrag hinsichtlich seiner – etwa durch Echtheit und Berechtigung des Auftraggebers bestimmten – Sicherheit und – etwa durch Kompatibilitätsanforderungen bestimmten – Korrektheit. Im Erfolgsfall 58 prüft (59) die Wartungssoftware 10 zudem die Sicherheit des Fahrzeuges 18 und stellt beispielsweise dessen Stillstand, Batteriekapazität, größtmögliche Diagnosezeit und Notfallreserve sicher. Hat auch letztere Prüfung Erfolg 60, so holt die Wartungssoftware 10 die Zustimmung ihres Nutzers ein (61) und, falls dieser die Zustimmung erteilt (62), veranlasst (63) zum Beispiel mittels UDS 65 die Bearbeitung 64 des Wartungsauftrages durch das zuständige Steuergerät 46. Prinzipiell sind aber auch andere Diagnoseprotokolle wie KWP2000 oder ISO-OBD möglich.
-
Daraufhin prüft (66) die Wartungssoftware 10 die erfolgte Bearbeitung 64. Im Falle einer grundsätzlich ordnungsmäßigen, jedoch noch unvollständigen (67) Bearbeitung 64 veranlasst (63) die Wartungssoftware 10 die weitere Bearbeitung 64, während sie bei vollständiger und ordnungsmäßiger (68) Bearbeitung 64 den Wartungsauftrag abschließt (69). In diesem Fall wird das Endergebnis 70 des Wartungsauftrages an den Eigner, Ausrüster 51 oder Fahrer 56 ausgegeben (71), bevor das Verfahren 50 endet (72). Eine negative Rückmeldung hingegen wird ausgegeben (71), falls der Wartungsauftrag ordnungswidrig (73) oder die Sicherheit unzureichend (74) ist, der Nutzer die Zustimmung verweigert (75) oder die Bearbeitung 64 endgültig gescheitert (76) ist.
-
3 schließlich verdeutlicht eine mögliche IT-Infrastruktur innerhalb des Fahrzeuges 18 in weiteren Einzelheiten einschließlich notwendiger Nutzerinteraktion etwa für Stornierung, Aufschub oder Auslösung einzelner Wartungsaufträge, wobei bestehende Funktionalität 87 und funktionale Erweiterungen 88 gemäß der Legende 89 dargestellt sind. Der Nutzer oder Fahrer 56 des Fahrzeuges 18 ist demnach zur Anwendungssteuerung 77 beispielsweise im Rahmen der Installation, Löschung oder Konfiguration einerseits mit einer Update-Benutzersteuerung 78 der Haupteinheit 55, zur Update-Steuerung 79 („Ja“/„Nein“/„Später“) andererseits mit der Wartungssoftware 10 des Zentralgateways 16 des Fahrzeuges 18 verbunden.
-
Die Update-Benutzersteuerung 78 wird dabei neben weiteren Ausrüster-Anwendungen 80 in einem Ausrüsterbereich 81, Fremdanwendungen 82 hingegen in einem beschränkten Fremdbereich 83 der Haupteinheit 55 unter deren Hypervisor 90 betrieben. Ein sicherer Start (secure boot) und sicherer Flashloader 84 entsprechen wie Bluetooth 85, USB 26, Hauptprozessor (central processing unit, CPU) 86, erstes Hardware-Sicherheitsmodul 91 und Ethernet 92 im Wesentlichen der herkömmlichen Konfiguration der Haupteinheit 55.
-
Die im Folgenden beschriebenen Merkmale sind lediglich exemplarisch und keinesfalls als erfindungswesentlich zu verstehen.
-
Die Haupteinheit 55 ist über das gemeinsame Ethernet 92 mit dem Zentralgateway 16 des Fahrzeuges 18 verbunden, das zudem über einen ersten Bus 93 mit dem Diagnosesteuergerät 94 (diagnostic control unit, DCU) des Karosseriebereiches 95, über einen zweiten Bus 96 mit dem Diagnosesteuergerät 97 des Sicherheitsbereiches 98 und über einen dritten Bus 99 mit dem Diagnosesteuergerät 11 eines weiteren Bereiches 13 und den jeweiligen Steuergeräten 15 der Bereiche 95, 98, 13 kommuniziert. Auch das Zentralgateway 16 verfügt ferner über einen Hauptprozessor 17, Flash-Speicher 19, ein zweites Hardware-Sicherheitsmodul 21 sowie LTE 23, eine speicherprogrammierbare Steuerung (programmable logic controller, PLC) 25, Borddiagnose 27 mitsamt Diagnoseanschluss (diagnostic link connector, DLC) 29 sowie Ethernet 92. Schließlich verfügt das Zentralgateway 16 ebenfalls über einen sicheren Start und sicheren Flashloader 31, welcher die Ausführung des Hypervisors 14 mit grundlegender Zugriffssteuerung, Dienstgüte und Echtzeitfähigkeit erlaubt. Dieser wiederum betreibt neben anderen Anwendungen 43 in einem Wartungssoftwarebereich 33 die Wartungssoftware 10, in einem Fremdbereich 35 mit beschränkter Virtualisierung-Schnittstelle einen Fremdanwendungsmarktplatz-Client 37 und in einem Ausrüsterbereich 39 verschiedene Ausrüster-Anwendungen 41.
-
Schließlich weist das Fahrzeug 18 eine über Ethernet 92 mit dem Zentralgateway 16 verbundene Datenübertragungseinheit (communications control unit, CCU) 45 auf, die ihrerseits in herkömmlicher Weise mit einem Hauptprozessor 47, einem Hardware-Sicherheitsmodul 1, LTE 2 und einer Fahrzeug-Infrastruktur-Kommunikation 3 ausgestattet ist. Auch die Datenübertragungseinheit 45 verfügt ferner über einen sicheren Start und sicheren Flashloader 4, AUTOSAR-Laufzeitumgebung (runtime environment, RTE) 5 mit Ausrüsterbereich 6 und darin betriebener geeigneter Datenübertragungsanwendung 7.
-
Die Anbindung an das Backend 20 des Ausrüsters 51 des Fahrzeuges 18 kann in diesem Szenario auf unterschiedliche Weise erfolgen: Erstens lässt sich ein mit der Cloud 28 verbundenes Endgerät 8 drahtlos per Bluetooth 85 oder drahtgebunden per USB 26 mit der Haupteinheit 55 koppeln. Zweitens kann ein seinerseits mit der Cloud 28 verbundener konventioneller Tester 9 drahtgebunden oder drahtlos mit dem Diagnoseanschluss 29 des Zentralgateways 16 kommunizieren. Drittens ist eine drahtlose Anbindung an die Cloud 28 über LTE 2 oder Fahrzeug-Infrastruktur-Kommunikation 3 der Datenübertragungseinheit 45 des Fahrzeuges 18 möglich.
-
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 102007050994 A1 [0003]
-
Zitierte Nicht-Patentliteratur
-
