DE102020000498A1

DE102020000498A1 - Managementvorrichtung und Applikationsvorrichtung für ein Fahrzeugkommunikationssystem

Info

Publication number: DE102020000498A1
Application number: DE102020000498.9A
Authority: DE
Inventors: Tobias Bandh; Simon Reiner
Original assignee: Daimler AG
Current assignee: Mercedes Benz Group AG
Priority date: 2020-01-27
Filing date: 2020-01-27
Publication date: 2020-09-10

Abstract

Es wird ein Fahrzeugkommunikationssystem (100) angegeben, aufweisend eine Managementvorrichtung (103) und eine Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c)dadurch gekennzeichnet, dassdie Managementvorrichtung (103) und die Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) in einer Kommunikationsbeziehung mit einander verbunden sind unddie Managementvorrichtung (103) eingerichtet ist, die Datenrate einer auf der Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) ausgeführten Applikation auf Applikationsebene festzulegen.

Description

Die Erfindung betrifft das technische Gebiet der Datenkommunikation, insbesondere die Datenkommunikation in einem Fahrzeug. Insbesondere betrifft die Erfindung eine Managementvorrichtung für ein Fahrzeugkommunikationssystem, eine Applikationsvorrichtung für ein Fahrzeugkommunikationssystem, ein Fahrzeugkommunikationssystem, ein Verfahren zum Managen einer Priorität einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems und ein Verfahren zum Einhalten einer Datenrate einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems.
Bei heutigen Fahrzeugen kommt eine Vielzahl von Applikationen oder Anwendungen zum Einsatz, wie beispielsweise eine Navigationsanwendung. Einfache Anwendungen können lokal in dem Fahrzeug eingesetzt werden. Jedoch machen komplexe Applikationen oftmals auch eine Interaktion mit externen Servern oder Cloud Komponenten erforderlich.
Diese komplexen Applikationen sind funktional im Wesentlichen in zwei Teile aufgeteilt, auf der einen Seite die Fahrzeug-Applikationen und auf der anderen Seite die zugehörigen Vehicle Cloud Applikationen. Die Fahrzeug-Applikationen stellen den Fahrzeuganteil der Applikation dar und werden auf unterschiedlichen Steuergeräten innerhalb des Fahrzeuges ausgeführt. Auf der anderen Seite bilden die Vehicle Cloud Applikationen, die in der Vehicle Cloud im Backend ausgeführt werden, die Gegenstelle.
Diese beiden Teile der Applikationen müssen Daten austauschen können, um zu funktionieren. Alle Komponenten des Systems, die für eine Datenübertragung von einer Fahrzeug-Applikation zu einer Vehicle Cloud Applikation oder umgekehrt durchlaufen werden müssen, werden auch als Systemkette bezeichnet.
Innerhalb des Fahrzeuges sind alle Steuergeräte vernetzt und können über die TCU (Telematic Control Unit), die über Mobilfunk eine Verbindung ins Internet herstellt, Daten mit dem Internet austauschen. Eine Fahrzeug-Applikation sendet somit ihre Daten zur TCU, die diese dann über das Mobilfunknetz in das Internet weiterleitet.
Von dort werden die Daten an einen Datenrouter übermittelt, beispielsweise an den MQTT (Message Queuing Telemetry Transport)-Broker. Dieser leitet die Nachrichten dann an den Backendanteil der jeweiligen Applikation weiter.
Über diese Kette kann die Fahrzeug-Applikation Daten mit ihrer Gegenstelle im Backend, der Vehicle Cloud Applikation, austauschen. Werden Daten von der Vehicle Cloud Applikation an das Fahrzeug übertragen, wird diese Abfolge dementsprechend in umgekehrter Reihenfolge durchlaufen.
Aufgrund der unterschiedlichen Kanalgüte eines mobilen Datenkanals kann es bei der Datenübertragung zu schwankenden Übertragungskapazitäten kommen.
Die Druckschrift DE 10 2014 200 226 A1 beschreibt eine zentrale Kommunikationseinheit eines Kraftfahrzeuges und ein Verfahren zum Steuern der Kommunikation zwischen mehreren Applikationen mittels einer solchen zentralen Kommunikationseinheit, wobei die zentrale Kommunikationseinheit ein Kommunikationsorganisationsmodul aufweist, das die zur Verfügung stehende externe Funk-Verbindungskapazitäten zwischen der zentralen Kommunikationseinheit und zumindest einer Sende-/Empfangseinrichtung aktiv nach vorbestimmten Kriterien auf einzelne aktive Datenverbindungen der Applikationen verteilen kann. Hierbei werden in der zentralen Kommunikationseinheit die vorhandenen externen Funk-Verbindungskapazitäten zwischen den einzelnen Datenverbindungen der einzelnen Applikationen gezielt gesteuert verteilt.
Aufgabe der vorliegenden Erfindung ist es, ein effizientes Übertragen von Daten zu ermöglichen, beispielsweise bei schwankender Kanalqualität.
Die Erfindung ergibt sich aus den Merkmalen der unabhängigen Ansprüche. Vorteilhafte Weiterbildungen und Ausgestaltungen sind Gegenstand der abhängigen Ansprüche. Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung, sowie der Erläuterung von Ausführungsbeispielen der Erfindung, die in den Figuren dargestellt sind.
Gemäß einem Aspekt der vorliegenden Erfindung wird eine Managementvorrichtung oder ein Network Governor für ein Fahrzeugkommunikationssystem bereitgestellt, welche/welcher eine Applikationskommunikationseinrichtung, eine Prioritätsverwaltungseinrichtung und eine Übertragungsqualitätsbestimmungseinrichtung aufweist.
Die Aufgabe ist mit der Managementvorrichtung dadurch gelöst, dass die Applikationskommunikationseinrichtung eingerichtet ist, mit einer Applikationsvorrichtung zu kommunizieren. Dabei ist die Prioritätsverwaltungseinrichtung eingerichtet, eine Priorität einer auf der Applikationsvorrichtung ausgeführten Applikation zu verwalten. Die Übertragungsqualitätsbestimmungseinrichtung ist eingerichtet, eine Übertragungsqualität eines von der Applikation genutzten Übertragungskanals zu bestimmen und die Applikationskommunikationseinrichtung ist eingerichtet, der Applikationsvorrichtung eine aus der Priorität und der Übertragungsqualität bestimmte Datenrate mitzuteilen.
Auf diese Weise mag eine Steuerung und/oder Regelung der Datenrate auf Applikationseben durchführbar sein. Somit mag sich im Gegensatz zu einer zentralen Prioritätssteuerung eine dezentrale Prioritätssteuerung ergeben.
Zwar gibt es noch eine zentrale Einheit im Fahrzeug, hier Network Governor genannt, der für die Zuteilung, der verfügbaren Bandbreite zwischen Fahrzeug und Vehicle Cloud, auf die mit der Cloud interagierenden ECUs und deren Applikationen zuständig ist. Allerdings mag es zu keinem Zeitpunkt ein vollständiges Wissen über die verfügbare Bandbreite geben.
Es mag berücksichtigbar sein, dass die Kommunikation zwischen Fahrzeug und Vehicle Cloud unterschiedlich priorisiert ist, abhängig von der jeweiligen Funktionalität der Applikation. So mag eine sicherheitskritische oder safety-kritische Kommunikation eine höhere Priorität haben, als beispielsweise ein Update von Navigationskarten. Diese unterschiedlichen Prioritäten können vorteilhaft durch die Festlegung einer Prioritätsklassifizierung berücksichtigt werden.
Das Steuern auf Applikationsebene mag außerdem in Betracht ziehen, dass zu jedem Zeitpunkt im Wesentlichen nur ein Subset der kommunikationsfähigen Entitäten oder der kommunikationsfähigen Applikationen kommuniziert.
Vorteilhafterweise kann der Network Governor oder die Managementvorrichtung mit den einzelnen Entitäten oder Applikationen sowohl im Fahrzeug als auch in der Vehicle Cloud interagieren, um den momentanen Status der Kommunikation zu erfahren.
Somit mag sich klären lassen, ob ausreichend Linkkapazität oder Bandbreite verfügbar ist, um die Funktion einer Applikation aufrecht zu erhalten. In dem Fall, dass eine Einschränkung der verfügbaren Bandbreite auftritt, bemerken die kommunizierenden Entitäten, beispielsweise die Fahrzeug-Applikation und die Vehicle Cloud Applikation, diese Einschränkung und benachrichtigen den Network Governor oder die Managementvorrichtung über diese Einschränkung. In dieser Situation verteilt der Network Governor oder die Managementvorrichtung die verfügbare Bandbreite entsprechend der Priorität auf die einzelnen Entitäten oder Applikationen. Diese Entitäten passen ihr Kommunikationsverhalten entsprechend an. Vorteilhaft stellt der Network Governor oder die Managementvorrichtung durch dieses Vorgehen sicher, dass sicherheitskritische Einheiten oder Applikationen und Einheiten, die zu der Quality of Experience für den Nutzer beitragen, im Wesentlichen immer oder zumindest in den meisten Fällen ihre Funktion erfüllen können.
Folglich mag im Gegensatz zu in der Fahrzeugtechnik oftmals angewendeter Verfahren, wie beispielsweise dem Reservieren einer Maximal-Durchsatzrate, die Kapazität des Kommunikationskanals maximal ausgeschöpft werden, ohne Reserven vorzuhalten. Somit mag sich das erfindungsgemäße System mit seinen Komponenten gut für die Gesamtfunktionalität eines Connected Cars eignen.
In einer Ausführungsform mag die Priorität auch eine benötigte Datenrate der Applikation, eine benötigte maximale Latenz der Applikation und/oder eine benötigte Gesamtdatenmenge berücksichtigen.
Beispielsweise mag eine Applikation der Managementvorrichtung ihre Anforderungen wie die Priorität, die benötigte Datenrate sowie die benötigte maximale Latenz oder auch, falls bekannt, die benötigte Gesamtdatenmenge der aktuell übertragenen Daten der Applikation mitteilen.
Gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung ist die Managementvorrichtung auf einer TCU und/oder einem Datenrouter, beispielsweise einem MQTT-Broker, implementiert und/oder integriert. Ein Datenrouter kann als Verteil- und/oder Entkopplungseinheit genutzt werden. Alternativ kann in einem anderen Beispiel ein Datenrouter zum Einsatz kommen, der das COAP Protokoll nutzt.
Die Managementvorrichtung kann als ein Zusatzmodul für bereits existierende Komponenten gefertigt werden, wodurch sich ein eigenes Gerät für die Managementvorrichtung oder den Network Governor vermeiden lässt.
Die Managementvorrichtung mag als ein Network Governor ausgeführt sein.
Gemäß einem anderen Aspekt der vorliegenden Erfindung wird eine Applikationsvorrichtung für ein Fahrzeugkommunikationssystem beschrieben, auf der eine Applikation ausgeführt wird. Die Applikationsvorrichtung mag eine Managementkommunikationseinrichtung und eine Datenratenüberwachungseinrichtung aufweisen.
Die Aufgabe ist mit der Applikationsvorrichtung dadurch gelöst, dass die Managementkommunikationseinrichtung eingerichtet ist, mit einer Managementvorrichtung zu kommunizieren und von dieser eine Datenrate zu erhalten. Die Datenratenüberwachungseinrichtung ist eingerichtet, die erhaltene Datenrate einzuhalten.
Somit mag eine dezentrale Steuerung der Datenrate der Applikation auf Applikationsebene ermöglicht werden. D.h. es mag möglich sein jede Applikation einzeln zu steuern und insbesondere jeden von einer Applikation generierten Datenstrom einzeln zu überwachen.
Die Applikationsvorrichtung mag als ein Steuergerät oder eine ECU (Electronic Control Unit) realisiert sein oder auf einer ECU als Sub-Modul integriert sein. Die Fahrzeug-Applikationen laufen auf verschiedenen Steuergeräten oder ECUs innerhalb des Fahrzeuges. In einem Premiumfahrzeug können bis zu 100 Steuergeräte verbaut sein. Somit mag eine Fahrzeug-Applikation auf einer Applikationsvorrichtung laufen.
Die Applikationsvorrichtung kann aber auch als eine Vorrichtung ausgeführt sein, auf der eine Vehicle Cloud Applikation ausgeführt wird.
In einem weiteren Beispiel kann die Datenüberwachungseinrichtung auch dazu ausgeführt sein, zu erkennen, dass eine vorgegebene Datenrate nicht eingehalten werden kann, beispielsweise aufgrund einer Degradation oder Verschlechterung eines Übertragungskanals.
Gemäß einem Aspekt der vorliegenden Erfindung ist die Applikation eine Fahrzeug-Applikation oder eine Cloud Applikation ist.
Die Mechanismen zur Überwachung der Datenrate und/oder der Priorisierung mögen unabhängig von der Kommunikationsrichtung erfolgen. Es mögen beispielsweise die beiden Kommunikationsrichtungen Car-to-Cloud Kommunikation und Cloud-to-Car Kommunikation unterschieden werden.
Bei der Car-to-Cloud Kommunikation mag die Fahrzeug-Applikation eine gewünschte Datenrate und/oder Priorität festlegen und die Vehicle Cloud Applikation mag die Datenrate überwachen und falls diese abnimmt, die Managementvorrichtung über die Managementkommunikationseinrichtung informieren.
Bei der Cloud-to-Car Kommunikation mag die Vehicle Cloud Applikation eine gewünschte Datenrate und/oder Priorität festlegen und die Fahrzeug-Applikation mag die Datenrate überwachen und falls diese abnimmt, die Managementvorrichtung über die Managementkommunikationseinrichtung informieren.
Durch Überwachen der ankommenden Datenrate mag sich eine Aussage über die Qualität des Übertragungskanals treffen lassen.
Je nach Rolle in der Kommunikationsbeziehung kann demnach eine Datenüberwachungseinrichtung die Datenrate des eingehenden Datenstroms und / oder des ausgehenden Datenstroms überwachen. Die Datenrate des eingehenden Datenstroms mag als Empfangsdatenrate und die Datenrate des ausgehenden Datenstroms als Sendedatenrate bezeichnet werden.
Sollte sich die Datenrate, mit der eine Applikation senden möchte, ändern, so kann die Applikation diese Änderung der Managementvorrichtung oder dem Network Governor mitteilen.
Auf diese Art und Weise lässt sich mittels Signalisierung auf Anwendungsebene oder mittels Signaling auf Anwendungsebene eine Anpassung der Senderate erreichen, insbesondere ein Drosseln oder Erniedrigen der Senderate.
In einer Ausführungsform mag vorgesehen sein, dass die Datenratenüberwachungseinrichtung eingerichtet ist, eine Datenrate eines Bündels von Applikationen einzuhalten.
So kann eine Überwachung der Datenrate mittels eines Traffic Shapings in der Transportschicht durchführen lassen. Hierbei kann eine Signalisierung der einzelnen Applikationen entfallen. Vorteilhafterweise mag in den einzelnen Applikationen die Funktionalität der Sendedrosselung nicht implementiert werden müssen, d.h. auf das Überwachen der Senderaten kann verzichtet werden. Der Aufwand für die Überwachung der Senderate einer einzelnen Applikation entfällt. Jedoch wird die gesamte Senderate eines Bündels von Applikationen betrachtet. Dabei mag jeder einzelne Datenstrom so gedrosselt werden, dass eine gesamte vorgebbare Bündeldatenrate nicht überschritten wird.
Hierbei wird die Priorität jeder einzelnen Applikation innerhalb des Bündels auf Applikationsebene betrachtet, indem die Prioritätsverwaltungseinrichtung nach der Mitteilung einer abnehmenden Empfangsdatenrate die neue maximale Datenrate jeder einzelnen Applikation berechnet. Jedoch wird nicht die Senderate an der Applikation überwacht sondern die Datenrate eines Datenstromes, der von der Applikation erzeugt wird, auf dem Weg zum Ziel im Zusammenhang mit einer gesamten Bündeldatenrate. Senden einzelne Applikationen über ihre berechneten maximalen Datenrate, so werden sie über Traffic Shaping gedrosselt, beispielsweise durch den Einsatz eines Leaky Bucket Algorithmus, bei dem beispielsweise Datenpakete einer Applikation mit niedriger Priorität verworfen werden. Hierzu kann die Applikationsvorrichtung auf einer TCU und/oder einer ECU implementiert sein, über welche dann die Datenverbindungen mehrerer Applikationen verlaufen, wobei die mehreren Applikationsverbindungen das Bündel von Verbindungen bilden. Auch hier findet die Ratenanpassung außerhalb des zentralen Network Governors oder der zentralen Managementvorrichtung statt.
Auch auf diese Weise lässt sich die Datenrate auf Applikationsebene steuern.
In einer vorteilhaften Ausführungsform ist die Applikationsvorrichtung als ECU ausgebildet.
Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein Fahrzeugkommunikationssystem, aufweisend eine erfindungsgemäße Managementvorrichtung und zumindest eine erfindungsgemäße Applikationsvorrichtung beschrieben, wobei die Managementvorrichtung und die Applikationsvorrichtung in einer Kommunikationsbeziehung mit einander verbunden sind und die Managementvorrichtung eingerichtet ist, die Datenrate einer auf der Applikationsvorrichtung ausgeführten Applikation auf Applikationsebene festzulegen.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Managen oder Verwalten einer Priorität einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems beschrieben, wobei das Verfahren das Kommunizieren mit einer Applikationsvorrichtung aufweist. Weiter weist das Verfahren das Verwalten einer Priorität einer auf der Applikationsvorrichtung ausgeführten Applikation und das Bestimmen einer Übertragungsqualität eines von der Applikation genutzten Übertragungskanals auf. Das Verfahren sieht auch ein Mitteilen einer aus der Priorität und der Übertragungsqualität bestimmten Datenrate an die Applikationsvorrichtung vor, so dass die Applikationsvorrichtung für das Einhalten der bestimmten Datenrate sorgen kann.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird ein Verfahren zum Einhalten einer Datenrate einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems angegeben, wobei das Verfahren ein Kommunizieren mit einer Managementvorrichtung aufweist, sowie ein Erhalten einer Datenrate der Applikation und ein Einhalten der erhaltene Datenrate.
Die erhaltene Datenrate mag eine vorgebbare Senderate sein, mit welcher die Applikation maximal senden darf.
Gemäß noch einem Aspekt der vorliegenden Erfindung wird ein Programmelement bereitgestellt, welches, wenn es von einem Prozessor ausgeführt wird, das Verfahren zum Managen einer Priorität einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems und/oder das Verfahren zum Einhalten einer Datenrate einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems ausführt.
Gemäß noch einem anderen Aspekt der vorliegenden Erfindung wird ein computerlesbares Speichermedium bereitgestellt, in dem ein Programm gespeichert ist, welches, wenn es von einem Prozessor ausgeführt wird, das Verfahren zum Managen einer Priorität einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems und/oder das Verfahren zum Einhalten einer Datenrate einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems ausführt.
Als ein computerlesbares Speichermedium mag eine Floppy Disc, eine Festplatte, ein USB (Universal Serial Bus) Speichergerät, ein RAM (Random Access Memory), ein ROM (Read Only Memory) oder ein EPROM (Erasable Programmable Read Only Memory) genutzt werden. Als Speichermedium kann auch ein ASIC (application-specific integrated circuit) oder ein FPGA (field-programmable gate array) genutzt werden sowie eine SSD (Solid-State-Drive) Technologie oder ein Flash-basiertes Speichermedium. Ebenso kann als Speichermedium ein Web-Server oder eine Cloud genutzt werden. Als ein computerlesbares Speichermedium mag auch ein Kommunikationsnetz angesehen werden, wie zum Beispiel das Internet, welches das Herunterladen eines Programmcodes zulassen mag. Es kann eine funkbasierte Netzwerktechnologie und/oder eine kabelgebundene Netzwerktechnologie genutzt werden.
Weitere Vorteile, Merkmale und Einzelheiten ergeben sich aus der nachfolgenden Beschreibung, in der - gegebenenfalls unter Bezug auf die Zeichnungen - zumindest ein Ausführungsbeispiel im Einzelnen beschrieben ist. Gleiche, ähnliche und/oder funktionsgleiche Teile sind mit gleichen Bezugszeichen versehen.
Es zeigen:

1 ein Blockschaltbild eines Fahrzeugkommunikationssystems gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
2 ein Blockschaltbild einer Managementvorrichtung für ein Fahrzeugkommunikationssystem gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
3 ein Blockschaltbild einer Applikationsvorrichtung für ein Fahrzeugkommunikationssystem, auf der eine Applikation ausgeführt wird, gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
4 ein Blockschaltbild zweier Datenverbindungen in einem Fahrzeugkommunikationssystem gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
5 ein Blockschaltbild weiterer zwei Datenverbindungen in einem Fahrzeugkommunikationssystem gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.

1 zeigt ein Blockschaltbild eines Fahrzeugkommunikationssystem 100 gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
Bei heutigen Fahrzeugen kommt eine Vielzahl von Applikationen oder Anwendungen, wie beispielsweise einer Navigationsanwendung, zum Einsatz.
Diese Applikationen sind funktional im Wesentlichen in zwei Teile aufgeteilt. Auf der einen Seite existieren die Fahrzeug-Applikationen welche auf Applikationsvorrichtungen 101a, 101b, 101c ausgeführt werden und auf der anderen Seite die zugehörigen Vehicle Cloud Applikationen, welche ebenfalls auf Applikationsvorrichtungen 102a, 102b, 102c ausgeführt werden. Um die fahrzeugseitigen 107a Applikationen von den Cloud-seitigen 107b Applikationen unterscheiden zu können werden für die fahrzeugseitigen Applikationsvorrichtungen die Bezugszeichen 101a, 101b, 101c und für die Cloud-seitigen Applikationen die Bezugszeichen 102a, 102b, 102c verwendet. In einem Beispiel können die fahrzeugseitigen Applikationen auf Embedded Devices als Applikationsvorrichtungen 101a, 101b, 101c und die Cloud-seitigen Applikationen auf einem oder mehreren Servern als Applikationsvorrichtungen 102a, 102b, 102c ausgeführt werden.
Der Einfachheit halber sollen für die auf den Applikationsvorrichtungen 101a, 101b, 101c, 102a, 102b, 102c laufenden Applikationen die gleichen Bezugszeichen 101a, 101b, 101c, 102a, 102b, 102c verwendet werden, wie für die Applikationsvorrichtungen 101a, 101b, 101c, 102a, 102b, 102c. Soll ganz spezifisch zwischen der Applikation 101'a und der Applikationsvorrichtung 101a, 101b, 101c unterschieden werden, so wird das Bezugszeichen mit einem Strich versehen.
Die Fahrzeug-Applikationen stellen den Fahrzeuganteil der Applikation dar und werden auf unterschiedlichen Steuergeräten 101', 101" oder ECUs 101', 101" innerhalb des Fahrzeuges ausgeführt. Auf der anderen Seite bilden die Vehicle Cloud Applikationen, die in der Vehicle Cloud im Backend ausgeführt werden, die Gegenstelle.
Diese beiden Teile der Applikationen müssen Daten austauschen können, um zu funktionieren. Da der Datenaustausch gerichtet ist gibt es eine Quell-Applikation und eine Zielapplikation. Alle Komponenten des Systems 100, die für eine Datenübertragung von einer Fahrzeug-Applikation zu einer Vehicle Cloud Applikation oder umgekehrt durchlaufen werden müssen, werden auch als Systemkette bezeichnet.
Innerhalb des Fahrzeuges sind alle Steuergeräte 101', 101" oder ECU 101', 101" über das Fahrzeugnetzwerk 108 vernetzt und können über die TCU (Telematic Control Unit) 104, die über Mobilfunk eine Verbindung ins Internet 106 herstellt, Daten mit dem Internet 106 austauschen. Eine Fahrzeug-Applikation 101a, 101b, 101c sendet somit ihre Daten zur TCU 104, die diese dann über das Mobilfunknetz in das Internet 106 weiterleitet.
Von dem Internet 106 werden die Daten an einen Datenrouter 105 übermittelt, beispielsweise den MQTT (Message Queuing Telemetry Transport)-Broker 105. Dieser leitet die Nachrichten dann an den Backendanteil 102a, 102b, 102c der jeweiligen Applikation weiter.
Über diese Kette kann die Fahrzeug-Applikation Daten mit ihrer Gegenstelle im Backend, der Vehicle Cloud Applikation, austauschen. Werden Daten von der Vehicle Cloud Applikation an das Fahrzeug übertragen, wird diese Abfolge dementsprechend in umgekehrter Reihenfolge durchlaufen.
Aufgrund der unterschiedlichen Kanalgüte eines mobilen Datenkanals kann es bei der Datenübertragung zu schwankenden Übertragungskapazitäten kommen.
Um mit solchen schwankenden Übertragungskapazitäten zurecht zu kommen gibt eine zentrale Einheit 103, die Managementvorrichtung 103 oder den Network Governor 103. Die gestrichelte Darstellung der Managementvorrichtung 103 in 3, deutet an, dass sich diese an einer beliebigen Stelle in der Systemkette befinden kann. Beispielsweise kann sich die Managementvorrichtung 103 im Fahrzeug befinden. Die Managementvorrichtung 103 oder der Network Governor 103 ist für die Zuteilung der zwischen Fahrzeug 107a und Vehicle Cloud 107b verfügbaren Bandbreite auf die mit der Cloud interagierenden Fahrzeug Applikationen 101a, 101b, 101c zuständig, insbesondere für die Zuteilung der verfügbaren Bandbreite auf die ECUs 101', 101" der Fahrzeug Applikationen 101a, 101b, 101c.
In einem System 100, in dem mehrere Entitäten 101a, 101b, 101c, 102a, 102b, 102c oder Applikationen 101a, 101b, 101c, 102a, 102b, 102c miteinander kommunizieren, kann es vorkommen, dass die verwendeten Links und/oder Datenkanäle überlastet sind, so dass die Anwendungen nicht richtig funktionieren. Typischerweise gibt es Anwendungen, die weniger wichtig sind, und andere, die eine hohe Priorität haben oder sogar mission criticle sind, mit potenziell hohen Sicherheitsauswirkungen. Das erfindungsgemäße System 100 bietet die Möglichkeit, die Steuergeräte 101', 101" in einem Fahrzeug bestimmen zu lassen, welche Anwendungen welchen Anteil an der verfügbaren Verbindungskapazität erhalten. Hierzu können die Applikationsvorrichtungen 101a, 101b, 101c, 102a, 102b, 102b mit der Managementvorrichtung 103 kommunizieren. Die Applikationsvorrichtungen 101a, 101b, 101c, 102a, 102b, 102b in Verbindung mit der Managementvorrichtung 103 können sowohl für die reine Bordkommunikation auf der Fahrzeugseite 107a als auch für eine Fahrzeug-zu-Cloud-Kommunikation genutzt werden, also off-board des Fahrzeuges.
Durch die Verwendung der Applikationsvorrichtungen 101a, 101b, 101c, 102a, 102b, 102b und der Managementvorrichtung 103 kann ein Traffic Shaping auf TCP Ebene, welches nach dem Fairness Prinzip arbeitet vermieden werden und eine hohe Flexibilität bei der Verteilung der Bandbreite erreicht werden.
Gemäß der Erfindung mag vorgesehen sein, dass der Network Governor 103 oder die Managementvorrichtung 103 mit den kommunizierenden Anwendungen 101a, 101b, 101c, 102a, 102b, 102b interagiert und dabei die aktuelle Verteilung der Prioritäten bestimmt. Der Network Governor 103 legt die Prioritätshierarchie fest und signalisiert die zulässige Netzwerknutzung den Applikationen und/oder den Applikationsvorrichtungen 101a, 101b, 101c, 102a, 102b, 102b mit niedrigerer Priorität, die ihre Netzwerknutzung entsprechend reduzieren, drosseln oder ein Traffic Shaping auf ein Bündel von Applikationen anwendet. Auf diese Art und Weise können mission critical Anwendungen trotz Überlastung der Verbindungen einen sicheren Betrieb aufrechterhalten. Hierbei mögen die mission critical Applikationen ein Sub-Set der insgesamt vorhandenen Applikationen bilden.
Es kann dann für die mission critical Applikationen ein sicherer Betrieb aufrechterhalten bleiben. Die Entscheidungen werden auf der Grundlage der Kommunikationsanforderungen der aktuellen aktiv kommunizierenden Anwendungen getroffen, wodurch eine hohe Flexibilität erreicht wird. Es ist im Wesentlichen keine Vorplanung der Netzwerknutzung erforderlich und beliebige Applikationen können in dem System 100 zugefügt oder entfernt werden. Außerdem lässt sich die verfügbare Netzwerkverbindungskapazität zur Maximierung des Anwendungsbetriebs ausnutzen, da im Wesentlichen ungenutzte Reserven vermieden werden. Ferner kann durch eine kontrollierte Reduzierung der Netzwerknutzung und/oder Signalisierungsoverheads schneller als bei IP- oder TCP-basierten Ansätze reagiert werden, indem ein Traffic Shaping auf höheren Netzwerksschichten auf sich ändernde Auslastungen und/oder Kanalkapazitäten reagiert.
Der Vehicle Network Governor 103 oder die Managementvorrichtung 103 interagiert mit den Onboard-Anwendungen 101a, 101b, 101c ebenso wie mit den Offboard-Anwendungen 102a, 102b, 102c, um sicherzustellen, dass mission critical Anwendungen einen sicheren Betrieb aufrechterhalten können, auch wenn die Kapazität der Kommunikationsverbindungen nicht den Anforderungen aller kommunizierenden Anwendungen entspricht. Ein verteilter und/oder dezentraler Erkennungsmechanismus sorgt für eine sehr kurze Reaktionszeit, so dass in den meisten Fällen die hochpriorisierten Anwendungen im Wesentlichen keine oder nur sehr kurze Serviceunterbrechungen erfahren. Indem der Vehicle Network Governor 103 im Wesentlichen nur die aktuell aktiven Anwendungen berücksichtigt, kann er im Zusammenspiel mit den Anwendungen die Netzwerknutzung maximieren und somit die Anzahl der Anwendungen erhöhen, die gleichzeitig betrieben werden können.
Eine mission critical Anwendung mag eine Anwendung sein, welche sicherheitsrelavant ist und damit eine hohe Priorität gegenüber anderen Anwendungen hat.
Bei einem Degradieren einer Kanalkapazität kann es beispielsweise sinnvoll sein, ein anstehendes Karten-Update des Navigationssystems gegenüber dem Erhalten von Bremsinformationen zurückzustellen.
Die Fahrzeug-Applikationen 101a, 101b, 101c laufen innerhalb des Fahrzeuges auf verschiedenen Applikationsvorrichtungen, welche wiederum in verschiedenen Steuergeräten 101', 101" oder ECUs 101', 101" zusammengefasst sein können. Das Leistungsvermögen der ECUs reicht von einfachen Mikrocontrollern bis hin zu leistungsfähigen Prozessoren. Die Steuergeräte 101', 101" sind untereinander vernetzt und tauschen Daten über ein Fahrzeugnetzwerk 108 aus, welches unterschiedliche Technologien wie CAN-Bus, LIN-Bus, FlexRay oder Ethernet nutzen kann. Aufgrund steigender Anforderungen wird bei Applikationen, die einen höheren Datendurchsatz fordern, oft auf Ethernet genutzt.
Die Ethernet-basierten Steuergeräte 101', 101" setzen auf höheren Netzwerkschichten die Internet Protokolle TCP/IP ein. Darauf aufbauend können verschiedene Layer-5-7 Protokolle wie bspw. SOME/IP (Scalable Service-Oriented Middleware over IP) eingesetzt werden. Wollen die Applikationen, die auf den ECUs ausgeführt werden, Daten an die Vehicle Cloud 107b und/oder den Vehicle Cloud Applikationen 102a, 102b, 102c senden, so schicken sie diese über das Protokoll SOME/IP oder das Protokoll MQTT an die TCU (Telematics Control Unit) 104. Die TCU 104 ist das Steuergerät, das die Mobilfunkverbindung herstellt. Alle Daten, die von einem Steuergerät in die Vehicle Cloud 107b übertragen werden, werden über die TCU 104 versendet.
Die TCU 104 kann als NAT (Network Address Translation)-Gateway konfiguriert sein und/oder als Communication Gateway konfiguriert sein und Protokolle übersetzen.
Das MQTT Protokoll ist ein Application Layer Protokoll, das auf TCP/IP aufsetzt. Der MQTT-Broker 105 ist die zentrale Komponente in der MQTT-Architektur. Der Broker 105 sorgt dafür, dass die MQTT-Clients sich nicht gegenseitig kennen müssen und auch nicht gleichzeitig ausgeführt werden müssen. Der Broker 105 sorgt somit für eine zeitliche und räumliche Entkoppelung der Clients. Er leitet alle Nachrichten an die MQTT-Clients weiter und verwaltet deren Verbindungszustand. In der MQTT-Architektur wird das publishsubscribe Entwurfsmuster umgesetzt. Um für ein bestimmtes MQTT-Topic Nachrichten zu erhalten, subscriben sich die Clients auf dieses Topic beim MQTT-Broker. Der MQTT-Broker sendet dann alle Nachrichten mit diesem Topic an die MQTT-Clients, die sich darauf subscribt haben, d.h. die das Topic abonniert haben. Um Nachrichten zu versenden, werden diese einfach auf ein bestimmtes Topic gepublished oder veröffentlicht.
Die einzelnen Applikationen 102a, 102b, 102c in der Vehicle Cloud 107b sind als MQTT-Clients eingerichtet. Auch die TCU 104 kann je nach TCU Funktionsvariante als MQTT-Clients eingerichtet sein, ebenso wie die Fahrzeug-Applikationen 101a, 101b, 101c, die auf den einzelnen Applikationsvorrichtungen 101a, 101b, 101c und/oder den ECUs 101'. 101" ausgeführt werden.
Bei den Applikationen 102a, 102b, 102c in der Vehicle Cloud 107b kann es sich um ein sehr heterogenes Feld hinsichtlich der eingesetzten Technologien handeln. Die Applikationen können auf unterschiedlichen Servern 102a, 102b, 102c und/oder in der Cloud ausgeführt werden. Von der Vielzahl von einsetzbaren Technologien sollen die Technologien genutzt werden, die eine Kommunikation über MQTT und somit über den MQTT-Broker 105 nutzt. Die Vehicle Cloud Applikationen 102a, 102b, 102c sind in diesem Beispiel jeweils MQTT-Clients, d.h. sie nutzen das MQTT Protokoll zur Kommunikation. Somit mögen sich die Vehicle Cloud Applikationen 102a, 102b, 102c von den Fahrzeug-Applikationen 101a. 101b. 101c durch das zugrunde liegende Protokoll unterscheiden.
Die 2 zeigt ein Blockschaltbild einer Managementvorrichtung 103 oder eines Network Governor 103 für ein Fahrzeugkommunikationssystem 100 gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
Die Managementvorrichtung 103 weist eine Applikationskommunikationseinrichtung 201, eine Prioritätsverwaltungseinrichtung 202 und eine Übertragungsqualitätsbestimmungseinrichtung 203 auf. Die Applikationskommunikationseinrichtung ist vorgesehen, um mit einer Applikationsvorrichtung 101a, 101b, 101c und insbesondere mit einer Applikation 101'a auf einer Applikationsvorrichtung 101a, 101b, 101c zu kommunizieren.
Die Prioritätsverwaltungseinrichtung 202 ist eingerichtet, eine Priorität einer auf der Applikationsvorrichtung 101a, 101b, 101c ausgeführten Applikation 101'a zu verwalten.

Die Priorität kann in einer Liste gespeichert werden, wie sie beispielhaft in Tabelle 1 dargestellt ist. Tabelle 1

Name der Applikation	Priorität	Prioritätsklasse
Network Control	Sehr hoch	8
Fernsteuern eines Fahrzeuges	Sehr hoch	7
Kommandos	Hoch	6
Anrufe	Hoch	5
Uploads/Downloads	Hoch	4
Streaming	Hoch	3
Kommandos	Mittel	2
Uploads/Downloads	Niedrig	1

Die Priorität kann seitens der Applikation, welche Daten zu übertragen hat, durch eine Signalisierung oder durch ein Signaling mitgeteilt werden. Eine Applikation, welche Daten zu übertragen hat, ist eine sog. Quell-Applikation oder Sende-Applikation.
Im Falle der Car-to-Cloud Kommunikation ist die Fahrzeug-Applikation 101a, 101b, 101c, insbesondere die Fahrzeug-Applikation 101'a, die Quell-Applikation. Die Vehicle Cloud Applikation 102a, 102b, 102c, insbesondere Vehicle Cloud Applikation 102'a, ist die End-Applikation.
Im Falle der Cloud-to-Car Kommunikation ist die Vehicle Cloud Applikation 102a, 102b, 102c, insbesondere die Vehicle Cloud Applikation 102'a, die Quell-Applikation. Die Fahrzeug-Applikation 101a, 101b, 101c, insbesondere die Fahrzeug-Applikation 101'a, ist die End-Applikation oder Empfänger-Applikation.
In entgegengesetzter Richtung zur Signalisierung von der Quell-Applikation 101'a, 102'a zu der Managementvorrichtung 103 kann der Quell-Applikation 101'a, 102'a über die Applikationskommunikationseinrichtung 201 eine einzuhaltende Datenrate mitgeteilt werden.
Zur Mitteilung der einzuhaltenden Datenrate ist die Applikationskommunikationseinrichtung 201 eingerichtet, der Applikationsvorrichtung 101a, 101b, 101c eine aus der Priorität und der Übertragungsqualität bestimmte Datenrate mitzuteilen.
Zur Mitteilung der einzuhaltenden Datenrate kann ebenfalls ein Signaling oder eine Signalisierung eingesetzt werden. Diese Signalisierung ist jedoch von der Managementvorrichtung 103 zu der Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c gerichtet, auf welcher die Quell-Applikation 101'a, 102'a läuft.
Diese Signalisierung in Richtung der Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c kann durch zwei verschiedene Strategien erfolgen.
Eine erste Strategie sieht eine implizite Freigabe der Datenkommunikation vor.
Eine zweite Strategie sieht eine implizite Drosselung vor.
Die Übertragungsqualitätsbestimmungseinrichtung 203 ist eingerichtet, eine Übertragungsqualität eines von der Applikation 101'a genutzten Übertragungskanals zu bestimmen. Sie erhält diese Information der Übertragungsqualität beispielsweise über eine Mitteilung der jeweiligen End-Applikation 101'a, 102'a.
Die 3 zeigt ein Blockschaltbild einer Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c für ein Fahrzeugkommunikationssystem 100, auf der eine Applikation 101'a, 102'a ausgeführt wird, gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
Die Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c weist eine Managementkommunikationseinrichtung 301 und eine Datenratenüberwachungseinrichtung 302 auf.
Die Managementkommunikationseinrichtung 301 ist eingerichtet, mit einer Managementvorrichtung 103 (nicht gezeigt in 3) zu kommunizieren und eine einzuhaltende Datenrate von der Managementvorrichtung 103 zu erhalten. Diese Datenrate wurde von der Priorität abgeleitet und wird über eine Signalisierung der Datenratenüberwachungseinrichtung 302 mitgeteilt. Die Datenratenüberwachungseinrichtung 302 ist eingerichtet ist, die erhaltene Datenrate einzuhalten. Insbesondere mag die Datenratenüberwachungseinrichtung 302 auf Applikationsebene sicherstellen, dass die der auf der Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c laufende Applikation 101'a, 102'a die Datenrate einhält.
In einem anderen Beispiel (nicht gezeigt in 3) kann ein Bündel von Kommunikationskanälen einer Vielzahl von Applikationen über die Managementkommunikationseinrichtung 301 laufen und die Datenratenüberwachungseinrichtung 302 kann mittels eines Traffic Shaping Verfahrens eine vorgegebene Gesamtdatenrate einhalten, beispielsweise durch die Nutzung eines Leaky Bucket Algorithmus.
Die 4 zeigt ein Blockschaltbild zweier Datenverbindungen 401a, 401b in einem Fahrzeugkommunikationssystem 100 gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
In diesem Fall ist die Managementvorrichtung 103 auf der TCU 104 implementiert.
Bei den Datenverbindungen 401a, 401b handelt es sich um eine Car-to-Cloud-Kommunikation, bei der die erste Car-Cloud-Datenverbindung 401a von der Quell-Applikation 101a bzw. 101'a zu der End-Applikation 102a bzw. 102'a eingerichtet ist. Die zweite Car-Cloud-Datenverbindung 401b ist von der Quell-Applikation 101b zu der End-Applikation 102b eingerichtet ist.
Die Car-Cloud-Datenverbindungen 401a, 401b ermöglichen es einer Fahrzeug-Applikation 101 'a Daten zu senden. Der Verbindung ist ein Verbindungsaufbau vorausgegangen, bei dem zunächst die Quell-Applikation 101'a mittels ihrer Quell-Applikationsvorrichtung 101a eine Sendeanfrage an die TCU 104 und insbesondere an die Managementvorrichtung 103 auf der TCU 104 sendet.
Die Signaling Nachrichten sind in 4 nicht dargestellt. Die gestrichelten Pfeile stellen die Datenströme 401a, 401b oder Datenverbindungen 401a, 401b dar.
Bei der Sendeanfrage wurden die Anforderungen der Applikation 101'a insbesondere der Applikation 101a bzw. 101b an die Managementvorrichtung 103 übertragen. Diese Anforderungen können beispielsweise die benötigte Datenrate, die benötigte maximale Latenz der Applikation, die Priorität und/oder, falls bekannt, die benötigte Gesamtdatenmenge der aktuell übertragenen Daten sein.
Ändert eine Applikation 101'a während dem Senden einen dieser Werte, informiert sie die TCU 104, insbesondere die Managementvorrichtung 103 mit einer Signaling-Nachricht darüber. So können auch unterschiedliche Prioritäten, die die Applikationen je nach Anwendungsfall haben, sowie sich ändernde Datenraten berücksichtigt werden.
Die Managementvorrichtung 103 beantwortet die Sendeanfrage mit einer positiven oder negativen Antwort. Da die Datenverbindungen 401a, 401b in 4 eingerichtet sind, war die Antwort positiv und die Applikationen der Applikationsvorrichtungen 101a, 101b können Daten senden.
Bemerkt eine End-Applikation 102'a oder Empfänger-Applikation 102'a, also in 4 eine Vehicle Cloud Applikation 102'a, insbesondere eine End- Applikationsvorrichtung 102a, 102b, eine zu geringe Empfangsdatenrate, so sendete die End- Applikationsvorrichtung 102a, 102b eine Signaling-Nachricht an die Managementvorrichtung 103. Die Managementvorrichtung 103 erkennt die Degradation der Empfangsdatenrate mit ihrer Übertragungsqualitätsbestimmungseinrichtung 203.
Anhand der Informationen die die Managementvorrichtung 103 durch die Sendeanfrage von der Quell-Applikationsvorrichtung 101a, 101b übermittelt bekam, kann die Managementvorrichtung 103 nun in der Prioritätsverwaltungseinrichtung 202 berechnen, wie die Aufteilung der Datenrate für die einzelnen Applikationen 101a, 101b bzw. ihre Datenströme 401a, 401b aussehen soll. Das Hauptkriterium für die Aufteilung der Datenrate ist die Priorität der Applikationen 101a, 101b. Dabei wird als ein Auswahlkriterium vorgegeben, die Datenrate so aufzuteilen, dass die wichtigsten Applikationen ihre Anforderungen erfüllen können. Als ein weiteres Auswahlkriterium mag dem Hauptauswahlkriterium untergeordnet vorgegeben werden, die Datenrate so aufzuteilen, dass möglichst viele Applikationen gleichzeitig ausgeführt werden können. Sind Informationen wie die Gesamtdatenmenge vorhanden, kann zusätzlich abgeschätzt werden, wie lange eine Datenübertragung voraussichtlich noch dauert.
Ist diese Berechnung für alle Applikationen abgeschlossen, sendet die Managementvorrichtung 103 auf der TCU 104 das Ergebnis ihrer Berechnung an die jeweiligen Fahrzeug-Applikationen 101'a, insbesondere an die Quell-Applikationen 101'a, und/oder deren Applikationsvorrichtungen 101a, 101b. In der für das Versenden genutzten Signalisierungsnachricht oder Signaling Nachricht ist enthalten, mit welcher Datenrate die Applikationen und/oder deren Applikationsvorrichtungen 101a, 101b maximal noch senden dürfen.
Die Applikationsvorrichtungen 101a, 101b reduzieren mittels ihrer Datenratenüberwachungseinrichtungen 302 dann aufgrund der Signaling Nachricht von der Managementvorrichtung 103, wenn nötig, ihr Sendeverhalten. Durch diese Reduktion stehen wichtigeren Applikationen mehr Ressourcen zur Verfügung, sodass diese ihre Netzwerkanforderungen wieder erfüllen können.
Die 5 zeigt ein Blockschaltbild zweier Datenverbindungen 501a, 501b in einem Fahrzeugkommunikationssystem 100 gemäß einem exemplarischen Ausführungsbeispiel der vorliegenden Erfindung.
Bei den Datenverbindungen 501a, 501b handelt es sich um eine Cloud-to-Car-Kommunikation, bei der die erste Cloud-Car-Datenverbindung 501a von der Quell-Applikation 102a bzw. 102'a zu der End-Applikation 101a bzw. 101'a eingerichtet ist. Die zweite Cloud-Car-Datenverbindung 501b ist von der Quell-Applikation 102b zu der End-Applikation 101b eingerichtet.
In anderen Worten sind im Vergleich zu 4 die Rollen der Vehicle Cloud Applikationen 102'a, insbesondere deren Applikationsvorrichtungen 102a, 102b und der Fahrzeug-Applikationen 101'a, insbesondere deren Applikationsvorrichtungen 101a, 101b, vertauscht. Für die jeweiligen Signalisierungsnachrichten mag jedoch entsprechendes wie bei 4 beschrieben unter Berücksichtigung der Rollenverteilung gelten.
Die Signalisierung von der Managementvorrichtung 103 an die jeweilige Quell-Applikation 101'a bzw. 102'a insbesondere an deren Applikationsvorrichtungen 101a, 101b bzw. 102a, 102b, kann sowohl bei Car-to-Cloud-Kommunikation als auch bei Cloud-to-Car-Kommunikation, durch die zwei unterschiedliche Signalisierungsstrategien implizite Freigabe und implizite Drosselung erfolgen.
Wird bei der impliziten Freigabe nichts signalisiert, gibt es keinerlei Einschränkungen für die Applikationen in ihrem Sendeverhalten. Eine Signalisierung findet im Wesentlichen nur statt, wenn eine Applikation ihre Datenrate einschränken soll.
Bei der impliziten Drosselung wird der Applikation signalisiert, dass es für einen vorgebbaren Zeitraum erlaubt ist, mit einer vorgebbaren Datenrate zu senden, es wird also die Freigabe signalisiert. Wird den Applikationen nichts signalisiert, ist es diesen auch nicht erlaubt zu senden.
Dadurch, dass bei der impliziten Freigabe eine Signalisierungsnachricht nur gesendet wird, wenn die Datenrate eingeschränkt werden soll, ist der Overhead an Nachrichten, die ausgetauscht werden müssen, geringer als bei der impliziten Drosselung. Eine implizite Freigabe ist somit mit wenig Aufwand realisierbar und hat einen geringeren Overhead als eine negative Freigabe durch die implizite Drosselung.
Implizite Freigabe und implizite Drosselung können sich jedoch bei eingeschränkter Verbindungsqualität oder eingeschränkter Kanalqualität unterschiedlich verhalten.
Ist nämlich die Qualität der Verbindung schlecht, muss im Falle der impliziten Freigabe ein Signal an einige Applikationen gesendet werden, um zu erreichen, dass diese ihre Datenrate drosseln. Aufgrund der schlechten Verbindungsqualität kann es passieren, dass die Signalisierungsnachricht zur Drosselung verloren geht oder gar nicht übertragen wird. Eine zuverlässige Signalisierung kann somit nicht immer angenommen werden, insbesondere, wenn die Signalisierung über eine mobile Verbindung mit schwankender Kanalqualität übertragen wird.
Geht bei der impliziten Drosselung durch die schlechte Verbindungsqualität eine Signalisierungsnachricht verloren, so stellt die Applikationen nach der in der ursprünglichen Signalisierungsnachricht festgelegten Zeit automatisch das Senden ein oder schränkt die Sendedatenrate ein. Die implizite Drosselung kann somit die Sicherheit bieten, dass Applikationen trotz schlechter Verbindung zuverlässig in ihrem Sendeverhalten eingeschränkt werden können.
In beide Datenflussrichtungen, Car-to-Cloud Kommunikation und Cloud-to-Car Kommunikation, ist die Signalisierung von der Managementvorrichtung 103 in Richtung der Quell-Applikation 101'a, 102'a gerichtet, hat aber je nach Datenflussrichtung unterschiedliche Auswirkungen.
Bei der Datenflussrichtung der Datenströme 401a, 401b von der Fahrzeug-Applikation zu der Vehicle Cloud Applikation, also bei Car-to-Cloud Kommunikation, findet die Signalisierung zur Drosselung von der Managementvorrichtung 103 zu der Quell-Applikationsvorrichtung 101a, 101b im Wesentlichen auf der Fahrzeugseite 107a statt, so dass im Wesentlichen keine volatile und mobile Übertragungsstrecke überwunden werden muss. Daher kann bei der Datenflussrichtung Fahrzeug zur Vehicle Cloud oder Car-to-Cloud die implizite Freigabe verwendet werden und der geringe Datenoverhead der entsprechenden Signalisierung genutzt werden.
Bei der Datenflussrichtung der Datenströme 501a, 501b Vehicle Cloud zum Fahrzeug muss die Managementvorrichtung 103 den Vehicle Cloud Applikationen 102'a als Quell-Applikationen signalisieren mit welcher Datenrate sie jeweils senden dürfen. Dazu muss die Signalisierungsnachricht die volatile und mobile Übertragungsstrecke 106 überwinden, wodurch sich die Gefahr eines Verlustes ergeben kann. Daher mag für die Datenflussrichtung Vehicle Cloud zum Fahrzeug oder Cloud-to-Car bevorzugt die implizite Drosselung verwendet werden.
Um Vehicle Cloud Applikationen 102'a, insbesondere um die Applikationsvorrichtung 102a, 102b mit Vehicle Cloud Applikationen auf der Vehicle Cloud Seite 107b zu drosseln, bietet es sich an, die Signalisierung basierend auf dem MQTT Protokoll durchzuführen. Die Managementvorrichtung 103 und/oder die TCU 104 und auch die Vehicle Cloud Applikationen 102a, 102b sind nämlich ggf. bereits als MQTT-Clients ausgeführt. Eine zusätzliche Implementierung ist also nur für das Einschränken oder Drosseln der Datenrate notwendig. In anderen Worten mag es im Wesentlichen lediglich notwendig sein, die Signalisierung über das bereits vorhandene MQTT Protokoll auf einer Applikationsvorrichtung 102a, 102b mit Vehicle Cloud Applikationen zu implementieren.
Innerhalb des Fahrzeuges, d.h. auf Fahrzeugseite 107a, und insbesondere für Applikationsvorrichtungen 101a, 101b mit Fahrzeug-Applikationen mag es aufwendig oder nicht sinnvoll sein, eine Signalisierung über das MQTT Protokoll zu implementieren, da nicht alle Fahrzeug-Applikationen, insbesondere deren Applikationsvorrichtungen 101a, 101b, als MQTT-Clients ausgebildet sind. Außerdem könnte es passieren, dass bei einem Signaling über MQTT die Signalisierungs-Nachrichten über den Broker 105 weitergeleitet werden. Dies könnte dazu führen, dass die Signaling Nachrichten nicht nur innerhalb des Fahrzeuges auf der Fahrzeugseite 107a, sondern auch außerhalb weitergeleitet werden. Das Verwenden unterschiedlicher Protokolle für die Signalisierung auf der Fahrzeugseite 107a und auf der Cloud Seite 107b, kann ein ungewünschtes Verbreiten einer Nachricht off-board verhindern.
Somit mag vorgesehen sein, dass zwischen der Managementvorrichtung 103 und den Fahrzeug-Applikationen 101'a, insbesondere den Applikationsvorrichtungen 101a, 101b mit Fahrzeug-Applikationen ein anderes Layer-4-Protokolle als MQTT genutzt wird. Für die Signalisierung in die Richtung einer Fahrzeug-Applikation 101'a mag daher ein Automotive Protokoll wie SOME/IP genutzt werden. SOME/IP wird beispielsweise auf den Applikationsvorrichtungen 101a, 101b mit Fahrzeug-Applikationen verwendet, um Daten zwischen den Steuergeräten 101', 101" und der TCU 104 auszutauschen. Der zusätzliche Implementierungsaufwand für ein Signalisierungsprotokoll würde sich dann auch in diesem Fall, d.h. bei der Signalisierung der Managementvorrichtung 103 in Richtung einer Fahrzeug-Applikation 101'a auf die Implementierung der Signalisierung für die Einschränkung oder Drosselung der Datenrate auf dem bereits vorhanden Automotive Protokoll beschränken.
Die Applikationskommunikationseinrichtung 201 der Managementvorrichtung 103 ist so eingerichtet, dass sie der Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c eine aus der Priorität und der Übertragungsqualität bestimmte einzuhaltende Datenrate mitteilt. Diese Mitteilung einer Datenrate mag eine Reduktion der Datenrate oder Drosselung der Datenrate einer Quell- Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c bedeuten.
Zur Drosselung mag die Managementvorrichtung 103 ein Verfahren zum Managen einer Priorität einer Datenübertragung ausführen. Der Algorithmus dieses Verfahrens mag vorsehen, in einer Engpasssituation oder bei schlechter Kanalqualität die Entscheidung zu treffen, welche Applikationen 101'a, 102'a wie stark gedrosselt werden sollen. Der Algorithmus mag weiter vorsehen, niedrig priorisierte Applikationen so zu drosseln, dass wichtigere Applikationen noch möglichst gut funktionieren, d.h. im Wesentlichen ihre benötigte Datenrate oder Bandbreite erhalten und/oder beibehalten. Der Algorithmus wird in der Managementvorrichtung 103 beispielsweise auf der TCU 104 ausgeführt und kann für diese Entscheidung auf zuvor erhobene Informationen zurückgreifen.
Eine der Informationen, die der Algorithmus benötigt, um seine Entscheidung treffen zu können, ist die Priorität der unterschiedlichen Applikationen 101'a. 102'a.
Eine Liste aller Prioritäten kann entweder aufgebaut werden, wenn die Applikationen ihre Priorität an die Managementvorrichtung 103 senden, beispielsweise bei dem Signalisieren eines Übertragungswunsches der Quell-Applikation an die Managementvorrichtung 103. Eine Quell-Applikation kann ihre Priorität in Abhängigkeit der Daten dynamisch anpassen, welche sie verschicken möchte. Hierzu kann eine dynamische Liste entsprechend der Tabelle 1 gepflegt werden.
Alternativ oder ergänzend zu der dynamischen Prioritätsliste mag die Managementvorrichtung 103, eine im Wesentlichen statische Liste mit Applikationen und deren Priorität vorhalten. In diesem Fall ist es nicht nötig, dass die Applikationen ihre Priorität an die Managementvorrichtung 103 senden. Allerdings kann mittels einer statischen Liste pro Applikation nur eine Priorität festgelegt werden. Unterschiedliche Prioritäten pro Applikation sind somit nicht möglich.
Ein Vorschlag für die Einteilung der Applikationen in acht fixe Prioritätsklassen ist in Tabelle 1 aufgeführt. Einige Applikationen können aufgrund der unterschiedlichen Priorität, mit der diese Applikationen Daten versenden können, mehrfach in der Liste vorhanden sein.
Applikationen können stetig oder diskret gedrosselt werden. Applikationen wie Videostreams können beispielsweise im Wesentlichen nur in diskreten Schritten sinnvoll gedrosselt werden. Videostreams liegen nämlich meist in mehreren unterschiedlichen Qualitätsstufen vor. Reicht die Datenrate einer Qualitätsstufe aufgrund von Netzwerkeinschränkungen oder Degradation nicht mehr aus, so wird eine niedrigere Qualitätsstufe mit geringerer Datenübertragungsrate verwendet, deren Anforderungen an den Übertragungskanal noch erfüllt sind. Andere Applikationen können stetig gedrosselt werden, wie beispielsweise das Downloaden von Updates oder von anderen zeitunkritischen Daten.
Alternativ oder in Ergänzung zur Drosselung mag das Einhalten einer von der Managementvorrichtung 103 mittels der Datenratenüberwachungseinrichtung 302 durch das Einhalten einer Datenrate eines Bündels von Applikationen realisiert werden. Hierzu mag eine Vielzahl von Applikationen mit einer Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c verbunden sein, wobei die Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c von der Managementvorrichtung 103 gesteuert wir. Insbesondere mag die Managementvorrichtung 103 der Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c eine Gesamtdatenrate für das Bündel von Applikationen vorgeben. Solch eine Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c kann als ECU 101', 101" ausgebildet sein, welche die Vielzahl der Fahrzeug-Applikationen zusammenfasst.
Für das Einhalten einer Datenrate eines Bündels von Applikationen mag die Datenratenüberwachungseinrichtung 302 ein Traffic Shaping durchführen. Das Traffic Shaping mag hierbei nicht direkt in jeder einzelnen Applikation oder Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c durchgeführt werden, sondern lediglich auf der zusammenführenden Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c, insbesondere auf der ECU 101', 101". Alternativ könnte solch eine zusammenführende Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c auch auf einer TCU 104 implementiert sein, da über eine TCU im Wesentlichen alle Daten der Applikationen ausgetauscht werden.
Das Betrachten eines Bündels von Applikationen bzw. deren Datenströme mag vermeiden, dass in den einzelnen Applikationen und insbesondere in den einzelnen Applikationsvorrichtungen 101a, 101b, 101c, 102a, 102b, 102c die Funktionalität der Sendedrosselung, insbesondere des Traffic Shapings, implementiert werden muss.
Bei der Car-to-Cloud Kommunikation wird die Engpasssituation oder die Degradation des Übertragungskanals in einer der Vehicle Cloud Applikationen 102'a erkannt, welche als End-Applikation eines Car-Cloud-Datenstroms 401a, 401b dient. Ist die Empfangsdatenrate einer Vehicle Cloud Applikation 102'a zu gering, so benachrichtigt sie die Managementvorrichtung 103 beispielsweise auf der TCU 104 darüber. Die Managementvorrichtung 103 analysiert die Datenrate aller Applikationen des Bündels, welche Daten an die Vehicle Cloud senden.
Auch beim Traffic Shaping wird über eine interne Liste in der Managementvorrichtung 103 die Priorität jeder einzelnen Applikation des Bündels von Applikationen bestimmt. Die Managementvorrichtung 103 hat für das Traffic Shaping die Information über die aktuelle Datenrate aller Applikationen 101'a, 102'a die an einem Bündel von Applikationen beteiligt sind sowie deren Priorität. Um die gesamte Bündeldatenrate der Vielzahl von Applikationen vorzugeben, welche die Datenratenüberwachungseinrichtung 302 einhalten soll, berechnet die Managementvorrichtung 103 mit der Prioritätsverwaltungseinrichtung 202 die neue maximale Datenrate jeder einzelnen an dem Bündel beteiligten Applikation. Der berechnete Wert wird an die Applikationsvorrichtungen 101a, 101b, 101c, 102a, 102b, 102c signalisiert, welche mit der Datenratenüberwachungseinrichtung 302 dafür sorgt, dass die gesamte vorgegebene Bündeldatenrate nicht überschritten wird.
Senden einzelne Applikationen des Bündels über ihrer berechneten maximalen Datenrate, so werden sie von der Datenratenüberwachungseinrichtung 302 unter Einsatz von Traffic Shaping gedrosselt. Das Traffic Shaping kann beispielsweise mit einem Leaky Bucket Algorithmus realisiert werden. Dabei ist drauf zu achten, dass die Puffer-Größe richtig bemessen ist, um die Verzögerung der Netzwerkpakete nicht zu stark zu erhöhen. Durch die Drosselung bestimmter Applikationen mit niedriger Priorität können höher priorisierte Applikationen ihre Anforderungen wieder erfüllen.
Grundsätzlich können bei Fahrzeug-Applikationen, die keine MQTT-Clients sind und somit nicht das MQTT Protokoll nutzen, zwei verschiedene Traffic Shaping Vorgehensweisen unterschieden werden. Die Daten von Fahrzeug-Applikationen, die keine MQTT-Clients sind, werden in der TCU 104 oder in der Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c von dem SOME/IP Protokoll in das MQTT "Protokoll übersetzt. Dazu bietet die TCU 104 oder die Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c eine Gateway-Funktionalität mit Protokollumsetzung.
Es werden also mehrere Datenströme von mehreren Fahrzeug-Applikationen in ein Bündel zusammengeführt und in einem einzelnen MQTT/TCP-Stream an die Vehicle Cloud 107b gesendet. Sollen diese Fahrzeug-Applikationen gedrosselt werden, kann das Traffic Shaping entweder auf die ankommenden Daten, d.h. Ingress-Traffic-Shaping, und/oder auf die abgehenden Daten, d.h. Egress-Traffic-Shaping, in der TCU 104 oder in der Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c angewendet werden. Die TCU 104 oder die Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c würde durch das Ingress-Traffic-Shaping die einzelnen Fahrzeug-Applikationen so drosseln, dass sie nur mit der erlaubten Datenrate senden.
Beim Egress-Traffic-Shaping, wird das Traffic-Shaping in Abhängigkeit der Applikation bei der Übersetzung in das MQTT-Protokoll auf Applikationsebene durchgeführt. Die Applikationen können anhand des MQTT-Topics unterschieden werden. Beim Egress-Traffic-Shaping kann die Datenrate des ausgehenden MQTT-Datenstroms mit einer hohen Genauigkeit gesteuert werden.
Die Cloud-to-Car Kommunikation unterscheidet sich im Wesentlichen kaum von der Car-to-Cloud Kommunikation. Lediglich die Datenflussrichtung 501a, 501b ist entgegengesetzt. Die Erkennung der Engpasssituation oder die Degradation des Übertragungskanals findet in den einzelnen Fahrzeug Applikationen 101'a statt, und wird an die Managementvorrichtung 103 signalisiert, welche sich auf der TCU 104 befinden kann.
Die Managementvorrichtung 103 analysiert dann alle eingehenden Datenflows welche ein Bündel bilden. Das Bündel mag auch auf der TCU 104 gebildet werden oder auf speziellen Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c auf der Vehicle Cloud Seite 107b, welche eine Vielzahl von Datenflows zu einem Bündel zusammenfassen. Zur Analyse identifiziert die Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c und/oder die TCU 104 die Applikationen über ein 4-Tupel aus Quell-IP, Ziel-IP, Quell-Port sowie Ziel-Port. Das verwendete Protokoll, das normalerweise beim TCP 5-Tupel verwendet wird, ist bei allen Flows gleich.
Über diese 4-Tupel wird die einzelne Applikation erkannt und die Priorität des Flows 501a, 501b kann so über eine interne Liste auf der Managementvorrichtung 103 festgestellt werden. Mit diesen Informationen kann die Managementvorrichtung 103 oder der Network Governor 103 berechnen, welche Applikationen 102'a wie gedrosselt werden sollen.
Die Drosselung findet über Traffic Shaping auf der speziellen Applikationsvorrichtung 101a, 101b, 101c, 102a, 102b, 102c statt, beispielsweise über einen Leaky Bucket Algorithmus. Dabei ist drauf zu achten, dass die Puffer-Größe richtig bemessen ist, um die Verzögerung der Netzwerkpakete nicht zu stark zu erhöhen.
Durch die Drosselung bestimmter Applikationen 102'a können andere Applikationen ihre Anforderungen an die Netzwerkkommunikation wieder erfüllen.
Obwohl die Erfindung im Detail durch bevorzugte Ausführungsbeispiele näher illustriert und erläutert wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen. Es ist daher klar, dass eine Vielzahl von Variationsmöglichkeiten existiert. Es ist ebenfalls klar, dass beispielhaft genannte Ausführungsformen wirklich nur Beispiele darstellen, die nicht in irgendeiner Weise als Begrenzung etwa des Schutzbereichs, der Anwendungsmöglichkeiten oder der Konfiguration der Erfindung aufzufassen sind. Vielmehr versetzen die vorhergehende Beschreibung und die Figurenbeschreibung den Fachmann in die Lage, die beispielhaften Ausführungsformen konkret umzusetzen, wobei der Fachmann in Kenntnis des offenbarten Erfindungsgedankens vielfältige Änderungen, beispielsweise hinsichtlich der Funktion oder der Anordnung einzelner, in einer beispielhaften Ausführungsform genannter Elemente, vornehmen kann, ohne den Schutzbereich zu verlassen, der durch die Ansprüche und deren rechtliche Entsprechungen, wie etwa weitergehenden Erläuterungen in der Beschreibung, definiert wird.
Bezugszeichenliste

100: Fahrzeugkommunikationssystem
101a, 101b, 101c: Applikationsvorrichtung mit Fahrzeug-Applikationen
101'a: Fahrzeug-Applikation
101', 101": ECU
102a, 102b, 102c: Applikationsvorrichtung mit Vehicle Cloud Applikationen
102'a: Vehicle Cloud -Applikation
103: Managementvorrichtung
104: TCU
105: MQTT Broker
106: Internet
107a: Fahrzeugseite
107b: Vehicle Cloud Seite
108: Fahrzeugnetzwerk
201: Applikationskommunikationseinrichtung
202: Prioritätsverwaltungseinrichtung
203: Übertragungsqualitätsbestimmungseinrichtung
301: Managementkommunikationseinrichtung
302: Datenratenüberwachungseinrichtung
401a, 401b: Datenverbindung Car-to-Cloud
501a, 501b: Datenverbindung Cloud-to-Car

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 Patentliteratur

DE 102014200226 A1 [0009]

Claims

Managementvorrichtung (103) für ein Fahrzeugkommunikationssystem (100), aufweisend: eine Applikationskommunikationseinrichtung (201); eine Prioritätsverwaltungseinrichtung (202); eine Übertragungsqualitätsbestimmungseinrichtung (203); dadurch gekennzeichnet, dass die Applikationskommunikationseinrichtung (201) eingerichtet ist, mit einer Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) zu kommunizieren; die Prioritätsverwaltungseinrichtung (202) eingerichtet ist, eine Priorität einer auf der Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) ausgeführten Applikation (101'a, 102'a) zu verwalten; die Übertragungsqualitätsbestimmungseinrichtung (203) eingerichtet ist, eine Übertragungsqualität eines von der Applikation (101'a, 102'a) genutzten Übertragungskanals (401a, 401b, 501a, 501b) zu bestimmen; und die Applikationskommunikationseinrichtung (201) eingerichtet ist, der Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) eine aus der Priorität und der Übertragungsqualität bestimmte Datenrate mitzuteilen.
Managementvorrichtung (103) nach Anspruch 1, wobei die Priorität auch eine benötigte Datenrate der Applikation (101'a, 102'a), eine benötigte maximale Latenz der Applikation (101'a, 102'a) und/oder eine benötigte Gesamtdatenmenge der Applikation (101'a, 102'a) berücksichtigt.
Managementvorrichtung (103) nach Anspruch 1 oder 2, wobei die Managementvorrichtung (103) auf einer TCU, einem Datenrouter und/oder einem MQTT-Broker implementiert ist.
Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) für ein Fahrzeugkommunikationssystem (100), auf der eine Applikation (101'a, 102'a) ausgeführt wird, aufweisend: eine Managementkommunikationseinrichtung (301); eine Datenratenüberwachungseinrichtung (302); dadurch gekennzeichnet, dass die Managementkommunikationseinrichtung (301) eingerichtet ist, mit einer Managementvorrichtung (103) zu kommunizieren und eine Datenrate zu erhalten; die Datenratenüberwachungseinrichtung (302) eingerichtet ist, die erhaltene Datenrate einzuhalten.
Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) nach Anspruch 4, wobei die Applikation (101'a, 102'a) eine Fahrzeug-Applikation (101'a) oder eine Cloud Applikation (102'a) ist.
Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) nach Anspruch 4 oder 5, wobei die Datenratenüberwachungseinrichtung (302) eingerichtet ist, eine Datenrate eines Bündels von Applikationen (101'a, 102'a) einzuhalten.
Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) nach einem der Ansprüche 4 bis 6, wobei die Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) als ECU (101', 101") ausgebildet ist.
Fahrzeugkommunikationssystem (100), aufweisend: eine Managementvorrichtung (103) nach einem der Ansprüche 1 bis 3; eine Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) nach einem der Ansprüche 4 bis 7; dadurch gekennzeichnet, dass die Managementvorrichtung (103) und die Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) in einer Kommunikationsbeziehung mit einander verbunden sind; die Managementvorrichtung (103) eingerichtet ist, die Datenrate einer auf der Applikationsvorrichtung (101a, 101b, 101c, 102a, 102b, 102c) ausgeführten Applikation (101'a, 102'a) auf Applikationsebene festzulegen.
Verfahren zum Managen einer Priorität einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems, dadurch gekennzeichnet, dass das Verfahren aufweist: Kommunizieren mit einer Applikationsvorrichtung; Verwalten einer Priorität einer auf der Applikationsvorrichtung ausgeführten Applikation; Bestimmen einer Übertragungsqualität eines von der Applikation genutzten Übertragungskanals; Mitteilen einer aus der Priorität und der Übertragungsqualität bestimmte Datenrate an die Applikationsvorrichtung.
Verfahren zum Einhalten einer Datenrate einer Datenübertragung einer Applikation eines Fahrzeugkommunikationssystems, dadurch gekennzeichnet, dass das Verfahren aufweist: Kommunizieren mit einer Managementvorrichtung; Erhalten einer Datenrate der Applikation; Einhalten der erhaltene Datenrate.