Beschreibung
Titel
Aktualisierungsverfahren für Datenbasen, insbesondere Navigationsdatenbasen
Die vorliegende Erfindung betrifft ein Verfahren zur Aktualisierung einer dezentralen
Datenbasis, insbesondere einer Navigationsdatenbasis, die in Segmente unterteilt ist, durch Übertragen eines aktualisierten Segments von einer in entsprechende Segmente unterteilten, zentralen Datenbasis in die dezentrale Datenbasis und Speichern des aktualisierten Segments in der dezentralen Datenbasis.
Heutige Navigationssysteme verfügen über umfangreiche Datenbasen, in denen beispielsweise Daten einer digitalisierten Karte, Daten zur Eingabe des Fahrziels, zur Routensuche und -anzeige und zur Zielführung unter Anzeige der derzeitigen Position eines Fahrzeugs gespeichert sind. Ferner können die Datenbasen zusätzliche Daten für Fahrerassistenzsysteme enthalten.
Der Anwender einer Datenbasis hat ein Interesse daran, dass die in der Datenbasis enthaltenen Informationen möglichst aktuell sind. Beispielsweise mindert sich der Wert einer Navigations-Datenbasis für den Fahrer, wenn sich das der Datenbasis zugrunde liegende Straßennetz verändert hat oder eine temporäre Verkehrsstörung nicht berücksichtigt werden kann, weil die Navigations-Datenbasis keine Informationen hierzu enthält. Ein anderes Beispiel stellen Computeranwendungen dar, die auf aktuelle Daten angewiesen sind.
Üblicherweise wird eine dezentrale Datenbasis in der Weise aktualisiert, dass in einem
Datenzentrum die Verfügbarkeit neuer Daten überprüft und gegebenenfalls eine neue Version der Datenbasis bereitgestellt wird. Wenn eine neue Version der Datenbasis verfügbar ist, werden diese zusammengestellt und in einer Aktualisierungs-Datenbasis gespeichert. Das dezentrale System, beispielsweise das Navigationssystem im Fahrzeug,
lädt geeignete Aktualisierungsdaten von dieser Aktualisierungs-Datenbasis herunter und bindet diese in seine dezentrale Datenbasis ein.
Die Aktualisierung einer Datenbasis kann vollständig oder teilweise erfolgen.
Eine vollständige Aktualisierung bietet den Vorteil, dass der gesamte Datenbestand aufeinander abgestimmt ist. Nachteilig ist jedoch, dass eine vollständige Aktualisierung für den Anwender häufig mit unnötigem Kosten- und Zeitaufwand verbunden ist. Dies ist beispielsweise dann der Fall, wenn Daten übermittelt werden, die sich entweder nicht geändert haben oder für den Anwender nicht notwendig sind und die Kosten vom
Datenvolumen abhängen.
Um die für einen Aktualisierungsschritt anfallenden Datenmengen zu reduzieren, kann die gesamte Datenbasis deshalb nicht in einem einzigen Schritt aktualisiert werden, sondern sie wird jeweils nur teilweise aktualisiert. Hierzu wird der Inhalt der Datenbasis in einzelne Segmente aufgeteilt, beispielsweise unter geografϊschen und/oder thematischen Gesichtspunkten oder einer Kombination davon.
Bei der in Teilschritten erfolgenden Aktualisierung können allerdings Probleme auftreten, da die Datenbasis ihre Konsistenz verlieren kann. Das heißt, durch die Aktualisierung eines Teilbereichs können mögliche Beziehungen mit anderen Segmenten gelöst werden.
Beispielsweise ist es denkbar, dass bei einer Aktualisierung in einem Segment ein
Straßenabschnitt gelöscht wird, auf den ein anderes, nicht aktualisiertes Segment mit einem Straßenanschluss noch hinweist. Derartige Inkonsistenzen müssen bei einer Aktualisierung in Teilschritten vermieden werden.
Eine gängige Vorgehensweise, Inkonsistenzen bei der Aktualisierung einer Datenbasis zu vermeiden, besteht darin, die Datenbasis in sich nicht überschneidende Segmente einzuteilen, denen jeweils eine Versionskennung zugeordnet ist. Aufgrund der Abhängigkeiten zwischen einzelnen Segmenten der Datenbasis wird nicht jede
Kombination von Versionen zu einem konsistenten Zustand führen. Daher müssen das Datenzentrum und/oder das dezentrale System sicherstellen, dass jede Aktualisierung der dezentralen Datenbasis zu einer konsistenten Kombination von Versionen führt. Dabei steigt der Aufwand dieser Sicherstellung mit der Anzahl der Abhängigkeiten zwischen
den einzelnen Segmenten. Um solche Abhängigkeiten zu reduzieren, werden diejenigen Segmente der Datenbasis, die bei einer Aktualisierung überprüft werden müssen, derart gebildet, dass die Anzahl der Beziehungen zwischen den Segmenten minimiert wird.
Ein weiteres Problem bei einer Aktualisierung der Datenbasis in Teilschritten besteht in dem so genannten Lawineneffekt. Darunter ist zur verstehen, dass, obwohl der Anwender lediglich ein Segment der Datenbasis aktualisieren möchte, viele Versionen vieler Segmente der Datenbasis ebenfalls aktualisiert werden müssen, um eine konsistente Kombination von Versionen zu erhalten. Dies führt wiederum zu erhöhten Kosten und einem erhöhten Zeitaufwand.
Lawineneffekte können dadurch begrenzt werden, dass die Datenbasis in kleinere Segmente unterteilt wird. Kleinere Segmente der Datenbasis, deren Versionen überprüft werden müssen, führen jedoch zu einer größeren Anzahl solcher Segmente. Damit steigen auch der Wartungsaufwand und der benötigte Speicherplatz für die Versionskontrolle.
Darüber hinaus steigt die Wahrscheinlichkeit so genannter Strukturänderungen, worunter das Hinzufügen oder Entfernen von Segmenten der Datenbasis zu verstehen ist, deren Versionen überprüft werden. Strukturänderungen können nur mit Hilfskonstruktionen verwaltet werden.
Vor diesem Hintergrund ist es die Aufgabe der vorliegenden Erfindung, eine verbesserte konsistente Aktualisierung beliebiger Segmente einer Datenbasis zu ermöglichen.
Diese Aufgabe wird durch ein Verfahren der eingangs beschriebenen Art dadurch gelöst, dass die Segmente in der dezentralen Datenbasis auf ein hierarchisches Modell abgebildet werden und bei der Aktualisierung des Segments in der dezentralen Datenbasis auch diejenigen Segmente aktualisiert werden, von denen das Segment abhängig ist. Eine Aktualisierung eines Segments verursacht hierdurch keine Inkonsistenz der Datenbasis, da die jeweiligen Segmente ebenfalls aktualisiert werden, von denen es abhängt.
Die hierarchische Datenstruktur ermöglicht zudem die Speicherung relativer Pfade, wodurch das Speichern und Übertragen der aktualiserten Segmente effizienter als bisher
- A -
erfolgt und der Wartungsaufwand der Datenbasis reduziert wird. Zweckmäßig wird die dezentrale Datenbasis in eine Baumstruktur abgebildet.
Eine Einteilung in Segmente kann dadurch erfolgen, dass in der dezentralen Datenbasis sogenannte versionierte Knoten bestimmt werden und die Segmente aus jeweils einem versionierten Knoten als Wurzel sowie allen untergeordneten Knoten, die keine versionierten Knoten sind, und deren Nachfolgern gebildet werden. Die Begriffe Knoten und Wurzel sind nicht auf Baumstrukturen beschränkt, sondern werden hier allgemein für hierarchische Datenstrukturen verwendet. Danach stellt ein Knoten ein Datenelement oder eine Datenmenge der Datenbasis dar.
Unter Wurzel der gesamten Datenbasis ist derjenige Knoten zu verstehen, der hierarchisch auf der höchsten Ebene der Datenbasis angeordnet ist; unter Wurzel eines Segmentes ist derjenige Knoten zu verstehen, der hierarchisch auf der höchsten Ebene innerhalb des Segmentes angeordnet ist. Bei den versionierten Knoten handelt es sich um eine Teilmenge sämtlicher Knoten des Datenbaums, zu dessen Elementen die Wurzel des Baumes gehört.
Die Anzahl versionierter Knoten und ihre Verteilung in der Datenbasis können im Einzelfall nach Zweckmäßigkeitsgesichtspunkten erfolgen. Zweckmäßig wird die Anzahl und Bestimmung der versionierten Knoten so vorgenommen, dass sich Daten, die voraussichtlich häufig aktualisiert werden, in Segmenten befinden, die keine oder nur wenige untergeordnete Segmente aufweisen. Auf diese Weise kann verhindert werden, dass sich die Aktualisierung eines Segments zu einer lawinenartigen Aktualisierung entwickelt. Es ist auch nicht ausgeschlossen, Teile der Datenbasis, zum Beispiel globale
Indizes, von der vorstehend beschriebenen Versionierung auszunehmen. Bei diesen Teilen muss dann auf andere Weise sichergestellt werden, dass keine Inkosistenzen auftreten, wenn Teile dieser Daten aktualisiert werden.
Damit die Versionen eines bestimmten Segments unterschieden werden können, wird jedem Segment eine Versionskennung zugeordnet. Beispielsweise kann die Versionskennung in einer ganzen Zahl bestehen.
Es gibt unterschiedliche Möglichkeiten, die Versionskennung eines untergeordneten Segments (B) zu behandeln, wenn sich ein übergeordnetes Segment (A) ändert: 1) Die Versionskennung des Segments (B) bleibt unverändert erhalten, wenn sich das Segment (B) nicht geändert hat; die Versionskennung des Segments (B) wird erhöht, wenn sich das Segment (B) geändert hat. 2) Die Versionskennung des Segments (B) wird zurückgesetzt
(sog. Reset; zum Beispiel auf Null), unabhängig davon, ob sich das Segment (B) geändert hat oder nicht. Durch den Reset werden auch die Versionskennungen sämtlicher, dem Segment (A) untergeordneter Segmente zurückgesetzt. 3) Die Versionskennung des Segments (B) wird wahlweise unverändert beibehalten oder zurückgesetzt werden. Die Wahl kann willkürlich oder situationsbedingt erfolgen.
Die Versionskennung kann jedoch auch weitere Informationen enthalten, wie zum Beispiel Informationen über den Inhalt und das Format der Daten innerhalb eines Segments und/oder über die Struktur untergeordneter Segmente. Die Versionskennung wird innerhalb des zugehörigen Segments oder in einer zentralen Liste der dezentralen
Datenbasis gespeichert. Hierdurch steht die Versionskennung eines Segments auch zu späteren Zeitpunkten zur Verfügung.
In einer bevorzugten Ausführungsform wird innerhalb des Datenzentrums für jede neue Versionskennung eines Segments geprüft, welche Versionen anderer Segmente mit der neuen Versionskennung konsistent sind. Diese Aufgabe kann beispielsweise durch einen
Update-Kompilator erfolgen. Zum einen wird hierdurch die Konsistenz der dezentralen
Datenbasis sichergestellt. Zum anderen können Änderungen der Datenbasis, insbesondere
Inhalts-, Format- und/oder Strukturänderungen, gebildet werden, ohne dass innerhalb des dezentralen Systems eine zusätzliche Prüfung auf Konsistenz erforderlich ist.
Für die Prüfung auf Konsistenz ist es erforderlich, dass die Version eines versionierten Segments eindeutig adressiert werden kann. Dies kann durch einen Versionspfad erfolgen. Dabei handelt es sich um einen Vektor, dessen Komponenten aus den Versionskennungen des versionierten Segments und den Versionskennungen sämtlicher untergeordneter versionierter Segmente bestehen. Dadurch werden abhängige untergeordnete Versionen zugelassen. Es ist jedoch auch möglich, die Version eines versionierten Segments durch dessen Versionskennung, beispielsweise einer ganzen Zahl, zu adressieren.
Um eine hohe Mobilität eines Systems, beispielsweise eines Navigationssystems, mit der dezentralen Datenbasis zu ermöglichen, wird bevorzugt die Übertragung der aktualisierten Segmente drahtlos durchgeführt. Dies kann beispielsweise mittels einer Radio- bzw. Funkübertragung oder über eine mobile Telekommunikationsverbindung erfolgen. Alternativ ist eine Datenübertragung über austauschbare Speichermedien ebenfalls denkbar. Es ist aber auch möglich, die Übertragung der aktualisierten Segmente über das Internet durchzuführen.
Die Erfindung wird nachfolgend anhand der beigefügten Figuren näher erläutert. Es zeigen:
Figur 1 - eine Übersicht eines Aktualisierungssystems,
Figur 2 - ein Beispiel einer hierarchisch strukturierten Datenbasis,
Figur 3 - schematisch das Hinzufügen eines untergeordneten Aktualisierungssegments,
Figur 4 - schematisch das Ändern eines untergeordneten Aktualisierungssegments und
Figur 5 - schematisch das Entfernen eines untergeordneten Aktualisierungssegments.
Die folgende Darstellung orientiert sich an einem Navigationssystem. Die Erfindung ist jedoch nicht auf Navigationssysteme beschränkt, sondern kann überall dort eingesetzt werden, wo aktualisierte Daten benötigt und in eine Datenbasis eingearbeitet werden müssen. Als Beispiel sei das Herunterladen aktualisierter Versionen von Spielen oder Anwendungsprogrammen aus dem Internet genannt.
In Figur 1 ist ein Datenzentrum 1 gezeigt. In dem Datenzentrum werden Navigations- Datenbasen erstellt. Die Navigations-Datenbasen enthalten beispielsweise Informationen über das Straßennetz oder so genannte Points of Interest, wie zum Beispiel Standorte von Tankstellen, Hotels oder Sehenswürdigkeiten.
Das Datenzentrum 1 umfasst einen Daten-Kompilator 2, der Daten zusammenträgt und - stellt. Der Daten-Kompilator 2 wird auch Data Compiler genannt. Der Daten-Kompilator 2 trägt Daten zusammen, die für eine Navigations-Datenbasis erforderlich oder nützlich sind, wie zum Beispiel die vorgenannten Daten über das Straßennetz. Aus diesen Daten setzt der Daten-Kompilator 2 Aktualisierungen 3, 4, 5 der Rohdaten der Navigations-
Datenbasis zusammen. In Figur 1 stellen die drei Zylinder drei Aktualisierungen 3, 4, 5 der Navigations-Datenbasis für drei aufeinander folgende Jahre dar. Jede Aktualisierung 3, 4, 5 umfasst den gesamten Datenbestand an Rohdaten der zugrunde liegenden Navigations-Datenbasis. Änderungen der Daten gegenüber einer Aktualisierung 3, 4 eines Vorjahres müssen nicht den gesamten Datenbestand betreffen. So ist es denkbar, dass sich die Daten des Straßennetzes nur in einem regionalen Gebiet geändert haben, obwohl die Rohdaten das Straßennetz für ein ganzes Land enthalten.
Ein Update-Kompilator 6, der auch Update Compiler genannt wird, überprüft eine vom Daten-Kompilator 2 zusammengesetzte Aktualisierung 3, 4, 5 darauf hin, wo sich der
Datenbestand gegenüber der vorigen Aktualisierung 3, 4 geändert hat. Wenn der Update- Kompilator 6 eine Änderung feststellt, stellt er die Aktualisierung 3, 4, 5 in einer Update- Datenbasis 7 bereit. Von der Update-Datenbasis 7 können diese Daten an ein dezentrales System 8 übertragen oder von dem dezentralen System 8 abgerufen werden.
Bei dem dezentralen System 8 handelt es sich in dem hier dargestellten Ausführungsbeispiel um ein Navigationssystem, das in einem Fahrzeug installiert ist. Das dezentrale System 8 umfasst einen Update-Integrator 9, der die Daten aus der Update- Datenbasis abruft und in das dezentrale System 8 überführt. Der Update-Integrator 9 aktualisiert daraufhin eine dezentrale Datenbasis 10 innerhalb des dezentralen Systems 8, im vorliegenden Fall also die Navigations-Datenbasis in dem Fahrzeug.
In Figur 2 ist eine Datenbasis 11 auf die Struktur eines Datenbaums, genauer eines Binärbaumes, abgebildet, bei dem von einem Knoten 12 höchstens zwei untergeordnete Knoten 13 abzweigen.
Es ist für die vorliegende Erfindung jedoch nicht Voraussetzung, dass die Datenbasis 11 auf eine Baumstruktur abgebildet wird. Erforderlich ist lediglich, dass es sich um eine hierarchische Datenstruktur handelt oder zumindest in eine hierarchische Datenstruktur
überfuhrt werden kann. Eine einfache Möglichkeit, eine nichthierarchisch angeordnete Datenstruktur in eine hierarchische Struktur zu projizieren, besteht darin, die gesamte Datenbasis als Wurzel eines Baumes aufzufassen, wobei jedes Segment der Datenbasis als ein direkt der Wurzel untergeordneter Knoten behandelt wird. Es kann aber auch eine tiefere Datenstruktur erwünscht sein. Dies kann beispielsweise mittels XML (Extensible
Markup Language) erreicht werden. Dabei kann jedes XML-Element als ein Knoten in dem hierarchischen Datenmodell angesehen werden.
Die Datenbasis 11 weist zwei unterschiedliche Klassen an Knoten 14, 15 auf: die eine Klasse bildet die Menge der versionierten Knoten 14, die andere Klasse die Menge der nichtversionierten Knoten 15. Die Anzahl und Verteilung der versionierten Knoten 14 innerhalb der Datenbasis 11 bestimmt die gegenseitige Abhängigkeit der Daten, die bei einer Aktualisierung der Datenbasis 11 berücksichtigt werden müssen. Die Einteilung in die beiden Klassen ist willkürlich, mit der einen Ausnahme, dass die Wurzel 16 einen versionierten Knoten 13 darstellen muss.
Die versionierten Knoten 14 und nichtversionierten Knoten 15 sind zu versionierten Segmenten 17 zusammengefasst. Die versionierten Segmente 17 sind in Figur 2 punktiert dargestellt. Jedes versioniertes Segment 17 besteht aus einem versionierten Knoten 12, 14, 16 sowie gegebenenfalls sämtlichen von diesem versionierten Knoten 12, 14, 16 abhängigen, das heißt untergeordneten nichtversionierten Knoten 15 sowie deren nichtversionierten Nachfolgern. Jedes versionierte Segment 17 enthält somit genau einen versionierten Knoten 12, 14, 16. Die Bedeutung des versionierten Segments 17 besteht darin, dass es nur insgesamt aktualisiert werden kann, auch wenn sich nur einige Teile von dessen Daten geändert haben.
Die Datenbasis 11 soll nachfolgend anhand von Daten für eine Navigations-Datenbasis näher erläutert werden.
Die Wurzel 16 des Datenbaumes bildet eine höchste Ebene 18, die so genannte
Datenbasis-Ebene. Die Wurzel 16 repräsentiert die Straßenkarte eines ganzen Landes. In einer zweiten Ebene 19, der Verzeichnis-Ebene, stellt der Knoten 14 ein begrenztes geografϊsches Gebiet innerhalb des Landes dar. In einer nächsten Ebene 20, der so genannten Datei-Ebene, liegt ein versionierter Knoten 20, der dem Knoten 14
untergeordnet ist und Informationen über Points of Interest des von dem Knoten 14 repräsentierten geografϊschen Gebiets enthält. Der versionierte Knoten 14 hat einen weiteren untergeordneten Knoten 21, der Informationen zu Straßenkarten des geografϊschen Gebiets enthält. Der Knoten 21 hat einen untergeordneten Knoten 22, der in einer vierten Ebene 23, der so genannten Element-Ebene, liegt. Der Knoten 22 enthält eine 3D-Darstellung von Häusern in den Straßen, die von dem Knoten 21 repräsentiert werden. Der Datenbaum könnte auch weitere Ebenen enthalten, zum Beispiel zusätzliche Verzeichnis-Ebenen oder Attribut-Ebenen.
Nachfolgend wird näher erläutert, wie sich die Einteilung der Datenbasis 11 in die einzelnen versionierten Segmente 17 auswirkt.
Wenn die Datenbasis 11 dahingehend geändert wird, dass der Anwender kein Interesse mehr an den Points of Interest des von dem Knoten 14 repräsentierten geografϊschen Gebiets hat, so kann das versionierte Segment, das durch den versionierten Knoten 20 als
Wurzel bestimmt wird, gelöscht werden, ohne dass eine Aktualisierung des versionierten Segments 17 erforderlich ist. Das folgt daraus, dass die gelöschten Points of Interest zu einem versionierten Segment gehören, das dem versionierten Segment 17 untergeordnet ist. Sollen dagegen die Daten zu den Straßenkarten im Knoten 21 geändert werden, so muss das gesamte versionierte Segment 17 aktualisiert werden.
In Figur 3 ist im linken Kasten ein versioniertes Segment 24 zu einem bestimmten Zeitpunkt dargestellt. Die Datenbasis wird nun einmal aktualisiert, was durch einen Pfeil 25 angedeutet wird. Die Aktualisierung besteht darin, dass der Datenbank ein versioniertes Segment 26 hinzugefügt wird. Das versionierte Segment 26 ist dem versionierten Segment 24 unmittelbar untergeordnet, das heißt es liegen keine Ebenen zwischen ihnen. Jedes versionierte Segment 24, 26 trägt ihre eigene Version, die entweder in dem jeweiligen versionierten Segment 24, 26 oder in einer zentralen Liste außerhalb der versionierten Segmente 24, 26 gespeichert sind. Vor der Aktualisierung hat das versionierte Segment 24 eine Versionskennung n gehabt, wobei n eine ganze Zahl darstellt. Nach dem Hinzufügen des untergeordneten versionierten Segments 26 erhöht sich die Versionskennung des versionierten Segments 24 um 1, das heißt das versionierte Segment 24 besitzt jetzt die Versionskennung n+1. Das hinzugefügte versionierte Segment 26 bekommt die Versionskennung 1, da es vorher nicht vorhanden war.
Die Speicherung der Versionen der einzelnen versionierten Segmente 24, 26 ist deshalb wichtig, weil die versionierten Segmente 24, 26 nur stufenweise mit steigenden Versionen richtig aktualisiert werden können. Dadurch wird auch sichergestellt, dass bei Kenntnis einer Versionsnummer eines versionierten Segments der zeitliche Zustand dieses versionierten Segments rekonstruiert werden kann.
In Figur 4 ist ein versioniertes Segment 27 zu einem bestimmten Zeitpunkt dargestellt, dem ein versioniertes Segment 28 untergeordnet ist. Das versionierte Segment 27 hat die Versionskennung n, das versionierte Segment 28 die Versionskennung m, wobei m und n ganze Zahlen sind. Während einer Aktualisierung, die durch einen Pfeil 29 angedeutet wird, wird das versionierte Segment 28 verändert. Aus diesem Grunde erhöht sich die Versionskennung des versionierten Segments 28 um 1, sodass sie jetzt m+1 beträgt. Die Versionskennung des versionierten Segments 27 bleibt unverändert.
In Figur 5 ist ein versioniertes Segment 30 mit einem versionierten Segment 31 zu einem bestimmten Zeitpunkt dargestellt. Das versionierte Segment 30 hat die Versionskennung n, das versionierte Segment 31 die Versionskennung m, wobei m und n ganze Zahlen sind. Nach einer Aktualisierung, die durch einen Pfeil 32 angedeutet wird, ist das versionierte Segment 31 entfernt worden. Die Versionskennung des versionierten
Segments 30 erhöht sich dadurch um 1 und beträgt jetzt n+1.