DE102019124914A1 - Cloudautorisierte fahrzeugsteuerung - Google Patents

Cloudautorisierte fahrzeugsteuerung Download PDF

Info

Publication number
DE102019124914A1
DE102019124914A1 DE102019124914.7A DE102019124914A DE102019124914A1 DE 102019124914 A1 DE102019124914 A1 DE 102019124914A1 DE 102019124914 A DE102019124914 A DE 102019124914A DE 102019124914 A1 DE102019124914 A1 DE 102019124914A1
Authority
DE
Germany
Prior art keywords
vehicle
command
response
server
signed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019124914.7A
Other languages
English (en)
Inventor
Karl Nathan Clark
Jason Michael Miller
Xin Ye
James Michael WEINFURTHER
Vijayababu Jayaraman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102019124914A1 publication Critical patent/DE102019124914A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3249—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using RSA or related signature schemes, e.g. Rabin scheme
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3252—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
    • G07C2009/00507—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks keyless data carrier having more than one function
    • G07C2009/00547—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks keyless data carrier having more than one function starting ignition
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00309—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks
    • G07C2009/00555—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated with bidirectional data transmission between data carrier and locks comprising means to detect or avoid relay attacks
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • G07C9/00571—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys operated by interacting with a central unit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Lock And Its Accessories (AREA)
  • Electric Propulsion And Braking For Vehicles (AREA)

Abstract

Diese Offenbarung stellt eine cloudautorisierte Fahrzeugsteuerung bereit. Ein Fahrzeug beinhaltet 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.

Description

  • 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.

Claims (15)

  1. Fahrzeug, umfassend: eine Steuerung, die zu Folgendem programmiert ist als Reaktion auf das Empfangen eines Befehls von einer Nichtkunden-Partei, Senden einer Autorisierungsanforderung auf Grundlage des Befehls und eines vordefinierten Fahrzeugparameters an einen Server, und als Reaktion auf das Empfangen eines signierten Befehls von dem Server, Ausführen des signierten Befehls.
  2. Fahrzeug nach Anspruch 1, wobei die Steuerung ferner dazu programmiert ist, die Ausführung des signierten Befehls zu verzögern, bis das Fahrzeug nicht verwendet wird.
  3. Fahrzeug nach Anspruch 1, wobei die Steuerung ferner dazu programmiert ist, den signierten Befehl an eine elektronische Steuereinheit (ECU) des Fahrzeugs weiterzuleiten.
  4. Fahrzeug nach Anspruch 3, wobei eine Kommunikation zwischen der Steuerung und der ECU über die ISO-Norm 15762 umgesetzt wird.
  5. Fahrzeug nach Anspruch 1, wobei die Steuerung ferner dazu programmiert ist, als Reaktion auf das Empfangen einer Anforderung für einen zusätzlichen Fahrzeugparameter von dem Server, den zusätzlichen Fahrzeugparameter zu sammeln und den zusätzlichen Fahrzeugparameter an den Server zu senden.
  6. Fahrzeug nach Anspruch 1, wobei der vordefinierte Fahrzeugparameter mindestens eines des Folgenden beinhaltet: eine Fahrzeugidentifikationsnummer (VIN), einen Fahrzeugstandort, ein Ladeniveau der Fahrzeugbatterie oder eine Fahrzeugsoftwareversion.
  7. Fahrzeug nach Anspruch 1, wobei die Steuerung ferner zu Folgendem programmiert ist: Empfangen einer Bedingung zum Ausführen des signierten Befehls von dem Server, und Ausführen des signierten Befehls als Reaktion auf das Auftreten der Bedingung.
  8. Fahrzeug nach Anspruch 7, wobei die Bedingung für den signierten Befehl mindestens eines des Folgenden beinhaltet: eine Zeitbedingung, einen Batterieladezustand oder eine Geostandortbedingung.
  9. Fahrzeug nach Anspruch 8, wobei die Steuerung ferner dazu programmiert ist, die Ausführung des signierten Befehls innerhalb der Zeitbedingung auszuführen.
  10. Fahrzeug nach Anspruch 1, wobei die Steuerung ferner zu Folgendem programmiert ist: als Reaktion auf das Erkennen, dass das Fahrzeug nicht verwendet wird, Ausführen des signierten Befehls; als Reaktion auf das Vorhersagen, dass das Fahrzeug für mindestens eine vorhergesagte Ausführungszeit für den signierten Befehl nicht verwendet wird, Ausführen des signierten Befehls; und Erzeugen eines Verwendungsmusters des Fahrzeugs.
  11. Verfahren für ein Fahrzeug, umfassend: 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; Erzeugen einer Autorisierungs- und Authentifizierungsanforderung auf Grundlage des von einem Nichtkunden ausgelösten Befehls; Senden der Autorisierungs- und Authentifizierungsanforderung an einen Server; Empfangen eines signierten Befehls, der den von einem Nichtkunden ausgelösten Befehl autorisiert und authentifiziert; und Ausführen des signierten Befehls.
  12. Verfahren nach Anspruch 11, ferner umfassend: Empfangen einer Anforderung für zusätzliche Fahrzeugparameter von dem Server; und Senden der angeforderten zusätzlichen Fahrzeugparameter an den Server.
  13. Verfahren nach Anspruch 11, ferner umfassend: Weiterleiten des signierten Befehls zur Ausführung an eine ECU; 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.
  14. Verfahren nach Anspruch 11, wobei der signierte Befehl unter Verwendung einer der folgenden digitalen Signaturtechnologien erzeugt wird: dem Rivest-Shamir-Adleman-Algorithmus (RSA) oder dem Elliptic-Curve-Digital-Signature-Algorithmus (ECDSA).
  15. Fahrzeugsystem, umfassend: 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, als Reaktion auf das Empfangen eines signierten Befehls von dem Server, Weiterleiten der Datendatei an eine ECU; und als Reaktion auf das Empfangen einer Ablehnung von dem Server, die angibt, dass die Datendatei nicht authentisch ist, Löschen der Datendatei und Melden eines Fehlerereignisses an einen Server.
DE102019124914.7A 2018-09-18 2019-09-16 Cloudautorisierte fahrzeugsteuerung Pending DE102019124914A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/133,875 2018-09-18
US16/133,875 US10834199B2 (en) 2018-09-18 2018-09-18 Cloud authorized vehicle control

Publications (1)

Publication Number Publication Date
DE102019124914A1 true DE102019124914A1 (de) 2020-03-19

Family

ID=69646512

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019124914.7A Pending DE102019124914A1 (de) 2018-09-18 2019-09-16 Cloudautorisierte fahrzeugsteuerung

Country Status (3)

Country Link
US (1) US10834199B2 (de)
CN (1) CN110920560A (de)
DE (1) DE102019124914A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3839723A1 (de) * 2019-12-18 2021-06-23 Volkswagen Aktiengesellschaft Vorrichtungen, verfahren und computerprogramme zur aktualisierung einer oder mehrerer software-komponenten eines fahrzeugs
US11535112B2 (en) * 2020-09-10 2022-12-27 Motional Ad Llc Managing power of electronic devices on a vehicle
US11513488B2 (en) * 2020-09-10 2022-11-29 Motional Ad Llc Controlling power of electronic devices on a vehicle
EP3968603B1 (de) * 2020-09-11 2024-08-21 Volkswagen Ag Steuerung der datenschutzeinstellung einer kommunikation zwischen einem fahrzeug und einer backend-cloud-vorrichtung
CN112597447A (zh) * 2020-12-15 2021-04-02 广州橙行智动汽车科技有限公司 车载服务授权激活方法、装置及车辆
JP7250056B2 (ja) * 2021-03-09 2023-03-31 本田技研工業株式会社 制御システム、移動体及び通信制御方法
CN113179298A (zh) * 2021-04-19 2021-07-27 广州易点智慧出行科技有限公司 车辆的控制方法、车辆系统及计算机可读存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4507884B2 (ja) 2005-01-11 2010-07-21 トヨタ自動車株式会社 遠隔制御システム及び遠隔制御装置を備える車両
US8863256B1 (en) * 2011-01-14 2014-10-14 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
CN104080658B (zh) 2012-01-25 2016-08-24 丰田自动车株式会社 车辆远程操作信息提供装置、车载远程操作信息取得装置及具备这些装置的车辆远程操作系统
US10375047B2 (en) 2013-09-30 2019-08-06 Schneider Electric Industries Sas Cloud-authenticated site resource management devices, apparatuses, methods and systems

Also Published As

Publication number Publication date
CN110920560A (zh) 2020-03-27
US10834199B2 (en) 2020-11-10
US20200092375A1 (en) 2020-03-19

Similar Documents

Publication Publication Date Title
DE102019124914A1 (de) Cloudautorisierte fahrzeugsteuerung
DE102016115669A1 (de) Boardseitige Webserver-Telematiksysteme und Verfahren
DE102018111262A1 (de) Bedienung eines schlüsselanhängers in einem carsharing-system
DE102014114606B4 (de) Programmierung von Fahrzeugmodulen mit Remotevorrichtungen und zugehörige Methoden und Systeme
DE102018104079A1 (de) Sichere end-to-end-fahrzeug-ecu-freischaltung in einer halb-offline-umgebung
DE102013222428B4 (de) Berechtigungsnachweisprüfung und Autorisierungslösung zur Personenfahrzeugvermietung
DE102019107336A1 (de) Automatisches plug-and-pay mit mehrstufiger authentifizierung zum betanken von fahrzeugen
DE102014114607B4 (de) Programmierung von Fahrzeugmodulen mit Remotevorrichtungen und zugehörige Methoden und Systeme
DE102017113295A1 (de) Firewall-fernaktualisierung für bordeigenes webserver-telematiksystem
DE102017128922A1 (de) Authentifizierung von mobilen Vorrichtungen zur Fahrzeugkommunikation
DE102017121962A1 (de) Beziehungsverwaltung für fahrgemeinschaftssysteme
DE102017119373A1 (de) Aktualisierung der servers der netzwerkadresse der mobilvorrichtung
DE102017102388A1 (de) Regeln des fahrzeugzugangs unter verwendung kryptografischer verfahren
DE102016110169A1 (de) Diebstahlverhinderung für autonome Fahrzeuge
DE102015116445A1 (de) Verteilen geheimer Schlüssel zum Verwalten eines Zugriffs auf ECUs
DE102015103020A1 (de) Steuern eines Zugriffs auf eine in einem Fahrzeug gespeicherte persönliche Information unter Verwendung eines kryptografischen Schlüssels
DE102015220489B4 (de) Verfahren zur Autorisierung einer Softwareaktualisierung in einem Kraftfahrzeug
DE102019135012A1 (de) Auf richtlinie und token basierender autorisierungsrahmen für konnektivität
DE102012202721A1 (de) Verfahren und Anwendungen zur Aktivierung von Fahrzeugsystemen
DE102019122259A1 (de) Intelligente fahrzeugverbindung
DE102020112275A1 (de) Identitätszugriffsverwaltung für fahrzeuge
DE102019104354A1 (de) Fahrzeugsicherheit
DE102019114358A1 (de) Vorübergehender und benutzerdefinierter fahrzeugzugriff
DE102016109978A1 (de) Schlüssellose Übergabesteuerung
DE102020103996A1 (de) Fahrzeugdatenschutz

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: LORENZ SEIDLER GOSSEL RECHTSANWAELTE PATENTANW, DE