-
TECHNISCHES GEBIET
-
Die vorliegende Erfindung betrifft im Allgemeinen ein Authentifizierungssystem für Fahrzeugbefehle. Insbesondere betrifft die vorliegende Offenbarung ein Fahrzeugsystem zum Anfordern und Empfangen eines signierten Befehls, der durch ein Cloudsystem autorisiert ist.
-
ALLGEMEINER STAND DER TECHNIK
-
Viele Fahrzeuge sind mit Fernsteuerungsmerkmalen bereitgestellt, die es Fahrzeugen erlauben, Befehle zu empfangen und verschiedene Funktionen, wie etwa einen ferngesteuerten Start oder eine ferngesteuerte Softwareaktualisierung, durchzuführen. Die Fernsteuerungsmerkmale können jedoch für Befehle von einer nicht autorisierten Partei anfällig sein. Ein nicht autorisierter Benutzer könnte einen nicht autorisierten ferngesteuerten Startbefehl derart in das Fahrzeugnetzwerk stellen, dass ein Fahrzeug den Befehl ohne Bezug auf seine Authentizität empfangen und ausführen würde.
-
KURZDARSTELLUNG
-
In einer oder mehreren veranschaulichten Ausführungsformen der vorliegenden Offenbarung beinhaltet ein Fahrzeug eine Steuerung, die dazu programmiert ist, als Reaktion auf das Empfangen eines Befehls von einer Nichtkunden-Partei, eine Autorisierungsanforderung auf Grundlage des Befehls und eines vordefinierten Fahrzeugparameters an einen Server zu senden; und als Reaktion auf das Empfangen eines signierten Befehls von dem Server, den signierten Befehl auszuführen.
-
In einer oder mehreren veranschaulichten Ausführungsformen der vorliegenden Offenbarung beinhaltet ein Verfahren das Erkennen eines von einem Nichtkunden ausgelösten Befehls, der durch die Steuerung innerhalb des Fahrzeugs als Reaktion darauf induziert wird, dass eine Vorbedingung erfüllt ist; das Erzeugen einer Autorisierungs- und Authentifizierungsanforderung auf Grundlage des von einem Nichtkunden ausgelösten Befehls, das Senden der Autorisierungs- und Authentifizierungsanforderung an einen Server, das Empfangen eines signierten Befehls, der den von einem Nichtkunden ausgelösten Befehl autorisiert und authentifiziert; und das Ausführen des signierten Befehls.
-
In einer oder mehreren veranschaulichten Ausführungsformen der vorliegenden Erfindung beinhaltet ein Fahrzeugsystem eine Steuerung, die zu Folgendem programmiert ist: als Reaktion auf das drahtlose Empfangen einer Datendatei von einer Nichtkunden-Partei, Senden einer Autorisierungs- und Authentifizierungsanforderung auf Grundlage der Datendatei an einen Server, der von der Nichtkunden-Partei unabhängig ist, und als Reaktion auf das Empfangen eines signierten Befehls von dem Server, Weiterleiten der Datendatei an eine ECU.
-
Figurenliste
-
Für ein besseres Verständnis der Erfindung und um zu zeigen, wie diese durchgeführt werden kann, werden nun Ausführungsformen davon ausschließlich als nicht einschränkende Beispiele beschrieben, wobei auf die beigefügten Zeichnungen Bezug genommen wird, in denen gilt:
- 1 veranschaulicht eine beispielhafte Blockstruktur eines Fahrzeugsystems einer Ausführungsform der vorliegenden Offenbarung;
- 2 veranschaulicht ein beispielhaftes Blockdiagramm eines Autorisierungs- und Authentifizierungssystems für Fahrzeugbefehle einer Ausführungsform der vorliegenden Offenbarung;
- 3 veranschaulicht ein beispielhaftes Ablaufdiagramm des Autorisierungs- und Authentifizierungsprozesses für Fahrzeugbefehle einer Ausführungsform der vorliegenden Offenbarung; und
- 4 veranschaulicht ein beispielhaftes Datenflussdiagramm zwischen einem Fahrzeug und einer Cloud einer Ausführungsform der vorliegenden Offenbarung.
-
DETAILLIERTE BESCHREIBUNG
-
Ausführliche Ausführungsformen der vorliegenden Erfindung werden hier nach Bedarf offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen für die Erfindung, die in verschiedenen und alternativen Formen ausgeführt sein kann, lediglich beispielhaft sind. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Demnach sind hier offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend zu interpretieren, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielfältige Verwendung der vorliegenden Erfindung zu lehren.
-
Die vorliegende Offenbarung stellt im Allgemeinen eine Vielzahl von Schaltungen oder anderen elektrischen Vorrichtungen bereit. Alle Bezugnahmen auf die Schaltungen und anderen elektrischen Vorrichtungen und die Funktionalität, die jeweils durch diese bereitgestellt wird, sollen nicht darauf beschränkt sein, dass sie lediglich das hierin Veranschaulichte und Beschriebene umschließen. Wenngleich den verschiedenen Schaltungen oder anderen elektrischen Vorrichtungen bestimmte Kennzeichnungen zugewiesen sein können, können derartige Schaltungen und andere elektrische Vorrichtungen auf Grundlage der konkreten Art der elektrischen Umsetzung, die gewünscht ist, auf beliebige Weise miteinander kombiniert und/oder voneinander getrennt sein. Es liegt auf der Hand, dass alle hierin offenbarten Schaltungen oder anderen elektrischen Vorrichtungen eine beliebige Anzahl von Mikroprozessoren, integrierten Schaltungen, Speichervorrichtungen (z. B. FLASH, Direktzugriffsspeicher (random access memory - RAM), Festwertspeicher (read only memory - ROM), elektrisch programmierbaren Festwertspeicher (electrically programmable read only memory - EPROM), elektrisch löschbaren programmierbaren Festwertspeicher (electrically erasable programmable read only memory - EEPROM) oder andere geeignete Varianten davon) und Software beinhalten können, die miteinander zusammenwirken, um den/die hierin offenbarten Vorgang/Vorgänge durchzuführen. Zusätzlich kann eine beliebige oder können mehrere beliebige der elektrischen Vorrichtungen dazu konfiguriert sein, ein Computerprogramm auszuführen, das in einem nichttransitorischen computerlesbaren Medium umgesetzt ist, das dazu programmiert ist, eine beliebige Anzahl der offenbarten Funktionen durchzuführen.
-
Die vorliegende Offenbarung sieht unter anderem ein Autorisierungssystem für ferngesteuerte Fahrzeugbefehle vor. Ein von einem Kunden ausgelöster Befehl, kann einen Befehl beinhalten, der durch einen Besitzer oder einen anderen autorisierten Benutzer des Fahrzeugs empfangen wird. Solche Befehle werden typischerweise von dem Kunden zur Ausführung durch das Fahrzeug gesendet. Befehle von Kunden werden typischerweise von einer authentifizierten Vorrichtung gesendet, was eine zusätzliche Verifizierung unnötig macht. Im Gegensatz zu solchen Befehlen sieht die vorliegende Offenbarung ein Fahrzeugsystem zum Autorisieren und Authentifizieren eines von einem Nichtkunden ausgelösten Befehls über eine Cloud vor, bevor der Befehl in dem Fahrzeug ausgeführt wird. Ein von einem Nichtkunden ausgelöster Befehl kann zum Beispiel einen Befehl beinhalten, der von einem Fahrzeughersteller oder einem Händler empfangen wird.
-
Unter Bezugnahme auf 1 ist eine beispielhafte Blockstruktur eines Autorisierungs- und Authentifizierungssystems 100 für Fahrzeugbefehle einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Bei dem Fahrzeug 102 kann es sich um verschiedene Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländewagen (sport utility vehicle - SUV), Trucks, Wohnmobilen (recreational vehicle - RV), Pendelbussen, Booten, Flugzeugen oder anderen mobilen Maschinen zum Befördern von Personen oder Gütern handeln. In vielen Fällen kann das Fahrzeug 102 durch einen Elektromotor mit Leistung versorgt werden. Als eine weitere Möglichkeit kann das Fahrzeug 102 ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch eine Brennkraftmaschine als auch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Serienhybrid-Elektrofahrzeug (series hybrid electric vehicle - SHEV), ein Parallelhybrid-Elektrofahrzeug (parallel hybrid electrical vehicle - PHEV) oder ein Parallel-/Serienhybrid-Elektrofahrzeug (parallel/series hybrid electric vehicle - PSHEV), ein Boot, ein Flugzeug oder eine andere mobile Maschine zum Befördern von Personen oder Gütern. Als ein Beispiel kann das Fahrzeug 102 das SYNC-System beinhalten, das durch The Ford Motor Company in Dearborn, Michigan, hergestellt wird.
-
Wie in 1 veranschaulicht, kann eine Rechenplattform 104 des Fahrzeugs 102 einen oder mehrere Prozessoren 112 beinhalten, die dazu konfiguriert sind, Anweisungen, Befehle und andere Routinen durchzuführen, um die hierin beschriebenen Prozesse zu unterstützen. Beispielsweise kann die Rechenplattform 104 dazu konfiguriert sein, Anweisungen von Fahrzeuganwendungen 108 auszuführen, um Merkmale wie etwa Navigation, Verarbeitung von ferngesteuerten Befehlen, Autorisierung und Authentifizierung bereitzustellen. Derartige Anweisungen und andere Daten können in nichtflüchtiger Weise unter Verwendung vielfältiger Arten computerlesbarer Speichermedien 106 aufbewahrt werden. Das computerlesbare Medium 106 (auch als prozessorlesbares Medium oder Speicher bezeichnet) beinhaltet ein beliebiges nichttransitorisches Medium (z. B. physisches Medium), das an der Bereitstellung von Anweisungen oder anderen Daten beteiligt ist, die durch den Prozessor 112 der Rechenplattform 104 gelesen werden können. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder ausgelegt werden, die unter Verwendung vielfältiger Programmiersprachen und/oder -techniken, einschließlich jedoch nicht beschränkt auf und entweder allein oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl und PL/SQL, erstellt wurden.
-
Die Rechenplattform 104 kann mit verschiedenen Merkmalen bereitgestellt sein, die es den Fahrzeuginsassen/-benutzern ermöglichen, über eine Schnittstelle mit der Rechenplattform 104 zu interagieren. Zum Beispiel kann die Rechenplattform 104 Eingaben von Steuerungen 126 einer Mensch-Maschine-Schnittstelle (human-machine interface - HMI) empfangen, die dazu konfiguriert sind, eine Interaktion zwischen Insasse und Fahrzeug 102 bereitzustellen. Zum Beispiel kann die Rechenplattform 104 mit einer oder mehreren Tasten (nicht gezeigt) oder anderen HMI-Steuerungen eine Schnittstelle bilden, die dazu konfiguriert sind, Funktionen auf der Rechenplattform 104 aufzurufen (z. B. Audiotasten am Lenkrad, eine Sprechtaste, Steuerungen am Armaturenbrett usw.).
-
Die Rechenplattform 104 kann zudem eine oder mehrere Anzeigen 116 antreiben, die dazu konfiguriert sind, über eine Videosteuerung 114 visuelle Ausgaben für Fahrzeuginsassen bereitzustellen oder anderweitig mit diesen kommunizieren. In einigen Fällen kann es sich bei der Anzeige 116 um einen Touchscreen handeln, der außerdem dazu konfiguriert ist, berührungsbasierte Eingaben des Benutzers über die Videosteuerung 114 zu empfangen, während die Anzeige 116 in anderen Fällen lediglich eine Anzeige ohne die Möglichkeit zur berührungsbasierten Eingabe sein kann. Die Rechenplattform 104 kann zudem einen oder mehrere Lautsprecher 122 antreiben, die dazu konfiguriert sind, über eine Audiosteuerung 120 Audioausgaben für Fahrzeuginsassen bereitzustellen oder anderweitig mit diesen kommunizieren. Der Rechenplattform 104 können auch Standortmerkmale durch eine Standortsteuerung wie etwa einer Steuerung 124 für das globale Positionsbestimmungssystem (GPS), die dazu konfiguriert ist, mit mehreren Satelliten zu kommunizieren, um einen Standort des Fahrzeugs 102 zu berechnen, bereitgestellt werden. Es ist anzumerken, dass die Standortsteuerung dazu konfiguriert sein kann, andere Funknavigationssysteme, die in verschiedenen Teilen der Welt verwendet werden, einschließlich Navigationssatellitensystemen von GALILEO, GLONASS und Beidou zu unterstützen.
-
Die Rechenplattform 104 kann ferner mit einem drahtlosen Sendeempfänger 132 bereitgestellt sein, der mit einer WLAN-Steuerung 124, einer Steuerung 128 für Nahfeldkommunikation (near-field communication - NFC), einer Bluetooth-Steuerung und anderen Steuerungen in Kommunikation steht, wie etwa einem Zigbee-Sendeempfänger, einem IrDA-Sendeempfänger (nicht gezeigt), der dazu konfiguriert ist, mit kompatiblen drahtlosen Sendeempfängern verschiedener Vorrichtungen zu kommunizieren.
-
Die Rechenplattform 104 kann außerdem dazu konfiguriert sein, über ein oder mehrere fahrzeuginterne Netzwerke 170 mit verschiedenen elektronischen Steuereinheiten (electronic control units - ECU) 142 zu kommunizieren. Als einige Beispiele kann das fahrzeuginterne Netzwerk 140 eines oder mehrere von einem Controller Area Network (CAN), einem Ethernet-Netzwerk und einer mediengebundenen Systemübertragung (media oriented system transport - MOST) beinhalten, ist aber nicht darauf beschränkt.
-
Die Rechenplattform 104 kann in Kommunikation mit mehreren ECU 142 stehen, die dazu konfiguriert sind, verschiedene Funktionen des Fahrzeugs 102 zu steuern und zu betreiben. Als wenige nicht einschränkende Beispiele können die ECU 142 eine Telematiksteuereinheit (telematics control unit - TCU) 144, die dazu konfiguriert ist, sich über ein Modem 146 durch eine drahtlose Verbindung 166 drahtlos mit einem Drahtlosnetzwerk 160 zu verbinden; ein Antriebsstrangsteuermodul (powertrain control module - PCM), das dazu konfiguriert ist, einen Antriebsstrang einschließlich des Motors/Elektromotors und des Getriebes des Fahrzeugs 102 zu steuern; und ein elektrisches Batteriesteuermodul (battery electric control module - BCEM) 150, das dazu konfiguriert ist, den Betrieb der Fahrzeugbatterien zu steuern, beinhalten. Das Fahrzeug 102 kann zum Beispiel eine herkömmliche Blei Säurebatterie, die dazu konfiguriert ist, verschiedenen elektrischen Komponenten Leistung bereitzustellen, und eine Hochleistungs-Traktionsbatterie für den Fall beinhalten, dass das Fahrzeug 102 ein elektrisch betriebenes Fahrzeug ist, das durch das BCEM 150 sowohl überwacht als auch gesteuert wird.
-
Die TCU 144 kann zur Kommunikation mit verschiedenen Parteien durch die drahtlose Verbindung 166 über das Drahtlosnetzwerk 160 konfiguriert sein. Die TCU 144 kann zum Beispiel dazu konfiguriert sein, über das Drahtlosnetzwerk 160 mit einem Nichtkunden 164 und einer Backend-Cloud 162 zu kommunizieren. Der Nichtkunde 164 kann ferner durch die drahtlose Verbindung 172 über den drahtlosen Sendeempfänger 132 direkt mit der Rechenplattform 104 kommunizieren. Der Nichtkunde 164 kann ein Fahrzeughersteller oder ein Fahrzeughändler sein, der mit dem Fahrzeug 102 assoziiert ist. Der Nichtkunde 164 kann dazu autorisiert sein, mit dem Fahrzeug 102 zu kommunizieren, um verschiedene Befehle und Datendateien (von einem Nichtkunden ausgelöste(r) Daten/Befehl) zu übertragen, um Funktionen wie etwa Fahrzeugsoftwareaktualisierungen, ferngesteuerte Türverriegelungs-/Türentriegelungsbefehle, ferngesteuerte Startbefehle und dergleichen durchzuführen. Aus Sicherheitsgründen können die von dem Nichtkunden 164 empfangenen Daten verschlüsselt sein und die Rechenplattform 104 kann dazu konfiguriert sein, die Daten zu entschlüsseln. Zusätzlich oder alternativ kann das Fahrzeug 102 mit einer Verschlüsselungssteuerung (nicht gezeigt) bereitgestellt sein, die in Kommunikation mit der Rechenplattform 104 steht und dazu konfiguriert ist, die Verschlüsselung und Entschlüsselung von Daten durchzuführen, die an verschiedene Parteien gesendet oder von diesen empfangen werden.
-
Die Rechenplattform 104 kann ferner dazu konfiguriert sein, Autorisierung und Authentifizierung über die Backend-Cloud 162 durchzuführen, bevor es dem bzw. den von einem Nichtkunden ausgelösten Befehl und Daten erlaubt ist, ausgeführt oder an eine Ziel-ECU weitergeleitet zu werden. Die Rechenplattform 104 kann zum Beispiel als Reaktion auf das Empfangen von Daten von dem Nichtkunden 164 anfordern, die Daten über die Backend-Cloud 162 unter Verwendung der TCU 144 durch das Drahtlosnetzwerk 160 zu authentifizieren. Die Backend-Cloud 162 kann einen oder mehrere Computer und Server beinhalten, die durch einen Fahrzeughersteller oder eine autorisierte Partei betrieben werden und dazu konfiguriert sind, als Reaktion auf das Empfangen von Fahrzeuganforderungen Autorisierung und Authentifizierung durchzuführen. Als Reaktion auf eine erfolgreiche Autorisierung und Authentifizierung, kann die Backend-Cloud 162 einen signierten Befehl zurück an das Fahrzeug 102 senden. Das Fahrzeug 102 kann dazu konfiguriert sein, den signierten Befehl, jedoch keine Befehle, die nicht signiert oder fehlerhaft signiert sind, auszuführen.
-
Unter Bezugnahme auf 2 ist ein beispielhaftes Blockdiagramm des Autorisierungs- und Authentifizierungssystems 200 für Fahrzeugbefehle veranschaulicht. Als allgemeines Beispiel für den Betrieb des Autorisierungs- und Authentifizierungssystems 200 für Fahrzeugbefehle kann die Rechenplattform 104 des Fahrzeugs 102 durch drahtlose Übertragung von einem Nichtkunden ausgelöste Daten 202 von dem Nichtkunden 164 empfangen. Bei den von einem Nichtkunden ausgelösten Daten kann es sich zum Beispiel um eine verschlüsselte Softwareaktualisierung einschließlich Befehlen und Dateien für die Ziel-ECU 142 durch den Fahrzeug- oder Bauteilhersteller, der mit dem Fahrzeug 102 oder der Ziel-ECU 142 assoziiert ist, handeln. Aufgrund des drahtlosen Charakters der Fahrzeugkonfiguration ist es jedoch auch möglich, dass von einem Nichtkunden ausgelöste Daten von einer nicht autorisierten Partei, wie etwa einem Hacker, gesendet werden. Die von einem Nichtkunden ausgelösten Daten können nicht autorisierte Befehle und kompromittierte Dateien enthalten, die Malware und Viren beinhalten, die der Ziel-ECU 142 wie auch anderen Komponenten des Fahrzeugs 102 möglicherweise Schäden zufügen können. Alternativ können die von einem Nichtkunden ausgelösten Daten von einem nicht autorisierten Shop gesendet werden und eine nicht genehmigte Softwareaktualisierung enthalten, die in ihrer Verwendung möglicherweise gefährlich ist. Daher sind Authentifizierung und Genehmigung erforderlich. Um die Authentizität der von dem Nichtkunden 164 empfangenen Daten zu verifizieren, kann die Rechenplattform 104 eine Autorisierungs- und Authentifizierungsanforderung 204 an die Backend-Cloud 162 senden und anfragen, einen signierten Fahrzeugbefehl auszugeben. Aus Sicherheitsgründen kann die Rechenplattform 104 dazu konfiguriert sein, keine von einem Nichtkunden ausgelöste Daten auszuführen oder weiterzuleiten, sofern nicht der signierte Befehl von der Backend-Cloud 162 empfangen wird, der die Authentizität der von dem Nichtkunden ausgelösten Daten verifiziert.
-
Als weiteres alternatives Beispiel kann der von einem Nichtkunden ausgelöste Befehl durch eine ECU 142 innerhalb des Fahrzeugs 102 durch einen Triggermechanismus wie etwa einen Zeitgeber und/oder eine andere in der Software eingestellte Vorbedingung selbstinduziert sein. Das Fahrzeug 102 kann zum Beispiel als Reaktion auf das Erkennen, das eine neue Softwaredatei vollständig heruntergeladen wurde, versuchen, die Ziel-ECU 142 zu programmieren und muss das fahrzeuginterne Netzwerk 140 durch Triggern eines Befehls hochfahren. Dieser durch das Fahrzeug selbst getriggerte Befehl müsste autorisiert und authentifiziert werden, bevor er ausgeführt wird. Daher kann die Rechenplattform 104 als Reaktion auf den Trigger den Trigger zur Autorisierung und Authentifizierung an die Cloud senden, bevor das BCEM 150 den Befehl zum Hochfahren ausführt.
-
Im Allgemeinen kann die Backend-Cloud 162 eine Autorisierung 206 und eine Authentifizierung 208 als Reaktion auf das Empfangen der Anforderung 204 von dem Fahrzeug 102 durchführen. Bei dem Autorisierungsvorgang 206 kann die Backend-Cloud 162 verifizieren, ob das Fahrzeug 102 dazu autorisiert ist, den angeforderten Vorgang (z. B. die ECU-Software zu aktualisieren) unter Verwendung verschiedener Parameter einschließlich Fahrzeugbetriebszustand, Batterieniveau, Fahrzeugstandort, usw. durchzuführen. Der Backend-Server 164 kann zum Beispiel ein Batterieladeniveau von dem BCEM 150 verwenden, um zu bestimmen, ob das Fahrzeug 102 genug Batterieleistung aufweist, um den angeforderten Vorgang durchzuführen. Als Reaktion auf eine erfolgreiche Autorisierung 206, kann die Backend-Cloud ferner überprüfen, ob die von einem Nichtkunden ausgelösten Daten ohne Modifizierung authentisch sind und von einer autorisierten Nichtkunden-Partei stammen. Es können verschiedene Technologien verwendet werden, um die Authentifizierung durchzuführen, und einige nicht einschränkende Beispiele dieser Technologien beinhalten die Verwendung von digitalen Signaturen, Hashing, Verschlüsselung und Geostandortverifizierung. Als Reaktion auf eine erfolgreiche Authentifizierung kann die Backend-Cloud 162 einen signierten Befehl erzeugen und den signierten Befehl 210 zur Ausführung zurück an das Fahrzeug 102 senden.
-
Als Reaktion auf das Empfangen des signierten Befehls von der Backend-Cloud kann die Rechenplattform 104 den signierten Befehl zur Ausführung der Softwareaktualisierung an die Ziel-ECU 142 weiterleiten 212. Als ein Beispiel kann die Kommunikation zwischen der Rechenplattform 104 und der Ziel-ECU 142 über die ISO 15762(CAN-Transportschicht)-Technologie umgesetzt werden, die es bestehenden ECU 142 des Fahrzeugs 102 erlaubt, die Cloud-Autorisierungstechnologie mit minimalen Softwareänderungen zu übernehmen. Es ist anzumerken, dass die Rechenplattform 104 dazu konfiguriert sein kann, keine(n) Daten/Befehl direkt auszuführen oder weiterzuleiten, die/der von einer Nichtkunden-Partei 164 empfangen werden/wird, ohne einen signierten Befehl von der Backend-Cloud 162 anzufordern und zu empfangen.
-
Unter Bezugnahme auf 3 ist ein beispielhaftes Ablaufdiagramm für einen in dem Fahrzeug umgesetzten Prozess 200 veranschaulicht. Obwohl der Prozess 200 in der nachfolgenden Beschreibung in der Rechenplattform 104 umgesetzt ist, ist anzumerken, dass der gleiche oder im Wesentlichen gleiche Prozess vollständig oder teilweise in anderen Komponenten des Fahrzeugs 102, das unter Bezugnahme auf die 1 und 2 gezeigt ist, umgesetzt werden kann. Bei Vorgang 302 empfängt die Rechenplattform 104 Daten/einen Befehl, die/der durch den Nichtkunden 164 ausgelöst werden/wird. Die von dem Nichtkunden ausgelösten Daten können zu Beispiel eine Softwareaktualisierung für eine Ziel-ECU 142 beinhalten, die von dem Autohersteller oder einem -händler gesendet wird. Zusätzlich oder alternativ können die von einem Nichtkunden ausgelösten Daten verschiedene Befehle beinhalten, die das Fahrzeug 102 anweisen, verschiedene Vorgänge wie etwa Überprüfen des Fahrzeugzustands, Einschalten von Leistungszufuhr für bestimmte Fahrzeugkomponenten, Starten des Fahrzeugs, Melden des Fahrzeugstandorts usw. beinhalten. Die Rechenplattform 104 kann die von einem Nichtkunden ausgelösten Daten in dem Speicher 106 als einen Teil der Fahrzeugdaten 110 speichern. Bei Vorgang 304 sendet sie Rechenplattform 104 eine Autorisierungs- und Authentifizierungsanforderung an die Backend-Cloud 162. Die Autorisierungs- und Authentifizierungsanforderung kann Informationen über den von einem Nichtkunden ausgelösten Befehl beinhalten, wie etwa Befehls-ID und -typ, ebenso wie Informationen über den Nichtkunden 164, wie etwa die ID, die IP-Adresse, den Standort des Nichtkunden usw. Die Autorisierungs- und Authentifizierungsanforderung kann für Analysezwecke ferner einen oder mehrere vordefinierte Fahrzeugparameter an die Backend-Cloud 162 senden. Einige Beispiele der vordefinierten Fahrzeugparameter können die Fahrzeugidentifikationsnummer (VIN), den Batterieladezustand, den Fahrzeugstandort und den aktuellen Fahrzeugbetriebsstatus beinhalten.
-
Abhängig von dem spezifischen von einem Nichtkunden ausgelösten Befehl kann die Backend-Cloud 162 zur Autorisierung und Authentifizierung weitere Informationen über das Fahrzeug 102 anfordern. Bei Vorgang 306 zum Beispiel empfängt die Rechenplattform 104 eine Anforderung für weitere Fahrzeugparameter von der Backend-Cloud 162. Bei dem Beispiel der ECU-Softwareaktualisierung kann die Backend-Cloud Parameter über die aktuelle Softwareversion oder das Ereignisprotokoll der Ziel-ECU 142 anfordern, um zu bestimmen, ob der von einem Nichtkunden ausgelöste Befehl autorisiert und authentifiziert werden soll. Als Reaktion sammelt die Rechenplattform 104 bei Vorgang 308 die angeforderten Parameter von verschiedenen Komponenten des Fahrzeugs 102 und versendet die angeforderten Parameter an die Backend-Cloud 162.
-
Wenn die Backend-Cloud 162 die Autorisierungs- und Authentifizierungsanfrage aus irgendeinem Grund ablehnt und die Rechenplattform 104 bei Vorgang 310 eine Ablehnung empfängt, geht der Prozess zu Vorgang 312 über und die Rechenplattform 104 löscht die/den von einem Nichtkunden ausgelösten Daten/Befehl aus dem Speicher 106. Zusätzlich kann die Rechenplattform 104 die mögliche Sicherheitsverletzung über das Drahtlosnetzwerk 160 an die Behörden melden. Wenn die Backend-Cloud 162 eine Anforderung genehmigt, kann ein signierter Befehl ausgegeben und an die Rechenplattform 104 gesendet werden. Bei Vorgang 314 empfängt die Rechenplattform 104 einen signierten Befehl von der Backend-Cloud 162. Der signierte Befehl kann mit einer Bedingung wie etwa einer Zeitrahmenautorisierung einhergehen, um den signierten Befehl innerhalb eines spezifischen Zeitraums (z. B. 24 Stunden) auszuführen. Beispielsweise kann das Fahrzeug 102 durch einen Benutzer verwendet werden, wenn die Rechenplattform 104 den signierten Befehl von der Backend-Cloud 162 empfängt. Vorgänge wie etwa das Aktualisieren einer ECU-Software können nur durchgeführt werden, während 102 das Fahrzeug nicht verwendet wird und können somit nicht unmittelbar nach dem Empfangen des signierten Befehls durchgeführt werden.
-
Bei Vorgang 316 bestimmt die Rechenplattform 104, ob das Fahrzeug 102 verwendet wird. Dies kann durch verschiedene Mechanismen erfolgen. Die Rechenplattform 104 kann zum Beispiel mit dem PCM 148 und/oder dem BCEM 150 kommunizieren, um zu verifizieren, ob das Fahrzeug 102 verwendet wird. Wenn das Fahrzeug 102 verwendet wird, wartet die Rechenplattform 104 bis das Fahrzeug 102 nicht weiter verwendet wird und der Prozess geht zu Vorgang 318 über. Ferner untersucht die Rechenplattform 104, ob der Zeitpunkt sich innerhalb des Zeitrahmens befindet, der durch die Backend-Cloud 162 autorisiert ist. Die Rechenplattform 104 kann dazu konfiguriert sein, ein Fortfahren zu erlauben, sofern sie das Ausführen des signierten Befehls innerhalb des Zeitrahmens startet. Alternativ kann die Rechenplattform 104 ferner, falls verfügbar, die vorhergesagte Laufzeit (z. B. ist vorhergesagt, dass eine ECU-Aktualisierung bis zu 30 Minuten dauert) berücksichtigen, sodass der Ausführungsprozess des Befehls innerhalb des genehmigten Zeitrahmens beendet wird. Wenn die autorisierte Zeitrahmenbedingung nicht erfüllt werden kann, kehrt der Prozess zu Vorgang 304 zurück und die Rechenplattform 104 sendet erneut die Autorisierungs- und Authentifizierungsanforderung an die Backend-Cloud 162. Wenn sich der Zeitpunkt noch innerhalb des autorisierten Zeitrahmens befindet, geht der Prozess zu Vorgang 320 über und die Rechenplattform 104 führt den von der Backend-Cloud empfangenen signierten Befehl aus. Sobald eine ECU 142 beteiligt ist, leitet die Rechenplattform 104 den signierten Befehl zur Ausführung an die Ziel-ECU 142 weiter.
-
Da das Fahrzeug 102 während eines solchen Prozesses wie etwa einer ECU-Aktualisierung, der einen längeren Zeitraum beanspruchen kann, was Unannehmlichkeiten für den Benutzer hervorruft, nicht verwendet werden kann, kann die Rechenplattform ferner dazu konfiguriert sein, einen Zeitpunkt zu reservieren, um den Vorgang des befohlenen Prozesses dann durchzuführen, wenn vorhergesagt ist, dass das Fahrzeug 102 für mindestens den längeren Zeitraum nicht verwendet wird. Die Rechenplattform kann zum Beispiel Standortdaten von der GPS-Steuerung 118 verwenden, um ein Verwendungsmuster des Benutzers zu erzeugen und den Vorgang nur als Reaktion auf das Bestimmen durchführen, dass das Fahrzeug in der Nähe des Zuhauses des Benutzers geparkt ist.
-
Unter Bezugnahme auf 4 ist ein beispielhaftes Datenflussdiagramm 400 zwischen dem Fahrzeug 102 und der Backend-Cloud 162 veranschaulicht. Unter weiterer Bezugnahme auf die 1-3 empfängt das Fahrzeug 102 bei Vorgang 402 ein von einem Nichtkunden ausgelösten Befehl. Als Reaktion sendet die Rechenplattform 104 bei Vorgang 404 zusammen mit vordefinierten Fahrzeugparametern eine Autorisierungs- und Authentifizierungsanforderung an die Backend-Cloud 162, um einen signierten Befehl zu erlangen. Als Reaktion auf das Empfangen der Autorisierungs- und Authentifizierungsanforderung und verschiedener Parameter bewertet die Backend-Cloud 162 die Anforderung unter Verwendung der verschiedenen Parameter. Wenn die Backend-Cloud 162 zum Beispiel bestimmt, dass der von einem Nichtkunden ausgelöste Befehl für eine ECU-Softwareaktualisierung bis zur Vollendung bis zu 30 Minuten dauert, die aktuelle Fahrzeugbatterieladung aber niedrig und nur ausreichend ist, um dem Aktualisierungsprozess Leistung für 20 Minuten zuzuführen, kann die Backend-Cloud 162 es ablehnen, den signierten Befehl zu autorisieren. Alternativ autorisiert die Backend-Cloud 162 die Anforderung bei Vorgang 406 mit Bedingungen. Die Bedingungen können einen Zeitrahmen für die Rechenplattform zum Durchführen des Befehls beinhalten. Zusätzlich kann bei dem vorstehenden Beispiel mit niedriger Batterie die Backend-Cloud eine bedingte Genehmigung ausgeben, sodass der signierte Befehl nur ausgeführt werden kann, wenn die Batterieladung über einem bestimmten Niveau (z. B. 50 %) liegt. Die Genehmigungsbedingungen können ferner eine Geostandort-Eingrenzung beinhalten, innerhalb welcher der signierte Befehl ausgeführt werden kann. Beispielsweise können Emissionsvorschriften und -gesetze von Staat zu Staat unterschiedlich sein. Ein von einem Nichtkunden ausgelöster Befehl, der die ECU aktualisiert und die Fahrzeugemissionen verändert, kann in bestimmten Staaten erlaubt sein und in den anderen nicht.
-
Bei Vorgang 408 authentifiziert die Backend-Cloud 162 den von einem Nichtkunden ausgelösten Befehl. Die Backend-Cloud 162 kann zum Beispiel unter Verwendung der IP-Adresse und/oder digitalen Signaturverifizierungen verifizieren, dass der von einem Nichtkunden ausgelöste Befehl von einer autorisierten Partei stammt. Die Backend-Cloud 162 kann ferner verifizieren, dass der von einem Nichtkunden ausgelöste Befehl selbst authentisch ist und nicht unter Verwendung von digitaler Signaturtechnologie kompromittiert wurde. Als Reaktion auf eine erfolgreiche Authentifizierung erzeugt die Backend-Cloud 162 einen signierten Befehl und sendet bei Vorgang 410 den signierten Befehl zusammen mit Autorisierungsbedingungen zurück an die Rechenplattform 104. Der signierte Befehl kann zum Beispiel unter Verwendung der digitalen Signaturtechnologien des Rivest-Shamir-Adleman-Algorithmus (RSA) oder des Elliptic-Curve-Digital-Signature-Algorithmus (ECDSA) erzeugt werden. Als Reaktion auf das Empfangen des signierten Befehls führt die Rechenplattform 104 den signierten Befehl den Autorisierungsbedingungen folgend, die dem signierten Befehl beigefügt sind, aus.
-
Wenngleich vorstehend Ausführungsbeispiele beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und nicht einschränkende Ausdrücke und versteht es sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Wesen und Schutzumfang der Offenbarung abzuweichen. Zusätzlich können die Merkmale verschiedener umsetzender Ausführungsformen miteinander kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
-
Gemäß einer Ausführungsform der Erfindung ist die Steuerung ferner dazu programmiert, als Reaktion auf das Vorhersagen, dass das Fahrzeug für mindestens eine vorhergesagte Ausführungszeit für den signierten Befehl nicht verwendet wird, den signierten Befehl auszuführen.
-
Gemäß einer Ausführungsform ist die Steuerung ferner dazu programmiert, ein Verwendungsmuster des Fahrzeugs zu erzeugen.
-
Gemäß einer Ausführungsform, ist die vorstehende Erfindung ferner durch Folgendes gekennzeichnet: Empfangen einer Zeitbedingung, die einen Zeitrahmen angibt, innerhalb welchen der signierte Befehl autorisiert ist, ausgeführt zu werden; und erneutes Senden der Autorisierungs- und Authentifizierungsanforderung als Reaktion darauf, dass das Ausführen des signierten Befehls innerhalb des Zeitrahmens fehlgeschlagen ist.
-
Gemäß einer Ausführungsform ist die Steuerung ferner dazu programmiert, als Reaktion auf das Empfangen einer Ablehnung von dem Server, die angibt, dass die Datendatei nicht authentisch ist, die Datendatei zu löschen und ein Fehlerereignis an einen Server zu melden.