DE102019135012A1 - Auf richtlinie und token basierender autorisierungsrahmen für konnektivität - Google Patents

Auf richtlinie und token basierender autorisierungsrahmen für konnektivität Download PDF

Info

Publication number
DE102019135012A1
DE102019135012A1 DE102019135012.3A DE102019135012A DE102019135012A1 DE 102019135012 A1 DE102019135012 A1 DE 102019135012A1 DE 102019135012 A DE102019135012 A DE 102019135012A DE 102019135012 A1 DE102019135012 A1 DE 102019135012A1
Authority
DE
Germany
Prior art keywords
token
vehicle
response
content
cloud
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
DE102019135012.3A
Other languages
English (en)
Inventor
Venkata Maruthe Ravikumara Sharma Chengalvala
Praveen Kumar Yalavarty
John Correia
Rajesh Balaji VIJAYAN
Edward Charles Esker
Michael Raymond Westra
Leonie Tessa Tielert
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 DE102019135012A1 publication Critical patent/DE102019135012A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • 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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • 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]
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Diese Offenbarung betrifft einen auf Richtlinie und Token basierenden Autorisierungsrahmen für Konnektivität.Ein System, das einen oder mehrere Server beinhaltet, dazu programmiert, als Reaktion auf das Empfangen einer Tokenanforderung von einem Fahrzeug, um auf in einer Inhaltscloud gespeicherten Inhalt zuzugreifen, die Tokenanforderung anhand vordefinierter Richtlinien zu validieren; als Reaktion auf eine erfolgreiche Richtlinienvalidierung die Verantwortung für die Tokenerzeugung auf der Grundlage eines Validierungsergebnisses und vordefinierter Richtlinien zu Verifizieren; und als Reaktion auf das verifizieren, dass das System die Verantwortung für die Tokenerzeugung hat, ein Token für die Tokenanforderung zu erzeugen.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Offenbarung bezieht sich im Allgemeinen auf ein Fahrzeugkonnektivitätsautorisierungssystem. Insbesondere bezieht sich die vorliegende Offenbarung auf ein auf Richtlinie und Token basierendes Autorisierungssystem für F ahrzeugkonnektivität.
  • ALLGEMEINER STAND DER TECHNIK
  • Viele Fahrzeuge sind mit drahtlosen Konnektivitätsfunktionen ausgestattet, mit denen die Fahrzeuge auf entfernte Inhalte zugreifen können. Beispielsweise kann eine Telematiksteuereinheit (telematics control unit - TCU) dazu verwendet werden, ein Fahrzeug über ein drahtloses Netzwerk mit einer Cloud zu verbinden. Eine elektronische Steuereinheit (electronic control unit - ECU) kann den Zugriff auf digitale Inhalte von einem entfernten Server über die TCU anfordern. Aus Sicherheitsgründen können verschiedene Berechtigungen erforderlich sein, bevor die ECU auf den auf dem Server gespeicherten digitalen Inhalt zugreifen kann, was die Latenz und Komplexität der Kommunikation erhöht.
  • KURZDARSTELLUNG
  • In einer oder mehreren veranschaulichenden Ausführungsformen der vorliegenden Offenbarung ist ein System, das einen oder mehrere Server beinhaltet, dazu programmiert, als Reaktion auf das Empfangen einer Tokenanforderung von einem Fahrzeug, um auf in einer Inhaltscloud gespeicherten Inhalt zuzugreifen, die Tokenanforderung anhand vordefinierter Richtlinien zu validieren; als Reaktion auf eine erfolgreiche Richtlinienvalidierung die Verantwortung für die Tokenerzeugung auf der Grundlage eines Validierungsergebnisses und vordefinierter Richtlinien zu Verifizieren; und als Reaktion auf das verifizieren, dass das System die Verantwortung für die Tokenerzeugung hat, ein Token für die Tokenanforderung zu erzeugen.
  • In einer oder mehreren veranschaulichenden Ausführungsformen der vorliegenden Offenbarung ist ein Fahrzeug, das eine Steuerung beinhaltet, dazu programmiert, als Reaktion auf das Erkennen einer Tokenanforderung von einer elektronischen Steuereinheit (ECU), die den Zugriff auf einen Inhalt in einer Cloud anfordert, Metainformationen der Tokenanforderung zu validieren; als Reaktion auf eine erfolgreiche Metainformationsvalidierung die Tokenanforderung anhand von fahrzeuginternen Richtlinien zu validieren; als Reaktion auf eine erfolgreiche Validierung von fahrzeuginternen Richtlinien die Tokenanforderung über eine Telematiksteuereinheit (TCU) an die Cloud zu senden; als Reaktion auf das Empfangen eines Tokens aus der Cloud das Token zu validieren einen Ablaufzeitstempel des Tokens zu speichern; und eine Verbindung zur Cloud herzustellen, um auf den Inhalt zuzugreifen, wobei das Token von einem Herstellerserver erzeugt wird, der dazu konfiguriert, die Tokenanforderung anhand vordefinierter Richtlinien zu validieren, die Verantwortung der Tokenerzeugung auf der Grundlage eines Validierungsergebnisses und vordefinierter Regeln zu verifizieren und als Reaktion auf das Verifizieren, dass der Herstellerserver die Verantwortung für die Tokenerzeugung hat, ein Token für die Tokenanforderung zu erzeugen.
  • In einer oder mehreren veranschaulichenden Ausführungsformen der vorliegenden Offenbarung beinhaltet ein Verfahren für einen Server als Reaktion auf das Empfangen einer Tokenanforderung von einem Fahrzeug über einen Tokenmanager, um auf auf einer Inhaltsserver gespeicherten Inhalt zuzugreifen, Validieren der Tokenanforderung anhand vordefinierter Cloud-Richtlinien über einen Richtlinienmanager; als Reaktion auf eine erfolgreiche Validierung der Cloud-Richtlinien von dem Richtlinienmanager Verifizieren der Verantwortung für die Tokenerzeugung auf der Grundlage eines Validierungsergebnisses der Cloud-Richtlinie und vordefinierter Richtlinien über den Tokenmanager; und als Reaktion auf das Verifizieren, dass die Verantwortung für die Tokenerzeugung beim Inhaltsserver liegt, Senden der Tokenanforderung über einen Anwendungsprogrammschnittstellen (API)-Manager an den Inhaltsserver.
  • Figurenliste
  • Für ein besseres Verständnis der Erfindung und um zu zeigen, wie sie durchgeführt werden kann, werden an dieser Stelle Ausführungsformen davon ausschließlich als nicht einschränkende Beispiele beschrieben, wobei auf die beigefügten Zeichnungen verwiesen wird, in denen Folgendes gilt:
    • 1 veranschaulicht eine beispielhafte Blocktopologie eines Fahrzeugsystems einer Ausführungsform der vorliegenden Offenbarung;
    • die 2A und 2B veranschaulichen ein beispielhaftes Datenflussdiagramm für einen Prozess eines Fahrzeugverbindungssystems einer Ausführungsform der vorliegenden Offenbarung;
    • die 3A und 3B veranschaulichen ein beispielhaftes Datenflussdiagramm für einen Prozess eines Fahrzeugverbindungssystems einer anderen Ausführungsform der vorliegenden Offenbarung; und
    • 4 veranschaulicht ein beispielhaftes Datenflussdiagramm für einen Prozess eines Fahrzeugverbindungssystems einer noch anderen Ausführungsform der vorliegenden Offenbarung.
  • DETAILLIERTE BESCHREIBUNG
  • Detaillierte Ausführungsformen der vorliegenden Erfindung sind hier wie vorgeschrieben offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein exemplarisch für die Erfindung stehen, die in verschiedenen und alternativen Formen verkörpert werden kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert sein, um Details bestimmter Komponenten zu zeigen. Demnach sind die hier offenbarten konkreten strukturellen und funktionellen Einzelheiten nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann den vielfältigen Gebrauch der vorliegenden Erfindung zu lehren.
  • Die vorliegende Offenbarung sieht im Allgemein mehrere Schaltungen oder andere elektrische Vorrichtungen vor. Alle Verweise auf die Schaltungen und andere elektrische Vorrichtungen und die von ihnen jeweils bereitgestellten Funktionen sollen nicht darauf beschränkt sein, nur das einzuschließen, was hierin veranschaulicht und beschrieben ist. Während den verschiedenen Schaltungen oder anderen elektrischen Vorrichtungen bestimmte Bezeichnungen zugewiesen werden können, können derartige Schaltungen und andere elektrische Geräte auf Grundlage der jeweiligen Art der gewünschten elektrischen Umsetzung miteinander kombiniert werden und/oder auf eine beliebige Weise getrennt werden. Es liegt auf der Hand, dass hier offenbarte Schaltungen oder andere elektrische 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 hier offenbarten Vorgang/Vorgänge durchzuführen. Zusätzlich kann eine beliebige oder können mehrere beliebige der elektrischen Vorrichtungen dazu ausgelegt 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 Fahrzeugkonnektivitätsautorisierungssystem vor. Insbesondere sieht die vorliegende Offenbarung ein auf Richtlinie und Token basierendes Autorisierungssystem für Fahrzeugkonnektivität vor.
  • Unter Bezugnahme auf 1 ist eine beispielhafte Blocktopologie eines Fahrzeugsystems 100 einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Bei einem Fahrzeug 102 kann es sich um unterschiedliche Arten von Automobilen, Softroadern (Crossover Utility Vehicle - CUV), Geländewagen (Sport Utility Vehicle - SUV), Lastwagen, Wohnmobilen (Recreational Vehicle - RV), Booten, Flugzeugen oder sonstige mobile Maschinen zum Befördern von Personen oder Transportieren von Gütern handeln. In vielen Fällen kann das Fahrzeug 102 durch eine Brennkraftmaschine angetrieben werden. Als eine weitere Möglichkeit kann das Fahrzeug 102 ein Batterie-Elektrofahrzeug (Battery Electric Vehicle - BEV), ein Hybrid-Elektrofahrzeug (Hybrid Electric Vehicle - HEV) sein, das sowohl durch einen Verbrennungsmotor als auch durch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Serienhybrid-Elektrofahrzeug (Series Hybrid Electric Vehicle - SHEV), ein Parallelhybrid-Elektrofahrzeug (Parallel Hybrid Electric Vehicle - PHEV) oder ein Parallel/Serienhybrid-Fahrzeug (Parallel/Series Hybrid Vehicle - PSHEV), ein Boot, ein Flugzeug oder eine andere mobile Maschine zum Transport von Personen oder Waren. Als ein Beispiel kann das System 100 das SYNC-System enthalten, hergestellt durch die Ford Motor Company in Dearborn, Michigan. Es ist anzumerken, dass das veranschaulichte System 100 lediglich ein Beispiel darstellt und mehr, weniger und/oder anders angeordnete Elemente verwendet werden können.
  • Wie in 1 veranschaulicht, kann eine Rechenplattform 104 einen oder mehrere Prozessoren 112 beinhalten, die dazu konfiguriert sind, Anweisungen, Befehle und andere Routinen durchzuführen, um die hier beschriebenen Prozesse zu unterstützen. Zum Beispiel kann die Rechenplattform 104 dazu konfiguriert sein, Anweisungen von Fahrzeuganwendungen 108 zum Bereitstellen von Funktionen, wie etwa Navigation, Satellitenfunk und drahtlose Kommunikation, auszuführen. Derartige Anweisungen und andere Daten können nicht flüchtig unter Verwendung einer Vielzahl von Arten von elektronisch lesbaren Speichermedien 106 gepflegt werden. Das computerlesbare Medium 112 (auch als prozessorlesbares Medium oder Speicher bezeichnet) beinhaltet ein beliebiges nichttransitorisches Medium (z. B. ein physisches Medium), das an der Bereitstellung von Anweisungen oder anderen Daten beteiligt ist, die durch den Prozessor 106 der Rechenplattform 104 gelesen werden können. Durch den Computer ausführbare Anweisungen können von Computerprogrammen zusammengestellt oder interpretiert werden, welche unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien hergestellt wurden, einschließlich unter anderem und entweder allein oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl und PL/SQL.
  • Die Rechenplattform 104 kann mit verschiedenen Funktionen ausgestattet sein, durch welche die Fahrzeuginsassen/-benutzer eine Verbindung mit der Rechenplattform 104 herstellen können. Die Rechenplattform 104 kann zum Beispiel Eingaben von Bedienelementen einer Mensch-Maschine-Schnittstelle (Human-Machine Interface - HMI) 118 empfangen, welche so konfiguriert ist, dass sie eine Interaktion zwischen Insassen und Fahrzeug 102 ermöglicht. Als ein Beispiel kann die Rechenplattform 104 mit einer oder mehreren Tasten oder anderen HMI-Steuerungen eine Schnittstelle herstellen, 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 ferner eine oder mehrere Anzeigen 116 steuern oder anderweitig damit kommunizieren, welche so konfiguriert sind, dass sie über ein Videosteuergerät 114 eine visuelle Ausgabe für die Fahrzeuginsassen bereitstellen. In einigen Fällen kann die Anzeige 116 ein Touchscreen sein, der außerdem dazu konfiguriert ist, berührungsbasierte Eingaben des Benutzers über die Videosteuerung 114 zu empfangen, wohingegen die Anzeige 116 in anderen Fällen lediglich eine Anzeige ohne berührungsbasierte Eingabefunktionen sein kann. Die Rechenplattform 104 kann ferner eine oder mehrere Lautsprecher 122 steuern oder anderweitig damit kommunizieren, welche so konfiguriert sind, dass sie über eine Audiosteuerung 120 eine Audioausgabe für die Fahrzeuginsassen b erei tstell en.
  • Die Rechenplattform 104 kann auch mit Navigations- und Routenplanungsmerkmalen durch eine Navigationssteuerung 126 versehen werden, die dazu konfiguriert ist, Navigationsrouten als Reaktion auf Benutzereingaben über z. B. die HMI-Steuerungen 118 zu berechnen und geplante Routen und Navigationsanweisungen über die Lautsprecher 122 und/oder die Anzeige 116 auszugeben. Standortdaten, die für die Navigation benötigt werden, können von einer globalen Navigationssatellitensystem- (GNSS-) Steuerung 124 gesammelt werden, die dazu konfiguriert ist, mit mehreren Satelliten zu kommunizieren und den Standort des Fahrzeugs 102 zu berechnen. Die GNSS-Steuerung 124 kann dazu konfiguriert sein, verschiedene aktuelle und/oder zukünftige globale oder regionale Standortsysteme zu unterstützen, wie etwa das globale Positionierungssystem (GPS), Galileo, Beidou, das globale Navigationssatellitensystem (GLONASS) und dergleichen. Kartendaten, die für die Routenplanung verwendet werden, können als Teil der Fahrzeugdaten 110 in dem Speicher 106 gespeichert werden. Navigationssoftware kann in dem Speicher 116 als eine der Fahrzeuganwendungen 108 gespeichert sein.
  • Die Rechenplattform 104 kann dazu konfiguriert sein, mit einer mobilen Vorrichtung 140 der Fahrzeugbenutzer/-insassen über eine Drahtlosverbindung 190 zu kommunizieren. Bei der mobilen Vorrichtung 140 kann es sich um eine beliebige verschiedener Arten tragbarer Rechenvorrichtungen handeln, wie etwa Mobiltelefone, Tablet-Computer, tragbare Vorrichtungen, Smartwatches, Laptop-Computer, tragbare Musikwiedergabevorrichtungen oder andere Vorrichtungen, die zur Kommunikation mit der Rechenplattform 104 in der Lage sind. Der drahtlose Sendeempfänger 132 kann mit einer Wi-Fi-Steuerung 128, einer Bluetooth-Steuerung 130, einer Funkfrequenzidentifikations (radio-frequency identification - RFID)-Steuerung 134, einer Nahfeldkommunikations (near-field communication - NFC)-Steuerun 136 und anderen Steuerungen wie etwa einem Zigbee-Sendeempfänger, einem IrDA-Sendeempfänger (nicht gezeigt) in Kommunikation stehen und dazu konfiguriert sein, mit einem kompatiblen drahtlosen Sendeempfänger 152 der mobilen Vorrichtung 140 zu kommunizieren.
  • Die mobile Vorrichtung 140 kann mit einem Prozessor 148 versehen sein, der zum Ausführen von Anweisungen, Befehlen und anderen Routinen zur Unterstützung der Prozesse wie etwa Navigation, Telefon, drahtlose Kommunikation und Multimedia-Verarbeitung konfiguriert ist. Beispielsweise kann die mobile Vorrichtung 140 über eine Navigationssteuerung 158 und eine GNSS-Steuerung 156 mit Standort- und Navigationsfunktionen versehen werden. Die mobile Vorrichtung 140 kann mit einem drahtlosen Sendeempfänger 152 in Kommunikation mit einer Wi-Fi-Steuerung 150, einer Bluetooth-Steuerung 154, einer RFID-Steuerung 160, einer NFC-Steuerung 162 und anderen Steuerung (nicht gezeigt) versehen sein, die dazu konfiguriert sind, mit dem drahtlosen Sendeempfänger 132 der Rechenplattform 104 zu kommunizieren.
  • Die Rechenplattform 104 kann ferner dazu konfiguriert sein, mit verschiedenen elektronische Steuereinheiten (ECUs) 172 über ein oder mehrere fahrzeuginterne Netzwerke 170 zu kommunizieren. Das fahrzeuginterne Netzwerk 170 kann als Beispiel unter anderem eines oder mehrere der Folgenden beinhalten: ein CAN (controller area network), ein Ethernet-Netzwerk oder ein mediengebundener Systemtransport (media oriented system transpoert - MOST).
  • Die ECUs 172 können eine TCU 174 beinhalten, die dazu konfiguriert ist, die Telekommunikation zwischen dem Fahrzeug 102 und einer Cloud 188 über eine drahtlose Verbindung 192 unter Verwendung eines Modems 176 zu steuern. Zusätzlich oder alternativ kann die Rechenplattform 104 dazu konfiguriert sein, über die mobile Vorrichtung 140 mittels einer drahtlosen Verbindung 194 mit der Cloud 188 zu kommunizieren. Die Cloud 188 kann einen oder mehrere Server oder Computer beinhalten, die über verschiedene Arten von drahtgebundenen oder drahtlosen Netzwerken verbunden sind. Es wird angemerkt, dass der Begriff Cloud in der gesamten vorliegenden Offenbarung als allgemeiner Begriff verwendet wird und sich auf beliebige cloudbasierte Dienste beziehen kann, die mehrere Servern, Computer, Vorrichtung und dergleichen enthalten. Beispielsweise kann die Cloud 188 einen oder mehrere Herstellerserver 196 beinhalten, die dazu konfiguriert sind, die Konnektivität der TCU 174 mit der Cloud 188 zu überwachen und zu steuern. Die Cloud kann ferner einen oder mehrere Inhaltsanbieterserver 198 beinhalten, die dazu konfiguriert sind, digitalen Dateninhalt für verschiedene Komponenten (z. B. ECUs 172) des Fahrzeugs 102 bereitzustellen.
  • Die ECUs 172 können verschiedene Steuerungen beinhalten, die dazu konfiguriert sind, verschiedene Merkmale des Fahrzeugs 102 zu überwachen und zu betreiben. Als ein paar nicht einschränkende Beispiele können die ECUs 172 ferner ein Antriebsstrangsteuermodul (powertrain control module - PCM) 178 beinhalten, das zum Überwachen und Steuern des Antriebsstrangbetriebs des Fahrzeugs 102 konfiguriert ist. Zum Beispiel kann das PCM 178 dazu konfiguriert sein, den Motor (nicht gezeigt) und/oder den Fahrmodus (z. B. wirtschaftlich, normal oder sportlich) des Fahrzeugs 102 über Software und Anweisungen, die in einem internen Speicher (nicht gezeigt) des PCM 178 gespeichert sind, zu stoppen/starten. Die ECUs 172 können ferner ein Karosseriesteuerungsmodul (body control module - BCM) 180 umfassen, das dazu konfiguriert ist, Karosseriebetrieb des Fahrzeugs 102 zu überwachen und zu steuern. Zum Beispiel kann das BCM 180 dazu konfiguriert sein, Karosseriefunktionen wie zum Beispiel Verriegeln/Entriegeln einer Tür, Sicherheitsgurtwarnung, Totwinkelüberwachung oder dergleichen zu steuern und zu überwachen. Software, die zum Steuern des Betriebs des BCM 180 verwendet wird, kann in einem internen Speicher (nicht gezeigt) des BCM 180 gespeichert sein. Die ECUs 152 können ferner eine autonome Fahrsteuerung (autonomous driving controller - ADC) 160 beinhalten, die dazu konfiguriert ist, die autonomen Fahrmerkmale des Fahrzeugs 102 über in einem internen Speicher gespeicherte Software 184 zu überwachen und zu steuern. Zu den Funktionen für autonomes Fahren können Spurhalteassistent, Sicherheitsabstand zu anderen Fahrzeugen, Tempomat, Alarm beim Loslassen des Lenkrads, Autobremsen, Bremsminderung mit mehreren Empfindlichkeitsstufen oder dergleichen gehören.
  • Die von verschiedenen ECUs 172 verwendete Software kann aus der Cloud 188 aktualisiert werden. Beispielsweise kann die ADC 182 als Reaktion auf das Erkennen einer neueren Version der ADC-Software 184 eine Verbindungsanforderung an einen Inhaltsanbieterserver 198 initiieren, um die Software herunterzuladen. Aus Sicherheitsgründen kann die Rechenplattform 104 dazu verwendet werden, die Kommunikation zwischen dem ADC 182 und der Cloud 188 über die TCU 174 zu überwachen und zu steuern. Beispielsweise kann die Rechenplattform 104 als ein erweitertes zentrales Gateway (enhanced central gateway - ECG) und/oder ein drahtloser Schnittstellenrouter (wireless interface router - WIR) unter Verwendung von Software umgesetzt sein, z. B. als eine der Fahrzeuganwendungen 108, dazu konfiguriert, die Verbindungsanforderung und -antwort an und von der Cloud 188 zu validieren. Alternativ kann das ECG/der WIR kann über die TCU 174 oder ein einzelnes ECG/WIR-Modul (nicht gezeigt) als eine der ECUs 172 umgesetzt sein.
  • Unter Bezugnahme auf 2 ist ein Datenflussdiagramm für einen Prozess 200 eines Fahrzeugverbindungssystems einer Ausführungsform der vorliegenden Offenbarung veranschaulicht. Der Prozess 200 bezieht sich im Allgemeinen auf eine Fahrzeug-ECU 172, die ein Sicherheitstoken von einem Herstellerserver 196 anfordert, um auf digitalen Inhalt von einem Inhaltsanbieterserver 198 zuzugreifen. Unter weiterer Bezugnahme auf 1 erzeugt eine ECU 172 des Fahrzeugs 102 in Schritt 202 eine Anforderung für ein Sicherheitstoken, um auf einen irgendwo in der Cloud 188 gespeicherten Inhalt zuzugreifen. Abhängig von der Konfiguration des Fahrzeugsystems 102 und/oder der Cloud 188 kann das Sicherheitstoken von verschiedenen Arten sein und verschiedene Informationen enthalten. Beispielsweise kann das Sicherheitstoken ein ECG/WIR-Token sein, das es der ECU 172 erlaubt, auf den Inhalt zuzugreifen. Die von der ECU 172 erzeugte Tokenanforderung kann verschiedene Metainformationen beinhalten, wie etwa eine Anwendungsidentifikation, die den Inhalt anfordert, eine ECU-Identifikation, eine Proxy-Anforderung oder dergleichen.
  • Als Reaktion auf das Empfangen der Tokenanforderung von der ECU 172 validiert die Rechenplattform 104 in Schritt 204 die in der Tokenanforderung enthaltenen Metainformationen. Als Reaktion auf eine erfolgreiche Validierung der Metainformationen validiert die Rechenplattform 104 in Schritt 206 die Tokenanforderung weiter auf Grundlage vordefinierter fahrzeuginterner Richtlinien, um festzustellen, ob die Anforderung gültig ist. Zum Beispiel können die fahrzeuginternen Richtlinien in dem Speicher 106 gespeichert sein und beinhalten verschiedene Aspekte des Zugriffs der ECU 172 auf digitale Inhalte, wie beispielsweise einen Zeitrahmen, für den die ECU 172 eine Verbindung mit der Cloud, dem Datenplanpaket, der Priorität der Fahrzeugaufgabe oder dergleichen herstellen darf. Als Reaktion auf eine erfolgreiche Validierung anhand der fahrzeuginternen Richtlinien sendet die Rechenplattform 104 in Schritt 208 die Tokenanforderung über die TCU 174 an den Herstellerserver 196, um die Erzeugung eines Sicherheitstoken für die Verbindung anzufordern.
  • Der Herstellerserver 196 kann eine oder mehrere Computerservervorrichtungen beinhalten, die einem Hersteller des Fahrzeugs 102, einem Hersteller der anfordernden ECU 172, einem Softwareentwickler der anfordernden ECU-Software und/oder eine beliebigen Partei, die berechtigt ist, die Kommunikation zwischen dem Fahrzeug 102 und dem InhaltsanbieterServer 198 zu steuern, zugeordnet sind. Der Herstellerserver 196 kann in mehrere Untersystem unterteilt sein, darunter ein Tokenmanagementsystem 260, das dazu konfiguriert ist, Sicherheitstoken zu erzeugen, ein Richtlinienmanagementsystem 262, das dazu konfiguriert ist, Cloud-Richtlinien zu verwalten, und ein Anwendungsprogrammschnittstellen (API)-Managementsystem 264, das dazu konfiguriert ist, mit dem Inhaltsanbieterserver 198 eine Schnittstelle zu bilden. Die mehreren Untersysteme können über Softwareanwendungen umgesetzt sein und dieselbe Hardwarestruktur nutzen. Beispielsweise validiert der Herstellerserver 196 als Reaktion auf das Empfangen der Tokenanforderung vom Fahrzeug 102 über das Tokenmanagementsystem 260 in Schritt 210 die Tokenanforderung anhand cloudbasierter Richtlinien über das Richtlinienmanagementsystem 262. Ähnlich den fahrzeuginternen Richtlinien kann der Herstellerserver 196 mit verschiedenen Richtlinien für die Datenkommunikation konfiguriert sein. Als einige nichteinschränkende Beispiele kann das Richtlinienmanagementsystem 262 die Tokenanforderung anhand einer Anwendung zum Management verbundener Fahrzeugmerkmale (connected vehicle feature management application - CVFMA) validieren, die den Umfang der verbundenen Merkmale von Fahrzeugen (einschließlich des Fahrzeugs 102), Abonnementmanagement, Kundenkonnektivitätseinstellungen und/oder verschiedene allgemeine oder spezifische Geschäftsregeln (z. B. merkmalsumsetzungsspezifische (FI-spezifische) Geschäftsregeln, die bestimmte Verbindungsfunktionen verwalten) verwalten, um zu bestimmen, ob die Tokenanforderung fortgesetzt und gewährt werden soll. Als Reaktion auf eine erfolgreiche cloudbasierte Richtlinienvalidierung aggregiert das Richtlinienmanagementsystem 262 in Schritt 212 die Validierungsantwort, um ein aggregiertes Richtlinienvalidierungsergebnis zu erzeugen, um es an das Tokenmanagementsystem 260 zurückzusenden.
  • Mit dem aggregierten Richtlinienvalidierungsergebnis, das von dem Richtlinienmanagementsystem 262 empfangen wurde, bestimmt das Tokenmanagementsystem 260 in Schritt 214 eine Tokenerzeugungsverantwortung basierend auf dem aggregierten Richtlinienvalidierungsergebnis. Beispielsweise wurde die Tokenanforderung möglicherweise bereits anhand einer vordefinierten Geschäftsregel verifiziert, die angibt, ob es für den Herstellerserver 196 ausreicht, das Sicherheitstoken zu generieren, oder ob der angeforderte Inhaltsanbieterserver 198 etwas anderes erfordert. In dem in dem Prozess 200 veranschaulichten Beispiel bestimmt das Tokenmanagementsystem 260, dass das Sicherheitstoken von dem Herstellerserver 196 erzeugt werden soll. Als Reaktion auf eine derartige Bestimmung erzeugt das Tokenmanagementsystem 260 das Sicherheitstoken in Schritt 216. Das Sicherheitstoken kann eine Autorisierung für den Inhalt beinhalten, die die ECU 172 anfordert, für ein bestimmtes Merkmal/einen bestimmten Inhalt auf den Inhaltsanbieterserver 198 zuzugreifen. Jedes generierte Token kann eine Existenzdauer (time to live - TTL) auf Grundlage einer vordefinierten Kategorisierung des Sicherheitsrisikos des angeforderten Merkmals aufweisen. Beispielsweise kann ein Sicherheitstoken für ECU-Aktualisierungen im Vergleich zu einem Sicherheitstoken für den Online-Zugang zu Unterhaltungsmedien (z. B ein paar Stunden) eine kürzere TTL haben (z. B. ein paar Minuten). Abhängig von der angeforderten Funktion kann das Sicherheitstoken während der TTL wiederverwendet werden. Alternativ kann die Sicherheit so konfiguriert sein, dass sie nur einmal verwendet werden kann und während der TTL nur einmal verwendet werden kann. In Schritt 218 sendet der Herstellerserver 196 das Sicherheitstoken über das API-Managementsystem 264 an den Inhaltsanbieterserver 198. Der Inhaltsanbieterserver 198 kann einen oder mehrere Server oder Rechen-/Speichervorrichtungen beinhalten, die mit dem Herstellerserver 196 verbunden sind oder von diesem unabhängig sind. Beispielsweise kann der Inhaltsanbieterserver 198 in den Herstellerserver 196 integriert sein. Alternativ kann der Inhaltsanbieterserver 198 von einer dritten Partei betrieben werden, die von dem Fahrzeughersteller oder dem ECU-Hersteller entfernt und unabhängig ist und dazu konfiguriert ist, kostenlos oder auf einer Abonnementgrundlage digitalen Inhalt bereitzustellen.
  • Als Reaktion auf das Empfangen des Sicherheitstokens speichert der Inhaltsanbieterserver 198 das Token zum Validieren von Inhaltsanforderungszwecken in Schritt 220 und sendet in Schritt 222 über das API-Managementsystem 264 eine Tokenbestätigung an das Tokenmanagementsystem 206. In Schritt 224 sendet das Tokenmanagementsystem 260 das in Schritt 214 erzeugte Sicherheitstoken zur reaktiven Validierung an das Fahrzeug 102. Als Reaktion auf das Empfangen des Sicherheitstokens validiert die Rechenplattform 104 in Schritt 226 das Sicherheitstoken und speichert das Sicherheitstoken nach einer erfolgreichen Validierung. In Schritt 228 sendet die Rechenplattform 104 das Sicherheitstoken zusammen mit der Verbindungsadresse (z. B. Internetprotokoll (IP)-Adresse), die zum Herstellen der Verbindung zu der inhaltsanfordernden ECU 172 verwendet wird. Die Verbindungsadresse kann im Sicherheitstoken enthalten sein oder separat gesendet werden. In Schritt 230 wird eine Verbindung zwischen der inhaltsanfordernden ECU 172 und dem Inhaltsanbieterserver 198 unter Verwendung des Sicherheitstokens hergestellt.
  • Das Sicherheitstoken kann während der TTL des Tokens wiederverwendet werden. Beispielsweise kann das Token während der TTL lokal von der anfordernden ECU 172 zwischengespeichert oder alternativ im Fahrzeugspeicher gespeichert werden (z. B. der Speicher 106). Auf diese Weise kann die Kommunikationslatenz zwischen dem Fahrzeug 102 und der Cloud 188 verringert werden. Zusätzlich kann das Tokenmanagementsystem 260 das Sicherheitstoken aus Sicherheitsgründen jederzeit widerrufen. Für den Fall, dass das Token an einer anderen Stelle generiert wird, kann die tokenerzeugende Einheit das Token widerrufen. Eine Widerrufsnachricht kann an das Fahrzeug 102 gesendet werden.
  • Die Schritte des Prozesses 200 können auf verschiedene Situationen angewendet werden. Der Prozess kann initiiert werden, indem eine der ECUs 172 automatisch anfordert, digitalen Inhalt aus der Cloud 188 herunterzuladen. Alternativ kann die ECU 172 die Tokenanforderung als Reaktion auf eine Benutzereingabe über die HMI 118 initiieren. Beispielsweise kann ein Benutzer des Fahrzeugs 102 über die HMI 118 eine Eingabe in die Rechenplattform 104 vornehmen, um den ADC 184 anzuweisen, die neueste Versionssoftware 184 aus der Cloud 188 herunterzuladen. Als ein anderes Beispiel kann die Navigationssteuerung 126 als Reaktion auf eine Benutzereingabe in das Navigationsmerkmal anfordern, auf Live-Verkehrsdaten aus der Cloud 188 zuzugreifen. Das Token, das zum Herstellen einer Verbindung mit dem Inhaltsanbieterserver benötigt wird, ist möglicherweise ein ECG/WIR-Token, und die Rechenplattform 104 kann als ein ECG/WIR betrieben werden, um die Tokenanforderung von der anfordernden ECU 172 zu validieren. Nach dem vorstehenden Beispiel der ADC 182, die eine Softwareaktualisierung anfordert, kann die als ECG/WIR dienende Rechenplattform 104 die Anfrage anhand vordefinierter fahrzeuginterner Richtlinien, die z. B. in dem Speicher 106 gespeichert sind, validieren. Als Reaktion auf eine erfolgreiche Validierung kann die Rechenplattform 104 die Tokenanforderung an den vordefinierten Herstellerserver 196 zur Tokenvalidierung über die TCU 174 senden. Zusätzlich oder alternativ kann die Tokenanforderung über die mobile Vorrichtung 140 über die drahtlose Verbindung 194 an den Herstellerserver 196 gesendet werden.
  • Wie vorstehend erörtert, kann der Herstellerserver 196 in mehrere Untersysteme unterteilt sein. Die mehreren Untersysteme können über Softwareanwendungen umgesetzt sein und dieselbe Hardwarestruktur nutzen. Alternativ können die mehreren Untersysteme strukturell unabhängig voneinander sein und über Kabel und/oder drahtlose Verbindungen verbunden sein. Das Tokenmanagementsystem 260 des Herstellerservers 196 kann dazu konfiguriert sein, mit dem Fahrzeug 102 zu kommunizieren, und das API-Managementsystem 264 kann dazu konfiguriert sein, mit dem Inhaltsanbieterserver 198 zu kommunizieren. Als Reaktion auf das Empfangen der Tokenanforderung vom Fahrzeug 102 kann das Tokenmanagementsystem 260 die Anforderung zur Validierung anhand verschiedener Cloud-Richtlinien an das Richtlinienmanagementsystem 262 senden. Das Richtlinienmanagementsystem 262 erzeugt ein aggregiertes Validierungsergebnis als Reaktion auf eine erfolgreiche Validierung. Als nächstes kann das Tokenmanagementsystem 260 entscheiden, ob ein vom Herstellerserver 196 erzeugtes Sicherheitstoken für die anfordernde ADC 182 ausreicht, um auf die Software-Aktualisierung vom Inhaltsanbieterserver zuzugreifen. Wenn zum Beispiel die ADC-Software 184 vom Fahrzeughersteller entwickelt wird oder der Fahrzeughersteller vom Inhaltsanbieter autorisiert ist, das Sicherheitstoken zu generieren, kann das Tokenmanagementsystem 260 so konfiguriert sein, dass es das Sicherheitstoken generiert. Andernfalls kann in dem Fall, dass der Inhaltsanbieter nur das Sicherheitstoken akzeptiert, das lokal vom Inhaltsanbieterserver 198 oder anderen autorisierten Parteien generiert wurde, das Tokenmanagementsystem 260 die autorisierten Server/Parteien für das Sicherheitstoken über das API-Managementsystem 264 anfordern.
  • Gemäß dem Beispiel, das in dem Prozess 200 dargestellt ist, in dem das Tokenmanagementsystem 260 das Sicherheitstoken generiert und das Sicherheitstoken über das API-Managementsystem 264 an den Inhaltsanbieterserver 198 sendet, kann der Inhaltsanbieterserver 198 das Token speichern und eine Bestätigung zurück zum Herstellerserver 196 senden. Das Tokenmanagementsystem 260 kann ferner als Reaktion auf das Empfangen der Bestätigung das Sicherheitstoken an das Fahrzeug 102 senden. Alternativ kann das Tokenmanagementsystem 260 das Sicherheitstoken an das Fahrzeug 102 senden, ohne auf die Bestätigung vom Inhaltsanbieterserver 198 zu warten. Die über das ECG/WIR-Merkmal verfügende Rechenplattform 104 kann das Sicherheitstoken in dem Speicher 106 und einen Ablaufzeitstempel, der mit dem Sicherheitstoken empfangen wurde, als Antwort auf eine erfolgreiche ECG/WIR-Validierung speichern. Da sowohl das Fahrzeug 102 als auch der Inhaltsanbieterserver 198 mit dem Sicherheitstoken versehen sind, kann der ADC 182 eine Inhaltsanforderung unter Verwendung des Sicherheitstokens über die TCU 174 und/oder das Mobilgerät 140 senden. Der Inhaltsanbieterserver 198 kann eine Inhaltsantwort an das Fahrzeug 102 senden, die auf den Empfang der Inhaltsanfrage anspricht, und es wird eine Datenverbindung zwischen dem Fahrzeug 102 und dem Inhaltsanbieterserver 198 hergestellt. In einigen Fällen kann der Herstellerserver 196 bei Bedarf als Proxy zwischen dem Fahrzeug 102 und dem Inhaltsanbieterserver 198 dienen.
  • Unter Bezugnahme auf 3 ist ein Datenflussdiagramm für einen Prozess 300 eines Fahrzeugverbindungssystems einer anderen Ausführungsform der vorliegenden Offenbarung veranschaulicht. Verglichen mit dem unter Bezugnahme auf 2 dargestellten Prozess 200 besteht der Hauptunterschied des vorliegenden Beispiels darin, dass das Token auf dem Inhaltsanbieterserver 198 generiert wird. Mit Bezug auf den Prozess 300 sind die Schritte 302-312 im Wesentlichen die gleichen wie die Schritte 202-212 des Prozesses 200. In Schritt 314 bestimmt das Tokenmanagementsystem 260, dass die Tokenerzeugungsverantwortung auf Grundlage des aggregierten Richtlinienvalidierungsergebnisses zu dem Inhaltsanbieterserver 198 gehört. Als Reaktion darauf sendet das Tokenmanagementsystem 260 die Tokenanforderung über das API-Managementsystem 264 in den Schritten 316 und 318 an den Inhaltsanbieterserver 198. Die Tokenanforderung kann dieselbe Tokenanforderung sein, die das Tokenmanagementsystem 260 vom Fahrzeug 102 empfangen hat. Alternativ kann das Tokenmanagementsystem 206 eine neue Tokenanforderung auf Grundlage der ursprünglichen Tokenanforderung vom Fahrzeug 102 zum Senden an den Inhaltsanbieterserver 198 erzeugen.
  • Als Reaktion auf das Empfangen der Tokenanforderung vom API-Managementsystem 264 validiert der Inhaltsanbieterserver 198 in Schritt 320 die Tokenanforderung und generiert ein Sicherheitstoken als Reaktion auf eine erfolgreiche Validierung. Das Sicherheitstoken kann einen Zeitrahmen, innerhalb dessen das Token gültig ist, sowie den Inhalt, auf den die anfordernde ECU 172 zugreifen darf, festlegen. In Schritt 322 sendet der Inhaltsanbieterserver 198 das Sicherheitstoken über das API-Managementsystem 264 an den Herstellerserver 196. In Schritt 324 leitet der Herstellerserver 196 das Sicherheitstoken an das Fahrzeug 102 weiter. Als Reaktion auf das Empfangen des Sicherheitstokens validiert die Rechenplattform 104 in Schritt 326 das Sicherheitstoken und speichert das Sicherheitstoken nach einer erfolgreichen Validierung. In Schritt 328 sendet die Rechenplattform 104 das Sicherheitstoken zusammen mit der IP-Adresse, die zum Herstellen der Verbindung mit der inhaltsanfordernden ECU 172 verwendet werden soll. In Schritt 330 wird eine Verbindung zwischen der inhaltsanfordernden ECU 172 und dem Inhaltsanbieterserver 198 über den Herstellerserver 196 als ein Proxy hergestellt.
  • Unter Bezugnahme auf 4 ist ein Datenflussdiagramm für einen Prozess 400 eines Fahrzeugverbindungssystems einer anderen Ausführungsform der vorliegenden Offenbarung veranschaulicht. Im vorliegenden Beispiel wird die Sicherheitstokenanforderung vom Inhaltsanbieterserver 198 initiiert. In Schritt 402 erzeugt der Inhaltsanbieterserver 198 eine Tokenanforderung als Reaktion auf das Erkennen eines Auslöseereignisses, z. B. eine Software-Aktualisierung, die für eine Fahrzeug-ECU 172 verfügbar ist. Der Inhaltsanbieterserver 198 senden die Tokenanforderung über das API-Managementsystem 264 des Herstellerservers 196 in den Schritten 404 und 406 an das Tokenmanagementsystem 260. In Schritt 408 validiert das Tokenmanagementsystem 260 die in der Tokenanforderung enthaltenen Metainformationen. Beispielsweise können die Metainformationen Softwareversion, Identität der Ziel-ECU 172, Dateninhaltstyp, Identität des Inhaltsanbieters oder dergleichen enthalten. Als Reaktion auf eine erfolgreiche Validierung von Metainformationen validiert das Richtlinienmanagementsystem 262 die Tokenanforderung anhand von Cloud-Richtlinien, darunter Merkmalsmanagement, Abonnementmanagement, Kundenkonnektivitätseinstellungen und/oder verschiedene allgemeine oder spezifische Geschäftsregeln, um zu bestimmen, ob die Tokenanforderung fortgesetzt werden soll. Als Reaktion auf eine erfolgreiche Validierung von Cloud-Richtlinien aggregiert das Richtlinienmanagementsystem 262 in Schritt 410 das Ergebnis der Richtlinienvalidierung, um ein aggregiertes Richtlinienvalidierungsergebnis für das Tokenmanagementsystem 260 zu erzeugen.
  • Das Tokenmanagementsystem 260 erzeugt als Reaktion auf eine erfolgreiche Validierung der Cloud-Richtlinie in Schritt 412 ein Sicherheitstoken und sendet in Schritt 414 das Sicherheitstoken über das API-Managementsystem 264 an den Inhaltsanbieterserver 192. In Schritt 416 speichert der Inhaltsanbieterserver 198 das Sicherheitstoken zum Validieren der Inhaltsanforderung von dem Fahrzeug 102. Das Tokenmanagementsystem 260 sendet ferner in Schritt 418 das Sicherheitstoken an das Fahrzeug 102. Als Reaktion auf das Empfangen des Sicherheitstokens validiert die Rechenplattform 104 das Sicherheitstoken und speichert das Sicherheitstoken mit einem Ablaufzeitstempel in dem Speicher 106. In Schritt 422 sendet die Rechenplattform 104 das Sicherheitstoken an die in dem Token angegebene Ziel-ECU 172, damit die Ziel-ECU 172 eine Verbindung mit dem Inhaltsanbieterserver 198 herstellen kann.
  • Obwohl vorstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Die in der Patentschrift verwendeten Ausdrücke sind vielmehr beschreibende Ausdrücke als einschränkende Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung auszubilden.
  • Gemäß einer Ausführungsform sind der eine oder die mehreren Server ferner dazu programmiert, als Reaktion auf das Empfangen der Bestätigung das Token an das Fahrzeug zu senden.
  • Gemäß einer Ausführungsform ist die Steuerung ferner dazu programmiert, eine Verbindung zum Inhaltsserver über den Herstellerserver als Proxy herzustellen.
  • Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner als Reaktion auf das Empfangen einer Bestätigung vom Inhaltsserver, die eine erfolgreiche Inhaltsservervalidierung für das Token bestätigt, gekennzeichnet durch Senden des Tokens an das Fahrzeug.

Claims (15)

  1. System, umfassend: einen oder mehrere Server, die zu Folgendem programmiert sind: als Reaktion auf das Empfangen einer Tokenanforderung von einem Fahrzeug, um auf in einer Inhaltscloud gespeicherte Inhalte zuzugreifen, die Tokenanforderung gegenüber vordefinierten Richtlinien zu validieren; als Reaktion auf eine erfolgreiche Richtlinienvalidierung, Verantwortung für die Tokenerzeugung auf der Grundlage eines Validierungsergebnisses und vordefinierter Regeln zu verifizieren; und als Reaktion auf das Verifizieren, dass das Systems Verantwortung für die Tokenerzeugung hat, ein Token für die Tokenanforderung zu erzeugen.
  2. System nach Anspruch 1, wobei der eine oder die mehreren Server ferner dazu programmiert sind, als Reaktion auf das Verifizieren, dass die Inhaltscloud die Verantwortung für die Tokenerzeugung hat, die Tokenanforderung an die Inhaltscloud zu senden.
  3. System nach Anspruch 2, wobei der eine oder die mehreren Server ferner dazu programmiert sind, als Reaktion auf das Empfangen eines Tokens von der Inhaltscloud das Token an das Fahrzeug weiterzuleiten.
  4. System nach Anspruch 1, wobei der eine oder die mehreren Server ferner dazu programmiert sind, als Reaktion auf eine erfolgreiche Richtlinienvalidierung das Validierungsergebnis zu aggregieren, um ein aggregiertes Validierungsergebnis zu erzeugen.
  5. System nach Anspruch 1, wobei der eine oder die mehreren Server ferner zu Folgendem programmiert sind: das Token an die Inhaltscloud zu senden; eine Bestätigung von der Inhaltscloud zu empfangen, in der eine erfolgreiche Validierung der Inhaltscloud unter Verwendung des Tokens bestätigt wird; und als Reaktion auf das Empfangen der Bestätigung das Token an das Fahrzeug zu senden.
  6. System nach Anspruch 1, wobei die vordefinierten Richtlinien zumindest eines von Merkmalmanagement für verbundene Fahrzeuge, Abonnementmanagement, die Kundenkonnektivitätseinstellungen oder die Geschäftsregeln für Merkmalsumsetzung beinhalten.
  7. System nach Anspruch 1, wobei der eine oder die mehreren Server ferner dazu programmiert sind, eine Verbindung zwischen dem Fahrzeug und der Inhaltscloud als ein Proxy zu ermöglichen.
  8. Fahrzeug, umfassend: eine Steuerung, die zu Folgendem programmiert ist: als Reaktion auf das Erkennen einer Tokenanforderung von einer elektronischen Steuereinheit (electronic control unit - ECU), die Zugriff auf einen Inhalt in einer Cloud anfordert, Metainformationen der Tokenanforderung zu validieren; als Reaktion auf eine erfolgreiche Metainformationsvalidierung die Tokenanforderung anhand von fahrzeuginternen Richtlinien zu validieren; als Reaktion auf eine erfolgreiche Validierung von fahrzeuginternen Richtlinien die Tokenanforderung über eine Telematiksteuereinheit (telematics control unit - TCU) an die Cloud zu senden; als Reaktion auf das Empfangen eines Tokens aus der Cloud das Token zu validieren und einen Ablaufzeitstempels des Tokens zu speichern; und eine Verbindung zur Cloud herzustellen, um auf den Inhalt zuzugreifen, wobei das Token von einem Herstellerserver erzeugt wird, der zu Folgendem konfiguriert ist: die Tokenanforderung anhand von vordefinierten Richtlinien zu validieren, die Verantwortung für die Tokenerzeugung auf der Grundlage eines Validierungsergebnisses und vordefinierter Regeln zu verifizieren; und als Reaktion auf das Verifizieren, dass der Herstellerserver Verantwortung für die Tokenerzeugung hat, ein Token für die Tokenanforderung zu erzeugen.
  9. Fahrzeug nach Anspruch 8, wobei die Steuerung ferner zu Folgendem programmiert ist: eine Verbindung zu einem Inhaltsserver herzustellen, um auf den Inhalt zuzugreifen, wobei der Inhaltsserver vom Herstellerserver entfernt ist; und eine Verbindung zum Inhaltsserver über den Herstellerserver als ein Proxy herzustellen.
  10. Fahrzeug nach Anspruch 8, wobei die Steuerung ferner dazu programmiert ist, als Reaktion auf das erfolgreiche Validieren des aus der Cloud empfangenen Tokens das Token zusammen mit einer Webadresse an die ECU zu senden, um die Verbindung herzustellen.
  11. Verfahren für einen Server, umfassend: als Reaktion auf das Empfangen einer Tokenanforderung von einem Fahrzeug über einen Tokenmanager, um auf auf einem Inhaltsserver gespeicherte Inhalte zuzugreifen, Validieren der Tokenanforderung gegenüber vordefinierten Cloud-Richtlinien über einen Richtlinienmanager; als Reaktion auf eine erfolgreiche Richtlinienvalidierung von dem Richtlinienmanager, Verifizieren der Verantwortung für die Tokenerzeugung auf der Grundlage eines Validierungsergebnisses der Cloud-Richtlinie und vordefinierter Regeln über den Tokenmanager; und als Reaktion auf das Verifizieren, dass die Verantwortung für die Tokenerzeugung beim Inhaltsserver liegt, Senden der Tokenanforderung über einen Anwendungsprogrammschnittstellen (application program interface - API)-Manager an den Inhaltsserver.
  12. Verfahren nach Anspruch 11, ferner umfassend: als Reaktion auf das Empfangen eines vom Inhaltsserver über den API-Manager erzeugten Tokens, Weiterleiten des Tokens über den Tokenmanager an das Fahrzeug.
  13. Verfahren nach Anspruch 11, wobei die vordefinierten Cloud-Richtlinien zumindest eines von Merkmalmanagement für verbundene Fahrzeuge, Abonnementmanagement, die Kundenkonnektivitätseinstellungen oder die Geschäftsregeln für Merkmalsumsetzung beinhalten.
  14. Verfahren nach Anspruch 11, ferner umfassend: als Reaktion auf das Verifizieren, dass die Verantwortung für die Tokenerzeugung beim Server liegt, Erzeugen eines Tokens für die Tokenanforderung über den T okenmanager; Senden des Tokens über den API-Manager an den Inhaltsserver; und als Reaktion auf das Empfangen einer Bestätigung vom Inhaltsserver, die eine erfolgreiche Inhaltsservervalidierung für das Token bestätigt, Senden des Tokens an das Fahrzeug.
  15. Verfahren nach Anspruch 11, ferner umfassend: Dienen als ein Proxy zwischen dem Fahrzeug und dem Inhaltsserver für die Inhaltskommunikation.
DE102019135012.3A 2018-12-20 2019-12-18 Auf richtlinie und token basierender autorisierungsrahmen für konnektivität Pending DE102019135012A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/227,441 2018-12-20
US16/227,441 US11196560B2 (en) 2018-12-20 2018-12-20 Policy and token based authorization framework for connectivity

Publications (1)

Publication Number Publication Date
DE102019135012A1 true DE102019135012A1 (de) 2020-06-25

Family

ID=70969292

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019135012.3A Pending DE102019135012A1 (de) 2018-12-20 2019-12-18 Auf richtlinie und token basierender autorisierungsrahmen für konnektivität

Country Status (3)

Country Link
US (1) US11196560B2 (de)
CN (1) CN111355701A (de)
DE (1) DE102019135012A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11225262B2 (en) * 2019-06-28 2022-01-18 Beijing Didi Infinity Technology And Development Co., Ltd. Remotely supervised passenger intervention of an autonomous vehicle
US11893092B2 (en) * 2020-01-17 2024-02-06 Sony Group Corporation Privilege auto platform
US11882446B1 (en) * 2020-07-22 2024-01-23 Motiv Power Systems, Inc. Vehicle charge station network access credential updating system
US11811929B2 (en) * 2021-01-27 2023-11-07 International Business Machines Corporation Detection of compromised credentials
US20230015789A1 (en) * 2021-07-08 2023-01-19 Vmware, Inc. Aggregation of user authorizations from different providers in a hybrid cloud environment
US11798001B2 (en) 2021-09-20 2023-10-24 International Business Machines Corporation Progressively validating access tokens
US11546358B1 (en) * 2021-10-01 2023-01-03 Netskope, Inc. Authorization token confidence system

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8874477B2 (en) * 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US8750123B1 (en) * 2013-03-11 2014-06-10 Seven Networks, Inc. Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network
WO2014197497A2 (en) * 2013-06-03 2014-12-11 The Morey Corporation Geospatial asset tracking systems, methods and apparatus for acquiring, manipulating and presenting telematic metadata
US9065765B2 (en) * 2013-07-22 2015-06-23 Seven Networks, Inc. Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network
US10572684B2 (en) * 2013-11-01 2020-02-25 Anonos Inc. Systems and methods for enforcing centralized privacy controls in de-centralized systems
US20180276674A1 (en) * 2014-03-28 2018-09-27 Confia Systems, Inc. Secure Transactions from a Connected Automobile Based on Location and Machine Identity
CA2982244C (en) * 2015-04-14 2024-01-23 Gigavation, Inc. Paravirtualized security threat protection of a computer-driven system with networked devices
US10263776B2 (en) 2016-03-12 2019-04-16 Uber Technologies, Inc. Multi-level encryption of tokenized protected data
US10479226B2 (en) 2016-09-13 2019-11-19 Ford Global Technologies, Llc Management of mobile device control of vehicle systems using policies
US10829088B2 (en) * 2017-09-22 2020-11-10 Sensormatic Electronics, LLC Identity management for implementing vehicle access and operation management

Also Published As

Publication number Publication date
US11196560B2 (en) 2021-12-07
US20200204371A1 (en) 2020-06-25
CN111355701A (zh) 2020-06-30

Similar Documents

Publication Publication Date Title
DE102019135012A1 (de) Auf richtlinie und token basierender autorisierungsrahmen für konnektivität
DE102013222428B4 (de) Berechtigungsnachweisprüfung und Autorisierungslösung zur Personenfahrzeugvermietung
DE102020111880A1 (de) Datenfreigabe zur fahrzeugaktualisierung
DE112019003727T5 (de) Elektronisches steuerungssystem für fahrzeug, programmaktualisierungsgenehmigungs-bestimmungsverfahren und programmaktualisierungsgenehmigungs-bestimmungsprogramm
DE102017108703A1 (de) Regionale Bereitstellung von Software nach Standort der Fahrzeugverbindung
DE102020100593A1 (de) Fahrzeug-zu-fahrzeug-dateifreigabesystem und -verfahren
DE102016115669A1 (de) Boardseitige Webserver-Telematiksysteme und Verfahren
DE102018119245A1 (de) Fahrzeugschlüsselverwaltung
DE102021100329A1 (de) Stellvertreterfahrzeug-ota-aktualisierung durch v2x
DE102016115545A1 (de) Mehrstufige sichere fahrzeug-softwareaktualisierung
DE102017102539A1 (de) Sicheres tunneln für sicherheit verbundener anwendungen
DE102013222421A1 (de) Mobiles, drahtloses Automobil-Kommunikationssystem für aktivierte Kleinunternehmen
DE102016212049A1 (de) Überwachungsvorrichtung für Fahrzeuginformationen
DE102017121067A1 (de) Verwaltung der steuerung einer mobilen vorrichtungen von fahrzeugsystemen unter verwendung von richtlinien
DE102019122259A1 (de) Intelligente fahrzeugverbindung
DE102020104551A1 (de) Sicherung und wiederherstellung einer fahrzeugsteuerungskonfiguration unter verwendung von datenschnappschüssen
DE102014204222A1 (de) Verfahren und vorrichtung für die umprogrammierung mehrerer fahrzeugsoftwaremodule
DE102008010056A1 (de) System und Verfahren zum Steuern eines Informationszugriffs an einer mobilen Plattform
DE102019124914A1 (de) Cloudautorisierte fahrzeugsteuerung
DE102020112275A1 (de) Identitätszugriffsverwaltung für fahrzeuge
DE102019101110A1 (de) System und verfahren zum warten eines fahrzeugs
DE102021120066A1 (de) Passthrough-richtlinie für mobile anwendungen
DE102015010203A1 (de) Verfahren zum Betreiben eines Kraftfahrzeugs und System zum Betreiben eines Kraftfahrzeugs
DE102019114358A1 (de) Vorübergehender und benutzerdefinierter fahrzeugzugriff
DE102020100734A1 (de) Fahrzeugdatenmomentaufnahme für flott

Legal Events

Date Code Title Description
R082 Change of representative

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