DE102019100436A1 - System zum dynamischen zuweisen von diensten zwischen steuerungen in einem automobil - Google Patents

System zum dynamischen zuweisen von diensten zwischen steuerungen in einem automobil Download PDF

Info

Publication number
DE102019100436A1
DE102019100436A1 DE102019100436.5A DE102019100436A DE102019100436A1 DE 102019100436 A1 DE102019100436 A1 DE 102019100436A1 DE 102019100436 A DE102019100436 A DE 102019100436A DE 102019100436 A1 DE102019100436 A1 DE 102019100436A1
Authority
DE
Germany
Prior art keywords
vehicle
service
controller
network
controllers
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
DE102019100436.5A
Other languages
English (en)
Inventor
Raghu Prabhudeva
Aishwarya Vasu
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 DE102019100436A1 publication Critical patent/DE102019100436A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • 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/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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
    • 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/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mechanical Engineering (AREA)
  • Small-Scale Networks (AREA)

Abstract

Ein Fahrzeug beinhaltet eine Vielzahl von Steuerungen, die dazu ausgelegt sind, über ein Netzwerk zu kommunizieren, und dazu programmiert sind, einen Dienst durch Durchführung einer Vielzahl von Routinen, die in zumindest einer der Steuerungen gespeichert und ausgeführt werden, durchzuführen. Das Fahrzeug beinhaltet eine Gateway-Steuerung, die in Kommunikation mit den Steuerungen steht und dazu programmiert ist, als Reaktion auf Leistungsdaten, die eine reduzierte Leistung der ersten Steuerung anzeigen, zumindest eine der Routinen von einer ersten Steuerung zu einer zweiten Steuerung zu übertragen.

Description

  • TECHNISCHES GEBIET
  • Diese Anmeldung betrifft im Allgemeinen ein Fahrzeugkommunikationssystem, das Steuerungen in einem Fahrzeug Dienstroutinen zuweist.
  • ALLGEMEINER STAND DER TECHNIK
  • Ein Automobil beinhaltet eine Anzahl von Steuerungen. Die Steuerungen sind dazu programmiert, einen bestimmten Satz von fahrzeugbezogenen Funktionen durchzuführen. Zum Beispiel kann eine Steuerung dazu programmiert sein, Fahrzeugtürverriegelungen und Fenster zu verwalten. Dieser Satz von Funktionen bleibt während der Lebensdauer der Steuerung gleich. Eine Steuerung, die dazu programmiert ist, Türverriegelungen und Fenster zu verwalten, führt dieselben Funktionen über die Lebensdauer des Fahrzeugs durch. Steuerungen sind außerdem dazu ausgestaltet, einige Speicher- und Verarbeitungsreserven aufzuweisen, um ausreichend Ausführungszeit und Ressourcen für alle durch die Steuerung ausgeführten Funktionen sicherzustellen. In dem Fall eines teilweisen oder vollständigen Steuerungsausfalls gehen die von dieser Steuerung umgesetzten Funktionen verloren. Bestehende Systeme sind nicht fehlertolerant.
  • KURZDARSTELLUNG
  • Ein Fahrzeug beinhaltet eine Vielzahl von Steuerungen, die dazu ausgelegt sind, über ein Netzwerk zu kommunizieren, und dazu programmiert sind, einen Dienst durch Durchführung einer Vielzahl von Routinen, die in zumindest einer der Steuerungen gespeichert und ausgeführt werden, durchzuführen. Das Fahrzeug beinhaltet ferner eine Gateway-Steuerung, die in Kommunikation mit den Steuerungen steht und dazu programmiert ist, als Reaktion auf Leistungsdaten, die eine reduzierte Leistung der ersten Steuerung anzeigen, zumindest eine der Routinen von einer ersten Steuerung zu einer zweiten Steuerung zu übertragen.
  • Bei dem Netzwerk kann es sich um ein Ethernet-Netzwerk handeln, und die Steuerungen können ferner dazu ausgelegt sein, ein Constrained Application Protocol (CoAP) über das Ethernet-Netzwerk umzusetzen. Die Daten, die eine reduzierte Leistung anzeigen, können eine Antwortzeit des Diensts, die eine vorbestimmte Zeit überschreitet, beinhalten. Die Daten, die eine reduzierte Leistung anzeigen, können einen Verlust der Kommunikation zwischen der Gateway-Steuerung und der ersten Steuerung für mehr als eine vorbestimmte Zeit beinhalten.
  • Die Daten, die eine reduzierte Leistung anzeigen, können eine Kommunikationsbandbreite zwischen der ersten Steuerung und der Gateway-Steuerung, die geringer als eine vorbestimmt Bandbreite ist, beinhalten. Die Gateway-Steuerung kann ferner dazu ausgelegt sein, als Reaktion auf Leistungsdaten, die eine reduzierte Leistung anzeigen, einen Befehl an die erste Steuerung zu senden, die Routinen anzuhalten und neu zu starten. Die Gateway-Steuerung kann ferner an ein externes Netzwerk gekoppelt sein und dazu programmiert sein, mit einer Anwendung, die auf einem externen Server ausgeführt wird, über das externe Netzwerk unter Verwendung von Hyper Text Transfer Protocol (HTTP) zu kommunizieren.
  • Ein Fahrzeug beinhaltet eine Vielzahl von Steuerungen, die dazu programmiert sind, eine Vielzahl von Routinen auszuführen, um einen Dienst durchzuführen und über ein Fahrzeugnetzwerk unter Verwendung von Constrained Application Protocol (CoAP) zu kommunizieren. Das Fahrzeug beinhaltet ferner eine Gateway-Steuerung, die dazu ausgelegt ist, mit einem externen Server unter Verwendung von Hyper Text Transfer Protocol (HTTP) zu kommunizieren, über das Fahrzeugnetzwerk unter Verwendung von CoAP zu kommunizieren und einen Dienst-Manager auszuführen, der die Routinen zwischen Steuerungen auf Grundlage von Leistungsparametern der Steuerungen dynamisch zuweist.
  • Die Gateway-Steuerung kann ferner dazu programmiert sein, Leistungsparameter an den externen Server zu übertragen. Die Leistungsparameter können eine Antwortzeit zwischen einer Ankunft einer Anforderung, einen Dienst durchzuführen und dem Abschluss der Anforderung beinhalten. Die Leistungsparameter können eine Kommunikationsbandbreite zwischen Steuerungen, die über das Fahrzeugnetzwerk verwendet wird, beinhalten. Die Leistungsparameter können eine Nutzungshäufigkeit für den Dienst beinhalten. Die Gateway-Steuerung kann ferner dazu programmiert sein, als Reaktion auf das Empfangen einer Vielzahl neuer Dienstroutinen zum Durchführen eines neuen Diensts von dem externen Server, die neuen Dienstroutinen den Steuerungen auf Grundlage der Leistungsparameter dynamisch zuzuweisen und an diese zu übertragen. Die Gateway-Steuerung kann dazu programmiert sein, die Routinen auf Grundlage der Ressourcennutzung und der verbleibenden Verarbeitungskapazität der Steuerungen zuzuweisen. Die Gateway-Steuerung kann ferner dazu programmiert sein, als Reaktion darauf, dass die Leistungsparameter einer ersten Steuerung eine Reduktion der Leistung der ersten Steuerung anzeigen, zumindest eine der Routinen, die von der ersten Steuerung ausgeführt werden, an eine zweite Steuerung zu übertragen.
  • Ein Fahrzeugkommunikationssystem beinhaltet eine Gateway-Steuerung, die dazu programmiert ist, mit einem externen Server unter Verwendung von Hyper Text Transfer Protocol (HTTP) zu kommunizieren, mit einem internen Fahrzeugnetzwerk über Constrained Application Protocol (CoAP) zu kommunizieren und einen Dienst-Manager auszuführen, der eine Vielzahl von Dienstroutinen, die einem Dienst zugeordnet sind, zwischen einer Vielzahl von Steuerungen, die mit dem internen Fahrzeugnetzwerk verbunden sind, auf Grundlage von Leistungsparametern der Steuerungen dynamisch zuweist.
  • Die Gateway-Steuerung kann ferner dazu programmiert sein, Leistungsparameter von den Steuerungen zu empfangen. Die Gateway-Steuerung kann ferner dazu programmiert sein, Leistungsparameter an den externen Server zu kommunizieren. Die Gateway-Steuerung kann ferner dazu programmiert sein, Dienststatistiken von jeder der Steuerungen zu empfangen und die Dienststatistiken an den externen Server zu übertragen. Die Gateway-Steuerung kann ferner dazu programmiert sein, den Zugriff auf den externen Server für die Steuerungen zu regeln.
  • Figurenliste
    • 1 ist eine mögliche Konfiguration eines Fahrzeugkommunikationssystems.
    • 2 ist eine mögliche Konfiguration für eine verteilte Verarbeitungsarchitektur für ein Fahrzeug.
    • 3 ist eine mögliche Konfiguration, die die Verteilung von Dienstroutinen für Dienste unter Steuerungen in einem Fahrzeug abbildet.
    • 4 ist ein Ablaufdiagramm für einen möglichen Satz von Vorgängen, die durch einen Dienst-Manager ausgeführt werden, der eine verteilte Dienstarchitektur in einem Fahrzeug umsetzt.
  • DETAILLIERTE BESCHREIBUNG
  • Ausführungsformen der vorliegenden Offenbarung werden hierin beschrieben. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale könnten vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Demnach sind hierin offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielfältige Verwendung der vorliegenden Erfindung zu lehren. Der Durchschnittsfachmann wird verstehen, dass verschiedene Merkmale, die unter Bezugnahme auf eine beliebige der Figuren veranschaulicht und beschrieben sind, mit Merkmalen kombiniert werden können, die in einer oder mehreren anderen Figuren veranschaulicht sind, um Ausführungsformen zu erzeugen, die nicht ausdrücklich veranschaulicht oder beschrieben sind. Die Kombinationen veranschaulichter Merkmale stellen repräsentative Ausführungsformen für übliche Anwendungen bereit. Verschiedene Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung vereinbar sind, könnten jedoch für bestimmte Anwendungen oder Umsetzungen wünschenswert sein.
  • 1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Rechensystem 100 (vehicle-based computing system - VCS) für ein Fahrzeug. Ein Beispiel für ein derartiges fahrzeugbasiertes Rechensystem 100 ist das SYNC-System, das von THE FORD MOTOR COMPANY hergestellt wird. Das Fahrzeug, das mit dem fahrzeugbasierten Rechensystem 100 ausgestattet ist, kann eine visuelle Frontend-Schnittstelle 104 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann dazu in der Lage sein, mit der Schnittstelle 104 zu interagieren, falls sie bereitgestellt ist, zum Beispiel mit einem berührungsempfindlichen Bildschirm. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch das Betätigen von Schaltflächen, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
  • Bei der in 1 gezeigten veranschaulichenden Ausführungsform steuert mindestens ein Prozessor 103 mindestens einen Teil des Betriebs des fahrzeugbasierten Rechensystems 100. Der innerhalb des Fahrzeugs 131 bereitgestellte Prozessor 103 ermöglicht ein fahrzeuginternes Verarbeiten von Befehlen und Routinen. Ferner ist der Prozessor 103 sowohl mit nicht dauerhaftem 105 als auch dauerhaftem Speicher 107 verbunden. In dieser veranschaulichenden Ausführungsform handelt es sich bei dem nicht dauerhaften Speicher 105 um Direktzugriffsspeicher (random access memory - RAM) und bei dem dauerhaften Speicher 107 um ein Festplattenlaufwerk (hard disk drive - HDD) oder Flash-Speicher. Nichtflüchtiger Speicher kann sowohl dauerhaften Speicher als auch RAM beinhalten. Im Allgemeinen kann dauerhafter Speicher 107 alle Speicherformen beinhalten, die Daten aufbewahren, wenn ein Computer oder eine andere Vorrichtung heruntergefahren ist. Dazu gehören unter anderem HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und jede beliebige andere geeignete Form von dauerhaftem Speicher.
  • Der Prozessor 103 kann zudem mehrere unterschiedliche Eingänge beinhalten, die es dem Benutzer und externen Systemen ermöglichen, über eine Schnittstelle mit dem Prozessor 103 zu interagieren. Das fahrzeugbasierte Rechensystem 100 kann ein Mikrofon 129, einen Hilfseingangsanschluss 125 (für eine Eingabe 133), einen Universal-Serial-Bus-(USB-)Eingang 123, einen Eingang 124 für ein globales Positionsbestimmungssystem (GPS), einen Bildschirm 104, bei dem es sich um eine Touchscreen-Anzeige handeln kann, und einen BLUETOOTH-Eingang 115 beinhalten. Das VCS 100 kann ferner einen Eingangswähler 151 beinhalten, der dazu ausgelegt ist, es einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Eingaben von sowohl dem Mikrofon 129 als auch dem Hilfsanschluss 125 können durch einen Analog/Digital-(A/D-)Wandler 127 von analog zu digital umgewandelt werden, bevor sie an den Prozessor 103 weitergeleitet werden. Wenngleich dies nicht gezeigt ist, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS in Kommunikation stehen, ein Fahrzeugnetzwerk (wie etwa unter anderem einen Controller-Area-Network-(CAN-)Bus, einen Local-Interconnect-Network-(LIN-)Bus, einen Media-Oriented-System-Transport-(MOST-)Bus, einen Ethernet-Bus oder einen FlexRay-Bus) verwenden, um Daten an das und von dem VCS 100 (oder Komponenten davon) weiterzuleiten.
  • Ausgänge von dem Prozessor 103 können unter anderem eine visuelle Anzeige 104 und einen Lautsprecher 113 oder einen Stereosystemausgang beinhalten. Der Lautsprecher 113 kann mit einem Verstärker 111 verbunden sein und sein Signal von dem Prozessor 103 durch einen Digital/Analog-(D/A-)Wandler 109 empfangen. Ausgänge können zudem zu einer entfernten BLUETOOTH-Vorrichtung wie etwa einer persönlichen Navigationsvorrichtung (Personal Navigation Device - PND) 154 oder einer USB-Vorrichtung wie etwa einer Fahrzeugnavigationsvorrichtung 160 entlang der bei 119 bzw. 121 gezeigten bidirektionalen Datenströme erfolgen.
  • In einer veranschaulichenden Ausführungsform verwendet das System 100 den BLUETOOTH-Sendeempfänger 115 mit einer Antenne 117, um mit einer Mobilvorrichtung 153 eines Benutzers (z. B. Mobiltelefon, Smartphone, Personal Digital Assistant (PDA) oder einer beliebigen anderen Vorrichtung, die sich mit einem drahtlosen Fernnetzwerk verbinden kann) zu kommunizieren. Die Mobilvorrichtung 153 kann dann dazu verwendet werden, über einen Mast-Netzwerk-Kommunikationspfad 159 mit einem Netzwerk 161 außerhalb des Fahrzeugs 131 zum Beispiel durch einen Vorrichtung-Mast-Kommunikationspfad 155 mit einem Mobilfunkmast 157 zu kommunizieren. In einigen Ausführungsformen kann der Mast 157 ein drahtloser Ethernet- oder WLAN-Zugangspunkt sein, wie durch die Normengruppe 802.11 des Institute of Electrical and Electronics Engineers (IEEE) definiert. Eine beispielhafte Kommunikation zwischen der Mobilvorrichtung 153 und dem BLUETOOTH-Sendeempfänger 115 ist durch den Bluetooth-Signalpfad 114 dargestellt.
  • Das Koppeln der Mobilvorrichtung 153 mit dem BLUETOOTH-Sendeempfänger 115 kann durch eine Taste 152 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der bordeigene BLUETOOTH-Sendeempfänger 115 mit einem BLUETOOTH-Sendeempfänger in einer Mobilvorrichtung 153 gekoppelt wird.
  • Zwischen der CPU 103 und dem Netzwerk 161 können zum Beispiel unter Verwendung eines Datentarifs, von Daten über Sprache oder Tönen eines Mehrfrequenzwahlverfahrens (MFV), welche der Mobilvorrichtung 153 zugeordnet sind, Daten kommuniziert werden. Alternativ dazu kann es wünschenswert sein, ein bordeigenes Modem 163 einzubeziehen, das eine Antenne 118 aufweist, um einen Fahrzeug-Vorrichtung-Kommunikationspfad 116 zum Übertragen von Daten zwischen der CPU 103 und dem Netzwerk 161 über das Sprachband herzustellen. Die Mobilvorrichtung 153 kann dann dazu verwendet werden, über den Mast-Netzwerk-Kommunikationspfad 159 mit einem Netzwerk 161 außerhalb des Fahrzeugs 131 zum Beispiel durch den Vorrichtung-Mast-Kommunikationspfad 155 mit einem Mobilfunkmast 157 zu kommunizieren. In einigen Ausführungsformen kann das Modem 163 einen Fahrzeug-Mast-Kommunikationspfad 120 direkt mit dem Mast 157 herstellen, um mit dem Netzwerk 161 zu kommunizieren. Als ein nicht einschränkendes Beispiel kann es sich bei dem Modem 163 um ein USB-Mobilfunkmodem und bei dem Fahrzeug-Mast-Kommunikationspfad 120 um eine Mobilfunkkommunikation handeln.
  • In einer veranschaulichenden Ausführungsform ist der Prozessor 103 mit einem Betriebssystem versehen, das eine Schnittstelle zur Anwendungsprogrammierung (application programming interface - API) zum Kommunizieren mit einer Modemanwendungssoftware beinhaltet. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Sendeempfänger 115 zugreifen, um eine drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sendeempfänger (wie etwa demjenigen, der in einer Mobilvorrichtung 153 vorliegt) herzustellen. Bei Bluetooth handelt es sich um eine Teilmenge der Protokolle aus IEEE 802 PAN (Personal Area Network). Protokolle aus IEEE 802 LAN (Local Area Network) beinhalten WLAN und weisen eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide sind für die drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Weitere drahtlose Kommunikationsmittel, die in diesem Bereich verwendet werden können, sind optische Freiraumkommunikation (wie etwa IrDA) und nicht standardisierte Verbraucher-IR-Protokolle oder induktiv gekoppelte Mittel, einschließlich unter anderem Nahfeldkommunikationssysteme wie etwa RFID.
  • In einer anderen Ausführungsform beinhaltet die Mobilvorrichtung 153 ein Modem zur Sprachband- oder Breitbanddatenkommunikation. In der Daten-über-Sprache-Ausführungsform kann eine Technik umgesetzt werden, die als Frequenzmultiplexverfahren bekannt ist, wenn der Besitzer der Mobilvorrichtung über die Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeitpunkten, wenn der Besitzer die Vorrichtung nicht verwendet, kann die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) für die Datenübertragung verwendet werden. Wenngleich das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet geläufig sein kann und nach wie vor verwendet wird, wurde es weitgehend durch Hybride aus Codemultiplexverfahren (Code Division Multiple Access - CDMA), Zeitmultiplexverfahren (Time Division Multiple Access - TDMA), Raummultiplexverfahren (Space-Division Multiple Access - SDMA) zur digitalen Mobilfunkkommunikation ersetzt, wozu unter anderem das orthogonale Frequenzmultiplexverfahren (Orthogonal Frequency-Division Multiple Access - OFDMA) gehört, das ein statistisches Multiplexen im Zeitbereich beinhalten kann. Bei allen davon handelt es sich um mit dem internationalen Mobiltelekommunikationsstandard (International Mobile Telecommunication - IMT) 2000 (3G) der Internationalen Fernmeldeunion (International Telegraph Union - ITU) konforme Standards, die Datenraten von bis zu 2 MBit/s für stillstehende oder gehende Benutzer und 385 kBit/s für Benutzer in einem sich bewegenden Fahrzeug bieten. 3G-Standards werden derzeit durch IMT-Advanced (4G) ersetzt, das 100 MBit/s für Benutzer in einem Fahrzeug und 1 GBit/s für stillstehende Benutzer bietet. Falls der Benutzer über einen der Mobilvorrichtung 153 zugeordneten Datentarif verfügt, ist es möglich, dass der Datentarif eine Breitbandübertragung ermöglicht und das System eine viel größere Bandbreite verwenden könnte (was die Datenübertragungsgeschwindigkeit erhöht). In noch einer anderen Ausführungsform wird die Mobilvorrichtung 153 durch eine Mobilfunkkommunikationsvorrichtung (nicht gezeigt) ersetzt, die in dem Fahrzeug 131 verbaut ist. In wieder einer anderen Ausführungsform kann die Mobilvorrichtung 153 eine Vorrichtung eines drahtlosen lokalen Netzwerks (LAN) sein, die dazu in der Lage ist, zum Beispiel (und unter anderem) über ein IEEE-802.11g-Netzwerk (d.h. WLAN) oder ein WiMax-Netzwerk zu kommunizieren.
  • In einer Ausführungsform können eingehende Daten über Daten über Sprache oder einen Datentarif durch die Mobilvorrichtung 153, durch den bordeigenen BLUETOOTH-Sendeempfänger 115 und an den internen Prozessor 103 des Fahrzeugs weitergeleitet werden. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf dem HDD oder einem anderen Speichermedium 107 gespeichert werden, bis die Daten nicht mehr benötigt werden.
  • Weitere Quellen, die eine Schnittstelle mit dem fahrzeugbasierten Rechensystem 100 aufweisen können, beinhalten Folgende: eine persönliche Navigationsvorrichtung 154, die zum Beispiel einen USB-Anschluss 156 und/oder eine Antenne 158 aufweist, eine Fahrzeugnavigationsvorrichtung 160, die einen USB-Anschluss 162 oder anderen Anschluss aufweist, eine fahrzeuginterne GPS-Vorrichtung 124 oder ein entferntes Navigationssystem (nicht gezeigt), das eine Verbindung mit dem Netzwerk 161 aufweist. Bei USB handelt es sich um eines einer Klasse serieller Netzwerkprotokolle. Die seriellen Protokolle IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Vorrichtung-zu-Vorrichtung-Standards. Die Mehrheit der Protokolle kann entweder für die elektrische oder die optische Kommunikation umgesetzt werden.
  • Ferner kann die CPU 103 mit einer Vielzahl von anderen Hilfsvorrichtungen 165 in Kommunikation stehen. Die Hilfsvorrichtungen 165 können durch eine drahtlose (z. B. über eine Hilfsvorrichtungsantenne 167) oder drahtgebundene (z. B. Hilfsvorrichtungs-USB 169) Verbindung verbunden sein. Zu den Hilfsvorrichtungen 165 können u. a. persönliche Medienwiedergabevorrichtungen, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen gehören.
  • Darüber hinaus oder alternativ kann die CPU 103 mit einem fahrzeugbasierten drahtlosen Router 173, z. B. unter Verwendung eines WLAN-Sendeempfängers / einer Antenne 171 (gemäß IEEE 802.11), verbunden sein. Dies kann es der CPU 103 ermöglichen, sich mit entfernten Netzwerken in Reichweite des lokalen Routers 173 zu verbinden. In einigen Konfigurationen können der Router 173 und das Modem 163 als eine integrierte Einheit kombiniert sein. Hier beschriebene Merkmale können jedoch auf Konfigurationen anwendbar sein, bei denen die Module getrennt oder integriert sind.
  • Neben der Ausführung beispielhafter Prozesse durch ein Fahrzeugrechensystem, das in einem Fahrzeug angeordnet ist, können die beispielhaften Prozesse in bestimmten Ausführungsformen durch ein Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Kommunikation steht. Ein derartiges System kann unter anderem eine drahtlose Vorrichtung (z. B. unter anderem ein Mobiltelefon) oder ein Remote-Rechensystem (z. B. unter anderem einen Server) einschließen, die über die drahtlose Vorrichtung verbunden sind. Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Rechensysteme (vehicle associated computing systems - VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS in Abhängigkeit von der konkreten Umsetzung des Systems bestimmte Teile eines Prozesses durchführen. Falls ein Prozess beispielsweise unter anderem einen Schritt zum Senden oder Empfangen von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, ist es wahrscheinlich, dass die drahtlose Vorrichtung den Prozess nicht durchführt, da die drahtlose Vorrichtung Informationen nicht mit sich selbst „senden und empfangen“ würde. Der Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes VACS auf eine jeweilige Lösung anzuwenden. Bei allen Lösungen wird in Erwägung gezogen, dass mindestens das innerhalb des Fahrzeugs selbst angeordnete Fahrzeugrechensystem (VCS) dazu in der Lage ist, die beispielhaften Prozesse durchzuführen.
  • Das fahrzeugbasierte Rechensystem 100 kann als Gateway zwischen externen Netzwerken (z. B. 161) und einem internen Fahrzeugnetzwerk fungieren. 2 bildet ein mögliches Diagramm für eine dezentralisierte Architektur zum Verbinden mehrerer Steuerungen in dem Fahrzeug 131 ab. Fahrzeugsysteme können eine beliebige Anzahl von Steuerung beinhalten. Der Steuerung kann dazu programmiert sein, verschiedene Dienste umzusetzen. Ein Dienst kann in Hardware/Firmware umgesetzt sein, um einen bestimmten Satz von Vorgängen in Bezug auf ein Merkmal oder eine Funktion durchzuführen. Zum Beispiel können Dienste umgesetzt sein, um Türen zu verriegeln und zu entriegeln, ein bestimmtes Sensorsignal zu messen und zu übertragen oder eine Diagnoseanforderung durchzuführen. Dienste können regelmäßig für Echtzeitvorgänge ausgelöst werden. Dienste können auf Anforderung ausgelöst werden, wenn eine externe Diagnoseanforderung empfangen wird oder eine andere, durch den Benutzer eingeleitete Funktion durchgeführt werden soll. Dienste können als einzelne Routine in einer einzelnen Steuerung umgesetzt werden oder können als mehrere Routinen in mehreren Steuerungen umgesetzt werden.
  • Eine dezentralisierte Architektur ist für Steuerdienste, wie etwa diejenigen, die in einem Fahrzeug umgesetzt werden, vorteilhaft. Sie vermeidet den Engpass eines einzelnen zentralen Orchestrators und stellt sicher, dass nicht alle Dienste aufhören zu funktionieren, wenn der Orchestrator ausfällt. Eine verteilte Architektur ist außerdem im Hinblick auf eine Optimierung vorteilhaft, da die Menge der übertragenen Daten häufig reduziert werden kann, indem die datenverbrauchende Steuerlogik in der Nähe der Datenerzeuger platziert wird. Des Weiteren können jederzeit neue Dienste mit bisher unbekannter Funktionalität hinzugefügt werden. Um diese Dynamik zu unterstützen, kann eine Steuerung ein Repository der verfügbaren Dienste in dem Netzwerk und eine Protokollierungseinrichtung, die das Nachverfolgen von Änderungen ermöglicht, verwalten und bereitstellen. Da neue Anwendungen während der Laufzeit installiert werden können, ist der Zweck einzelner Dienste in dem Netzwerk nicht festgelegt und kann während der Lebensdauer des Netzwerks geändert werden. Dies erfordert ein dediziertes Lebenszyklus-Management, das die Installation, den Start, das Herunterfahren und das Entfernen von Diensten in den mit dem Netzwerk verbundenen Steuerungen unterstützt.
  • Dienste können auf Vorrichtungen mit begrenzten Speicher- und Verarbeitungskapazitäten ausgeführt werden und können von effizienten Nachrichtenformaten für die Kommunikation zwischen diesen Vorrichtungen profitieren. Effiziente Kommunikation kann erreicht werden, indem eine klare Trennung zwischen der Beschreibung der Daten, die nur einmal vorgegeben wird, und dem Übertragungsformat, das nur die Rohdatennutzlast in einer binären Darstellung enthält, definiert wird. Darüber hinaus können Dienste und Software auf effiziente Weise ausgestaltet sein, um die Ausführung auf Vorrichtungen mit beschränkten Ressourcen zu ermöglichen. In derartigen Systemen ist ein minimaler Kommunikationsaufwand gewünscht. Dienste können aus einer Vielzahl von Dienstroutinen bestehen, die in einer Vielzahl von Steuerungen, die an das Netzwerk gekoppelt sind, ausgeführt werden. Intelligente Verteilung der Dienstroutinen unter den Steuerungen kann die Netzwerkbandbreite, die für das Übertragen von Daten zwischen den Steuerungen erforderlich ist, reduzieren.
  • Da der Bedarf an Konnektivität und Cloud-Kommunikation in Fahrzeuganwendungen zunimmt, muss sich das eingebettete Fahrzeugnetzwerk weiterentwickeln, um eine Vielzahl von Steuerungen auf Grundlage verschiedener Plattformen (z. B. Betriebssysteme, Programmiersprachen usw.) zu beinhalten. Eine weitere Herausforderung besteht darin, dass jede Steuerung von einem anderen Anbieter unter Verwendung unterschiedlicher Plattformen ausgestaltet und entwickelt werden kann. Demzufolge sollte die Software anbieterunabhängige, interoperable, plattformübergreifende Lösungen unterstützen. Eine beliebige Softwarelösung sollte Interoperabilität und Datenaustausch zwischen verschiedenen Produkten oder Diensten, die für einen weitreichenden Einsatz vorgesehen sind, ermöglichen.
  • Steuerdienste, die auf Fahrzeugnetzwerken ausgeführt werden, können datengetrieben sein. In einer datengetriebenen Umgebung können Daten regelmäßig von den Sensoren erfasst werden und an verbundene Dienste, die in den Steuerungen ausgeführt werden, übertragen werden. Diese Dienste können auf Grundlage der empfangenen Eingabe neue Daten erzeugen, die dann an den nächsten Dienst in der Verarbeitungskette übertragen werden können. Steuerdienste, die auf Fahrzeugnetzwerken ausgeführt werden, können auch steuerungsgetrieben sein. In einer steuerungsgetriebenen Umgebung können Client-Anwendungen mit Diensten über abstrakte Vorrichtungsinteraktionen interagieren. Dienste können dann wiederum die Vorrichtungen steuern (z. B. kann ein Dienst hintere Fenster öffnen/schließen, indem er auf Anforderung durch Client-Routinen einen Befehl ausgibt). Generische Befehle können definiert werden und Steuerdienste können umgesetzt werden, um die generischen Befehle durchzuführen. Der Benutzer oder Dienst auf hoher Ebene kann unter Verwendung der generischen Befehle kommunizieren, ohne konkret zu wissen, wie oder in welcher/welchen Steuerung(en) der generische Befehl umgesetzt wird. Zum Beispiel kann die Schnittstelle aus Vorgängen vom Typ des Hyper Text Transfer Protocol (HTTP), wie etwa GET, POST, PUT und DELETE bestehen.
  • Fahrzeugnetzwerke arbeiten nicht isoliert und sind häufig dazu ausgelegt, auf Weitverkehrsnetzwerke und/oder das Internet zuzugreifen. Webdienstbasierte Schnittstellen können umgesetzt werden, um Netzwerke und externe Komponenten zu integrieren. Die Herausforderung besteht darin, die Webdienstdomäne mit ihrem hohen Ressourcenbedarf und ihren hochverfügbaren Komponenten mit der Fahrzeugnetzwerkdomäne mit ihren Knoten mit geringem Ressourcenbedarf zu verbinden. Webdienstschnittstellen allein sind für die Integration von Fahrzeugnetzwerken mit Unternehmens-Backends (z. B. in einem Szenario einer Integration in einer Produktionsstätte) nicht ausreichend. Darüber hinaus können die von dem Sensornetzwerk gelieferten Daten in die Wissensdomäne des Unternehmens integriert werden. Dies kann semantische Informationen beinhalten, die das Kombinieren der Messdaten mit den in den Backend-Datenbanken enthaltenen Informationen ermöglichen. Ein Fahrzeugnetzwerk kann außerdem Sicherheitsprobleme angehen. Sicherheitsmerkmale in dem Fahrzeugnetzwerk können Integrität, Authentifizierung und Vertraulichkeit beinhalten. Die Ausgestaltung der Softwarelösung kann Mechanismen bereitstellen, um die vorstehend genannten Sicherheitsmerkmale anzugehen und umzusetzen.
  • Unter Bezugnahme auf 2 kann das Fahrzeug 131 eine Gateway-Steuerung 204 beinhalten. Die Gateway-Steuerung 204 kann Merkmale und Funktionalität wie in Bezug auf das fahrzeugbasierte Rechensystem 100 aus 1 beschrieben beinhalten. Die Gateway-Steuerung 204 kann dazu ausgelegt sein, zwischen dem externen Netzwerk 161 und dem internen Fahrzeugnetzwerk (durch einen Netzwerk-Switch 206 dargestellt) zu kommunizieren.
  • Das Fahrzeug 131 kann eine Vielzahl von Steuerungen oder elektronischen Steuereinheiten (electronic control units - ECU) beinhalten. Zum Beispiel kann das Fahrzeug 131 eine erste Steuerung 208 beinhalten, die an einen ersten Satz 210 von Sensoren und Aktoren gekoppelt ist. Das Fahrzeug 131 kann eine zweite Steuerung 212 beinhalten, die an einen zweiten Satz 214 von Sensoren und Aktoren gekoppelt ist. Das Fahrzeug 131 kann eine dritte Steuerung 216 beinhalten, die an einen dritten Satz 218 von Sensoren und Aktoren gekoppelt ist. Das Fahrzeug 131 kann eine vierte Steuerung 220 beinhalten, die an einen vierten Satz 222 von Sensoren und Aktoren gekoppelt ist. Die Steuerungen (208, 212, 216, 220) und die Gateway-Steuerung 204 können einen Prozessor und flüchtigen und nichtflüchtigen Speicher beinhalten. Die Steuerungen (208, 212, 216, 220) können ferner eine Schnittstellenschaltung zum Verbinden des zugeordneten Satzes von Sensoren und Aktoren beinhalten. Die Sensoren können dazu ausgelegt sein, Rückkopplungssignale zum Betreiben verschiedener Fahrzeugmerkmale bereitzustellen. Die Aktoren können dazu ausgelegt sein, verschiedene Fahrzeugmerkmale zu betreiben. Es ist zu beachten, dass weitere Steuerung ohne Einschränkung vorhanden sein können.
  • Die Steuerungen (208, 212, 216, 220) können an ein internes Fahrzeugnetzwerk gekoppelt sein. Das interne Fahrzeugnetzwerk kann einen Netzwerk-Switch 206 beinhalten. Der Netzwerk-Switch 206 kann dazu ausgelegt sein, Daten und Nachrichten zwischen Steuerungen, einschließlich der Gateway-Steuerung 204, in dem Fahrzeug 131 zu leiten. Bei dem Fahrzeugnetzwerk kann es sich um ein Ethernet-Netzwerk (IEEE 802) handeln. Die Steuerungen (208, 212, 216, 220) können jeweils mit Hardware- und Softwarekomponenten ausgelegt sein, um eine Schnittstelle mit dem Fahrzeugnetzwerk zu bilden.
  • Die Steuerungen (208, 212, 216, 220) können dazu programmiert sein, konkrete Dienste umzusetzen. Um einen Dienst durchzuführen, können Signale von einer oder mehreren der anderen Steuerungen gewünscht sein. Die Steuerungen (208, 212, 216, 220) können Signale über das interne Fahrzeugnetzwerk übertragen. Herkömmliche Fahrzeugsteuerungsnetzwerke sind statisch angeordnet, sodass die Dienste einer vorbestimmten Steuerung statisch zugewiesen werden. Derartige Konfigurationen werden im Allgemeinen während der Fahrzeugausgestaltungsphase vorbestimmt und bleiben über die Lebensdauer des Fahrzeugs konstant. Derartige Ausgestaltungen handhaben das Hinzufügen von Merkmalen und Funktionen nachdem das Fahrzeug produziert und verkauft wurde nicht effizient. Da sich die Fahrzeugtechnologie erweitert, um autonome Fahrzeuge einzuschließen und die Konnektivität zwischen Fahrzeugen und Infrastruktur zu erhöhen, können derartige statische Ausgestaltungen nicht Schritt halten. Ein dynamischerer Ansatz kann zu Fahrzeugen mit einer längeren Nutzungsdauer und einer erhöhten Kundenzufriedenheit führen.
  • Dienste stellen ein höheres Abstraktionsniveau bereit, das die Umsetzungsdetails der Hardwarevorrichtungen von dem Entwickler sicher verbirgt. Neu hinzugefügte Dienste können automatisch erkannt werden und automatisch/halbautomatisch in bestehende Anwendungen integriert werden oder verwendet werden, um neue Anwendungen aufzubauen. Die Aufspaltung von Diensten in lose gekoppelte Softwaremodule stellt hohe Flexibilität, Wiederverwendbarkeit, und Erweiterbarkeit bereit und vereinfacht gleichzeitig die Koexistenz verschiedener Anwendungen. Ein weiterer Vorteil ist die Möglichkeit der Integration von Diensten von verschiedenen Hardware- und Softwareanbietern auf nahtlose Weise. Des Weiteren ist das Fachwissen aufgrund des hohen Abstraktionsniveaus ausreichend, um die Funktionalität von Diensten zu verstehen und Dienste in dem Netzwerk zu installieren und zu konfigurieren/neu zu konfigurieren.
  • Jeder der Sensoren und Aktoren kann eine zugeordnete Dienstroutine aufweisen, die in der zugeordneten Steuerung umgesetzt ist. Bei der Dienstroutine kann es sich um ein Programm oder eine Anwendung handeln, das/die dazu ausgelegt ist, eine Schnittstelle für den zugeordneten Sensor oder Aktor bereitzustellen. Die Dienstroutine kann als Server für den Sensor/Aktor bezeichnet werden. Die Dienstroutine kann dazu ausgelegt sein, die Sensoreingabe zu verarbeiten und dem Fahrzeugnetzwerk das/die entsprechende(n) Signal(e) bereitzustellen. Die Dienstroutine kann dazu ausgelegt sein, Signale, einschließlich Anforderungen, die Aktoren zu betreiben, zu empfangen und den Aktoren Signale bereitzustellen, um den angeforderten Betrieb zu erreichen. Die Steuerungen können dazu programmiert sein, bei Initialisierung oder auf Anforderung eine Liste der verfügbaren Dienste über das interne Netzwerk zu übertragen. Die verfügbaren Dienste können in dem Repository zusammen mit Daten, die die Steuerung, in der der Dienst umgesetzt wird, identifizieren, aufgelistet sein.
  • Es ist zu beachten, dass jede Steuerung mit einer Vielzahl von Dienstroutinen programmiert sein kann. Des Weiteren kann es verschiedene Ebenen von Dienstroutinen geben. Zum Beispiel kann eine Dienstroutine auf hoher Ebene eine Schnittstelle mit einer Anzahl von Dienstroutinen auf niedriger Ebene bilden, um eine Funktion durchzuführen. Darüber hinaus können einige Steuerungen Dienstroutinen umsetzen, die eine Schnittstelle mit Dienstroutinen in anderen Steuerungen bilden. Die Architektur kann als verteilte Rechenumgebung beschrieben werden. Die Dienstroutinen können Schnittstellen zum Kommunizieren über das Fahrzeugnetzwerk beinhalten.
  • Jede der Steuerungen (208, 212, 216, 220) kann ein Echtzeit-Betriebssystem umsetzen, das eine effiziente Verwaltung der Dienste ermöglicht. Das Betriebssystem kann dazu ausgelegt sein, die Installation von Dienstroutinen, das Entfernen von Dienstroutinen, das Starten von Dienstroutinen oder das Anhalten von Dienstroutinen zu ermöglichen. Das Echtzeit-Betriebssystem kann die Dienstroutinen (z. B. Aufgaben), die der Steuerung zugewiesen sind, verwalten und koordinieren. Zum Beispiel kann das Echtzeit-Betriebssystem die regelmäßige Ausführung von Dienstroutinen, die regelmäßig ausgeführt werden, auslösen.
  • 3 stellt ein Beispiel einer verteilten eingebetteten dienstorientierten Architektur für ein Fahrzeug dar. Eine Gateway-Steuerung 204 kann mit einer Dienst-Manager-Anwendung 320 programmiert sein. Die Dienst-Manager-Anwendung 320 kann dazu ausgelegt sein, die Dienstroutinen, die in den Steuerungen vorhanden sind, zu verwalten. Die Dienst-Manager-Anwendung, die in der verteilten Rechenumgebung verfügbar sind, können mit der Dienst-Manager-Anwendung 320 registriert sein. Die Dienst-Manager-Anwendung 320 kann dazu programmiert sein, ein Repository oder eine Datenbank der verfügbaren Dienste und Dienstroutinen zu speichern und die Datenbank zur weiteren Verwendung in nichtflüchtigem Speicher speichern.
  • Die Dienst-Manager-Anwendung 320 kann ferner dazu ausgelegt sein, die Dienste, die in dem Fahrzeug verteilt sind, zu überwachen. Die Dienst-Manager-Anwendung 320 kann ein Dienstregister führen, das den Status jedes Diensts und/oder jeder Dienstroutine beinhaltet. Das Dienstregister kann Dienstversionsinformationen, Dienstkompatibilitätsinformationen, eine Berechtigungsliste für jeden Dienst und Dienststatistiken beinhalten. Die Dienst-Manager-Anwendung 320 kann für das Starten, Anhalten und Zurücksetzen der Dienste, die in dem Fahrzeug vorhanden sind, zuständig sein. Zum Beispiel kann der Dienst-Manager 320 eine Schnittstelle mit dem Betriebssystem bilden, um Befehle zum Starten und Anhalten der Dienstroutinen in den Steuerungen bereitzustellen. Jede Steuerung kann Informationen von den zugewiesenen Diensten erfassen und die Dienstinformationen über das Ethernet-Netzwerk des Fahrzeugs an den Dienst-Manager 320 übertragen.
  • Die Dienst-Manager-Anwendung 320 kann außerdem die von den Dienstroutinen genutzten Ressourcen überwachen. Zum Beispiel kann der Dienst-Manager 320 eine Liste der Routinen auf niedriger Ebene, die von jeder der Dienstroutinen verwendet werden, führen. Die Dienst-Manager-Anwendung 320 kann eine zugeordnete Dienststatistik für jede der Dienstroutinen führen. Dienststatistiken können von den Dienstroutinen, die in den Steuerungen ausgeführt werden, empfangen werden.
  • Die Gateway-Steuerung 204 kann ferner mit einer ersten Dienstanwendung 322 (z. B. Fahrzeuganwendung X) und einer zweiten Dienstanwendung 324 (z. B. Fahrzeuganwendung Y) programmiert sein. Die erste Dienstanwendung 322 und die zweite Dienstanwendung 324 können dazu ausgelegt sein, einen bestimmten Dienst oder ein bestimmtes Merkmal, der/das in mehreren Steuerungen umgesetzt ist, zu koordinieren.
  • Die erste Steuerung 208 kann dazu ausgelegt sein, eine Dienstroutine 326 (z. B. Fahrzeugdienst X1) umzusetzen, die der ersten Dienstanwendung 322 zugeordnet ist. Die erste Steuerung 208 kann dazu ausgelegt sein, eine Dienstroutine 328 (z. B. Fahrzeugdienst Y2) umzusetzen, die der zweiten Dienstanwendung 324 zugeordnet ist. Die zweite Steuerung 212 kann dazu ausgelegt sein, eine Dienstroutine 330 (z. B. Fahrzeugdienst X2) umzusetzen, die der ersten Dienstanwendung 322 zugeordnet ist. Die zweite Steuerung 212 kann dazu ausgelegt sein, eine Dienstroutine 332 (z. B. Fahrzeugdienst Y1) umzusetzen, die der zweiten Dienstanwendung 324 zugeordnet ist. Die dritte Steuerung 216 kann dazu ausgelegt sein, eine Dienstroutine 334 (z. B. Fahrzeugdienst X3) umzusetzen, die der ersten Dienstanwendung 322 zugeordnet ist. Es ist zu beachten, dass weitere Steuerung ohne weitere Dienstroutinen vorhanden sein können.
  • Die erste Steuerung 208, die zweite Steuerung 212 und die dritte Steuerung 216 können dazu ausgelegt sein, über das Fahrzeugnetzwerk zu kommunizieren. Jede der Dienstroutinen kann dazu ausgelegt sein, eine Schnittstelle mit Fahrzeugnetzwerktreibern zu bilden, um Signale über das Fahrzeugnetzwerk zu kommunizieren. Bei dem Fahrzeugnetzwerk kann es sich um ein Ethernet-Netzwerk handeln. Durch die Steuerungen ausgetauschte Nachrichten und Signale können einem definierten Protokoll entsprechen.
  • Jede der Steuerungen kann an ein oder mehrere Ethernet-Netzwerke in dem Fahrzeug gekoppelt sein. Die Gateway-Steuerung 204 kann dazu ausgelegt sein, eine Schnittstelle mit einem externen Netzwerk 161 zu bilden. Zum Beispiel kann die Gateway-Steuerung 204 dazu ausgelegt sein, eine drahtlose Schnittstelle zu einem entfernten Netzwerk über ein Mobilfunknetzwerk oder eine drahtlose Ethernet-Verbindung zu bilden. Die Kommunikation zu dem entfernten Netzwerk kann ein (HTTP) über Transmission Control Protocol (TCP) verwenden.
  • Zum Kommunizieren über ein Ethernet-Netzwerk ist eine Vielfalt von Protokollen verfügbar. Einige Anwendungen können TCP verwenden, um über das Netzwerk zu kommunizieren. TCP beinhaltet Merkmale, die sichere und fehlerfreie Übertragung von Daten über das Netzwerk sicherstellen. Das TCP definiert, wie Daten über das Netzwerk transportiert werden. Das Fahrzeugkommunikationssystem kann HTTP verwenden, um Informationen zwischen Systemen zu übertragen. Das HTTP definiert, wie die Daten für die Übertragung über das Netzwerk verpackt und angeordnet werden. Das HTTP definiert, wie Anforderungen von Daten und Antworten gehandhabt werden. Die TCP-Umsetzungen erfordern im Allgemeinen mehr Speicher- und Verarbeitungsressourcen als in eingebetteten Steuerungen verfügbar sein können. Zum Beispiel erfordert TCP, dass Verbindungen in einem mehrstufigen Handshake-Prozess hergestellt werden, bevor Nachrichten ausgetauscht werden. Dies erhöht die Start- und Kommunikationszeiten. Außerdem können bei TCP die beiden kommunizierenden Konten bei einer anhaltenden Sitzung ihre TCP-Sockets ständig füreinander geöffnet halten, was bei Vorrichtungen mit beschränkten Ressourcen schwierig zu erreichen sein kann. TCP-Takte können ein zusätzlicher Overhead für Vorrichtungen mit beschränkten Ressourcen sein. Infolgedessen kann TCP für Echtzeitsysteme, bei denen schnelle Antworten bevorzugt sind, nicht optimal sein.
  • Bei eingebetteten Anwendungen, wie etwa einem Fahrzeug, ein ressourceneffizienteres Protokoll bevorzugt sein. Ein derartiges Protokoll ist das Constrained Application Protocol (CoAP). CoAP ist auf eingebettete System- und Internet-of-Things-(IoT-)Anwendungen ausgelegt. CoAP kann durch Request For Comments (RFC) 7252 und zugehörige Dokumente, die von der Internet Engineering Task Force (IETF) veröffentlicht wurden, definiert werden. CoAP-basierte Systeme können weniger Speicher- und Verarbeitungsressourcen als TCPbasierte Systeme erfordern. Eine eingebettete Steuerung, die CoAP umsetzt, kann unter Verwendung eines User Datagram Protocol (UDP) kommunizieren. Das UDP ist eine Alternative zu dem TCP. Das UDP ist dazu ausgestaltet, um Datenpakete zu senden, ohne Prüfungen bereitzustellen, um sicherzustellen, dass Pakete nicht verloren gehen oder nicht ordnungsgemäß empfangen werden. Im Gegensatz dazu überprüft TCP auf verlorene Pakete und sendet diese erneut, was Overhead und Latenz erhöht. Demzufolge kann UDP ein besser geeignetes Protokoll für eingebettete Echtzeitanwendungen sein.
  • Die Anforderungen für die internetbasierten Kommunikationen und die Fahrzeugnetzwerkkommunikation sind nicht gleich. Bei vielen Fahrzeuganwendungen kann ein sehr kurzes Timeout gewünscht sein, um in einer sehr kurzen Zeit zu reagieren oder zu antworten. Derartige Merkmale können unter Verwendung von UDP eingehalten werden, da die Anwendung selbst dazu ausgelegt werden kann, den unwahrscheinlichen Fall von Fehlern zu handhaben. Zum Beispiel kann bei Anwendungsfällen mit zyklischen Daten der bevorzugte Ansatz darin bestehen, die nächste Datenübertragung abzuwarten anstatt zu versuchen, die vorherige zu reparieren. Ein Nachteil von UDP besteht darin, dass es keine Segmentierung handhabt und nur kleinere Datenpakete transportieren kann. Die Softwarelösung kann UDP unterstützen und Segmentierung auf der Anwendungsschicht handhaben. Aktuelle Transportprotokolle für CAN und FlexRay beschränken Nachrichten auf 4095 Bytes.
  • CoAP über UDP mit zugeordneten Service-Discovery-Mechanismen unterstützen eine verteilte und rekonfigurierbare Netzwerkarchitektur. Fahrzeugnetzwerke können sich im Laufe der Zeit ändern, indem neue Dienste hinzugefügt und/oder vorhandene Dienste entfernt werden. Die dienstorientierte Architektur-(service oriented architecture - SOA-)CoAP-Plattform unterstützt diese dynamischen Netzwerke, indem sie einen Erkennungsmechanismus für neue Dienste bereitstellt. Beim Erkennen eines neuen Diensts kann die automatische/halbautomatische Dienstzusammensetzung verwendet werden, um eine schnelle Integration des neuen Diensts mit den laufenden Anwendungen bereitzustellen.
  • CoAP ist schnell und effizient, da sie sich auf UDP mit geringem Overhead stützt. UDP ist grundsätzlich und absichtlich weniger zuverlässig als TCP und seine Zuverlässigkeit hängt von wiederholter Nachrichtenübermittlung anstatt von konstanten Verbindungen ab. TCP ist bei zwei kommunizierenden Konten ideal, um bei einer anhaltenden Sitzung ihre TCP-Sockets ständig füreinander geöffnet zu halten, was bei Vorrichtungen mit beschränkten Ressourcen schwierig sein kann.
  • Die Zuverlässigkeit von CoAP beruht auf Quality of Service (QoS). Dies stellt ein einfaches Verfahren zum Bereitstellen bestätigbarer und nicht bestätigbarer Nachrichten bereit. Die bestätigbare Nachricht kann mit einer Bestätigungsnachricht (ACK) von dem beabsichtigten Empfänger bestätigt werden. Dies bestätigt, dass die Nachricht empfangen wurde, bestätigt aber nicht, dass die Nachrichteninhalte korrekt oder überhaupt decodiert wurden. Eine nicht bestätigbare Nachricht wird lediglich gesendet und vergessen. Bei einem eingebetteten Fahrzeugsystem befindet sich das Fahrzeugnetzwerk im Allgemeinen in einer geschlossenen Umgebung und in der Nähe des Fahrzeugs.
  • CoAP kann verschiedene Arten von Datennutzlasten übermitteln und kann identifizieren, welche Nutzlastart verwendet wird. CoAP kann mit Extensible Markup Language (XML), JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR) oder einem beliebigen Datenformat integriert werden. CoAP weist einen festen 4-Byte-Header auf, und eine kompakte Codierung von Optionen ermöglicht kleine Nachrichten, die eine geringe oder keine Fragmentierung der Verbindungsschicht bewirken.
  • Ein CoAP-Netzwerk ist grundsätzlich Eins-zu-Eins. Es unterstützt jedoch auch Eins-zu-Viele- oder Viele-zu-Viele Multicast-Nachrichtenübermittlung. Dies liegt in der Natur von CoAP, da es auf Internet Protocol Version 6 (IPv6) aufgebaut ist, welches Multicast-Adressierung für Vorrichtungen zusätzlich zu ihren normalen IPv6-Adressen ermöglicht. CoAP ist als Anwendungsschichtprotokoll über der Internet-Protocol-(IP-)Schicht aufgebaut. Somit arbeitet CoAP unabhängig von der IP-Version. Mit CoAP aufgebaute Dienste sind portabel und können zu IPV6 migriert werden. CoAP unterstützt sowohl ein anforderungs- als auch ein antwortbasiertes Interaktionsmodell durch einen Representational-State-Transfer-(REST-)Architekturstil. Darüber hinaus unterstützt ein Beobachter-Interaktionsmodell ein Publish-Subscribe-(z. B. pub/sub-)basiertes Interaktionsmodell.
  • CoAP ist von kleinen, eingebetteten Mikrocontrollern zu High-End-Mikroprozessoren portabel. CoAP ist ein Anwendungsprotokoll und kann auf vielen Betriebssystemen (OS) ausgeführt werden. Mehrere Sprachimplementierungen sind verfügbar, um plattformübergreifende Integration/Interoperabilität zu unterstützen. Es gibt viele CoAP-Protokoll-Implementierungen. CoAP wurde als Internet-Standard-Dokument RFC 7252 entwickelt. CoAP ist dazu ausgestaltet, mit HTTP und dem RESTful Web über einfache Proxys zu interagieren, wodurch es nativ kompatible mit dem Internet ist. CoAP verwendet Datagram Transport Layer Security (DTLS) auf dem UDP-Transportprotokoll. DTLS ist ein komplettes Sicherheitsprotokoll, das Authentifizierung und Schlüsselaustausch durchführen kann und Anwendungsdaten mit dem ausgehandelten Schlüsselmaterial und Algorithmen schützen kann. CoAP-Endpunkte können durch Bandbreite und Verarbeitungsleistung eingeschränkt sein. Um die Leistung der Datenübertragung unter diesen Einschränkungen zu optimieren, verwendet CoAP Caching-Merkmale, die mit HTTP übereinstimmen.
  • Dienstchoreografie ist eine Form von Dienstzusammensetzung, bei der sich das Interaktionsprotokoll zwischen verschiedenen Partnerdiensten ohne einen einzelnen Steuerungspunkt befindet. Dienstorchestrierung ist eine Form von Dienstzusammensetzung, bei der die Beziehung zwischen allen teilnehmenden Diensten durch einen einzelnen Endpunkt (d. h. den zusammengesetzten Dienst) beschrieben werden kann. Die Orchestrierung beinhaltet die Verwaltung von Transaktionen zwischen einzelnen Diensten. Orchestrierung setzt einen zentralisierten Ansatz für die Dienstzusammensetzung ein. Unter Verwendung von CoAP können beide Formen von Dienstzusammensetzung realisiert werden. Unter Verwendung eines Client-Server-Musters kann ein zentralisierter Orchestrator die Geschäftslogik umsetzen, um sich mit anderen Diensten zu koordinieren, um einen Bedarf zu realisieren.
  • Ein Fahrzeugkommunikationssystem kann derart ausgelegt sein, dass das Fahrzeugnetzwerk das CoAP umsetzt. Die Kommunikation über das Fahrzeugnetzwerk kann CoAP verwenden. Die Gateway-Steuerung 204 kann CoAP zum Bilden einer Schnittstelle mit den Steuerungen, die mit dem Fahrzeugnetzwerk verbunden sind, umsetzen. Mit dem Fahrzeugnetzwerk verbundene Steuerungen können außerdem CoAP umsetzen, um mit der Gateway-Steuerung 204 zu kommunizieren. Die Gateway-Steuerung 204 kann außerdem dazu ausgelegt sein, mit dem externen Netzwerk 161 unter Verwendung von HTTP zu kommunizieren. Die Gateway-Steuerung 204 kann dazu ausgelegt sein, zwischen HTTP und CoAP zu übersetzen, um Kommunikation zwischen dem externen Netzwerk 161 und dem Fahrzeugnetzwerk 206 zu ermöglichen.
  • Die Fahrzeugdienstroutinen können als CoAP-Client umgesetzt sein. Jede der Fahrzeugdienstroutinen kann Kindprozesse oder -dienste, die in der gleichen Steuerung umgesetzt sind, verwalten und koordinieren. Die Fahrzeugdienstroutinen (z. B. CoAP-Clients) können Daten unter Verwendung von UDP-Datagram-Paketen ohne Verwendung von TCP/IP-Verbindungen über das Fahrzeugnetzwerk austauschen. Die Datenkommunikation zwischen den Elementen kann einem Peer-to-Peer-Kommunikationsprotokoll folgen.
  • Dienststatistiken und/oder Leistungsparameter können von den Steuerungen erfasst werden und an den Dienst-Manager 320 gemeldet werden. Der Dienst-Manager 320 kann die Dienststatistiken an einen externen Server, der mit dem externen Netzwerk 161 verbunden ist, unter Verwendung eines etablierten HTTP-CoAP-Proxys melden. Dienststatistiken können die Prozessorauslastung beinhalten, die als Anteil der möglichen Gesamtauslastung ausgedrückt werden kann. Die Prozessorauslastung kann auch als Ausführungszeit über ein Zeitintervall ausgedrückt werden. Die Dienststatistiken können die Speicherauslastung beinhalten, die als Anteil des Gesamtspeichers ausgedrückt werden kann. Die Speicherauslastung kann sowohl flüchtige als auch nichtflüchtige Speichernutzung für die Steuerung umfassen. Die Dienststatistiken können die Netzwerkauslastung beinhalten, die als eine Menge von Daten, die über das Fahrzeugnetzwerk über ein Zeitintervall ausgetauscht werden, ausgedrückt werden kann.
  • Leistungsparameter können eine Antwortzeit eines Diensts beinhalten. Zum Beispiel kann der Dienst-Manager 320 dazu ausgelegt sein, eine Zeit zum Abschließen eines Diensts aufzuzeichnen. Eine Zeit vom Starten des Diensts bis zum Abschluss des Diensts kann gemessen werden. Eine Antwortzeit, die eine vorbestimmte Zeit überschreitet, kann eine reduzierte Leistung anzeigen. Antwortzeiten können auch für die verschiedenen Unterdienste überwacht werden. Antwortzeiten für Kinddienste können als Zeit zwischen Ankunft der Anforderung und Abschluss der Anforderung gemessen werden. Die Möglichkeit, die verschiedenen Antwortzeiten zu überwachen, kann verwendet werden, um zu bestimmen, wo Verarbeitungsengpässe innerhalb eines Diensts auftreten können.
  • Leistungsparameter können eine Nutzungshäufigkeit der Dienste und/oder Dienstroutinen beinhalten. Die Steuerungen können dazu programmiert sein, eine Anzahl von Anforderungen eines Diensts und/oder einer Dienstroutine über ein vorbestimmtes Zeitintervall zu berechnen. Eine höhere Nutzungshäufigkeit kann einen Dienst anzeigen, der mehr Prozessorzeit erfordert.
  • Leistungsparameter können einen Status der Kommunikation zwischen der Gateway-Steuerung 204 und den anderen Steuerungen beinhalten. Der Dienst-Manager 320 kann dazu ausgelegt sein, einen Verlust der Kommunikation zwischen Steuerungen zu überwachen. Zum Beispiel kann der Dienst-Manager 320 eine der zuletzt von einer Steuerung empfangenen Nachricht zugeordnete Zeit aufzeichnen. Eine seit der zuletzt aufgezeichneten Zeit vergangene Zeit, die eine vorbestimmte Zeit überschreitet, kann einen Verlust der Kommunikation mit der Steuerung (d. h. reduzierte Leistung) anzeigen.
  • Leistungsparameter können eine Auslastung der Netzwerkbandbreite zwischen den Steuerungen beinhalten. Die Dienst-Manager 320 kann dazu ausgelegt sein, den Verkehr auf dem Fahrzeugnetzwerk zu überwachen. Der Dienst-Manager 320 kann ferner dazu ausgelegt sein, die Netzwerkauslastung für jeden der Dienste zu bestimmen. Zum Beispiel kann die Netzwerkauslastung für jeden der Dienste bestimmt werden, indem der Nachrichtenverkehr für jeden der Dienste überwacht wird. Die Netzwerkbandbreite kann als Anteil der Gesamtnetzwerkbandbreite, die durch Kommunikation mit der Steuerung verbraucht wird, ausgedrückt werden.
  • Unter Verwendung dieses Protokolls kann das Fehlermanagement in einer dienstorientierten verteilten Architektur vereinfacht werden. Ein Fehler oder ein Zustand mit reduzierter Leistung, der durch einen Dienst erkannt wird, kann an andere Dienste weitergegeben werden. Ein Elterndienst kann entscheiden, dass System selbst zu reparieren, indem der Kinddienst zurückgesetzt/wiederhergestellt wird oder kann den Fehler an den Root-Dienst (Dienst-Manager 320) weitergeben. Der Service-Manager 320 kann eine Richtlinie umsetzen und eine Wiederherstellung versuchen, indem der Dienst oder das System auf Grundlage der Schwere des Fehlers zurückgesetzt wird. Der Dienst-Manager 320 kann die Störungs-/Fehlerstatistiken eines bestimmten Diensts an den externen Server, der mit dem externen Netzwerk 161 verbunden ist, melden.
  • Dienste können auf System-/Benutzerereignisse, wie etwa Zündung-Einschalt-Abschaltereignisse oder Factory Resets, reagieren müssen. Der Dienst-Manager 320 kann diese Nachrichten auf dem Netzwerk per Multicast senden, und die Dienste können die Reihenfolge, mit der die Dienste ein-/abgeschaltet werden, bestimmen. Der Elterndienst kann die Reihenfolge für alle seine Kindknoten entscheiden. Verschiedene andere System-/Benutzerereignisse sind möglich.
  • Der Konnektivitätsstatus des Fahrzeugnetzwerks kann aufgrund des Multicasts der Nachrichten einfach bestimmt werden. Zum Beispiel kann eine Verkehrsanwendung, die eine Verbindung zu dem Verkehrsserver, der sich in der Cloud befindet, herstellt, den optimierten Konnektivitätspfad kennen müssen, bevor sie versucht, die Verbindung herzustellen. Die Anwendung kann mit einem lokalen Netzwerkdienst kommunizieren, um die optimierte Verbindung herzustellen. Die Steuerung, die den Status der Verbindung überwacht und veröffentlicht (z. B. WIFI, Mobilfunk, Bluetooth), kann den Status für alle Dienste, die den Konnektivitätsstatus benötigen, über das Fahrzeugnetzwerk per Multicast senden. Die Netzwerkdienstroutine, die sich in der Steuerung befindet, in der die Verkehrsanwendung ausgeführt wird, kann diese Informationen abonnieren und lokal zwischenspeichern. Die Steuerung kann den optimierten Pfad bestimmen und die Verbindung für die Anwendung auf Grundlage der zwischengespeicherten Informationen herstellen. Die Verkehrsanwendung kann sich dann über die ihr von dem Netzwerkdienst bereitgestellte optimierte Verbindung mit dem externen Verkehrsserver verbinden.
  • Der Dienst-Manager 320, der in der Gateway-Steuerung 204 ausgeführt wird, kann jeden der Dienste, die in dem System umgesetzt werden, überwachen. Als Reaktion darauf, dass die Leistungsparameter eine Reduktion der Leistung eines Diensts oder einer Dienstroutine anzeigen, kann der Dienst-Manager 320 die zugeordneten Routinen zwischen den Steuerungen dynamisch zuweisen. Zum Beispiel kann der Dienst-Manager 320 als Reaktion auf Leistungsdaten, die eine reduzierte Leistung einer ersten Steuerung anzeigen, die Dienstroutine, die in der ersten Steuerung ausgeführt wird, an eine zweite Steuerung übertragen. Der Dienst-Manager 320 kann Anweisungen oder Befehle an die erste Steuerung senden, die Ausführung der zugeordneten Dienstroutinen anzuhalten. Der Dienst-Manager 320 kann dann die Dienstroutine an die zweite Steuerung zur Installation übertragen. Der Dienst-Manager 320 kann das Repository aktualisieren und einen Befehl an die zweite Steuerung senden, die übertragene Dienstroutine zu starten. Der Dienst-Manager 320 kann die Dienstroutine von einem externen Server, der mit dem externen Netzwerk verbunden ist, abrufen. Der Dienst-Manager 320 kann die Dienstroutine von der ersten Steuerung auf Anforderung abrufen.
  • In einigen Konfigurationen können ein neuer Dienst und zugeordnete Dienstroutinen von dem Dienst-Manager 320 empfangen werden. Zum Beispiel kann der neue Dienst von einem externen Server aus dem externen Netzwerk 161 empfangen werden. Der Dienst-Manager 320 kann die Dienststatistiken jeder Steuerung überprüfen, um zu bestimmen, in welcher Steuerung die neuen Dienstroutinen zugewiesen werden sollen. Zum Beispiel können Leistungsdaten, die Prozessor- und Speicherauslastung beinhalten, überprüft werden. Darüber hinaus kann der Dienst-Manager 320 bestimmen, welche Dienste auf niedriger Ebene von den neuen Dienstroutinen benötigt werden. Der Dienst-Manager 320 kann versuchen, die neue Dienstroutine zuzuweisen, um Netzwerkverkehr zu minimieren, indem die neue Dienstroutine einer Steuerung zugewiesen wird, die Dienste auf niedriger Ebene, die von der neuen Dienstroutine verwendet werden, ausführt. Der Dienst-Manager 320 kann die neuen Dienstroutinen über das Fahrzeugnetzwerk an die ausgewählten Steuerungen übertragen. Nachdem die neuen Dienstroutinen installiert wurden, kann der Dienst-Manager 320 einen Startbefehl für den neuen Dienst erteilen, der die neuen Dienstroutinen veranlasst, mit der Ausführung zu beginnen.
  • Es gibt viele Beispiele für potentielle neue Dienste. Beispiele beinhalten Dienstroutinen für Diagnose und Fehlersuche, die von einer Serviceeinrichtung geladen und ausgeführt werden können. Die Diagnose-Dienstroutinen können bei der Diagnose der Zustände verschiedener Komponenten helfen. Der Vorteil dieser Architektur besteht darin, dass die neuen Dienstroutinen installiert und ausgeführt werden können, um konkrete Funktionen durchzuführen. Die neuen Dienstroutinen können temporäre Routinen sein, die entfernt werden, nachdem sie verwendet wurden. Andere potentielle neue Dienste können das Ermöglichen neuer Merkmale oder Funktionen beinhalten. Zum Beispiel können Fahrzeugfunktionen im Laufe der Zeit verbessert werden, was weitere Dienstroutinen erfordert.
  • 4 stellt ein mögliches Ablaufdiagramm 400 für eine Folge von Vorgängen dar, die von dem Dienst-Manager 320 durchgeführt werden können. Es ist zu beachten, dass die dargestellten Vorgänge für eine beliebige Anzahl von Diensten parallel durchgeführt werden können. Die Vorgänge können für jeden der Dienste und jede der Dienstroutinen kontinuierlich wiederholt werden. Bei Vorgang 402 kann der Dienst-Manager 320 Leistungsparameter empfangen und/oder berechnen. Die Leistungsparameter können die vorstehend hierin erörterten Parameter und Dienststatistiken beinhalten. Die Leistungsparameter können von den Dienstroutinen, die in den Steuerungen ausgeführt werden, empfangen werden.
  • Bei Vorgang 404 kann der Dienst-Manager 320 die Dienste, die aktuell in dem Fahrzeug installiert sind, überwachen. Zum Beispiel kann der Dienst-Manager 320 die Datenbank der Dienste und zugehörige Parameter überwachen, um zu bestimmen, ob die Dienste ordnungsgemäß ausgeführt werden. Der Dienst-Manager 320 kann die Parameter überprüfen, um die Verfügbarkeit jedes der Dienste sicherzustellen. Das Ergebnis der Überwachung kann eine Anforderung sein, Dienstroutinen hinzuzufügen, zu entfernen oder zu übertragen.
  • Bei Vorgang 406 kann der Dienst-Manager 320 eine Überprüfung durchführen, um zu bestimmen, ob beliebige neue Dienste hinzugefügt werden sollen. Der Dienst-Manager 320 kann eine Anforderung von dem externen Server erhalten, einen neuen Dienst zu installieren. Wenn ein neuer Dienst hinzugefügt werden soll, kann Vorgang 408 durchgeführt werden. Bei Vorgang 408 können die dem neuen Dienst zugeordneten Dienstroutinen den Steuerungen gemäß den hier beschriebenen Leistungsparametern zugewiesen werden.
  • Wenn keine neuen Dienste hinzugefügt werden sollen, kann Vorgang 410 durchgeführt werden, um zu überprüfen, ob beliebige Dienste entfernt werden sollen. Wenn ein Dienst entfernt werden soll, kann Vorgang 412 durchgeführt werden, um die zugeordneten Dienstroutinen anzuhalten und von den Steuerungen zu entfernen. Zum Beispiel kann ein Dienst, der temporär hinzugefügt wurde, entfernt werden, nachdem der Dienst ausgeführt wurde. Ein Befehl, den Dienst zu entfernen, kann von dem Dienst-Manager 320 von dem externen Server empfangen werden.
  • Wenn keine Dienste entfernt werden sollen, kann Vorgang 414 durchgeführt werden, um zu bestimmen, ob ein beliebiger der Leistungsparameter eine reduzierte Leistung für den zugeordneten Dienst anzeigt. Wenn die Leistungsparameter für einen oder mehrere Dienste eine reduzierte Leistung anzeigen, kann Vorgang 416 durchgeführt werden, um einen Neustart (z. B. Stopp gefolgt von einem Start) der Dienstroutine anzuweisen. Bei Vorgang 418 kann eine Überprüfung durchgeführt werden, um zu bestimmen, ob der Neustart ausreichend war, um den reduzierten Leistungszustand zu beheben. Das heißt, die Leistungsparameter können überprüft werden, um zu bestimmen, ob die Reduktion der Leistung immer noch vorhanden ist. Wenn die Leistungsparameter einen normalen Betrieb anzeigen, kann die Ausführung zu Vorgang 402 zurückkehren. Wenn immer noch reduzierte Leistungsbedingungen vorhanden sind, kann Vorgang 420 durchgeführt werden, um die betroffenen Dienstroutinen einer anderen Steuerung wie hierin beschrieben neu zuzuweisen.
  • Die hierin offenbarten Prozesse, Verfahren oder Algorithmen können einer Verarbeitungsvorrichtung, einer Steuerung oder einem Computer zuführbar sein/davon umgesetzt werden, die/der eine beliebige bestehende programmierbare elektronische Steuereinheit oder eine dedizierte elektronische Steuereinheit beinhalten kann. Gleichermaßen können die Prozesse, Verfahren oder Algorithmen als Daten und Anweisungen gespeichert sein, die durch eine Steuerung oder einen Computer in vielen Formen, einschließlich unter anderem Informationen, die permanent auf nicht beschreibbaren Speichermedien wie etwa ROM-Vorrichtungen gespeichert sind, und Informationen, die veränderbar auf beschreibbaren Speichermedien wie etwa Disketten, Magnetbändern, CDs, RAM-Vorrichtungen und sonstigen magnetischen und optischen Medien gespeichert sind, ausgeführt werden können. Die Prozesse, Verfahren und Algorithmen können zudem in einem durch Software ausführbaren Objekt umgesetzt sein. Alternativ können die Prozesse, Verfahren oder Algorithmen ganz oder teilweise unter Verwendung geeigneter Hardwarekomponenten, wie etwa anwendungsspezifischer integrierter Schaltungen (Application Specific Integrated Circuits - ASIC), feldprogrammierbarer Gate-Arrays (Field-Programmable Gate Arrays - FPGA), Zustandsmaschinen, Steuerungen oder anderer Hardwarekomponenten oder Vorrichtungen oder einer Kombination aus Hardware-, Software- und Firmwarekomponenten, ausgeführt sein.
  • Wenngleich vorstehend Ausführungsbeispiele beschrieben sind, ist es nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen beschreiben, die durch die Patentansprüche eingeschlossen sind. Die in der Beschreibung verwendeten Ausdrücke sind vielmehr beschreibende als einschränkende Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen. Wie zuvor beschrieben, können die Merkmale verschiedener Ausführungsformen miteinander kombiniert werden, um weitere erfindungsgemäße Ausführungsformen zu bilden, die unter Umständen nicht ausdrücklich beschrieben oder veranschaulicht sind. Wenngleich verschiedene Ausführungsformen gegenüber anderen Ausführungsformen oder Umsetzungen nach dem Stand der Technik hinsichtlich einer oder mehreren gewünschten Eigenschaften als vorteilhaft oder bevorzugt beschrieben sein können, erkennt der Durchschnittsfachmann, dass ein oder mehrere Merkmale oder eine oder mehrere Eigenschaften in Frage gestellt werden können, um die gewünschten Gesamtattribute des Systems zu erzielen, die von der konkreten Anwendung und Umsetzung abhängen. Diese Attribute können unter anderem Kosten, Festigkeit, Lebensdauer, Lebenszykluskosten, Marktfähigkeit, Erscheinungsbild, Verpackung, Größe, Betriebsfähigkeit, Gewicht, Herstellbarkeit, einfache Montage usw. beinhalten. Demnach liegen Ausführungsformen, die in Bezug auf eine oder mehrere Eigenschaften als weniger wünschenswert als andere Ausführungsformen oder Umsetzungen nach dem Stand der Technik beschrieben sind, nicht außerhalb des Umfangs der Offenbarung und können für bestimmte Anwendungen wünschenswert sein.
  • Gemäß der vorliegenden Erfindung ist ein Fahrzeug bereitgestellt, das eine Vielzahl von Steuerungen aufweist, die dazu ausgelegt sind, über ein Netzwerk zu kommunizieren und dazu programmiert sind, einen Dienst durch Ausführen einer Vielzahl von Routinen, die in zumindest einer der Steuerungen gespeichert und ausgeführt werden, durchzuführen; und eine Gateway-Steuerung, die in Kommunikation mit den Steuerungen steht und dazu programmiert ist, als Reaktion auf Leistungsdaten, die eine reduzierte Leistung der ersten Steuerung anzeigen, zumindest eine der Routinen von einer ersten Steuerung zu einer zweiten Steuerung zu übertragen.
  • Gemäß einer Ausführungsform handelt es sich bei dem Netzwerk um ein Ethernet-Netzwerk, und die Steuerungen sind ferner dazu ausgelegt sein, ein Constrained Application Protocol (CoAP) über das Ethernet-Netzwerk umzusetzen.
  • Gemäß einer Ausführungsform beinhalten die Daten, die eine reduzierte Leistung anzeigen, eine Antwortzeit des Diensts, die eine vorbestimmte Zeit überschreitet.
  • Gemäß einer Ausführungsform beinhalten die Daten, die eine reduzierte Leistung anzeigen, einen Verlust der Kommunikation zwischen der Gateway-Steuerung und der ersten Steuerung für mehr als eine vorbestimmte Zeit.
  • Gemäß einer Ausführungsform beinhalten die Daten, die eine reduzierte Leistung anzeigen, eine Kommunikationsbandbreite zwischen der ersten Steuerung und der Gateway-Steuerung, die geringer als eine vorbestimmt Bandbreite ist.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner dazu ausgelegt, als Reaktion auf Leistungsdaten, die eine reduzierte Leistung anzeigen, einen Befehl an die erste Steuerung zu senden, die Routinen anzuhalten und neu zu starten.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner an ein externes Netzwerk gekoppelt und dazu programmiert, mit einer Anwendung, die auf einem externen Server ausgeführt wird, über das externe Netzwerk unter Verwendung von Hyper Text Transfer Protocol (HTTP) zu kommunizieren.
  • Gemäß der vorliegenden Erfindung ist ein Fahrzeug bereitgestellt, das eine Vielzahl von Steuerungen aufweist, die dazu programmiert sind, eine Vielzahl von Routinen auszuführen, um einen Dienst durchzuführen und über ein Fahrzeugnetzwerk unter Verwendung von Constrained Application Protocol (CoAP) zu kommunizieren; und eine Gateway-Steuerung, die dazu ausgelegt ist, mit einem externen Server unter Verwendung von Hyper Text Transfer Protocol (HTTP) zu kommunizieren, über das Fahrzeugnetzwerk unter Verwendung von CoAP zu kommunizieren und einen Dienst-Manager auszuführen, der die Routinen zwischen Steuerungen auf Grundlage von Leistungsparametern der Steuerungen dynamisch zuweist.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner dazu programmiert, Leistungsparameter an den externen Server zu übertragen.
  • Gemäß einer Ausführungsform ist die vorstehende Erfindung ferner dadurch gekennzeichnet, dass Leistungsparameter eine Antwortzeit zwischen einer Ankunft einer Anforderung, einen Dienst durchzuführen und dem Abschluss der Anforderung beinhalten.
  • Gemäß einer Ausführungsform, ist die vorstehende Erfindung ferner dadurch gekennzeichnet, dass Leistungsparameter eine Kommunikationsbandbreite zwischen Steuerungen, die über das Fahrzeugnetzwerk verwendet wird, beinhalten.
  • Gemäß einer Ausführungsform beinhalten Leistungsparameter eine Nutzungshäufigkeit für den Dienst.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner dazu programmiert, als Reaktion auf das Empfangen einer Vielzahl neuer Dienstroutinen zum Durchführen eines neuen Diensts von dem externen Server, die neuen Dienstroutinen den Steuerungen auf Grundlage der Leistungsparameter dynamisch zuzuweisen und an diese zu übertragen.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung dazu programmiert, die Routinen auf Grundlage der Ressourcennutzung und der verbleibenden Verarbeitungskapazität der Steuerungen zuzuweisen.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner dazu programmiert, als Reaktion darauf, dass die Leistungsparameter einer ersten Steuerung eine Reduktion der Leistung der ersten Steuerung anzeigen, zumindest eine der Routinen, die von der ersten Steuerung ausgeführt werden, an eine zweite Steuerung zu übertragen.
  • Gemäß der vorliegenden Erfindung ist ein Fahrzeugkommunikationssystem bereitgestellt, das eine Gateway-Steuerung aufweist, die dazu programmiert ist, mit einem externen Server unter Verwendung von Hyper Text Transfer Protocol (HTTP) zu kommunizieren, mit einem internen Fahrzeugnetzwerk über Constrained Application Protocol (CoAP) zu kommunizieren und einen Dienst-Manager auszuführen, der eine Vielzahl von Dienstroutinen, die einem Dienst zugeordnet sind, zwischen einer Vielzahl von Steuerungen, die mit dem internen Fahrzeugnetzwerk verbunden sind, auf Grundlage von Leistungsparametern der Steuerungen dynamisch zuweist.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner dazu programmiert, Leistungsparameter von den Steuerungen zu empfangen.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner dazu programmiert, Leistungsparameter an den externen Server zu kommunizieren.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner dazu programmiert, Dienststatistiken von jeder der Steuerungen zu empfangen und die Dienststatistiken an den externen Server zu übertragen.
  • Gemäß einer Ausführungsform ist die Gateway-Steuerung ferner dazu programmiert, den Zugriff auf den externen Server für die Steuerungen zu regeln.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • IEEE 802 PAN [0018]

Claims (15)

  1. Fahrzeug, umfassend: eine Vielzahl von Steuerungen, die dazu ausgelegt sind, über ein Netzwerk zu kommunizieren, und dazu programmiert sind, einen Dienst durch Durchführung einer Vielzahl von Routinen, die in zumindest einer der Steuerungen gespeichert und ausgeführt werden, durchzuführen; und eine Gateway-Steuerung, die in Kommunikation mit den Steuerungen steht und dazu programmiert ist, als Reaktion auf Leistungsdaten, die eine reduzierte Leistung der ersten Steuerung anzeigen, zumindest eine der Routinen von einer ersten Steuerung zu einer zweiten Steuerung zu übertragen.
  2. Fahrzeug nach Anspruch 1, wobei es sich bei dem Netzwerk um ein Ethernet-Netzwerk handelt, und die Steuerungen ferner dazu ausgelegt sind, ein Constrained Application Protocol (CoAP) über das Ethernet-Netzwerk umzusetzen.
  3. Fahrzeug nach Anspruch 1, wobei die Daten, die eine reduzierte Leistung anzeigen, eine Antwortzeit des Diensts, die eine vorbestimmte Zeit überschreitet, beinhalten.
  4. Fahrzeug nach Anspruch 1, wobei die Daten, die eine reduzierte Leistung anzeigen, einen Verlust der Kommunikation zwischen der Gateway-Steuerung und der ersten Steuerung für mehr als eine vorbestimmte Zeit beinhalten
  5. Fahrzeug nach Anspruch 1, wobei die Daten, die eine reduzierte Leistung anzeigen, eine Kommunikationsbandbreite zwischen der ersten Steuerung und der Gateway-Steuerung, die geringer als eine vorbestimmt Bandbreite ist, beinhalten.
  6. Fahrzeug nach Anspruch 1, wobei die Gateway-Steuerung ferner dazu ausgelegt ist, als Reaktion auf Leistungsdaten, die eine reduzierte Leistung anzeigen, einen Befehl an die erste Steuerung zu senden, die Routinen anzuhalten und neu zu starten.
  7. Fahrzeug nach Anspruch 1, wobei die Gateway-Steuerung ferner an ein externes Netzwerk gekoppelt ist und dazu programmiert ist, mit einer Anwendung, die auf einem externen Server ausgeführt wird, über das externe Netzwerk unter Verwendung von Hyper Text Transfer Protocol (HTTP) zu kommunizieren.
  8. Fahrzeug, umfassend: eine Vielzahl von Steuerungen, die dazu programmiert sind, eine Vielzahl von Routinen auszuführen, um einen Dienst durchzuführen und über ein Fahrzeugnetzwerk unter Verwendung von Constrained Application Protocol (CoAP) zu kommunizieren; und eine Gateway-Steuerung, die dazu ausgelegt ist, mit einem externen Server unter Verwendung von Hyper Text Transfer Protocol (HTTP) zu kommunizieren, über das Fahrzeugnetzwerk unter Verwendung von CoAP zu kommunizieren und einen Dienst-Manager auszuführen, der die Routinen zwischen Steuerungen auf Grundlage von Leistungsparametern der Steuerungen dynamisch zuweist.
  9. Fahrzeug nach Anspruch 8, wobei die Gateway-Steuerung ferner dazu programmiert ist, Leistungsparameter an den externen Server zu übertragen.
  10. Fahrzeug nach Anspruch 8, wobei Leistungsparameter eine Antwortzeit zwischen einer Ankunft einer Anforderung, einen Dienst durchzuführen und dem Abschluss der Anforderung beinhalten.
  11. Fahrzeug nach Anspruch 8, wobei Leistungsparameter eine Kommunikationsbandbreite zwischen Steuerungen, die über das Fahrzeugnetzwerk verwendet wird, beinhalten.
  12. Fahrzeug nach Anspruch 8, wobei Leistungsparameter eine Nutzungshäufigkeit für den Dienst beinhalten.
  13. Fahrzeug nach Anspruch 8, wobei die Gateway-Steuerung ferner dazu programmiert ist, als Reaktion auf das Empfangen einer Vielzahl neuer Dienstroutinen zum Durchführen eines neuen Diensts von dem externen Server, die neuen Dienstroutinen den Steuerungen auf Grundlage der Leistungsparameter dynamisch zuzuweisen und an diese zu übertragen.
  14. Fahrzeug nach Anspruch 8, wobei die Gateway-Steuerung dazu programmiert ist, die Routinen auf Grundlage der Ressourcennutzung und der verbleibenden Verarbeitungskapazität der Steuerungen zuzuweisen.
  15. Fahrzeug nach Anspruch 8, wobei die Gateway-Steuerung ferner dazu programmiert ist, als Reaktion darauf, dass die Leistungsparameter einer ersten Steuerung eine Reduktion der Leistung der ersten Steuerung anzeigen, zumindest eine der Routinen, die von der ersten Steuerung ausgeführt werden, an eine zweite Steuerung zu übertragen.
DE102019100436.5A 2018-01-12 2019-01-09 System zum dynamischen zuweisen von diensten zwischen steuerungen in einem automobil Pending DE102019100436A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/870,218 2018-01-12
US15/870,218 US10750339B2 (en) 2018-01-12 2018-01-12 System for dynamically allocating services between controllers in an automobile

Publications (1)

Publication Number Publication Date
DE102019100436A1 true DE102019100436A1 (de) 2019-07-18

Family

ID=67068699

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019100436.5A Pending DE102019100436A1 (de) 2018-01-12 2019-01-09 System zum dynamischen zuweisen von diensten zwischen steuerungen in einem automobil

Country Status (3)

Country Link
US (1) US10750339B2 (de)
CN (1) CN110035109A (de)
DE (1) DE102019100436A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020104405A1 (de) 2020-02-19 2021-08-19 HELLA GmbH & Co. KGaA Vorrichtung und Verfahren zum Verbinden einer serviceorientierten Kommunikation mit einer signalbasierten Kommunikation
DE102022107431B3 (de) 2022-03-29 2023-05-11 Volkswagen Aktiengesellschaft Verfahren zum Nachrüsten einer Socks-Kompatibilität für zumindest eine Anwendung in einem Kraftfahrzeug sowie entsprechend eingerichtetes Kraftfahrzeug

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10855753B2 (en) * 2018-02-23 2020-12-01 Standard Cognition, Corp. Distributed computing of vehicle data by selecting a computation resource of a remote server that satisfies a selection policy for meeting resource requirements according to capability information
CN110535740B (zh) * 2019-08-29 2020-10-02 华人运通(江苏)技术有限公司 信号处理方法、装置、存储介质及终端
CN113037603B (zh) * 2021-03-12 2023-05-12 广州小鹏汽车科技有限公司 一种远程控制方法、装置和车辆
CN113360207A (zh) * 2021-06-03 2021-09-07 奥特酷智能科技(南京)有限公司 一种基于动态应用程序加载技术的车身电气网络架构
US11902406B2 (en) * 2022-01-12 2024-02-13 Nxp B.V. Data communication using Constrained Application Protocol over local area network
CN114553873B (zh) * 2022-02-27 2023-06-09 重庆长安汽车股份有限公司 基于soa的车云协同控制系统、方法及可读存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090319656A1 (en) * 2008-06-24 2009-12-24 Chen-Yui Yang Apparatus and method for managing a network
JP2010238051A (ja) * 2009-03-31 2010-10-21 Fujitsu Ltd 負荷分散プログラム及び負荷分散装置
US20110078303A1 (en) * 2009-09-30 2011-03-31 Alcatel-Lucent Usa Inc. Dynamic load balancing and scaling of allocated cloud resources in an enterprise network
CN103650630B (zh) * 2011-07-15 2017-11-14 诺基亚技术有限公司 用于分发传感器数据的方法和装置
US8775615B2 (en) 2012-03-08 2014-07-08 International Business Machines Corporation SNMP-based management of service oriented architecture environments
US9915950B2 (en) * 2013-12-31 2018-03-13 Polysync Technologies, Inc. Autonomous vehicle interface system
US9762395B2 (en) * 2014-04-30 2017-09-12 International Business Machines Corporation Adjusting a number of dispersed storage units
KR101612819B1 (ko) 2014-11-18 2016-04-15 현대자동차주식회사 Avb 기술 연동을 통한 some/ip 스트림 처리 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IEEE 802 PAN

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020104405A1 (de) 2020-02-19 2021-08-19 HELLA GmbH & Co. KGaA Vorrichtung und Verfahren zum Verbinden einer serviceorientierten Kommunikation mit einer signalbasierten Kommunikation
DE102022107431B3 (de) 2022-03-29 2023-05-11 Volkswagen Aktiengesellschaft Verfahren zum Nachrüsten einer Socks-Kompatibilität für zumindest eine Anwendung in einem Kraftfahrzeug sowie entsprechend eingerichtetes Kraftfahrzeug

Also Published As

Publication number Publication date
US10750339B2 (en) 2020-08-18
CN110035109A (zh) 2019-07-19
US20190222984A1 (en) 2019-07-18

Similar Documents

Publication Publication Date Title
DE102019100436A1 (de) System zum dynamischen zuweisen von diensten zwischen steuerungen in einem automobil
DE102011075066A1 (de) Verfahren und Systeme zum Herstellen einer Schnittstelle mit einem Fahrzeugdatenverarbeitungssystem über mehrere Datentransportkanäle
DE112020004736T5 (de) Edge-computing-technologien für transportschichtüberlastregelung und point-of-presence-optimierungen auf grundlage erweiterter vorab-dienstgüte-benachrichtigungen
DE102018103187A1 (de) Erweitertes zentrales Gateway zur Fahrzeugvernetzung
DE112017006994T5 (de) Bereitstellung und verwaltung von microservices
DE60101566T2 (de) Gerätetreibererzeugung
DE102015103974A1 (de) Fahrzeugtelematik-Datenaustausch
DE102015223512A1 (de) System und Verfahren zum Zusammenwirken zwischen Fahrzeugsteuerung und externer Ressource
DE102015216190A1 (de) Verfahren und System zum Bereitstellen einer optimierten Ethernetkommunikation für ein Fahrzeug
EP2526487A1 (de) Verbindungsmodul zum anbinden mindestens eines sensors, aktors oder effektors an ein service oriented architecture- (soa-) netzwerk
EP3230856B1 (de) Verfahren zum update von firmware von geräten
DE102013216055A1 (de) Verfahren und Vorrichtungen für Fahrzeugrechensystem-Softwareaktualisierungen
US10733035B1 (en) Dynamic optimization of application workflows
DE102022203249A1 (de) Mehrfachzugriff-edge-computing- (mec-) fahrzeug-zu-alles-(v2x-) interoperabilitätsunterstützung für mehrere v2x-nachrichtenbroker
DE102021123546A1 (de) Veröffentlichungs-abonnement-kommunikationsarchitektur für sehr vielseitige feldgeräte in steuerungs- und automationssystemen
DE102015215480A1 (de) Verfahren und Vorrichtung zum Übertragen einer Nachricht in einem Fahrzeug
DE102021123544A1 (de) Knotenverwaltung von knotenbasierten kommunikationsnetzwerken für sehr vielseitige feldgeräte in steuerungs- und automationssystemen
DE102021123538A1 (de) Sicherheitssysteme zum einsatz beim implementieren von sehr vielseitigen feldgeräten und kommunikationsnetzwerken in steuerungs- und automationssystemen
DE102017107863A1 (de) Verfahren und Vorrichtung für dynamische Fahrzeugkommunikationsantwort
DE102020000029A1 (de) Softwarerahmen und entwicklungsplattform für wi-fi-chipsätze
DE60312490T2 (de) Verfahrensermöglichte vertragsbasierte verwaltung eines netzwerkbetriebsunterstützungssystems
DE102015110806A1 (de) Verfahren zum automatischen Schließen einer Anwendung bei Transportverbindungsabkopplung
DE112017007523T5 (de) Erstellen eines computersystems
WO2019096713A1 (de) Verfahren und vorrichtung zum datenorientierten informationsaustausch mit einem fahrzeugnetzwerk
DE102014104521A1 (de) Vorrichtung und Verfahren zum Zuweisen dynamischer Internetprotokolladressen (IP Adressen) in einem Fahrzeugkommunikationsnetz

Legal Events

Date Code Title Description
R082 Change of representative

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