-
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 geografischen 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 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:
-
1 – eine Übersicht
eines Aktualisierungssystems,
-
2 – ein Beispiel
einer hierarchisch strukturierten Datenbasis,
-
3 – schematisch
das Hinzufügen
eines untergeordneten Aktualisierungssegments,
-
4 – schematisch
das Ändern
eines untergeordneten Aktualisierungssegments und
-
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 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 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 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 überführt 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 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 geografisches 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 geografischen Gebiets
enthält.
Der versionierte Knoten 14 hat einen weiteren untergeordneten Knoten 21,
der Informationen zu Straßenkarten
des geografischen 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
geografischen 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 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 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 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.