-
Die
Erfindung betrifft ein Verfahren und eine Vorrichtung zur rechnergestützten
Verarbeitung von Daten, insbesondere Konfigurationsdaten, für
einen oder mehrere Telematik-Dienste in einem Kraftfahrzeug.
-
In
einem Kraftfahrzeug müssen zur Bereitstellung von Telematik-Diensten
Daten bereitgestellt werden, welche Informationen beispielsweise über
die Herstellung eines Verbindungsaufbaus zu einem Rechner eines Dienstanbieters,
Portalzugangsdaten, Fahrzeug-Profile, Konfigurationsparameter und
dergleichen umfasst. Da in einem Kraftfahrzeug die Ressourcen der
darin verbauten Rechner (sog. Steuergeräte) hinsichtlich
ihrer Rechenleistung und ihrer Speicherkapazität begrenzt
sind, müssen die Daten derart vorgehalten werden, dass diese
einen möglichst geringen Speicherbedarf aufweisen und der
Zugriff auf diese mit möglichst geringer Rechenleistung
erfolgen kann. Eine effiziente Speicherung der Daten ist auch notwendig,
um bei Abfragen bestimmter Daten die Antwortzeiten bis zum Erhalt
der erwünschten Daten möglichst gering zu halten.
Um eine möglichst hohe Performance der in einem Kraftfahrzeug
verbauten Rechner ermöglichen zu können, ist es deshalb
wünschenswert, dass möglichst viele oder sogar
alle der verbauten Rechner auf die gespeicherten Daten zugreifen
können. Damit dieser gemeinsame Zugriff gewährleistet
werden kann und damit der Speicherbedarf begrenzt werden kann, ist
die Unterstützung von einem gemeinsam verständlichen
Datenformat notwendig, wodurch auch multiples Kopieren ein und desselben
Datensatzes in unterschiedlichen Formaten vermieden wird.
-
Es
ist daher Aufgabe der vorliegenden Erfindung, ein Verfahren und
eine Vorrichtung zur rechnergestützten Verarbeitung von
Daten, insbesondere Konfigurationsdaten, für einen oder
mehrere Telematik-Dienste in einem Kraftfahrzeug anzugeben, welche
die oben genannten Anforderungen erfüllen.
-
Diese
Aufgabe wird gelöst durch ein Verfahren mit den Merkmalen
des Patentanspruches 1 bzw. eine Vorrichtung mit den Merkmalen des
Patentanspruches 19. Die Aufgabe wird ferner gelöst durch
ein Computerprogrammprodukt mit den Merkmalen des Patentanspru ches
18. Vorteilhafte Ausgestaltungen sind jeweils in den abhängigen
Patentansprüchen wiedergegeben.
-
Die
Erfindung schafft ein Verfahren zur rechnergestützten Verarbeitung
von Daten, insbesondere Konfigurationsdaten, für einen
oder mehrere Telematik-Dienste in einem Kraftfahrzeug. Erfindungsgemäß werden die
Daten in einer hierarchischen Datenstruktur (d. h. Daten-Baum) in
einem ersten vorgegebenen Datenformat bereitgestellt. Das Bereitstellen
der Daten in dem ersten Datenformat kann beispielsweise auf einem Rechner
des Anbieters des Telematik-Dienstes erfolgen. Die Daten werden
dann von dem ersten Datenformat in ein zweites Datenformat überführt,
in dem die Daten in einer oder mehreren tabellarischen Datenstrukturen angeordnet
werden, die die Inhalte des ersten Datenformats beinhalten, jedoch
nicht mehr die hierarchische Struktur. Diese werden in dem Kraftfahrzeug
zur weiteren Verarbeitung zur Verfügung gestellt. Schließlich
werden die in dem zweiten Datenformat enthaltenen Daten in einer
textuellen Datenstruktur als lesbares Format oder als persistente
Datenbank wiedergegeben.
-
Gemäß einer
Ausgestaltung des erfindungsgemäßen Verfahrens
werden die Daten in dem ersten Datenformat gemäß einer
XML(eXtensible Markup Language)-Spezifikation, d. h. im XML-Format,
bereitgestellt. Dabei liegen die Daten in der hierarchischen Datenstruktur
vor. Die tabellarische Datenstruktur wird daraus generiert und in
dem Kraftfahrzeug zur Verfügung gestellt. Eines der meist
verwendeten Kommunikationssysteme im automobilen Infotainment Bereich
ist das MOST (Media Oriented Systems Transport) 0. MOST ist eine fahrzeugspezifische
Architektur für Meta-Daten und Medienübertragung.
Daher entsprechen die generierten Datenstrukturen Objekte, die über
MOST übertragbar sind und in den unterschiedlichen Kraftfahrzeug-Rechner
verwendbar sind.
-
Die
Anpassung des allgemeinen XML Formats an die für den Fahrzeug übliche
MOST Technologie ermöglicht, dass Rechner des Kraftfahrzeugs
direkt auf die Daten zugreifen können, so dass eine große
Performanz ohne Zwischenformatierung und Zwischenspeicherung der
Daten erzielt werden kann. Ferner ist es aufgrund der Rechenleistung
und der speziellen Betriebssysteme im Fahrzeug ist es auch nicht
möglich Standard-XML-Hilfwerkzeuge zu benutzen, da die
Fahrzeugumgebung dafür nicht geeignet bzw. nicht performant genug
ist. Zum Beispiel erfordert die Verwendung von DOM-Parsern (beschrieben
in 0 und 0) eine Zwischendarstellung als Objekt-Baum. Ein Standard-XML- Validierer
erfordert das Laden eines zusätzlichen Models für die
Datenverarbeitung und Gültigkeitsüberprüfung
des Instanzdatensatzes. Daher basiert diese Erfindung nur auf der
Nutzung eines simplen SAX-basierten Parsers (beschrieben in 0 und
0) ohne XML-Validierung unter Verwendung von darunter beschriebenen
heuristischen Verfahren.
-
Die üblichen
bekannten XML Gültigkeitsüberprüfungsformen
umfassen entweder eine Komplettvalidierung des Daten-Baumes oder
gar keine Validierung. Allerdings, um das Zielformat auf MOST zu
erreichen, ist ein Mindestmass an Gültigkeitsüberprüfung
notwendig. Um zu umgehen, die üblicherweise notwendige Komplettvalidierung
von im XML-Format vorliegenden Daten vornehmen zu müssen,
ist gemäß einer weiteren Ausgestaltung vorgesehen,
die Daten in dem ersten vorgegebenen Datenformat in ein vorgegebenes
Datenmodell, das eine im Voraus bekannte Datenstruktur aufweist,
abzubilden. Insbesondere umfasst das Datenmodell ein oder mehrere
Konfigurationen, denen jeweils eine oder mehrere semantische Datenblöcke
zugeordnet werden können. Solange die Daten noch in dem
ersten Datenformat, d. h. gemäß XML-Spezifikation, vorliegen,
werden für jede Konfiguration auf dem Rechner eines Dienstanbieters
zweckmäßigerweise ein oder mehrere XML-Instanzdokumente
bereitgestellt. Bei Bedarf werden sie über Internettechnologien
auf den Fahrzeugrechner des Dienstnutzers übertragen. Angekommen
im Fahrzeugrechner, müssen die Daten für die interne
Konfiguration der Fahrzeugsteuergeräte für Telematikdienste
aufbereitet werden. Die einzelnen Datenblöcke der Konfiguration
weisen eine spezifische Struktur auf, die entsprechend tabellarisch
darstellbar ist. Das erfindungsgemäße Verfahren
weist den Vorteil auf, dass nach der Transformation in das zweite
Datenformat, bei dem die Daten in der tabellarischen Datenstruktur
angeordnet sind, die Mehrzahl an ursprünglichen XML Dokumenten
nicht mehr benötigt wird, so dass die Verarbeitung in dem
Kraftfahrzeug erheblich vereinfacht ist. Darüber hinaus
wird die Validierung der Daten vereinfacht, dadurch dass der heuristische
Validierer nur eine konkrete Erkennung der XML Elemente am XML-Baum-Wurzel-Bereich
benötigt. Der restliche Datenblock kann abgespalten werden.
Die Aufbereitung basiert nur auf der Tiefe der Sub-Bäume.
Dieses heuristische Verfahren wird in dieser Beschreibung als „Partielle
Validierung” bezeichnet.
-
Da
die Datenblöcke formale Darstellungen von ISO-OSI 0 Lagers
2–3 (Connectivity) und Lagers 4–7 (Services) sind,
weisen sie spezifische, im Voraus bekannte, Strukturen auf, die
als Strukturierungsmodell für MOST Objekte spezifizierbar
sind. Insbesondere umfasst einer der Datenblöcke Verbindungsdaten
und/oder einen Verbindungsaufbau betreffende Daten. Dieser Datenblock
wird auch als „Connectivity” oder Verbindungs-Objekt
bezeichnet. Einer der Datenblöcke umfasst gemäß einer
weiteren Ausführungsform Dienste und/oder Dienstmerkmale
betreffende Daten. Dieser Datenblock wird auch als „Services” oder
Dienste-Objekt bezeichnet. Ein weiterer der Datenblöcke
umfasst Beschränkungen betreffende Daten. Dieser wird auch
als „Constraints” oder Beschränkungen-Objekt
bezeichnet. Das Datenmodell, das vorzugsweise sämtliche
der genannten Datenblöcke umfasst, ermöglicht
bereits bei der Bereitstellung der Daten in dem ersten Datenformat eine
vereinfachte Administration. Darüber hinaus ermöglicht
es das Datenmodell nach der Überführung in das zweite
Datenformat und der Zurverfügungstellung in einer zu der
hierarchischen Datenstruktur korrespondierenden Datenstruktur in
dem Kraftfahrzeug einen vereinfachten Zugriff auf die Daten, welcher
insbesondere autark durch die Rechner des Kraftfahrzeugs vorgenommen
werden kann.
-
Die
Daten eines Datenblocks können gemäß einer
weiteren Ausgestaltung in einem oder in mehreren Sub-Datenblöcken
angeordnet und abgespeichert werden. Auf diese Weise ist eine weitere
Strukturierung der Daten möglich, wodurch der Datenzugriff
durch die Rechner des Kraftfahrzeugs weiter verbessert wird. Das heißt
die weitere Erkennung und Validierung der Konfigurationsdaten (bis
zu einzelnen Parametern und Werten im Modell) wird spezifisch in
den Telematik-Diensten und -Applikationen vorgenommen, die die eigentlichen
Nutzer der Konfigurationen sind. Dadurch ist die „Partielle
Validierung” auch eine Rechner- und Software-Modul-verteilte
Validierung, im Unterschied zu üblichen XML-Validierungsverfahren.
-
Auf
Grund der Modellkomplexität muss für Debugging-
und Diagnose-Zwecke die interne MOST Darstellung auch in menschenlesbarer
Form als Text wiederherzustellen sein. Die einzelnen Zeilen der
generierten Tabellen sind textuell als Links zu dem einzelnen Parameter
darstellbar. Gemäß einer weiteren Ausgestaltung
ist in dem zweiten Datenformat jedem Parameter und dem zugeordneten
Parameterwert eine Pfadangabe zugeordnet, wobei die Pfadangabe zumindest
einem Kennzeichner für den betreffenden Datenblock und den
oder die optionalen Sub-Datenblöcke umfasst. In dem tabellarischen
Datenformat wird somit jedem Parameter eines Datenblocks eine Pfadangabe
vorangestellt. Auf diese Weise ist es möglich, einerseits
die tabellarische Darstellung in Textform wieder herzustellen. Bei
Verwendung von XPath 0 als Basis für die Link-Darstellung
ist es möglich, Datenbankanfragen auf die MOST Objekte
durchzuführen.
-
Gemäß einer
weiteren Ausgestaltung werden die Daten in dem ersten vorgegebenen
Datenformat von einem ersten Rechner eines Rechnernetzwerks an einen
zweiten Rechner des Kraftfahrzeugs, insbesondere drahtlos, übertragen
und von dem zweiten Rechner des Kraftfahrzeugs in das zweite Datenformat überführt. Mit
anderen Worten bedeutet dies, dass die Übertragung der
Daten von dem Rechner des Dienst-Anbieters an das Kraftfahrzeug
in dem ersten Datenformat, insbesondere gemäß XML-Spezifikation,
erfolgt. Dies weist den Vorteil auf, dass die Datenübertragung
mit bekannten Übertragungsmechanismen erfolgen kann. Hierdurch
lässt sich bei der Übertragung eine hohe Effizienz
erzielen. Da die Verarbeitung der Daten in dem ersten Datenformat
für das Kraftfahrzeug jedoch hinderlich ist, wird durch
einen Rechner des Kraftfahrzeugs die Überführung
in das zweite Datenformat vorgenommen, welches die beschriebenen
Vorteile in der Verarbeitung bietet.
-
Insbesondere
wird nach der Überprüfung der Daten in das zweite
Datenformat überprüft, ob das Datenmodell gültig
ist. Die Überprüfung erfolgt anhand der tabellarischen
Datenstruktur. Dabei wird die Überprüfung des
Datenmodells nach einer, insbesondere nach jeder, Änderung
und/oder Ergänzung der Daten in dem ersten Datenformat
sowie anschließender Überführung in das
zweite Datenformat vorgenommen. Eine Änderung und/oder
Ergänzung der Daten kann dadurch vorgenommen werden, dass
entsprechende Parameter mit ihrem Parameterwert und der Pfadangabe
entweder den Daten im zweiten Datenformat hinzugefügt werden oder
ein sich verändernder Wert überschrieben wird.
Demgegenüber müssen Daten, die im XML-Datenformat vorliegen,
durch ein vollständiges Überschreiben des gesamten
XML-Dokuments aktualisiert werden. Hierdurch ist jedoch ein im Vergleich
zum erfindungsgemäßen Vorgehen erhöhter
Zeitaufwand für die Datenübertragung sowie für
die Verarbeitung der Daten in dem Kraftfahrzeug notwendig.
-
Die Überprüfung
des Datenmodells erfolgt auf einfache Weise dadurch, dass das Vorhandensein
zumindest eines der Kennzeichner eines der Datenblöcke überprüft
wird. Demgemäß ist es ausreichend, wenn die in
das zweite Datenformat überführten Daten lediglich
auf das Vorhandensein eines einzigen Kennzeichners eines der Datenblöcke überprüft
werden. Hierdurch kann die Überprüfung auf einfache
Weise und in kurzer Zeit erfolgen. Eine Überprüfung
der Konsistenz der Parameter bzw. Parameterwerte eines jeden Datums findet
zu diesem Zeitpunkt hingegen nicht statt.
-
Es
ist weiterhin vorgesehen, dass ein nicht validierender, Ereignis-basierter
Parser wie SAX0 und 0 zur Verarbeitung der Daten in dem Kraftfahrzeug
verwendet wird, welcher die Verarbeitung der Daten ohne vorherige
semantische Überprüfung vornimmt und nur die Struktur
der zu verarbeitenden XML-Instanzen überprüft
(Es wird nur eine „Wellformness” 0 0 Überprüfung
vorgenommen). Hierdurch kann die Effizienz und Performanz des Rechnersystems
in dem Kraftfahrzeug gesteigert werden, da die spezifische semantische Überprüfung
als verteilte Aufgabe zwischen mehreren Anwendungen und Rechnern
nach Bedarf vorgenommen wird (d. h. „Partielle Validierung”).
-
Gemäß einer
weiteren Ausgestaltung werden die Daten in dem zweiten Datenformat,
insbesondere in dem oder durch den gleichen oder einen zweiten Rechner,
in dem Kraftfahrzeug in einem dritten Datenformat abgebildet, das
eine textuelle Darstellung wiedergibt, welche als menschlichlesbares
Format angezeigt werden kann bzw. auf einem persistenten Medium
als Datenbank abgespeichert werden kann.
-
Von
der Erfindung ist ferner ein Computerprogrammprodukt umfasst, das
auf einem computergeeigneten Medium gespeichert ist und direkt in
den internen Speicher eines digitalen Rechners oder mehrerer miteinander
in Kommunikationsverbindung zueinander stehenden Rechnern geladen
werden kann und Softwarecodeabschnitte umfasst, mit denen die Schritte
des beschriebenen Verfahrens ausgeführt werden, wenn das Produkt
auf dem oder den Rechnern läuft.
-
Die
Erfindung schafft ferner eine Vorrichtung zur rechnergestützten
Verarbeitung von Daten, insbesondere Konfigurationsdaten, für
einen oder mehrere Telematik-Dienste in einem Kraftfahrzeug. Die
Vorrichtung umfasst ein erstes Mittel zur Bereitstellung der Daten
einer hierarchischen Datenstruktur in einem ersten vorgegebenen
Datenformat. Die Vorrichtung umfasst weiter ein zweites Mittel zur Überführung
der Daten in eine tabellarische Datenstruktur. Schließlich
umfasst die Vorrichtung ein drittes Mittel zur Bereitstellung der
in dem zweiten Datenformat enthaltenen Daten in eine textuelle Form.
-
In
einer zweckmäßigen Ausgestaltung kann die Vorrichtung
weitere Mittel zur Durchführung des oben beschriebenen
Verfahrens aufweisen.
-
Die
Erfindung wird nachfolgend näher anhand der Zeichnungen
erläutert. Es zeigen:
-
1 eine
schematische Darstellung des dem erfindungsgemäßen
Verfahren zu Grunde liegenden Vorgehens,
-
2 ein
erfindungsgemäßes Datenmodell zur Abbildung der
Daten, insbesondere Konfigurationsdaten, und
-
3 eine
schematische Darstellung einer Architektur zur teilweisen Validierung
der Daten.
-
1 zeigt
in einer schematischen Darstellung das der Erfindung zu Grunde liegende
Vorgehen. In einem Rechner 1, z. B. einem Rechner eines
Rechnernetzwerks eines Dienste-Anbieters, werden Daten, wie z. B.
Konfigurationsdaten, für einen oder mehrere Telematik-Dienste
in einer hierarchischen Datenstruktur in einem ersten vorgegebenen
Datenformat bereitgestellt. Es ist zweckmäßig,
wenn die Daten in dem ersten Datenformat als XML-Daten bereitgestellt
werden. Dies ist mit dem Bezugszeichen 4 gekennzeichnet.
Die in dem ersten Datenformat vorliegenden Daten werden über
eine Kommunikationsstrecke 3, die insbesondere drahtlos
ausgebildet ist, an einen Rechner 2 eines Kraftfahrzeugs übermittelt.
Durch den Rechner 2 werden die in der hierarchischen Datenstruktur
vorliegenden Daten des ersten Datenformats in ein zweites Datenformat 5 überführt,
in dem die Daten in einer tabellarischen Datenstruktur angeordnet
werden. Die Daten werden hierbei datenblockweise (BL1, BL2, BL3)
abgespeichert. Dabei werden die in dem zweiten Datenformat 5 enthaltenen Daten
dem Kraftfahrzeug zur weiteren Verarbeitung zur Verfügung
gestellt bzw. in einem dritten Format in textueller Datenform als
lesbares Format dargestellt.. Die Ausgestaltung der Datenstrukturen
wird weiter unten näher erläutert.
-
Das
Vorgehen wird nachfolgend näher beschrieben.
-
Telematik-Dienste
im automobilen Umfeld benötigen eine Kommunikation mit
einer die Dienste bereitstellenden Infrastruktur. Die Kommunikation
zwischen dem Rechner 2 des Kraftfahrzeugs und dem Rechner 1 der
Infrastruktur erfolgt dabei bevorzugt über drahtlose Kommunikationstechnologien.
Dabei ist insbesondere zu berücksichtigten, dass die entsprechenden
Dienste bzw. Applikationen mit unterschiedlichen Übertragungstechnologien
(z. B. CSD und GPRS in Verbindung mit GSM, UMTS usw.) und unter
unterschiedlichen Service-Providerumgebungen, wie z. B. Roaming,
verwendet werden können müssen. Der in dem Kraftfahrzeug verwendete
Rechner 2 muss deshalb zur Vermeidung einer Unterbrechung
eines ausgeführten Dienstes unterschiedliche Charakteristika
ausführen können. Insbesondere muss der Rechner
in der Lage sein, unterschiedliche Übertragungstechnologien
zu verwenden und Handover auszuführen. Im automobilen Umfeld
eingesetzte Telematik-Dienste müssen deshalb den Datenaustausch
mit der Netzwerkinfrastruktur in unterschiedlichen Konfigurationen
unterstützen (vgl. z. B. [1]).
-
Eine
Telematik-Anwendung umfasst drei Haupt-Konfigurationstypen, die
unterschiedlichen funktionellen Abstraktionen der Dienste zugeordnet
sind. Dies sind Verbindungskonfigurationen, Ende-zu-Ende-Performanz-Einstellungen
und diesbezügliche Beschränkungen. Die Beschränkungen
(Constraints) repräsentieren Verknüpfungen zwischen
Verbindungskonfigurationen (Connectivity) und den Ende-zu-Ende-Performanz-Konfigurationen
(end-to-end performance configuration), welche aufgrund von Hardware-Konfigurationen
und/oder Nutzererfordernissen und/oder Serviceprovidervereinbarungen
(Provider Service Level Agreement, SLA) mit den Nutzern festgelegt
sind (vgl. [1] bis [4]).
-
Hardware-Restriktionen
können beispielsweise die Verfügbarkeit eines
bestimmten NAD-Moduls, wie z. B. ein GSM- oder UMTS-Gerät,
sein. Eine Nutzer-Restriktion (user restriction) kann die Erlaubnis
umfassen, eine bestimmte Web-Adresse oder einen Telefonservice zu
aktivieren. Ein Provider-SLA kann z. B. festlegen, dass nur bestimmte Übertragungstechnologiearten
aktiviert werden können, obwohl ein NAD-Modul mehr oder andere
Technologien über die in der SLA genannten Technologien
unterstützen kann. Derartige Konfigurationen werden in
den Konfigurationsdaten eines Kraftfahrzeugs hinterlegt.
-
Dies
erfolgt erfindungsgemäß dadurch, dass die Daten
in einem vorgegebenen Datenmodell abgebildet werden. Dies ist schematisch
in 2 in einem UML-Klassen-Diagramm [9] dargestellt.
Das Modell kann alternativ auch durch eine Gruppe von Protokollen
reprä sentiert sein, bei dem Teile des Modells zu einem
Session-Layer-Protokoll und Teile zu einem daran angehängten
Presentation-Layer-Protokoll gehören. Dies ist beispielsweise
im Falle von SIP [11] und SDP [12] der Fall.
-
Das
Daten- oder Konfigurationsmodell umfasst eine Wurzel 10 („model
route”) mit einem eindeutigen Kennzeichner („model
ID”), welcher als Kennzeichner für das gesamte
Modell verwendet werden kann. Beispielsweise kann im Fall eines
im XML-Spezifikation vorliegenden Modells der Kennzeichner der Namensraum des
Schemas oder im Falle von DTD (Document Type Definition) der Name
des DTD-Modells sein. Eine zusätzliche Kennzeichnung des
Modells kann durch eine inhaltsbezogene Definition innerhalb eines
Protokolls erfolgen, welche das Konfigurationsmodell umfasst. Dies
ist beispielsweise in IANA MIME [13], SIP [11] und HTTP [14] beschrieben.
-
Das
Datenmodell kann eine oder mehrere vollständige Konfigurationen
umfassen, welche durch ein Konfigurations-Objekt 20 („configuration”)
repräsentiert ist. Das Konfigurations-Objekt 20 umfasst
ebenfalls einen Kennzeichner: „Config ID”. Jede
der Konfigurationen muss identifizierbar sein, um die Konfiguration
mit einer spezifischen Infrastruktur für die Kommunikation
in Verbindung bringen zu können. Für Telematik-Applikationen
können dies die Schichten 2 und/oder 3 des OSI-Referenzmodells
[10], Protokollidentifikation, wie z. B. GSM SIM [15] oder IP-Adressierung
[16], [17] oder die Identifikation der Provider-Infrastruktur über
DNS [18] sein.
-
Mit
dem Konfigurations-Objekt 20 sind ein Verbindungs-Objekt 21 („Connectivity”),
ein Dienste-Objekt 22 („Services”) und
ein Beschränkungen-Objekt 23 („Contraints”)
verbunden. Diese sog. „Kinder”- oder „Child”-Objekte
stellen die oben beschriebenen Klassen von Konfigurationen dar,
welche notwendig sind für eine vollständige Ende-zu-Ende-Performanz
eines Telematik-Dientes innerhalb einer spezifischen Technologie
und/oder einer Provider-Domaine. Jedes dieser Objekte 21, 22, 23 kann
wiederum ein oder mehrere „Child”-Konfigurationen
aufweisen:
Ein Zugangsdaten-Objekt 31 („access”)
mit einem Kennzeichner („access ID”) identifiziert
eine spezifische Zugangstechnologie und verwendet als Kennzeichner
beispielsweise den Namen der Technologie (z. B. CSD, GPRS, usw.).
Das Zugangsdaten-Objekt 31 ist zugehörig zu einem
Sub-Baum oder Sub-Tree (41), der die Parametrisierung der
Zugangs technologie beschreibt. Dies umfasst beispielsweise den Namen
eines Zugangsrechners zu einem Netzwerk, einem sog. Access Point
(APN), wie z. B. eine IP-Adresse oder eine Einwahlnummer oder einen
spezifischen Technologie-Performanzparameter, wie z. B. QoS-Parameter.
Diese Informationen werden verwendet, um das Telematik-System des
Kraftfahrzeugs zu konfigurieren, um eine Verbindung zur Schicht
2 und/oder 3 des OSI-Referenzmodells herzustellen.
-
Ein
Applikations-Objekt 32 („application”)
mit einem Kennzeichner („application ID”) identifiziert Schicht
3 und die Zugänglichkeit zu einer Ende-zu-Ende-Verbindung
eines Infrastruktur-Dienstes, wie z. B. ein www-Portal. Der dazugehörige
Sub-Tree 42 von Objekten beschreibt Parametrisierungen
der spezifischen Applikationen, wie z. B. www-Adressen und QoS-Servicezustände,
wie z. B. ein Retry-Intervall oder Protokoll-Time-outs.
-
Ein
Beschränkungen-Objekt 33 („constraint”)
mit einem Kennzeichner („contraint ID”) identifiziert
spezifische Verbindungen zwischen Zugangselementen oder Applikations-Elementen
sowie zwischen Zugangs- und Applikations-Elementen. Die Sub-Tree-Elemente 43 definieren
Konfigurationszustände zur Ausführung des Telematik-Dienstes
oder einer Klasse ähnlicher Applikationen.
-
Dieses
Datenmodell ermöglicht im Gegensatz zur Validierung eines
XML-Dokuments die teilweise Validierung der durch das Datenmodell
repräsentierten Daten. Die spezifische Anwendung für
eine partielle Validierung entsteht aus dem Fall verteilter Telematik-Applikationen,
bei denen unterschiedliche Geräte und Softwareteile der
Applikation durch dasselbe Modell konfiguriert werden müssen,
um Datenkonsistenz und Interoperabilität bereitstellen
zu können. Die einzelnen Geräte und Software-Sub-Systeme
rufen jedoch nur Teile des gesamten Modells für ihre spezifische
Konfiguration ab.
-
In
solchen Fällen kann der Zugang und die Validierung vollständiger
XML-Datenmodellteile nicht als Ganzes durchgeführt werden,
da entsprechende Sub-Systeme bestimmte Modellteile nicht verstehen
oder nicht verstehen dürfen, wenn sie nicht für
deren Zwecke notwendig sind.
-
Bei
der Erfindung ist deshalb vorgesehen, dass ein Rechner des Kraftfahrzeugs
zwar das vollständige Datenmodell erhält, dieses
jedoch in Datenblöcke aufspaltet, welche später als
busspezifische Modelle bereitgestellt werden. Insbesondere können
diese als MOST-spezifische Inhaltsmodelle bereitgestellt werden
[19]. Dies bedeutet, dass die Empfänger einer MOST-spezifischen
Repräsentierung des Datenmodells die Validierung auch selbst
durchführen können müssen.
-
Die
Softwarearchitektur zur lediglich teilweisen Überprüfung
der an das Fahrzeug übertragenen Daten ist in 3 dargestellt.
Die Architektur basiert auf einem sog. XML Non-Validating Parser 140.
Dieser verwendet klassische XML-Regeln zur Validierung, um die (Top-Level-)Struktur 160 des
Datenmodells zu überprüfen. Diese Regeln sind über
eine Konfigurationsmodell-Klasse 110 spezifiziert und entsprechen
einer semantischen Modellvalidierung. Die extrahierten Sub-Trees
können durch einen Validator 130 strukturell überprüft werden
(150), um eine Klassifikation von Daten vorzunehmen, bevor
eine Aufbereitung in ein für Bus-Zugriff geeignetes Format
erfolgt. Die Regeln für ein solches Vorgehen sind als „Modellteil”-Klassen 100 definiert.
Die Regeln für die Sub-Tree-Validierung folgen der natürlichen
Struktur des Sub-Modells, das der Telematik-Anwendung zugeordnet
ist.
-
Beispielsweise
können eine Applikation und seine Parameter einen zweistufigen
Sub-Tree darlegen, um das Modell in eine Applikation (als „Parent”-Element),
seine Parameter (als „Child”-Element) und die
Parameterwerte (als Elementwerte) aufzuteilen.
-
Eine
allgemeinere Definition einer strukturellen Überprüfungsregel
ist z. B. „Ein Element weist mindestens ein „Child”-Element
und mindestens ein „Grand-Child”-Element auf,
wobei das „Grand-Child”-Element keinen leeren
Wert umfasst. Keines der Elemente in der Struktur hat keine Attribute”.
Solche Spezifikationen definieren zusätzliche Restriktionen
zu einem vordefinierten XML-Infoset [20]. Ein XML-Infoset definiert
die Regeln für die klassische „XML-Wellformness” und
die Gültigkeitsbestätigung von Belegdokumenten.
Solche Regeln können durch die Wiederverwendung von XML-Schemaspezifikationen
definiert werden. Die Interpretation einer strukturellen Validierung
betrifft nur die Form des Baums, jedoch nicht seiner Inhalte (vgl.
ebenfalls Synthetic Infoset [20]).
-
Die
klassische XML-Repräsentation weist eine verschachtelte
Struktur auf. Dies bedeutet, sie hat ein Start- und ein Ende-Element,
das Inhalte von Child- und/oder Grand-Children-Definitionen „einwickelt”.
Dies ist nachfolgend exemplarisch dargestellt.
-
-
In
einer Software-Entität werden solche Inhalte üblicherweise
als ein Objektbaum repräsentiert. Die Übertragung
von Objektbäumen oder Sub-Trees kann im Falle von Applikationen,
die das gemeinsame XML-Konfigurationsmodell teilen, heikel sein,
da die Anordnung/Entpackung (deserialization) von Inhalten notwendig
ist, um die Daten für unterschiedliche Softwareentitäten
und unterschiedliche Transportmedien zu repräsentieren.
-
Es
ist natürlich möglich, dass XML Inhalte auch über
MOST übertragen werden, allerdings setzt diese Möglichkeit
voraus, dass jede Einheit, die die Daten verwenden will über
XML Parser und Generator verfügt. Aus diesem Grund greift
die Erfindung auf eine tabellarische Datenstruktur von XML-Inhalten
zurück, die die Daten in ähnlicher zu den MOST
Dynamic Arrays 0 Form überführt. Jede einzelne
Tabelle stellt einen Konfigurationsblock dar. Allerdings ist diese
tabellarische Form nicht ohne weiteres lesbar bzw. persistent abzuspeichern.
-
Aus
diesem Grund greift die Erfindung auf eine lineare Datenstruktur
von XML-Inhalten zurück, bei denen als Separator der sog.
XPaths einzelner Elementinhalte die Struktur „<&>” verwendet
wird, wie dies nachfolgend dargestellt ist:
/xml/configuration/connectivity/conn1/[accessnr=+1234567890]<&>
/xml/configuration/connectivity/conn1/[user=myFunnyUser]<&>
/xml/configuration/connectivity/conn1/[pwd=myFunnyPWD]<&>
/xml/configuration/connectivity/conn2/[accessurl=xyz.my-funny-provider.org]<&>
/xml/configuration/connectivity/conn2/[user=myFunnyUser]<&>
/xml/configuration/connectivity/conn2/[pwd=myFunnyPWD]<&>
-
Wie
dieser Darstellung ohne Weiteres entnehmbar ist, umfasst jeder Eintrag
eine Pfadangabe (hier: /xml/configuration/connectivity/conn1/) sowie
einen Parameter in Verbindung mit einem Wert (hier z. B. accessnr
als Parameter und +1234567890 als Wert). Am Ende eines jeweiligen
Zeileneintrags ist der Separator „<&>” vorgesehen.
Da die Symbole „<”, „>” und „&”, die
als Separator verwendet werden, XML-reservierte Symbole sind (vgl.
[22]), ist eine Rückwärtskompatibilität
bei der Re-Kompilierung der in linearer Form vorliegenden Daten
in ein klassisches XML-Format sichergestellt. Darüber hinaus
kann erfindungsgemäße Format auf einfache Weise
in eine Vektorform gebracht werden, wie dies nachfolgend gezeigt
ist. Dies erfolgt durch eine Suche nach dem Separator „<&>”.
| 0 | /xml/configuration/connectivity/conn1/[accessnr=+1234567890] |
| 1 | /xml/configuration/connectivity/conn1/[user=myFunnyUser] |
| 2 | /xml/configuration/connectivity/conn1/[pwd=myFunnyPWD] |
| 3 | /xml/configuration/connectivity/conn2/[accessurl=xyz.my-funny-provider.org] |
| 4 | /xml/configuration/connectivity/conn2/[user=myFunnyUser] |
| 5 | /xml/configuration/connectivity/conn2/[pwd=myFunnyPWD] |
-
Das
lineare Datenformat weist eine Vielzahl von Vorteilen im Vergleich
zum herkömmlichen XML-Format auf:
- – Es
kann in Software und/oder Transfer-Mediendaten-Containern verwendet
werden, die mit Vektoren korrespondieren.
- – Die Daten können unter Verwendung der XPath-Konvention
(vgl. [21]) auf einfache Weise gesucht und extrahiert werden, da
die interne Repräsentation auf Separatoren oder in einem
Vektor XPath-basiert. Das heißt, nur ein Vergleich von
Strings ohne zusätzliche Zerlegung der Daten ist notwendig.
-
Auch
die Textform ist über MOST übertragbar. Dies findet
Verwendung im Falle, dass die Überführung der
Daten in die Textform und das persistente Medium sich in verschiedenen
Steuergeräten im Fahrzeug befinden.
-
Der
Mechanismus zum Repräsentieren von Konfigurationsdaten
kann für verschiedene MOST-Geräte verwendet werden.
Beispielsweise können die Daten auf einem MOST-Bus in der
Form eines dynamischen Datenarrays repräsentiert sein.
Dies kann beispielsweise in einer Vektor-Form oder einem klassifizierten Stream
(z. B. in linearisierter Form) erfolgen. Das Streaming der Daten
kann beispielsweise unter Verwendung der sog. MoCCA Middleware der
Firma HarmanBecker [23] erfolgen, um die Daten für einen
seriellen Transport zu typisieren. Damit kann beispielsweise ein
neuer IANA-Mediendatentyp definiert werden:
„application/HBMOCCAObject” („;” parameter)
-
Beispiele
für die Verwendung dieser Datentypen sind:
”Content-Type=application/HBMOCCAObject;
type=THBVector”
oder
”Content-Type=application/HBMOCCAObject;
type=CHBString”
-
MoCCA
kann beispielsweise in einer Fahrzeug-zu-Fahrzeug-Kommunikation
eingesetzt werden. Es kann als „Shared Agent System” zwischen
Kraftfahrzeugen und/oder Internetbasierten Infrastrukturen verwendet
werden. Für den Fall, in dem sich Kraftfahrzeuge Telematik-Plattformen
teilen, können das Daten-Handling und die Anordnungsmechanismen
für Konfigurationsinformationen über Internetprotokolle,
wie z. B. HTTP oder SIP, durchgeführt werden. Die Spezifikation
eines gemeinsamen Medientyps ist Voraussetzung für die
Interoperabilität zwischen Datentransfersystemen.
-
Die
Software, welche die Daten über ein Datentransfersystem
repräsentiert, schließt Softwarestücke wie
Adapter und Proxy [24] ein. Die Schnittstelle (API, Application
Programable Interface) zur Repräsentierung der transportablen
Sub-Strukturen hängt jedoch von dem Teil-Validierungsalgorithmus
ab. Liste der verwendeten Abkürzungen
| Wort | Definition |
| APN | Access
Point Name |
| CSD | Circuit
Switched Data |
| DNS | Domain
Name System |
| DTD | Document
Type Definition |
| GPRS | General
Packet Radio Service |
| GSM | Global
System for Mobile communications |
| HMI | Human-Machine
Interface |
| HTTP | Hyper-Text
Transfer Protocol |
| HW | Hardware |
| IANA | Internet
Assigned Numbers Authority |
| Infoset | Information
Set |
| IP | Internet
Protocol |
| MIME | Multipurpose
Internet Mail Extensions |
| MOST | Media
Oriented Systems Transport |
| NAD | Network
Access Device |
| QoS | Quality
of Service |
| SIM | Subscriber
Identity Modules |
| SIP | Session
Initiation Protocol |
| SLA | Service
Level Agreement |
| SW | Software |
| UMTS | Universal
Mobile Telecommunications System |
| WWW | World
Wide Web |
| XML | Extensible
Markup Language |
-
Liste der Veröffentlichungen
-
- [1] T. Guenkova-Luy, "Multimedia Networking – Coordination
of Multimedia Services in Next Generation Mobile Networks",
VDM Verlag Dr. Mueller, 2007
- [2] M. Alfano, N. Radouniklis, "A Cooperative
Multimedia Environment with QoS Control: Architectural and Implementation
Issues", ICSI Technical Report TR-96-040, International
Computer Science Institute, Berkeley (CA, USA), Sept. 1996
- [3] A. Watson, M. A. Sasse, "Measuring Perceived
Quality of Speech and Video in Multimedia Conferencing Applications",
Sixth ACM international conference an Multimedia, Bristol (UK),
September 1998
- [4] Y. Ito, Sh. Tasaka, Y. Fukuta, "Psychometric
Analysis of the Effect of End-to-End Delay on User-Level QoS in
Live Audio-Video Transmission", IEEE International Conference
on Communications (ICC2004), Paris (France), June 2004
- [7] Ch. Valentine, "XML Schemas",
SYBEX, 2002
- [8] B. Marchal, "XML by Example",
QUE, 2002
- [9] H.-E. Eriksson et al., "Uml 2 Toolkit",
Wiley Publishing, 2004
- [10] International Organization for Standardization,
International Electrotechnical Commission and International Telecommunication
Union, "Information Processing Systems – OSI Reference
Model – The Basic Model", International Standard
ISO/IEC 7498-1: 1994 and ITU-T Recommendation X.200, 1994
- [11] J. Rosenberg et al., "SIP: Session Initiation
Protocol", IETF RFC 3261, June 2002
- [12] M. Handley, V. Jacobson, C. Perkins, "SDP:
Session Description Protocol", IETF RFC 4566, July 2006
- [13] IANA, "MIME Media Types", http://www.iana.org/assignments/media-types/
- [14] R. Fielding et al., "Hypertext Transfer
Protocol – HTTP/1.1", IETF RFC 2616, June 1999
- [15] GSM 02.17 V8.0.0 (1999-11), "Digital cellular
telecommunications system (Phase 2+); Subscriber Identity Modules
(SIM); Functional characteristics", Technical Specification,
Nov. 1999
- [16] DARPA INTERNET PROGRAM, "Internet Protocol",
IETF RFC 791, Sept. 1981
- [17] S. Deering, R. Hinden, "Internet Protocol,
Version 6 (IPv6)", IETF RFC 2460, Dec. 1998
- [18] P. V. Mockapetris, "Domain Names – Concepts
And Facilities", IETF RFC 1034, Nov. 1987
- [19] MOST Cooperation, "MOST Media Oriented
Systems Transport – Multimedia and Control Networking Technology",
MOST Specification, Rev 2.5, 10/2006, http://www.mostcooperation.com/publications/Specifications_Organizational_Procedures/index.html?dir=97
- [20] W3C, "XML Information Set (Second Edition)",
W3C Recommendation, February 2004, http://www.w3.org/TR/xml-infoset/
- [21] W3C, "XML Path Language (XPath), Version
1.0", W3C Recommendation, Nov. 1999, http://www.w3.org/TR/xpath
- [22] W3C, "XML Primer", Oxford Brookes
University 2002, http://www.w3c.rl.ac.uk/primers/xml/xmlprimer.htm
- [23] HBAS, "MoCCA User's Guide", MoCCAUsers-Guide_Version1_9_Release_D2_5.pdf,
Revision 1.9 January, 2008
- [24] E. Gamma, R. Helm, R. Johnson, J. M. Vlissides, "Design
Patterns: Elements of Reusable Object-Oriented Software",
Addison-Wesley, 1995
-
- 1
- erster
Rechner
- 2
- zweiter
Rechner
- 3
- Datenübertragungsstrecke
- 4
- Daten
in erstem Datenformat
- 5
- Daten
in zweiten Datenformat
- 6
- Daten
in drittem Datenformat
- 10
- Wurzel
des Konfigurationsmodells
- 20
- Konfigurations-Objekt
- 21
- Verbindungs-Objekt
- 22
- Dienste-Objekt
- 23
- Beschränkungen-Objekt
- 31
- Zugangsdaten-Objekt
- 32
- Applikations-Objekt
- 33
- Beschränkungen-Objekt
-
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 Nicht-Patentliteratur
-
- - T. Guenkova-Luy, ”Multimedia
Networking – Coordination of Multimedia Services in Next
Generation Mobile Networks”, VDM Verlag Dr. Mueller, 2007 [0051]
- - M. Alfano, N. Radouniklis, ”A Cooperative Multimedia
Environment with QoS Control: Architectural and Implementation Issues”,
ICSI Technical Report TR-96-040, International Computer Science
Institute, Berkeley (CA, USA), Sept. 1996 [0051]
- - A. Watson, M. A. Sasse, ”Measuring Perceived Quality
of Speech and Video in Multimedia Conferencing Applications”,
Sixth ACM international conference an Multimedia, Bristol (UK),
September 1998 [0051]
- - Y. Ito, Sh. Tasaka, Y. Fukuta, ”Psychometric Analysis
of the Effect of End-to-End Delay on User-Level QoS in Live Audio-Video
Transmission”, IEEE International Conference on Communications
(ICC2004), Paris (France), June 2004 [0051]
- - Ch. Valentine, ”XML Schemas”, SYBEX, 2002 [0051]
- - B. Marchal, ”XML by Example”, QUE, 2002 [0051]
- - H.-E. Eriksson et al., ”Uml 2 Toolkit”,
Wiley Publishing, 2004 [0051]
- - International Organization for Standardization, International
Electrotechnical Commission and International Telecommunication
Union, ”Information Processing Systems – OSI Reference
Model – The Basic Model”, International Standard
ISO/IEC 7498-1: 1994 and ITU-T Recommendation X.200, 1994 [0051]
- - J. Rosenberg et al., ”SIP: Session Initiation Protocol”,
IETF RFC 3261, June 2002 [0051]
- - M. Handley, V. Jacobson, C. Perkins, ”SDP: Session
Description Protocol”, IETF RFC 4566, July 2006 [0051]
- - IANA, ”MIME Media Types”, http://www.iana.org/assignments/media-types/ [0051]
- - R. Fielding et al., ”Hypertext Transfer Protocol – HTTP/1.1”,
IETF RFC 2616, June 1999 [0051]
- - GSM 02.17 V8.0.0 (1999-11), ”Digital cellular telecommunications
system (Phase 2+); Subscriber Identity Modules (SIM); Functional
characteristics”, Technical Specification, Nov. 1999 [0051]
- - DARPA INTERNET PROGRAM, ”Internet Protocol”,
IETF RFC 791, Sept. 1981 [0051]
- - S. Deering, R. Hinden, ”Internet Protocol, Version
6 (IPv6)”, IETF RFC 2460, Dec. 1998 [0051]
- - P. V. Mockapetris, ”Domain Names – Concepts
And Facilities”, IETF RFC 1034, Nov. 1987 [0051]
- - MOST Cooperation, ”MOST Media Oriented Systems Transport – Multimedia
and Control Networking Technology”, MOST Specification,
Rev 2.5, 10/2006, http://www.mostcooperation.com/publications/Specifications_Organizational_Procedures/index.html?dir=97 [0051]
- - W3C, ”XML Information Set (Second Edition)”,
W3C Recommendation, February 2004, http://www.w3.org/TR/xml-infoset/ [0051]
- - W3C, ”XML Path Language (XPath), Version 1.0”,
W3C Recommendation, Nov. 1999, http://www.w3.org/TR/xpath [0051]
- - W3C, ”XML Primer”, Oxford Brookes University
2002, http://www.w3c.rl.ac.uk/primers/xml/xmlprimer.htm [0051]
- - HBAS, ”MoCCA User's Guide”, MoCCAUsers-Guide_Version1_9_Release_D2_5.pdf,
Revision 1.9 January, 2008 [0051]
- - E. Gamma, R. Helm, R. Johnson, J. M. Vlissides, ”Design
Patterns: Elements of Reusable Object-Oriented Software”,
Addison-Wesley, 1995 [0051]
