-
TECHNISCHES GEBIET
-
Die vorliegende Offenbarung betrifft das Aggregieren fahrzeugbezogener BIG DATA.
-
HINTERGRUND
-
Big Data betrifft Datensätze, die so groß oder komplex sind, dass traditionelle Techniken der Datenverarbeitung inadäquat sind – z. B. Verarbeitung von Exabyte von Daten und mehr. Fahrzeuge mit Telematik-Vorrichtungen besitzen die Fähigkeit, Zustandsberichte des Fahrzeugs an ein Fahrzeug Call-Center zu senden, das diese Daten analysieren kann. Da sich jedoch die Anzahl der mit Telematik-Vorrichtungen ausgestatteten Fahrzeuge in den letzten Jahren erhöht hat, ist auch das Volumen der Fahrzeug-Statusberichte gestiegen – z. B. nähert sich das Volumen an oder kann bereits als 'Big Data' klassifiziert werden. Um die große Menge der empfangenen Fahrzeug-Zustandsberichte zu verwenden, besteht somit ein Bedarf für einen Mechanismus zum Aggregieren dieser Daten.
-
ZUSAMMENFASSUNG
-
Gemäß einer Ausführungsform der Erfindung, wird ein Verfahren zum Aggregieren von Fahrzeugdaten über ein privates Computernetzwerk bereitgestellt, das mit einer Fahrzeugdaten-Servicestelle verbunden ist. Das Verfahren umfasst die Schritte: Empfang von einer oder mehreren Upload-Nachrichten von einem ersten Teilnehmer-Fahrzeug durch einen Load-Balancing-Computer (LBC), worin jede der einen oder mehreren Upload-Nachrichten unverschlüsselte Daten umfasst; basierend auf den unverschlüsselten Daten die Auswahl mindestens eines Telematik-Servers einer Telematik-Serverfarm am LBC zum Senden der einen oder mehreren Upload-Nachrichten; und Bereitstellen der einen oder mehreren Upload-Nachrichten an mindestens einen Telematik-Server zum Aggregieren der Upload-Nachrichten, worin der LBC und die Telematik-Serverfarm mit dem privaten Computernetzwerk verbunden sind.
-
Gemäß einer weiteren Ausführungsform der Erfindung wird ein Verfahren zum Aggregieren von Fahrzeugdaten über ein privates Computernetzwerk bereitgestellt, das mit einer Fahrzeugdaten-Servicestelle verbunden ist. Das Verfahren umfasst die Schritte: Empfang einer Vielzahl von Upload-Nachrichten bei einem Load-Balancing-Computer (LBC), worin die Vielzahl der Upload-Nachrichten von einer Vielzahl teilnehmender Fahrzeuge empfangen wird, worin jede Upload-Nachricht in dieser Vielzahl einen Header enthält, worin mindestens einige Teile des Headers einen unverschlüsselten Abschnitt enthalten; Analyse der unverschlüsselten Abschnitte der Vielzahl von Upload-Nachrichten am LBC nach Affinitäts-Daten und basierend auf den Affinitäts-Daten: die Auswahl mindestens eines Telematik-Servers aus einer Telematik-Serverfarm am LBC und Bereitstellen eines Teils aus der Vielzahl der Upload-Nachrichten an den mindestens einen Telematik-Server zum Aggregieren der Upload-Nachrichten.
-
Gemäß einer weiteren Ausführungsform der Erfindung wird ein privates Computernetzwerk bereitgestellt, das mit einer Fahrzeugdaten-Servicestelle für das Aggregieren von Fahrzeugdaten verbunden ist. Das private Computernetzwerk umfasst: einen Load-Balancing-Computer (LBC) mit Speicher und einem oder mehreren Prozessoren, worin der Speicher ausführbare Anweisungen für den einen oder die mehreren Prozessoren speichert; und eine Telematik-Serverfarm, bestehend aus einer Vielzahl von Telematik-Servern einschließlich eines ersten Telematik-Servers, worin der LBC und die Telematik-Serverfarm kommunikativ gekoppelt sind und worin die Anweisungen enthalten: Verarbeitung einer Vielzahl von Upload-Nachrichten, die von einer Vielzahl von Teilnehmer-Fahrzeugen empfangen werden; bei Empfang einer ersten Upload-Nachricht aus einer Vielzahl von Upload-Nachrichten die Analyse der ersten Upload-Nachricht nach unverschlüsselten Daten; anhand der Inhalte der unverschlüsselten Daten die Bestimmung des Sendens der ersten Upload-Nachricht an den ersten Telematik-Server aus der Vielzahl der Telematik-Server; und vor dem Senden der ersten Upload-Nachricht an den ersten Telematik-Server die Bestimmung, ob der erste Telematik-Server eine Verarbeitungsverzögerung aufweist, und falls der erste Telematik-Server eine Verarbeitungsverzögerung aufweist, die Bestimmung eines anderen Telematik-Servers zum Senden der ersten Upload-Nachricht sowie das Senden der ersten Upload-Nachricht an den anderen Telematik-Server, und falls bestimmt wird, dass der erste Telematik-Server keine Verarbeitungsverzögerung aufweist, das Senden der ersten Upload-Nachricht an den ersten Telematik-Server.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:
-
1 ein Blockdiagramm ist, das eine Ausführungsform einer Daten-Servicestelle in Kommunikation mit einer Vielzahl von Fahrzeugen zeigt und die Daten-Servicestelle so konfiguriert ist, um das hierin offenbarte Verfahren auszuführen;
-
2 ein schematisches Diagramm eines Load-Balancing-Computers der in 1 gezeigten Daten-Servicestelle ist;
-
3 ein schematisches Diagramm eines Telematik-Servers der in 1 gezeigten Daten-Servicestelle ist;
-
4 ein Blockdiagramm zur Darstellung exemplarischer Komponenten einer Upload-Nachricht ist;
-
5 ein Blockdiagramm zur Darstellung eines Fahrzeugdaten-Uploads (VDU) ist, bestehend aus einer oder mehreren Upload-Nachrichten;
-
6 ein Blockdiagramm zur Darstellung einer Datenzusammenstellung ist, die aus einem oder mehreren VDUs besteht; und
-
7A–7B ein Ablaufdiagramm eines Verfahrens zum Aggregieren von Fahrzeugdaten ist, die über Upload-Nachrichten von einer Vielzahl von Teilnehmer-Fahrzeugen empfangen werden.
-
DETAILLIERTE BESCHREIBUNG DER VERANSCHAULICHTEN AUSFÜHRUNGSFORM(EN)
-
Das System und nachfolgend beschriebene Verfahren betrifft das Aggregieren, Zusammenstellen und/oder Ausnutzen großer Mengen von Fahrzeugen empfangener Daten, die mit einem gemeinsamen Backend-System verbunden sind. Moderne Fahrzeuge können so konfiguriert werden, dass sie verschiedene Arten von Fahrzeuginformationen an das Backend-System liefern, welches die Informationen für verschiedene Zwecke verwenden kann (z. B. zur Bereitstellung von Navigations-Informationen, Telefonie-Informationen, Informationen für Notfallunterstützung, Diagnose-Informationen, Infotainment-Informationen usw.). Beispielsweise kann das Backend-System Diagnosedaten in Form eines Fahrzeugdaten-Uploads (VDU) von einem mit Telematik ausgestatteten Fahrzeug empfangen. Der VDU kann den Gesundheitszustand des Fahrzeugs oder die Notwendigkeit einer Fahrzeugwartung anzeigen. Nach Empfang im Backend-System kann das Backend-System bestimmen, ob dem Bediener des Fahrzeugs eine Warnung oder Benachrichtigung gesendet wird (z. B. dass der Fahrzeugmotor überprüft werden sollte). Die Diagnosedaten sind lediglich eine Art von VDU-Informationen; Daten in anderen VDUs könnten zu anderen Fahrzeugsystemen oder Subsystemen gehören, wie nachfolgend erläutert wird. Da die Anzahl der mit Telematik ausgestatteten Fahrzeuge in den letzten Jahren gestiegen ist, hat auch die Menge der an die Backend-Systeme gesendeten VDU-Informationen zugenommen. Traditionelle Techniken der Datenverarbeitung sind im Allgemeinen zur Verarbeitung dieser großen Menge von Informationen bzw. Big Data ungeeignet, wie der Begriff dafür bei Fachleuten gebräuchlich ist. Das System und nachfolgend beschriebene Verfahren enthält einen Load-Balancing-Computer und eine Telematik-Serverfarm zum Empfangen und Aggregieren großer Mengen von Fahrzeugdaten von den mit Telematik ausgestatteten Fahrzeugen, die mit einem gemeinsamen Backend-System (oder einer Fahrzeugdaten-Servicestelle) verbunden sind, sodass diese Fahrzeugdaten analysiert und zur Verbesserung von Diensten für die mit Telematik ausgestatteten Fahrzeuge genutzt werden können.
-
Unter Bezugnahme auf 1 ist eine Betriebsumgebung gezeigt, bestehend aus mehreren Fahrzeugen 10, die eine Fernkommunikation mit einer Daten-Servicestelle 12 führen können, einem oder mehreren Drahtlosträgersystemen 14, einem Festnetz 16 und der Daten-Servicestelle 12 (z. B. ein gemeinsames Backend-System, an das alle Fahrzeuge 10 VDU-Information senden). Die Daten-Servicestelle 12 enthält ein privates Computernetzwerk 20 – d. h. eine Reihe von Computern, auf die die Fahrzeuge 10 über einen oder mehrere Gateway-Computer wie den Load-Balancing-Computer 22 privat zugreifen können. Das Netzwerk 20 enthält weiter: eine Telematik-Serverfarm 24, Computer 26 zum Aggregieren der Daten, Datenanalysecomputer 28 und Datenbank(en) 30. (Nur ein Load-Balancing-Computer 22, ein Aggregations-Computer 26, ein Datenanalysecomputer 28 und eine Datenbank 30 sind in 1 gezeigt und nachstehend beschrieben; es versteht sich jedoch, dass jedes davon abhängig von der jeweiligen Implementierung eine einzelne Vorrichtung oder mehrere Vorrichtungen repräsentieren kann. Auch versteht es sich, dass die Architektur des Systems nicht speziell auf die hier gezeigte Betriebsumgebung beschränkt ist, und dass das/die hierin offenbarte(n) Verfahren mit Daten-Servicestellen mit unterschiedlichen Computern oder anderen Anordnungen der Computersysteme verwendet werden kann/können.
-
Es versteht sich weiterhin, dass 1 eine Reihe von Abstraktionsschichten im Zusammenhang mit Telekommunikation und Computersystem-Funktionen veranschaulicht. Beispielsweise können das Drahtlosträgersystem 14 und das Festnetz 16 als physikalische Schicht (z. B. wie in der Open Systems Interconnection oder dem OSI-Modell) angesehen werden. Gemeinsam können der Load-Balancing-Computer 22, die Telematik-Serverfarm 24 und der Computer für Datenaggregation 26 als Unterschichten einer Darstellungsschicht angesehen werden (siehe OSI-Modell). Wie unten erläutert wird, kann jede dieser Vorrichtungen 22, 24, 26 Fahrzeugdaten für den Datenanalyse-Computer 28 analysieren und zusammenführen. Und der Datenanalyse-Computer 28 und die Datenbank 30 können als eine Anwendungsschicht betrachtet werden (siehe OSI-Modell). Diese mehrschichtige Darstellung soll zeigen – zumindest teilweise – dass die Ansammlung von Fahrzeugdaten näher an der physikalischen Schicht erfolgt. Wie noch im Hinblick auf Big Data erläutert werden wird, entspricht dies einer größeren Systemleistung und -effizienz.
-
Die Fahrzeuge 10 sind in der veranschaulichten Ausführungsform als PKW dargestellt, aber es sollte klar sein, dass jedes andere Fahrzeug einschließlich Motorräder, LKWs, Sport Utility Vehicles (SUV), Campingfahrzeuge (RVs), Schiffe, Flugzeuge usw., ebenfalls verwendet werden können. Zusätzlich enthält jedes Fahrzeug 10 eine Telematik-Vorrichtung oder ein fahrzeugeigenes Kommunikationssystem (nicht gezeigt), das alle geeigneten Komponenten umfassen kann, um Upload-Dateien mit Fahrzeugdaten (oder schlicht VDUs) 32 für die Daten-Servicestelle 12 bereitzustellen. Wie noch erläutert werden wird, können die VDUs 32 in einzelne Komponenten oder Upload-Nachrichten 34 aufgeteilt werden. Jedes fahrzeugeigene Kommunikationssystem kann einen oder mehrere Mobilfunk-Sender-Empfänger, einen Transceiver für Kurzbereichs-Drahtloskommunikation (SRWC), eine verdrahtete Anschluss-Schnittstelle oder Ähnliches haben – jeder der Mobilfunk-Sender-Empfänger oder die Anschluss-Schnittstellen können zur Übertragung von VDUs zur Daten-Servicestelle 12 über das Drahtlosträgersystem 14, das Festnetz 16 oder beide verwendet werden. Der Mobilfunk-Sender-Empfänger in Fahrzeugen 10 kann eine Kommunikation gemäß einem oder mehrerer Protokolle führen (z. B. LTE, EVDO, CDMA, GPRS, EDGE und dergleichen). Der SRWC Sender-Empfänger kann eines oder mehrere SRWC-Protokolle nutzen (z. B. alle IEEE 802.11-Protokolle, WiMAX, ZigBeeTM, Wi-Fi Direct, Bluetooth, Nahfeld-Kommunikation und dergleichen). Und die Schnittstelle jeder physikalischen Verbindung kann die Fahrzeug-Kommunikation über eine USB-Schnittstelle, einen Ethernet-Anschluss, einen OBDII-Anschluss und dergleichen ermöglichen. Zusätzlich zur Verwendung hierin kann der Begriff fahrzeugeigenes Kommunikationssystem auch Kommunikationssysteme einbeziehen, welche mit dem Mobilgerät des Fahrzeug-Bedieners interagieren oder dieses nutzen (z. B. Mobiltelefon, Smartphone, Tablet usw.), um ebenfalls Fahrzeugdaten zur Servicestelle 12 zu übertragen. Solche fahrzeugeigenen Kommunikationssysteme – sowie deren Implementierung für jede geeignete Fahrzeug-zu-Fahrzeug (V2V) oder Fahrzeug-zu-Infrastruktur (V2I) Kommunikation – sind in der Technik bekannt.
-
Es sollte beachtet werden, dass die fahrzeugeigenen Kommunikationssystem jedes Fahrzeugs 10 ebenfalls eine vielfältige Palette von anderen Fahrzeug-Diensten anbieten können; d. h. sie können nicht nur konfiguriert sein, um mit der Daten-Servicestelle 12 zu kommunizieren, sondern sie können auch (mindestens teilweise) dazu verwendet werden, andere Dienste auszuführen oder anzubieten wie: Anweisungen der Routenführung und andere navigationsbezogene Dienste, Meldung über Airbagentfaltung und andere Notfall- oder Pannendienste, die im Zusammenhang mit einem oder mehreren Kollisionssensor-Schnittstellenmodulen wie einem Chassis-Steuermodul (nicht dargestellt) bereitgestellt werden, Diagnoseberichte unter Verwendung eines oder mehrerer Diagnosemodule (nicht dargestellt), infotainment-bezogener Dienste, bei denen Musik, Webseiten, Filme, Fernsehprogramme, Videospiele und/oder andere Informationen durch ein Infotainmentmodul (nicht dargestellt) heruntergeladen oder übertragen werden, Echtzeitanalysedienste (z. B. bezüglich des Fahrzeuge-Gesundheitszustands oder -diagnose, Fahrverhalten usw.) und dergleichen. Weiter können die fahrzeugeigenen Kommunikationssysteme jedes Fahrzeugs 10 aus geeigneter Hardware, Software oder einer Kombination davon bestehen, um mindestens einen Teil der hierin beschriebenen Verfahren auszuführen. Beispielsweise kann das fahrzeugeigene Kommunikationssystem von Teilnehmer-Fahrzeugen 10 in Software, Hardware, usw. so konfiguriert sein, um Push-Benachrichtigungen oder Meldungen zur Daten-Servicestelle 12 zu übertragen. Wie hierin verwendet, ist eine Push-Nachricht oder Push-Meldung eine Upload-Nachricht 34, die von einem Teilnehmer-Fahrzeug 10 ohne bestimmte Anforderung zur Daten-Servicestelle 12 (genauer gesagt, ohne Aufforderung von dem LBC 22) übertragen wird. Weiterhin kann der Inhalt der von jedem Fahrzeug 10 übertragenen Upload-Nachrichten 34 mit einem der Fahrzeugdienste verknüpft werden, die durch das fahrzeugeigene Kommunikationssystem ausführbar sind.
-
In mindestens einer Ausführungsform sind alle Fahrzeuge 10 Teilnehmer-Fahrzeuge. Wie hierin verwendet, ist ein Teilnehmer-Fahrzeug ein Fahrzeug, das mindestens zeitweilig eine gewisse Art von Zustandsdaten an die Daten-Servicestelle 12 übermittelt. Die Zustandsdaten umfassen das Bereitstellen eines VDU – z. B. mit einem geeigneten Inhalt oder Thema. Ein Teilnehmer-Fahrzeug kann Fahrzeuge umfassen, in denen ein Benutzer des Fahrzeugs eine Teilnahmevereinbarung mit einem Service-Provider hat, der mit der Daten-Servicestelle 12 verknüpft ist; das ist jedoch nicht obligatorisch. In einigen Implementierungen hat ein Benutzer des Fahrzeugs 10 dem Senden oder Verteilen von Fahrzeugdaten zur Daten-Servicestelle 12 zugestimmt oder das bestätigt (z. B. zum Zeitpunkt des Kaufs, Leasings usw. des Fahrzeugs oder gemäß einer späteren Vereinbarung – in einigen Fällen kann der Benutzer das machen, um einen indirekten Vorteil von der Leistungsfähigkeit der Daten-Servicestelle zu erhalten); das ist jedoch wiederum nicht obligatorisch. In mindestens einer Ausführungsform haben die Teilnehmer-Fahrzeuge 10 einen gemeinsamen Hersteller oder eine gemeinsame Herstellervereinigung (z. B. die Marke, geschäftliche Division oder andere geschäftliche Einheit, usw.). In mindestens einer Ausführungsform stellen die Teilnehmer-Fahrzeuge der Daten-Servicestelle 12 Informationen zur Verfügung, die zusammengestellt und genutzt werden, um die allgemeine Kundenzufriedenheit zu verbessern, was in dem Verfahren nachstehend beschrieben wird.
-
Wie oben erwähnt, können die Fahrzeuge 10 Upload-Dateien (VDUs) 32 mit Fahrzeugdaten zur Daten-Servicestelle 12 übertragen. Diese VDUs 32 können als Paketdaten (z. B. TCP, UDP oder ähnliches), als Kurznachricht (SMS) oder dergleichen übertragen werden – und können über Mobilfunk-Übertragung, über SRWC (z. B. über Infrastrukturen), über drahtlose oder drahtgebundene Kommunikation an eine Servicestelle oder für Fahrzeugwartung oder in irgendeiner anderen geeigneten Weise übertragen werden. Zusätzlich können diese VDUs 32 stückweise als eines oder mehrere Fragmente oder als Upload-Nachrichten 34 übertragen werden; z. B. kann das Senden mehrerer Upload-Nachrichten 34 wünschenswert sein, wenn die Datenmenge in einem einzigen VDU 32 eine wünschenswerte Übertragungsgröße übersteigt (z. B. eine geeignete Paketgröße oder SMS-Größe). Jede Upload-Nachricht 34 kann ein Fragment oder einen Teil der VDU-Daten im Hauptteil der Upload-Nachricht 34 enthalten. Somit kann das Fahrzeug 10 (oder das fahrzeugeigene Kommunikationssystem darin) in diesen Fällen den VDU 32 in Stücke aufteilen und die Gesamtheit des VDU 32 als mehrere Upload-Nachrichten 34 versenden und – die Daten-Servicestelle 12 kann den VDU 32 unter Verwendung der mehreren Nachrichten rekonstruieren. Dies wird nachstehend näher beschrieben werden. Es versteht sich jedoch, dass, obwohl die Aufteilung der VDUs 32 in Stücke die Möglichkeiten (oder Fähigkeiten) zur Übertragung im Fahrzeug 10 oder über das Drahtlosträgersystem 14 oder Festnetz 16 verbessert, dies eine größere Komplexität an der Daten-Servicestelle 12 bewirkt, wo diese Bestandteile wieder zusammengefügt werden müssen (z. B. aggregiert, zusammengestellt, organisiert, usw.).
-
Mindestens einige der Fahrzeuge 10 können für eine private Kommunikation mit dem privaten Computernetzwerk 20 der Daten-Servicestelle 12 konfiguriert sein. Beispielsweise kann die Kommunikationsverbindung zwischen dem/den Fahrzeug(en) 10 und der Daten-Servicestelle 12 über eine dedizierte Verbindung erfolgen (z. B. mit einem privaten Zugangspunkt oder APN) – der nur den Fahrzeugen 10 bekannt ist. Desgleichen kann jedes Fahrzeug 10 eine eindeutige Kennung (z. B. einen APN) haben, die nur der Daten-Servicestelle 12 bekannt ist. In diesen Beispielen können die Fahrzeuge 10 einen anderen APN für alle anderen Fahrzeugverbindungen haben (z. B. einen öffentlichen APN). Die von jedem Fahrzeug 10 durchgeführte Kommunikation über die private Kommunikationsverbindung kann mindestens einige Verschlüsselungstechniken verwenden; z. B. mindestens ein Teil der Verbindungen kann unter Verwendung eines kryptographischen Schlüssels signiert werden (z. B. ein gemeinsamer oder privater Schlüssel, der für Verbindungen zwischen der Daten-Servicestelle 12 und dem betreffenden Fahrzeug 10 zugeordnet ist). Wie später näher erläutert werden wird, darf jedoch in mindestens einer Ausführungsform ein Teil der zwischen dem/den Fahrzeug(en) 10 und der Daten-Servicestelle 12 gesendeten Upload-Nachrichten 34 nicht verschlüsselt werden. Bei einigen dieser Fälle kann der Rest der Upload-Nachricht(en) 34 mit einem privaten Schlüssel, öffentlichen Schlüssel oder dergleichen verschlüsselt werden.
-
Das Drahtlosträgersystem 14 ist bevorzugt ein Mobiltelefon-System. Beispielsweise in GSM-Systemen kann das Drahtlosträgersystem 14 Mobilfunkmasten, Basisstations-Subsysteme, Mobilfunk-Schaltsysteme usw. umfassen. Oder beispielsweise in LTE-Systemen kann das Drahtlosträgersystem Mobilfunkmasten, entwickelte Knoten Bs (eNBs), Server-Gateways (SGWs), öffentliche Datennetzwerke oder PDN-Gateways (PGWs) usw. umfassen. Fachlich versierte Techniker werden verstehen, dass GSM-Systeme und LTE-Systeme andere Elemente, Subsysteme oder Teile enthalten und dass die aufgezählten Elemente lediglich Beispiele sind. Weiterhin sind GSM- und LTE-Systeme lediglich Beispiele für Drahtlosträgersysteme 14 und nicht als begrenzend zu verstehen; andere Drahtlosträgersysteme sind ebenfalls in Betracht gezogen.
-
Das Festnetz 16 kann ein konventionelles landgebundenes Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das Drahtlosträgersystem 14 mit der Daten-Servicestelle 12 verbindet. So kann beispielsweise das Festnetz 16 ein Fernsprechnetz (PSTN) wie dasjenige sein, das verwendet wird, um festverdrahtetes Fernsprechen, paketvermittelte Datenkommunikationen und die Internetinfrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 16 könnten durch Verwenden eines normalen drahtgebundenen Netzwerks, eines Lichtleiter- oder eines anderen optischen Netzwerks, eines Kabelnetzes, von Stromleitungen, anderen drahtlosen Netzwerken wie drahtlose lokale Netzwerke (WLANs) oder Netzwerke, die drahtlosen Breitbandzugang (BWA) bereitstellen oder jeder Kombination davon implementiert sein. Des Weiteren muss die Daten-Servicestelle 12 nicht über das Festnetz 16 verbunden sein, sondern könnte Funktelefonieausrüstung enthalten, sodass sie direkt mit einem drahtlosen Netzwerk wie dem Drahtlosträgersystem 14 kommunizieren könnte. In jedoch mindestens einer Implementierung (wie in 1 gezeigt), ist die Daten-Servicestelle 12 mit dem Festnetz 16 verbunden.
-
Im Allgemeinen ist die Daten-Servicestelle 12 so konzipiert, um den Fahrzeugen 10 eine Reihe unterschiedlicher System-Back-End-Funktionen bereitzustellen. Beispielsweise kann die Daten-Servicestelle 12 einen Kundendienst oder ein Call-Center umfassen, dass ein automatisiertes Sprach-Reaktionssystem, eine Gruppe von Live-Beratern oder beides umfasst. Wie nachstehend beschrieben wird, kann die Daten-Servicestelle 12 übertragene Daten zu/von Fahrzeugen 10 empfangen, senden, speichern, zusammenführen, analysieren usw. Die Daten können die Form von Fahrzeug-Daten-Uploads (VDU) 32 oder jede andere geeignete Form haben. Nichtbeschränkende Beispiele vom Inhalt dieser Daten enthalten Authentifizierungsinformationen der Teilnehmer, Fahrzeug-Kennungen, Profilaufzeichnungen, Verhaltensmuster, Daten zu Fahrzeugdiagnose (oder Gesundheitszustand), Fahrzeug-Nutzungsdaten (Fahrverhalten oder andere ähnliche Dinge), Infotainment- und Entertainment-Daten, Navigations- und/oder Verkehrsdaten, Daten für Notfallhilfe und andere sachbezogene Teilnehmerinformationen.
-
Der Load-Balancing-Computer (LBC) 22 der Daten-Servicestelle 12 ist in 2 auch gezeigt. In der dargestellten Ausführungsform umfasst der LBC 22 einen Prozessor 40, mehrere Speichervorrichtungen 42 und mehrere Puffer 44. Der Prozessor 40 kann Eingabe-Daten 34 über das Festnetz 16 (oder in einigen Fällen direkt vom Drahtlosträgersystem 14) empfangen. Weiterhin ist der Prozessor 40 sowohl mit der/den Speichervorrichtung(en) 42 und Puffer(n) 44 verbunden. Der Prozessor 40 kann jede Geräteart sein, die elektronische Befehle verarbeiten kann, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Der Prozessor 40 kann zur Ausführung verschiedener Arten von digital gespeicherten Anweisungen 46 wie Software oder Firmware-Programme, die in Speichervorrichtungen 42 gespeichert sind, konfiguriert sein, welche dem LBC 22 ermöglichen, eine Reihe von Load-Balancing-Diensten bereitzustellen. Zum Beispiel kann der Prozessor 40 Programme ausführen oder Daten verarbeiten, um mindestens einen Teil des Verfahrens auszuführen, das hierin beschrieben ist.
-
In einem nicht beschränkendem Beispiel kann der Prozessor 40 eine Multi-CPU-Zentrale mit vier oder mehr angeordneten separaten CPUs 48 sein, um den parallelen Betrieb zu ermöglichen und die Systemsteuerung zu verbessern. Bei mehreren CPUs 48 können jeder Einheit 48 eine oder mehrere Aufgaben oder Routinen zugeordnet sein, die mit Sortieren und/oder Aggregieren von Daten verbunden sind (z. B. Sortieren und/oder Aggregieren der Upload-Nachrichten 34). In einigen Implementierungen können einer oder mehreren CPUs 48 Aufgaben zugeordnet sein, die mit dem Sortieren von Upload-Nachrichten 34 nach Inhalt der Nachricht verbunden sind, während einer oder mehreren anderen CPUs 48 Aufgaben zugeordnet sein können, die mit dem Sortieren von Upload-Nachrichten 34 nach einer Identifikation des Senders oder der Quelle der Nachricht verbunden sind. Dies wird nachstehend ausführlicher erklärt werden. Weiterhin sollte klar sein, dass der dargestellte Prozessor 40 lediglich Beispiel ist. In anderen Ausführungsformen kann der LBC 22 mehrere Prozessoren 40 umfassen und in mindestens einer bevorzugten Ausführungsform ist das so. In solchen Implementierungen kann ein Prozessor 40 einer Aufgabe des Aggregierens zugeordnet sein (z. B. Sortieren der Nachrichten 34 von einer Gruppe von Fahrzeugen 10), während ein anderer Prozessor 40 einer anderen Aufgabe des Aggregierens zugeordnet sein kann (z. B. Sortieren der Nachrichten 34 von einer anderen Gruppe von Fahrzeugen 10). Das sind lediglich Beispiele, und andere Ausführungsformen sind möglich.
-
Die Speichervorrichtungen 42 können jedes geeignete nicht transitorische computerlesbare oder vom Computer nutzbare Medium enthalten, das eine oder mehrere Speichervorrichtungen, Speicherartikel oder Datenbanken enthalten kann. Exemplarische nicht-transitorische computernutzbare Speichervorrichtungen beinhalten ein herkömmliches Computersystem-RAM (random access memory), ROM (read only memory), EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM) und magnetische oder optische Platten oder Bänder. Das dargestellte Ausführungsbeispiel zeigt eine einzelnen Speichervorrichtung 42 zum Speichern von Anweisungen 46 und drei andere Speichervorrichtungen 42; dies ist jedoch nur ein Beispiel. Die Anzahl und Anordnung von Speichervorrichtungen 42 kann variieren; ferner können digitale Anweisungen ebenso auf mehr als einer Vorrichtung 42 gespeichert sein.
-
Puffer oder Warteschlangen 44 können jede temporäre Speichervorrichtung sein (z. B. flüchtiger Speicher wie RAM-Speicher) und als Halteort für Upload-Nachrichten 34 dienen, bis der Prozessor 40 die Nachrichten 34 zu einem anderen Abschnitt des privaten Computernetzwerks 20 senden kann (z. B. die Telematik-Serverfarm 24). Wie nachfolgend näher erläutert werden wird, können in mindestens einer Implementierung die Upload-Nachrichten 34 in einem oder mehreren Puffern 44 gehalten werden, bis der LBC 22 einen Status eines Servers in der Telematik-Serverfarm 24 bestimmt oder bis der Server zum Empfang der Nachricht 34 bereit ist. Puffer 44 können als ein fester Speicherplatz in der Hardware oder durch Verwendung eines virtuellen Datenpuffers in der Software, der auf eine Stelle im physikalischen Speicher verweist, implementiert werden. Im Allgemeinen sind Hardware, Software oder Kombinationen derselben zur Implementierung von Puffern 44 den Fachleuten bekannt und werden hier nicht weiter ausgearbeitet.
-
Wie in dem Verfahren nachstehend erläutert werden wird, können die in den Speichervorrichtung(en) 42 gespeicherten und durch den Prozessor 40 ausführbaren digitalen Anweisungen 46 so konfiguriert sein, um die von einem oder mehreren Fahrzeugen 10 empfangenen Upload-Nachrichten 34 zu sortieren. In mindestens einer Ausführungsform lesen die Befehle 46 einen unverschlüsselten Abschnitt aus dem Header einer Upload-Nachricht und basierend auf den unverschlüsselten Daten im Header bestimmt der Prozessor 40 (gemäß Anweisungen 46), an welchen Server in der Serverfarm 24 die Upload-Nachricht 34 gesendet wird. Dieses Verfahren kann für mehrere Upload-Nachrichten 34 wiederholt werden – und in vielen Fällen gleichzeitig durchgeführt werden. Bei einigen Ausführungsformen enthalten die unverschlüsselten Daten im Header eine Fahrzeug-Kennung (z. B. eine Telematik-Seriennummer, Fahrgestellnummer (VIN) oder dergleichen), die der Prozessor 40 (gemäß Anweisungen 46) verwenden kann, um die Quelle der Upload-Nachricht 34 zu bestimmen. Und in anderen Ausführungsformen enthalten unverschlüsselte Daten im Header Trigger-Kennung(n) für eine Anwendung, die der Prozessor 40 (gemäß Anweisungen 46) verwenden kann, um die Inhalte der Upload-Nachricht 34 zu erkennen – d. h. welches Fahrzeug-Teilsystem bzw. welche Anwendung den VDU 32 ausgelöst hat (z. B. welches System oder Teilsystem die Signalfolge oder Serie von Upload-Nachrichten 34 ausgelöst hat). In jedem Fall können diese unverschlüsselten Daten bei der Auswahl oder Bestimmung verwendet werden, an welchen Server (in der Serverfarm 24) die Upload-Nachricht 34 zu senden ist. Selbstverständlich sind das lediglich Beispiele und andere geeignete Sortieranweisungen können ebenso verwendet werden. Diese Beispiele sind nachstehend weiter erläutert.
-
Die Telematik-Serverfarm 24 in 1 umfasst eine Vielzahl von Servern 50. Jeder Telematik-Server 50 kann ähnliche Hardware haben; daher wird hierin nur einer beschrieben (siehe 3). Jeder Server 50 kann einen oder mehrere Prozessoren 52 und eine oder mehrere Speichervorrichtungen 54 umfassen. Jeder Prozessor 52 kann ähnlich zum oben beschriebenen Prozessor 40 angeordnet sein. Beispielsweise kann/können Prozessor(en) 52 jede Art von Vorrichtung sein, die elektronische Befehle verarbeiten kann, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Jedoch kann Prozessor 52 so konfiguriert sein, um digital gespeicherte Anweisungen 56 aus Speicher-Vorrichtung(en) 54 auszuführen – die von den Anweisungen 46 abweichen können. Anweisungen 56 können als Software und/oder Firmware-Programme ausgeführt sein, mit denen der Server 50 bei der Ausführung eine Reihe von Diensten zum Aggregieren anbieten kann und mindestens einen Teil des nachfolgend besprochenen Verfahrens ausführt. Beispielsweise können die in Speicher-Vorrichtung(en) 54 gespeicherten und vom Prozessor 52 ausführbaren digitalen Anweisungen 56 so konfiguriert sein, um die vom LBC 22 empfangenen Upload-Nachrichten 34 zu aggregieren. 5 zeigt eine Aggregation von mehreren Upload-Nachrichten 34 in einen einzigen Fahrzeugdaten-Upload (VDU) 32, und ein Beispiel hierfür ist in dem nachfolgend beschriebenen Verfahren angegeben. Weiterhin können die Anweisungen 56 dem Prozessor 52 ermöglichen, Inhalte oder Inhaltsdaten aus dem Hauptteil jeder Nachricht 34 zu extrahieren und die Inhalte in einem übersichtlichen Format zusammenzustellen oder anzuordnen.
-
Der Speicher-Vorrichtung(en) 54 können ähnlich zu den oben beschriebenen Speicher-Vorrichtungen 42 sein – außer, dass Vorrichtung(en) 54 unterschiedliche Daten und/oder digitale Anweisungen speichern. Beispielsweise können die Speicher-Vorrichtung(en) jedes geeignete nicht transitorische computerlesbare oder vom Computer nutzbare Medium enthalten, das eine oder mehrere Speichervorrichtungen, Speicherartikel oder Datenbanken enthalten kann. Exemplarische nicht-transitorische computernutzbare Speichervorrichtungen beinhalten ein herkömmliches Computersystem-RAM (random access memory), ROM (read only memory), EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM) und magnetische oder optische Platten oder Bänder. In 3 ist eine Speichervorrichtung 42 gezeigt; stattdessen könnte jedoch jeder Server 50 mehrere Speichervorrichtungen 54 umfassen.
-
In einer Ausführungsform sind alle Server 50 identisch und in ähnlicher Weise konfiguriert. Beispielsweise können die auf jedem Server 50 gespeicherten Befehle 56 identisch sein, sodass jeder Server gleichermaßen Anweisungen zum Aggregieren ausführen kann. Auf diese Weise kann/können, wenn ein Server 50 eine Verarbeitungsverzögerung aufweist, ein oder mehrere andere Server 50 seine Aufgaben oder Zuständigkeiten übernehmen. Wie hierin verwendet, enthält eine Verarbeitungsverzögerung jede server-bezogene Verzögerung, Fehlfunktion oder jedes Problem und/oder jede server-bezogene Nichtfunktionsfähigkeit – von denen alle tendenziell die Verarbeitungsfähigkeit oder -leistung des jeweiligen Servers 50 auf weniger als einen vorbestimmten oder vergleichenden Schwellwert bremsen. Ein vorgegebener Schwellwert ist ein objektiver Wert (z. B. ein Prozentsatz) und enthält einen Schwellenwert basierend auf einer restlichen CPU- oder Verarbeitungsfähigkeit (z. B. anstatt der aktuell bearbeiteten Aufgaben, Routinen, Programme usw.). Ein vergleichender Schwellwert kann ein subjektiver Wert auf Grundlage der relativen CPU- oder Verarbeitungsfähigkeit sein – verglichen mit anderen Servern 50 in der Serverfarm 24. So könnte zum Beispiel in mindestens einer Ausführungsform ein Server unter dem vordefinierten Schwellwert arbeiten, aber höher gegenüber einem vergleichenden Schwellenwert – in solchen Fällen soll der Server nicht als in der Verarbeitung verzögert angesehen werden. Weiter mit diesem Beispiel, wenn der gleiche Server sowohl unter einem vordefinierten Schwellenwert als auch unter einem vergleichenden Schwellenwert arbeitet, dann kann der Server eine Verarbeitungsverzögerung aufweisen.
-
In anderen Ausführungsformen könnte(n) ein oder mehrere Server 50 zum Empfang bestimmter Upload-Nachrichten 34 dediziert oder markiert sein (z. B. vorgesehen) – z. B. basierend auf dem Nachrichteninhalt oder einer Quelle der Nachricht 34. Beispielsweise könnte(n) einer oder mehrere Server 50 Upload-Nachrichten 34 vom LBC 22 bezüglich einer ersten Gruppe von Fahrzeugen 10 empfangen, während einer oder mehrere andere Server 50 Upload-Nachrichten 34 vom LBC 22 bezüglich einer zweiten Gruppe von Fahrzeugen 10 empfangen, usw. Oder beispielsweise könnte(n) einer oder mehrere Server 50 Upload-Nachrichten 34 vom LBC 22 empfangen, wenn die Upload-Nachrichten einem Diagnoseprotokoll oder einer Funktion zugeordnet sind, die in den Fahrzeugen 10 bestimmt ist. Oder beispielsweise könnte(n) einer oder mehrere unterschiedliche Server 50 Upload-Nachrichten 34 vom LBC 22 empfangen, wenn die Upload-Nachrichten einer Software-Version des fahrzeugeigenen Kommunikationssystems der Fahrzeuge 10 zugeordnet sind. Wie weiter unten besprochen wird, kann der LCB 22 dafür verantwortlich sein, diese unterschiedlichen Kategorien der Upload-Nachrichten 34 zu sortieren und die Nachrichten 34 entsprechend auf die verschiedenen Server 50 zu verteilen.
-
In anderen Ausführungsformen kann der LBC 22 den operativen Betriebszustand jedes Server 50 bestimmen, sodass die Aggregationsaufgaben oder Zuständigkeiten der jeweiligen Server 50 bei einer Verarbeitungsverzögerung bei einem oder mehreren Server(n) 50 aufgeteilt werden können. Wenn daher die Server 50 zum Empfang der Nachrichten 34 basierend auf einer Kategorie wie Inhalt, Quelle usw. markiert sind, werden in mindestens einer bevorzugten Ausführungsform jeder Kategorie mehrere Server 50 zugeordnet – auf diese Weise kann im Falle einer Verarbeitungsverzögerung ein anderer gleichartig markierter Server 50 (in der gleichen Kategorie) die Zuständigkeiten des Servers mit der Verarbeitungsverzögerung übernehmen. Somit ist unabhängig von der Konfiguration der Server 50 vorgesehen, dass mindestens ein weiterer Server 50 die Aufgaben oder Zuständigkeiten jedes Servers 50 übernehmen kann – sodass der LBC 22 Anpassungen der Serverauswahl vornehmen und den Datenverkehr der Upload-Nachrichten zwischen unterschiedlichen Servern 50 balancieren kann.
-
1 zeigt, dass der Computer 26 für die Datenzusammenführung und der Computer 28 für die Datenanalyse jeweils Prozessoren 62, 72, Speicher-Vorrichtungen 64, 74 und digital gespeicherte Befehle 66, 76 umfassen kann. Aus Gründen der Kürze werden die Prozessoren 62, 72 und die Speicher-Vorrichtungen 64, 74 hierin nicht beschrieben. Es sollte beachtet werden, dass jede dieser Vorrichtungen 62–64 und 72–74 nach einer oder mehreren der oben beschriebenen Implementierungen der Prozessoren und Speicher-Vorrichtungen im Hinblick auf den LBC 22 und/oder die Server 50 ausgeführt werden kann. Dementsprechend kann jeder der Prozessoren 62, 72 die Anweisungen 66, 76 aus den (entsprechenden) Speicher-Vorrichtungen 64, 74 ausführen, um mindestens einen Teil des hierin beschriebenen Verfahrens auszuführen. Die Anweisungen 66 und 76 können sich jedoch hinsichtlich Konfiguration, Zweck und Funktion unterscheiden.
-
In mindestens einer Ausführungsform können die Anweisungen 66 einen oder mehrere VDUs 32 von der Serverfarm 24 gemäß geeigneten Affinitäten gruppieren – z. B. die VDUs 32 in Vorbereitung für die Analyse durch den Datenanalysecomputer 28 aggregieren. Beispielsweise zeigt 6, dass mehrere VDUs 32 in einer Datenzusammenstellung oder VDU-Affinitätsgruppe 80 aggregiert werden können (z. B. nach Analogie, wenn ein VDU 32 eine Datei ist, könnte die Affinitätsgruppe 80 ähnlich zu einer Sammlung von Dateien sein; dieses Beispiel dient jedoch lediglich zur Erläuterung einer Affinitätsgruppierung; andere geeignete Affinitätsgruppierungen oder Darstellungen sind ebenso denkbar). Nichtbeschränkende Beispiele der VDU-Zusammenführung in Affinitätsgruppen 80 enthalten: Aggregieren von VDUs 32 gemäß dem spezifischem Fahrzeug 10, von dem die VDUs 32 empfangen wurden, Aggregieren der VDUs 32 gemäß einer vorbestimmten Anzahl oder Auswahl von Fahrzeugen 10, von denen die VDUs 32 empfangen wurden, Aggregieren der VDUs 32 gemäß der Fahrzeuge 10 innerhalb eines bestimmten oder allgemeinen geographischen Orts oder Bereichs zum Zeitpunkt der Upload-Nachricht(en) 34, Aggregieren der VDUs 32 gemäß Art oder Kategorie von Diagnosenachricht oder Diagnosefehlercode (z. B. DTC), Aggregieren von VDUs 32 gemäß einer zugeordneten Software-Version mit den Fahrzeugen 10 (z. B. eine Software-Version zugeordnet zu jedem der fahrzeugeigenen Kommunikationssysteme) usw. Wiederum sind dies lediglich Beispiele. Die Art, wie die Daten zur Analyse durch den Datenanalysecomputer 28 vorbereitet und aggregiert werden, kann gemeinsam mit Systemarchitekten und anderen Fachleuten ausgewählt oder konfiguriert werden, die mit Art und/oder Notwendigkeit für bestimmte Fahrzeuganalytik vertraut sind.
-
Weiterhin kann der Prozessor 62 durch Ausführen der Anweisungen 66 die VDUs 32 gemäß vordefinierter oder vorbereiteter Affinitäten gruppieren. Oder die Anweisungen 66 können dem Prozessor 62 erlauben, Eingabe oder Rückkopplung 82 vom Datenanalysecomputer 28 zu akzeptieren – z. B. Bereitstellen regelmäßiger oder periodischer Echtzeit-Änderungen an gewünschten Affinitäten. In diesem letzteren Fall kann der Datenaggregationscomputer 26 – mindestens vorübergehend – die VDUs 32 in unterschiedlichen Affinitätsgruppen 80 aggregieren und danach diese verschiedenen Affinitätsgruppen 80 dem Computer 28 bereitstellen. Wieder ist dies nur ein Beispiel; andere Implementierungen durch Systemarchitekten sind ebenfalls möglich.
-
Die Anweisungen 76 können eine Affinitätsanalyse der VDUs 32, der VDU-Gruppen 80 oder von beiden durchführen. Beispielsweise kann der Datenanalysecomputer 28 VDUs 32, VDU-Gruppen 80 oder beide verarbeiten und dabei aufdecken: zu Fahrzeugen 10 gehörige Muster oder zu Benutzern der Fahrzeuge 10 gehörige Muster; Korrelationen basierend auf Geographie, Fahrzeughersteller, Fahrzeugmodell, Fahrzeugbenutzer-Demographie, Fahrzeug-Hardware und/oder -Software (z. B. einschließlich Softwareversionen) und Fahrzeugdiagnose, um nur einige nichtbeschränkende Beispiele zu nennen; Kunden-Präferenzen und Trends (z. B. Daten-Downloads, Upload-Trends, Nutzung der Fahrzeug-Hardware/Software durch Benutzer usw.); und/oder Marketing- oder andere geschäftliche nützliche Informationen. Systemarchitekten und andere Fachleute werden geeignete Arten von Analysen, geeignete Zeitpunkte und Dauern solcher Analysen, geeignete Realisierung solcher Analysen, und dergleichen begrüßen. Es ist offensichtlich, dass Big-Data-Analytik mit Verwendung der Anweisungen 76 zur Verbesserung der Fahrzeug-Erfahrung der Teilnehmer-Fahrzeuge 10 verwendet werden kann, die operative Effizienz der Daten-Servicestelle 12 verbessern kann, Marketing-Umsatz erzeugen kann und/oder die Daten-Servicestelle 12 mit bestimmten Wettbewerbsvorteilen gegenüber anderen Backend-Systemen versorgen kann. Die Beispiele der analytischen Anweisungen 76 sind lediglich exemplarisch; andere Implementierungen werden hierin vorgesehen.
-
Die in 1 gezeigte Big-Data- oder Backend-Datenbank 30 kann im Allgemeinen jede geeignete Art bzw. Ansammlung von Speichervorrichtungen (ähnlich wie die zuvor beschriebenen) sein; z. B. kann Datenbank 30 ein nichtflüchtiges computerlesbares oder vom Computer nutzbares Medium sein. In mindestens einer Ausführungsform kann Umfang oder Größe der Speicher-Vorrichtung(en) der Datenbank 30 größer als alle der zuvor beschriebenen Speichervorrichtungen sein (z. B. größer als Vorrichtungen 42, 64 oder 74); z. B. zehnmal, hundertmal oder tausende Mal größer. Die Datenbank 30 kann historische VDU-Daten und gruppierte VDU-Daten, historische Analysen der VDU-Daten und VDU-Gruppierungen usw. speichern. Weiterhin kann die Datenbank 30 über den Datenanalysecomputer 28 zugänglich sein – z. B. zum Vergleich vorhandener oder aktueller Daten mit historischen Daten. Die Dauer, in der Datenbank 30 solche Daten speichert, die spezifischen Arten der darin gespeicherten Daten usw. wird für Fachleute bekannt sein.
-
Ein Verfahren wird nachfolgend unter Verwendung des privaten Computernetzwerks 20 der Daten-Servicestelle 12 beschrieben, worin die zuvor beschriebenen Elemente 22, 24, 26, 28 und 30 in Reihenfolge und/oder zusammen miteinander arbeiten, um das Verfahren durchzuführen. Wie in 1 gezeigt, können Upload-Nachrichten 34 über jedes geeignete Kommunikationsmedium zum Load-Balancing-Computer (LBC) 22 übertragen werden, der bestimmen kann, an welchen der einen oder mehreren geeigneten Server 50 in der Serverfarm 24 die Upload-Nachrichten 34 zu senden sind. Bei der Serverfarm 24 können die Upload-Nachrichten 34 in VDUs 32 zusammengestellt und zum Datenaggregationscomputer 26 gesendet werden. Beim Datenaggregationscomputer 26 können die VDUs 32 weiter in VDU-Gruppen 80 aggregiert werden; dann können die VDUs 32 und/oder VDU-Gruppen 80 zum Datenanalysecomputer 28 weitergeleitet werden. Beim Analysecomputer 28 können die Daten 32, 80 analysiert und jede geeignete Ausgabe kann erzeugt werden. VDUs 32, die Gruppen 80, der analytische Ausgabe des Datenanalysecomputers 28 oder eine beliebige Kombination davon kann für jede passende Zeitdauer in der/den Datenbank(en) 30 gespeichert werden. Dieses Verfahren kann kontinuierlich sein. Weiterhin kann der LBC 22 so konfiguriert werden, um den Datenverkehr zu optimieren, sodass der Datenanalysecomputer 28 VDUs 32 und VDU-Gruppen 80 zeitnäher empfängt – z. B. in anderen Worten kann der LBC 22 den Datenverkehr zwischen den Servern 50 ausbalancieren, um die Geschwindigkeit und Effizienz des Aggregierens zu maximieren. Wie in dem nachfolgenden Verfahren besprochen, wird die Struktur des privaten Computernetzwerks 20 – sowie die Konfigurationen und Befehle der jeweiligen Computer/Computersysteme – angepasst, um die Aggregation der Big Data näher zum Rand des privaten Computernetzwerks 20 zu bringen; d. h. angepasst, um die Aggregation der Big Data näher zum LBC 22 zu bringen, wodurch letztlich eine effizientere und schneller Datenanalyse möglich wird.
-
Verfahren –
-
Nun zu den 7A–7B, wo eine Methode 700 zum Aggregieren von Fahrzeugdaten gezeigt ist, die das private Computernetzwerk 20 verbunden mit der Daten-Servicestelle 12 verwendet. Das Verfahren beginnt mit Schritt 705, worin der Load-Balancing-Computer (LBC) 22 eine Upload-Nachricht 34 empfängt. Zu Veranschaulichungszwecken beschreibt Methode 700 eine einzige Upload-Nachricht. Es sollte jedoch klar sein, dass der LBC 22 in der Praxis Millionen von Upload-Nachrichten 34 gleichzeitig oder nahezu so empfangen könnte. Im Schritt 705 kann die Nachricht 34 über jedes geeignete Mittel empfangen werden (z. B. über eine Mobilfunkübertragung, SRWC-Kommunikation (z. B. über Infrastrukturen), über eine Fahrzeug-Servicestelle usw.). In mindestens einer Ausführungsform wird die Upload-Nachricht 34 per Mobilverbindung über das fahrzeugeigene Kommunikationssystem von einem der Teilnehmer-Fahrzeuge 10 empfangen (z. B. eine gesendete Paketdatennachricht über das Drahtlosträgersystem 14 und das Festnetz 16). Dies kann das Ergebnis sein, wenn das Fahrzeug 10 die Upload-Nachricht 34 aktiv zum LBC 22 versendet (z. B. eine Push-Benachrichtigung).
-
Sobald die Upload-Nachricht 34 am LBC 22 empfangen ist, bestimmt (z. B. zerlegt, liest und interpretiert) der LBC im Schritt 710 mindestens einen Parameter eines Headers 102 der Upload-Nachricht 34; siehe 4. 4 veranschaulicht ein Format einer Paketdaten-Ausführungsform der Upload-Nachricht 34. Wieder sollte klar sein, dass Paketdaten lediglich eine Art der Upload-Nachricht 34 sind (z. B. wie oben erörtert, könnte die Nachricht 34 eine SMS-Nachricht oder jede andere geeignete Art einer digitalen Übertragung sein). Die Upload-Nachricht 34 in 4 umfasst den Header 102, einen Hauptteil 104 und eine Fußzeile 106. In mindestens einer Ausführungsform enthält der Header 102 mindestens einen unverschlüsselten Teil 110; in manchen Ausführungsformen kann der Header 102 ferner ebenso einen verschlüsselten Teil 112 umfassen (dies ist jedoch nicht erforderlich). Der unverschlüsselte Teil 110 kann ein Übertragungssteuerprotokoll/Benutzer-Datagrammprotokoll (oder TCP/UDP) Header sein und kann einen oder mehrere Header-Parameter 120–132 umfassen. In 4 sind Beispiele unverschlüsselter Header-Parameter 120–132 dargestellt; diese sind jedoch lediglich Beispiele. Bei einigen Ausführungsformen kann ein einziger unverschlüsselter Header-Parameter vorhanden sein (z. B. einer der Parameter 120–132). Und in noch anderen Ausführungsformen kann es andere unverschlüsselte Header-Parameter als die hierin gezeigten und beschriebenen geben oder mehr oder weniger Parameter als in 4 gezeigt. Nichtbeschränkende Beispiele unverschlüsselter Header-Parameter 120–132 mfassen: einen Hinweisparameter für das Nachrichtenformat 120, einen Identifikationsparameter zum Anwendungs-Trigger 122, einen Parameter zur Identifikation der Einheit 124, einen Zeitstempel-Parameter 126, einen Parameter der Nachrichtengröße 128, einen oder mehrere Sub-Header-Parameter 130 und einen oder mehrere Transport- oder Transportprotokoll-Parameter 132. Der Hinweisparameter für das Nachrichtenformat 120 kann Anweisungsinformationen für die Server 50 bereitstellen – z. B. wie der Hauptteil 104 der Nachricht 34 zu zerlegen ist. Zusätzlich könnte der Hinweisparameter für das Nachrichtenformat 120 die vom fahrzeugeigenen Kommunikationssystem des Fahrzeugs 10 verwendete Software-Version angeben (von der aus die Nachricht 34 gesendet wurde). Der Identifikationsparameter zum Anwendungs-Trigger 122 kann einen Zweck oder Verwendungsfall der Nachricht angeben – z. B. ob die Nachricht 34 Diagnose, Fahrverhalten, usw. betrifft. In einigen Implementierungen kann Parameter 122 angeben, ob Daten zu einem speziellen Modul im jeweiligen Fahrzeug 10 gehören (z. B. ein Bordnetzsteuergerät, eine Navigationseinheit, usw.). Der Parameter zur Identifikation der Einheit 124 kann das bestimmte Fahrzeug 10 identifizieren, von dem aus die Nachricht 34 gesendet wurde. In einigen Implementierungen kann dies eine Fahrgestellnummer (VIN) oder eine Fabrikationsnummer oder APN sein, welche das fahrzeugeigene Kommunikationssystem des bestimmten Fahrzeugs 10 identifiziert. Dies sind lediglich Beispiele; es gibt auch andere Beispiele (z. B. eine zugeordnete Kennung zu einem Subscriber-Identity-Module (SIM) wie eine internationale Mobilteilnehmer-Identität (oder IMSI)). Der Zeitstempel-Parameter 126 enthält eine Angabe zu einer Zeit, wann die Nachricht 34 übertragen wurde; z. B. eine tatsächliche Zeit der Übertragung vom Fahrzeug 10. Dies ist nur ein Beispiel eines Zeitparameters; ebenso können andere Zeitparameter verwendet werden. Der Größenparameter 128 kann die Größe der jeweiligen Upload-Nachricht 34 anzeigen (oder etwa die Größe des Hauptteils 104 der Nachricht 34) und/oder die Größe des gesamten VDU 32 (zu dem die Nachricht 34 gehört). Der/Die Sub-Header-Parameter(s) 130 kann/können zusätzliche Informationen zur Art und Reihenfolge der Upload-Nachrichten 34 angeben, welche der VDU 32 umfasst. Beispielsweise kann ein Sub-Header-Parameter 130 ein Index-Wert sein, der einem Server 50 (in der Serverfarm 24) das erneute Zusammenstellen der Nachricht 34 in einer Aufeinanderfolge mit anderen konstituierenden Elementen des jeweiligen VDU 32 gestattet. Nur zu Zwecken der Veranschaulichung betrachten wir eine Folge von fünf Upload-Nachrichten mit den Indexwerten 001, 002, 003, 004 und 005, worin die bestimmte Upload-Nachricht 34 (in Schritt 710) einen Indexwert 004 hat. Server 50 könnte die bestimmte Upload-Nachricht zwischen den einzelnen Nachrichten mit Indizes von 003 und 005 neu zusammenstellen (sobald der Server 50 diese Nachrichten ebenfalls empfangen hat). Dies ist natürlich nur ein Beispiel zur Veranschaulichung einer Implementierung des Sub-Header-Parameters 130 (z. B. wie eine Reihe oder Folge von Upload-Nachrichten 34 später auf Server 50 neu zusammengestellt werden könnte); andere Implementierungen sind auch möglich. Und der/die Transport-Parameter 132 könnte das Quell-Internetprotokoll(IP)-Adresse und die Port-Nummer identifizieren (und/oder die Ziel-IP-Adresse und Port-Nummer), sowie jede andere geeignete Information zum Transportprotokoll.
-
Als Nächstes in Schritt 715, bevor die Upload-Nachricht 34 an einen oder mehrere Server 50 gesendet wird, kann der LBC den Zeitstempel-Parameter 126 der Upload-Nachricht 34 bestimmen (z. B. zerlegen, auslesen und auszuwerten). Genauer gesagt kann der LBC 22 im Schritt 715 bestimmen, ob ein zugehöriges Zeitfenster für die Upload-Nachricht 34 abgelaufen ist. In einer Ausführungsform kann der LBC 22 einen vorbestimmten Zeitraum oder ein Ablauffenster speichern, den Zeitstempel-Parameter 126 mit diesem Ablauffenster vergleichen und bestimmen, ob die Upload-Nachricht 34 abgelaufen ist oder nicht. Wenn die Upload-Nachricht abgelaufen ist, kann der LBC 22 die Nachricht 34 ignorieren und/oder verwerfen und das Verfahren 700 kann zum Schritt 705 zurückkehren. Wenn die Upload-Nachricht nicht abgelaufen ist, dann kann das Verfahren bei Schritt 720 fortsetzen. Dem Ablauffenster kann einer Zeitdauer zugeordnet werden, in der der LBC 22 den Empfang eines gesamten vom Fahrzeug 10 gesendeten VDU 32 erwartet. Wenn zum Beispiel ein Fahrzeug 10 einen VDU in einer Folge von Upload-Nachrichten 34 überträgt, kann dies relativ schnell auftreten (z. B. in Sekunden oder auch wenigen Minuten). In einigen Fällen kann der LBC 22 mehrere weitere Minuten lang keine der Upload-Nachrichten empfangen – besonders wenn Übertragungsverzögerungen auftrete. Somit könnte in mindestens einigen Ausführungsformen das Ablauffenster 15 Minuten, 20 Minuten oder auch 30 Minuten sein. In jedem dieser Beispiele berücksichtigt die Dauer des Ablauffensters die Zeit der Fahrzeugübertragung, Verzögerungen oder Rückstände im Trägersystem 14 oder Festnetz 16 und manchmal mehrere oder mehr zusätzliche Minuten (z. B. eine Zeit- oder Verzögerungstoleranz). So kann nur zu Veranschaulichungszwecken und – bei Annahme eines Ablauffensters von 30 Minuten – der LBC 22 festlegen, dass der Wert des Zeitstempel-Parameters 126 2015-10-31, 13:10:59 ist und das mit einem Zeitwert am LBC vergleichen. Wenn die LBC-Uhr kleiner oder gleich 2015-10-31, 13:40:59 ist (d. h. 30 Minuten ab der Zeit der Übertragung), so bestimmt der LBC 22, dass die Nachricht 34 noch nicht abgelaufen ist und geht weiter zu Schritt 720. Und wenn die LBC-Uhr größer als 2015-10-31, 13:40:59 ist, dann bestimmt der LBC 22, dass die Nachricht 34 abgelaufen ist, ignoriert und/oder verwirft die Nachricht 34 und kehrt zum Schritt 705 zurück. Auf diese Weise können Nachrichten 34, die für eine Echtzeit-Analyse nicht mehr relevant sind, vom Prozess der Big-Data-Aggregation entfernt werden wodurch – die Systemeffizienz verbessert wird.
-
Als nächstes in Schritt 720 kann der LBC 22 einen oder mehrere Server 50 in der Serverfarm 24 bestimmen, um die nicht abgelaufene Upload-Nachricht 34 dorthin zu senden. Wie oben erörtert, kann diese Auswahl von einem oder mehreren der unverschlüsselten Header-Parameter 120–132 abhängen. Wenn zum Beispiel der LBC 22 Upload-Nachrichten anhand der Quelle sortiert, kann der LBC 22 die Server 50 basierend auf dem unverschlüsselten Parameter zur Identifikation der Einheit 124 bestimmen. Oder wenn beispielsweise der LBC 22 Upload-Nachrichten anhand des Inhalts sortiert, kann der LBC 22 die Server 50 basierend auf dem unverschlüsselten Parameter zur Anwendungs-Triggererkennung 122 bestimmen. Oder wenn beispielsweise der LBC 22 Upload-Nachrichten anhand der Software-Version (der jeweiligen fahrzeugeigenen Kommunikationssysteme) sortiert, kann der LBC 22 den/die Server 50 basierend auf dem unverschlüsselten Indikator für das Nachrichtenformat 120 bestimmen. Oder wenn der LBC 22 Upload-Nachrichten anhand von Transport-Parameter(n) sortiert, könnte der LBC den/die Server 50 anhand der Quell-IP-Adresse und dem Port und/oder der Ziel-IP-Adresse und dem Port bestimmen. In einigen Implementierungen könnten mehr als ein Parameter 120–132 für die Bestimmung berücksichtigt werden, an welche(n) Server die Nachricht 34 zu senden ist. Somit können diese Sortiermittel einzeln oder in Kombination miteinander verwendet werden. Und dies sind lediglich einige Beispiele zur Veranschaulichung eines Aspekts, wie der LBC 22 einen Server 50 auswählen kann. Wie nachfolgend in Schritt 725 beschrieben, kann der LBC 22 auch berücksichtigen, welche(r) Server 50 ein geringeres Datenverkehrsaufkommen hat/haben.
-
In mindestens einer Ausführungsform nutzt der LBC 22 lediglich den Parameter zur Einheits-Identifikation 124 und/oder den Zeitstempel-Parameter 126. In mindestens einer anderen Ausführungsform verwendet der LBC 22 mindestens einen von: dem Parameter zur Einheits-Identifikation 124, dem Zeitstempel-Parameter 126 und dem/den Transport-Parameter(n) 132. Und in mindestens einer anderen Ausführungsform verwendet der LBC 22 mindestens einen von: dem Parameter zur Einheits-Identifikation Parameter 124, dem Zeitstempel-Parameter 126, dem/den Transport- Parameter(n) 132, dem Parameter des Nachrichtenformats 120 und dem Parameter des Anwendungstriggers 122.
-
Im Schritt 725 bestimmt der LBC 22 den Status der ausgewählten Server 50 – z. B., ob der/die ausgewählte(n) Server 50 in einem normalen oder abnormalen Zustand arbeiten. Wenn die Server 50 im Normalbetrieb arbeiten, dann fährt das Verfahren mit Schritt 740 (7B) fort. Falls jedoch der/die die ausgewählte(n) Server 50 in einem abnormalen Zustand sind, dann fährt das Verfahren mit Schritt 730 fort (wählt z. B. einen anderen Server 50 oder erwägt zumindest einen anderen Server). Der Normalbetrieb 50 kann bei dem/den Server(n) 50 anzeigen, dass keine Verarbeitungsverzögerung(en) auftreten. Und der abnormale Zustand kann bedeuten, dass bei dem/den Server(n) 50 Verarbeitungsverzögerungen auftreten (oder ganz außer Betrieb sind).
-
Im Schritt 730 kann der LBC einen anderen Server 50 identifizieren – z. B. mindestens einen alternativen Server, an den die Upload-Nachricht 34 zu senden ist. Der andere Server 50 kann aus ähnlichen Gründen wie in Schritt 720 identifiziert oder bestimmt werden. Beispielsweise kann der andere Server 50 so identifiziert werden, dass er ähnlich kategorisierte Upload-Nachrichten 34 verarbeitet. Nach Schritt 730 kehrt das Verfahren 700 zum Schritt 725 zurück und bestimmt den Status des/der neu ausgewählten Server(s) 50. In einigen Implementierungen kann/können der/die neu ausgewählte(n) Server 50 im Normalbetrieb sein, in welchem Fall das Verfahren mit Schritt 740 fortfährt. Wenn jedoch der/die neu ausgewählte(n) Server 50 auch in einem abnormalen Zustand sind, kann der LBC 22 entweder mit Schritt 730 fortfahren (andere(n) Server 50 auswählen) oder einen Vergleich zwischen den zwei oder mehr der zuvor ausgewählten Server 50 machen (z. B. bestimmen, ob einer oder mehrere zur Verarbeitung der jeweiligen Upload-Nachricht 34 besser geeignet sind als die anderen). Das kann einschließen, dass der LBC 22 den oben erörterten vergleichenden Schwellwert bestimmt. Weiter kann diese Schleife zwischen den Schritten 725 und 730 iterativ sein. Durch abnormale Betriebszustände mehrerer Server 50 könnte der LBC 22 beispielsweise mehrere Server 50 auswählen (die alle in abnormalen Modi arbeiten) und schließlich einen der besser (oder am besten) geeigneten Kandidaten auswählen. Diese iterative Bestimmung kann zum Beispiel typischerweise während Perioden mit hohem Verkehrsaufkommen, ausgeführter Wartung an Servern 50 oder wenn mehrere Server 50 Verarbeitungsverzögerungen aufweisen, auftreten. In einigen Umständen kann das Verfahren auch zurück zu Schritt 720 gehen und basierend auf anderen Parameter(n) einen Telematik-Server auswählen. Es versteht sich von selbst, dass Schritte 715, 720, 725 und 730 Load-Balancing-Schritte sind; d. h. der LBC 22 kann den effizientesten Server 50 zur Weiterverarbeitung der jeweiligen Upload-Nachricht 34 bestimmen.
-
In Schritt 740 (7B) überträgt der LBC 22 die Upload-Nachricht 34 zu dem/den ermittelten oder letztlich ausgewählten Server(n) 50. In mindestens einer Ausführungsform erfolgt das über eine verdrahtete Verbindung im privaten Computernetzwerk 20 (z. B. über einen Bus oder dergleichen); jedoch ist das nicht obligatorisch.
-
Im Schritt 745 kann der ausgewählte Server 50 der Serverfarm 24 beginnen, den VDU 32 unter Verwendung der Upload-Nachricht 34 zu erstellen oder zusammenzusetzen. Das obige Beispiel weiterführend, wenn beispielsweise die bestimmte Upload-Nachricht 004 ist – und mit der Annahme, der Server 50 hat zuvor die Nachrichten 001, 002, 003 und 005 empfangen – dann kann Server 50 die Zusammenstellung der VDU 32 unter Verwendung dieser letzten Nachricht (d. h. 004) fertigstellen. Der Server 50 kann nicht nur die Upload-Nachrichten (001, 002, 003, 004, und 005) gemäß VDU 32 aggregieren; der Server 50 kann die Inhalte jeder Upload-Nachricht 34 extrahieren und die Bestandteile in ein Ganzes zusammenfügen – d. h. eine ganze VDU-Datei. Wie bereits erläutert, kann der Hauptteil jeder Upload-Nachricht 34 mindestens teilweise verschlüsselt sein; daher kann der Server 50 den Inhalt jeder Nachricht 34 entschlüsseln und die unverschlüsselten Inhalte in einer gesamten VDU-Datei neu zusammenfügen. In anderen Implementierungen kann die Entschlüsselung beim Datenaggregationscomputer 26 erfolgen.
-
Im Schritt 750 kann der ausgewählte Server 50 bestimmen, ob der gesamte VDU 32 zusammengesetzt wird. Wenn der VDU nicht vollständig ist, kann der Server 50 ermitteln, dass er zusätzliche Upload-Nachrichten 34 (Schritt 755) empfangen muss und zu Schritt 705 zurückkehren. Wenn das Verfahren zum Schritt 705 zurückkehrt, sollte klar sein, dass die Folge der Upload-Nachrichten, die den gesamten VDU ausmachen, in beliebiger Reihenfolge und in unregelmäßigen Abständen empfangen werden können. Weiterhin kann während eine Upload-Nachricht 34 verarbeitet wird (zugeordnet zu einem bestimmten VDU 32), eine andere zugehörige Upload-Nachricht 34 am LBC 22 empfangen werden, bevor die erste Nachricht im Schritt 750 verarbeitet wird. Somit kann das Verfahren im Allgemeinen kontinuierlich und sich überlappend sein. Wenn im Schritt 750 der Server 50 bestimmt, dass die VDU 32 vollständig ist (alle Upload-Nachrichten sind kompiliert), dann kann das Verfahren 700 mit Schritt 760 fortfahren.
-
In Schritt 760 überträgt der Server 50 den jeweiligen VDU 32 zum Datenaggregationscomputer 26. Nach Erhalt im Schritt 765 stellt der Aggregationscomputer 26 die VDUs 32 gemäß einer oder mehrerer passender Affinitäten zusammen (z. B. wie oben erörtert). Im Allgemeinen ist für Fachleute und Systemarchitekten offensichtlich, welche Affinitäten für die Aggregation entsprechend oder wünschenswert sind. In mindestens einer Ausführungsform stellt der Datenaggregationscomputer 26 mehrere VDUs 32 in einer VDU-Affinitätsgruppe 80 zusammen und stellt diese Gruppe 80 dem Datenanalysecomputer 28 unter Verwendung des privaten Computernetzwerks 20 (z. B. über einen Datenbus) zur Verfügung. In anderen Ausführungsformen stellt der Datenaggregationscomputer 26 dem Datenanalysecomputer 28 zusätzlich oder anstatt der Affinitätsgruppen 80 mehrere VDUs 32 zur Verfügung. Die zusammengestellten VDUs 32 können vom selben Fahrzeug 10 sein, aber wahrscheinlicher von anderen Teilnehmer-Fahrzeugen 10 stammen. Desgleichen sind die Affinitätsgruppen 80 in vielen Implementierungen von mehreren Fahrzeugen 10 (dies ist jedoch nicht erforderlich). Sobald die VDUs 32 aggregiert sind, geht das Verfahren 700 weiter zu Schritt 770.
-
Im folgenden Schritt 770 wertet der Datenanalysecomputer 28 die VDUs 32, die Affinitätsgruppen 80 oder beide aus. Ähnlich zu Schritt 765 werden Fachleute und Systemarchitekten entsprechende oder gewünschte Analysen begrüßen, die durch den Analysecomputer 28 ausgeführt werden. Diese Analysen können in der Datenbank 30 gespeichert werden. Weiterhin kann der Analysecomputer 28 der Datenbank 30 ebenfalls VDUs 32 und/oder Affinitätsgruppen 80 zur Speicherung bereitstellen. Nach dem Schritt 765 endet das Verfahren 700.
-
Somit wurde eine Daten-Servicestelle beschrieben, umfassend ein privates Computernetzwerk zur Verwendung von Daten, die von einem oder mehreren Teilnehmer-Fahrzeugen empfangen wurden. Das Computernetzwerk enthält einen Gateway-Computer oder Load-Balancing-Computer, der die Fahrzeugdaten zerlegt und sortiert sowie bestimmt, an welchen aus einer Vielzahl von Telematik-Servern die jeweiligen Fahrzeugdaten gesendet werden. Das Computernetzwerk kann ferner die Daten in Vorbereitung für eine noch höhere Schicht der Analyseausführung aggregieren. Das Computernetzwerk ist so konfiguriert, dass mehr Aggregation näher an einer physikalischen Schicht (z. B. ein Drahtlosträgersystem und/oder Festnetz) durchgeführt wird. Auf diese Weise kann die Leistung und Effizienz der Daten-Servicestelle verbessert werden.
-
Es versteht sich, dass es sich bei dem Vorstehenden um eine Beschreibung einer oder mehrerer Ausführungsformen der Erfindung handelt. Die Erfindung ist nicht auf die besonderen hierin offenbarten Ausführungsform(en) beschränkt, sondern wird ausschließlich durch die folgenden Patentansprüche definiert. Darüber hinaus beziehen sich die in der vorstehenden Beschreibung gemachten Aussagen auf bestimmte Ausführungsformen und sind nicht als Einschränkungen des Umfangs der Erfindung oder nicht als Definition der in den Ansprüchen verwendeten Begriffe zu verstehen, außer dort, wo ein Begriff oder Ausdruck ausdrücklich vorstehend definiert wurde. Verschiedene andere Ausführungsformen und verschiedene Änderungen und Modifikationen an der/den ausgewiesenen Ausführungsform(en) sind für Fachkundige offensichtlich. Alle diese anderen Ausführungsformen, Änderungen und Modifikationen sollten im Geltungsbereich der angehängten Patentansprüche verstanden werden.
-
Wie in dieser Beschreibung und den Ansprüchen verwendet, sind die Begriffe „zum Beispiel”, „beispielsweise”, „zum Beispiel”, „wie” und „gleich” und die Verben „umfassen”, „aufweisen”, „enthalten” und ihre anderen Verbformen, wenn sie in Verbindung mit einer Auflistung einer oder mehrerer Komponenten oder anderen Gegenständen verwendet werden, jeweils als offen auszulegen, was bedeutet, dass die Auflistung nicht so berücksichtigt wird, als dass sie andere, zusätzliche Komponenten oder Elemente ausschließt. Andere Begriffe sind in deren weitesten vernünftigen Sinn auszulegen, es sei denn, diese werden in einem Kontext verwendet, der eine andere Auslegung erfordert.
