-
Die Erfindung betrifft ein Verfahren zum Übertragen von Daten von einem fahrzeugexternen Server zu mit diesem in Kommunikationsverbindung stehenden Fahrzeugen nach der im Oberbegriff von Anspruch 1 näher definierten Art.
-
Die Erfindung stammt aus dem Gebiet der Telematik und der Assistenzsysteme und beschreibt ein Verfahren zur Übertragung von Daten von einem fahrzeugexternen Server, insbesondere einem sogenannten Vehicle Backend, zu Fahrzeugen eines Fahrzeug-Ökosystems, welche mit diesem Vehicle Backend in Kommunikationsverbindung stehen. Die Kommunikationsverbindung wird dabei typischerweise über ein Mobilfunknetz aufgebaut.
-
Derart vernetzte Fahrzeuge, welche mit einem zentralen Vehicle Backend verbunden sind, sind damit aus dem Stand der Technik bekannt. Der Betrieb eines solchen Systems wird fortlaufend in Bezug auf Kosten und Effizienz optimiert, um auch große Fahrzeugflotten mit entsprechenden Diensten wie beispielsweise Verkehrsdiensten, Kartenaktualisierungsdiensten und dergleichen mit hoher Aktualität versorgen zu können.
-
Die Offenlegung
DE 10 2020 003 281 A1 beschreibt ein Verfahren zum Betreiben eines Systems aus einer Vielzahl von Kraftfahrzeugen. Die Offenlegungsschrift betrifft ein Verfahren zum Betreiben eines derartigen Systems aus einer Vielzahl von Kraftfahrzeugen, wobei ein jeweiliges Kraftfahrzeug eine jeweilige Datendienstabfrage an eine elektronische Recheneinheit, wie z.B. den Vehicle Backend,des Systems übermittelt und wobei in Abhängigkeit von einem syntaktischen Kriterium innerhalb der elektronischen Recheneinrichtung die jeweilige Dienstabfrage bearbeitet wird. Zusätzlich erfolgt die Bearbeitung in Abhängigkeit von einem semantischen Kriterium des von dem System angebotenen Dienstes. Dabei werden Betriebsaspekte beschrieben, die die Verfügbarkeit in Hochlaufphasen etc. für die jeweiligen Dienstarten verbessert steuern können.
-
Ein weiterer Aspekt, welcher insbesondere für Datenübertragungskosten und -effizienz von großer Bedeutung ist, ist die Art der Datenkompression der zwischen dem Vehicle Backend und den Fahrzeugen der Fahrzeugflotte übertragenen Daten. Eine standardisierte und bereits millionenfach für die Kompression von Verkehrsdiensten angewendete Kompression ist beispielsweise „gzip“. Eine weitere ist beispielsweise das Kompressionsverfahren „brotli“, bei welchem verschiedene Kompressionslevel angeboten werden. Darüber hinaus ist es bekannt, dass eine stärkere Komprimierung von Daten mit einem höheren Zeitaufwand verbunden ist, mit den höchsten Kompressionsstufen steigt der Zeitbedarf für die Kompression exponentiell an.
-
In der heutigen Dienstewelt der Fahrzeug-Ökosysteme mit einem Vehicle Backend und mit diesem in Kommunikationsverbindung stehenden Fahrzeugen werden verschiedene Datenarten an die Fahrzeugflotte übertragen, deren Rohdatenformat textuell, codiert oder bildbasiert sein kann. Typische Beispiele sind im Bereich der Navigation zu finden, insbesondere Verkehrsdienste oder Kartendaten zur Aktualisierung der Fahrzeugnavigation.
-
Die Aufgabe der hier vorliegenden Erfindung ist es nun, ein verbessertes Verfahren zur Übertragung von Daten von einem fahrzeugexternen Server, also dem Vehicle Backend, zu diesen, insbesondere über ein Mobilfunknetz, in Kommunikationsverbindung stehenden Fahrzeugen anzugeben, wobei die Daten entsprechend komprimiert werden und das Verfahren eine optimierte Übertragung sicherstellen soll.
-
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1, und hier insbesondere im kennzeichnenden Teil des Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen des Verfahrens ergeben sich aus den hiervon abhängigen Unteransprüchen.
-
Bei dem erfindungsgemäßen Verfahren ist es so, dass die zwischen dem fahrzeugexternen Server und den Fahrzeugen übertragenen Daten zur Übertragung komprimiert werden. Der fahrzeugexterne Server, welcher auch als Vehicle Backend bezeichnet werden kann, verwaltet und nutzt dabei zwei verschiedene Arten von Kompressionsverfahren und/oder zumindest ein Kompressionsverfahren mit mindestens zwei unterschiedlichen Kompressionsstufen. Es liegen also verschiedene Kompressionsverfahren und/oder Kompressionsstufen zumindest bei einem der Verfahren vor. Die Verfahren können rein beispielhaft, und ohne sich auf diese Beispiele zu beschränken, das Verfahren gzip sowie das brotli-Verfahren mit bis zu elf Kompressionsstufen sein.
-
Das erfindungsgemäße Verfahren optimiert die Datenübertragung nun über eine anwendungsspezifische zeitlich-räumliche Auswahl des geeigneten Kompressionsverfahrens. Bei dem erfindungsgemäßen Verfahren werden dabei zur Auswahl des Kompressionsverfahrens, was in diesem Zusammenhang die Kompressionsstufen eines Kompressionsstufen bereitstellenden Verfahrens ausdrücklich einschließt, verschiedene Kriterien genutzt. Diese Kriterien können einzeln, allesamt oder in beliebigen Kombinationen miteinander bei der Auswahl des Kompressionsverfahrens berücksichtigt werden.
-
Die wichtigsten Kriterien sind dabei die Art der Daten, also beispielsweise ob es sich um bildbasierte Kartendaten, um Textdaten oder Ähnliches handelt, sowie die Datenmenge. Die Datenmenge kann beispielsweise zwischen der Übertragung eines Verkehrsdienstes einerseits und einer umfangreichen Kartenaktualisierung andererseits massiv voneinander abweichen. Ferner kann als weiteres Kriterium die aktuelle Datenübertragungsrate der Kommunikationsverbindung berücksichtigt werden. Ist die Kommunikationsverbindung entsprechend schlecht, kann eine höhere Kompression von Vorteil sein, um insgesamt weniger Daten übertragen zu müssen, was dann auch bei einer schlechteren Kommunikationsverbindung noch möglich ist. Ein weiteres Kriterium kann beispielsweise die am jeweiligen Fahrzeug verfügbare Signalstärke der Kommunikationsverbindung sein, welche ähnlich wie die grundsätzliche Datenübertragungsrate eine entscheidende Rolle bei der Übertragung der Daten spielt. So kann beispielsweise in einem 5G-Netz mit hoher Signalstärke eine hohe Datenmenge einfach und schnell übertragen werden, sodass die Kompression entsprechend niedrig gewählt werden kann. Liegt dagegen lediglich ein 3G-Netz vor und dieses hat gegebenenfalls auch noch eine sehr geringe Signalstärke, kann es durchaus von Vorteil sein, auf dem fahrzeugexternen Server etwas mehr Zeit in die Datenkompression zu investieren, um die Daten dann trotz der schlechten Netzverbindung noch übertragen zu können. Ein weiterer insbesondere aus Kundensicht relevanter Aspekt können die Datenübertragungskosten sein. Werden diese nach Zeit oder Datenvolumen abgerechnet, dann kann auch hier eine höhere Kompression von Vorteil sein, um die Kosten entsprechend zu reduzieren.
-
Ein weiterer Aspekt, welcher oben bereits angeklungen ist, ist die für die Kompression oder auch die Dekompression benötigte Zeitspanne. Typischerweise erfolgt die Kompression auf dem fahrzeugexternen Server schneller als in den Endgeräten des Fahrzeugs die Dekompression. Bis die Daten verfügbar in dem Fahrzeug vorliegen, muss jedoch sowohl die Kompression, die Datenübertragung als auch die Dekompression entsprechend erfolgen. Je nachdem, wie „eilig“ die Übertragung der Daten ist, kann hier die für die Kompression benötigte Zeitspanne ebenso wie die für die Dekompression benötigte Zeitspanne eine entscheidende Rolle spielen. Diese kann also ebenfalls mit berücksichtigt werden, sodass bei entsprechend schnell benötigten Daten beispielsweise Verkehrswarnmeldungen auf einem Navigationssystem entsprechend kleinere Kompressionen gewählt werden, um die Übertragung der Daten nicht unnötig zu verzögern.
-
Gemäß einer sehr vorteilhaften Weiterbildung kann es dabei vorgesehen sein, dass die Zeitspanne auf eine von der Art der Daten abhängige Zeitobergrenze begrenzt wird. So kann beispielsweise für Verkehrsdienstdaten eine Zeitgrenze von 20 Sekunden für die Kompression auf dem Vehicle Backend vorgegeben werden, sodass also jeweils die Kompressionsrate bzw. das Kompressionsverfahren ausgewählt wird, welches innerhalb dieser Zeitspanne die, für den jeweiligen Fall maximal vorgesehene Kompression erlaubt.
-
Insbesondere für den Fall, dass verschiedene Kompressionsstufen in wenigstens einem der genutzten Kompressionsverfahren vorliegen, kann es gemäß einer sehr vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ferner vorgesehen sein, dass eine umso höhere Kompressionsstufe, also mit stärkerer Kompression, gewählt wird, je größer die Datenmenge ist, wobei die Steigerung der Kompressionsstufe durch eine vorgegebene Maximalzeit begrenzt wird. Hier ist es nun möglich, bei größeren Datenmengen, insbesondere bei sehr großen Datenmengen, wie sie beispielsweise für Kartenaktualisierungen benötigt werden, in Abhängigkeit der Datenmenge die nach Möglichkeit höchste Kompressionsstufe zu wählen, um die Datenmenge maximal zu verringern. Auch hier kann es sinnvoll sein, beispielsweise eine maximale Zeitspanne für die Kompression vorzugeben, um die Abläufe nicht unnötig stark zu verzögern. Beispielsweise kann eine zeitliche Obergrenze bei Kartenaktualisierungen, welche typischerweise keine große Eilbedürftigkeit haben in der Größenordnung von 100 bis 200 Sekunden oder auch mehreren hundert Sekunden gewählt werden, sodass beispielsweise Kartenaktualisierungsdaten in der Größenordnung von bis zu 20 MB mit brotli-Level 9, bis 40 MB mit brotli-Level 10 und ab 40 MB mit brotli-Level 11 bis zu einer erlaubten Obergrenze von 180 Sekunden Kompressionszeit entsprechend komprimiert werden.
-
Weitere Kriterien, um soweit irgendmöglich die maximale Kompression, und damit bei einem Kompressionsverfahren mit verschiedenen Kompressionsstufen die nach Möglichkeit höchste Kompressionsstufe zu nutzen, liegt dann vor, wenn eine schlechte Signalstärke, eine schlechte Datenübertragungsrate und/oder die Ausbildung der Kommunikationsverbindung in einem ausländischen Mobilfunknetz vorliegt. In solchen Fällen hat vor dem zeitlichen Ablauf die Möglichkeit, die Daten überhaupt an das Fahrzeug übertragen zu können, bzw. im Falle eines ausländischen Netzes die Daten möglichst kostengünstig ohne zusätzliche oder mit minimalen zusätzlichen Roaminggebühren übertragen zu können, Vorrang. In diesem Fall lässt sich dann dementsprechend immer die höchste Kompressionsstufe auswählen.
-
Eine weitere sehr vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens kann es dabei vorsehen, dass die Auswahlregeln anhand einer auf dem fahrzeugexternen Server gespeicherten Auswahltabelle festgelegt werden. Eine solche Festlegung über eine Tabelle ist entsprechend einfach und effizient. So kann beispielsweise je nach Datenart einer Zeitobergrenze bei der Komprimierung und größenabhängigen Stufen einfach das für die jeweilige Anwendung passende Kompressionsverfahren bzw. die innerhalb des Kompressionsverfahrens für die jeweilige Anwendung passenden Kompressionsstufen ausgewählt werden.
-
Gemäß einer sehr vorteilhaften Weiterbildung dieses Aspekts des erfindungsgemäßen Verfahrens kann es dabei ferner vorgesehen sein, dass die Auswahlregeln für die Kompressionsverfahren und/oder Kompressionsstufen fahrzeugspezifisch, datendienstspezifisch und/oder in Abhängigkeit des für das jeweilige Fahrzeug geltenden mobilen Datentarifs angepasst und optimiert werden. Es können hier also für den jeweiligen Datendienst und das jeweilige Fahrzeug bzw. den Fahrzeugtyp spezifische Parameter vorgegeben werden, ebenso wie Kostenparameter hinsichtlich des in dem jeweiligen Fahrzeug geltenden Datentarifs. Hierdurch lässt sich vorzugsweise automatisiert, beispielsweise unter Einsatz künstlicher Intelligenz, eine jeweils individuell angepasste Auswahltabelle für bestimmte Fahrzeuge bzw. für vergleichbare Fahrzeuge als eine Fahrzeuggruppe, entsprechend anpassen.
-
Alles in allem kann so sichergestellt werden, dass durch eine bessere anwendungsspezifische Datenkompression Kostenvorteile bei der Datenübertragung ohne sichtbaren Qualitätsverlust beim Nutzer erzeugt werden. Insbesondere durch eine stärkere Kompression bei vergleichsweise teuren Roaminggebühren lassen sich erhebliche Kostenvorteile generieren. In ähnlicher Weise kann dies auch je nach Netzauslastung bzw. Bandbreitenverfügbarkeit entsprechend erfolgen, um kürzere Übertragungszeiten bei einer kleineren Auslastung für die Transmission und den Empfang des komprimierten Pakets zu erzielen. Durch die verkürzte Transmission und kleinere Datenpakete kann so nämlich auch bei einer relativ schlechten Qualität des Mobilfunknetzes noch ein qualitativ hochwertiger Datenaustausch, wenn auch mit leichter zeitlicher Verzögerung, realisiert werden.
-
Vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens und seiner Anwendungen ergeben sich auch aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figuren näher beschrieben sind.
-
Dabei zeigen:
- 1 ein beispielhaftes Szenario zur Erläuterung der Randbedingungen für das erfindungsgemäße Verfahren; und
- 2 Auswahlregeln für eine anwendungsspezifische zeitlich-räumliche Datenkompression in Form einer Tabelle.
-
In der Darstellung der 1 ist ein beispielhaftes Szenario eines Fahrzeug-Ökosystems, in welchem das erfindungsgemäße Verfahren zum Einsatz kommen kann, exemplarisch dargestellt. Dabei ist eine Fahrzeugflotte 1 mit einer Vielzahl von einzeln nicht näher bezeichneten Fahrzeugen zu erkennen, welche allesamt in einer durch die Striche angedeuteten Kommunikationsverbindung zu einem fahrzeugexternen Server 2, dem sogenannten Vehicle Backend des Fahrzeugherstellungs- bzw. OEMs stehen. Dieser fahrzeugexterne Server ist als Cloud dargestellt. Er wird nachfolgend auch als Vehicle Backend 2 bezeichnet.
-
Der Vehicle Backend 2 verwaltet und nutzt verschiedene Kompressionsverfahren, von welchen zumindest einige verschiedene Kompressionsstufen ermöglichen. Rein beispielhaft können dies die gängigen und bekannten Verfahren gzip und brotli mit bis zu elf Kompressionsstufen sein. Auch weitere Verfahren sind, wie es sich aus der Darstellung der 2 später noch ergeben wird, grundlegend denkbar.
-
Dabei ist es so, dass verschiedene Kompressionsverfahren und/oder verschiedene Kompressionsstufen unterschiedliche Rohdatenformate, beispielsweise textuelle Formate, Bildformate, codierte Formate oder dergleichen unterschiedlich stark komprimieren. Bei Kompressionsverfahren mit mehreren Kompressionsstufen steigt die Kompression mit höherer Kompressionsstufe typischerweise an, sodass die nach der Kompression vorliegende Datenmenge bei höheren Kompressionsstufen kleiner ist als bei niedrigen Kompressionsstufen. Dabei ist es bekannt, dass eine stärkere Komprimierung der Daten mit einem höheren Zeitaufwand zur Komprimierung auf dem fahrzeugexternen Server und später auch zur Dekomprimierung in den einzelnen Fahrzeugen der Fahrzeugflotte 1 einhergeht. Aus dieser Variabilität der Kompressionsverfahren hinsichtlich des Zeitbedarfs und des erreichbaren Kompressionslevels ergibt sich nun, dass diese anwendungsspezifisch optimiert eingesetzt werden können. Dies wird in den nachfolgenden Beispielen anhand von Verkehrs- und Kartenaktualisierungsdiensten detailliert beschrieben.
-
Ein erstes Beispiel ist eine broth-Kompression im Vergleich mit verschiedenen Kompressionsstufen, wobei als Beispieldatei koreanische TPEG-Verkehrsdaten mit 4,4 MByte Binärdaten zum Einsatz kommen. TPEG steht dabei für Transport Protocol Experts Group und bezeichnet ein Übertragungsformat für erweiterte Verkehrs- und Reiseinformationen über digitale Übertragungswege. Aus der 4,4 MByte großen Beispieldatei mit Verkehrsdaten sind je nach Kompressionsstufe 750/780/860 kByte mit brotli, bei maximal 6-facher Komprimierung und ca. 1 MByte bei gzip als komprimierte Datei entstanden. Bei brotli benötigte dies 13,1/8,5/1,9 s, bei gzip 1,8 s. Je stärker die Kompression wird, desto stärker steigt also auch die für die Kompression benötigte Zeitspanne an. Mit sehr starker Kompression, hier also von 4,4 MByte auf 750 kByte ist ein Anstieg auf mehr als 13 s aufgetreten. Die maximale Kompression mit brotli auf 750 kByte entspricht dabei der in etwa 6-fachen Komprimierung und der Kompressionsstufe 11. Die Daten werden damit 25% besser komprimiert als mit dem Kompressionsverfahren gzip bei einer 7,3-fach längeren Zeitdauer. Wenn diese längere Zeitdauer aus Sicht des Dienstes gegenüber dem Kunden akzeptabel ist und ohne Qualitätsverluste bei dem Dienst umgesetzt werden kann, dann können bei der Datenübertragung 25% des Datenvolumens und bei einem volumenabhängigen Datentarif damit 25% der Datenübertragungskosten eingespart werden.
-
Bei einem Verkehrsdienst kann nun außerdem eine Latenzobergrenze für die Zeitspanne zur Kompression in der Größenordnung von beispielsweise 20 s festgelegt werden. Bei einer Kartenaktualisierung, welche weitaus weniger zeitkritisch ist, kann diese maximale Zeitspanne bzw. Latenzobergrenze auch bei mehreren Minuten liegen. Dabei ist es so, dass für verschiedene Märkte von Verkehrsdiensten die einzelnen Kompressionsverfahren verschieden leistungsfähig sind. Zur Art der komprimierten Daten gehört also auch letztlich ihre Herkunft. Das zuvor beschriebene Beispiel basierte auf einer koreanischen Datei mit TPEG-Verkehrsdaten. Das nachfolgende Beispiel soll nun auf einer deutschen TPEG-Verkehrsdatendatei basieren. Komprimiert man diese Datei mit einer Grundgröße von knapp 0,5 MByte Verkehrsdaten, sind je nach Stufe 158/163/179/179 kByte mit brotli bei einer maximalen dreifachen Komprimierung und ca. 193 kByte mit gzip zu erzielen. Bei brotli dauert dieser Vorgang 1,8/0,7/0,25/0,21 s, bei gzip 0,27 s. Auch hier es wieder so, je stärker die Kompressionsrate steigt, desto länger benötigt man für die Kompression. Man sieht hier jedoch auch, dass es grundlegend von den Ausgangsdaten abhängig. Man kann hier mit brotli in der höchsten Kompressionsstufe 11 lediglich 19% besser als mit gzip komprimieren und dies bei einer 6,5-fach längeren Zeitdauer. Wenn man das aus Dienstesicht gegenüber dem Kunden ohne Qualitätsverlust akzeptieren kann, dann kann man hier pro Anfrage 19% der Datenübertragungskosten im Falle eines volumenbasierten Datentarifs einsparen. Die Einsparung liegt dabei niedriger als bei den zuvor genannten koreanischen Daten als Ausgangsbasis.
-
Prinzipiell ist es so, dass die elf möglichen Kompressionsstufen eine Komprimierung der Primärdatei auf 42% (Stufe 1) bis 32% (Stufe 11) ermöglichen. Bei brotli ist mit Stufe 11 also eine um 25% stärkere Datenreduzierung machbar. Bei einem Preis von 0,50 cent/GByte Daten, vier Fahrten pro Tag mit je zehn Anfragen zu 200 kByte, in Summe als 2 MByte pro Tag und Fahrzeug, bei einer Million Fahrzeugen in der Fahrzeugflotte 1 ergeben sich so 2000 GByte pro Tag in der Fahrzeugflotte 1. Dies führt zu 1000 Euro pro Tag an Kosten. Eine Einsparung von 250 Euro durch eine bessere Kompression führt dann zu einer Einsparung von 90.000 Euro pro Jahr nur bei den Verkehrsdiensten. Bei einem Kartenupdate, welches ein Vielfaches mehr an Datenmenge beinhaltet, vervielfacht sich diese Einsparung dementsprechend. Fährt ein Fahrzeug darüber hinaus ins Ausland, können, zumindest bei einer Fahrt außerhalb der Europäischen Union, zusätzlich erhebliche Roamingkosten anfallen, die dann ebenfalls bis zu 25% eingespart werden können.
-
Nachfolgend soll nun ein weiteres Beispiel zur Kompression einer Kartendatei erläutert werden. Diese Kartendatei stellt ein 32tel eines digitalen Kartenlayers für Stuttgart dar und umfasst eine Datenmenge von ca. 96,4 kByte. Auch hier werden aus den knapp 100 kByte Kartendaten je nach Stufe 77,8/76,7/75,3/74,1 kByte mit brotli, bei maximal dreifacher Komprimierung. Bei gzip erfolgt die Komprimierung auf ca. 79,5 kByte. Bei brotli dauert dies 0,167/0,176/ 0,339/0,645 s, bei gzip 0,096 s. Auch hier sieht man wieder, dass es grundlegend von den Ausgangsdaten abhängt. Man kann also auch mit der höchsten Kompressionsstufe 11 bei brotli in diesem Fall lediglich 7% an Vorteil gegenüber gzip erreichen, wobei dies mit einer 6,7-fach längeren Zeitdauer erkauft wird. Auch hier lassen sich wieder 7% der Datenübertragungskosten gemäß den obigen Beispielen einsparen, wenn die zusätzliche Zeitdauer aus Dienstesicht gegenüber dem Kunden zu rechtfertigen und ohne Qualitätsverlust ist. Die Zeitspanne für die erforderliche Kompression steigt auch hier wieder an. Alles in allem gibt es damit anwendungsspezifisch, datenspezifisch und in Abhängigkeit des jeweiligen Datentarifs also Punkte, an denen für deutlich mehr eingesetzte Zeit zum Komprimieren, was immer auch bedeutet, dass diese Zeit zum späteren Dekomprimieren erneut benötigt wird, eine kaum verbesserte Kompression eintritt. Dies ist dabei stark anwendungsabhängig.
-
Die soeben angesprochene Dekompression erfolgt typischerweise in dem Fahrzeug. Dort liegen die Ressourcen und die Rechenleistung im Allgemeinen auf einem sehr viel niedrigerem Niveau als im Bereich des Vehicle Backends 2. Deshalb muss davon ausgegangen werden, dass die Zeit für die Dekompression typischerweise größer als die Zeit für die Kompression ist, je nach Gerätespezifikation und Leistung. Im Allgemeinen kann von einer Größenordnung von zwei ausgegangen werden, also von einem in etwa doppelten Zeitbedarf für die Dekompression im Vergleich zu dem für die Kompression.
-
Die Art der eingesetzten Kompression, also das Kompressionsverfahren und/oder die eingesetzte Kompressionsstufe sollte in dem Vehicle Backend 2 also anwendungsspezifisch, dienstespezifisch und räumlich/zeitlich gesteuert werden. Hierfür kann eine Tabelle vorgesehen sein, welche auch in Abhängigkeit weiterer Parameter angepasst werden kann, beispielsweise für bestimmte Fahrzeuggruppen, bestimmte Datenverträge oder dergleichen.
-
In der Darstellung der 2 ist nun eine solche Tabelle beispielhaft dargestellt, um eine mögliche Vorgehensweise darzulegen.
-
In der Spalte 1 ist dabei aufgeführt, um welchen Dienst es sich handelt. Hier sind beispielhaft Verkehrsdienste mit TPEG, Verkehrsdienste mit XML oder JSON (Extensible Markup Language, Java Script Open Notation) aufgeführt, ein Kartenupdate mit sogenannten Kartenkachein, ein Kartenupdate mit einem Streaming großer Gebiete oder ein Parkinformationsdienst. Wie es durch die Punkte angedeutet ist, kann die Tabelle auch weiter fortgesetzt werden. In der zweiten Spalte ist dann das geeignete oder sind die geeigneten Kompressionsverfahren angegeben. Dies kann beispielsweise bei den Verkehrsdiensten mit TPEG, brotli oder gzip sein, im Falle von brotli sind in der nächsten Spalte die Kompressionsstufen 5 bis 11 angegeben und es ist eine Zeitobergrenze bei der Komprimierung angegeben. Dementsprechend wird also die Komprimierung nur, so stark vorgenommen, wie sie innerhalb dieser Zeitgrenze möglich ist. Diese Zeitgrenze liegt hier bei beispielhaft 20 s. Darüber hinaus gibt es größenabhängige Stufen, sodass also bis zu einer Datengröße von 2 MByte die Kompressionsstufe 2 zur Anwendung kommt, ab 2 MByte die Kompressionsstufe 8 und ab 4 MByte die Kompressionsstufe 10. Bei Verkehrsdiensten mit XML/JSON kommt typischerweise brotli zum Einsatz unter Nutzung aller seiner Kompressionsstufen 1 bis 11 und einer zeitlichen Obergrenze von 30 s. Die größenabhängigen Stufen können hier beispielsweise wiederum bis zu 2 MByte Stufe 2, ab 4 MByte Stufe 6 und ab 8 MByte Stufe 9 sein. Für ein Kartenupdate mit Kacheln kann ein anderes Verfahren zum Einsatz kommen, welches hier beispielhaft mit Verfahren X gekennzeichnet ist. Auch dieses Verfahren soll verschiedene Kompressionsstufen ermöglichen und die Komprimierung soll bis zu einer Zeitobergrenze von 90 s umgesetzt werden. Bis zu 20 MByte kann dabei die Stufe 6 zum Einsatz kommen, darüber die Stufe 10. Für das Kartenupdate mit Streaming von großen Gebieten soll ein weiteres hier als Verfahren Y ganz allgemein bezeichnetes Verfahren eingesetzt werden, welches wiederum über Kompressionsstufen verfügt. Dabei sollen dessen Kompressionsstufen 5 bis 10 zum Einsatz kommen und eine zeitliche Obergrenze von 150 s vorgegeben werden. Bis zu 60 MByte wird dabei die Stufe 5 und ab 60 MByte die Stufe 7 der Kompression verwendet. Bei Parkinformationsdiensten kann wiederum das Kompressionsverfahren brotli eingesetzt werden, hier vorzugsweise mit der höchsten Komprimierungsstufe und einer zeitlichen Obergrenze von 5 s für die Komprimierung. Anstelle der größenabhängigen Stufen wird hier also, soweit es die Zeitgrenze zulässt immer die Stufe 11, die höchstmögliche Kompression genutzt.
-
Weitere Dienste können sich dann, wie es durch die Punkte angedeutet ist, in weiteren Zeilen anschließen.
-
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 102020003281 A1 [0004]
