DE102017105672A1

DE102017105672A1 - Skripterstellung auf einer Telematiksteuereinheit

Info

Publication number: DE102017105672A1
Application number: DE102017105672.6A
Authority: DE
Inventors: Basavaraj Tonshal; Jamal Alezzani; John William SCHMOTZER; Panduranga Chary Kondoju; Harminder Sandhu; Mark Meyer
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2016-03-18
Filing date: 2017-03-16
Publication date: 2017-09-21
Also published as: RU2017108153A3; US10318247B2; CN107204052B; GB2550258A; RU2017108153A; GB201704152D0; US20170269908A1; CN107204052A; RU2728813C2; MX2017003582A

Abstract

Ein Telematiksteuersystem, das umfasst: einen externen Server, der so ausgelegt ist, dass er ein Skript mit einem externen Protokollpuffer serialisiert und das serialisierte Skript an eine TCU sendet; ein Fahrzeug mit Sensoren und der TCU, wobei die TCU ausgelegt ist zum: Deserialisieren des Skripts mit einem TCU-Protokollpuffer, Ausführen des Skripts durch einen im Voraus in die TCU geladenen Interpreter, Speichern von Daten von den Sensoren basierend auf dem Skript.

Description

TECHNISCHES GEBIET
Diese Offenbarung betrifft Skripts, die auf einer Telematiksteuereinheit eines Fahrzeugs ausgeführt werden.
HINTERGRUND
Fahrzeug-Telematiksteuereinheiten (TCUs für engl. telematics control units) extrahieren Daten, die in einem Fahrzeug erzeugt werden, bereiten die extrahierten Daten zur Übertragung vor und senden diese Daten dann über eine Antenne. Herkömmliche TCUs führen diese Operationen gemäß Anweisungen durch, die gemäß vorkompiliertem Code erzeugt werden. Es ist schwierig, vorkompilierten Code dynamisch zu aktualisieren, weshalb TCU-Hersteller den vollständigen Satz von TCU-Software zum Zeitpunkt der Herstellung laden (d. h. hartcodieren) müssen. Der Begriff „hartcodieren“, wie auf dem Fachgebiet verwendet, bedeutet derartiges Einbetten des Codes in den Quellcode des Programms, dass ein Ändern des eingebetteten Codes erfordert, dass der Benutzer neuen Quellcode bereitstellt. Diese Methodologie führt zu einem verlustbehafteten System, das Daten auf eine Weise sammelt, die nicht geeignet ist, um ms-Auflösung sich schnell ändernder Fahrzeugparameter zu finden.
KURZDARSTELLUNG
Diese Offenbarung behebt die zuvor erwähnten Probleme dadurch, dass sie Verfahren und Systeme zum dynamischen Aktualisieren von Code bereitstellt, der auf einer Fahrzeug-TCU ausgeführt wird. In einigen Ausführungsformen stellt die Offenbarung ein Telematiksteuersystem bereit, das umfasst: einen externen Server, der so ausgelegt ist, dass er ein Skript mit einem externen Protokollpuffer serialisiert und das serialisierte Skript an eine TCU sendet; ein Fahrzeug mit Sensoren und der TCU, wobei die TCU ausgelegt ist zum: Deserialisieren des Skripts mit einem TCU-Protokollpuffer, Ausführen des Skripts durch einen im Voraus in die TCU geladenen Interpreter, Speichern von Daten von den Sensoren basierend auf dem Skript.
Die Offenbarung stellt außerdem ein Verfahren zum Steuern einer Telematiksteuereinheit (TCU) in einem Fahrzeug mit Sensoren bereit, wobei die TCU eine Antenne, einen Prozessor und Speicher umfasst, wobei das Verfahren umfasst: Serialisieren eines Skripts mit einem externen Server-Protokollpuffer, Senden des serialisierten Skripts an die TCU, Deserialisieren des Skripts mit einem TCU-Protokollpuffer, Ausführen des Skripts durch einen im Voraus in die TCU geladenen Interpreter, Speichern von Daten von Fahrzeugsensoren basierend auf dem Skript.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Für ein besseres Verständnis der Erfindung kann auf Ausführungsformen Bezug genommen werden, die in den folgenden Zeichnungen dargestellt sind. Die Komponenten in den Zeichnungen sind nicht unbedingt maßstabgetreu, und zugehörige Elemente können wegelassen sein, oder in einigen Fällen können Proportionen übertrieben sein, um die neuartigen Merkmale, die hierin beschrieben werden, hervorzuheben und klar zu veranschaulichen. Außerdem können Systemkomponenten verschiedenartig angeordnet werden, wie auf dem Fachgebiet bekannt. Ferner bezeichnen in den Zeichnungen gleiche Bezugszeichen die verschiedenen Ansichten hindurch entsprechende Teile.
1 ist ein Blockdiagramm von Datenübertragung an ein und von einem Fahrzeug.
2 ist ein Blockdiagramm von Modulen, die innerhalb eines Skriptcodes enthalten sind.
3 ist ein Blockdiagramm einer virtuellen Maschine, die mit dem Skript ausführt.
4 ist ein Blockdiagramm eines Verfahrens zum Senden von Skriptcode an ein Fahrzeug.
5 ist ein Blockdiagramm einer Fahrzeug-Hardware.
6 ist ein Blockdiagramm eines Skripts, das über eine Schnittstelle mit Fahrzeug-Hardware verbunden ist.
AUSFÜHRLICHE BESCHREIBUNG VON BEISPIELHAFTEN
AUSFÜHRUNGSFORMEN
Obwohl die Erfindung in verschiedenen Formen realisiert werden kann, werden in den Zeichnungen einige beispielhafte und nicht einschränkende Ausführungsformen dargestellt und im Folgenden beschrieben, wobei es sich von selbst versteht, dass die vorliegende Offenbarung als eine Veranschaulichung der Erfindung zu betrachten ist und die Erfindung nicht auf die veranschaulichten spezifischen Ausführungsformen beschränken soll.
In dieser Anmeldung soll die Verwendung der Disjunktion auch die Konjunktion einbeziehen. Die Verwendung von bestimmten oder unbestimmten Artikeln soll keine Kardinalität anzeigen. Insbesondere soll eine Bezugnahme auf „das“ Objekt oder „ein“ Objekt auch eines von einer möglichen Mehrzahl solcher Objekte bezeichnen. Ferner kann die Konjunktion „oder“ verwendet werden, um Merkmale auszudrücken, die gleichzeitig vorhanden statt sich gegenseitige ausschließende Alternativen sind. Anders ausgedrückt, ist die Konjunktion „oder“ so zu verstehen, dass sie „und/oder“ einbezieht.
Unter Bezugnahme auf 5 sind Hardwarekomponenten 500 eines Fahrzeugs 110 allgemein dargestellt und veranschaulicht. Das Fahrzeug 110 kann ein PKW mit einem Verbrennungsmotor oder einem Elektromotor, einer Batterie, einem Lenkrad, Fenstern, Türen, Sicherheitsgurten, Reifen usw. sein. Das Fahrzeug 110 kann eine Limousine, ein Geländewagen, ein Motorrad oder ein LKW sein. Das Fahrzeug kann benzinbetrieben, dieselbetrieben, naturgasantrieben, hybrid oder elektrisch sein.
Das Fahrzeug 110 hat einen Hauptdatenbus 501, der einen oder mehrere Prozessoren funktionell verbindet, einen flüchtigen Speicher 503, wie beispielsweise einen Direktzugriffsspeicher 503, einen nichtflüchtigen Speicher 504, wie beispielsweise ein magnetisches Festplattenlaufwerk oder eine Festkörpervorrichtung, Stellantriebe 506, welche die Bewegung von elektromechanischen Fahrzeugkomponenten, wie beispielsweise das Getriebe oder Kraftstoffeinspritzdüsen, steuern, und lokale Sensoren 505, die so ausgelegt, dass sie Dimensionen von Ereignissen messen, die in dem und um das Fahrzeug eintreten. Beispiele für lokale Sensoren 505 umfassen Motortemperatursensoren Umgebungstemperatursensoren, Fahrgastraumtemperatursensoren, Motor-U/MIN-Sensoren, Batterietemperatursensoren, Batterieladestandsensoren, Geschwindigkeitssensoren usw. Die Sensoren können digital oder analog sein.
Das Fahrzeug 110 kommuniziert drahtlos über eine Telematiksteuereinheit (TCU) 550, die als ein Modem für das Fahrzeug fungiert. Wie in 5 dargestellt, kann die TCU 550 mit dem Hauptdatenbus 501 funktionell verbunden sein. Die TCU ist eine eigenständige Verarbeitungsbaugruppe mit einem TCU-Datenbus 551, der mit TCU-Prozessoren 552 funktionell verbunden ist, einem flüchtigen TCU-Speicher 553, einem nichtflüchtigen TCU-Speicher 554 und Antennen 555. Der TCU-Speicher kann eine Mehrzahl von hartcodierten Telematikprotokollen umfassen. Die Hardwarekonfiguration einer TCU ist auf dem Fachgebiet bekannt und wird zum Beispiel in der US-Veröffentlichung Nr. 2007/0055414 offenbart, die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen wird.
Während des Normalbetriebs messen verschiedene lokale Sensoren 505 Bedingungen in dem und um das Fahrzeug. Die lokalen Sensoren geben einen Strom von serialisierten Daten an den Fahrzeugdatenbus 501 aus, die (a) den Sensor identifizieren und (b) eine Messung oder eine Dimension umfassen. Geeignete lokale Fahrzeugsensoren sind auf dem Fachgebiet bekannt und gegenwärtig in Verbraucherfahrzeugen vorhanden.
Zurück zur TCU können die eine oder die mehreren TCU-Antennen 555 so ausgelegt sein, dass sie Drahtlossignale erzeugen und empfangen, die eine drahtlose Verbindung über ein oder mehrere Dienstzustellnetze ermöglichen. Die Netze können zellulare Verbrauchernetze sein, wie beispielsweise jene, die bekannten Funknetzbetreiber, darunter AT&T, Verizon, T-Mobile usw., gehören und von diesen betrieben werden. Die Netze können proprietäre Drahtlosnetze oder Netze zwischen Fahrzeugen sein. Geeignete Antennen sind im Handel erhältlich und auf dem Fachgebiet bekannt.
Die TCU 550 umfasst Telematikprotokolle, die zur Ausführung auf dem TCU-Prozessor im TCU-Speicher gespeichert sind. Die Telematikprotokolle sind so ausgelegt, dass sie Daten empfangen, die zur Übertragung an eine externe Quelle gekennzeichnet sind, und dann die Daten in eine Serie von Bits umsetzt, die zur Übertragung als Signale oder Wellen über die eine oder die mehreren Antennen 555 geeignet sind. Wie bereits erwähnt, können die Telematikprotokolle in den TCU-Speicher hartcodiert sind.
Nunmehr unter Hinwendung zu 1 ist ein Verfahren zur dynamischen Aktualisierung von Software, die auf der TCU 550 ausgeführt oder gespeichert wird, allgemein dargestellt und veranschaulicht. Eine Person gibt Daten in eine Webdienstmerkmal-Benutzer-Schnittstelle 101 ein. Die Webdienstmerkmal-Benutzer-Schnittstelle 101 wird in Reaktion darauf angezeigt, dass eine Person auf ein Computerprogramm, wie beispielsweise eine Website, zugreift. Die Person gibt Daten, wie beispielsweise Skriptcodezeilen, unstrukturiert in die Webdienstmerkmal-Benutzer-Schnittstelle ein. Unstrukturierte Daten sind typischerweise vom Menschen lesbare Rohinformationen. Zum Beispiel handelt es sich bei dem Text dieser Patentanmeldung um unstrukturierte Daten. Strukturierte Daten sind dagegen gemäß bestimmten logischen Regeln organisiert. Strukturierte Daten sind typischerweise maschinenlesbar.
Zurück zu 1 setzt die Webdienstmerkmal-Benutzer-Schnittstelle 101 die unstrukturierten Daten in strukturierte oder maschinenlesbare Daten um. Zum Beispiel kann eine Person eine Zeile von Code eingeben, der zur Ausführung im Fahrzeug bestimmt ist. Die Benutzerschnittstelle 101 strukturiert diese Daten dann so, dass sie dem Satz von logischen Regeln folgen, die durch andere Software gelesen und implementiert werden können.
Der Webdienstmerkmals-Protokollpuffer 102 empfängt die strukturierten Daten und setzt sie in serialisierte Daten um. Serialisierte Daten können im Bitformat ausgedrückt sein, das es ermöglicht, die serialisierten Daten auf einem Computer zu speichern oder zwischen Computern als eine Serie von physikalischen elektrischen (oder magnetischen) Signalen oder Impulsen zu übertragen. In einer Ausführungsform der vorliegenden Erfindung ist der Protokollpuffer 102 ein Google-Protokollpuffer (GPB). In verschiedenen Ausführungsformen funktioniert der Puffer 102 als eine API für die TCU 550. Genauer gesagt, ist der Protokollpuffer 102 so ausgelegt, dass er serialisierte Daten, wie beispielsweise Codezeilen, zur Ausführung durch die TCU an die TCU sendet. Der Protokollpuffer 102 ist außerdem so ausgelegt, dass er Daten, die von der TCU gesendet werden, in eine benutzerspezifische Datenstruktur deserialisiert. Zusätzliche Merkmale des GPBs werden im Leitfaden für GPB-Entwickler beschrieben, der auf developers.google.com/protocol-buffers/docs/techniques verfügbar ist und hiermit durch Bezugnahme in seiner Gesamtheit aufgenommen wird.
Unter Bezugnahme auf 1 kann der Protokollpuffer 102 die strukturierten Daten an andere Anwendungen 108 senden, die auf dem gleichen Server wie der Protokollpuffer ausgeführt werden. Die anderen Anwendungen 108 können die Daten zur Übertragung an externe Server serialisieren, die eine Daten-Cloud 109 hosten.
Nach dem Serialisieren der strukturierten Daten sendet der Protokollpuffer 102 die serialisierten Daten über ein Dienstzustellnetz 103 an ein Fahrzeug 110 und insbesondere an die TCU 550. Dienstzustellnetze umfassen zellulare Verbrauchernetze, wie beispielsweise jene, die bekannten Funknetzbetreiber, darunter AT&T, Verizon, T-Mobile usw., gehören und von diesen betrieben werden.
Das Fahrzeug 110 empfängt die serialisierten Daten als elektrische Signale oder Impulse über das TCU-Modem 104, das die TCU-Antenne 555 umfasst, und Programme, die im TCU-Speicher gespeichert und auf dem TCU-Prozessor 552 ausgeführt werden. Das TCU-Modem decodiert die physikalischen Signale oder Impulse, die an der Antenne empfangen werden, in maschinenlesbare serialisierte Daten. In verschiedenen Ausführungsformen umfasst die TCU-Antenne 555 einen dedizierten Prozessor und Speicher.
Das maschinenlesbare Bitformat ist eine Kopie der serialisierten Daten, die vom Webdienstmerkmals-Protokollpuffer 102 über das Dienstzustellnetz 103 gesendet werden. Um mit den Daten zu interagieren, deserialisiert die TCU die Serie von Bits durch einen Protokollpuffer, der im TCU-Speicher 553 und 554 gespeichert ist und auf dem TCU-Prozessor 552 ausgeführt wird, in strukturierte Daten. Der TCU-Protokollpuffer kann das gleiche Serialisierungsprogramm oder die gleiche Serialisierungssoftware wie der Webdienstmerkmals-Protokollpuffer 102 umfassen. Durch Deserialisieren der Daten repliziert der TCU-Protokollpuffer 105 die strukturierten Daten, die ursprünglich am Webdienstmerkmals-Protokollpuffer 102 serialisiert wurden.
Die TCU bildet eine virtuelle Maschine mit den deserialisierten Daten, die vom TCU-Modem 104 empfangen werden. Genauer gesagt, umfassen die deserialisierten Daten ein Skript zur Ausführung auf der TCU. Software, die im Voraus in den TCU-Speicher geladen wurde, wie bereits erwähnt, ist so ausgelegt, dass sie das Skript auf dem TCU-Prozessor ausführt und dadurch die virtuelle Maschine erstellt.
6 veranschaulicht ein Blockdiagramm dessen, wie das Skript mit der Hardware und der im Voraus geladenen Software im Fahrzeug interagiert. Genauer gesagt, umfasst das Fahrzeug Hardware 604, wie beispielsweise die TCU-Hardware, die in 5 veranschaulicht ist. TCU-Firmware 603 (oder ein TCU-Betriebssystem) ist im Voraus in das Fahrzeug geladen und so ausgelegt, dass sie sich über eine Schnittstelle mit der TCU-Hardware 604 koppeln lässt. Ein Interpreter 602 ist ebenfalls im Voraus auf die TCU geladen und so ausgelegt, dass er das Lua-Skript in Anweisungen übersetzt, die von der Firmware 603 gelesen werden können. Die Interaktion eines Lua-Skripts mit Firmware ist auf dem Fachgebiet allgemein bekannt und wird zum Beispiel in der US-Veröffentlichung Nr. 2007/0046821 beschrieben, die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen wird.
2 veranschaulicht verschiedene Operation von Codezeilen des Skripts 601, wie beispielsweise des Lua-Skripts. Jede Codezeile 200 kann eines oder mehrere eines Quellmoduls 201, eines Bearbeitungsmoduls 202 und eines Übergangsmoduls 203 umfassen. Das Quellmodul 201 identifiziert einen oder mehrere spezifische Sensoren und die Struktur der Sensordaten. Das Bearbeitungsmodul 203 umfasst mathematische Operationen, welche die TCU-Hardware an der Eingabe von den spezifischen Sensoren durchführt. Das Übergangsmodul 204 identifiziert, wie das Skript auf Ausgaben des Manipulationsmodul 203 reagiert.
3 ist ein Blockdiagramm einer mit den Codezeilen 200 erzeugten virtuellen Maschine 300. Bei 301 empfängt die virtuelle Maschine Daten von spezifischen Sensoren (gemäß dem Quellmodul 201) in einem spezifischen Format oder einer spezifischen Struktur. Bei 302 führt die virtuelle Maschine Operationen an den empfangenen Daten gemäß Anweisungen im Bearbeitungsmodul 202 durch. Bei 303 gibt die virtuelle Maschine neue strukturierte Daten aus. Bei 304 wendet die virtuelle Maschine Code oder Funktionen im Übergangsmodul 204 auf die neuen strukturierten Daten an, um ein oder mehrere Ergebnisse zu erzeugen.
3 stellt mögliche Ergebnisse 305 bis 310 dar. Die Ergebnisse können die virtuelle Maschine veranlassen, Daten an einem spezifischen Ort im TCU-Speicher zu speichern, Daten zu verwerfen, Daten über das TCU-Modem zu senden oder spezifische Zeilen von Skripterstellungscode auszuführen. Das Lua 5.3 Bedienungshandbuch, das hiermit durch Bezugnahme in seiner Gesamtheit aufgenommen wird, umfasst eine vollständigere Beschreibung der Arten von Skripterstellungsoperationen, die in Lua möglich sind.
Unter Bezugnahme auf 1 kehren die neuen strukturierten Daten als serialisierte Daten über den TCU-Protokollpuffer 105, das TCU-Modem 104 und das Dienstzustellnetz 103 zum Webdienstmerkmals-Protokollpuffer 102 zurück. In verschiedenen Ausführungsformen ist die TCU so ausgelegt, dass sie die Daten nur am Ende eines Fahrzyklus über das Dienstzustellnetz sendet (oder nur mit dem Protokollpuffer 102 serialisiert). Mit anderen Worten ist die TCU so ausgelegt, dass sie (a) die strukturierten Daten oder (b) die serialisierten strukturierten Daten lokal speichert, bis die TCU ein Ende eines Fahrzyklus erkennt. Die TCU kann das Ende des Fahrzyklus unter Bezugnahme auf eines oder mehreres von einer Position des Fahrzeugschlüssels, der Gegenwart eines Fahrers auf dem Fahrersitz, der Verfügbarkeit eines bestimmten Netzes (d. h. Erkennung eines WiFi-Heimnetzes) oder einem aktuellen Zustand des Fahrzeugmotors (z. B. aktiv oder inaktiv) erkennen.
Es versteht sich, dass der Webdienstmerkmals-Protokollpuffer 102 Daten, die von der Webdienstmerkmal-Benutzer-Schnittstelle 101 empfangen werden, mit Anweisungen ergänzen kann, die von anderen Anwendungen 108 empfangen werden. Die anderen Anwendungen 108 können mit Datenbanken, die in der Cloud 109 gespeichert sind, in Kommunikation sein. Ähnlich kann der Webdienstmerkmals-Protokollpuffer 102 Daten, die vom Fahrzeug 110 empfangen werden, sowohl an die Webdienstmerkmal-Benutzer-Schnittstelle 101 als auch an andere Anwendungen 108 melden, die mit der Cloud 109 verbunden sind.
Zurück zu 4 ist ein Verfahren zum Installieren einer neuen virtuellen Maschine in einem Fahrzeug mit einem Blockdiagramm 400 allgemein dargestellt und veranschaulicht. Ein Webdienstmerkmal 401 stellt ein Programm dar, das auf einem entfernten Computer ausgeführt wird. Ein Dienstzustellnetz 402 ist ein drahtloses Netz, das zum Zustellen von Daten vom entfernten Computer an ein Fahrzeug ausgelegt ist. Eine Telematiksteuereinheit (TCU) 403 ist in ein Fahrzeug, wie beispielsweise das Fahrzeug 110, geladen. Eine Firewall 404 überwacht und kontrolliert Verkehr, der zwischen dem Webdienstmerkmal und der Fahrzeug-TCU 403 fließt.
In einem Beispiel funktioniert das System, wie folgt. Das Webdienstmerkmal bereitet bei 405 eine Meldung vor, welche die TCU anweist, ein Paket zu erwarten, das eine neue virtuelle Maschine 200 definiert. Das SDN leitet die Meldung bei 406 an die TCU weiter. Die TCU verarbeitet die Meldung und bestimmt bei 407, dass sie bereit ist, eine neue virtuelle Maschine anzunehmen. Die TCU sendet den Bereit-Status bei 408 durch das TCU-Modem an das SDN. Das SDN leitet den Bereit-Status bei 409 an das Webdienstmerkmal weiter.
Das Webdienstmerkmal antwortet bei 410 mit serialisierten Daten, die eine neue virtuelle Maschine definieren. Das SDN leitet die Daten bei 411 an die TCU weiter. Bei 412 deserialisiert die TCU die Daten, was zu strukturierten Daten führt, die das Skript verkörpern. Unmittelbar danach lädt die TCU das Skript in den Speicher und bereit die Erzeugung der virtuellen Maschine vor.
Danach sendet die TCU bei 413 eine Bestätigung durch das SDN. Das SDN leitet die Bestätigung bei 414 an das Webdienstmerkmal weiter. Eine Person oder Software, die auf dem Webdienstmerkmal ausgeführt wird, weist die TCU bei 415 an, die virtuelle Maschine auszuführen. Das SDN leitet die Anweisung bei 416 an die TCU weiter. Die TCU führt die virtuelle Maschine bei 417 aus und sendet bei 418 und 419 eine Bestätigung an das Webdienstmerkmal.
Bei 420 und 421 weist eine Person oder Software, die auf dem Webdienstmerkmal ausgeführt wird, die TCU an, die Ausführung der virtuellen Maschine zu beenden. Bei 422 beendet die TCU die Ausführung der virtuellen Maschine. Bei 423 und 424 bestätigt die TCU, dass die virtuelle Maschine deaktiviert ist.
Es versteht sich, dass der Begriff „TCU“ für die Zwecke der Ansprüche hierdurch so definiert ist, dass er „Telematiksteuereinheit, umfassend eine oder mehrere Antennen, einen oder mehrere Prozessoren und Speicher“ bedeutet. Es versteht sich ferner, dass der Begriff „geladenes Fahrzeug“ für die Zwecke der Ansprüche so definiert ist, dass er bedeutet: „Fahrzeug, umfassend: einen Motor, der ein oder mehrere Räder antreibt, Bremsen für die Räder, ein Lenksystem, das zum Anpassen der Richtung mindestens eines der Räder ausgelegt ist, eine Quelle von gespeicherter Energie, die zum Antreiben des Motors ausgelegt ist, einen oder mehrere Prozessoren, Speicher und lokale Fahrzeugsensoren, die zum Melden von Messungen an die Prozessoren ausgelegt sind“.
Die vorstehend beschriebenen Ausführungsformen und insbesondere jegliche bevorzugten Ausführungsformen sind mögliche Beispiele von Implementierungen und dienen lediglich einem besseren Verständnis der Prinzipien der Erfindung. Es können viele Abänderungen und Modifikationen an der/den zuvor beschriebenen Ausführungsform(en) vorgenommen werden, ohne im Wesentlichen vom Wesen und den Prinzipien der hierin beschriebenen Techniken abzuweichen. Alle Modifikationen sollen in den Schutzbereich dieser Offenbarung fallen und durch die folgenden Ansprüche geschützt werden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2007/0055414 [0016]
US 2007/0046821 [0028]

Claims

Telematiksteuersystem, umfassend: einen externen Server, der so ausgelegt ist, dass er ein Skript mit einem externen Protokollpuffer serialisiert und das serialisierte Skript an eine TCU sendet; ein Fahrzeug mit Sensoren und der TCU, wobei die TCU ausgelegt ist zum: Deserialisieren des Skripts mit einem TCU-Protokollpuffer, Ausführen des Skripts durch einen im Voraus in die TCU geladenen Interpreter, Speichern von Daten von den Sensoren basierend auf dem Skript.
System nach Anspruch 1, wobei die TCU ausgelegt ist zum: Senden der gespeicherten Sensordaten an den TCU-Protokollpuffer.
System nach Anspruch 2, wobei die TCU ausgelegt ist zum: Serialisieren der gespeicherten Sensordaten mit dem TCU-Protokollpuffer und Senden der serialisierten Daten durch die Antenne über ein Inhaltszustellnetz.
System nach Anspruch 3, wobei der externe Server so ausgelegt ist, dass er die serialisierten Sensordaten empfängt und die serialisierten Sensordaten durch den externen Protokollpuffer in strukturierte Daten deserialisiert.
System nach Anspruch 1, wobei die TCU so ausgelegt ist, dass sie basierend auf dem Skript eine virtuelle Maschine bildet.
System nach Anspruch 5, wobei die TCU so ausgelegt ist, dass sie Operationen an Daten, die von den Fahrzeugsensoren gesendet werden, mit der virtuellen Maschine durchführt, um einen Satz von strukturierten Daten zu erzeugen.
System nach Anspruch 6, wobei die virtuelle Maschine so ausgelegt ist, dass sie den Satz von strukturierten Daten beurteilt und sich angesichts der Beurteilung selbst aktualisiert.
System nach Anspruch 7, wobei die virtuelle Maschine so ausgelegt ist, dass sie sich angesichts der Beurteilung selbst aktualisiert, indem sie zu einer Codezeile im Skript springt, wobei die Position der Codezeile im Skript auf der Beurteilung des Satzes von strukturierten Daten basiert.
System nach Anspruch 2, wobei die TCU so ausgelegt ist, dass sie die Übertragung nur am Ende eines Fahrzyklus durchführt, und die TCU mit einer Mehrzahl von Telematikprotokollen hartcodiert ist.
System nach Anspruch 1, wobei der Interpreter, aber nicht das Skript, auf die TCU hartcodiert ist.
Verfahren zur Steuerung einer Telematiksteuereinheit (TCU) in einem Fahrzeug mit Sensoren, wobei die TCU eine Antenne, einen Prozessor und Speicher umfasst, und das Verfahren umfasst: Serialisieren eines Skripts mit einem externen Server-Protokollpuffer, Senden des serialisierten Skripts an die TCU, Deserialisieren des Skripts mit einem TCU-Protokollpuffer, Ausführen des Skripts durch einen im Voraus in die TCU geladenen Interpreter, Speichern von Daten von Fahrzeugsensoren basierend auf dem Skript.
Verfahren nach Anspruch 11, ferner umfassend: Ausführen des Skripts durch den im Voraus in die TCU geladenen Interpreter, um die gespeicherten Daten an den TCU-Protokollpuffer zu senden.
Verfahren nach Anspruch 12, ferner umfassend: Serialisieren der gespeicherten Sensordaten mit dem TCU-Protokollpuffer; Senden der serialisierten Sensordaten über die Antenne.
Verfahren nach Anspruch 13, ferner umfassend: Empfangen der serialisierten Sensordaten am externen Protokollpuffer; Deserialisieren der serialisierten Sensordaten mit dem externen Protokollpuffer in strukturierte Daten.
Verfahren nach einem der Ansprüche 11 bis 14, ferner umfassend: Bilden einer virtuellen Maschine auf der TCU mit dem Skript.
Verfahren nach Anspruch 15, ferner umfassend: Durchführen von Operationen an Daten, die von den Fahrzeugsensoren gesendet werden, mit der virtuellen Maschine, um einen Satz von strukturierten Daten zu erzeugen.
Verfahren nach Anspruch 16, ferner umfassend: Beurteilen des Satzes von strukturierten Daten mit der virtuellen Maschine; Aktualisieren der virtuellen Maschine angesichts der Beurteilung.
Verfahren nach Anspruch 17, wobei das Aktualisieren der virtuellen Maschine angesichts der Beurteilung ein Springen zu einer Codezeile im Skript umfasst, wobei die Position der Codezeile im Skript von der Beurteilung des Satzes von strukturierten Daten abhängt.
Verfahren nach einem der Ansprüche 12 bis 18, wobei die TCU so ausgelegt ist, dass sie die Übertragung nur am Ende eines Fahrzyklus durchführt, und die TCU mit einer Mehrzahl von Telematikprotokollen hartcodiert ist.
Verfahren nach Anspruch 11, wobei der Interpreter, aber nicht das Skript, auf die TCU hartcodiert ist.