DE102023106929A1

DE102023106929A1 - Fahrzeugvariantenbewusste dienste

Info

Publication number: DE102023106929A1
Application number: DE102023106929.2A
Authority: DE
Inventors: Aishwarya Vasu
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2022-04-04
Filing date: 2023-03-20
Publication date: 2023-10-05
Also published as: US20230318872A1; CN116896570A

Abstract

Ein System beinhaltet einen Prozessor zum Ausführen von Anweisungen für Folgendes: Abrufen von (a) Konfigurationsdaten, die ein oder mehrere Merkmale spezifizieren, die für eine Steueranwendung in einem Fahrzeug verfügbar sind, und (b) Einstellungsdaten, die eine oder mehrere aktuelle Einstellungen für die Steueranwendung spezifizieren, bei Instanziierung einer Steueranwendung in dem Fahrzeug; Überwachen eines Fahrzeugnetzwerks auf eine Anforderung von einer entfernten Vorrichtung für ein ausgewähltes Merkmal der Steueranwendung in dem Fahrzeug; Bestimmen anhand der Konfigurationsdaten, ob das ausgewählte Merkmal in dem einen oder den mehreren Merkmalen beinhaltet ist, die für die Steueranwendung in dem Fahrzeug verfügbar sind; und Betätigen einer Komponente in dem Fahrzeug auf Grundlage des ausgewählten Merkmals und der Einstellungsdaten, wenn das ausgewählte Merkmal beinhaltet ist.

Description

GEBIET DER TECHNIK
Die Offenbarung betrifft fahrzeugvariantenbewusste Dienste.
ALLGEMEINER STAND DER TECHNIK
Automobilfähigkeiten und -merkmale für ein Fahrzeug können in Form von Diensten geliefert werden, die durch Anwendungen bereitgestellt werden. Fahrzeugdienste, zum Beispiel der Betrieb einer Fahrzeugkomponente, können durch Benutzereingaben in eine auf einer Benutzervorrichtung oder über eine Fahrzeugbenutzerschnittstelle bereitgestellte Anwendung angefordert werden, z. B. zum Starten eines Fahrzeugs, Entriegeln einer Tür oder eines Kofferraums, Öffnen oder Schließen eines Fensters, Anschalten eines Klimasteuersystems usw. Die Anwendungen, die diese Dienste liefern, können unter Verwendung von Grundsätzen und Empfehlungen für verschiedene Prioritäten, wie etwa ASIL-Klassifizierungen, entwickelt werden und können teilweise gemäß dem Betrieb einer elektronischen Steuereinheit (Electronic Control Unit - ECU) des Fahrzeug bereitgestellt werden.
KURZDARSTELLUNG
In einer Umsetzung kann ein Benutzer eine Fahrzeugkomponente, wie etwa Öffnen eines Kofferraums oder Fernstarten des Fahrzeugs, über eine Steueranwendung in dem Fahrzeug fernsteuern. Die Steueranwendung kann (a) Konfigurationsdaten, die ein oder mehrere Merkmale spezifizieren, die für das spezifische Fahrzeug verfügbar sind, und (b) Einstellungsdaten, die eine oder mehrere aktuelle Einstellungen des Fahrzeugs spezifizieren, abrufen. Die Steueranwendung überwacht ein Netzwerk in dem Fahrzeug und, wenn eine Anforderung bezüglich eines ausgewählten Merkmals von einer entfernten Vorrichtung, wie etwa einem Smartphone des Benutzers, empfangen wird, kann die Steueranwendung anhand der Konfigurationsdaten bestimmen, ob das ausgewählte Merkmal in dem spezifischen Fahrzeug beinhaltet ist. Wenn das ausgewählte Merkmal beinhaltet ist, kann die Steueranwendung eine Komponente in dem Fahrzeug auf Grundlage des ausgewählten Merkmals und der Einstellungsdaten betätigen.
Mit dem Netzwerk verbundene elektronische Steuereinheiten (ECUs) des Fahrzeugs können verwendet werden, um eine Komponente in dem Fahrzeug zu betätigen. Durch Verbinden von Fahrzeug-ECUs, die traditionell unter Verwendung eines Controller-Area-Networks (CAN-Busses) verbunden wurden, derart, dass sie stattdessen Ethernet-Protokoll-Kommunikation (IEEE 802.3) verwenden, können eine bessere Netzwerkbandbreite und schnellere Reaktionszeiten erzielt werden. Auf derartigen Plattformen hat sich eine dienstorientierte Kommunikation, die einem Publish-Subscribe-Modell folgt, als sehr zuverlässig und über eine Fahrzeug- und Cloud-Infrastruktur skalierbar erwiesen. Die Zuverlässigkeit und Skalierbarkeit können jedoch leiden, wenn Anwendungskommunikationen und -empfehlungen über Fahrzeugvarianten hinweg priorisiert werden. Eine Fahrzeugvariante ist eine Art von Fahrzeug, die durch ein oder mehrere Attribute spezifiziert ist, z. B. einen Hersteller, ein Modell, eine Ausstattungslinie usw. Zum Beispiel können Fahrzeuge, die verschiedene Anwendungsdienste nutzen, in einer breiten Vielfalt von Varianten auf Grundlage von Stilen (z. B. Pickup, SUV, Limousine, Coupe usw.), Modellen (z. B. F-150, Explorer, Mustang usw.), Ausstattungslinien (XL, XLT, Lariat, Titanium usw.) und Ausrüstungspaketen/-optionen (z. B. Technologie, Anhängerbetrieb, Schiebedach, Ledersitze usw.) erhältlich sein, die in dieser Schrift als Fahrzeugvarianten bezeichnet werden. Unterschiedliche Fahrzeugvarianten stellen nicht nur Herausforderungen für die Skalierbarkeit und Zuverlässigkeit von Anwendungen dar, die Fahrzeugdienste bereitstellen, sondern die Entwicklung von Anwendungen, die Dienste für jede Fahrzeugvariante liefern, erfordert auch zusätzliche Ressourcen.
In einer Umsetzung weist ein System eine Rechenvorrichtung auf, die einen Prozessor und einen Speicher beinhaltet, wobei der Speicher Anweisungen speichert, die durch den Prozessor ausführbar sind, wobei die Anweisungen Anweisungen zum Abrufen von (a) Konfigurationsdaten, die ein oder mehrere Merkmale spezifizieren, die für eine Steueranwendung in einem Fahrzeug verfügbar sind, und (b) Einstellungsdaten, die eine oder mehrere Einstellungen für die Steueranwendung spezifizieren, bei Instanziierung einer Steueranwendung in dem Fahrzeug beinhalten. Das System weist zudem Anweisungen zum Überwachen eines Fahrzeugnetzwerks auf eine Anforderung von einer entfernten Vorrichtung für ein ausgewähltes Merkmal der Steueranwendung in dem Fahrzeug, Bestimmen anhand der Konfigurationsdaten, ob das ausgewählte Merkmal in dem einen oder den mehreren Merkmalen beinhaltet ist, die für die Steueranwendung in dem Fahrzeug verfügbar sind, und Betätigen einer Komponente in dem Fahrzeug auf Grundlage des ausgewählten Merkmals und der Einstellungsdaten, wenn das ausgewählte Merkmal beinhaltet ist, auf.
Die Konfigurationsdaten können auf Grundlage einer Art des Fahrzeugs bestimmt werden.
Die Konfigurationsdaten können ein Baujahr, ein Modell, eine Ausstattung und optionale Ausrüstung des Fahrzeugs angeben.
Die Einstellungsdaten können einen Wert beinhalten, der auf Grundlage einer Benutzereingabe bestimmt wird.
Die Steueranwendung kann durch die Rechenvorrichtung ausführbar sein.
Eine Umsetzung kann ferner eine elektronische Steuereinheit (ECU) beinhalten, die kommunikativ an die Rechenvorrichtung gekoppelt ist, wobei die Steueranwendung durch die ECU ausführbar ist.
Die ECU und die Rechenvorrichtung können in einem Mesh-Ethernet-Netzwerk kommunikativ gekoppelt sein.
Die Rechenvorrichtung kann eine elektronische Steuereinheit (ECU) für ein Fahrzeug sein.
Die Konfigurationsdaten können Prioritätsdaten für das eine oder die mehreren Merkmale beinhalten.
Die Anweisungen können ferner Anweisungen zum Blockieren einer Anforderung für das ausgewählte Merkmal, die auf Grundlage der Prioritätsdaten als ungültig bestimmt wird, beinhalten.
Die Anweisungen können ferner Anweisungen zum Heraufsetzen einer Anzahl von Anforderungen für Merkmale, die als ungültig bestimmt wurden, und zum Ausgeben einer Benachrichtigung, wenn die Anzahl einen vorbestimmten Schwellenwert erfüllt, beinhalten.
Die Rechenvorrichtung kann ein Proxy zum Abrufen der Konfigurationsdaten, der Einstellungsdaten und zum Überwachen des Fahrzeugnetzwerks beinhalten.
Die Rechenvorrichtung kann ein Proxy zum Priorisieren von Kommunikationen und Empfehlungen auf Grundlage einer Prioritätsstufe eines Dienstes oder einer Komponente beinhalten.
Die Steueranwendung kann eine einer Vielzahl von Steueranwendungen in dem Fahrzeug sein.
In einer anderen Umsetzung beinhaltet ein Verfahren zum Bereitstellen eines Dienstes für ein Fahrzeug, der dienstorientierte Kommunikation nutzt, Ausführen einer Logik des Dienstes für das Fahrzeug in einer Dienstkomponente auf Grundlage empfangener Befehle, Ausführen von Netzwerkarbeit für den Dienst in einer Netzwerkkomponente einer Proxy-Komponente, Überwachen der Kommunikation zwischen Komponenten und/oder Diensten unterschiedlicher oder gleicher Priorität in einer Prioritätskomponente der Proxy-Komponente, Aktivieren/Deaktivieren von Anwendungsprogrammierschnittstellen (Application Programming Interfaces - APIs), die durch den Dienst angeboten werden, auf Grundlage von Fahrzeugkonfigurationsdaten, die durch eine Konfigurationskomponente der Proxy-Komponente abgerufen werden, und Anwenden gewisser Standardwerte für Ressourcen mindestens teilweise auf Grundlage von Informationen, die von Fahrzeugkonfigurationsdaten empfangen werden, die durch eine Kalibrierungskomponente der Proxy-Komponente abgerufen werden, wobei die Netzwerkkomponente, die Prioritätskomponente, die Konfigurationskomponente und die Kalibrierungskomponente der Proxy-Komponente durch ein Proxy miteinander verbunden sind.
Das Verfahren kann ferner Bereitstellen von End-to-End-Schutzmechanismen beinhalten, die aus einer Berechnung zur zyklischen Redundanzprüfung (Cyclic Redundancy Check - CRC), CRC-Prüfungen und Verschlüsselung und Entschlüsselung von Daten an den Endpunkten sowohl des Senders als auch des Empfängers mit der Netzwerkkomponente ausgewählt sind.
Das Überwachen der Kommunikation zwischen Prioritätskomponenten kann Protokollieren ungültiger Zugriffsanforderungen beinhalten.
Das Überwachen der Kommunikation zwischen Prioritätskomponenten kann ferner Blockieren ungültiger Zugriffsanforderungen beinhalten.
Das Überwachen der Kommunikation zwischen Prioritätskomponenten kann ferner Heraufsetzen einer Anzahl der ungültigen Zugriffsanforderungen und Melden der ungültigen Zugriffsanforderungen bei Erreichen einer vorbestimmten Anzahl beinhalten.
In dem Verfahren kann das Ausführen der Logik einen Aktor des Fahrzeugs betreiben.
KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 veranschaulicht ein vernetztes Fahrzeugsystem, das mit Umsetzungen der erfindungsgemäßen Konzepte verwendbar ist.
2A veranschaulicht einen beispielhaften Anwendungsfall für eine Umsetzung eines dienstorientierten Kommunikationssystems.
2B veranschaulicht eine Umsetzung einer Mesh-Dienstarchitektur.
3 veranschaulicht eine Umsetzung einer fahrzeugvariantenbewussten Mesh-Dienstarchitektur für Fahrzeugdienste, die dienstorientierte Kommunikation nutzen.
4 ist ein Ablaufdiagramm einer Umsetzung.

DETAILLIERTE BESCHREIBUNG
Unter Bezugnahme auf 1 kann ein vernetztes Fahrzeugsystem 100 Kommunikationen zwischen einem Fahrzeug 102 und einem oder mehreren tragbaren Computern 118 und einem zentralen Computer 120 bereitstellen, um Zugriff auf verschiedene Fahrzeugdienste unter Verwendung einer Fahrzeugsteueranwendung (App) bereitzustellen, die auf einem tragbaren Computer 118 eines Benutzers, wie etwa einem Smartphone oder Tablet, installiert ist. Der tragbare Computer 118 kann direkt oder indirekt mit dem Fahrzeug 102 kommunizieren, wie ausführlicher erörtert wird.
Das Fahrzeug 102 ist ein Satz von Komponenten oder Teilen, der Hardwarekomponenten und in der Regel auch Software und/oder Programmierung zum Durchführen einer Funktion oder einen Satzes von Vorgängen in dem Fahrzeug 102 beinhaltet. Fahrzeugteilsysteme 106, die Fahrzeugkomponenten (z. B. die in 2 veranschaulichten Aktoren 231, 232, 233) beinhalten, beinhalten in der Regel ein Bremssystem, ein Antriebssystem und ein Lenksystem sowie andere Teilsysteme, einschließlich unter anderem eines Karosseriesteuersystems, eines Klimasteuersystems, eines Beleuchtungssystems und eines Infotainmentsystems. Das Antriebsteilsystem wandelt Energie in eine Drehung der Räder des Fahrzeugs 102 um, um das Fahrzeug 102 vorwärts und/oder rückwärts voranzutreiben. Das Bremsteilsystem kann die Bewegung des Fahrzeugs 102 verlangsamen und/oder anhalten. Das Lenkteilsystem kann einen Gierwinkel, z. B. Abbiegen nach links und rechts und Beibehalten eines geraden Wegs, des Fahrzeugs 102 steuern, während sich dieses bewegt. Andere Beispiele für die Teilsysteme 106 können ein Klimasteuersteilsystem, ein Karosseriesteuerteilsystem (z. B. Steuern des Verriegelns/Entriegelns und Öffnens/Schließens von Fahrzeugtüren, Fenstern, Laderaumklappen, wie etwa Kofferraumdeckel und/oder Motorhaube), ein Infotainmentteilsystem, ein Zündsteuerteilsystem, ein Kraftstoffsteuerteilsystem usw. beinhalten.
Computer, einschließlich des/der in dieser Schrift erörterten eines oder mehreren Fahrzeugcomputer in Form der elektronischen Steuereinheiten (ECUs) 104, des tragbaren Computers 118 und des zentralen Computers 120, beinhalten jeweils Prozessoren und Speicher. Ein Computerspeicher kann eine oder mehrere Formen computerlesbarer Medien beinhalten und speichert Anweisungen, die durch einen Prozessor zum Durchführen verschiedener Vorgänge, einschließlich der in dieser Schrift offenbarten, ausführbar sind. Zum Beispiel kann der Computer ein generischer Computer mit einem Prozessor und einem Speicher sein, wie vorstehend beschrieben, und/oder eine ECU, eine Steuerung oder dergleichen für eine spezifische Funktion oder einen spezifischen Satz von Funktionen und/oder eine dedizierte elektronische Schaltung, einschließlich einer ASIC, die für einen konkreten Vorgang hergestellt ist, z. B. eine ASIC zum Verarbeiten von Sensordaten und/oder Kommunizieren der Sensordaten. In einem anderen Beispiel kann der Computer ein FPGA (Field-Programmable Gate Array - feldprogrammierbares Gate-Array) beinhalten, bei dem es sich um eine integrierte Schaltung handelt, die so hergestellt ist, dass sie durch einen Benutzer konfigurierbar ist. In der Regel wird eine Hardware-Beschreibungssprache, wie etwa VHDL (Very High Speed Integrated Circuit Hardware Description Language - Hardware-Beschreibungssprache für integrierte Schaltungen mit sehr hoher Geschwindigkeit), in der elektronischen Ausgestaltungsautomatisierung verwendet, um digitale und Mischsignal-Systeme, wie etwa FPGA und ASIC, zu beschreiben. Zum Beispiel wird eine ASIC auf Grundlage von VHDL-Programmierung gefertigt, die vor der Herstellung bereitgestellt wird, wohingegen logische Komponenten im Inneren eines FPGA auf Grundlage von VHDL-Programmierung konfiguriert werden können, die z. B. in einem Speicher gespeichert ist, der elektrisch mit der FPGA-Schaltung verbunden ist. In einigen Beispielen kann eine Kombination aus Prozessor(en), ASIC(s) und/oder FPGA-Schaltungen in einem Computer beinhaltet sein.
Ein Computerspeicher kann von beliebiger geeigneter Art sein, z. B. EEPROM, EPROM, ROM, Flash, Festplattenlaufwerke, Festkörperlaufwerke, Server oder beliebige flüchtige oder nichtflüchtige Medien. Der Speicher kann Daten speichern, z. B. ein Speicher einer ECU 104. Der Speicher kann eine von dem Computer getrennte Vorrichtung sein und der Computer kann in dem Speicher gespeicherte Informationen abrufen, z. B. kann/können eine oder mehrere ECUs 104 zu speichernde Daten über ein Fahrzeugnetzwerk 112 in dem Fahrzeug 102 erhalten, z. B. über einen Ethernet-Bus, einen CAN-Bus, ein drahtloses Netzwerk usw. Alternativ oder zusätzlich kann der Speicher Teil des Computers sein, d. h. als Speicher des Computers oder als Firmware eines programmierbaren Chips.
Die eine oder die mehreren ECUs 104 können in einem Fahrzeug 102 beinhaltet sein, das eine beliebige geeignete Art von Bodenfahrzeug 102 sein kann, z. B. ein Personen- oder Nutzkraftfahrzeug, wie etwa eine Limousine, ein Coupe, ein LKW, ein SUV, ein Crossover-Fahrzeug, ein Van, ein Minivan usw. Eine ECU 104 kann Programmierung zum Betreiben eines oder mehrerer von Bremsen, Antrieb (z. B. Steuerung der Beschleunigung des Fahrzeugs 102 durch Steuern eines oder mehrerer von einer Brennkraftmaschine, einem Elektromotor, einem Hybridmotor usw.), Lenkung, Klimasteuerung, Innen- und/oder Außenbeleuchtung usw. des Fahrzeugs 102 und zum Bestimmen, ob und wann der Computer derartige Vorgänge anstelle eines menschlichen Bedieners steuern soll, beinhalten. Zusätzlich kann eine ECU 104 oder ein anderer Computer dazu programmiert sein, zu bestimmen, ob und wann ein menschlicher Bediener derartige Vorgänge steuern soll.
Eine ECU 104 kann mehr als einen Prozessor beinhalten, z. B. in Komponenten, wie etwa Aktoren 108, elektronischen Steuereinheiten (ECUs) oder dergleichen, beinhaltet, die in dem Fahrzeug 102 zum Überwachen und/oder Steuern verschiedener Fahrzeugkomponenten, z. B. eines Antriebsstrangs, einer Bremssteuerung, einer Lenksteuerung usw., beinhaltet sind, oder kommunikativ daran gekoppelt sein, z. B. über ein Fahrzeugnetzwerk 112, wie etwa einen Kommunikationsbus, wie nachstehend ausführlicher beschrieben. Die ECUs 104 sind im Allgemeinen zur Kommunikation in einem Kommunikationsnetzwerk 112 des Fahrzeugs angeordnet, das einen Bus in dem Fahrzeug 102, wie etwa Ethernet (IEEE 802.3), ein Controller Area Network (CAN) oder dergleichen, und/oder andere drahtgebundene und/oder drahtlose Mechanismen beinhalten kann.
Verschiedene Steuerungen und/oder Aktoren 108 können Daten von einer oder mehreren ECUs 104 über das Kommunikationsnetzwerk des Fahrzeugs 102 empfangen. Fahrzeuge 102 beinhalten in der Regel vielfältige Aktoren 108. Einige Aktoren 108 können zudem Sensoren zum Detektieren interner Zustände betätigter Vorrichtungen des Fahrzeugs 102, zum Beispiel Raddrehzahl, Radausrichtung und Motor- und Getriebevariablen, beinhalten. Andere Aktoren 108 können den Status verschiedener Komponenten steuern, wie etwa Zündschalterstatus, Audiolautstärkestatus usw. Oft, aber nicht notwendigerweise, beinhaltet ein Aktor einen Digital-Analog-Wandler, um ein digitales Steuersignal, das von einen digitalen Computer, z. B. über ein Netzwerk, bereitgestellt wird, in ein analoges Signal umzuwandeln, das durch eine analoge Steuervorrichtung, wie etwa ein Relais oder eine Magnetspule, verwendbar ist.
Ein Fahrzeugnetzwerk 112 ist ein Netzwerk, über das Nachrichten zwischen verschiedenen Vorrichtungen in dem Fahrzeug 102 ausgetauscht werden können. Die ECUs 104 können im Allgemeinen dazu programmiert sein, über das Fahrzeugnetzwerk 112 Nachrichten an und/oder von anderen Vorrichtungen in dem Fahrzeug 102, z. B. beliebigen oder allen der ECUs 104, der Aktoren 108, der Komponenten, des Kommunikationsmoduls 110, der Teilsysteme 106, einer Mensch-Maschine-Schnittstelle HMI usw., zu senden und/oder zu empfangen. Zusätzlich können Nachrichten zwischen verschiedenen derartigen anderen Vorrichtungen in dem Fahrzeug 102 über das Fahrzeugnetzwerk 112 ausgetauscht werden. Ferner können, wie nachstehend erwähnt, verschiedene Steuerungen und/oder Aktoren 108 Daten empfangen und den ECUs 104 bereitstellen. In einigen Umsetzungen kann das Fahrzeugnetzwerk 112 ein Netzwerk sein, in dem Nachrichten über einen Kommunikationsbus des Fahrzeugs 102 übermittelt werden. Zum Beispiel kann das Fahrzeugnetzwerk 112 ein Ethernet-Netzwerk, ein Controller Area Network (CAN), in dem Nachrichten über einen CAN-Bus übermittelt werden, oder ein Local Interconnect Network (LIN), in dem Nachrichten über einen LIN-Bus übermittelt werden, beinhalten. In einigen Umsetzungen kann das Fahrzeugnetzwerk 112 ein Netzwerk beinhalten, in dem Nachrichten unter Verwendung anderer drahtgebundener Kommunikationstechnologien und/oder drahtloser Kommunikationstechnologien übermittelt werden, z. B. Ethernet, Wi-Fi, Bluetooth, Ultrabreitband (Ultra-Wide Band - UWB) usw. Zusätzliche Beispiele für Protokolle, die in einigen Umsetzungen zur Kommunikation über das Fahrzeugnetzwerk 112 verwendet werden können, beinhalten unter anderem Media Oriented System Transport (MOST), Time-Triggered Protocol TTP und FlexRay. In einigen Umsetzungen kann das Fahrzeugnetzwerk 112 eine Kombination aus mehreren Netzwerken, möglicherweise unterschiedlicher Art, darstellen, die Kommunikation zwischen Vorrichtungen in dem Fahrzeug 102 unterstützen. Zum Beispiel kann das Fahrzeugnetzwerk 112 ein CAN, in dem einige Vorrichtungen in dem Fahrzeug 102 über einen CAN-Bus kommunizieren, und ein drahtgebundenes oder drahtloses lokales Netzwerk, in dem einige Vorrichtungen in dem Fahrzeug 102 gemäß Ethernet- oder Wi-Fi-Kommunikationsprotokollen kommunizieren, beinhalten.
Die ECUs 104, der tragbare Computer 118 und/oder der zentrale Computer 120 können über ein Weitverkehrsnetzwerk 116, zum Beispiel das Internet, kommunizieren. Ferner können verschiedene in dieser Schrift erörterte Rechenvorrichtungen direkt miteinander kommunizieren, z. B. über direkte Funkfrequenzkommunikation gemäß Protokollen wie etwa BLUETOOTH oder dergleichen. Zum Beispiel kann ein Fahrzeug 102 ein Kommunikationsmodul 110 beinhalten, um Kommunikation mit Vorrichtungen und/oder Netzwerken bereitzustellen, die nicht als Teil des Fahrzeugs 102 beinhaltet sind, wie zum Beispiel dem Weitverkehrsnetzwerk 116 und/oder einem tragbaren Computer 118. Das Kommunikationsmodul 110 kann verschiedene Arten von Kommunikation, z. B. Fahrzeug-zu-Fahrzeug (V2V), Fahrzeug-zu-Infrastruktur oder zu Allem (V2X) oder Fahrzeug-zu-Allem mit Mobilfunkkommunikation (C-V2X), drahtlose Mobilfunkkommunikation, dedizierte Nahbereichskommunikation (DSRC) usw., an ein anderes Fahrzeug 102, an ein Infrastrukturelement, in der Regel über direkte Funkfrequenzkommunikation und/oder, in der Regel über das Weitverkehrsnetzwerk 116 z. B. an den zentrale Computer 120 bereitstellen. Das Kommunikationsmodul 110 könnte einen oder mehrere Mechanismen beinhalten, durch die ein Fahrzeugcomputer, wie etwa eine ECU 104, kommunizieren kann, darunter eine beliebige gewünschte Kombination aus drahtlosen, z. B. Mobilfunk-, Drahtlos-, Satelliten-, Mikrowellen- und Funkfrequenz-Kommunikationsmechanismen und eine beliebige gewünschte Netzwerktopologie oder -topologien, wenn eine Vielzahl von Kommunikationsmechanismen genutzt wird. Beispielhafte Kommunikation, die über das Modul bereitgestellt wird, kann Mobilfunk, Bluetooth, IEEE 802.11, DSRC, Mobilfunk-V2X, CV2X und dergleichen beinhalten.
Der tragbare Computer 118 kann ein Smartphone, ein Tablet, eine Smartwatch oder eine andere geeignete tragbare Rechenvorrichtung beinhalten. Der tragbare Computer 118 kann eine beliebige geeignete Art von drahtloser Kommunikation, wie etwa Mobilfunk oder Wi-Fi, verwenden, um über das Weitverkehrsnetzwerk 116 mit dem zentralen Computer 120 zu kommunizieren.
Der tragbare Computer 118 kann eine Fahrzeugsteueranwendung (App) beinhalten, um Dienste bereitzustellen, in der Regel in Verbindung mit einer Serveranwendung, die auf einem zentralen Computer 120 ausgeführt wird, und unter Verwendung des Fahrzeugkommunikationssystems 100 mit einer Fahrzeugsteueranwendung (App) zu interagieren, die auf einer ECU 104 des Fahrzeugs 102 ausgeführt wird.
2A veranschaulicht ein beispielhaftes Dienstbereitstellungskommunikationssystem 200. Ein „Dienst“ oder „Dienste“ bedeutet im Kontext dieser Offenbarung Betätigung eines oder mehrerer Aktoren 108 für verschiedene Fahrzeugkomponenten unter Verwendung eines tragbaren Computers 118. Zum Beispiel kann ein Fernstartdienst für ein Fahrzeug es einem Benutzer ermöglichen, einen Aktor (siehe Aktor 108 aus 1) für einen EIN- und einen AUSZustand der Zündung eines Fahrzeugs über eine Anwendung auf einem tragbaren Computer 118, wie etwa einem Smartphone, zu steuern. Eine derartige Anwendung kann als Fahrzeugfernsteuerapp bezeichnet werden.
Ein Benutzer kann mit der Fahrzeugfernsteuerapp auf dem tragbaren Computer 118 interagieren, um Dienstbefehle über ein Weitverkehrsnetzwerk 116 an einen zentralen Computer 120 mit einer Serveranwendung zu kommunizieren, die Programmierung zum Empfangen von Befehlen von der Fahrzeugfernsteuerapp beinhaltet. Authentifizierte/erlaubte Dienstbefehle können durch den zentralen Computer an eine ECU 104 weitergeleitet werden, die eine Fahrzeugsteueranwendung in dem Fahrzeug 102 ausführt. Dienstbefehle können für einen oder mehrere Dienste von zum Beispiel einem ersten Dienst 221, einem zweiten Dienst 222 und einem dritten Dienst 223 bereitgestellt werden. Die Dienste 221, 222 und 223 können sich auf die Steuerung eines oder mehrerer jeweiliger Aktoren 108 beziehen, die durch eine ECU 104 angeschaltet werden können, zum Beispiel eines ersten Aktors 231, eines zweiten Aktors 232 und eines dritten Aktors 233. Wie vorstehend erwähnt, können die Aktoren 231, 232, 233 Komponenten in verschiedenen Teilsystemen 106 sein. In einem Beispiel für einen Fernstartdienst kann der erste Dienst 221 ein Zünddienst sein und der Aktor 231 ein Zündschalter sein, kann der zweite Dienst 222 ein Kraftstoffsteuerdienst sein und der Aktor 232 eine Kraftstoffpumpe und/oder ein elektronisches Kraftstoffeinspritzsystem (electronic fuel injection - EFI) betreiben und kann sich der dritte Dienst 223 auf einen Wegfahrsperrendienst beziehen und kann der Aktor 233 betrieben werden, um die Türen und/oder das Getriebe des Fahrzeugs 102 zu verriegeln, um einen Diebstahl des laufenden Fahrzeugs zu vermeiden.
In einer zentralisierten Architektur unter Verwendung eines Client-Server-Modells verbinden sich einzelne Clients/Knoten mit einem Server/Broker und nehmen Komponenten ein Publish-Subscribe-Kommunikationsmuster an. Der zentrale Server/Broker ist für das Koordinieren aller Anforderungen von den Knoten/Clients verantwortlich und sendet die Antworten/Status an die Subscriber-Knoten/Clients. Diese Knoten/Clients synchronisieren sich selbst mit einer globalen Uhr, die üblicherweise durch den Server/Broker verwaltet wird. Sicherheit wird in einem zentralisierten System ohne Probleme erzielt, da die Authentifizierung und Autorisierung von Clients/Knoten durch den Server/Broker verwaltet werden. Clients/Knoten können ohne Probleme zu dem System hinzugefügt oder aus diesem entfernt werden, da der Server/Broker die Gesamtkoordination und Orchestrierung verwaltet. Anwendungen und das Gesamtsystem können jedoch ausfallen, wenn die Clients/Knoten die Netzwerkkonnektivität verlieren, und ein Ausfall des Servers/Brokers kann zu einem Ausfall des Gesamtsystems führen. Zusätzlich kann der Server/Broker überlastet werden, wenn viele Clients/Knoten zu dem System hinzugefügt werden, und können Clients/Knoten einen hohen Kommunikationsaufwand erfahren. Somit kann es selbst mit großen Mengen an Hardware- und Softwareressourcen schwierig sein, Skalierbarkeit zu erzielen.
Im Gegensatz dazu verwendet ein verteiltes System ein Peer-to-Peer-Architekturmodell, bei dem sich einzelne Clients/Knoten mit dem Netzwerk verbinden und alle Clients/Knoten auf das Erreichen eines gemeinsamen Ziels hinarbeiten. Diese einzelnen Clients/Knoten, denen eine globale Uhr fehlt, erzielen Zeitgleichheit unter Verwendung von Transaktions-IDs. Ein derartiges verteiltes System kann eine geringe Latenz und eine hohe Skalierbarkeit erzielen, da es keinen Server/Broker gibt, der die Kommunikation koordiniert. Es ist jedoch schwierig, Synchronisierung zwischen Diensten zu erzielen, und das Protokollieren der Zeitpunkte gewisser Ereignisse kann aufgrund des Fehlens einer globalen Uhr schwierig sein. In der Tat weisen die Dienste, wenn sie von unterschiedlichen ECUs 104 gehostet werden, keine gemeinsame Uhr auf.
Eine Softwarekomponente, die an einer dienstorientierten Kommunikation beteiligt ist, ist für Folgendes verantwortlich: (i) Logik für den vorgeschlagenen Dienst; (ii) Herstellen von Kommunikation mit anderen Diensten (Dienstsuche); (iii) Umsetzen einer Nachrichtenweiterleitungslogik; (iv) Umsetzen von Authentifizierungs- und Autorisierungsmechanismen für die Sicherheit; und (v) Umsetzen von Fehlerbehandlungsmechanismen (Zeitüberschreitungsbehandlung, Wiederholungsversuche usw.).
Das Einrichten und Aufrechterhalten der Peer-to-Peer-Kommunikation in einem verteilten System ist eine Herausforderung. Da die Dienste, die an der dienstorientierten Kommunikation in dem verteilten System beteiligt sind, zusätzlich zu der Logik ähnliche Netzwerk-, Sicherheits- und Fehlerbehandlungsanforderungen aufweisen, ist es vorteilhaft, die Logik von Netzwerk/Sicherheit/Fehlerbehandlung der Dienste zu entkoppeln. Dies wird unter Verwendung einer Mesh-Dienstarchitektur erzielt, in der die Logik in der Dienstkomponente enthalten ist und alle netzwerkkritischen Funktionalitäten durch eine Proxy-Komponente gehandhabt werden.
2B veranschaulicht eine Umsetzung einer Mesh-Dienstarchitektur 250, in der die Logik 262 in der Dienstkomponente 260 enthalten ist und alle netzwerkkritischen Funktionalitäten durch eine Proxy-Dienstkomponente 270 gehandhabt werden. Wie in dieser Offenbarung verwendet, bezieht sich ein Proxy oder eine Proxy-Komponente auf eine Softwareschicht oder ein Modul, die/das als Vermittler zwischen Komponenten, die Ressourcen anfordern, und Komponenten, die Ressourcen bereitstellen, fungiert. Die Dienstkomponente 260 wird in der Regel auf einer ECU 104 gehostet, die in der Lage ist, den/die Aktor(en) 108 anzuschalten, der/die dem Dienst zugeordnet ist/sind.
In einer Mesh-Dienstarchitektur kommunizieren die Dienste nicht direkt miteinander. Dienstanforderungen/-antworten werden durch die Dienst-Proxys 270 weitergeleitet. Eine Netzwerkkomponente 272 des Dienst-Proxys 270 ist für Funktionen wie etwa Dienstsuche, Dienstregistrierung, Ausfallsicherheit, Protokollierung, Lastausgleich usw. verantwortlich. Zum Beispiel kann die Dienstsuche durch Verwenden passender Themen in einem Datenverteilungsdienst (Data Distribution Service - DDS) erzielt werden. Diese Offenbarung ist jedoch nicht auf ein spezifisches Protokoll, wie etwa DDS oder Scalable Service-Oriented Middleware over IP (SOME/IP), beschränkt und es kann ein beliebiges anderes geeignetes dienstorientiertes Protokoll verwendet werden, das Peer-to-Peer-Kommunikation unterstützt. Eine Fehlerbehandlungskomponente 276 ist für Funktionen wie etwa Fehlerdetektion und - behandlung, Wiederholungsversuche bei Zeitüberschreitung, Protokollierung usw. verantwortlich. Eine Sicherheitskomponente 274 des Dienst-Proxys 270 ist für Funktionen wie etwa TLS, Schlüsselverwaltung, Zugriffssteuerung (Autorisierung und Authentifizierung) usw. verantwortlich. Die Netzwerkkomponente 272, die Sicherheitskomponente 274 und die Fehlerbehandlungskomponente 276 in dem Dienst-Proxy 270 sind durch ein Proxy 280 miteinander verbunden.
Diese Mesh-Dienstarchitektur 250 vermeidet die meisten der Probleme, die Problemen des Netzwerks 272 und der Fehlerbehandlung 276 zugeordnet sind, da sie nur für das Proxy 280 des Service-Proxy 270 zentral sind. Das Debuggen von Dienstumsetzungen ist in dieser Mesh-Dienstarchitektur 250 ebenfalls einfacher. Das Erzielen und Garantieren von Prioritätskommunikationen und -empfehlungen, z. B. gemäß ASIL-Bewertungen (Automotive Safety Integrity Level), in einer derartigen Mesh-Dienstarchitektur 250 kann jedoch in der Mesh-Dienstarchitektur 250 schwierig sein oder dieser fehlen. Darüber hinaus bietet die Mesh-Dienstarchitektur 250 möglicherweise keine ausreichende Skalierbarkeit für unterschiedliche Fahrzeugvarianten und -konfigurationen.
3 veranschaulicht eine Umsetzung einer fahrzeugvariantenbewussten Mesh-Dienstarchitektur 300 für Fahrzeugdienste, die dienstorientierte Kommunikation nutzen. In einer Umsetzung kann eine Steuerebene 310, d. h. der Teil der ausgeführten Software, der den Datenfluss zu und von der Datenebene 340 bereitstellt und/oder steuert, für fahrzeuginterne Host-Anwendungen auf einer ECU 104 eingerichtet sein, zum Beispiel einer ECU für Cloud-Dienste, die App 1 und App 2 beinhaltet. Die Steuerebene 310 kann eine Fahrzeugkonfiguration 320 beinhalten, auf die durch Anwendungen, wie etwa eine erste App 321 und eine zweite App 322, zugegriffen werden kann, um sie mit verschiedenen Diensten SVC 1 331, SVC 2 332, SVC 3 333, SVC 4 334 usw. innerhalb der Datenebene 340, d. h. des Teils der ausgeführten Software, der die Datenanforderungen/-befehle verarbeitet, der fahrzeugvariantenbewussten Mesh-Dienstarchitektur 300 zu teilen.
Wie bei der Mesh-Dienstarchitektur 250 beinhaltet jede der Komponenten des ersten bis vierten Dienstes 331, 332, 333 und 334 die Logik des jeweiligen Dienstes, die von dem Proxy 341, 342, 343 und 344 der Dienste entkoppelt ist. Gleichermaßen beinhalten die Proxys 341, 342, 343 und 344 der Dienste eine Netzwerkkomponente, wie sie in der Mesh-Dienstarchitektur 250 zu finden ist. In der fahrzeugvariantenbewussten Mesh-Dienstarchitektur 300 beinhalten die Proxys 341, 342, 343 und 344 der Dienste jedoch zusätzliche Komponenten, die in der Mesh-Dienstarchitektur 250 aus 2B nicht zu finden sind.
Wie in 3 gezeigt, beinhalten die Proxys 341, 342, 343 und 344 der Dienste in der fahrzeugvariantenbewussten Mesh-Dienstarchitektur 300 ferner eine Prioritätskomponente, eine Konfigurationskomponente zum Filtern der Dienstmerkmale auf Grundlage von Fahrzeugkonfigurationsdaten und eine Kalibrierungskomponente zum Anwenden gewisser Standardwerte für Ressourcen. Die Fahrzeugkonfigurationsdaten sind fahrzeugspezifisch und spezifizieren die Merkmale, die für eine oder mehrere Steueranwendungen verfügbar sind, auf Grundlage der konkreten Fahrzeugvariante (z. B. Baujahr, Modell, Ausstattung und optionale Ausrüstung). Zum Beispiel könnten die Konfigurationsdaten, wenn eine Steueranwendung dazu programmiert ist, ein Öffnen eines Schiebedachs aus der Ferner zu erlauben, spezifizieren, ob das Fahrzeug ein Schiebedach aufweist oder nicht. Die Standardwerte können Einstellungsdaten beinhalten, die eine oder mehrere aktuelle Einstellungen des spezifischen Fahrzeugs spezifizieren (z. B. Fahrmodus, Umgebungsbeleuchtungseinstellung, Armaturenbretteinstellungen usw.).
Die Prioritätskomponente der Proxys 341, 342, 343 und 344 kann die Kommunikation zwischen Komponenten und/oder Diensten mit unterschiedlichen Prioritäten überwachen und End-to-End-Schutzmechanismen hinzufügen, wie durch ISO 26262 empfohlen. Beispiele beinhalten unter anderem eine Berechnung zur zyklischen Redundanzprüfung (CRC), CRC-Prüfungen und Verschlüsselung und Entschlüsselung von Daten sowohl an Sender- als auch an Empfängerendpunkten. Die Prioritätskomponente protokolliert zudem ungültige Zugriffe durch Dienste mit anderen Prioritäten. Derartige Protokolle können später zur Analyse in einer Cloud-Umgebung verwendet werden und können es dem zentralen Computer 120 ermöglichen, ungültige oder böswillige Angriffe zu verfolgen, die innerhalb des Fahrzeugs 102 erfolgen können. Diese gesammelten Daten können nützlich sein, um derartige Angriffe in Zukunft zu vermeiden. Die Prioritätskomponente kann zudem ungültige Zugriffsanforderungen blockieren und/oder die Anzahl ungültiger Zugriffsanforderungen zählen und die betreffende Anwendung melden oder verwendet werden, um API-Verbesserungen zu planen, um derartige ungültige Zugriffsanforderungen in Zukunft zu verhindern.
Die Konfigurationskomponente der Proxys 341, 342, 343 und 344 ruft die Konfigurationsdaten für die Fahrzeugvariante ab und aktiviert/deaktiviert durch den Dienst angebotene Anwendungsprogrammierschnittstellen (APIs). Zum Beispiel werden bei einem Fahrzeug ohne Frunk (d. h. vorderer Kofferraum) APIs, die sich auf einen Frunk beziehen, wie etwa „FrunkÖffnen“ und „FrunkSchließen“, deaktiviert. Somit können die Dienstbenutzer nur die APIs aufrufen, die für die aktuelle Fahrzeugkonfiguration relevant sind. Dies ermöglicht, dass die Programmierung, die für Dienste entwickelt wurde, die in mehreren Fahrzeugen verwendet werden, noch auf Grundlage von Fahrzeugkonfigurationsdaten, die von der Fahrzeugkonfiguration 320 in der Steuerebene 310 empfangen werden, an eine konkrete Fahrzeugvariante angepasst werden kann. Die Konfigurationsdaten können auch durch die Fahrzeugsteueranwendung auf dem mobilen Computer 118 abgerufen werden, wobei die Konfigurationsdaten für die Fahrzeugvariante durch den Dienst innerhalb der Fahrzeugsteueranwendung angebotene Anwendungsprogrammierschnittstellen (APIs) aktivieren/deaktivieren. Darüber hinaus kann die fahrzeugvariantenbewusste Mesh-Dienstarchitektur 300 unabhängig davon sein, ob eine Anwendung innerhalb des Fahrzeugs oder cloudbasiert ausgeführt wird.
Die Kalibrierungskomponente der Proxys 341, 342, 343 und 344 ruft Kalibrierungsdaten für die Fahrzeugvariante mindestens teilweise auf Grundlage von Informationen ab, die von der Fahrzeugkonfiguration 320 in der Steuerebene 310 empfangen werden. Die Kalibrierungskomponente nutzt diese Informationen, um gewisse Standardwerte für Ressourcen anzuwenden. Zum Beispiel könnte bei einem Fahrzeug mit konfigurierbaren Fahrmodi ein Standardfahrmodus angewendet werden, wenn der Dienst bei „Zündung AN“ startet. Die Dienstkomponente, welche die Logik umsetzt, muss diese Werte nicht für unterschiedliche Fahrzeugvarianten hartcodieren. Dies ermöglicht ebenfalls, dass die Programmierung, die für Dienste entwickelt wurde, die in mehreren Fahrzeugen verwendet werden, noch an eine konkrete Fahrzeugvariante angepasst werden kann.
Somit kann eine fahrzeugvariantenbewusste Mesh-Dienstarchitektur 300 für Fahrzeugdienste, die dienstorientierte Kommunikation nutzen, Prioritätsstufen sichern, vorausgesetzt, dass die Prioritätskomponente in den Proxys 341, 342, 343, 344 bis zur höchsten Stufe (z. B. ASIL D) entwickelt ist. Zusätzlich kann ein Dienst-Proxy über Fahrzeugvarianten hinweg wiederverwendet werden, vorausgesetzt, dass Konfigurations- und Kalibrierungskomponenten des Proxy Konfigurations- und Kalibrierungsdaten für die Fahrzeugvariante abrufen können.
4 veranschaulicht ein Ablaufdiagramm einer Umsetzung des Bereitstellens eines Dienstes bei Instanziierung einer Fahrzeugsteueranwendung (z. B. 321 oder 322 in 3) in dem Fahrzeug 102.
Bei Instanziierung der Fahrzeugsteueranwendung führt ein Prozessor, wie etwa eine ECU, welche die App 2 322 ausführt, Anweisungen zum Abrufen von Konfigurationsdaten 320, die ein oder mehrere Merkmale spezifizieren, die für die Fahrzeugsteueranwendung in dem Fahrzeug verfügbar sind, bei Block 410 und Abrufen von Einstellungsdaten, die eine oder mehrere aktuelle Einstellungen für die Steueranwendung spezifizieren, bei Block 420 aus.
Zudem werden Anweisungen zum Überwachen eines Fahrzeugnetzwerks auf eine Anforderung von einer entfernten Vorrichtung für ein ausgewähltes Merkmal der Steueranwendung in dem Fahrzeug bei Block 430, Bestimmen anhand der Konfigurationsdaten, ob das ausgewählte Merkmal in dem einen oder den mehreren Merkmalen beinhaltet ist, die für die Steueranwendung in dem Fahrzeug verfügbar sind, bei Block 440 und Betätigen einer Komponente in dem Fahrzeug auf Grundlage des ausgewählten Merkmals und der Einstellungsdaten, wenn das ausgewählte Merkmal beinhaltet ist (JA bestimmt), bei Block 450 ausgeführt. Der Prozessor, der diese Anweisungen ausführt, kann sich in einer ECU befinden, welche die zu betätigende Komponente steuert. Zum Beispiel kann, wenn das ausgewählte Merkmal/der ausgewählte Aktor, wie etwa der Aktor 231 in 2A, durch einen ersten Dienst 221/331 gesteuert wird, der seine eigene ECU aufweist, eine Netzwerkkomponente des Dienst-Proxy 341 das Fahrzeugnetzwerk auf eine Anforderung von einer entfernten Vorrichtung überwachen, die Konfigurationskomponente des Dienst-Proxy 341 anhand der Konfigurationsdaten bestimmen, ob das ausgewählte Merkmal beinhaltet ist, und der erste Dienst 221/331 einen Aktor 231 auf Grundlage der Anforderung und der Einstellungen von der Kalibrierungskomponente des Dienst-Proxy 341 steuern.
Wenn bei Block 440 das Merkmal nicht in dem einen oder den mehreren Merkmalen beinhaltet ist, die für die Steueranwendung in dem Fahrzeug verfügbar sind, (NEIN bestimmt), wird die ungültige Anforderung bei Block 460 blockiert, zum Beispiel durch die Prioritätskomponente des Dienst-Proxy 341.
Bei Block 470 können ferner ungültige Anforderungen protokolliert werden und/oder kann ferner eine Anzahl heraufgesetzt werden.
Wenn bei Block 480 die Anzahl einen Schwellenwert überschreitet, kann bei Block 490 eine Benachrichtigung ausgegeben werden, um die zukünftige Softwareentwicklung zu unterstützen. Wenn bei Block 480 die Anzahl nicht den Schwellenwert überschritten hat, kann der Prozess enden, ohne dass eine Benachrichtigung ausgegeben wird.
Die Verwendung von „als Reaktion auf“, „auf Grundlage von“ und „wenn bestimmt wird“ gibt in dieser Schrift eine kausale Beziehung an, nicht nur eine rein temporale Beziehung. Die Adjektive „erstes“ und „zweites“ werden in der gesamten Schrift als Kennungen verwendet und sollen keine Bedeutung, Reihenfolge oder Menge andeuten, es sei denn, dies ist ausdrücklich angegeben.
In den Zeichnungen geben gleiche Bezugszeichen die gleichen Elemente an. Ferner könnten einige oder alle dieser Elemente geändert werden. Hinsichtlich der in dieser Schrift beschriebenen Medien, Prozesse, Systeme, Verfahren usw. versteht es sich, dass, obwohl die Schritte derartiger Prozesse usw. als gemäß einer gewissen geordneten Sequenz erfolgend beschrieben worden sind, die beschriebenen Schritte bei der Ausführung derartiger Prozesse in einer Reihenfolge durchgeführt werden könnten, bei der es sich nicht um die in dieser Schrift beschriebene Reihenfolge handelt, es sei denn, es ist etwas anderes angegeben oder erschließt sich aus dem Zusammenhang. Gleichermaßen versteht es sich ferner, dass gewisse Schritte gleichzeitig durchgeführt werden können, andere Schritte hinzugefügt oder gewisse, in dieser Schrift beschriebene Schritte ausgelassen werden könnten. Anders ausgedrückt werden die Beschreibungen von Prozessen in dieser Schrift zur Veranschaulichung gewisser Ausführungsformen bereitgestellt und sollten keinesfalls dahingehend ausgelegt werden, dass sie die beanspruchte Erfindung einschränken.
Die Offenbarung ist auf veranschaulichende Weise beschrieben worden und es versteht sich, dass die Terminologie, die verwendet worden ist, beschreibenden und nicht einschränkenden Charakters sein soll. In Anbetracht der vorstehenden Lehren sind viele Modifikationen und Variationen der vorliegenden Offenbarung möglich und die Offenbarung kann in der Praxis anders als spezifisch beschrieben umgesetzt werden.
Gemäß der vorliegenden Erfindung wird ein System bereitgestellt, das eine Rechenvorrichtung aufweist, die einen Prozessor und einen Speicher umfasst, wobei der Speicher Anweisungen speichert, die durch den Prozessor ausführbar sind, wobei die Anweisungen Anweisungen für Folgendes beinhalten: bei Instanziierung einer Steueranwendung in einem Fahrzeug, Abrufen von (a) Konfigurationsdaten, die ein oder mehrere Merkmale spezifizieren, die für die Steueranwendung in dem Fahrzeug verfügbar sind, und (b) Einstellungsdaten, die eine oder mehrere aktuelle Einstellungen für die Steueranwendung spezifizieren; Überwachen eines Fahrzeugnetzwerks auf eine Anforderung von einer entfernten Vorrichtung für ein ausgewähltes Merkmal der Steueranwendung in dem Fahrzeug; Bestimmen anhand der Konfigurationsdaten, ob das ausgewählte Merkmal in dem einen oder den mehreren Merkmalen beinhaltet ist, die für die Steueranwendung in dem Fahrzeug verfügbar sind; und, wenn das ausgewählte Merkmal beinhaltet ist, Betätigen einer Komponente in dem Fahrzeug auf Grundlage des ausgewählten Merkmals und der Einstellungsdaten.
Gemäß einer Ausführungsform werden die Konfigurationsdaten auf Grundlage einer Art des Fahrzeugs bestimmt.
Gemäß einer Ausführungsform geben die Konfigurationsdaten ein Baujahr, ein Modell, eine Ausstattung und optionale Ausrüstung des Fahrzeugs an.
Gemäß einer Ausführungsform beinhalten die Einstellungsdaten einen Wert, der auf Grundlage einer Benutzereingabe bestimmt wird.
Gemäß einer Ausführungsform ist die Steueranwendung durch die Rechenvorrichtung ausführbar.
Gemäß einer Ausführungsform ist die Erfindung ferner gekennzeichnet durch eine elektronische Steuereinheit (ECU), die kommunikativ an die Rechenvorrichtung gekoppelt ist, wobei die Steueranwendung durch die ECU ausführbar ist.
Gemäß einer Ausführungsform sind die ECU und die Rechenvorrichtung in einem Mesh-Ethernet-Netzwerk kommunikativ gekoppelt.
Gemäß einer Ausführungsform ist die Rechenvorrichtung eine elektronische Steuereinheit (ECU) für ein Fahrzeug.
Gemäß einer Ausführungsform beinhalten die Konfigurationsdaten Prioritätsdaten für das eine oder die mehreren Merkmale.
Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen zum Blockieren einer Anforderung für das ausgewählte Merkmal, die auf Grundlage der Prioritätsdaten als ungültig bestimmt wird.
Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen zum Heraufsetzen einer Anzahl von Anforderungen für Merkmale, die als ungültig bestimmt wurden, und zum Ausgeben einer Benachrichtigung, wenn die Anzahl einen vorbestimmten Schwellenwert erfüllt.
Gemäß einer Ausführungsform beinhaltet die Rechenvorrichtung ein Proxy zum Abrufen der Konfigurationsdaten, der Einstellungsdaten und zum Überwachen des Fahrzeugnetzwerks.
Gemäß einer Ausführungsform beinhaltet die Rechenvorrichtung ein Proxy zum Priorisieren von Kommunikationen und Empfehlungen auf Grundlage einer Prioritätsstufe eines Dienstes oder einer Komponente.
Gemäß einer Ausführungsform ist die Steueranwendung eine einer Vielzahl von Steueranwendungen in dem Fahrzeug.
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren zum Bereitstellen eines Dienstes für ein Fahrzeug, der dienstorientierte Kommunikation nutzt, Folgendes: Ausführen einer Logik des Dienstes für das Fahrzeug in einer Dienstkomponente auf Grundlage empfangener Befehle; Ausführen von Netzwerkarbeit für den Dienst in einer Netzwerkkomponente einer Proxy-Komponente; Überwachen der Kommunikation zwischen Komponenten und/oder Diensten unterschiedlicher oder gleicher Priorität in einer Prioritätskomponente der Proxy-Komponente; Aktivieren/Deaktivieren von Anwendungsprogrammierschnittstellen (APIs), die durch den Dienst angeboten werden, auf Grundlage von Fahrzeugkonfigurationsdaten, die durch eine Konfigurationskomponente der Proxy-Komponente abgerufen werden; und Anwenden gewisser Standardwerte für Ressourcen mindestens teilweise auf Grundlage von Informationen, die von Fahrzeugkonfigurationsdaten empfangen werden, die durch eine Kalibrierungskomponente der Proxy-Komponente abgerufen werden, wobei die Netzwerkkomponente, die Prioritätskomponente, die Konfigurationskomponente und die Kalibrierungskomponente der Proxy-Komponente durch ein Proxy miteinander verbunden sind.
In einem Aspekt der Erfindung beinhaltet das Verfahren Bereitstellen von End-to-End-Schutzmechanismen, die aus einer Berechnung zur zyklischen Redundanzprüfung (CRC), CRC-Prüfungen und Verschlüsselung und Entschlüsselung von Daten an den Endpunkten sowohl des Senders als auch des Empfängers mit der Netzwerkkomponente ausgewählt sind.
In einem Aspekt der Erfindung beinhaltet das Überwachen der Kommunikation zwischen Prioritätskomponenten Protokollieren ungültiger Zugriffsanforderungen.
In einem Aspekt der Erfindung beinhaltet das Überwachen der Kommunikation zwischen Prioritätskomponenten ferner Blockieren ungültiger Zugriffsanforderungen.
In einem Aspekt der Erfindung beinhaltet das Überwachen der Kommunikation zwischen Prioritätskomponenten ferner Heraufsetzen einer Anzahl der ungültigen Zugriffsanforderungen und Melden der ungültigen Zugriffsanforderungen bei Erreichen einer vorbestimmten Anzahl.
In einem Aspekt der Erfindung betreibt das Ausführen der Logik einen Aktor des Fahrzeugs.

Claims

Verfahren zum Betreiben einer Steueranwendung in einem Fahrzeug, umfassend: Abrufen von (a) Konfigurationsdaten, die ein oder mehrere Merkmale spezifizieren, die für die Steueranwendung in dem Fahrzeug verfügbar sind, und (b) Einstellungsdaten, die eine oder mehrere aktuelle Einstellungen für die Steueranwendung spezifizieren; Überwachen eines Fahrzeugnetzwerks auf eine Anforderung von einer entfernten Vorrichtung für ein ausgewähltes Merkmal der Steueranwendung in dem Fahrzeug; Bestimmen anhand der Konfigurationsdaten, ob das ausgewählte Merkmal in dem einen oder den mehreren Merkmalen beinhaltet ist, die für die Steueranwendung in dem Fahrzeug verfügbar sind; und Betätigen einer Komponente in dem Fahrzeug auf Grundlage des ausgewählten Merkmals und der Einstellungsdaten, wenn das ausgewählte Merkmal beinhaltet ist.
Verfahren nach Anspruch 1, wobei die Konfigurationsdaten auf Grundlage einer Art des Fahrzeugs bestimmt werden.
Verfahren nach Anspruch 1, wobei die Konfigurationsdaten ein Baujahr, ein Modell, eine Ausstattung und optionale Ausrüstung des Fahrzeugs angeben.
Verfahren nach Anspruch 1, wobei die Einstellungsdaten einen Wert beinhalten, der auf Grundlage einer Benutzereingabe bestimmt wird.
Verfahren nach Anspruch 1, wobei die Konfigurationsdaten Prioritätsdaten für das eine oder die mehreren Merkmale beinhalten.
Verfahren nach Anspruch 5, ferner umfassend Blockieren einer Anforderung für das ausgewählte Merkmal, die auf Grundlage der Prioritätsdaten als ungültig bestimmt wird.
Verfahren nach Anspruch 6, ferner umfassend Heraufsetzen einer Anzahl von Anforderungen für Merkmale, die als ungültig bestimmt wurden, und Ausgeben einer Benachrichtigung, wenn die Anzahl einen vorbestimmten Schwellenwert erfüllt.
Verfahren nach Anspruch 1, wobei die Steueranwendung dem Fahrzeug einen Dienst bereitstellt, der dienstorientierte Kommunikation über Mesh-Ethernet nutzt, und Folgendes beinhaltend: Ausführen einer Logik des Dienstes für das Fahrzeug in einer Dienstkomponente auf Grundlage empfangener Befehle; Ausführen von Netzwerkarbeit für den Dienst in einer Netzwerkkomponente einer Proxy -Komponente; Überwachen der Kommunikation zwischen Komponenten und/oder Diensten unterschiedlicher oder gleicher Priorität in einer Prioritätskomponente der Proxy-Komponente; Aktivieren/Deaktivieren von Anwendungsprogrammierschnittstellen (APIs), die durch den Dienst angeboten werden, auf Grundlage der Konfigurationsdaten, die durch eine Konfigurationskomponente der Proxy-Komponente abgerufen werden; und Anwenden gewisser Standardwerte für Ressourcen mindestens teilweise auf Grundlage der Einstellungsdaten, die durch eine Kalibrierungskomponente der Proxy-Komponente abgerufen werden, wobei die Netzwerkkomponente, die Prioritätskomponente, die Konfigurationskomponente und die Kalibrierungskomponente der Proxy-Komponente durch ein Proxy miteinander verbunden sind.
Verfahren nach Anspruch 8, ferner beinhaltend Bereitstellen von End-to-End-Schutzmechanismen, die aus einer Berechnung zur zyklischen Redundanzprüfung (CRC), CRC-Prüfungen und Verschlüsselung und Entschlüsselung von Daten an den Endpunkten sowohl des Senders als auch des Empfängers mit der Netzwerkkomponente ausgewählt sind.
Verfahren nach Anspruch 8, wobei das Überwachen der Kommunikation zwischen Prioritätskomponenten Protokollieren ungültiger Zugriffsanforderungen beinhaltet.
Verfahren nach Anspruch 10, wobei das Überwachen der Kommunikation zwischen Prioritätskomponenten ferner Blockieren ungültiger Zugriffsanforderungen beinhaltet.
Verfahren nach Anspruch 10, wobei das Überwachen der Kommunikation zwischen Prioritätskomponenten ferner Heraufsetzen einer Anzahl der ungültigen Zugriffsanforderungen und Melden der ungültigen Zugriffsanforderungen bei Erreichen einer vorbestimmten Anzahl beinhaltet.
Verfahren nach Anspruch 8, wobei das Ausführen der Logik einen Aktor des Fahrzeugs betreibt, um die Komponente zu betätigen.
Verfahren nach Anspruch 8, wobei die Konfigurationsdaten ein Baujahr, ein Modell, eine Ausstattung und optionale Ausrüstung des Fahrzeugs angeben und die Einstellungsdaten einen Wert beinhalten, der auf Grundlage einer Benutzereingabe bestimmt wird.
Computervorrichtung eines Fahrzeugs, umfassend einen Prozessor und einen Speicher, der durch den Prozessor ausführbare Anweisungen zum Durchführen des Verfahrens nach einem der Ansprüche 1-14 speichert.