DE112021001727T5 - System und verfahren zur filterlosen drosselung von fahrzeugereignisdaten - Google Patents

Abstract

Ausführungsformen beziehen sich auf ein System und auf Verfahren zur filterlosen Drosselung von Fahrzeugereignisdaten über ein Egress-Portal.

Description

• HINTERGRUND DER OFFENBARUNG
• Die Automobilindustrie befindet sich in einem radikalen Wandel, wie es ihn noch nie gegeben hat. Das gesamte Mobilitäts-Ökosystem befindet sich im Umbruch. Das Ergebnis sind Fahrzeuge, die stärker automatisiert, vernetzt, elektrifiziert und gemeinsam genutzt werden. Dies führt zu einer explosionsartigen Zunahme der vom Fahrzeug generierten Daten. Dieser reiche neue Datenschatz bleibt weitgehend ungenutzt.
• Fahrzeugstandort-Ereignisdaten, wie z. B. GPS-Daten, sind extrem umfangreich und können 200.000-600.000 Datensätze („records“) pro Sekunde umfassen. Die Verarbeitung von StandortEreignisdaten stellt für herkömmliche Systeme eine Herausforderung dar, wenn es darum geht, die Daten im Wesentlichen in Echtzeit zu analysieren, insbesondere für einzelne Fahrzeuge. Insbesondere die Endnutzertechnologie kann Datenpakete erfordern. Benötigt werden Systemplattformen und Datenverarbeitungsalgorithmen und -prozesse, die so konfiguriert sind, dass sie große Datenmengen mit geringer Latenzzeit verarbeiten können.
• Es gibt zwar Systeme zur Verfolgung von Fahrzeugen, aber es werden praktisch in Echtzeit genaue Reise- und Straßeninformationen aus großen Fahrzeugdatenmengen benötigt. Benötigt werden Systeme und Algorithmen, die so konfiguriert sind, dass sie große Mengen an Bewegungen und Routenanalysen mit geringer Latenzzeit verarbeiten können.
• ZUSAMMENFASSENDE DARSTELLUNG
• Im Folgenden werden Ausführungsformen kurz beschrieben, um ein grundlegendes Verständnis einiger Aspekte der hier beschriebenen Innovationen zu vermitteln. Diese kurze Beschreibung ist nicht als umfassender Überblick gedacht. Es ist nicht beabsichtigt, wichtige oder kritische Elemente zu identifizieren oder den Schutzbereich abzugrenzen oder anderweitig einzuschränken. Sie dient lediglich dazu, einige Konzepte in vereinfachter Form als Auftakt zu der später folgenden detaillierteren Beschreibung darzustellen.
• Kurz gesagt, verschiedene Ausführungsformen eines Systems, Verfahrens und Computerprogrammprodukts zur Verarbeitung von Fahrzeugereignisdaten.
• Eine Implementierung ist ein System, das einen nicht-transitorischen Speicher, der Programmanweisungen enthält, und einen Prozessor umfasst, der so konfiguriert ist, dass er Anweisungen ausführt, um zumindest: Einlesen („ingress“) über einen Ingress-Server eines Ingress-Datenstroms von Fahrzeugereignisdaten, die Bewegungsdaten für eine Vielzahl von Fahrzeugen enthalten; Zuweisen einer Vielzahl von Fahrzeugkennungen (Vehicle Identifiers) zu einer Vielzahl von jeweiligen Fahrzeugdatensätzen für die Vielzahl von Fahrzeugen der Fahrzeugereignisdaten; und Ausgeben („egress“) eines gedrosselten („throttled“) Datenstroms der Fahrzeugdatensätze an eine Client-Vorrichtung über einen Egress- bzw. Ausgabe-Server mit einem filterlosen Drosselalgorithmus, der so konfiguriert ist, dass er einen Teil der Fahrzeugdatensätze, die aus dem Ingress-Datenstrom identifiziert wurden, um an die Client-Vorrichtung ausgegeben zu werden, in eine Vielzahl von Bucket-Dateien bzw. Bereichsdateien sortiert, und die Fahrzeugdatensätze von dem Egresss-Server löscht, die nicht in die Vielzahl von Bucket-Dateien sortiert sind.
• Das System umfasst einen Datenspeicher, der so konfiguriert ist, dass er Fahrzeugereignisdaten speichert, und einen filterlosen Drosselungsalgorithmus, der so konfiguriert ist, um zumindest: eine Gesamtzahl von Fahrzeugen (Total Vehicles number) zu erhalten, indem eine Gesamtzahl von Fahrzeugen der Fahrzeugereignisdaten bestimmt wird, die von dem System für eine vorbestimmte Zeitperiode gespeichert werden; eine Gesamtbucketzahl (Total Buckets number) für die Gesamtzahl von Bucket-Dateien zu identifizieren, um einen Teil der Fahrzeugdatensätze aus den Fahrzeugereignisdaten zu sortieren, die an die externe Client-Vorrichtung ausgegeben werden sollen; eine Anzahl von Fahrzeugen pro Bucket (Vehicles Per Bucket) zu berechnen, indem die Gesamtzahl von Fahrzeugen durch die Gesamtzahl von Buckets geteilt wird; eine Fahrzeugzielzahl (Vehicle Target number) für die Anzahl von Fahrzeugdatensätzen zu berechnen, die an die externe Client-Vorrichtung ausgegeben werden sollen; eine erforderliche Bucketzahl (Required Buckets number) zu berechnen, indem die Fahrzeugzielzahl durch die Anzahl von Fahrzeugen pro Bucket geteilt wird; einen Fahrzeugkennungs-Hashwert (Vehicle Identifier Hash) berechnen, indem die Fahrzeugkennung auf eine positive Zahl gehasht wird; eine Fahrzeugbucketzahl (Vehicle Bucket number) berechnen, indem ein Modulus des Fahrzeugkennungs-Hashwertes durch die Gesamtbucketszahl genommen („by taking“) wird; und wenn die Fahrzeugbucketzahl kleiner oder gleich der erforderlichen Bucketzahl ist, den Fahrzeugdatensatz für das identifizierte Fahrzeug in die Fahrzeugbucketdatei aufnehmen und den Fahrzeugdatensatz über einen Ausgangs- bzw. Egress-Server an die Client-Vorrichtung („client device“) ausgeben; oder, wenn die Fahrzeugbucketzahl größer als die erforderliche Bucketzahl ist, den Fahrzeugdatensatz vom Egress-Server löschen. Der filterlose Drosselungsalgorithmus kann ferner so konfiguriert werden, dass er zumindest: ein Fahrzeugziel (Vehicle Target) berechnet, indem er einen minimalen Zusatzprozentsatz (Minimum Additional Percentage) von Fahrzeugen berechnet und zu den Gesamtfahrzeugen (Total vehicles) addiert.
• In einer Implementierung ist der filterlose Drosselungsalgorithmus ferner so konfiguriert, dass er zumindest: den Fahrzeugbucket (Vehicle Bucket) periodisch neu berechnet, um schwankende Volumina von Fahrzeugen, die aus den Fahrzeugereignisdaten identifiziert wurden, auszugleichen. Das Neuberechnen umfasst: Neuberechnen der Fahrzeuge pro Bucket; Neuberechnen des Fahrzeugziels; und Neuberechnen des Fahrzeugbucket. Der filterlose Drosselungsalgorithmus kann ferner so konfiguriert sein, dass er zumindest: den Fahrzeugbucket für den Fahrzeugereignisdatensatz vorberechnet, wobei die Vorberechnung Folgendes umfasst: Vorberechnung der Fahrzeuge pro Bucket; Vorberechnung des Fahrzeugziels; und Vorberechnung des Fahrzeugbucket.
• In einer Implementierung ist der filterlose Drosselungsalgorithmus so konfiguriert, dass er den Hashwert mit einem Partitionsalgorithmus berechnet.
• In einer Implementierung ist der filterlose Drosselungsalgorithmus so konfiguriert, dass er den gedrosselten Datenstrom auf der Grundlage der Anforderungen eines externen Client-Systems drosselt. Der Egress-Server ist so konfiguriert, dass er den gedrosselten Datenstrom für die Stream-Zustellung (stream delivery), die Batch-Zustellung (batch delivery) oder beides drosselt.
• Eine Ausführungsform ist ein Verfahren, das auf einem System auszuführen ist, das einen nicht-transitorischen Speicher mit Programmanweisungen und einen Prozessor umfasst, der so konfiguriert ist, dass er die oben und hier beschriebenen Anweisungen ausführt.
• Mindestens eine Ausführungsform ist ein Computerprogrammprodukt mit einem Programmspeicher, der Anweisungen enthält, die, wenn sie von einem Prozessor ausgeführt werden, die oben und hier beschriebenen Verfahren ausführen.
• Figurenliste
• Nicht beschränkende und nicht erschöpfende Ausführungsformen werden unter Bezugnahme auf die folgenden Zeichnungen beschrieben. In den Zeichnungen beziehen sich gleiche Referenznummern auf gleiche Teile in den verschiedenen Figuren, sofern nicht anders angegeben.
• Zum besseren Verständnis wird auf die folgende ausführliche Beschreibung verwiesen, die in Verbindung mit den beigefügten Zeichnungen zu lesen ist, in denen:
• 1 ein Systemdiagramm einer Umgebung ist, in der mindestens eine der verschiedenen Ausführungsformen implementiert werden kann.
• 2 eine logische Architektur und ein Flussdiagramm für ein Ingress-Server-System in Übereinstimmung mit mindestens einer der verschiedenen Ausführungsformen der vorliegenden Offenbarung zeigt.
• 3 eine logische Architektur und ein Flussdiagramm für ein Stream Processing Server System gemäß mindestens einer der verschiedenen Ausführungsformen zeigt.
• 4A eine logische Architektur und ein Flussdiagramm für ein Egress-Server-System gemäß mindestens einer der verschiedenen Ausführungsformen darstellt;
• 4B einen Prozess zur Drosselung von Fahrzeugereignisdaten zeigt.
• 5 eine logische Architektur und ein Flussdiagramm für einen Prozess für ein Analyseserversystem in Übereinstimmung mit mindestens einer der verschiedenen Ausführungsformen zeigt.
• 6 eine logische Architektur und ein Flussdiagramm für einen Prozess für ein Portal-Server-System in Übereinstimmung mit mindestens einer der verschiedenen Ausführungsformen zeigt.
• 7 ein Flussdiagramm ist, das eine Datenqualitäts-Pipeline von Datenverarbeitungsprüfungen für das System zeigt.
• 8 eine Cloud-Computing-Architektur in Übereinstimmung mit mindestens einer der verschiedenen Ausführungsformen zeigt.
• 9 eine logische Architektur für eine Cloud-Computing-Plattform in Übereinstimmung mit mindestens einer der verschiedenen Ausführungsformen zeigt.
• DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
• Verschiedene Ausführungsformen werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungen, die einen Teil dieses Dokuments bilden und die zur Veranschaulichung spezifische Ausführungsformen zeigen, mit denen die hier beschriebenen Innovationen umgesetzt werden können, ausführlicher beschrieben. Die Ausführungsformen können jedoch in vielen verschiedenen Formen verkörpert werden und sollten nicht als auf die hier dargestellten Ausführungsformen beschränkt verstanden werden. Vielmehr sind diese Ausführungsformen vorgesehen, damit diese Offenbarung gründlich und vollständig ist und dem Fachmann den Umfang der Ausführungsformen vollständig vermittelt. Bei den verschiedenen Ausführungsformen kann es sich unter anderem um Verfahren, Systeme, Medien oder Vorrichtungen handeln. Dementsprechend können die verschiedenen Ausführungsformen die Form einer reinen Hardware-Ausführung, einer reinen Software-Ausführung oder einer Ausführungsform annehmen, die Software- und Hardware-Aspekte kombiniert. Die folgende detaillierte Beschreibung ist daher nicht in einem einschränkenden Sinne zu verstehen.
• In der gesamten Beschreibung und den Ansprüchen haben die folgenden Begriffe die hierin ausdrücklich zugewiesene Bedeutung, sofern aus dem Kontext nicht eindeutig etwas anderes hervorgeht. Der Begriff „hierin“ bzw. „hier“) bezieht sich auf die Beschreibung, die Ansprüche und die Zeichnungen, die mit der vorliegenden Anmeldung verbunden sind. Der Ausdruck „in der einen Ausführungsform“ oder „in einer Ausführungsform“, wie er hier verwendet wird, muss sich nicht unbedingt auf dieselbe Ausführungsform oder eine einzige Einbettung beziehen, kann es aber. Darüber hinaus muss sich der hier verwendete Ausdruck „in einer anderen Ausführungsform“ nicht unbedingt auf eine unterschiedliche Ausführungsform beziehen, obwohl dies möglich ist. So können, wie im Folgenden beschrieben, verschiedene Ausführungsformen ohne weiteres kombiniert werden, ohne vom Umfang oder Geist der Erfindung abzuweichen.
• Darüber hinaus ist der hier verwendete Begriff „oder“ ein umfassender bzw. inklusiver „oder“-Operator und entspricht dem Begriff „und/oder“, sofern der Kontext nicht eindeutig etwas anderes vorschreibt. Der Begriff „basierend auf“ ist nicht exklusiv und erlaubt es, auf zusätzlichen, nicht beschriebenen Faktoren zu basieren, sofern der Kontext nicht eindeutig etwas anderes vorschreibt. Darüber hinaus schließt die Bedeutung von „ein/eine/eines“ und „der/die/das“ in der gesamten Beschreibung die Mehrzahl ein. Die Bedeutung von „in“ schließt „in“ und „am“ bzw. („auf“) ein.
• Wie hier verwendet, kann sich der Begriff „Host“ auf eine Einzelperson, eine Partnerschaft, eine Organisation oder eine juristische Person beziehen, die eines oder mehreres digitales Medieneigentum (z. B. Websites, mobile Anwendungen oder Ähnliches) besitzen oder betreiben kann. Hosts können digitales Medieneigentum so einrichten, dass sie hyperlokales Targeting verwenden, indem sie das Eigentum bzw. die Eigenschaft so einrichten, dass es/sie mit Widget-Controllern, Content Management Servern oder Content Delivery Servern integriert wird.
• Wie hierin verwendet, kann eine Reise („journey“) jede Fahrt („trip“), jeden Lauf oder jeden Reisevorgang zu einem Zielort umfassen.
• Illustrative Logiksystemarchitektur und Systemabläufe
• 1 ist eine Logikarchitektur des Systems 10 für die Verarbeitung und Analyse von Geolokalisierungsereignissen in Übereinstimmung mit mindestens einer Ausführungsform. In mindestens einer Ausführungsform kann das Ingress Server System 100 so angeordnet sein, dass es mit dem Stream Processing Server System 200 und dem Analyseserversystem bzw. Analytics Server System 500 kommuniziert. Das Stream Processing Server System 200 kann so eingerichtet sein, dass es mit dem Egress Server System 400 und dem Analytics Server System 500 kommuniziert.
• Das Egress Server System 400 kann so konfiguriert werden, dass es mit Datenkonsumenten kommuniziert und diese mit Daten versorgt. Das Egress Server System 400 kann auch so konfiguriert werden, dass es mit dem Stream Processing Server 200 kommuniziert.
• Das Analyseserversystem 500 ist so konfiguriert, dass es mit dem Ingress-Serversystem 100, dem Stream-Processing-Serversystem 200 und dem EgressServer System 400 kommuniziert und Daten von diesen akzeptiert. Das Analyseserversystem 500 ist so konfiguriert, dass es mit einem Portalserversystem 600 kommuniziert und Daten an dieses ausgibt.
• In mindestens einer Ausführungsform können das Ingress Server System 100, das Stream Processing Server System 200, das Egress Server System 400, das Analytics Server System 500 und das Portal Server System 600 jeweils ein oder mehrere Computer oder Server sein. In mindestens einer Ausführungsform können ein oder mehrere der Systeme Ingress Server System 100, Stream Processing Server System 200, Egress Server System 400, Analytics Server System 500 und Portal Server System 600 so konfiguriert sein, dass sie auf einem einzigen Computer, beispielsweise einem Netzwerkserver, oder auf mehreren Computern arbeiten. In mindestens einer Ausführungsform kann das System 10 beispielsweise so konfiguriert werden, dass es auf einem Webservice-Plattform-Host wie Amazon Web Services (AWS)® oder Microsoft Azure® läuft. In einer beispielhaften Ausführungsform ist das System auf einer AWS-Plattform konfiguriert, die einen Spark Streaming Server verwendet, der so konfiguriert werden kann, dass er die hier beschriebene Datenverarbeitung durchführt. In einer Ausführungsform kann das System so konfiguriert werden, dass ein Messaging-Server mit hohem Durchsatz verwendet wird, z. B. Apache Kafka.
• In mindestens einer Ausführungsform können das Ingress Server System 100, das Stream Processing Server System 200, das Egress Server System 400, das Analytics Server System 500 und das Portal Server System 600 so eingerichtet werden, dass sie sich integrieren und/oder über APIs oder andere Kommunikationsschnittstellen kommunizieren, die von den Service-Einrichtungen bereitgestellt werden.
• In mindestens einer Ausführungsform können das Ingress Server System 100, das Stream Processing Server System 200, das Egress Server System 400, das Analytics Server System 500 und das Portal Server System 600 auf Hosting Servern gehostet werden.
• In mindestens einer Ausführungsform können das Ingress Server System 100, das Stream Processing Server- System 200, das EgressServer System 400, das Analytics Server System 500 und das Portal Server System 600 so eingerichtet sein, dass sie direkt oder indirekt über ein Netzwerk mit den Client-Computern kommunizieren, wobei ein oder mehrere direkte Netzwerkpfade einschließlich Wide Access Networks (WAN) oder Local Access Networks (LAN) verwendet werden.
• Einer Fachperson wird klar sein, dass die Architektur des Systems 10 ein nicht einschränkendes Beispiel ist, das zumindest einen Teil einer Ausführungsform veranschaulicht. So können mehr oder weniger Komponenten verwendet und/oder anders angeordnet werden, ohne dass der Schutzumfang der hier beschriebenen Innovationen verlassen wird. Das System 10 reicht jedoch aus, um zumindest die hier beanspruchten Neuerungen zu offenbaren.
• Unter Bezugnahme auf 2 wird eine Logikarchitektur für ein Ingress Server System 100 zur Aufnahme von Daten und Datendurchsatz in Übereinstimmung mit mindestens einer Ausführungsform gezeigt. In mindestens einer Ausführungsform können Ereignisse aus einer oder mehreren Ereignisquellen ermittelt werden. In einer Ausführungsform, wie in 1 gezeigt, können Ereignisquellen eine Fahrzeugsensordatenquelle 12, eine OEM-Fahrzeugsensordatenquelle 14, eine Anwendungsdatenquelle 16, eine Telematikdatenquelle 20, eine drahtlose Infrastrukturdatenquelle 17 und eine Drittanbieterdatenquelle 15 oder Ähnliches umfassen. In mindestens einer Ausführungsform können die ermittelten bzw. bestimmten Ereignisse Standortdaten, Fahrzeugsensordaten, verschiedenen Benutzerinteraktionen, Anzeigevorgängen, Eindrücken oder Ähnlichem entsprechen, die von nachgelagerten Komponenten des Systems, wie dem Stream Processing Server System 200 und dem Analytics Server System 500, verwaltet werden können. In mindestens einer Ausführungsform kann das Ingress Server System 100 mehr oder weniger Ereignisquellen als in 1 dargestellt einlesen („ingress“).
• In mindestens einer Ausführungsform umfassen Ereignisse, die von einer oder mehreren Ereignisquellen empfangen und/oder bestimmt werden können, Fahrzeugereignisdaten von einer oder mehreren Datenquellen, z. B. GPS-Geräte oder Standortdatentabellen, die von einer Drittanbieter-Datenquelle 15 bereitgestellt werden, wie z. B. eine OEM-FahrzeugsensorDatenquelle 14. Fahrzeug-Ereignisdaten können in Datenbankformaten, z. B. JSON, CSV und XML, eingelesen werden. Die Fahrzeugereignisdaten können über APIs oder andere Kommunikationsschnittstellen eingelesen werden, die von den Service-Einrichtungen und/oder dem Ingress Server System 100 bereitgestellt werden. Beispielsweise kann das Ingress Server System 100 eine API-Gateway Schnittstelle 102 anbieten, die mit einer Ingress Server API 106 integriert ist, die es dem Ingress Server System 100 ermöglicht, verschiedene Ereignisse zu bestimmen, die mit den von der Fahrzeugereignisquelle 14 bereitgestellten Datenbanken verknüpft werden können. Ein beispielhaftes API-Gateway kann z. B. ein AWS API-Gateway umfassen. Eine beispielhafte Hosting-Plattform für ein Ingress Server System 100-System kann Kubernetes und Docker umfassen, obwohl auch andere Plattformen und Netzwerkcomputerkonfigurationen verwendet werden können.
• In mindestens einer Ausführungsform umfasst das Ingress Server System 100 einen Server 104, der so konfiguriert ist, dass er Rohdaten akzeptiert, z. B. kann ein Secure File Transfer Protocol Server (SFTP), eine API oder andere Dateneingänge so konfiguriert sein, dass sie Fahrzeugereignisdaten akzeptieren. Das Ingress Server System 100 kann so konfiguriert werden, dass es die Rohdaten in einem Datenspeicher 107 zur weiteren Analyse speichert, z. B. durch ein Analytics Server System 500. Zu den Ereignisdaten können Zündung ein, Zeitstempel (T1...TN), Zündung aus, interessante Ereignisdaten, Breiten- und Längengrad sowie Fahrzeuginformationsnummer (VIN) gehören. Beispielhafte Ereignisdaten können Fahrzeugbewegungsdaten aus bekannten Quellen umfassen, z. B. entweder von den Fahrzeugen selbst (z. B. über GPS, API) oder Tabellen mit Standortdaten, die von Datenquellen 15 Dritter bereitgestellt werden.
• In mindestens einer Ausführungsform ist das Ingress Server System 100 so konfiguriert, dass es Daten bereinigt und validiert. Beispielsweise kann der Ingress Server 100 so konfiguriert sein, dass er eine Ingress API 106 enthält, die die aufgenommenen Telematik- und Standortdaten validiert und die validierten Standortdaten an eine Server-Warteschlange 108, beispielsweise eine Apache-Kafka-Warteschlange, weiterleitet, die dann an den Stream Processing Server 300 ausgegeben wird. Der Server 108 kann so konfiguriert werden, dass er die validierten eingegebenen Standortdaten auch an den Datenspeicher 107 ausgibt. Der Ingress Server kann auch so konfiguriert werden, dass er ungültige Daten an einen Datenspeicher 107 weiterleitet. Zum Beispiel können ungültige Nutzdaten im Datenspeicher 107 gespeichert werden. Beispiele für ungültige Daten sind Daten mit fehlerhaften Feldern, nicht erkannten Feldern oder identischen Ereignissen.
• In einer Ausführungsform ist das System so konfiguriert, dass es Fahrzeugstandorte mit erhöhter Genauigkeit erkennt und kartiert. Um nützliche Aggregate über das Straßennetz zu sammeln, z. B. das erwartete Verkehrsaufkommen und die Geschwindigkeiten im Tages-/Wochenzyklus, kann das System so konfiguriert werden, dass es ermittelt, wie sich die Fahrzeuge durch ein bestimmtes Straßennetz bewegen. Wie bereits erwähnt, kann ein naiver Ansatz, bei dem jeder Datenpunkt dem nächstgelegenen Straßenabschnitt zugeordnet („associating or „snapping““) wird, fehlschlagen, da die GPS-Daten von Fahrzeugen aufgrund verschiedener bekannter physikalischer Effekte einen inhärenten Fehlergrad aufweisen. Außerdem nähert und kreuzt sich ein Straßennetz oft in komplizierten Geometrien, was zu Orten mit mehreren Fang- bzw. Snapping-Kandidaten führt.
• In einer Ausführungsform kann das System so konfiguriert werden, dass es eine Basiskarte enthält, die als eine Sammlung von Liniensegmenten für Straßensegmente vorliegt. Das System enthält für jedes Liniensegment geometrische Informationen über die Beziehung des Liniensegments zu seinen nächsten Nachbarn. Für jedes Streckensegment werden in einer ersten Iteration des Prozesses statistische Informationen über erwartete Verkehrsaufkommen und - geschwindigkeiten generiert. Wie oben dargestellt, umfassen die Ereignisdaten der Fahrzeugbewegungen Längengrad, Breitengrad, Richtung, Geschwindigkeit und Tageszeit.
• In einer Ausführungsform ist das System so konfiguriert, dass es eine Sammlung von Liniensegmenten nimmt, die Straßensegmenten entsprechen, und einen R-Baum-Index („R-tree index“) über die Sammlung von Liniensegmenten erstellt. R-Bäume sind Baumdatenstrukturen, die für räumliche Zugriffsmethoden verwendet werden, d. h. für die Indizierung mehrdimensionaler Informationen wie geografische Koordinaten, Rechtecke oder Polygone. Der R-Baum ist so konfiguriert, dass er räumliche Objekte als Bounding-Box-Polygone speichert, um unter anderem Straßensegmente darstellen. Der R-Baum wird zunächst dazu verwendet, Straßensegmentkandidaten zu finden, die sich in einer vorgegebenen Entfernung von einer Koordinate befinden, um einen Datenpunkt zu fangen („snap“). Die Kandidaten werden dann anhand einer verfeinerten Metrik weiter untersucht, die Ereignisdaten wie die Richtung berücksichtigt, die ein Straßensegment mit der größten Wahrscheinlichkeit auf der Grundlage aller bekannten Informationen wählt. Ereignisdaten wie Geschwindigkeit und/oder Tageszeit können ebenfalls zur Auswahl eines Straßensegments herangezogen werden.
• Der Ingress Server 100 kann so konfiguriert werden, dass er die gespeicherten ungültigen Daten ausgibt oder es ermöglicht, dass gespeicherte Daten aus dem Datenspeicher 107 zur Analyse auf den Analysis Server 500 gezogen werden, um z. B. die Systemleistung zu verbessern. Der Analysis Server 500 kann beispielsweise mit diagnostischem maschinellem Lernen konfiguriert werden, um eine Analyse von Datenbanken mit ungültigen Daten mit nicht erkannten Feldern durchzuführen, um Felder für die validierte Verarbeitung neu zu identifizieren und zu kennzeichnen. Der Ingress Server 100 kann auch so konfiguriert werden, dass er gespeicherte Ingress-Standortdaten zur Verarbeitung durch den Analysis Server 500 weiterleitet, zum Beispiel für die hier beschriebene Reise- bzw. Joumey-Analyse.
• In einer Ausführungsform ist der Ingress Server 100 so konfiguriert, dass er Ereignisdaten verarbeitet, um Fahrzeugbewegungsdaten abzuleiten, z. B. Geschwindigkeit, Dauer und Beschleunigung. In einer Ausführungsform wird zum Beispiel alle x Sekunden (z. B. 3 Sekunden) ein Schnappschuss in der Ereignisdatenbank gemacht. Längengrad/Breitengrad- bzw. Lat/Long-Daten und Zeitdaten können dann verarbeitet werden, um Fahrzeugverfolgungsdaten, wie Geschwindigkeit und Beschleunigung, unter Verwendung der Fahrzeugposition und -zeit abzuleiten.
• In einer Ausführungsform ist der Ingress Server 100 so konfiguriert, dass er Daten von Geräten und Plattformen von Drittanbietern akzeptiert. Die Ingress API 106 kann so konfiguriert werden, dass sie Geräte und Partner oder Drittanbieterplattformen und Plattform-Hosts gegenüber dem System 10 authentifiziert.
• Dementsprechend ist der Ingress Server 100 in einer Ausführungsform so konfiguriert, dass er Rohdaten empfängt und Datenqualitätsprüfungen für Rohdaten und eine Schemabewertung durchführt. Das Einlesen und Validieren von Rohdaten ist der Beginn einer Datenqualitäts-Pipeline von Qualitätsprüfungen für das System, wie in 7 in Block 701 gezeigt. Tabelle 1 zeigt ein Beispiel für Rohdaten, die in das System eingespeist werden. Tabelle 1

  	Attribut	Typ	Löschbar	Beschreibung
  Rohdaten.	Partner_id	ganzzahlig	Nein	Kennung für Ingress-Partner
  	Vorrichtung_id	String	Ja	4-9 Zeichen lang
  	erfasster_Zeitstempel	String	Nein	Zeitpunkt eines Ereignisses, ausgedrückt in Ortszeit mit UTC-Offset
  	empfangener Zeitstempel	String	Nein	Uhrzeit, zu der das Ereignis vom Ingress Server empfangen wurde, UTC
  	Längengrad, Breitengrad	Doppelt	Nein	WGS84-Koordinaten eines Ereignisses
  	Geschwindigkeit	Float	Nein	Fahrzeuggeschwindigkeit in Kilometern pro Stunde, die zum Zeitpunkt des Ereignisses gemessen wurde
  	zusätzlich	Karte	Nein	Karte mit String-Schlüssel-Wert-Paaren, um Datenattribute auszudrücken, die für jeden Ingress eindeutig sind
  	Fahrt id	String	Nein	Kennung für eine Fahrt und die zugehörigen Ereignisse innerhalb dieser Fahrt
  	Richtung	ganzzahlig	Ja	Ausrichtung des Fahrzeugs im Uhrzeigersinn, 0 ist gleich Norden
  	Höhe	ganzzahlig	Ja	Vom GPS gemeldete Höhe des Fahrzeugs
  	Squish_vin	String	Ja	Codierte Darstellung der Merkmale der Fahrzeugmarke/des Fahrzeugmodells
  	Zündung_status	String	Ja	Anzeige, ob das Fahrzeug unter Strom steht

• In einer anderen Ausführungsform können die Fahrzeugereignisdaten von einer Ingress-Quelle weniger Informationen enthalten. Wie in Tabelle 2 dargestellt, können die rohen Fahrzeugereignisdaten beispielsweise eine begrenzte Anzahl von Attributen umfassen, z. B. Standortdaten (Längen- und Breitengrad) und Zeitdaten (Zeitstempel). Tabelle 2

  	Attribut	Typ	Löschbar	Beschreibung
  Rohdaten.	erfasster_Zeitstempel	String	Nein	Zeitpunkt eines Ereignisses, ausgedrückt in Ortszeit mit UTC-Offset
  	empfangener Zeitstempel	String	Nein	Uhrzeit, zu der das Ereignis vom Ingress Server empfangen wurde, UTC
  	Längengrad, Breitengrad	Doppelt	Nein	WGS84-Koordinaten eines Ereignisses

• Ein beispielhafter Vorteil von Ausführungsformen der vorliegenden Offenbarung besteht darin, dass fehlende Informationen aus den hier beschriebenen innovativen Algorithmen abgeleitet werden können. Beispielsweise können Fahrzeugereignisdaten keine Reiseidentifikation bzw. Fahrtenkennung enthalten oder eine Fahrtenkennung aufweisen, die ungenau ist. Dementsprechend kann das System so konfiguriert werden, dass es zusätzliche Fahrzeugereignis-Attributdaten ableitet, wenn die ursprünglich eingegebenen Daten nur begrenzte Attribute aufweisen. Zum Beispiel kann das System so konfiguriert werden, dass es ein bestimmtes Fahrzeug für die eingegebenen Fahrzeugereignisdaten identifiziert und eine Fahrzeug-ID anhängt. Auf diese Weise kann das System die Bewegung des Fahrzeugs nachverfolgen - einschließlich Starts und Stopps, Geschwindigkeit, Richtung, Beschleunigung und andere Attribute, indem es zum Beispiel nur Standort- und Zeitstempeldaten verwendet, die mit einer Fahrzeug-ID verbunden sind.
• In einer Ausführungsform können in Block 702 die empfangenen Daten einem extern definierten Schema entsprechen, z. B. Avro oder JSON. Die Daten können in ein internes Schema umgewandelt und validiert werden. In einer Ausführungsform können die Ereignisdaten anhand einer vereinbarten Schemadefinition validiert werden, bevor sie an das Nachrichtensystem zur nachgelagerten Verarbeitung durch die Datenqualitätspipeline weitergeleitet werden. Beispielsweise kann eine Apache-Avro-Schemadefinition verwendet werden, bevor die validierten Daten an ein Apache-Kafka-Nachrichtensystem weitergegeben werden. In einer anderen Ausführungsform können die rohen Bewegungs- und Ereignisdaten auch von einer Client-Knoten-Cluster-Konfiguration verarbeitet werden, bei der jeder Client ein Konsument oder Produzent ist und die Cluster innerhalb einer Instanz Daten untereinander replizieren können.
• Beispielsweise kann das Ingress Server System 100 mit einem Pulsar-Client konfiguriert werden, der mit einem Apache-Pulsar-Endpunkt für einen Pulsar-Cluster verbunden ist. In einer Ausführungsform verfolgt der Apache-Pulsar-Endpunkt die zuletzt gelesenen Daten, so dass ein Apache-Pulsar-Client jederzeit eine Verbindung herstellen kann, um an die zuletzt gelesenen Daten anzuknüpfen. In Pulsar beinhaltet eine „Standard“-Konsumentenschnittstelle die Verwendung von „Konsumenten“-Clients, um auf Topics zu hören, eingehende Nachrichten zu verarbeiten und schließlich diese Nachrichten zu bestätigen, wenn die Nachrichten verarbeitet wurden. Wenn ein Client eine Verbindung zu einem Topic herstellt, beginnt er automatisch mit dem Lesen der frühesten unbestätigten Nachricht, da der Cursor des Topics automatisch von einem Pulsar-Broker-Modul verwaltet wird. Eine Leseschnittstelle für den Client ermöglicht es der Client-Anwendung jedoch, Topic-Cursor auf individuelle Weise zu verwalten. Beispielsweise kann ein Pulsar-Client-Lesegerät so konfiguriert werden, dass es eine Verbindung zu einem Topic herstellt, um anzugeben, mit welcher Nachricht das Lesegerät mit dem Lesen beginnt, wenn es eine Verbindung zu einem Topic herstellt. Wenn eine Verbindung zu einem Topic hergestellt wird, ermöglicht die Leserschnittstelle dem Client, mit der frühesten verfügbaren Nachricht im Topic oder mit der neuesten verfügbaren Nachricht im Topic zu beginnen. Der Client-Leser kann auch so konfiguriert werden, dass er mit einer anderen Nachricht zwischen der frühesten und der spätesten Nachricht beginnt, z. B. durch Verwendung einer Nachrichten-ID zum Abrufen von Nachrichten („messages“) aus einem persistenten Datenspeicher oder Cache.
• In mindestens einer Ausführungsform ist das Ingress Server System 100 so konfiguriert, dass es Daten bereinigt und validiert. Beispielsweise kann das Ingress Server System 100 so konfiguriert sein, dass es eine Ingress Server API 106 enthält, die die eingelesenen bzw. aufgenommenen Fahrzeugereignis- und -standortdaten validieren und die validierten Standortdaten an eine Server-Warteschlange 108 weiterleiten kann, z. B. eine Apache Kafka-Warteschlange 108, die dann an das Stream Processing Server System 200 ausgegeben wird. Der Server 104 kann so konfiguriert werden, dass er die validierten eingegebenen Standortdaten auch an den Datenspeicher 107 ausgibt. Das Ingress Server System 100 kann auch so konfiguriert werden, dass es ungültige Daten an einen Datenspeicher 107 weiterleitet. Bei der Kartendatenbank kann es sich zum Beispiel um eine Point-of-Interest-Datenbank oder eine andere Kartendatenbank handeln, einschließlich öffentlicher oder proprietärer Kartendatenbanken. Beispielhafte Kartendatenbanken können vorhandene Straßenkartendaten wie Geofabric für lokale Straßenkarten oder die World Map Database umfassen. Das System kann ferner so konfiguriert werden, dass es die Daten an externe Kartenschnittstellen, Navigationsschnittstellen, Verkehrsschnittstellen und Schnittstellen für vernetzte Fahrzeuge ausgibt, wie hier beschrieben.
• In einer Ausführungsform können in Block 702 die empfangenen Daten einem extern definierten Schema entsprechen, z. B. Avro oder JSON. Das Ingress Server System 100 kann so konfiguriert werden, dass es die gespeicherten ungültigen Daten ausgibt oder es ermöglicht, dass gespeicherte Daten aus dem Datenspeicher 107 zur Analyse auf das Analysis Server System 500 gezogen werden, um z. B. die Systemleistung zu verbessern. Beispielsweise kann das Analysis-Server System 500 mit diagnostischem maschinellem Lernen konfiguriert werden, um eine Analyse von Datenbanken mit ungültigen Daten mit nicht erkannten Feldern durchzuführen, um Felder für die validierte Verarbeitung neu zu identifizieren und zu kennzeichnen. Das Ingress Server System 100 kann auch so konfiguriert werden, dass es gespeicherte Ingress-Standortdaten zur Verarbeitung durch das Analytics Server System 500 weiterleitet, z. B. zur Journey-Analyse, wie hier beschrieben.
• Wie hier beschrieben, ist das System 10 so konfiguriert, dass es Daten sowohl in einem Streaming- als auch in einem Batch-Kontext verarbeiten kann. Im Streaming-Kontext ist eine niedrige Latenz wichtiger als die Vollständigkeit, d. h. alte Daten müssen nicht verarbeitet werden, und die Verarbeitung alter Daten kann sich sogar nachteilig auswirken, da sie die Verarbeitung anderer, neuerer Daten verzögern kann. Im Batch-Kontext ist die Vollständigkeit der Daten wichtiger als eine geringe Latenzzeit. Um die Verarbeitung von Daten in diesen beiden Kontexten zu erleichtern, kann das System in einer Ausführungsform standardmäßig eine Streaming-Verbindung herstellen, die alle Daten aufnimmt, sobald sie verfügbar sind, aber auch so konfiguriert werden, dass alte Daten übersprungen werden. Ein Batch--Prozessor kann so konfiguriert werden, dass er alle Lücken füllt, die der Streaming-Prozessor aufgrund alter Daten hinterlässt.
• 3 ist eine logische Architektur für ein Stream Processing Server System 200 für Datendurchsatz und -analyse in Übereinstimmung mit mindestens einer Ausführungsform. Die hier beschriebene Stream-Verarbeitung führt zu Verbesserungen bei der Systemverarbeitung, einschließlich Verbesserungen beim Durchsatz bei linearer Skalierung von mindestens 200k bis 600k Datensätzen pro Sekunde. Die Verbesserung umfasst außerdem eine End-to-End-Systemverarbeitung von 20 Sekunden, wobei weitere Verbesserungen der Systemlatenzzeit in Arbeit sind. In mindestens einer Ausführungsform kann das System so konfiguriert werden, dass ein Server für die Micro-Batchverarbeitung eingesetzt wird. Wie hierin beschrieben, kann das Stream Processing Server System 200 beispielsweise so konfiguriert werden, dass es auf einem Webservice-Plattform-Host wie AWS läuft, der einen Spark-Streaming-Server und einen Messaging-Server mit hohem Durchsatz wie Apache Kafka verwendet. In einer Ausführungsform kann das Stream Processing Server System 200 einen Device Management Server 207, z. B. AWS Ignite, umfassen, der für die Eingabe verarbeiteter Daten vom Datenverarbeitungsserver konfiguriert werden kann. Der Device Management Server 207 kann so konfiguriert werden, dass er anonymisierte Daten für die Analyse einzelner Fahrzeugdaten verwendet, die extern angeboten oder über eine Schnittstelle übertragen werden können. Das System 10 kann so konfiguriert werden, dass es Daten in Echtzeit ausgibt sowie Daten in einem oder mehreren Datenspeichern für zukünftige Analysen speichert. Das Stream Processing Server System 200 kann beispielsweise so konfiguriert werden, dass es Echtzeitdaten über eine Schnittstelle, z. B. Apache Kafka, an das Egress Server System 400 ausgibt. Das Stream Processing Server System 200 kann auch so konfiguriert werden, dass es sowohl Echtzeit- als auch Batch-Daten im Datenspeicher 107 speichert. Auf die Daten im Datenspeicher 107 kann zugegriffen werden oder sie können dem Insight bzw. Erkenntnis Server System 500 zur weiteren Analyse zur Verfügung gestellt werden.
• In mindestens einer Ausführungsform können Ereignisinformationen in einem oder mehreren Datenspeichern 107 gespeichert werden, um später verarbeitet und/oder analysiert zu werden. Ebenso können in mindestens einer Ausführungsform die Ereignisdaten und -informationen verarbeitet werden, sobald sie ermittelt oder empfangen werden. Außerdem können Ereignis-Nutzdaten und Prozessinformationen in Datenspeichern, wie dem Datenspeicher 107, zur Verwendung als historische Informationen und/oder Vergleichsinformationen und zur weiteren Verarbeitung gespeichert werden.
• In mindestens einer Ausführungsform ist das Stream Processing Server System 200 so konfiguriert, dass es die Verarbeitung von Fahrzeugereignisdaten durchführt.
• 3 zeigt eine logische Architektur und ein Übersichtsflussdiagramm für ein Stream Processing Server System 200 in Übereinstimmung mit mindestens einer Ausführungsform. In Block 202 führt das Stream Processing Server System 200 eine Validierung von StandortEreignisdaten von eingegangenen Standorten 201 durch. Daten, die nicht ordnungsgemäß formatiert sind, doppelt vorhanden sind oder nicht erkannt werden, werden herausgefiltert. Zu den ungültigen Daten gehören beispielsweise Daten mit fehlerhaften Feldern, nicht erkannten Feldern oder identischen Ereignissen (Duplikaten) oder Datenpunkte beim Ein- und Ausschalten eines Motors, die am selben Ort und zur selben Zeit auftreten. Die Validierung umfasst auch eine Latenzprüfung, die Ereignisdaten verwirft, die älter sind als ein vorgegebener Zeitraum, z. B. 7 Sekunden. In einer Ausführungsform können auch andere Latenzfilter verwendet werden, z. B. zwischen 4 und 15 Sekunden.
• In einer Ausführungsform, wie in Block 703 von 7 gezeigt, ist das Stream Processing Server System 200 so konfiguriert, dass es eine Attributgrenzenfilterung („Attribute Bounds Filtering“) durchführt. Die Attributgrenzenfilterung prüft, ob die Attribute der Ereignisdaten innerhalb vordefinierter Grenzen für die Daten liegen, die für die Daten sinnvoll sind. Zum Beispiel ist ein Überschriftenattribut als Kreis (0 → 359) definiert. Ein Squish-Vin ist eine 9-10 Zeichen lange VIN. Beispiele hierfür sind Daten, die von einem Datenanbieter vordefiniert oder durch eine Norm festgelegt sind. Datenwerte, die nicht innerhalb dieser Grenzen liegen, weisen darauf hin, dass die Daten für das Attribut von Natur aus fehlerhaft sind. Nicht konforme Daten können geprüft und herausgefiltert werden. Ein Beispiel für die Filterung von Attributgrenzen findet sich in Tabelle 3. Tabelle 3

  Filterung von Attributgrenzen Werte innerhalb eines sinnvollen Bereichs.	Attribute enthalten nur Werte innerhalb extern vordefinierter Grenzen.	Attribut	Einheiten	Festgelegt durch	Grenzen	Markierte Datenpunkte	Markierte Datenpunkte (%)
  		Vorrichtung_id	String	Extern	N/A	27	0,00171%
  		Längengrad, Breitengrad	Doppelt	Intern	auf Anfrage	586	586
  		Richtung	ganzzahlig	Extern	0 → 359	94	0,00004%
  		Squish_vin	String	Extern	9-10 Zeichen	0	0%

• In einer Ausführungsform ist das System in Block 704 so konfiguriert, dass es eine Attributwertfilterung durchführt. Die Attributwertfilterung prüft, ob die Attributwerte intern festgelegt sind oder auf definierte Bereiche zutreffen. Während zum Beispiel ein Datum von 1970 eine Attributgrenzenfilterprüfung für ein Datumsattribut des Ereignisses bestehen kann, ist das Datum kein sinnvoller Wert für Fahrzeugverfolgungsdaten. Dementsprechend ist die Attributwertfilterung so konfiguriert, dass Daten gefiltert werden, die älter als eine vordefinierte Zeitspanne sind, z. B. 6 Wochen oder älter, die geprüft und gefiltert werden können. Ein Beispiel für die Attributgrenzenfilterung ist in Tabelle 3 dargestellt. Tabelle 3

  Filterung von Attributgrenzen Werte innerhalb eines sinnvollen Bereichs.	Attribute enthalten nur Werte innerhalb extern vordefinierter Grenzen.	Attribut	Einheiten	Festgelegt durch	Festgelegte Grenzen	Markierte Datenpunkte	Markierte Datenpunkte (%)
  		erfasster_Zeitstempel	Zeitstempel		< vor weniger als 6 Wochen		64296
  		empfangener_Zeitstempel	Zeitstempel		> jetzt		0
  		Längengrad, Breitengrad	Grad	Intern	Begrenzungsrahmen		0
  		Geschwindigkeit	km/h	Intern	0 → 360		0
  		Höhe	Meter	Intern	-1000 → 10000

• In Block 705 kann das System eine weitere Validierung der Attribute in einem Datensatz durchführen, um zu bestätigen, dass die Beziehungen zwischen den Attributen der Datensatzdatenpunkte kohärent sind. Zum Beispiel macht ein Ereignis, bei dem der Fahrtbeginn nicht Null ist, keinen logischen Sinn für die hier beschriebene Fahrtenbestimmung. Dementsprechend kann das System 10, wie in Tabelle 4 gezeigt, so konfiguriert werden, dass es Geschwindigkeitsereignisse ungleich Null, die für dieselben Attribute für einen erfassten Zeitstempel und einen empfangenen Zeitstempel für einen Ort aufgezeichnet wurden, als „TripStart“ oder „Journey-Zündung“ bei Starereignis filtert. Tabelle 4

  Filtern auf Datensatzebene Rohinhalte haben semantische Bedeutung,	Attribute	Bedingungen	Markierte Datenpunkte	Markierte Datenpunkte (%)
  	Geschwindigkeit, Zündstatus	Geschwindigkeit > 0 UND Zündstatus IN (‚AUS‘,‘ AN‘)	439	0,0004%
  	erfasster_Zeitstempel, empfangener_Zeitstempel	erfasster_Zeitstempel < empfangener_Zeitstempel	41	0,00004%

• Zurück zu 2: In Block 204 führt der Stream Processing Server 200 in mindestens einer Ausführungsform ein Geohashing der Standortereignisdaten durch. Obwohl es Alternativen zum Geohashing gibt, wie z. B. einen H3-Algorithmus, wie er von Uber™ verwendet wird, oder einen S2-Algorithmus, wie er von Google™ verwendet wird, hat sich gezeigt, dass Geohashing beispielhafte Verbesserungen für das System 10 bietet, z. B. Verbesserungen der Systemlatenz und des Durchsatzes. Geohashing sorgte auch für Datenbankverbesserungen bei der Genauigkeit des Systems 10 und der Fahrzeugerfassung. Zum Beispiel kann ein Geohash mit einer Genauigkeit von 9 Zeichen verwendet werden, um ein Fahrzeug eindeutig dem Geohash zuordnen zu können. Eine solche Genauigkeit kann in den hier beschriebenen Algorithmen zur Joumey- bzw. Reise-Bestimmung verwendet werden. In mindestens einer Ausführungsform werden die Standortdaten in den Ereignisdaten in eine Annäherung („proximity“) kodiert, wobei die Kodierung das Geohashing von Breitengrad und Längengrad für jedes Ereignis in eine Annäherung für jedes Ereignis umfasst. Die Ereignisdaten umfassen die Zeit, die Position (Breitengrad/Längengrad) und die Daten des interessierenden Ereignisses. Zu den interessierenden Ereignisdaten können scharfes Bremsen und starke Beschleunigung gehören. Eine Vollbremsung kann beispielsweise als eine Verzögerung in einem vorbestimmten Zeitraum (z. B. 40-0 in x Sekunden) und eine Vollbeschleunigung als eine Beschleunigung in einem vorbestimmten Zeitraum (z. B. 40-80 mph in x Sekunden) definiert werden. Die Daten zu den interessierenden Ereignissen können korreliert und für die Verwendung in anderen Algorithmen verarbeitet werden. So kann beispielsweise ein Cluster von starkem Bremsen, der hinsichtlich des Standortes auf einen räumlich-zeitlichen Cluster gemappt ist, als Algorithmus zur Stauerkennung verwendet werden.
• Der Geohashing-Algorithmus kodiert Breiten- und Längengraddaten (Lat/Long) aus Ereignisdaten in eine kurzen String von n Zeichen. In einer Ausführungsform werden die geogehashten Breiten-/Längsdaten in eine Form geogehashed. In einer Ausführungsform können die Breiten-/Längsdaten beispielsweise in ein Rechteck geogehashed werden, dessen Kanten proportional zu den Zeichen in dem String bzw. der Zeichenkette sind. In einer Ausführungsform kann der Geohash zwischen 4 und 9 Zeichen kodiert werden.
• Eine Reihe von Vorteilen ergeben sich aus der Verwendung von geogehashten Ereignisdaten, wie hier beschrieben. Zum Beispiel werden in einer Datenbank durch Geohash indizierte Daten alle Punkte für einen gegebenen rechteckigen Bereich in zusammenhängenden Scheiben aufweisen, wobei die Anzahl der Scheiben durch die Geohash-Präzision der Kodierung bestimmt wird. Dadurch wird die Datenbank verbessert, da Abfragen über einen einzigen Index möglich sind, was wesentlich einfacher und schneller ist als Abfragen über mehrere Indizes. Die Geohash-Indexstruktur ist auch für eine rationalisierte Proximity-Suche nützlich, da die nächstgelegenen Punkte oft zu den nächstgelegenen Geohashes gehören.
• In Block 206 führt das Stream Processing Server System 200 in mindestens einer Ausführungsform eine Standortsuche („location lookup“) durch. Wie oben erwähnt, kann das System in einer Ausführungsform so konfiguriert werden, dass es den Geohash kodiert, um ein definiertes geografisches Gebiet zu identifizieren, z. B. ein Land, einen Staat oder eine Postleitzahl. Das System kann den Breiten-/Längengrad in ein Rechteck geohashen, dessen Kanten proportional zu den Zeichen in der Zeichenfolge sind.
• In einer Ausführungsform kann das Geohashing beispielsweise so konfiguriert werden, dass der Geohash mit 5 Zeichen kodiert wird, und das System kann so konfiguriert werden, dass es einen Staat mit dem 5-stelligen geohashten Ort identifiziert. Beispielsweise ist der auf eine Präzision von 5 Scheiben oder Zeichen kodierte Geohash auf +/- 2,5 Kilometer genau, was ausreicht, um einen Staat zu identifizieren. Ein Geohash mit 6 Zeichen kann verwendet werden, um den geogehashten Standort einer Postleitzahl zuzuordnen, da er auf +/- 0,61 Kilometer genau ist. Ein Geohash mit 4 Zeichen kann verwendet werden, um ein Land zu identifizieren. In einer Ausführungsform kann das System 10 so konfiguriert werden, dass es den Geohash verschlüsselt, um ein Fahrzeug mit dem geogehashten Standort eindeutig zu identifizieren. In einer Ausführungsform kann das System 10 so konfiguriert werden, dass der Geohash mit 9 Zeichen kodiert wird, um ein Fahrzeug eindeutig zu identifizieren.
• In einer Ausführungsform kann das System 10 ferner so konfiguriert sein, dass es die geogehashten Ereignisdaten in eine Kartendatenbank mappt. Die Kartendatenbank kann beispielsweise eine Point-of-Interest-Datenbank oder eine andere Kartendatenbank sein, einschließlich öffentlicher oder proprietärer Kartendatenbanken. Beispielhafte Kartendatenbanken können vorhandene Straßenkartendaten wie Geofabric für lokale Straßenkarten oder die World Map Database umfassen. Das System kann ferner so konfiguriert werden, dass es Mapping- bzw. Kartenschnittstellen erzeugt. Ein beispielhafter Vorteil der Verwendung von Geohashing, wie hier beschrieben, ist, dass es eine viel schnellere Anreicherung der Fahrzeugereignisdaten mit geringer Latenzzeit ermöglicht, wenn diese nachgelagert verarbeitet werden. So lassen sich beispielsweise geografische Definitionen, Kartendaten und andere Anreicherungen leicht auf geogehashte Standorte und Fahrzeug-IDs mappen bzw. abbilden. Feed-Daten können auch zu einem aggregierten Datensatz kombiniert und unter Verwendung einer Schnittstelle visualisiert werden, z. B. mit einem GIS-Visualisierungstool (z. B. Mapbox, CARTO, ArcGIS oder Google Maps API) oder anderen Schnittstellen, um grafische Berichte zu erstellen und zu verknüpfen oder um Berichte an Dritte 15 auszugeben, die die verarbeiteten Daten verwenden, um die analytischen Erkenntnisse zu gewinnen, z. B. über das Egress Server System 400 oder das Portal Server System 600.
• In mindestens einer Ausführungsform kann das Stream Processor Server System 200 in Block 208 so konfiguriert werden, dass die Daten anonymisiert werden, um identifizierende Informationen zu entfernen, beispielsweise durch Entfernen oder Unkenntlichmachen von persönlich identifizierenden Informationen aus einer Fahrzeugidentifikationsnummer (VIN) für Fahrzeugdaten in den Ereignisdaten. In verschiedenen Ausführungsformen können Ereignisdaten oder andere Daten VIN-Nummern enthalten, die Zahlen enthalten, die Produktinformationen für das Fahrzeug darstellen, wie z. B. Marke, Modell und Jahr, und auch Zeichen enthalten, die das Fahrzeug eindeutig identifizieren und verwendet werden können, um es einem Eigentümer persönlich zuzuordnen. Das System 10 kann beispielsweise einen Algorithmus enthalten, der die Zeichen in der VIN, die ein Fahrzeug eindeutig identifizieren, aus den Fahrzeugdaten entfernt, aber andere identifizierende Seriennummern (z. B. für Marke, Modell und Jahr) belässt, z. B. einen Squish-Vin-Algorithmus. In einer Ausführungsform kann das System 10 so konfiguriert werden, dass den anonymisierten Daten ein eindeutiges Fahrzeugkennzeichen („vehicle tag“) hinzugefügt wird. Beispielsweise kann das System 10 so konfiguriert werden, dass es anonymisierten Daten eindeutige Zahlen, Zeichen oder andere identifizierende Informationen hinzufügt, so dass die Ereignisdaten für ein eindeutiges Fahrzeug nachverfolgt, verarbeitet und analysiert werden können, nachdem die der VIN bzw. Fahrgestellnummer zugeordneten personenbezogenen bzw. personenidentifizierenden Informationen entfernt worden sind. Ein beispielhafter Vorteil anonymisierter Daten besteht darin, dass die anonymisierten Daten es ermöglichen, verarbeitete Ereignisdaten extern zur Verfügung zu stellen und gleichzeitig personenbezogene Informationen aus den Daten zu schützen, wie es z. B. gesetzlich vorgeschrieben oder von den Benutzern gewünscht wird.
• In mindestens einer Ausführungsform, wie hier beschrieben, kann ein Geohash mit 9 Zeichen auch eine eindeutige Identifizierung eines Fahrzeugs ermöglichen, ohne dass personenbezogene Informationen, wie z. B. VIN-Daten, eingeholt oder benötigt werden. Fahrzeuge können durch die Verarbeitung von Ereignisdaten aus einer Datenbank identifiziert und mit einer ausreichenden Genauigkeit geogehashed werden, um eindeutige Fahrzeuge zu identifizieren, z. B. auf 9 Zeichen, und das Fahrzeug kann dann identifiziert, verfolgt und seine Daten wie hier beschrieben verarbeitet werden.
• In einer Ausführungsform können die Daten wie hier beschrieben verarbeitet werden. Beispielsweise können unaggregierte Daten in einer Datenbank (z. B. Parquet) gespeichert und nach Zeit unterteilt werden. Die Daten können strombegleitend („in-stream“) validiert und anschließend strombegleitend umgekehrt geokodiert werden. Die Datenanreicherung, z. B. nach Fahrzeugtyp, kann strombegleitend erfolgen. Die Fahrzeugereignisdaten können z. B. nach Region, Fahrt („journey“) und Datum aggregiert werden. Die Daten können in Parquet, aber auch in Postgres gespeichert werden. Referenzdaten können in Parquet für strombegleitende bzw. In-Stream-Merges verwendet werden. Andere Referenzdaten können in Postgres für räumliche Attribute verwendet werden.
• Wie bereits erwähnt, werden beim Echtzeit-Streaming in Block 202 durch die Datenvalidierung Daten herausgefiltert, die eine übermäßige Latenz aufweisen, z. B. eine Latenz von über 7 Sekunden. Die Batch-Datenverarbeitung kann jedoch mit einem vollständigen Datensatz ohne Lücken durchgeführt werden und somit auch Daten enthalten, die nicht auf Latenz gefiltert wurden. Beispielsweise kann ein Batch-Datenprozess für Analysen, wie in 5 beschrieben, so konfiguriert sein, dass er Daten akzeptiert, die bis zu 6 Wochen alt sind, während der Streaming-Stack des Stream Processing Server Systems 200 so konfiguriert ist, dass er Daten filtert, die über 7 Sekunden alt sind, und somit die Latenzvalidierungsprüfung in Block 202 umfasst und Ereignisse mit höherer Latenz zurückweist.
• In einer Ausführungsform werden in Block 212 sowohl die transformierten, nach Latenz gefilterten Standortdaten als auch die zurückgewiesenen Latenzdaten in eine Server-Warteschlange, z. B. eine Apache-Kafka-Warteschlange, eingegeben. In Block 214 kann das Stream Processing Server System 200 die Daten in einen Datensatz, der die vollständigen Daten 216 - die nach Latenz gefilterten transformierten Standortdaten und die zurückgewiesenen Latenzdaten - enthält und einen weiteren Datensatz mit den transformierten Standortdaten 222 aufteilen. Die vollständigen Daten 216 werden im Datenspeicher 107 für den Zugriff oder die Lieferung an das Analytics Server System 500 gespeichert, während die gefilterten transformierten Standortdaten an das Egress Server System 400 geliefert werden. In einer anderen Ausführungsform kann der vollständige Datensatz oder Teile davon, einschließlich der zurückgewiesenen Daten, auch an das Egress Server System 400 für Plattformen von Drittanbietern zur deren eigener Verwendung und Analyse geliefert werden. In einer solchen Ausführungsform können in Block 213 transformierte Standortdaten, die nach Latenz gefiltert wurden, und die zurückgewiesenen Latenzdaten direkt an das Egress Server System 400 geliefert werden.
• 4A ist eine logische Architektur für ein Egress Server System 400, In mindestens einer Ausführungsform kann das Egress Server System 400 aus einem oder mehreren Computern bestehen, die so angeordnet sind, dass sie Durchsatzdatensätze einlesen („ingress“) und Ereignisdaten ausgeben. In einer Ausführungsform kann das System 10 beispielsweise so konfiguriert sein, dass es einen Push-Server 410 aus einem Apache Spark-Cluster verwendet. Der Push-Server 410 kann so konfiguriert werden, dass er transformierte Standortdaten aus dem Stream Processing Server-System 200 verarbeitet, z. B. für eine Latenzfilterung 411, eine Geofilterung 412, eine Ereignisfilterung 413, eine Transformation 414 und eine Transmission 415. Wie hierin beschrieben, verbessert Geohashing die Durchsatzlatenz des Systems 10, was Vorteile bei der rechtzeitigen Push-Benachrichtigung für Daten ermöglicht, die in unmittelbarer Nähe von Ereignissen verarbeitet werden, zum Beispiel innerhalb von Minuten und sogar Sekunden. In einer Ausführungsform ist das System 10 beispielsweise so konfiguriert, dass eine Latenzzeit von unter 60 Sekunden angestrebt wird. Wie bereits erwähnt, ist das Stream Processing Server System 200 so konfiguriert, dass es Ereignisse mit einer Latenzzeit von weniger als 7 Sekunden filtert, was ebenfalls den Durchsatz verbessert. In einer Ausführungsform kann ein Datenspeicher 406 für Abrufdaten („pull data store“) über ein API-Gateway 404 bereitgestellt werden, und eine Abruf-API 405 kann verfolgen, welche Drittpartei-Benutzer 15 Daten abrufen und nach welchen Daten die Benutzer fragen.
• In mindestens einer Ausführungsform kann der Egress Server 400 einen oder mehrere Computer umfassen, die so angeordnet sind, dass sie Durchsatzdatensätze einlesen und Ereignisdaten ausgeben. Das Egress Server System 400 kann so konfiguriert werden, dass es Daten auf einer Push- oder einer Pull-Basis bereitstellt. In einer Ausführungsform kann das System beispielsweise so konfiguriert sein, dass es einen Push-Server 410 von einem Apache Spark-Cluster oder ein verteiltes Serversystem für die parallele Verarbeitung über mehrere Knoten einsetzt, z. B. eine Scala- oder Java-Plattform auf einer Akka-Server-Plattform.
• In einer Ausführungsform, wie hier beschrieben, verbessert Geohashing die Latenzzeit des Systemdurchsatzes beträchtlich, was Vorteile bei der rechtzeitigen Push-Benachrichtigung für Daten ermöglicht, die in unmittelbarer Nähe zu Ereignissen verarbeitet werden, beispielsweise innerhalb von Minuten und sogar Sekunden. In einer Ausführungsform ist das System beispielsweise so konfiguriert, dass eine Latenzzeit von unter 60 Sekunden angestrebt wird. Wie bereits erwähnt, ist die Stream-Verarbeitung so konfiguriert, dass Ereignisse mit einer Latenz von weniger als 7 Sekunden herausgefiltert werden, wodurch sich der Durchsatz auch verbessert. In einer anderen Ausführungsform kann der Egress Server Ereignisanalysealgorithmen zur Bereitstellung von Streams mit hohem Durchsatz und geringer Latenz für nachgelagerte Schnittstellen, z. B. Partner-Client-Schnittstellen 20, enthalten.
• In einer Ausführungsform kann ein Datenspeicher 403 für Pull-Daten bereitgestellt werden, und eine Pull-API 404 kann verfolgen, welche Benutzer Daten abrufen („pulling“) und welche Daten sie anfordern.
• In einer Ausführungsform kann der Egress Server 400 beispielsweise Musterdaten („pattern data“) auf der Grundlage von durch das System bereitgestellten Filtern bereitstellen. Zum Beispiel kann das System so konfiguriert werden, dass es einen Geofence-Filter bereitstellt, um Ereignisdaten für einen bestimmten Ort oder bestimmte Orte zu filtern. Wie zu erkennen ist, kann Geofencing so konfiguriert werden, dass Fahrt- und/oder Ereignisdaten wie hierin beschrieben für zahlreiche Muster und Konfigurationen gebunden und verarbeitet werden. In einer Ausführungsform kann der Egress Server beispielsweise so konfiguriert werden, dass er einen „Parken“-Filter bereitstellt, der so konfiguriert ist, dass die Daten zu dem Beginn und dem Ende der Fahrt (Zündung_Schlüssel-Ein/Aus-Ereignisse) innerhalb der vom Benutzer angegebenen oder ausgewählten Längen-/Breitengrade beschränkt werden. Weitere Filter oder Ausnahmen für diese Daten können konfiguriert werden, z. B. nach Staat bzw. Bundesland (Staatscode oder Breiten-/Längengrad). Das System kann auch mit einem „Traffic“- bzw. „Verkehrs“-Filter konfiguriert werden, um z. B. Daten zu Verkehrsmustern zu liefern, wobei bestimmte Staaten und Längen-/Breitengrade von den Filtern ausgeschlossen werden.
• In einer Ausführungsform kann der Egress Server 400 so konfiguriert werden, dass er Daten mit Algorithmen mit niedriger Latenz verarbeitet, die so konfiguriert sind, dass sie den Echtzeit-Durchsatz mit niedriger Latenz aufrechterhalten und verbessern. Die Algorithmen können so konfiguriert werden, dass sie die Daten für eine Dateiausgabe mit niedriger Latenz verarbeiten, die nachgelagerte Schnittstellen befüllen kann, die gezielte, die Rechenressourcen nicht verstopftende oder diese unbrauchbar machende Echtzeitdaten benötigen. In einer Ausführungsform ist das System so konfiguriert, dass es Daten zur durchschnittlichen Straßengeschwindigkeit mit niedriger Latenz für Straßensegmente zur Ausgabe in nahezu Echtzeit aus einem Live-Datenstrom von Fahrzeugbewegungen vom Stream Processing Server 200 bereitstellt. Der Egress Server 400 kann auch so konfiguriert werden, dass er Rohdaten löscht, um Partnern 20 leichtgewichtige Datenpakete zur Verfügung zu stellen, und dass er für nachgelagerte Schnittstellen konfiguriert wird, beispielsweise über den Push-Server 410.
• In einer Ausführungsform kann der Egress Server so konfiguriert werden, dass er Daten, die nach außen übertragen werden, ohne Anwendung von Filtern drosselt. Ein beispielhafter Vorteil der Konfiguration des Systems zur Drosselung der ausgegebenen („egressed“) Daten ist die Fähigkeit, die Anzahl der Analysen von Fahrzeugereignisdaten und die Größe der an externe Systeme und Clients ausgegebenen Datenpakete zu steuern. Externe Systeme und Clients können unter Umständen nicht so konfiguriert sein, dass sie das Volumen der vom System verarbeiteten Fahrzeugereignisdaten akzeptieren. Ein weiterer beispielhafter Vorteil der filterlosen Drosselung besteht darin, dass das System einen relativ leichtgewichtigen Algorithmus verwenden kann, um große Mengen von Fahrzeugereignisdaten und deren Analyse ohne komplexe Filter zu verarbeiten, die sich negativ auf die Latenzzeit und die Verarbeitung auswirken.
• 4B zeigt einen Prozess zur Drosselung von Fahrzeugereignisdaten. In Block 416 ist das System so konfiguriert, dass es Echtzeit-Fahrzeugbewegungs-Ereignisdaten mit hohem Durchsatz aufnimmt („ingests“), die Standardtrip-Ereignisdaten umfassen, die vom Ingress Server 100 aufgenommen („ingressed“) und vom Stream Processing Server 300 verarbeitet werden, die Informationen wie eine Geräte bzw. Vorrichtungs-ID, Breiten-/Längenangaben, Zündstatus, Geschwindigkeit und einen Zeitstempel enthalten.
• In einer Ausführungsform ist das System so konfiguriert, dass es Daten basierend auf einer Fahrzeugkennung („vehicle identifier“) für ein Fahrzeug drosselt. Das System kann so konfiguriert werden, dass es Daten für Fahrereignisdaten und Fahrzeugbewegungsdaten drosselt. Das System kann auch so konfiguriert werden, dass es eine Drosselung sowohl für die Stream-Verarbeitung durch den Stream Processing Server 200 als auch für die Batch-Verarbeitung, beispielsweise durch den Analytics Server 500, vornimmt. Das System kann so konfiguriert werden, dass es eine eindeutige Fahrzeug-ID verwendet, die zufällig und nicht geografisch voreingenommen ist.
• Das System ist so konfiguriert, dass es Fahrzeugereignisdaten aus einem Datenstrom von Fahrzeugbewegungsereignissen bereitstellt. Die Fahrzeugereignisdaten werden anhand der in Tabelle 5 aufgeführten Informationen verarbeitet. Tabelle 5

  	Bezeichnung	Einzelheiten
  1	Fahrzeugkennung	Zufällige eindeutiger Kennung für ein Fahrzeug.
  2	Gesamtfahrzeuge	Gesamtzahl der Fahrzeuge auf der Plattform im Vormonat, wie sie in den Datamart-Aggregationen erfasst ist. Diese werden pro OEM/Drittanbieter-Umgebung geführt.
  3	Gesamtbuckets	Die Gesamtzahl der Buckets bzw. Töpfe (Bereiche), in die die Fahrzeuge aufgeteilt werden. Dies ist ein konfigurierbarer Wert pro OEM-Umgebung. Er sollte den Wert Fahrzeuge insgesamt nicht überschreiten.
  4	Grenzwert für Fahrzeuge	Die ungefähre Anzahl der Fahrzeuge, auf die ein Egress-Partner beschränkt werden soll. Dies ist ein konfigurierbarer Wert pro Egress-Partner-Feed.
  5	Minimaler Zusatzprozentsatz	Der Mindestprozentsatz zusätzlicher Fahrzeuge, die zur Ausgabe hinzugefügt werden. Dies ist ein konfigurierbarer Wert pro OEM-Umgebung. Dabei wird berücksichtigt, dass nicht alle Fahrzeuge in einem bestimmten Zeitraum aktiv sind, und es wird die Tatsache kompensiert, dass die Einteilung in Buckets nicht exakt ist.
  6	Fahrzeuge pro Bucket	Die Anzahl der Fahrzeuge, die sich in jedem Bucket befinden werden (unter der Annahme einer gleichmäßigen Verteilung). Berechnet.
  7	Erforderliche Buckets	Die Anzahl der Buckets, die benötigt werden, um die gewünschte Anzahl von Fahrzeugen bereitzustellen. Berechnet.
  8	Fahrzeugziel	Die Zielanzahl der Fahrzeuge, die an den Egress-Partner gesendet werden sollen. Berechnet.
  9	Fahrzeugkennungs-Hash	Der positive Hash-Wert für die Fahrzeugkennung. Berechnet.
  10	Fahrzeugbucket	Der Bucket, dem ein Fahrzeug zugeordnet ist.

• In Block 417 ist das System so konfiguriert, dass es die Fahrzeuge pro Bucket berechnet, indem es die Gesamtanzahl der Fahrzeuge durch die Anzahl der Buckets teilt. In Block 418 ist das System so konfiguriert, dass es ein Fahrzeugziel berechnet, indem es einen minimalen zusätzlichen Prozentsatz an Fahrzeugen berechnet und zu den Gesamtfahrzeugen addiert. In Block 419 wird das System so konfiguriert, dass es die erforderlichen Buckets berechnet, indem es das Fahrzeugziel durch die Fahrzeuge pro Bucket teilt. Die erforderlichen Buckets werden auf eine ganze Zahl aufgerundet. In einer Ausführungsform werden die Blöcke 417 bis 419 periodisch neu berechnet, um eine Anpassung an schwankende Fahrzeugmengen aus den Fahrzeugereignisdaten vorzunehmen. So hat sich beispielsweise die Neuberechnung alle 24 Stunden als vorteilhaft für die Identifizierung von Verkehrsmustern erwiesen. In einer Ausführungsform können die Blöcke 417 bis 419 auch vorberechnet werden, und das System erfordert nicht, dass die Berechnungen für jeden Fahrzeugdatensatz ausgeführt werden.
• In Block 420 ist das System so konfiguriert, dass es einen Fahrzeugkennungs- bzw. Fahrzeugidentifikator-Hashwert berechnet, indem es die Fahrzeugkennung hasht und eine positive Zahl sicherstellt. In Block 421 ist das System so konfiguriert, dass es einen Fahrzeugbucket berechnet, indem es den Modulus des Hash-Wertes der Fahrzeugkennung durch die Gesamtzahl der Buckets heranzieht bzw. teilt. In Block 422 wird der Datensatz in den Bucket aufgenommen, wenn der Fahrzeugbucket (Vehicle Bucket) kleiner oder gleich den erforderlichen Buckets (Required Buckets) ist, und für die Egress-Ausgabe in Block 415 übertragen („transmitted“) (4A). Ist der Fahrzeugbucket größer als die erforderlichen Buckets, wird der Datensatz aus der Egress-Ausgabe verworfen. Natürlich können der ursprüngliche Datensatz und die verarbeiteten Fahrten- und Reisedaten erhalten und gespeichert werden. In einer Ausführungsform werden die Daten nur ausgegeben oder gelöscht, je nachdem, ob sie die erforderlichen Bucketkriterien (Required Bucket criteria) erfüllen. Ein weiterer Vorteil des Drosselungsalgorithmus besteht darin, dass er die Systemleistung und die Leistung der Datenausgabe durch selektives Löschen oder Ausgeben von Daten verbessert, ohne dass Filter erforderlich sind.
• Ein Arbeitsbeispiel für einen Drosselungsalgorithmus, der in Bezug auf 4B beschrieben wird, lautet wie folgt:
• Gesamtfahrzeugzahl = 9,2 Millionen
• Gesamtbucketzahl = 1 Million
• Fahrzeuggrenzwert = 3 Millionen
• Minimaler Zusatzprozentsatz = 5%
• Fahrzeugkennung bzw. Fahrzeug-ID = Fahrzeug 12345
$$\begin{array}{l}\text{Fahrzeuge pro Bucket}=\text{Gesamtfahrzeugzahl}/\text{Gesamtbucketzahl}=\mathrm{9,2}\text{Millionen}/1\text{ Milion}\\ =\mathrm{9,2}\end{array}$$

$$\begin{array}{l}\text{Fahrzeugziel}=(\text{Fahrzeuggrenzwert}*\text{minimaler Zusats}\text{prozentsatz})+\text{Fahrzeuggrenzwert}=\\ \left(3\text{ Millionen}*5\%\right)+3\text{ Millionen}=\mathrm{3,15}\text{Millionen}\end{array}$$

$$\begin{array}{l}\text{Erforderliche BucketsAufrunden}\left(\text{Fahrzeugziel}/\text{Fahrzeuge pro Bucket}\right)=\text{Aufrunden}\\ \left(\text{3}\text{,15 Millionen}/\mathrm{9,2}\right)=342392\end{array}$$

$$\begin{array}{l}\text{Fahrzeugkennungs}-\text{Hashwert}=\text{Hash}\left(\text{Fahrzeugkennung}\right)=\text{Hash}\left(\text{Fahrzeug12345}\right)=\\ 1909956441\end{array}$$

$$\begin{array}{l}\text{Fahrzeugbucket}=\text{Fahrzeugkennungs}-\text{Hashwert\%Gesamtbucketzahl=1909956441}\%\text{1}\\ \text{Million}=956411\end{array}$$

$$\begin{array}{l}\text{In Ausgabe einbeziehen}=\left(\text{Fahrzeugbucket }<=\text{Erforderliche Buckets}\right)=(956441<=\\ 342392)=\text{falsch}\end{array}$$

• Wie man sieht, kann das System so konfiguriert werden, dass es den Hash unter Verwendung eines entsprechend leistungsfähigen Partitionsalgorithmus ausführt, wie z. B. ein Kafka-Partitions-Hashing unter Verwendung von murmur2.
• Wie hierin erläutert, ist eine verbesserte Latenzzeit nicht zufällig mit dem Design und der Implementierung des Algorithmus und den Ereignisaufzeichnungscontainern verbunden, die für die Ausgabe von Segmentereignissen verwendet werden, da eine niedrige Latenzzeit ein wichtiges technisches Merkmal des Systems ist. Darüber hinaus ermöglicht die Drosselung von Ereignisaufzeichnungscontainern den Betrieb nachgeschalteter Konsolen, z. B. Verkehrsmanagementkonsolen. In Block 415 von 4A kann beispielsweise Segmentereignissdatensätze in Echtzeit vom Push-Server 410 an externe Partner 20 übertragen werden. In einer Ausführungsform kann der Segmentereignisdatensatz beispielsweise so konfiguriert werden, dass er vom Push-Server 410 an eine Schnittstelle wie einen AWS S3-Bucket, Web-Sockets oder eine API übermittelt wird. In einer Ausführungsform können Segmentereignisdatensätze an den Analytics Server 500 für die Erkenntnisverarbeitung übertragen und an den Portal Server 600 für APIs oder andere Schnittstellen ausgegeben werden. Daher ist das System in Block 418 so konfiguriert, dass es die Rohdaten an dem Egress Server 400 verwirft, um sowohl die systemeigene Latenz als auch die Bedienbarkeit der nachgelagerten Schnittstellen und Konsolen zu verbessern.
• Ein weiterer beispielhafter Vorteil der Systemkonfiguration ist, dass der Drosselungsalgorithmus geografisch agnostisch bzw. unabhängig ist. Da der Algorithmus so konfiguriert ist, dass er die Fahrzeugkennung bzw. Fahrzeug-ID verwendet, können Fahrzeugdaten und Ereignisdatenpunkte an Dritte als ein in Buckets gegebener („bucketed“) Prozentsatz von Fahrzeugen ausgegeben werden, ohne dass Fahrzeuge auf einen geografischen Filter beschränkt werden. Auf diese Weise kann ein externer Kunde einen Datenfluss erhalten, der für die Gesamtheit der von ihm gewünschten Ereignisdaten repräsentativ ist, ohne dass ein unerwünschter Filter angewendet wird, z. B. durch Ausschluss bestimmter geografischer Gebiete (z.B. Staaten, Regionen, Länder, gezielte („targeted“) Geofences).
• Ein weiterer beispielhafter Vorteil der Systemkonfiguration besteht darin, dass das System die Menge der Daten kontrollieren kann, die externen Stellen zur Verfügung gestellt werden, ohne Filter anzuwenden, die die Daten verändern. Wenn beispielsweise ein externer Client nicht für ein größeres Datenvolumen konfiguriert ist, kann das System so konfiguriert werden, dass es die Daten auf einen Fluss drosselt, den der externe Client operativ verarbeiten kann. Das System kann auch so konfiguriert werden, dass es festlegt, wie viele Fahrzeuge pro Partner gedrosselt werden sollen. Ebenso kann die Systemkonfiguration den Ereignisdatenfluss aus anderen Gründen drosseln, z.B. um vertragliche oder Systemanforderungen eines Kunden oder Partners in Bezug auf Latenz und Verfügbarkeit zu erfüllen. Dementsprechend bietet der Drosselungsalgorithmus den Vorteil, dass er eine konsistente und vorhersehbare Datenmenge bereitstellt, um einen Bedarf und die Systemkapazität eines Kunden zu unterstützen. So kann das System beispielsweise so konfiguriert werden, dass die Anzahl der Fahrzeuge, die an einen Egress-Partner gesendet werden, im Wesentlichen gleich bleibt, wenn Fahrzeuge von der Plattform kommen und gehen.
• Ein weiterer beispielhafter Vorteil besteht darin, dass das System so konfiguriert werden kann, dass es die vollständigen Fahrten- oder Reisedaten aufbewahrt, nachdem das System die Daten gedrosselt hat. Ein weiterer beispielhafter Vorteil ist, dass die Daten sowohl für Streamals auch für Batch-Liefermechanismen gedrosselt werden können.
• 5 stellt die Logikarchitektur eines Analytics Server Systems 500 für Datenanalyse und Einblicke dar. In mindestens einer Ausführungsform kann das Analytics Server System 500 aus einem oder mehreren Computern bestehen, die zur Analyse von Ereignisdaten eingerichtet sind. Sowohl Echtzeit- als auch Batch- bzw. Stapeldaten können an das Analytics Server System 500 zur Verarbeitung von anderen Komponenten, wie hier beschrieben, weitergeleitet werden. In einer Ausführungsform kann das Analytics Server System 500 einen Cluster-Computing-Framework- und Batch-Prozessor, wie z. B. einen Apache Spark Cluster, verwenden, der Batch- und Streaming-Datenverarbeitung kombiniert. Die dem Analytics Server System 500 zur Verfügung gestellten Daten können beispielsweise Daten von dem Ingress Server System 100, dem Stream Processing Server System 200 und dem Egress Server System 400 umfassen.
• In einer Ausführungsform kann das Analytics Server System 500 so konfiguriert sein, dass es Fahrzeugereignis-Nutzdaten und verarbeitete Informationen akzeptiert, die in Datenspeichern, wie z. B. Datenspeichern 107, gespeichert werden können. Wie in 5 gezeigt, umfasst der Speicher Echtzeit-Ausgangsdaten vom Egress Server System 400, transformierte Standortdaten und zurückgewiesene Daten vom Stream Processing Server System 200 sowie Batch- und Echtzeit-Rohdaten von dem Ingress Server System 100. Wie in 2 dargestellt, können die im Datenspeicher 107 gespeicherten eingegangenen Standorte („ingressed locations“) in das Analytics Server System 500 ausgegeben oder gezogen („pulled“) werden. Das Analytics Server System 500 kann so konfiguriert werden, dass es die eingegangenen Standortdaten auf die gleiche Weise verarbeitet wie das Stream Processing Server System 200, wie in 2 dargestellt. Wie bereits erwähnt, kann das Stream Processing Server System 200 so konfiguriert werden, dass es die Daten in einen vollständigen Datensatz 216 mit vollständigen Daten (transformierte Standortdaten, die nach Latenz gefiltert wurden, und die zurückgewiesenen Latenzdaten) und einen Datensatz mit transformierten Standortdaten 222 aufteilt. Der vollständige Datensatz 216 wird im Datenspeicher 107 für den Zugriff oder die Lieferung an das Analytics Server System 500 gespeichert, während die gefilterten transformierten Standortdaten an das Egress Server System 400 geliefert werden. Wie in 5 gezeigt, können gefilterte Daten in Echtzeit für die Berichterstattung in nahezu Echtzeit verarbeitet werden, einschließlich Berichten zur Leistung („performance“) 522, Ingress vs. Egress 524, Betriebsüberwachung 526 und Alarmierung bzw. Warnmeldungen 528.
• 6 ist eine Logikarchitektur für ein Portal Server System 600. In mindestens einer Ausführungsform kann das Portalserversystem 600 aus einem oder mehreren Computern bestehen, die so angeordnet sind, dass sie Datensätze und Ereignisdaten aufnehmen und durchleiten. Das Portalserversystem 600 kann mit einer Portalbenutzerschnittstelle („Portal UI“) 604 und einem API-Gateway 606 für eine Portal-API 608 konfiguriert werden, um Daten von Drittnutzern 15 der Plattform anzuschließen und Daten von den Drittnutzern 15 zu akzeptieren. In einer Ausführungsform kann das Portal Server System 600 so konfiguriert werden, dass es tägliche statische Aggregate bereitstellt und mit einer Suchmaschine und Zugangsportalen für den Echtzeitzugriff auf die vom Analytics Server System 500 bereitgestellten Daten konfiguriert ist. In mindestens einer Ausführungsform kann das Portal Server System 600 so konfiguriert sein, dass es den Benutzern, z. B. den Client-Computern von Dritten 15, ein Dashboard zur Verfügung stellt. In mindestens einer Ausführungsform können Informationen vom Analytics Server System 500 an einen Berichts- oder Schnittstellengenerator fließen, der von einer Portalbenutzerschnittstelle 604 bereitgestellt wird. In mindestens einer Ausführungsform kann ein Berichts- oder Schnittstellengenerator so eingerichtet sein, dass er einen oder mehrere Berichte auf der Grundlage der Leistungsinformationen erstellt. In mindestens einer Ausführungsform können die Berichte auf der Grundlage einer oder mehrerer Berichtsvorlagen bestimmt und formatiert werden.
• Die niedrige Latenzzeit sorgt für eine superschnelle Verbindung, die Informationen von der Fahrzeugquelle zum Endkunden liefert. Die weitere Datenerfassung hat eine hohe Erfassungsrate („capture rate“) von 3 Sekunden pro Datenpunkt, wodurch beispielsweise bis zu 330 Milliarden Datenpunkte pro Monat erfasst werden können. Wie hier beschrieben, sind die Daten präzise bis auf Fahrspur-Ebene mit Standortdaten und mit einer Genauigkeit von 95 % innerhalb eines 3-Meter-Radius, der Größe eines typischen Autos.
• 7 ist ein Flussdiagramm, das eine Datenpipeline der oben beschriebenen Datenverarbeitung zeigt. Wie in 7 dargestellt, durchlaufen die Ereignisdaten in einer Ausführungsform eine siebenstufige (7) Pipeline von Datenqualitätsprüfungen. Darüber hinaus werden Datenverarbeitungen sowohl in Form von Stream- als auch in Form von Batch-Verarbeitung durchgeführt. Beim Streaming wird jeweils ein Datensatz zur Zeit verarbeitet, ohne dass der Kontext irgendwelcher früherer Datensätze für eine Fahrt berücksichtigt wird, und es kann für Überprüfungen verwendet werden, die auf dem Attribut- und Datensatz-Level ausgeführt werden. Die Batch-Verarbeitung bietet eine umfassendere Sicht auf die Daten und kann den gesamten Endto-End-Prozess abdecken. Bei der Batch-Verarbeitung werden dieselben Prüfungen wie bei der Streaming-Verarbeitung durchgeführt, und zusätzlich Prüfungen, die für mehrere Datensätze und Fahrten durchgeführt werden.
• In mindestens einer Ausführungsform kann eine Dashboard-Anzeige eine Darstellung der von den anderen Komponenten des Systems 10 erzeugten Informationen wiedergeben. In mindestens einer Ausführungsform kann die Dashboard-Anzeige auf einem Client-Computer dargestellt werden, auf den über ein Netzwerk zugegriffen wird. In mindestens einer Ausführungsform können Benutzerschnittstellen verwendet werden, ohne vom Geist und/oder Schutzumfang des beanspruchten Gegenstands abzuweichen. Solche Benutzeroberflächen können eine beliebige Anzahl von Benutzeroberflächenelementen aufweisen, die auf verschiedene Weise angeordnet sein können. In einigen Ausführungsformen können Benutzerschnittstellen unter Verwendung von Webseiten, mobilen Anwendungen, GIS-Visualisierungstools, Mapping-Schnittstellen, E-Mails, Dateiservern, PDF-Dokumenten, Textnachrichten oder ähnlichem erzeugt werden. In mindestens einer Ausführungsform können das Ingress Server System 100, das Stream Processing Server System 200, das Egress Server System 400, das Analytics Server System 500 oder das Portal Server System 600 Prozesse und/oder APIs zur Erzeugung von Benutzerschnittstellen enthalten.
• Wie hierin beschrieben, können Ausführungsformen des Systems 10, von Prozessen und von Algorithmen so konfiguriert werden, dass sie auf einem Webservice-Plattform-Host wie Amazon Web Services (AWS)® oder Microsoft Azure® laufen. Eine Cloud-Computing-Architektur ist für einen bequemen On-Demand-Netzwerk-Zugang zu einem gemeinsamen Pool von konfigurierbaren Computing-Ressourcen (z. B. Netzwerke, Netzwerk-Bandbreite, Server, Verarbeitung, Speicher, Anwendungen, virtuelle Maschinen und Dienstleistungen) konfiguriert. Eine Cloud-Computerplattform kann so konfiguriert werden, dass ein Plattformanbieter Rechenkapazitäten („computing capabilities“) wie Serverzeit und Netzwerkspeicher einseitig und automatisch nach Bedarf bereitstellen kann, ohne dass eine menschliche Interaktion mit dem Anbieter des Dienstes erforderlich ist. Außerdem ist Cloud Computing über ein Netzwerk verfügbar und der Zugriff erfolgt über Standardmechanismen, die die Nutzung durch heterogene Thin- oder Thick-Client-Plattformen (z. B. Mobiltelefone, Laptops und PDAs) fördern. In einer Cloud-Computing-Architektur können die Rechenressourcen einer Plattform zusammengelegt werden, um mehrere Verbraucher, Partner oder andere Drittnutzer unter Verwendung eines Multi-Tenant-Modell zu bedienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch zugewiesen und je nach Bedarf neu zugewiesen werden. Eine Cloud-Computing-Architektur ist auch so konfiguriert, dass Plattformressourcen schnell und elastisch bereitgestellt werden können, in einigen Fällen automatisch, um schnell hoch bzw. aus zu skalieren, und rasch freigegeben werden können, um schnell herunter bzw. ein zu skalieren.
• Cloud-Computing-Systeme können mit Systemen konfiguriert werden, die die Ressourcennutzung automatisch steuern und optimieren, indem sie eine Messfähigkeit auf einer für die Art des Dienstes (z. B. Speicher, Verarbeitung, Bandbreite und aktive Benutzerkonten) geeigneten Abstraktionsebene wirksam nutzen. Die Ressourcennutzung kann überwacht, gesteuert und gemeldet werden. Wie hierin beschrieben, wird das System 10 in Ausführungsformen vorteilhafterweise vom Plattformanbieter mit innovativen Algorithmen und Datenbankstrukturen konfiguriert, die für niedrige Latenzzeiten ausgelegt sind.
• Eine Cloud-Computing-Architektur umfasst eine Reihe von Dienst- und Plattformkonfigurationen.
• Eine Software-as-a-Service (SaaS) ist so konfiguriert, dass ein Plattformanbieter die Anwendungen des Anbieters („provider“) nutzen kann, die auf einer Cloud-Infrastruktur laufen. Die Anwendungen sind von verschiedenen Client-Geräten aus über eine Thin-Client-Schnittstelle wie einen Webbrowser (z. B. webbasierte E-Mail) zugänglich. Der Verbraucher verwaltet oder steuert in der Regel nicht die zugrunde liegende Cloud-Infrastruktur, einschließlich Netzwerk, Server, Betriebssysteme, Speicher, oder sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme begrenzter benutzerspezifischer Anwendungskonfigurationseinstellungen.
• Eine Platform-as-a-Service (PaaS) ist so konfiguriert, dass ein Plattformanbieter in der Cloud-Infrastruktur vom Kunden erstellte oder erworbene Anwendungen bereitstellen kann, die mit den vom Anbieter unterstützten Programmiersprachen und Tools erstellt wurden. Der Kunde verwaltet oder kontrolliert nicht die zugrunde liegende Cloud-Infrastruktur, einschließlich Netzwerken, Servern, Betriebssystemen oder Speicherplatz, kann aber die Kontrolle über die bereitgestellten Anwendungen und möglicherweise die Konfigurationen der Anwendungs-Hosting-Umgebung haben.
• Eine Infrastructure-as-a-Service (IaaS) ist so konfiguriert, dass ein Plattformanbieter Verarbeitungs-, Speicher-, Netzwerk- und andere grundlegende Rechenressourcen bereitstellen kann, auf denen der Verbraucher beliebige Software einsetzen und ausführen kann, die Betriebssysteme und Anwendungen enthalten kann. Der Verbraucher verwaltet oder kontrolliert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen, und hat möglicherweise eine begrenzte Kontrolle über ausgewählte Netzkomponenten (z. B. Host-Firewalls).
• Eine Cloud-Computing-Architektur kann als private Cloud-Computing-Architektur, als Community-Cloud-Computing-Architektur oder als öffentliche Cloud-Computing-Architektur bereitgestellt werden. Eine Cloud-Computing-Architektur kann auch als hybride Cloud-Computing-Architektur konfiguriert werden, die zwei oder mehr Cloud-Plattformen (privat, Community/gemeinschaftlich oder öffentlich) umfasst, die eigenständige Einheiten bleiben, aber durch standardisierte oder proprietäre Technologie miteinander verbunden sind, die die Übertragbarkeit bzw. Portabilität von Daten und Anwendungen ermöglicht (z. B. Cloud-Bursting für den Lastausgleich zwischen Clouds).
• Eine Cloud-Computing-Umgebung ist Service-orientiert und legt den Schwerpunkt auf Zustandslosigkeit, geringe Kopplung, Modularität und semantische Interoperabilität. Das Herzstück des Cloud-Computing ist eine Infrastruktur, die ein Netzwerk von miteinander verbundenen Knoten umfasst.
• In 8 ist eine beispielhafte Cloud-Computing-Umgebung 50 dargestellt. Wie dargestellt, umfasst die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 30, mit denen lokale Computergeräte, die von Cloud-Konsumenten verwendet werden, wie z. B. ein persönlicher digitaler Assistent (PDA) oder ein Mobiltelefon 23, ein Desktop-Computer 21, ein Laptop-Computer 22, und ein Ereignis, wie z. B. eine OEM-Fahrzeugsensordatenquelle 14, eine Anwendungsdatenquelle 16, eine Telematikdatenquelle 20, eine drahtlose Infrastrukturdatenquelle 17 und eine Drittanbieter-Datenquelle 15 und/oder Automobil-Computersysteme, wie z. B. eine Fahrzeugdatenquelle 12, verbunden sind. Die Knoten 30 können miteinander kommunizieren. Sie können physisch oder virtuell in einem oder mehreren Netzwerken gruppiert sein (nicht dargestellt), wie z. B. private, Community/gemeinschaftliche, öffentliche oder hybride Clouds, wie hier beschrieben, oder in eine Kombination davon. Die Cloud-Computing-Umgebung 50 ist so konfiguriert, dass sie Infrastruktur, Plattformen und/oder Software als Dienste anbietet, für die ein Cloud-Kunde keine Ressourcen auf einem lokalen Computergerät vorhalten muss. Es versteht sich, dass die in 9 gezeigten Arten von Computergeräten nur zur Veranschaulichung dienen und dass die Computing-Knoten 30 und die Cloud-Computing-Umgebung 50 mit jeder Art von Computergerät über jede Art von Netzwerk und/oder netzwerkadressierbare Verbindung (z. B. mittels eines Webbrowsers) kommunizieren können.
• 9 zeigt eine Reihe von funktionalen Abstraktionsschichten, die von der Cloud-Computing-Umgebung 50 ( ) bereitgestellt werden. Die in 9 dargestellten Komponenten, Schichten und Funktionen sind illustrativ und die hier beschriebenen Ausführungsformen sind nicht darauf beschränkt. Wie dargestellt, sind die folgenden Ebenen und entsprechenden Funktionen vorgesehen:
• Eine Hardware- und Softwareschicht 60 kann Hardware- und Softwarekomponenten aufweisen. Beispiele für Hardwarekomponenten sind z. B. Großrechner bzw. Mainframes 61, Server 62, Server 63, Blade-Server 64, Speichergeräte 65 sowie Netzwerke und Netzwerkkomponenten 66. In einigen Ausführungsformen gehören zu den Softwarekomponenten Netzwerkanwendungsserversoftware 67 und Datenbanksoftware 68.
• Eine Virtualisierungsschicht 70 bietet eine Abstraktionsschicht, von der aus die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 71; virtuelle Speicher 72; virtuelle Netzwerke 73, einschließlich virtueller privater Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
• In einem Beispiel kann eine Verwaltungsschicht 80 die unten beschriebenen Funktionen bereitstellen. Die Ressourcenbereitstellung 81 ermöglicht die dynamische Beschaffung von Rechenressourcen und anderen Ressourcen, die zur Ausführung von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Messungen und Preisgestaltung 82 ermöglichen die Kostenverfolgung bei der Nutzung von Ressourcen innerhalb der Cloud-Computing-Umgebung und die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungssoftware umfassen. Sicherheit („Security“) bietet Identitätsüberprüfung für Cloud-Kunden und -Aufgaben sowie Schutz für Daten und andere Ressourcen. Das Benutzerportal 83 ermöglicht Verbrauchern und Systemadministratoren den Zugriff auf die Cloud-Computing-Umgebung. Das Service-Level-Management 84 sorgt für die Zuweisung und Verwaltung von Cloud-Computing-Ressourcen, damit die erforderlichen Service-Levels eingehalten werden. Service Level Agreement (SLA)-Planung und -Erfüllung 85 ermöglicht die Vorabvereinbarung und Beschaffung von Cloud-Computing-Ressourcen, für die ein zukünftiger Bedarf gemäß einem SLA erwartet wird.
• Eine Arbeitsbelastungsschicht 90 bietet Beispiele für Funktionen, für die die Cloud-Computing-Umgebung genutzt werden kann. Beispiele für Arbeitsbelastungen bzw. Workloads und Funktionen, die von dieser Schicht aus bereitgestellt werden können, umfassen Mapping und Navigation 91, Ingress-Verarbeitung 92, Stream-Verarbeitung 93, Portal-Dashboard-Lieferung 94 - gleiche Nummer, Datenanalyse-Verarbeitung 95 und Egress und Datenlieferung 96.
• Obwohl diese Offenbarung Ausführungsformen auf einer Cloud-Computing-Plattform beschreibt, ist die Implementierung der hier beschriebenen Ausführungsformen nicht auf eine Cloud-Computing-Umgebung beschränkt.
• Ausführungsformen, die in Bezug auf die Systeme 10, 50, 100, 200, 400, 500, 600 und 700 beschrieben sind, die in Verbindung mit den 1-9 beschrieben sind, können von einem einzigen Netzwerkcomputer implementiert und/oder auf diesem ausgeführt werden. In anderen Ausführungsformen können diese Prozesse oder Teile dieser Prozesse von einer Vielzahl von Netzwerkcomputern implementiert und/oder auf diesen ausgeführt werden. Ebenso können in mindestens einer Ausführungsform die in Bezug auf die Systeme 10, 50, 100, 200, 400, 500 und 600 beschriebenen Prozesse oder Teile davon auf einer oder mehreren verschiedenen Kombinationen von Netzwerkcomputern, Client-Computern, virtuellen Maschinen oder ähnlichem betriebsmäßig eingesetzt werden. Ferner können in mindestens einer Ausführungsform die in Verbindung mit den 1 bis 9 beschriebenen Prozesse in Systemen mit Logikarchitekturen eingesetzt werden, wie sie auch in Verbindung mit den 1 bis 9 beschrieben sind.
• Es versteht sich, dass jeder Block der Flussdiagrammdarstellung und Kombinationen von Blöcken in der Flussdiagrammdarstellung durch Computerprogrammanweisungen implementiert werden können. Diese Programmanweisungen können einem Prozessor zur Verfügung gestellt werden, um eine Maschine zu erzeugen, so dass die Anweisungen, die auf dem Prozessor ausgeführt werden, Mittel zur Implementierung der in dem Flussdiagrammblock oder den Blöcken angegebenen Aktionen schaffen. Die Computerprogrammanweisungen können von einem Prozessor ausgeführt werden, um eine Reihe von Betriebsschritten zu veranlassen, die von dem Prozessor ausgeführt werden, um einen computerimplementierten Prozess zu erzeugen, so dass die Anweisungen, die auf dem Prozessor ausgeführt werden, Schritte zur Implementierung der in dem Flussdiagrammblock oder den Blöcken angegebenen Aktionen bereitstellen. Die Computerprogrammanweisungen können auch bewirken, dass zumindest einige der in den Blöcken des Flussdiagramms dargestellten Arbeitsschritte parallel ausgeführt werden. Darüber hinaus können einige der Schritte auch von mehr als einem Prozessor ausgeführt werden, wie es beispielsweise in einem Computersystem mit mehreren Prozessoren oder sogar in einer Gruppe von mehreren Computersystemen der Fall sein kann. Darüber hinaus können ein oder mehrere Blöcke oder Kombinationen von Blöcken im Flussdiagramm auch gleichzeitig mit anderen Blöcken oder Kombinationen von Blöcken oder sogar in einer anderen als der dargestellten Reihenfolge ausgeführt werden, ohne dass dadurch der Schutzbereich oder der Geist der Offenbarung verlassen wird.
• Dementsprechend unterstützen die Blöcke des Flussdiagramms Kombinationen zur Durchführung der angegebenen Aktionen, Kombinationen von Schritten zur Durchführung der angegebenen Aktionen und Programmbefehlsmittel zur Durchführung der angegebenen Aktionen, Es versteht sich auch, dass jeder Block des Flussdiagramms und Kombinationen von Blöcken im Flussdiagramm durch spezielle auf den Zweck bezogene hardwarebasierte Systeme implementiert werden können, die die angegebenen Aktionen oder Schritte ausführen, oder durch Kombinationen von spezieller auf den Zweck bezogener Hardware und Computerbefehlen. Das vorstehende Beispiel ist nicht als einschränkend und/oder erschöpfend zu verstehen, sondern vielmehr als ein anschaulicher Anwendungsfall, der eine Implementierung von mindestens einer der verschiedenen Ausführungsformen zeigt.

Claims (16)

1. System mit einem nicht-transitorischen Speicher, der Programmanweisungen enthält, und einem Prozessor, der so konfiguriert ist, dass er Anweisungen ausführt, um zumindest folgendes zu erreichen: Einlesen eines Ingress-Datenstroms von Fahrzeugereignisdaten, die Bewegungsdaten für eine Vielzahl von Fahrzeugen enthalten, über einen Ingress-Server; Zuweisen einer Vielzahl von Fahrzeugkennungen zu einer Vielzahl von jeweiligen Fahrzeugdatensätzen für die Vielzahl von Fahrzeugen der Fahrzeugereignisdaten; und Ausgeben eines gedrosselten Datenstroms der Fahrzeugdatensätze an eine Client-Vorrichtung über einen Egress-Server mit einem filterlosen Drosselalgorithmus, der so konfiguriert ist, dass er einen Teil der Fahrzeugdatensätze, die aus dem Ingress-Datenstrom identifiziert wurden, um an die Client-Vorrichtung ausgegeben zu werden, in eine Vielzahl von Bucket-Dateien sortiert, und die Fahrzeugdatensätze von dem Egress-Server löscht, die nicht in die Vielzahl von Bucket-Dateien sortiert sind.
2. System nach Anspruch 1, wobei das System ferner einen Datenspeicher umfasst, der zum Speichern von Fahrzeugereignisdaten konfiguriert ist, und wobei der filterlose Drosselungsalgorithmus konfiguriert ist, um zumindest folgendes zu erreichen: Erhalten einer Gesamtfahrzeugzahl, indem eine Gesamtzahl von Fahrzeugen der Fahrzeugereignisdaten bestimmt wird, die von dem System für eine vorbestimmte Zeitperiode gespeichert sind; Identifizieren einer Gesamtbucketzahl für die Gesamtzahl von Bucket-Dateien, um einen Teil der Fahrzeugdatensätze aus den Fahrzeugereignisdaten zu sortieren, die an die externe Client-Vorrichtung auszugeben sind; Berechnen einer Zahl von Fahrzeugen pro Bucket durch Dividieren der Gesamtfahrzeugzahl durch die Gesamtbucketzahl; Berechnen einer Fahrzeugzielzahl für die Anzahl von Fahrzeugdatensätze, die an die externe Client-Vorrichtung auszugeben sind; Berechnen einer erforderlichen Bucketzahl durch Dividieren der Fahrzeugzielzahl durch die Zahl von Fahrzeugen pro Bucket; Berechnen eines Fahrzeugkennungs-Hashwertes durch Hashen der Fahrzeugkennung auf eine positive Zahl; Berechnen einer Fahrzeugbucketzahl, indem ein Modulus des Fahrzeugkennungs-Hashwertes durch die Gesamtbucketzahl herangezogen wird; und wenn die Fahrzeugbucketzahl kleiner oder gleich der erforderlichen Bucketzahl ist, Aufnehmen des Fahrzeugdatensatzes für das identifizierte Fahrzeug in die Fahrzeugbucketdatei und Ausgeben des Fahrzeugdatensatzes über einen Egress-Server an die Client-Vorrichtung; oder wenn die Fahrzeugbucketzahl größer als die erforderliche Bucketzahl ist, Löschen des Fahrzeugdatensatzes von dem Egress-Server.
3. System nach Anspruch 2, wobei der filterlose Drosselungsalgorithmus ferner so konfiguriert ist, um zumindest folgendes zu erreichen: Berechnen eines Fahrzeugziels durch Berechnen eines minimalen Zusatzprozentsatzes von Fahrzeugen und Addieren des minimalen Zusatzprozentsatzes von Fahrzeugen zu der Gesamtfahrzeugzahl.
4. System nach Anspruch 3, wobei der filterlose Drosselungsalgorithmus ferner so konfiguriert ist, um zumindest folgendes zu erreichen: periodisches Neuberechnen des Fahrzeugbuckets bzw. der Fahrzeugbucketzahl, um eine Anpassung an schwankende Volumina von Fahrzeugen, die aus den Fahrzeug-Ereignisdaten identifiziert werden, zu vorzunehmen, wobei das Neuberechnen umfasst: Neuberechnen der Fahrzeuge pro Bucket; Neuberechnen des Fahrzeugziels; und Neuberechnen des Fahrzeugbuckets.
5. System nach Anspruch 3, wobei der filterlose Drosselungsalgorithmus ferner so konfiguriert ist, um zumindest folgendes zu erreichen: Vorberechnen des Fahrzeugbuckets für den Fahrzeugereignisdatensatz, wobei das Vorberechnen umfasst: Vorberechnen der Fahrzeuge pro Bucket; Vorberechnen des Fahrzeugziels; und Vorberechnen des Fahrzeugbuckets.
6. System nach Anspruch 2, wobei der filterlose Drosselungsalgorithmus so konfiguriert ist, dass er den Hash mit einem Partitionsalgorithmus berechnet.
7. System nach Anspruch 1, wobei der filterlose Drosselungsalgorithmus so konfiguriert ist, dass er den gedrosselten Datenstrom basierend auf den Anforderungen eines externen Client-Systems drosselt.
8. System nach Anspruch 1, wobei der Egress-Server so konfiguriert ist, dass er den gedrosselten Datenstrom für eine Stream-Zustellung, eine Batch-Zustellung oder beides drosselt.
9. Verfahren, das auf einem System ausgeführt werden soll, das einen nicht-transitorischen Speicher mit Programmanweisungen und einen Prozessor umfasst, der so konfiguriert ist, dass er Anweisungen für ein Verfahren ausführt, wobei das Verfahren Folgendes umfasst: Einlesen eines Ingress-Datenstroms von Fahrzeugereignisdaten, die Bewegungsdaten für eine Vielzahl von Fahrzeugen enthalten, über einen Ingress-Server; Zuweisen einer Vielzahl von Fahrzeugkennungen zu einer Vielzahl von jeweiligen Fahrzeugdatensätzen für die Vielzahl von Fahrzeugen der Fahrzeugereignisdaten; und Ausgeben eines gedrosselten Datenstroms der Fahrzeugdatensätze an eine Client-Vorrichtung über einen Egress-Server mit einem filterlosen Drosselalgorithmus, der so konfiguriert ist, dass er einen Teil der Fahrzeugdatensätze, die aus dem Ingress-Datenstrom identifiziert wurden, um an die Client-Vorrichtung ausgegeben zu werden, in eine Vielzahl von Bucket-Dateien sortiert, und die Fahrzeugdatensätze von dem Egress-Server löscht, die nicht in die Vielzahl von Bucket-Dateien sortiert sind.
10. Verfahren nach Anspruch 9, wobei das Verfahren ferner umfasst: Erhalten einer Gesamtfahrzeugzahl, indem eine Gesamtzahl von Fahrzeugen der Fahrzeugereignisdaten bestimmt wird, die von dem System für eine vorbestimmte Zeitperiode gespeichert sind; Identifizieren einer Gesamtbucketzahl für die Gesamtzahl von Bucket-Dateien, um einen Teil der Fahrzeugdatensätze aus den Fahrzeugereignisdaten zu sortieren, die an die externe Client-Vorrichtung auszugeben sind; Berechnen einer Zahl von Fahrzeugen pro Bucket durch Dividieren der Gesamtfahrzeugzahl durch die Gesamtbucketzahl; Berechnen einer Fahrzeugzielzahl für die Anzahl von Fahrzeugdatensätze, die an die externe Client-Vorrichtung auszugeben sind; Berechnen einer erforderlichen Bucketzahl durch Dividieren der Fahrzeugzielzahl durch die Zahl von Fahrzeugen pro Bucket; Berechnen eines Fahrzeugkennungs-Hashwertes durch Hashen der Fahrzeugkennung auf eine positive Zahl; Berechnen einer Fahrzeugbucketzahl, indem ein Modulus des Fahrzeugkennungs-Hashwertes durch die Gesamtbucketzahl herangezogen wird; und wenn die Fahrzeugbucketzahl kleiner oder gleich der erforderlichen Bucketzahl ist, Aufnehmen des Fahrzeugdatensatzes für das identifizierte Fahrzeug in die Fahrzeugbucketdatei und Ausgeben des Fahrzeugdatensatzes über einen Egress-Server an die Client-Vorrichtung; oder wenn die Fahrzeugbucketzahl größer als die erforderliche Bucketzahl ist, Löschen des Fahrzeugdatensatzes von dem Egress-Server.
11. Verfahren nach Anspruch 10, wobei das Verfahren ferner umfasst: Konfigurieren eines minimalen Zusatzprozentsatzes von identifizierten Fahrzeugen zum Hinzuaddieren zu den Gesamtfahrzeugen; und Berechnen des Fahrzeugziels durch Berechnen und Addieren eines minimalen Zusatzprozentsatzes von Fahrzeugen zu den Gesamtfahrzeugen.
12. Verfahren nach Anspruch 11, wobei das Verfahren ferner umfasst: periodisches Neuberechnen des Fahrzeugbuckets bzw. der Fahrzeugbucketzahl, um eine Anpassung an schwankende Volumina von Fahrzeugen, die aus den Fahrzeug-Ereignisdaten identifiziert werden, zu vorzunehmen, wobei das Neuberechnen umfasst: Neuberechnen der Fahrzeuge pro Bucket; Neuberechnen des Fahrzeugziels; und Neuberechnen des Fahrzeugbuckets.
13. Verfahren nach Anspruch 11, wobei das Verfahren ferner umfasst: Vorberechnen des Fahrzeugbuckets für den Fahrzeugereignisdatensatz, wobei das Vorberechnen umfasst: Vorberechnen der Fahrzeuge pro Bucket; Vorberechnen des Fahrzeugziels; und Vorberechnen des Fahrzeugbuckets.
14. Verfahren nach Anspruch 10, wobei das Verfahren ferner das Berechnen des Hashwertes mit einem Partitionsalgorithmus umfasst.
15. Verfahren nach Anspruch 9, wobei das Verfahren ferner umfasst: Drosseln des gedrosselten Datenstroms auf der Grundlage der Anforderungen eines externen Client-Systems.
16. Verfahren nach Anspruch 9, wobei das Verfahren ferner Folgendes umfasst: Drosseln des gedrosselten Datenstroms für eine Stream-Zustellung, die Batch-Zustellung oder beides.

Images