-
HINWEIS AUF VERWANDTE
ANMELDUNGEN
-
Die
vorliegende Anmeldung ist verwandt mit der gleichzeitig anhängigen,
am 25. Oktober 1996 eingereichten Anmeldung mit dem Titel „IMPROVED
SYSTEM AND METHOD FOR USE AND STORAGE OF GEOGRAPHIC DATA ON PHYSICAL
MEDIA", US-Anmeldenummer
08,740,295, die auf den Rechtsnachfolger der vorliegenden Anmeldung übertragen
wurde.
-
HINTERGRUND DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft Navigationssysteme, und die vorliegende
Erfindung betrifft insbesondere eine Navigationssystem-Schnittstellenschicht,
welche Verwendung und Zugriff auf eine auf einem physikalischen
Speicherträger
gespeicherte geographische Datenbank erleichtert.
-
Rechnergestützte Navigationssysteme
zur Verwendung an Land sind inzwischen in vielfältigen Formen verfügbar und
sehen vielfältige
nützliche
Merkmale vor. Beispielsweise verwendet ein Navigationssystemtyp
(1) einen detaillierten Datensatz über einen oder mehrere geographische
Bereiche oder Regionen, (2) ein Navigationsanwendungsprogramm, (3)
geeignete Computer-Hardware, wie zum Beispiel Mikroprozessor, interner
sowie externer Speicher und wahlweise (4) ein Positionsbestimmungssystem.
Der detaillierte Geodatensatzteil des Navigationssystems liegt in
Form einer oder mehrerer detaillierter, organisierter Dateien oder Datenbanken
vor. Der detaillierte Geodatensatz kann Informationen über die
Lage von Straßen
und Kreuzungen in oder bezogen auf einen oder mehrere bestimmte
geographische Regionalbereiche enthalten sowie auch Informationen über Einbahnstraßen, Abbiegeverbote,
Hausadressen, alternative Strecken, Hotels, Restaurants, Museen,
Stadien, Büros,
Autohändler,
Autowerkstätten
etc.
-
Das
Positionsbestimmungssystem kann eine der verschiedenen allgemein
bekannten Technologien verwenden, mit der man seinen physikalischen
Standort in einem geographischen Regionalbereich bestimmen oder
annähernd
bestimmen kann. Das Positionsbestimmungssystem kann beispielsweise
ein System des Typs GPS (globales Positionsbestimmungssystem), ein
System des Typs „Koppelnavigation" oder Kombinationen
derselben oder andere Systeme verwenden, die im Stand der Technik
alle allgemein bekannt sind.
-
Der
Navigationsanwendungs-Programmteil des Navigationssystems ist ein
Softwareprogramm, das den detaillierten Geodatensatz und das Positionsbestimmungssystem
(soweit verwendet) einsetzt. Das Navigationsanwendungsprogramm kann
für den
Anwender eine graphische Anzeige (z.B. eine „Karte") des spezifischen Standorts des Anwenders
im geographischen Bereich vorsehen. Zusätzlich kann das Navigationsanwendungsprogramm
dem Anwender von dessen Standort aus auch spezifische Richtungsanweisungen
zu Örtlichkeiten
im geographischen Bereich geben.
-
Bei
einigen Navigationssystemen sind Navigationsanwendungsprogramm,
geographischer Datensatz und wahlweise das Positionsbestimmungssystem
in einer einzigen Einheit kombiniert. Derartige aus einer einzigen
Einheit bestehende Systeme können
in Fahrzeuge eingebaut sein oder von Personen getragen werden. Alternativ
können
die Navigationsanwendungsprogramme und geographischen Datensätze dem
Anwender zum Laden in seinen Personalcomputer als käufliche
oder lizenzierte Softwareerzeugnisse zur Verfügung gestellt werden. In weiteren
Alternativen kann das Navigationssystem zentral oder regional platziert
und für
eine Vielzahl von Anwendern „nach
Bedarf" oder alternativ
online über
ein Netzwerk oder eine Kommunikationsverbindung zugänglich sein.
Personalcomputergestützte
Systeme können
autonome Systeme sein oder eine Kommunikationsverbindung zu einem
zentralen oder regionalen oder dezentralen System verwenden. Zudem können Anwender
auf ein Navigationssystem über
einen Online-Dienst wie das Internet oder über private Einwähldienste,
wie beispielsweise CompuServe, Prodigy und America Online zugreifen.
In Fahrzeuge eingebaute Navigationssysteme können drahtlose Kommunikationsverbindungen
nutzen. Navigationssysteme können auch
von Betreibern von Fuhrparks, wie beispielsweise LKW-Firmen, Paketzustelldienste
und so weiter verwendet werden. Navigationssysteme können auch
von Stellen verwendet werden, die mit Verkehrsregelung oder Verkehrsüberwachung
befasst sind.
-
Rechnergestützte Navigationssysteme
bieten Anwendern Navigationshilfe auf hohem Niveau. Navigationssysteme
können
detaillierte Fahranweisungen zu gewünschten Zielen geben und so
dazu beitragen, Reisezeit und Kosten einzusparen. Navigationssysteme
können
auch verbesserte Navigationsmerkmale bieten, beispielsweise Pendlern
und Reisenden dabei helfen, Verzögerungen
durch Baustellen zu vermeiden und den schnellsten Weg zum gewünschten
Ziel zu finden. Navigationssysteme können auch zur Integration von
Echtzeit-Verkehrsinformationen verwendet werden.
-
Um
diese nützlichen
und verbesserten Merkmale in einem Navigationssystem vorsehen zu
können,
ist es notwendig, umfassende, detaillierte, zuverlässige und
aktuelle Daten über
geographische Regionen und Bereiche zu sammeln und zu organisieren.
Es ist zudem notwendig, die geographischen Daten kontinuierlich zu
aktualisieren, da viele Daten schnell veraltet sind. Die Sammlung
von solchen geographischen Daten und die Bereitstellung derartiger
Daten in einem rechnerverwendbaren Format werden derzeit von der
Navigation Technologies in Sunnyvale, Kalifornien sichergestellt.
-
Ein
potenzielles mit der Bereitstellung verbesserter Merkmale und aktualisierter
Geodatenbanken für Navigationssysteme
verbundenes Problem besteht darin, dass es zahlreiche verschiedene
Navigationssystemplattformen gibt. Diese Plattformen können unterschiedliche
Hardware, Navigationssoftware, Betriebssysteme und so weiter aufweisen.
Viele dieser verschiedenen Plattformen haben sich unabhängig entwickelt
und sind untereinander nicht kompatibel. Selbst wenn die Sammlung
aktualisierter geographischer Daten und die Herstellung einer aktualisierten
rechnerlesbaren Geodatenbank möglich
wäre, so
wäre es
aufgrund der großen Anzahl
existierender verschiedener Plattformen schwierig, mit den unterschiedlichen
Navigationssystemplattformtypen verwendbare geographische Datenbanken
bereitzustellen und zu vertreiben. Durch neue, von Navigationssystemherstellern
entwickelte Navigationssystemgenerationen mit mehr und verbesserten
Merkmalen kann sich dieses Problem in Zukunft noch verschlimmern.
-
Ein
weiteres Problem besteht hinsichtlich der Bereitstellung aktualisierter
geographischer Daten für existierende
Navigationssysteme. Wie bei herkömmlichen
gedruckten Karten können
auch die in rechnergestützten
Navigationssystemen verwendeten geographischen Informationen irgendwann
veraltet sein. So werden beispielsweise neue Straßen gebaut,
Gewerbebetriebe ziehen um, Straßen
werden aufgrund von Bauarbeiten gesperrt, Umleitungen werden eingerichtet, Öffnungszeiten
von Museen und Restaurants ändern
sich etc. Es steht zu erwarten, dass Endanwender, wie beispielsweise
Fahrzeugbesitzer, die ein Navigationssystem in ihrem Fahrzeug haben,
die geographischen Daten in ihrem Navigationssystem von Zeit zu
Zeit auf den neuesten Stand bringen lassen möchten.
-
Die
stark anwachsende Anzahl oben genannter vielfältiger, unterschiedlicher,
inkompatibler Navigationssystemplattformen stellt auch ein Hindernis
bei der Bereitstellung aktualisierter Geodaten für Endanwender dar, d.h. Personen
und Gewerbebetriebe, die Navigationssysteme besitzen und verwenden.
Um dem Endanwender während
der Lebensdauer des Navigationssystems aktualisierte Geodaten für dessen
Navigationssystem bereitstellen zu können, muss der Anbieter von
geographischen Daten ein Erzeugnis liefern, das nicht nur aktualisierte
Geodaten aufweist, sondern auch mit dem speziellen Navigationssystem
des Anwenders kompatibel ist. Angesichts der erwarteten Lebensdauer
von Navigationssystemen, die 10 Jahre und länger sein kann, wäre es hierzu
erforderlich, eine wachsende Anzahl alter, inkompatibler Navigationssysteme
und -plattformen zu unterstützen.
Müssten
für jede
einzelne, unterschiedliche Navigationsplattformatart oder -version
spezielle Versionen aktualisierter Geodatenerzeugnisse hergestellt
werden, würde
die Anzahl unterschiedlicher Erzeugnisse im Laufe der Zeit ständig weiterwachsen
und die Bereitstellung von aktualisierten Geodatenerzeugnissen für Endanwender
somit schwierig und kostspielig werden.
-
Dementsprechend
ist es Aufgabe der vorliegenden Erfindung, eine Lösung für das Problem
der Bereitstellung geographischer Daten für verschiedene Hardware-Plattformen vorzusehen.
-
Ferner
ist es Aufgabe der vorliegenden Erfindung ein verbessertes Navigationssystem
und Navigations-Geodatenbank(en) zur Verwendung darin vorzusehen,
die über
verschiedene Navigationssystemplattformen, Betriebssysteme und Versionen
effizient entwickelt, hergestellt, an Kundenwünsche angepasst, vertrieben
und/oder aktualisiert werden können.
-
Die
Druckschrift EP-A-0 514 972 offenbart ein System zur verteilten
Datenverarbeitung, das ein verteiltes Echtzeit-Betriebssystem, Sensoren,
Anwender-E/A, Datenverarbeitung
und Massenspeicherung von geographischen Daten umfasst.
-
Die
Druckschrift EP-A-0 715 250 offenbart ein Verfahren zur Verarbeitung
einer Zugriffsanforderung in einem Rechnersystem mit einer Mehrzahl
Untersysteme.
-
ÜBERSICHT ÜBER DIE ERFINDUNG
-
Um
die vorgenannten sowie weitere Aufgaben zu lösen, und gemäß den Zwecken
der vorliegenden Erfindung, wird ein verbessertes Navigationssystem
entsprechend Anspruch 1 bereitgestellt. Es wird zudem eine Schnittstellenschicht
entsprechend Anspruch 23 bereitgestellt sowie ein verbessertes Verfahren
zur Verwendung eines Navigationssystems entsprechend Anspruch 28.
Das Navigationssystem ist von der Bauart, die ein Navigationsanwendungs-Softwareprogramm
umfasst, mit dem einem Systemanwender Navigationsmerkmale zur Verfügung gestellt
werden, sowie eine auf einem rechnerlesbaren Speicherträger gespeicherte geographische
Datenbank, wobei die geographische Datenbank Informationen über die
geographische Region umfasst, zu der das Navigationssystem die Navigationsmerkmale
für den
Anwender bereitstellt. Die Datenzugriffs-Schnittstellenschicht ist
vorzugsweise im Navigationssystem als Softwarefunktionsbibliothek
gespeichert. Die Datenzugriffsschicht arbeitet in Verbindung mit
der Navigationssystem-Anwendungssoftware. Die Datenzugriffs-Schnittstellenschicht
isoliert die Navigationsanwendungssoftware von den auf dem Speicherträger gespeicherten
geographischen Daten. Die Datenzugriffs-Schnittstellenschicht fängt Anfragen
der Navigationsanwendungssoftware nach geographischen Daten ab.
Die Datenzugriffs-Schnittstellenschicht ruft geographische Daten
vom Speicherträger
ab und wandelt die Daten in ein von der Navigationsanwendungssoftware
verwendbares Format um. Die Datenzugriffs-Schnittstellenschicht sorgt auch für Speichermanagement, durch
das der schnelle und effiziente Zugriff auf geographische Daten
vom jeweiligen Speicherträger
und deren Verwendung erleichtert wird. Die Datenzugriffs-Schnittstellenschicht
erkennt unterschiedliche Medientypen mit unterschiedlichen physikalischen
Formaten, erfasst und trennt die Unterschiede, so dass die mit der Navigationsanwendungssoftware
in Wechselwirkung stehenden Teile der Datenzugriffs-Schnittstellenschicht generisch
sein können.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
1 ist
eine grafische Darstellung eines Navigationssystems mit einem Speicherträger, auf
dem geographische Daten, und wahlweise weitere Daten, gespeichert
sind.
-
2 ist
eine grafische Darstellung von Softwarekomponenten im Navigationssystem
der 1.
-
3 ist
ein Blockdiagramm, das die Softwarekomponenten des Navigationssystems
der 1 mit den Hauptsystemen der Schnittstellenschicht
der 2 darstellt.
-
4 ist
ein Blockdiagramm, das eine Ausführungsform
der Ressourcenmanager-Softwarearchitektur der 3 darstellt.
-
5A und 5B sind
Darstellungen der internen Speicherung während des Betriebs des in der 3 gezeigten
Cursor-Managementsystems.
-
6 ist
ein Beispiel, das eine Paket-ID zeigt, die im Mapper physikalischer
Speicheradressen der 4 verwendet wird.
-
7 ist
ein Flussdiagramm, das das Verfahren zum Verknüpfen der Navigationsanwendungskomponente
mit der Datenschnittstellenschicht darstellt.
-
8 ist
ein Blockdiagramm, das eine weitere Ausführungsform der Ressourcenmanager-Softwarearchitektur
der 3 darstellt.
-
AUSFÜHRLICHE BESCHREIBUNG DER DERZEIT
BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
I. Überblick Navigationssystem
-
1 ist
eine grafische Darstellung, die beispielhaft eine Konfiguration
eines Navigationssystems 10 zeigt. Das Navigationssystem 10 ist
eine Kombination aus Hardware- und Softwarekomponenten. In einer
Ausführungsform
umfasst das Navigationssystem 10 einen Prozessor 12,
ein mit dem Prozessor 12 verbundenes Laufwerk 14 sowie
eine Speichervorrichtung 16, wie beispielsweise ein ROM,
zum Speichern eines Navigationsanwendungs-Softwareprogramms 18.
Das Navigationsanwendungs-Softwareprogramm 18 wird vom
ROM 16 in einen dem Prozessor 12 zugeordneten
Speicher 20 geladen, um das Navigationssystem zu bedienen. Der
Prozessor 12 kann von jeglicher in Navigationssystemen
verwendeter Bauart sein, wie 32-Bit-Prozessoren, die einen linearen
Adressraum verwenden, beispielsweise ein Hitachi SH1, ein Intel
80386, ein Intel 960, ein Motorola 68020 (oder andere Prozessoren
mit ähnlichem
oder größerem Adressraum).
Es eignen sich auch andere als die genannten Prozessortypen sowie
Prozessoren, die zukünftig
möglicherweise
noch entwickelt werden. Im Laufwerk 14 ist ein Speicherträger 22 installiert.
In einer vorliegenden Ausführungsform
ist der Speicherträger 22 eine
CD-ROM. In einer anderen alternativen Ausführungsform kann der Speicherträger 22 eine
PC-Karte (PCMCIA-Karte) sein, wobei das Laufwerk 14 in
diesem Fall durch einen PCMCIA-Steckplatz ersetzt würde. Verschiedene
andere Speicherträger
können
verwendet werden, einschließlich
Festplatten, DVD (digitale Videodisketten) oder andere derzeit verfügbare Speicherträger, sowie Speicherträger, die
zukünftig
möglicherweise
noch entwickelt werden. Der Speicherträger 22 umfasst geographische
Daten, wie in der oben genannten gleichzeitig anhängigen Anmeldung
mit dem Titel „IMPROVED
SYSTEM AND METHOD FOR USE AND STORAGE OF GEOGRAPHIC DATA IN PHYSICAL
MEDIA" ausführlicher
beschrieben ist.
-
Das
Navigationssystem 10 kann auch ein Positionsbestimmungssystem 24 umfassen.
Das Positionsbestimmungssystem 24 kann eine Technologie
vom Typ GPS, ein System vom Typ Koppelnavigation oder Kombinationen
derselben oder andere Systeme verwenden, die im Stand der Technik
alle bekannt sind. Das Positionsbestimmungssystem 24 gibt
ein Signal 26 an den Prozessor 12 aus. Das Signal 26 kann
von der auf dem Prozessor 12 laufenden Navigationsanwendungssoftware 18 zur
Bestimmung des Standorts, der Richtung, Geschwindigkeit etc. des
Navigationssystems 10 verwendet werden. Das Navigationssystem 10 verwendet
die auf dem Speicherträger 22 gespeicherten
geographischen Daten, gegebenenfalls in Verbindung mit dem Ausgangssignal 26 des
Positionsbestimmungssystems 24, um verschiedene Navigationsanwendungsmerkmale
bereitzustellen. Diese Navigationsanwendungsmerkmale können Streckenberechnung,
Kartenanzeige, Fahrzeug-Positionsbestimmung (z.B. Kartenabgleich),
Manövergenerierung
(wobei zum Erreichen eines gewünschten
Ziels detaillierte Richtungsanweisungen gegeben werden) sowie weitere
Merkmale umfassen. Diese Navigationsanwendungsmerkmale werden von
Navigationsanwendungsprogrammen (d.h. Unterprogramme oder Funktionen)
bereitgestellt, die zum Navigationsanwendungs-Softwareprogramm 18 gehören. Die
Navigationsmerkmale werden dem Anwender (z.B. dem Fahrer des Fahrzeugs)
mittels einer Anzeige 27, Lautsprechern 29 oder
anderen Mitteln zur Verfügung
gestellt.
-
In
der 2 umfasst das Navigationsanwendungs-Softwareprogramm 18 separate
Anwendungen (oder Unterprogramme) 200. Für die Navigationsanwendungsprogramme 200 des
Navigationssystems 10 kann angenommen werden, dass sie
Streckenberechnungsfunktionen, Manövergenerierfunktionen, Kartenanzeigefunktionen,
Fahrzeugpositionsbestimmungsfunktionen, Zielauflösungsfähigkeiten und so weiter umfassen.
Die 2 zeigt diese separaten Navigationsanwendungen 200,
darunter eine Streckenberechnungsfunktion 28, eine Kartenanzeigefunktion 30,
eine Manövergenerierfunktion 32 sowie
weitere Funktionen oder Unterprogramme 34. Diese Navigationsanwendungs-Unterprogramme
sind zwar als separate Funktionen oder Anwendungen innerhalb des
Navigationsanwendungs-Softwareprogramms 18 dargestellt,
diese Funktionen können
jedoch kombiniert und als ein einziges Programm bereitgestellt werden.
-
In
der 2 weist der Speicherträger 22 auf ihm gespeicherte
geographische Daten 40 auf. Die geographischen Daten 40 liegen
in Form einer oder mehrerer rechnerlesbarer Dateien oder Datenbanken
vor. Die geographischen Daten 40 können Informationen über die
Lage von Straßen
und Kreuzungen in oder bezogen auf einen bestimmten geographischen
Regionalbereich umfassen sowie Informationen über Einbahnstraßen, Abbiegeverbote,
Hausadressen, Alternativstrecken, Hotels, Restaurants, Museen, Stadien,
Büros,
Autohändler,
Autowerkstätten
etc. Die geographischen Daten 40 sind derart in einem Format
organisiert und auf dem Speicherträger 22 gespeichert,
dass Verwendung und Zugriff durch die Navigationsanwendungsfunktionen 200 des
Navigationsanwendungsprogramms 18 erleichtert werden. Organisation
und Speicherung der geographischen Daten 40 sind in der
oben genannten gleichzeitig anhängigen
Anmeldung mit dem Titel „IMPROVED
SYSTEM AND METHOD FOR USE AND STORAGE OF GEOGRAPHIC DATA ON PHYSICAL
MEDIA" ausführlicher
beschrieben.
-
Die
verschiedenen, separaten Navigationsanwendungen 200 der
Navigationsanwendungssoftware 18 greifen auf Teile der
geographischen Daten 40 auf dem Speicherträger 22 zu
und lesen diese, um dem Anwender des Navigationssystems 10 nützliche
Navigationsmerkmale zur Verfügung
zu stellen. In einer vorliegenden Ausführungsform befindet sich zwischen
den verschiedenen Navigationsanwendungen 200 (wie beispielsweise
die Funktionen 28, 30, 32 und 34)
und dem Geodatensatz 40 eine Datenzugriffs-Schnittstellenschicht 41. Die
Datenzugriffs-Schnittstellenschicht 41 isoliert die Navigationsanwendungsfunktionen 200 von
Formatierung, Speicherung und anderen Details hinsichtlich der geographischen
Daten 40. Dementsprechend sorgt die Datenzugriffs-Schnittstellenschicht 41 dafür, dass
mehrere unterschiedliche Navigationssystemplattformen ein gemeinsames
Geodatenbankerzeugnis, d.h. den auf dem Speicherträger 22 gespeicherten
Geodatensatz 40 verwenden können. Zusätzlich ermöglicht die Datenzugriffs-Schnittstellenschicht 41 dem
Endanwender eine leichtere Aktualisierung der geographischen Daten
in seinem Navigationssystem.
-
II. Datenzugriffs-Schnittstellenschicht – Überblick
-
Die
Datenzugriffs-Schnittstellenschicht 41 ist eine Softwarekomponente,
die im Navigationssystem 10 residieren kann. In einer bevorzugten
Ausführungsform
ist zumindest ein Teil der Datenzugriffs-Schnittstellenschicht 41 mit
dem ausführbaren,
die Navigationsanwendungssoftware 18 im Navigationssystem 10 bildenden Modul
verlinkt oder in dieses einkompiliert, wobei die Navigationsanwendungssoftware
beim Betrieb des Navigationssystems 10 vom ROM 16 in
den Speicher 20 (1) geladen
wird. Innerhalb der Datenzugriffs-Schnittstellenschicht 41 existieren
mehrere Untersystemkomponenten. Es gibt interne Schnittstellen zwischen
diesen Untersystemkomponenten sowie externe Schnittstellen zu den
Navigationsanwendungs-Softwarekomponenten 200 und dem Betriebssystem 202 des
Navigationssystems 10. Den Navigationsanwendungen werden
Daten als logische Datenentitäten
präsentiert.
Die logischen Datenmodellentitätssätze haben
eine feste Länge
und enthalten dekomprimierte Daten ohne jegliche Querverweisinformationen.
-
In
einer bevorzugten Ausführungsform
ist die Datenzugriffs-Schnittstellenschicht 41 in
Form einer Bibliothek mit Softwarefunktionen vorgesehen. Diese Funktionsbibliothek
ermöglicht
Datenzugriff zur Verwendung durch die verschiedenen Komponenten
oder Unterprogramme 200 des Navigationsanwendungs-Softwareprogramms 18.
In einer bevorzugten Ausführungsform
sind einige oder alle dieser Bibliotheksfunktionen direkt mit den
verschiedenen Navigationsanwendungen 200 verknüpft, um
das Navigationssoftwareerzeugnis 18 zu bilden. Die Datenzugriffs-Schnittstellenschicht 41 ist
also in die Navigationsanwendungssoftware der Navigationssysteme
von OEM-Herstellern (Ersthersteller) oder der im Zubehörhandel
erhältlichen
Kraftfahrzeug-Navigationssysteme integriert, die eine separat gespeicherte
Geodatenbank verwenden. In nachfolgend behandelten alternativen
Ausführungsformen
kann die Datenzugriffs-Schnittstellenschicht 41 in Navigationssystemen
integriert sein, die nicht im Fahrzeug eingebaut sind.
-
In
einer bevorzugten Ausführungsform
ist der Quellcode zwar in der Programmiersprache C geschrieben,
in alternativen Ausführungsformen
können
jedoch andere Sprachen verwendet werden.
-
Da
die Datenzugriffs-Schnittstellenschicht 41 mit mehreren
unterschiedlichen Navigationssystemen verwendet wird, trägt die Schnittstellenschicht 41 den
Unterschieden zwischen diesen Systemen Rechnung. Einige in Fahrzeuge
eingebaute Navigationssysteme weisen relativ kleines RAM auf, langsame
E/A-Geräte sowie
proprietäre
und/oder echtzeitorientierte Betriebssystemkernels. Einige dieser
Navigationssysteme errechnen eine optimale Strecke und geben dem
Endanwender eine Führungsanleitung
in Echtzeit und für
jede einzelne Abzweigung. Dementsprechend ist es von Vorteil, verschiedene
Positions- und Richtungs-Sensorinformationen
in Echtzeit und im Hintergrund zu integrieren. Einige dieser Navigationssysteme
weisen auch eine kartographische Anzeige, eine flexible Fähigkeit
zum Erhalten von Streckenzielpunkten sowie eine an kraftfahrzeuginterner
Ergonomie orientierte Schnittstelle auf.
-
Wie
oben erwähnt,
isoliert die Datenzugriffs-Schnittstellenschicht 41 die
Navigationsanwendungssoftware 18 von Größe, Komplexität und Weiterentwicklung
der Geokartendatenbank 40 auf dem physikalischen Träger 22.
In einer bevorzugten Ausführungsform
können ähnliche
oder identische Datenzugriffs-Schnittstellenschichten
von unterschiedlichen Navigationssystemen verwendet werden. Die
Datenzugriffs-Schnittstellenschicht 41 ist über verschiedene
Hardware-Plattformen
portabel. Die Datenzugriffs-Schnittstellenschicht 41 sorgt
für Flexibilität, um einen
Großteil
oder die gesamte geplante Navigationsanwendungsfunktionalität über eine
breite Palette von Produktfähigkeiten
und Hardware-Plattformen zu unterstützen. In einer bevorzugten Ausführungsform
verwendet die die Datenzugriffs-Schnittstellenschicht
umfassende Softwarebibliothek weniger als 256 KBytes Speicher und
16 KBytes Stapelspeicher sowie mindestens 256 KBytes Haldenspeicher.
-
Wie
oben erwähnt,
sind die geographischen Daten 40 auf der Speichervorrichtung 22,
wie beispielsweise einer CD-ROM, gespeichert. In einer bevorzugten
Ausführungsform
sind die geographischen Daten unter Verwendung einiger oder aller
physikalischen Speicherformatmerkmale, die in der oben genannten
gleichzeitig anhängigen
Anmeldung mit dem Titel „IMPROVED
SYSTEM AND METHOD FOR USE AND STORAGE OF GEOGRAPHIC DATA IN PHYSICAL MEDIA" offenbart sind,
gespeichert. Die im physikalischen Speicherformat verwendeten Merkmale
sorgen für
effizienten Zugriff auf die geographischen Daten und zugehörige Drittdaten
(„TPD"). Unterschiedliche
Speicherträgertypen
weisen charakteristische Datenkapazitäten und Zugriffseigenschaften
auf. Dementsprechend tragen die in der gleichzeitig anhängigen Anmeldung
offenbarten physikalischen Speicherformatmerkmale den verschiedenen
zur Verwendung in Navigationssystemen bestimmten Trägern Rechnung.
Die vorliegende Ausführungsform
der Datenzugriffs-Schnittstellenschicht 41 verwendet zwar
das in der gleichzeitig anhängigen
Anmeldung offenbarte physikalische Speicherformat, jedoch können einige
oder alle Merkmale der hierin offenbarten Datenzugriffs-Schnittstellenschicht
mit anderen Formaten verwendet werden.
-
Wie
in der gleichzeitig anhängigen
Anmeldung beschrieben, werden die geographischen Daten auf dem Träger mit
Hilfe eines Geodatensatz-Compilers gespeichert. Der Compiler akzeptiert
geographische Daten und zugehörige
Drittdaten in einem Austauschformat. Die geographischen Daten und
Drittdaten werden dem Compiler eingegeben, der eine Ausgabe in Form
eines geeigneten physikalischen Speicherformats erzeugt. Die geographischen
Daten können
von der Navigation Technologies in Sunnyvale, Kalifornien, herausgegeben
sein.
-
3 ist
ein Blockdiagramm des Navigationssystems 10, das Komponenten
der Datenzugriffs-Schnittstellenschicht 41 zeigt. In der 3 liegt
die Datenzugriffs-Schnittstellenschicht 41 in
der Navigationsanwendungssoftware 18 logisch unter den
Navigationsanwendungsprogrammen 200 und über dem
Betriebssystem 202. Dies gestattet es der Datenzugriffs-Schnittstellenschicht 41,
auf die Datenzugriffsanfragen der verschiedenen Navigationsanwendungs-Softwareprogramme 200 anzusprechen.
-
Für die die
Datenzugriffs-Schnittstellenschicht 41 bildende Software-Bibliothek
kann angenommen werden, dass sie aus drei Hauptuntersystemen besteht.
Das oberste Untersystem ist das Untersystem 210 der Datenzugriffs-Programmierschnittstellen-Abfragelogik
(„DQL" oder „Abfragelogik"). Das Abfragelogik-Untersystem 210 sieht
eine Funktionsaufruf-Schnittstelle 212 zu den Navigationsanwendungs-Softwareprogrammen 200 vor.
Die Datenzugriffs-Schnittstellenschicht 41 definiert
eine Datenstrukturansicht (als „logisches Datenmodell" oder „LDM" bezeichnet) der
geographischen Daten 40 auf dem Speicherträger 22 für die Navigationsanwendungsprogramme 200.
-
In
einer derzeit bevorzugten Ausführungsform
ist die von der Schicht 41 definierte Datenstrukturansicht
in der C-Sprache. Wie oben erwähnt,
repräsentiert
das logische Datenmodell die Entitäten in vollständig dekomprimierter
Form. Die Entitäten
in der logischen Datenmodellform sind nicht komprimiert. Dies führt zwar zu
Platzverschwendung innerhalb der Datenentitäten, erleichtert jedoch die
unmittelbare Verwendung der Datenentitäten durch die Navigationsanwendung.
Jede der Datenentitäten
eines gegeben Typs kann eine feste, bekannte vorbestimmte Größe haben.
In einer bevorzugten Ausführungsform
umfassen Entitäten
in einem logischen Datenformat zudem keine Querverweisinformationen
oder andere Informationsarten, die vor Verwendung der Daten durch
die Navigationsanwendung eine Verarbeitung bedingen.
-
Das
Abfragelogik-Untersystem 210 umfasst einen Satz Funktionsaufrufe,
die es den Navigationsanwendungsprogrammen 200 erlauben,
einen bestimmten Entitätssatz
im logischen Datenmodellformat anzufordern. Das Abfragelogik-Untersystem 210 implementiert
auch die Logik, die die angeforderten Entitäten lokalisiert und den resultierenden
Datensatz verwaltet, der dann an die anfragende Komponente der Navigationsanwendungsprogramme 200 zurückgegeben
wird.
-
Das
Abfragelogik-Untersystem 210 löst Datenzugriffsabfragen in
Form von Unterteilungen der physikalischen Träger auf, die als „Pakete" bezeichnet werden
und die angeforderten Daten im physikalischen Speicherformat der
geographischen Daten 40 auf dem Träger 22 beinhalten.
Das Abfragelogik-Untersystem 210 sorgt auch für die Verwaltung
des Abfrageergebnissatzes, was im Sinne eines „Cursors" für
die Abfragen, die mehr als eine Eintragung zurückgeben können, ausgedrückt werden
kann. Der Cursor ist ein Konstrukt, der es den Navigationsanwendungsprogrammen
erlaubt, auf Teile eines großen
Abfrageergebnissatzes zuzugreifen, ohne dass eine speicherinterne
Kopie von jedem Datensatz in umgesetzter logischer Datenmodellform
erforderlich ist.
-
Unterhalb
des Abfragelogik-Untersystems 210 befindet sich ein Indexmanagement-
und Datenumsetzungs-(IMN)-Untersystem 216. Das Indexmanagement-
und Datenumsetzungs-Untersystem 216 weist mehrere separate
Funktionen auf. Die erste Funktion verwendet Indexinformationen,
um Daten für
physikalische Entitäten,
die auf dem Träger
gespeichert sind, nach Anweisung des Abfragelogik-Untersystems 210 zu
lokalisieren. Eine zweite von dem Indexmanagement- und Datenumsetzungs-Untersystem 216 zur
Verfügung
gestellte Funktion ist das Entpacken oder sonstig geartete Dekomprimieren
der optimierten Entitäten
und das Umwandeln der Entitäten
in die logischen Datenmodelldatenentitäten, die an das anfragende
Navigationsanwendungsprogramm 200 zurückgegeben werden. Wenn die
auf dem Träger
gespeicherten geographischen Daten 40 gepackt oder komprimiert
sind, dient die vom Untersystem 216 bereitgestellte zweite
Funktion auch dazu, die optimierten physikalischen Entitäten zu entpacken
oder in sonstiger Weise zu dekomprimieren, so dass sie in das logische
Datenmodellformat umgewandelt werden können. Eine weitere Funktion
des Indexmanagement- und Datenumsetzungs-Untersystems ist das Bereitstellen
von Aufwärts-/Abwärtskompatibilität über verschiedene
Versionen, wie weiter unten erklärt
wird.
-
Unterhalb
des Indexmanagement- und Datenumsetzungs-Untersystems 216 befindet
sich das Ressourcenmanagement-Untersystem 220. Wie oben
erwähnt,
sind in einigen Navigationssystemen der Speicherumfang und die E/A-Bandbreite
relativ gering. Herkömmliche
Techniken zur Verwaltung dieser Ressourcen können begrenzt sein. In manchen
Navigationssystemen besteht beispielsweise ein Ansatz zur Lösung von Leistungsproblemen
aufgrund langsamer E/A darin, Speicher zum Cachen von Daten zu verwenden
und dadurch die physikalische E/A zu minimieren. Doch auch in diesen
Navigationssystemtypen kann der Speicherplatz begrenzt sein, insbesondere,
wenn mehrere Funktionen der Navigationsanwendung 200 möglicherweise gleichzeitig
arbeiten müssen.
-
Ein
verbesserter Lösungsansatz
zum Ressourcenmanagement wird durch die vorliegende Ausführungsform
bereitgestellt. In der vorliegenden Ausführungsform ist die Datenzugriffs-Schnittstellenschicht 41 mit ihrem
eigenen Ressourcenmanagement-Untersystem 220 ausgestattet,
das von jeglicher von den Navigationsanwendungs-Programmen 200 bereitgestellter
Ressourcenmanagementfunktion getrennt ist. Die Schnittstellenschicht 41 ist
mit einem Teil des Navigationssystemspeichers versehen, den ausschließlich sie
nutzen darf und der vom Ressourcenmanagement-Untersystem 220 verwaltet
wird. Darüber
hinaus besitzt das Ressourcenmanagement-Untersystem 220 die
Fähigkeit,
zusätzliche
Teile des Navigationssystemspeichers zu nutzen, wenn diese nicht
von den Navigationsanwendungsprogrammen benötigt werden. Das Ressourcenmanagement-Untersystem 220 sorgt
für verbessertes
Speicher- und E/A-Management,
indem es sich auf Datenzugriffsanforderungen des Abfragelogik- Untersystems unter
Berücksichtigung
der spezifischen Datenorganisation des physikalischen Speicherformats
konzentriert. Das Ressourcenmanagement-Untersystem 220 vermittelt
Zugriff auf Cachespeicherpuffer and den physikalischen E/A-Kanal
für Datenzugriffstasks.
Der Verwaltung dieser Ressourcen kommt auch die Koordination von
Aktionen und Datenbedarf über
der Ebene der Datenzugriffs-Schnittstellenschicht 41,
d.h. in der Software der Navigationsanwendungsprogramme 200,
zugute. Der Datenzugriffsbedarf der Navigationsanwendungsprogramme 200 dient
als Hilfe, um zu bestimmen, welche Daten im Cachespeicher behalten
werden sollen. Ein vorteilhafter Weg, dem Ressourcenmanagement-Untersystem 220 diese
Informationen zur Verfügung
zu stellen, besteht in zusätzlichen
Zugriffsprogrammparametern, die es der Datenzugriffs-Schnittstellenschicht 41 erlauben,
im Hintergrund Daten für
eine zu erwartende zukünftige
Verwendung vorzubereiten. Dies geschieht zusätzlich zu den Datenzugriffsaufrufen,
wenn das Navigationsanwendungsprogramm auf unmittelbar benötigte Daten
wartet. Darüber
hinaus kann das Ressourcenmanagement-Untersystem 220 Parameter
akzeptieren, die eine Steuerung der Reihenfolge der Datenzugriffe
auf den physikalischen Träger
ermöglichen.
-
Im
Folgenden wird jedes dieser Schnittstellenschicht-Untersysteme näher erläutert.
-
III. Abfragelogik-(DQL)-Untersystem 210
-
Das
Abfragelogik-Untersystem 210 repräsentiert eine Ebene der Softwarebibliothek,
die die Datenzugriffs-Schnittstellenschicht 41 bildet.
Das Abfragelogik-Untersystem 210 implementiert eine Schnittstelle 212 zu
den Navigationsanwendungsprogrammen 200, indem sie der
Navigationsanwendung 200 eine Ansicht der Geodatenbank
zur Verfügung
stellt. In einer vorliegenden Ausführungsform ermöglicht die
Datenzugriffsschnittstelle 41 Datenzugriff. Die Datenzugriffsschnittstelle 41 definiert
einen Satz Datenstrukturen in der C-Sprache (logisches Datenmodell)
und einen Satz Funktionsaufrufe, die diese logischen Datenmodell-Entitäten an die
Navigationsanwendungs-Softwareprogramme 200 liefern, die
die Funktionsaufrufe für
den Zugriff auf die geographischen Daten verwenden. (Zwar ist eine
bevorzugte Ausführungsform
der Datenschnittstellenschicht 41 als C-Sprachen-Struktur
definiert, die Schnittstellenschicht kann jedoch in jeder geeigneten
Programmiersprache definiert sein). In einer bevorzugten Ausführungsform
wird jeder der durch die Navigationsanwendungsprogramme gemachten
Datenzugriffs-Schnittstellenschicht-Funktionsaufrufe als Wrapper um einen
entsprechenden Funktionsaufruf im Abfragelogik-Untersystem 210 implementiert.
-
Im
Allgemeinen stellt das Abfragelogik-Untersystem 210 den
Navigationsanwendungsprogrammen drei Arten der Datenzugriffsmöglichkeit
zur Verfügung.
Eine Art des durch das Abfragelogik-Untersystem zur Verfügung gestellten
Datenzugriffs erlaubt es den Navigationsanwendungsprogrammen, eine
bestimmte Datenentität
anhand ihrer Datenbankkennung (DBID) anzufordern. Das Abfragelogiksystem 210 stellt
der Navigationsanwendung die angeforderte Datenentität im logischen
Datenmodellformat zur Verfügung.
Eine weitere Art des durch das Abfragelogik-Untersystem 210 zur
Verfügung
gestellten Datenzugriffs erlaubt es den Navigationsanwendungen,
einen Satz Datenentitäten
anzufordern, die mit einer bestimmten Datenentität in Beziehung stehen. Das
Abfragelogik-Untersystem
stellt der Navigationsanwendung einen Cursor (Erläuterung
folgt weiter unten) auf den resultierenden Datenentitätssatz zur
Verfügung.
Einige oder alle der Datenentitäten
im resultierenden Satz können
im logischen Datenformat sein. Eine dritte Art des durch das Abfragelogik-Untersystem
zur Verfügung
gestellten Datenzugriffs erlaubt es der Navigationsanwendung, Daten
auf Grundlage einer Suchanfrage zu erhalten. Das Abfragelogik-Untersystem
gibt einen Cursor auf einen resultierenden Satz Datenentitäten zurück, die
mit den Suchkriterien übereinstimmen.
-
Die
die Schnittstelle 212 bildenden Funktionen erlauben es
den Navigationsanwendungsprogrammen 200, eine bestimmte
Entität
oder Entitätsgruppe
(wie beispielsweise „Knoten", „Orte", „Segmente", „Points-of-Interest", „Postleitzahlen" und so weiter) anzufordern,
die durch eine bestimmte Teilmenge von Attributen (wie beispielsweise „alle Segmente
mit einem Endpunkt am Knoten X" oder „alle Gemeinden,
die „See" als Namensbestandteil
aufweisen" und so
weiter), die entweder direkt Teil der Entität oder in sonstiger Weise eng
mit der Entität
verknüpft
sind, näher
bestimmt werden können.
Alternativ können
diese Anfragen auch durch geographische Parameter oder Attribute
näher bestimmt
werden, wie beispielsweise alle Segmente innerhalb eines vorgegebenen
rechteckigen Bereichs oder innerhalb eines bestimmten benannten
Ortes. Die geographischen Kennzeichner können auf die primären Kartendatenentitäten angewandt
werden und bei der Eingrenzung einer Suche nach gewünschten
Daten nützlich
sein.
-
Die
Funktionen im Abfragelogik-Unterprogramm 210 sorgen für pervasiven
Zugriff auf Daten. Dies bedeutet, dass der Zugriff auf jede beliebige
logische Datenmodellentität
ungeachtet des Navigationsanwendungszweckes durch ein angemessenes
Leistungsniveau unterstützt
wird. Beispielsweise kann die Streckenführungssoftware 28 (2)
Zugriff auf Daten über
Points-of-Interest fordern. Die Unterstützung für pervasiven Datenzugriff erfolgt
ungeachtet der auf der Ebene des physikalischen Speicherformats
erfolgenden Entitätsklassifizierung
zur Leistungsoptimierung des Datenzugriffs auf den Basissatz von
Entitäten,
die für
wichtige Funktionen wie Streckenberechnung oder Kartenanzeige erforderlich
sind. Pervasiver Datenzugriff bietet eine gewisse Synergie mit den
geographischen Abfragekennzeichnern. Beispielsweise sind für geometrische
Daten wie Segmente oder Knoten Abfragen rechteckförmiger Flächen üblich, die
aber auch für
Straßennamen und
Points-of-Interest nützlich
sein können.
-
Das
Abfragelogik-Untersystem 210 ist auch in der Lage, eine
prädiktive
Datenzugriffstransaktion zu initiieren, z.B. wenn Daten nicht sofort
verlangt werden, aber deren baldiger Bedarf erwartet wird. Diese
Art der Datenzugriffstransaktion läuft vorzugsweise im Hintergrund
ab, so dass die Navigationsanwendungsprogramme ihre Arbeit fortsetzen
können.
Das Abfragelogik-Untersystem 210 als solches ist dazu fähig, diese
prädiktiven
Zugriffsaufrufe zusätzlich
zu den normalen Zugriffsaufrufen, bei denen die Daten unmittelbar
verlangt werden, durchzuführen.
Diese Funktion stimmt sich mit den Navigationsanwendungsprogrammen 200 ab,
um vorherzusagen, welche Daten möglicherweise
als nächstes
angefordert werden.
-
Einige
der Abfragelogik-Untersystemfunktionen geben eine einzige Entität oder ein
zusätzliches
Detail über
eine bestimmte Entität
zurück.
Andere Funktionen wiederum geben eine unvorhersagbare Anzahl Entitäten zurück. Diese
Anzahl könnte
unter Umständen,
abhängig
von der jeweiligen Abfrage und ihrem Qualifikationsgrad, recht groß sein.
Daher umfassen diese Abfragelogik-Untersystemfunktionen ein Cursormanagement-Untersystem 249.
Ein Cursor wird zum Zeitpunkt der Abfrage definiert. Der Cursor
bildet ein Fenster (Erklärung
unten) eines von der Abfrage erstellten Ergebnissatzes willkürlicher
Größe. Der
Cursor erlaubt es der Navigationsanwendung vorzugeben, wie viele
Entitäten
jeweils auf einmal zurückgegeben
werden sollen, wenn Daten durch den Cursor abgerufen werden. Cursormanagement-Mehrzweckfunktionen
in der Datenzugriffs-Programmierschnittstelle 212 erlauben
es den Navigationsanwendungs-Softwareprogrammen 200,
dieses Fenster dann in flexibler und praktischer Art und Weise zu
bewegen.
-
A. Abfrageauflösung
-
Das
Datenabfragelogik-Untersystem 210 implementiert die Schnittstelle
zu den Navigationsanwendungsprogrammen 200 dadurch, dass
es die Abfragen von den Programmen in einen Satz als Pakete bezeichnete
physikalische Datenunterteilungen auflöst, die auf den Trägern vorhanden
sind. Diese Pakete können räumlich organisierte
Daten, nicht-räumliche
Daten, Indexinformationen oder andere Daten enthalten. Sobald die
Pakete in Antwort auf eine Abfrage identifiziert sind, werden sie
in den Speicher gelesen. Innerhalb eines Pakets können die
Daten noch weiter in Teilmengen organisiert sein, um die Menge an
Daten, die in einem Paket zur Auflösung einer Abfrage untersucht
werden müssen,
zu minimieren. Die geeigneten Pakete oder Paketdatenteilmengen werden
identifiziert, und innerhalb dieser Pakete oder Paketdatenteilmengen
werden Entitäten
lokalisiert, damit das Datenabfragelogik-Untersystem 210 einen
Cursorergebnissatz für
eine bestimmte Anfrage erstellen kann. Alternativ kann bei einfacheren
Abfragen, die immer einen einzigen Datensatz zurückgeben und keine Erstellung
eines Cursors bedingen, ein einziger logischer Datensatz direkt
an die Navigationsanwendungs-Softwareprogramme 200 zurückgegeben
werden. Bei beiden Lösungsansätzen werden
jedoch ein oder mehrere physikalische Pakete lokalisiert und erhalten,
die letzten Endes im physikalischen Speicherformat auf dem Speicherträger 22 residieren,
und es wird eine Teilmenge der Paketdaten physikalisch untersucht,
um die den Ergebnissatz bildenden Entitäten zu lokalisieren. Sobald
der Ergebnissatz identifiziert ist, werden die Entitäten in das
logische Datenmodellformat umgewandelt und an die Navigationsanwendungs-Softwareprogramme 200 zurückgegeben.
-
Für Abfrageauflösungen werden
Informationen über
das jeweilige auf dem Speicherträger 22 verwendete
physikalische Speicherformat benötigt.
Die Datenzugriffs-Schnittstellenschicht 41 isoliert die
vom spezifischen physikalischen Speicherformat abhängigen Teile
ihrer Softwarebibliothek, so dass andere Komponenten ihrer Bibliothek
von einem jeweiligen physikalischen Format unabhängig sein können. Die vom Speicherformat
abhängigen
Komponenten sind im Indexmanagement- und Datenumsetzungs-Untersystem 216 enthalten.
Dieses Untersystem 216 umfasst zwei weitere Untersysteme:
das Indexmanagement- und -navigationsuntersystem 242 sowie
das Untersystem 244 zur physikalisch-logischen Datenumsetzung.
-
Es
werden mindestens zwei Lösungsansätze angewandt,
um die Zugriffe auf den physikalischen Träger zu minimieren. Ein Lösungsansatz
besteht darin, Indexinformationen innerhalb von Paketen zu verwenden,
um nach Daten zu suchen. Ein weiterer Lösungsansatz besteht darin,
Datenentitäts-IDs
zu verwenden, die explizit das Paket identifizieren, in dem sich
die Datenentität
befindet. (Der letztgenannte Lösungsansatz wird
in der oben erwähnten
gleichzeitig anhängigen
Anmeldung näher
beschrieben.) Sowohl Indexinformationen als auch explizite Datenentitäts-IDs dienen
dazu, eine Abfrage auf Paket-, Paketunterteilungs- oder Datensatzebene
aufzulösen.
Der Ort und die Art der verfügbaren
Indexinformation hängen
vom physikalischen Speicherformat ab. Daraus ergibt sich auch, dass
der Algorithmus zum Navigieren im Index auch vom physikalischen
Format abhängt.
Die Funktion zum Navigieren im Index auf dem physikalischen Träger ist
im Indexmanagement- und -navigationsuntersystem 242 enthalten.
Dementsprechend ist die Umwandlung komprimierter Daten aus dem Format
auf dem physikalischen Träger
in eine für
die Abfrageauflösung
und Umsetzung in das logische Datenmodellformat zur Rückgabe an
das Navigationsanwendungsprogramm geeignete Form im Untersystem
zur physikalisch-logischen Datenumsetzung 244 enthalten.
-
Der
durch das Abfragelogik-Untersystem 210 bereitgestellte
Abfrageauflösungsprozess
hängt für den Datenzugriff
von den formatabhängigen
Diensten ab, die vom Indexmanagement- und -navigationsuntersystem 242 und
dem physikalisch-logischen Untersystem 244 zur Verfügung gestellt
werden. Die Implementierung des Abfragelogik-Untersystems 210 kann
daher generisch und vom physikalischen Speicherformat unabhängig sein.
Der Abfrageauflösungsprozess
macht auch von Diensten auf unterer Ebene Gebrauch, um Pakete vom
physikalischen Träger
oder Cachespeicher und private dynamische Speicherpuffer zu erhalten.
Diese Dienste werden vom Ressourcenmanagement-Untersystem (SRM) 220 bereitgestellt.
Das Indexmanagement- und -navigationsuntersystem 242, das
physikalisch-logische Untersystem 244 und das Ressourcenmanagement-Untersystem 220 errichten
eine Grundlage für
den Abfrageauflösungsprozess
und erscheinen logisch unterhalb der Ebene des Datenabfragelogik-Untersystems 210 in 3.
Bei dieser schichtartigen Methode werden zwischen dem Datenabfragelogik-Untersystem 210 und
sowohl dem Indexmanagement- und -navigationsuntersystem 242 als
auch dem physikalisch-logischen Untersystem 244 zusätzliche
Schnittstellen definiert.
-
Eine
Schnittstelle 248 im Indexmanagement- und -navigationsuntersystem 242 entnimmt
dem Datenabfragelogik-Untersystem 210 ein Index-Spezifikationselement
und Abfrageparameter-Informationen und gibt einen Satz Paketkennungen
zurück.
Eine Paketkennung ist ein formatspezifisches Konstrukt zur Identifizierung
des Pakets, welches mit der physikalischen Organisation der Daten
im physikalischen Speicherformat auf dem Träger in Beziehung steht. Die
Paketkennungen werden dann an das Ressourcenmanagement-Untersystem 220 geleitet,
um einen Zeiger auf das physikalische Paket im Speicher zu erhalten.
Eine weitere Schnittstelle 250 im Indexmanagement- und
-navigationsuntersystem 242 sorgt für die Umsetzung einer vom Navigationsanwendungsprogramm 200 über das
Datenabfragelogik-Untersystem 210 weitergeleiteten spezifischen
Entitätskennung
in eine Kennung für
das diese Entität
enthaltende Paket. Um eine Abfrage noch weiter in eine bestimmte
Paketdatenteilmenge oder einen Datensatz aufzulösen, sind zwischen der Datenabfragelogik 210 und
dem Indexmanagement- und -navigationsuntersystem 242 zusätzliche
Schnittstellen 253 erforderlich. Die über diese Schnittstelle 253 weitergeleiteten
Abfrageparameter werden vom Indexmanagement- und -navigationsuntersystem 242 zur
Navigation im internen Index des Pakets (d.h. dem Index für die Paketdatenteilmengen)
verwendet, um die entsprechende Paketdatenteilmenge oder den Datensatz
zu lokalisieren.
-
Wenn
keine internen Indexinformationen vorhanden sind, um eine Abfrage
in eine bestimmte Entität oder
einen Entitätssatz
innerhalb des Pakets aufzulösen,
wird auf Ebene des Datenabfragelogik-Untersystems 210 eine
Brute-Force-Datensatzprüfung oder
Binärsuchtechniken
bereitgestellt. Bei Verwendung dieser Methoden werden die Entitäten in einem
dekomprimierten Zwischenformat („DIF") dargestellt, so dass Attributwerte
in einer vom physikalischen Speicherformat unabhängigen Form untersucht werden
können.
-
Das
dekomprimierte Zwischenformat ist vom physikalischen Speicherformat,
das bei verschiedenen Trägertypen
unterschiedlich sein kann, unabhängig.
In einer bevorzugten Ausführungsform
ist das Zwischenformat auch von jeglichen Änderungen der Versionsstufe
des physikalischen Formats unabhängig.
Diese Unabhängigkeit
gestattet es dem Abfragelogik-Untersystem 210, das der
Primärklient
des physikalisch-logischen Untersystems 244 ist, Daten
in dieser Darstellung zu untersuchen und zu verstehen, um die Abfrage
aufzulösen.
Die Schnittstelle zur Konvertierung in das dekomprimierte Zwischenformat
arbeitet hauptsächlich
auf Basis von Datensätzen,
wobei, soweit erforderlich, für
Konvertierung innerhalb der Paketunterteilungen gesorgt ist. Der
Konvertierungsprozess kann auch Metadatentabellen (Beschreibung
unten) verwenden, um die Umsetzung in das dekomprimierte Zwischenformat
aus neueren Datenspezifikationsstufen im physikalischen Speicherformat
zu erleichtern.
-
Das
dekomprimierte Zwischenformat soll unnötigen Zeit- und Platzaufwand
vermeiden, der zum Beibehalten von Datensätzen im vollen logischen Datenmodellformat
erforderlich wäre.
Entitäten
im logischen Datenmodellformat sind erheblich größer als im entsprechenden dekomprimierten
Zwischenformat. Logische Datenmodellentitäten sind Entitäten fester
Größe, die
der Anwendungssoftware bekannt sind und vom Abfragelogiksystem 210 über die
Schnittstelle 212 zurückgegeben
werden. Durch Beschränkung
der Konvertierung aus dem Zwischenformat in das logische Datenmodellformat
auf die Datensätze,
die an die Navigationsanwendung zurückgegeben werden, wird der
Speicherbedarf und Konvertierungsaufwand minimiert, der für Entitäten erforderlich
wäre, die
einer bestimmten Abfrage nicht genügen. Zwischen den Typen der
dekomprimierten Zwischenformate und der logischen Datenmodellentitäten besteht
eine Eins-zu-Eins-Beziehung.
-
Die
Umwandlung in das dekomprimierte Zwischenformat stützt sich
auf eine Schnittstelle 257, die vom physikalisch-logischen
Untersystem 244 bereitgestellt wird. Dieses verwendet das
Zwischenformat, das alle einer Entität innerhalb des gleichen Pakets
entsprechenden Daten lokalisiert. Die zum Halten der Daten in diesem
Zwischenformat erforderliche Speichermenge ist vorzugsweise geringer
als die Datenmenge, die nötig wäre, um dieselben
Datenentitäten
im logischen Datenmodellformat zu halten. Wurden durch die Abfrageauflösungslogik
Entitäten
identifiziert, die den Ergebnissatz enthalten, steht schließlich eine
weitere physikalisch-logische Schnittstelle 255 zur Verfügung, um
die Daten in das logische Datenmodellformat zur Rückgabe an
die Navigationsanwendungsprogramme 200 umzusetzen.
-
B. Cursormanagement
-
Das
Abfrageergebnis von der Datenzugriffs-Schnittstellenschicht 41 wird
in Speicherpuffer kopiert, die von den Navigationsanwendungs-Softwareprogrammen 200 bereitgestellt
werden, unabhängig
davon, ob Cursors beteiligt sind oder nicht. Dadurch ist es der
Datenzugriffs-Schnittstellenschicht 41 möglich, den
ihr in ihrem Speicherpool zugeteilten Speicher ohne Auswirkungen
auf die Navigationsanwendungsprogramme 200 zu komprimieren
(d.h. verdichten). Das oben erwähnte
Cursormanagement-Untersystem 249 ist Teil des Abfragelogik-Untersystems 210.
Wenn ein cursorgestützter
Abfrageaufruf in der Datenzugriffs-Schnittstellenschicht 41 aufgerufen
wird, wird vom Cursormanagement-Untersystem 249 ein interner
Cursor erstellt und eine eindeutige Referenz auf den Cursor an dasjenige
der Navigationsanwendungsprogramme 200 zurückgegeben, welches
die Daten angefordert hat. Die Cursorreferenz dient dazu, alle oder
einen gewissen Teil der resultierenden Daten zu erhalten. Werden
Daten über
einen Cursor erhalten, so gibt das Navigationsanwendungsprogramm 200 einen
Speicherpuffer in einer Größe vor,
die einem Vielfachen der Größe der zurückgegebenen logischen
Datenmodellentität
entspricht. Dieses Vielfache basiert darauf, wie viele Datensätze das
Navigationsanwendungsprogramm jeweils auf einmal zu verarbeiten
bevorzugt (oder verarbeiten kann). In einer bevorzugten Ausführungsform
wird diese Technik dadurch erleichtert, dass die logischen Datenmodellentitäten eine
bekannte feste Größe aufweisen.
-
Das
Cursormanagement-Untersystem 249 speichert die den Cursorergebnissatz
umfassenden Entitäten
auf zwei verschiedene Arten. In der 5A werden
einige der Entitäten
im Ergebnissatz in voll umgesetzter logischer Datenmodellform gespeichert.
Ob alle Entitäten
im Satz in logischer Datenmodellform beibehalten werden oder nicht,
hängt von
der Anzahl der den Abfrageergebnissatz bildenden Entitäten ab.
In Fällen, in
denen die Ergebnissatzgröße unterhalb
einer ersten Schwelle liegt, wird der gesamte Satz als Array 511 mit dekomprimierten
logischen Datenmodellentitäten
beibehalten. Bei Cursors, deren Ergebnissatz diese erste Schwelle überschreitet,
werden die restlichen in einem zweiten nur Entitätskennungen umfassenden Array 513 beibehalten.
Die Entitätskennung
(die in vielen Fällen
die Datenbankkennung beziehungsweise „DBID" sein kann) gestattet einen schnellen
Zugriff auf den Datensatz im physikalischen Paket zur Umwandlung
in das logische Datenmodellformat.
-
Der
zum Beibehalten des Cursorergebnissatzes verwendete Speicher wird
dynamisch zugewiesen, und zwar unter Verwendung der internen privaten
dynamischen Speichermanagementschnittstelle, die, wie weiter unten
noch erklärt
wird, vom Ressourcenmanagement-Untersystem 220 bereitgestellt
wird. Bei sehr großen
Ergebnissätzen
kann ein Ergebnisteilsatz beibehalten werden, wenn die Anzahl der
der Abfrage entsprechenden Entitäten
noch eine weitere Schwelle überschreitet.
Diese zweite Schwelle dient dazu, eventuelle nachteilige Auswirkungen
auf den Speicher durch einen sehr großen Ergebnissatz zu minimieren.
Jede dieser Schwellen kann zum Zeitpunkt der Kompilierung des ausführbaren
Moduls 18 einschließlich
der Navigationsanwendungsprogramme 200 und der Datenzugriffs-Schnittstellenschicht 41 konfiguriert
werden. Die vollständige
oder unvollständige
Art einer bestimmten Abfrage wird dem aufrufenden Navigationsanwendungsprogramm 200 mitgeteilt,
so dass die Anzahl der von der Abfrage zurückgegebenen Datensätze richtig
interpretiert werden kann.
-
Bei
Beibehaltung eines Teilergebnissatzes für einen Bezugscursor kommt
der Abfrageauflösungsprozess
vorübergehend
zum Stillstand, sobald die Teilabfragehöchstgrenze erreicht ist. Um
die Abfrage zu einem späteren
Zeitpunkt fortzuführen,
behält
der Cursor auch genügend
Informationen, um den Abfrageauflösungsprozess wieder an der
Stelle aufzunehmen, an der er aufhörte.
-
Das
Cursormanagement-Untersystem 249 weist zusätzliche
Cursorfunktionalität
auf. Sobald ein Cursor für
eine bestimmte Abfrage definiert ist, wird der Cursor am Ergebnissatzanfang
positioniert. Eine „Fetch-Next"-Cursorfunktion füllt den Ergebnispuffer der
Navigationsanwendung (die im Abfrageaufruf, der den Cursor erstellte,
spezifiziert ist) mit den nächsten
N Datensätzen
und Positionen für
den Cursor nach dem letzten zurückgegebenen
Datensatz. Der Cursor wird als sich über den Ergebnissatz bewegendes „Fenster" mit logischen Datenmodellsätzen beibehalten,
so dass der Cursor-Holprozess einfach eine Kopie von Speicher zu
Speicher von dem in der Datenzugriffs-Schnittstellenschicht 41 integrierten
Adressraum des Cursors auf den Adressraum des Navigationsanwendungsprogramms 200 ist.
-
Das
Cursormanagement-Untersystem 249 weist auch verschiedene
Formen von Cursorbetätigungsfunktionen
auf, darunter die Fähigkeit,
die Cursorposition auf Anfang, Ende oder eine absolute Position
im Ergebnissatz zurückzustellen.
Des Weiteren ist eine Cursorfunktion „hole vorherigen" vorgesehen, um die
Funktionalität „hole nächsten" zu erhöhen. Die
Funktion der absoluten Positionierung ist im Zusammenhang mit der Datensatzanzahl
des Ergebnissatzes nützlich,
die von der den Cursor erstellenden Abfragefunktion zurückgegeben
wird.
-
IV. Indexmanagement- und
-navigations-(IMN)-Untersystem 242
-
Um
wieder auf 3 Bezug zu nehmen, dort enthält das Indexmanagement- und -navigationsuntersystem 242 einen
Teil der für
das physikalische Format spezifischen Indexmanagement- und -navigationssoftware
in der Softwarebibliothek, die die Datenzugriffs-Schnittstellenschicht 41 bildet.
Das Indexmanagement- und -navigationsuntersystem 242 ermöglicht es
dem Abfragelogik-Untersystem 210 und dem Ressourcenmanagement-Untersystem 220,
die sich oberhalb beziehungsweise unterhalb des Indexmanagement-
und -navigationsuntersystems 242 befinden, von dem auf
dem Träger
verwendeten physikalischen Speicherformat unabhängig zu sein.
-
Indexinformationen
dienen zur Auflösung
der Position eines eine gewünschte
Entität
oder Entitäten enthaltenden
Pakets auf Grundlage verschiedener Suchkriterien. Indizes dienen
in manchen Fällen
auch dazu, eine bestimmte Datenteilmenge innerhalb eines Pakets
zu lokalisieren. (Ein zur Auflösung
in ein bestimmtes Paket verwendeter Index kann als externer Index
betrachtet werden und ein zur Auflösung in eine paketinterne Unterteilung
verwendeter Index kann als interner Index betrachtet werden, da
er im Paket gespeichert ist.) Externe Indizes dienen dazu, die Notwendigkeit
des physikalischen Zugriffs auf Pakete, die die angeforderten Daten
möglicherweise
nicht enthalten, zu minimieren oder zu eliminieren. Sowohl externe
als auch interne Indizes helfen auch bei der Minimierung des zur
Prüfung
der in Frage kommenden Entitäten
notwendigen Dekomprimier- und Umsetzungsaufwands. Da verschiedene
Aspekte der Arbeit mit Indexinformationen zur Auflösung in ein
Paket, eine Paketdatenteilmenge oder Ebene mit dem spezifischen
physikalischen Speicherformat in Beziehung stehen, wird diese Funktionalität innerhalb
des formatspezifischen Indexmanagement- und -navigationsuntersystems 242 implementiert.
-
Einige
der Charakteristika der vom jeweiligen physikalischen Speicherformat
abhängigen
Indexinformationen beinhalten die eindeutige Kennung für das Paket, welches
die Wurzel des Index auf den physikalischen Trägern enthält, welche Art Index verwendet
wird, und ob der Index zur Auflösung
auf Paket-, Datenteilmengenpaket- oder Datensatzebene dient. Zudem
können
bestimmte Arten von Indexinformationen auf einem Speicherformattyp
existieren, auf einem anderen wiederum nicht. Zum Beibehalten von
Informationen über diese
Indexcharakteristika existiert ein Rahmen, um diese Informationen
innerhalb des Indexmanagement- und -navigationsuntersystems 242 beizubehalten.
Diese Informationen können
auf dem physikalischen Träger residieren.
Diese Information kann zum Zeitpunkt der Initialisierung in den
Speicher gelesen und dort zur Verwendung durch das Indexmanagement-
und -navigationsuntersystem 242 beibehalten werden.
-
Dieser
Indexinformationsrahmen, der die Details der auf dem physikalischen
Speicherformat vorhandenen Indizes beibehält, umfasst einen Satz Schnittstellen 245,
die vom Datenabfragelogik-Untersystem 210 verwendet werden
können,
um die Informationen zu erhalten, die es benötigt, um auf Grundlage der über einen Aufruf
durch das Abfragelogik-Untersystem 210 empfangenen Abfrageparameter
den zu verwendenden optimalen Index zu bestimmen. In einer bevorzugten
Ausführungsform
wird unabhängig
vom physikalischen Speicherformat eine Indexmindestteilmenge bereitgestellt.
Durch die Verwendung einer Indexmindestteilmenge wird unnötiger Aufwand
im Abfragelogik-Untersystem 210 minimiert, der sich aus
einem vollkommen flexiblen Satz Indizierungsfähigkeiten ergeben würde. Der
Indexinformationsrahmen 245 stellt auch eine Struktur auf dem
Abfrageparametersatz bereit, der an das Indexmanagement- und -navigationsuntersystem 242 weitergegeben
wird, um eine Abfrage unter Verwendung eines bestimmten Index aufzulösen. Darüber hinaus
ist dieser Rahmen erweiterbar und erlaubt es dadurch, neue Indextypen
für zukünftige physikalische
Speicherformate zu definieren und Indizes in Form von Entitäten und/oder
Attributen zu definieren, die in gängigen Datenbankversionen oder
-spezifikationen nicht existieren.
-
Es
werden mehrere verschiedene Indizierungsschemata verwendet, je nach
Trägergröße, Trägerzugriffscharakteristika,
Entitätstyp
und physikalischer Organisation eines bestimmten physikalischen
Speicherformats. Beispielsweise wird zur zweidimensionalen Auflösung räumlicher
Daten ein kd-Baum, oder Varianten desselben, verwendet, während für gewisse
nicht-räumliche
Daten in einem für
CD-ROM verwendeten
physikalischen Speicherformat ein breiter und flacher B-Baum verwendet
wird. Das Indexmanagement- und -navigationsuntersystem 242 implementiert
die zur Lokalisierung und Navigation innerhalb dieser verschiedenen
Indexbaumtypen verwendete Logik. Für externe Indexinformationen
spezifizieren die Blattknoten dieser Bäume eine bestimmte Paketkennung.
Für paketinterne
Indexinformationen dagegen spezifizieren die Blattknoten eine bestimmte
Paketdatenteilmenge oder einen Datensatz. Jeder eindeutige Indextyp,
der zur Verwendung in der Datenzugriffs-Schnittstellenschicht 41 bestimmt
ist, wird innerhalb eines separaten Moduls implementiert, vorzugsweise
im C-Quellcode. Die Codegröße wird
also minimiert, indem unnötiger
Code nicht aufgenommen wird, wenn ein bestimmtes Indizierungsschema
nicht in einem bestimmten physikalischen Speicherformat verwendet
wird.
-
Da
externe Indexinformationen in Paketen auf dem physikalischen Träger gespeichert
sind, verwendet das Indexmanagement- und -navigationsuntersystem 242 das
Ressourcenmanagement-Untersystem 220, um die Indexinformationen
physikalisch aus dem Speicherträger
in einen Speicherpuffer zu lesen. In alternativen Ausführungsformen
können
diese Indexpakete während
des Fortschreitens des Indexnavigationsprozesses im Speicher behalten
werden, da damit zu rechnen ist, dass einige dieser Indizes innerhalb
desselben Funktionsaufrufs oder sogar darüber hinaus erneut verwendet
werden. Daher werden Indexpakete durch die vom Ressourcenmanagement-Untersystem 220 implementierte
Caching-Logik im Speicher behalten.
-
In
einer Ausführungsform überprüft das Indexmanagement-Untersystem 242 zunächst die
Verfügbarkeit
des Index, wenn ein Task (wie beispielsweise eine Funktion im Abfragelogiksystem 210)
einen Index anfordert. Steht der gewünschte Index zur Verfügung, so
gibt das Indexmanagementsystem eine Meldung über die Verfügbarkeit
des Index zusammen mit einem Handle zur Suche unter Verwendung des
Index an den Task zurück.
Das Handle umfasst einen Zeiger, der aufgerufen wird, um die Suchaktionen
unter Verwendung des Index durchzuführen. Der Task erhält Speicher
(wie unten noch erklärt
wird) und erstellt Informationen für den Indexschlüssel. Der
Task erhält
auch Speicher, um das Ergebnis der Indexsuche zu hatten.
-
V. Untersystem 244 zur
physikalisch-logischen Datenumsetzung (P2L)
-
Das
Untersystem 244 zur physikalisch-logischen Datenumsetzung
(P2L) umfasst die speicherformatspezifische Datenumsetzungssoftware
in der Softwarebibliothek, die die Datenzugriffs-Schnittstellenschicht 41 bildet.
Dadurch können
das Datenabfragelogik-Untersystem 210 und das Ressourcenmanagement-Untersystem 220 vom
physikalischen Speicherformat unabhängig sein.
-
Das
physikalisch-logische Untersystem 244 stellt eine Schnittstelle 260 zur
Umsetzung einer Entität
in der physikalischen Speicherformatform (die eine komprimierte
Form sein kann) in die dekomprimierte Zwischenform bereit. Diese
Schnittstelle 260 dekomprimiert die Entität zunächst. Dann
folgt, soweit erforderlich, ein Meta-Umsetzungsschritt 261.
Der zum Halten des Ergebnisses verwendete Speicherpuffer wird vom
Datenabfragelogik-Untersystem 210 bereitgestellt. Der Meta-Umsetzungsschritt 261 kann
zur Effizienzsteigerung umgangen werden, wenn die Versionsstufen
des physikalischen Speicherformats und des dekomprimierten Zwischenformats
gleich sind.
-
Sobald
das Datenabfragelogik-Untersystem 210 eine an das Navigationsanwendungsprogramm 200 zurückzugebende
Entität
identifiziert, verwendet es eine Schnittstelle 263 im physikalisch-logischen
Untersystem 242, die die Entität aus der dekomprimierten Zwischenform
in die endgültige
logische Datenmodellform umsetzt. Für Einzelentitätsabfragen
ohne Cursor stellt das aufrufende Navigationsanwendungsprogramm 200 den
Speicherpuffer bereit, der die umgesetzte logische Datenmodellausgabe
hält. Ansonsten
stellt das Datenabfragelogik-Untersystem 210 einen dynamisch
zugewiesenen privaten Cursor-Speicherpuffer bereit. Im Gegensatz
zum tabellengesteuerten Meta-Umsetzungsprozess
wird die logische Datenmodellumsetzung in die physikalisch-logische Software-Implementierung
codiert.
-
Es
kann wünschenswert
sein, dass Entitäten
in der dekomprimierten Zwischenform innerhalb oder auch über Datenzugriffsaufrufe
hinweg für
nachfolgende wiederholte Zugriffe bestehen bleiben. Dadurch könnte zusätzlicher
Aufwand im Zusammenhang mit der CPU, der für die wiederholte Durchführung der
Dekomprimierung und Meta-Umsetzung für dieselben Daten erforderlich
wäre, sowie
zusätzlicher
Speichermanagementaufwand, der durch die ansonsten wiederholte Zuweisung
eines Ausgabepuffers entstünde,
minimiert werden. Dieser Fortbestand wird vom Datenabfragelogik-Untersystem 210 verwaltet.
Bei diesem Lösungsansatz wird
die für
CPU und Speicher erwartete Einsparung berücksichtigt sowie die Untersuchung
von Datenzugriffsmustern, um zu bestimmen, wie oft wiederholter
Zugriff auf dieselben dekomprimierten Daten erfolgt. Die Gesamtleistung
des Meta-Umsetzungsprozesses
spielt in dieser Analyse ebenfalls eine Rolle.
-
In
einer alternativen Ausführungsform
können
einige Datenentitäten
einer direkten Umwandlung aus dem physikalischen Speicherformat
in das logische Datenmodellformat ohne Zwischenumsetzung in das
dekomprimierte Zwischenformat unterzogen werden.
-
Meta-Umsetzung
beschreibt die Umsetzung von Daten aus der komprimierten physikalischen
Speicherformat-Darstellung auf einer bestimmten Datenversionsstufe
(auch bezeichnet als „Spezifikationsstufe") in die dekomprimierte
Zwischendarstellung, die dem Datenabfragelogik-Untersystem 210 auf
einer anderen Datenversionsstufe bekannt ist. Zur Erleichterung
der Umwandlung aus einer Versionsstufe in eine andere werden Metadatentabellen 259 verwendet.
Die Metadatentabellen 259 im physikalischen Speicherformat
werden zum Zeitpunkt der Systeminitialisierung vom Träger in einen
semipermanent zugewiesenen Speicher eingelesen. Eine nähere Beschreibung
des Metadatenprozesses folgt weiter unten.
-
VI. Ressourcenmanagement-(SRM)-Untersystem 220
-
Das
Ressourcenmanagement-Untersystem 220 sorgt für Zugriff
auf Speicher- und
E/A-Ressourcen für
die die Datenzugriffs-Schnittstellenschicht 41 bildende
Softwarebibliothek. Das Ressourcenmanagement-Untersystem 220 verwaltet
die Verfügbarkeit
von Navigationssystemspeicher- und E/A-Ressourcen zur Verwendung
durch die Datenzugriffs-Schnittstellenschicht 41 in einem
Multitasking-Umfeld, in welchem die Navigationsanwendungsprogramme 200 ebenfalls
um diese Ressourcen konkurrieren. In einer bevorzugten Ausführungsform
verwaltet das Ressourcenmanagement-Untersystem 220 die
Speicher- und E/A-Ressourcen für
die Navigationsanwendungs-Softwareprogramme 200 ausschließlich für Tasks,
die auf die geographische Datenbank über die Schnittstellenschicht 41 zugreifen.
-
Es
gibt zwei primäre
Datenzugriffsschnittstellen zum Ressourcenmanagement-Untersystem 220.
Die erste dient zur Zuweisung und Freigabe von Arbeitsplatzspeicher
aus einem Pool, der für
die ausschließliche Verwendung
durch die Datenzugriffs-Schnittstellenschicht 41 reserviert
ist. Die zweite Schnittstelle spezifiziert eine Paketkennung und
gibt einen Zeiger auf einen das Paket enthaltenden Cachespeicherpuffer
zurück.
Die Paketpriorität,
d.h. eine Angabe darüber,
wie (relativ) bald das Paket benötigt
wird, kann spezifiziert werden. Dieses Merkmal ermöglicht ein
Priorisieren der Paket-E/A-Transaktionen und Fortbestehen der Paketdaten
im Cache, wenn um den Cache konkurriert wird. Wird ein angefordertes
Paket nicht im Cache gefunden, so wird eine physikalische E/A-Transaktion initiiert,
um das Paket vom Träger
zu lesen. Im Ressourcenmanagement-Untersystem 220 gibt
es zusätzliche
Schnittstellen, durch die es der Navigationsanwendungssoftware 200 möglich ist,
die Ressourcenmanagementstrategien während der Ausführungszeit
anzugleichen.
-
Zur
Leistungssteigerung verwendet das Ressourcenmanagement-Untersystem 220 mindestens
zwei Lösungsansätze. Der
erste besteht in der Minimierung und Optimierung von E/A-Transaktionen
innerhalb eines beschränkten
Speicherumfelds, das aus einem Teil des Haldenspeichers des Navigationssystems
besteht, der der Softwarebibliothek zugeordnet ist, die die Datenzugriffs-Schnittstelle 41 bildet.
Der zweite besteht in der Verwaltung des Zugriffs auf diesen relativ
kleinen Speicherteil. Speichermanagement umfasst auch Methoden zum
Beibehalten von Daten in Cachepuffern, um die E/A zu minimieren
und den zugeordneten Haldenspeicher zu verdichten. Bei diesen Lösungsansätzen sind
der Aufwand im Zusammenhang mit der CPU und der Speicherbedarf gering.
Zur Implementierung dieser Lösungsansätze werden
sowohl die physikalische Organisation der Daten auf dem Speicherträger als
auch die Abfrageoptimierungstechniken, die im Datenabfragelogik-Untersystem 210 und
im Indexmanagement- und -navigationsuntersystem 242 implementiert
werden, berücksichtigt.
-
Das
Ressourcenmanagement-Untersystem 220 arbeitet über ein
breites Spektrum von Trägertypen, physikalischen
Speicherformaten, Betriebssystemumgebungen und Gerätetreiberfähigkeiten.
Zur Optimierung des Ressourcenmanagement-Untersystems 220 für eine jeweilige
Navigationssystemplattform und Navigationssoftwareanwendung sind
verschiedene Mechanismen vorgesehen. Zu diesen Mechanismen zählt das Festlegen
von Konfigurationsparametern zum Zeitpunkt der Kompilierung. Dazu
gehört
auch ein Satz von Funktionsaufrufen in der Datenzugriffs-Schnittstellenschicht 41,
die das Ressourcenmanagementverhalten zum Zeitpunkt der Ausführung beeinflussen.
Darüber
hinaus sind die Datenzugriffsaufrufe so ausgelegt, dass sie von
integrierten Ressourcenmanagementfähigkeiten wie Hintergrunddatenzugriff
profitieren. Des Weiteren sorgt das Ressourcenmanagement-Untersystem
für das
Priorisieren von Anfragen nach mehreren Paketen, wenn von einer
Funktion mehr als ein Paket angefordert wird (d.h. Funktionsebenengranularität), und
alternativ kann das Ressourcenmanagement-Untersystem sogar für das Priorisieren
von Anfragen nach mehreren Paketen sorgen, wenn Pakete von mehr
als einer Funktion angefordert werden.
-
Die 4 stellt
eine Ausführungsform
einer Schnittstellenschicht 41 dar, die in einem Multitasking-Umfeld
in einem Navigationssystem verwendet wird. Jeder Navigationsanwendungstask
APP1, APP2 ... APPn, der Datenzugriffs-Schnittstellenaufrufe tätigt, wird
mit einer Schnittstellenschicht-Softwarebibliothek LIB1, LIB2 ...
LIBn in gemeinsam genutztem Coderaum verknüpft. Jede Bibliothek implementiert
das Datenabfragelogik-Untersystem 210, das Indexmanagement-
und -navigationsuntersystem 242 und das physikalisch-logische Untersystem 244 sowie
einen Großteil
(oder alles) des Ressourcenmanagement-Untersystems 220.
Wie in der Ausführungsform
der 4 gezeigt, wird der E/A-Manager-(IOM)-Teil 270 des
Ressourcenmanagement-Untersystems 220 als vom Rest der
Untersysteme (d.h. Datenabfragelogik-Untersystem 210, Indexmanagement- und
-navigationsuntersystem 242, physikalisch-logisches Untersystem 244 sowie
ein Großteil
des Ressourcenmanagement-Untersystems 220) der Datenzugriffs-Schnittstellenschicht 41 separater
Prozess implementiert. Dies bedeutet, dass der E/A-Manager 270 nicht,
wie der Rest der Untersysteme in der Schnittstellenschicht, mit
den Anwendungsprogrammen 200 statisch verknüpft sein
darf, sondern stattdessen mit jedem separaten Navigationsprozess 200A, 200B,
... 200n über
die verknüpften
Teile der Schnittstellenschicht in jedem Prozess arbeitet. Dadurch
ist es dem E/A-Manager 270 gestattet, die physikalische
E/A im Hintergrund weiter zu verarbeiten, während diese anderen Tasks weiterlaufen.
Diese Ausführungsform
des E/A-Managers 270 käme
in Navigationssystemen zum Einsatz, deren Gerätetreiber asynchrone E/A-Meldefähigkeit
nicht unterstützt.
Eine alternative Ausführungsform
des E/A-Managers 270 kann jedoch verwendet werden, wenn
der Navigationssystemtyp einen asynchrone E/A-Meldefähigkeit
unterstützenden
Gerätetreiber
umfasst. Eine nähere Beschreibung
dieser alternativen Ausführungsform
folgt weiter unten.
-
A. Speichermanagement
-
Wie
aus der 4 hervorgeht, ist ein Teil 278 des
Systemhaldenspeichers 276 für die ausschließliche Verwendung
durch die Datenzugriffs-Schnittstellenschicht 41 zugewiesen.
Der Teil 278 ist der Schnittstellenschicht-Speicherpool.
Dieser Speicherpool 278 ist vom Teil 283 des von
den Navigationsanwendungen 200 genutzten Speichers getrennt.
Die Größe des Speicherpools 278 wird
vom Navigationsanwendungsprogramm 200 über einen Aufruf an das Ressourcenmanagement-Untersystem 220 über die
Datenzugriffs-Programmierschnittstelle 212 bestimmt.
Das Ressourcenmanagement-Untersystem 220 gestattet es dem
Navigationsanwendungsprogramm 200, die Größe des Pools 278 zum
Zeitpunkt der Ausführung
dynamisch zu verändern (wie
durch den Pfeil 275 zwischen den zwei Unterteilungen angedeutet).
Die Mindestgröße des Speicherpools 278 beträgt in einer
Ausführungsform
256 KBytes, mit zusätzlichem
Speicher für
CD-ROM-Träger, um
die Datenmenge im Cache zu vergrößern.
-
Der
Speicherpool 278 wird von der Datenzugriffs-Schnittstellenschicht 41 zum
Cachen von Paketen unterschiedlicher Größe, die vom physikalischen
Träger
gelesen werden, als auch für
eine private Mehrzweckhalde der Softwarebibliotheks-Funktionen der Datenzugriffs-Schnittstellenschicht 41 verwendet.
Von diesem Haldenspeicher zugewiesene Puffer dienen als allgemeiner
Arbeitsplatz, um dekomprimierte Datensätze zu halten, sowie für Cursor-Ergebnissätze.
-
Der
für Cachepuffer
verwendete Speicher ist tendenziell größer und weist einheitlichere
Größen auf als
Speicher, der aus dem privaten Mehrzweck-Haldenspeicher zugewiesen wird, der
typischerweise kleiner ist und unterschiedlichere Größen aufweist.
Bei der Verwaltung von Cachepuffern wird auch berücksichtigt, dass
eine Persistenzstrategie vorgesehen ist. Darüber hinaus sollte die Suche
nach einem bestimmten Paket im Cache so wenig Aufwand wie möglich verursachen.
-
Diese
unterschiedlichen, aber sich dennoch überschneidenden Ziele des Speichermanagements
werden durch einen zweistufigen Lösungsansatz unterstützt. Die
erste Stufe ist für
die Verwaltung der einheitlicheren und größeren Puffer verantwortlich,
die sich für
Zwecke des Paket-Cachens eignen. Die zweite Stufe bearbeitet diese
größeren Puffer
und teilt sie in kleinere und weniger einheitliche Stücke zur
Zuweisung von Mehrzweckhaldenspeicher auf. Die Cachepuffer- Persistenzstrategie
wird durch die erste Stufe des Speicherpuffermanagements realisiert.
-
Beide
Stufen des Speichermanagements werden von einer Speichermanagementbibliothek
(„MML" oder „Speichermanager") 280 durchgeführt. Die
Speichermanagementbibliothek 280 ist Teil des lokal residenten
Teils des Ressourcenmanagement-Untersystems 220, das mit
der Navigationsanwendungssoftware 200 verknüpft ist
und als Teil eines jeden Navigationsanwendungsprozesses läuft. Die
Speichermanagementbibliothek 280 ist eine gemeinsam genutzte
Codebibliothek, die eine Technik des wechselseitigen Ausschlusses (Beschreibung
unten) anwendet, um mehreren Anwendungen den gleichzeitigen Speicherzugriff
zu gestatten. Beispielsweise können
mehrere Navigationsanwendungsprozesse, wie 200A, 200B,
... 200n, gleichzeitig ablaufen. Die Speichermanagementbibliothek 280 implementiert
auch den Cachemanagementprozess.
-
Durch
diese zweistufige Speichermanagementarchitektur wird die erforderliche
Speichermenge für Kontrollstrukturen
minimiert, die dazu dienen, die interne Speicherzuweisung zu verfolgen.
Diese Kontrollstrukturen residieren zusammen mit den Cachemanagement-Kontrollstrukturen
im Speicherpool 278 der Datenzugriffs-Schnittstellenschicht 41.
Um Speicheranfragen durch Arbitration des Zugriffs auf diese Kontrollstrukturen in
einem Multitasking-Umfeld zu serialisieren, verwendet die Speichermanagementbibliothek
Techniken der Interprozesskommunikation (IPK), wie Semaphor-Schutz.
Dies ist durch die gepunkteten Linien 277 angedeutet, die
die Speichermanagementbibliothek 280 eines jeden Navigationsanwendungstasks 200A–200n mit
dem Speicherpool 278 verbinden.
-
Schließlich wird
ein Teil des aus dem Speicherpool 278 zugewiesenen Speichers
von den Softwarebibliotheks-Komponenten der Datenzugriffs-Schnittstellenschicht 41 verwendet.
Dieser Teil des Speicherpools wird nicht gemeinsam genutzt (oder
ansonsten zurückgegeben)
an das Navigationsanwendungs-Softwareprogramm 200. Dies
wird dadurch erleichtert, dass für
das Navigationsanwendungsprogramm 200 vorgesehen ist, sich
seine eigenen privaten Puffer zum Halten zurückgegebener Datenentitäten im logischen
Datenmodell zuzuweisen. Durch diese Isolierung ist es dem Ressourcenmanagement-Untersystem 220 gestattet,
Verdichtungsstrategien zur Minimierung der Fragmentierung des Speicherpools 278 zu
verfolgen, ohne dass eine Bearbeitung dieses Speichermanagementtasks
durch die Navigationsanwendungsprogramme 200 erforderlich ist.
-
B. Cachemanagement
-
Anfragen
nach Daten- und Indexpaketen werden über die Speichermanagementbibliothek 280 in
Form einer Paketkennung geleitet. Es wird eine Suche nach dem Paket
im Cachespeicher durchgeführt.
Wenn das Paket nicht im Cache gefunden wird, erfolgt eine physikalische
E/A-Anfrage an den E/A-Manager 270. Sobald das Paket im
Cachespeicher ist, sperrt eine Schnittstelle 285 im Ressourcenmanagement-Untersystem 220 das
Paket im Puffer, wenn die Pufferadresse an das Datenabfragelogik-Untersystem 210 zurückgegeben
wird. Es wird dadurch verhindert, dass der Puffer ausgelagert wird,
wenn ein Datenzugriffs-Schnittstellenaufruf
aktiv ist. Eine zusätzliche
Schnittstelle 279 des Ressourcenmanagement-Untersystems 220 gibt
diese Sperre frei und wird aufgerufen, bevor der Datenzugriffs-Schnittstellenaufruf
die Kontrolle an das Navigationsanwendungsprogramm zurückgibt.
Auslagerung kann erfolgen, wenn eine große Anzahl gleichzeitiger Paketanfragen dazu
führt,
dass sich das System einer Speicherüberbelegung nähert.
-
Die
Persistenzstrategie für
die gecachten Pakete wird auch in der Speichermanagementbibliothek 280 implementiert.
Bei dieser Strategie werden bei der Entscheidung, welche Puffer
ausgelagert werden sollten, Puffersperren, Priorität, Nutzungsverlauf
und Nutzungshäufigkeit
berücksichtigt.
-
Das
Navigationsanwendungs-Softwareprogramm 200 ist in der Lage
vorauszusehen, welche Daten möglicherweise
irgendwann einmal benötigt
werden und welche Daten unmittelbar verlangt werden. Zur Unterscheidung
der Datenzugriffsanfragen nach unmittelbar erforderlichen Daten
und nach Daten, die für
späteren
Zugriff vorzubereiten sind, unterstützt das Ressourcenmanagement-Untersystem 220 synchrone
(d.h. Warten auf das Ergebnis im Vordergrund) und asynchrone (d.h.
die Verarbeitung läuft
weiter, während
die E/A im Hintergrund läuft)
Paketanfragen. Die asynchronen Aufrufe werden von den Datenzugriffsschnittstellen-Funktionen „Cache
vorbereiten" verwendet.
Eine asynchrone Anfrage gestattet es dem Navigationsanwendungsprogramm 200,
mit der Durchführung
nützlicher
Arbeit fortzufahren, während
die E/A-Transaktion im Hintergrund weiterläuft. Im Ressourcenmanagement-Untersystem 220 ist
auch ein Schnittstellenaufruf 281 vorgesehen, der es dem
Navigationsanwendungsprogramm 200 gestattet, eine asynchrone
Datenanfrage zu annullieren. Zusätzlich
ist in jedem Datenzugriffs-Schnittstellenaufruf
ein Ressourcenprioritätswert
vorgesehen, um das Navigationsanwendungsprogramm 200 mit
einer besseren Feinsteuerung zur Verwaltung dieser Vordergrund-
und Hintergrundanfragen auszustatten.
-
C. E/A-Manager 270
-
In
der in der 4 gezeigten Ausführungsform
empfängt
der E/A-Manager 270 Anfragen für physikalische E/A. Diese
E/A-Anfragen gehen von den synchronen und asynchronen „Anfragepaket"-Schnittstellen 287 aus,
die vom Ressourcenmanagement-Untersystem 220 immer dann
bereitgestellt werden, wenn ein angefordertes Paket nicht im Cachespeicher
gefunden werden kann. Geschieht dies, so initiiert die Speichermanagementbibliothek 280 über die
E/A-Managerschnittstelle 269 eine
E/A-Anfrage, was dazu führt,
dass eine E/A-Transaktionsanfrage
in eine E/A-Manager-Nachrichtenwarteschlange gestellt wird. Die
E/A-Managerschnittstelle 269 ist in der 4 im
statisch verknüpften
Teil 271 des Ressourcenmanagement-Untersystems 220 dargestellt.
In diesem Fall wird Konkurrenz um die E/A-Warteschlange mit Hilfe
von Interprozesskommunikationstechniken wie Nachrichtenwarteschlangen 273 verwaltet,
die die E/A-Manager-Schnittstelle 269 mit dem separaten
E/A-Manager-Prozess 270 verbinden.
Die Nachrichtenwarteschlangen 273 stellen für jeden Prozess
(d.h. Klient) eine einzelne Ereignispunktmitteilung bereit. Die
Nachrichtenwarteschlangen 273 können zur Mitteilung von Ereignissen,
wie Beendigung der E/A, Beendigung der Speicherzuweisung oder Freigabe des
Ressourcenzugriffs, verwendet werden. Es können auch weitere Ereignisse
unterstützt
werden. Für
jeden Prozess (d.h. Klient) gibt es eine Klienten-Nachrichtenwarteschlange.
-
In
einer bevorzugten Ausführungsform
werden über
die Warteschlange 273 eingehende E/A-Transaktionen in Form
von Paketkennungen empfangen. Enthalten sein können auch eine Angabe zur Priorität der Anfrage,
eine Kennung des die Anfrage durchführenden Tasks (Klient), eine
Angabe zu einer vom Absender der Anfrage verwendeten Nachrichtenwarteschlange.
Durch die Verwendung von Paketkennungen können die Speichermanagementbibliothek 280 und
der E/A- Manager 270 vom
physikalischen Speicherformat unabhängig bleiben. Eine Erläuterung
der Abhängigkeiten
vom physikalischen Speicherformat im Ressourcenmanagement-Untersystem 220 folgt
weiter unten. Für
diese E/A-Anfragen
erfolgt eine Umsetzung von Paketkennung in physikalische Trägeradresse.
Wenn die E/A-Transaktion an die Trägervorrichtung versendet wird,
fordert der E/A-Manager 270 von
der Speichermanagementbibliothek 280 einen Cachepuffer
an, um die von den Trägern zu
lesenden Daten zu halten. Dadurch wird sowohl überflüssige Interprozesskommunikation
reduziert, da annullierte Anfragen daran gehindert werden, unnötigerweise
einen Puffer anzufordern und freizugeben, als auch die Konkurrenz
um Cache minimiert, da der Puffer so spät wie möglich zugewiesen wird.
-
Zur
Systemleistungssteigerung weist der E/A-Manager 270 zwei
Funktionen auf. Eine bereits erwähnte
Funktion besteht darin, physikalische E/A parallel zu anderen Aktivitäten zuzulassen.
Dadurch ist es anderen Navigationsanwendungs-Softwarefunktionen 200 oder
der Datenzugriffs-Schnittstellenschicht-Software 41 gestattet,
während
einer laufenden physikalischen E/A-Transaktion weiterzulaufen. Die
andere vom E/A-Manager 270 bereitgestellte Funktion besteht
in einer Serialisierungsfunktion, mit deren Hilfe eingehende E/A-Anfragen
umgeordnet werden können.
Dieses Umordnen basiert auf mehreren Faktoren, darunter die Priorität der Anfrage,
der physikalische Ort der Daten auf den Trägern, die aktuelle Lesekopfposition.
Es können auch
weitere Faktoren enthalten sein. Anzumerken ist, dass sogar innerhalb
einer einzigen durch einen einzigen Navigationsanwendungsprozess
eingegebenen Transaktion mehrere Pakete spezifiziert werden können. Dies
bedeutet, dass die E/A-Umordnung selbst dann zu einer Leistungssteigerung
führen
kann, wenn nur ein einziger Task Daten anfordert (d.h. „Funktionsebenengranularität"). Darüber hinaus
wählt der
E/A-Manager 270, da Index- und Dateninformationen, insbesondere
bei physikalischen Speicherformaten für Träger mit relativ langsamer wahlfreier
Zugriffsleistung, wie zum Beispiel CD-ROM, redundant auftreten können, das nächstliegende
der zu lesenden redundanten Pakete aus. Dieses Merkmal wird zum
Teil durch die vom E/A-Manager 270 bereitgestellte Unterstützung für gestreutes
Lesen ermöglicht.
-
Alle
oben beschriebenen Umordnungsfähigkeiten
stützen
sich auf die Fähigkeit
des E/A-Managers 270, die aktuelle physikalische Lesekopfposition
beizubehalten. Diese wird vom Trägervorrichtungstreiber 290 (3)
bereitgestellt. Der E/A-Manager 270 hängt auch von der Fähigkeit
ab, von einer „undurchsichtigen" Paketkennung eine
physikalische Trägeradresse
(bzw. Adressen, bei redundant platzierten Paketen) zu erhalten. (Unter „undurchsichtig" ist zu verstehen,
dass der E/A-Manager 270 die Paketkennung weiterreichen
kann, ohne zu wissen, auf was genau auf dem physikalischen Speicherformatträger sich
diese bezieht.) Die physikalische Trägeradresse hängt vom
physikalischen Speicherformat ab. Diese Abhängigkeiten werden vom generischen
Teil des E/A-Managers 270 durch zwei zusätzliche
Ressourcenmanagement-Komponenten isoliert: einem Mapper physikalischer
Speicherformatadressen (PAM) 296 und einem Dateiverzeichnis-Mapper (FDM) 298.
Eine Trägervorrichtungs-Isolierschicht
(MDIL) 300 sorgt für
die Isolierung der Trägervorrichtung.
-
(In
einer bevorzugten Ausführungsform
bearbeitet der E/A-Manager 270 alle vom Träger gelesenen Daten.
Unter gewissen Umständen
kann die Navigationsanwendung direkt auf die Daten auf dem Träger zugreifen.
Wenn auf dem Träger
beispielsweise ein bestimmter Drittdatentyp gespeichert ist, kann
es besser sein, wenn die Navigationsanwendung direkt darauf zugreifen
kann. Auch für
gewisse andere Datentypen kann es von Vorteil sein, wenn sie direkt
vom Träger
gelesen werden oder die Speicherung im Cache umgehen. Zu diesen
Datentypen gehören
Ton- oder Videodaten. Aufgrund der Art und Weise, wie diese Datentypen genutzt
werden, kann es vorzuziehen sein, dass Ton- oder Videodaten eine
Cachespeicherung umgehen und direkt an die Navigationsanwendung
fließen,
um sie dem Endanwender zu präsentieren.)
-
D. Dateiverzeichnis-Mapper 298
-
Die
geographische Datenbank 40 existiert in einer oder mehreren
physikalischen Binärdateien
auf dem Speicherträger 22.
Die Paketkennungen für
alle Daten in diesen Dateien, sowohl Index- als auch Kartendateninformationen
stehen in enger Beziehung mit einem physikalischen Offset beziehungsweise
einer Adresse in einer dieser Dateien. Alle Schnittstellenschicht-E/A
vom E/A-Manager 270 werden in Form einer physikalischen
Trägeradresse
und eines Umfangs (Größe) durchgeführt. Adressen
und Umfang werden in Form von ganzzahligen physikalischen Unterteilungen
auf dem Träger
dargestellt. Bei CD-ROM-Trägern
ist diese physikalische Unterteilung der 2-KByte-Sektor. Der E/A-Manager 270 nutzt
die durch den Mapper physikalischer Speicherformatadressen 296 bereitgestellten
Dienste, um die physikalische Trägeradresse
für ein
Paket bezogen auf den Anfang seiner Datei zu erhalten. Damit der
E/A-Manager 270 die absolute Trägeradresse generieren kann,
wird die Ausgangsposition der Datei bestimmt. Diese Information
wird vom Dateiverzeichnis-Mapper (FDM) 298 bereitgestellt.
Ein Dateiverzeichnis existiert an irgendeiner bekannten Stelle auf
dem Träger.
Das Verzeichnis stellt für
jede der Dateien auf dem Träger
eine physikalische Trägeradresse
bereit, unabhängig
davon, ob es sich dabei um geographische Dateien handelt oder nicht.
Dieses Dateiverzeichnis wird für
den jeweiligen Träger
spezifiziert. In einer bevorzugten Ausführungsform wird das Dateisystem
nach dem ISO-9660-Standard für
CD-ROM-Träger verwendet,
es können
sich jedoch auch alternative Dateisysteme eignen. Für Lese-/Schreib-Träger kann
ein DOS-FAT-Dateisystem vorgesehen sein, wobei die Geodatei zur
Umgehung des FAT-Umweges auf dem Träger als zusammenhängend organisierte,
schreibgeschützte
Datei gespeichert ist.
-
Der
Dateiverzeichnis-Mapper 298 isoliert den E/A-Manager 270 von
der trägerspezifischen
(und somit für
das physikalische Speicherformat spezifischen) Dateiverzeichnisorganisation.
Der Dateiverzeichnis-Mapper 298 stellt eine Schnittstelle
bereit, die einen Dateinamen in die physikalische Trägeradresse
des Dateianfangs umsetzt. Diese Schnittstelle kann der Navigationsanwendungssoftware 200 zur
Verfügung
stehen, so dass die Positionen von Drittdateien oder navigationsanwendungsspezifischen
Dateien, soweit vorhanden, bereitgestellt werden können. Diese
Schnittstelle gestattet es der Navigationsanwendung, einen Datei-E/A-Rahmen
auf Grundlage von Dateideskriptoren und Byte-Offsets zu implementieren,
so dass auf Drittdateien oder navigationsanwendungsspezifische Dateien über die
Trägervorrichtungstreiber-Schnittstelle
zugegriffen werden kann.
-
Der
Dateiverzeichnis-Mapper 298 ist in der Lage, den Ort des
Dateiverzeichnisses auf dem Träger 22 festzustellen,
und zwar auf Grundlage einer vorbestimmten Information seiner Struktur.
Wenn der Dateiverzeichnis-Mapper 298 aufgerufen wird, liest
er das Verzeichnis vom bekannten Ort auf dem Träger. Dies ist durch die Schnittstelle 301 zwischen
dem Dateiverzeichnis-Mapper 298 und der Trägervorrichtung 22 dargestellt.
Ein von der Speichermanagementbibliothek 280 erhaltener
privater Puffer dient dazu, eine temporäre Kopie des Verzeichnisses
zu halten, bis der Offset bestimmt ist. Diese Aktivität findet
zum Zeitpunkt der Initialisierung für alle geographischen Dateien
statt, um wiederholten Zugriff auf das Verzeichnis zu minimieren.
Die Startposition für
jede Datei wird im Dateiverzeichnis-Mapper 298 für die Dauer
einer Arbeitssitzung aufbewahrt.
-
E. Mapper physikalischer
Speicherformatadressen 296
-
Wie
oben erwähnt,
setzt der Mapper physikalischer Speicherformatadressen 296 eine
Paketkennung (d.h. eine „Paket-ID") in eine physikalische
Trägeradresse
(oder Adressen) bezogen auf den Anfang der Datei um, in der sich
das Paket befindet. Genauer gesagt, setzt der Mapper physikalischer
Speicherformatadressen 296 eine Paket-ID in eine physikalische
Sektoradresse und Sektoranzahl auf dem Medium unter Verwendung des
Dateiadressen-Mappers 298 um, um die Datei auf dem Träger zu lokalisieren,
und unter Umsetzung der logischen Paket-ID in physikalischen Startsektor
und Sektoranzahl. Für
redundant platzierte Index- und Datenpakete werden Mehrfachadressen
zurückgegeben.
Der Adressen-Mapper 296 ist eine Komponente des E/A-Manager-Untersystems 270,
das mit dem Träger 22 nicht
in physikalischer Wechselwirkung steht.
-
Die
Paketkennungen stehen mit den physikalischen Adressen des Pakets
auf dem Träger
in enger Beziehung. Die Kennung beinhaltet auch Informationen über Paketgröße und ein
das Vorhandensein redundanter Kopien des Pakets auf dem Träger anzeigendes
Bit (oder andere Informationen). In der 6 ist ein
Beispiel einer Paket-ID 600 gezeigt. Die Paket-ID 600 kann
aus einem Teil 601 bestehen, welcher ein Offset vom Anfang
der das Paket enthaltenden Datei ist, einen zweiten die Paketgröße anzeigenden
Teil 602 und einen dritten Teil 603, der anzeigt,
ob redundante Kopien des Pakets auf dem Träger vorhanden sind. Die Orte
von redundanten Kopien des Pakets werden durch Verwendung einer
Tabelle bestimmt, die während
der Arbeitssitzung des Navigationssystems im Globalspeicher aufbewahrt
wird. Diese Information kann innerhalb des Mappers physikalischer
Speicherformatadressen 296 auf eine für das physikalische Speicherformat
spezifische Art und Weise algorithmisch kombiniert werden, um die
physikalische Adresse unter minimalem CPU- oder Speichertabellenaufwand
zu generieren.
-
Die
vom Mapper physikalischer Speicherformatadressen 296 zurückgegebene
physikalische Trägeradresse
(oder Adressen bei redundant gespeicherten Paketen) ist keine Byteadresse,
sondern befindet sich stattdessen an einer physikalischen Unterteilung
des Trägers.
Bei CD-ROM-Trägern
ist diese Unterteilung der 2-KByte-Sektor. Für Lese-/Schreibträger kann
die Unterteilung kleiner sein, z.B. 256. Entsprechend kann die Paketgröße auch
in dieser Form ausgedrückt
werden.
-
Die
Schnittstelle zum Mapper physikalischer Speicherformatadressen 296 nimmt
eine Paketkennung (Paket-ID) und gibt eine relative physikalische Trägeradresse
(oder einen Satz physikalischer Trägeradressen bei redundant gespeicherten
Paketen) zusammen mit der Paketgröße zurück. Diese Informationen entsprechen
den Teilen 601 bzw. 602 der Paket-ID. Die relative
physikalische Trägeradresse
(bzw. Adressen) wird zu einer absoluten Datei-Ausgangspositions-Adresse, die vom
Dateiverzeichnis-Mapper 298 zum Zeitpunkt der Initialisierung
bereitgestellt wurde, addiert, um eine absolute physikalische Adresse
(bzw. Adressen) für
das Paket zu erstellen. Werden redundante Paketkopien bereitgestellt,
so wählt
der E/A-Manager 270 dann auf Grundlage der aktuellen Lesekopfposition
die nächstliegende
Adresse aus und gibt diese Adresse, den Paketumfang (Größe) und
die Adresse des von der Speichermanagementbibliothek 280 erhaltenen
Cachespeichers an die Trägervorrichtungs-Isolierschicht 300 weiter,
um die physikalische E/A zu initiieren.
-
F. Betriebssystem-Isolierschicht
(OSIL) 302
-
Eine
Betriebssystem-Isolierschicht (OSIL) 302 stellt eine Schnittstelle
zwischen den generischen Betriebssystemdiensten, für die die
Datenzugriffs-Schnittstellenschicht 41 geschrieben
ist, und den jeweiligen, vom Betriebssystem 202 der Navigationssystemplattform
vorgesehenen Diensten bereit. Die Betriebssystem-Isolierschicht 302 kann beispielsweise
dafür verwendet
werden, verschiedene Betriebssysteme, darunter ITRON, OS9, pSOS,
VRTX, VxWorks, proprietäre
Betriebssysteme und Single-Task-Betriebssysteme, zu unterstützen. Die
Betriebssystem-Isolierschicht 302 ist ein Softwaremodul,
das mit einer spezifischen Plattform (oder BS) in Beziehung steht
und es der Datenzugriffs-Schnittstellenschicht 41 ermöglicht,
auf einer bestimmten Plattform zu arbeiten.
-
Es
gibt mehrere unterschiedliche Arten von Betriebssystemdiensten.
Die erste besteht aus Mehrzweckdiensten, wie z.B. String-Funktionen
(einschließlich
der Umwandlung zwischen Multibyte- und Wide-Character-Formaten),
mathematische Funktionen, allgemeine Dienstprogramme wie Suchen
und Sortieren und dergleichen. Einige dieser Betriebssystemdienste
werden von der die Datenzugriffs-Schnittstellenschicht 41 umfassenden
Softwarebibliothek benutzt. Für
diese Funktionen wird beispielsweise eine ANSI-C-Standardbibliotheks-(stdlib)-Schnittstelle
verwendet. Die Speichermanagementfunktionen malloc() und free()
fallen auch unter die stdlib-Schnittstelle. Sie werden vom Ressourcenmanagement-Untersystem 220 dazu
verwendet, den Speicherpool 278 zur internen Verwaltung
zuzuweisen und seine Größe zu ändern (wie
oben erwähnt).
-
Der
andere vom Ressourcenmanagement-Untersystem 220 verwendete
Schnittstellensatz auf BS-Ebene umfasst den Schutz gemeinsam genutzter
Datenstrukturen im Speicher, wie die Speichermanagement- und Cachekontrollstrukturen,
sowie die E/A-Warteschlange. Die Konkurrenz um diese Strukturen
von mehreren mit der Datenzugriffs-Schnittstellenschicht 41 verknüpften Tasks
wird durch den Einsatz von Interprozesskommunikationsmechanismen
wie Semaphoren und Nachrichtenwarteschlangen verwaltet. Das Ressourcenmanagement-Untersystem 220 verwendet
vorzugsweise die POSIX.4-Standardschnittstellen
für diese
Mechanismen.
-
Wird
vom Betriebssystem 202 des Navigationssystems 10 ein
anderer Schnittstellentyp bereitgestellt, so implementiert die Betriebssystem-Isolierschicht 302 die
ANSI-C-stdlib- und POSIX.4-Schnittstellen als Umsetzungsschicht
zu den Schnittstellen für
die durch das Navigationssystem-BS bereitgestellten nativen Dienste.
Wenn nicht, dann wird der Dienst innerhalb der Betriebssystem-Isolierschicht 302 implementiert.
-
Anzumerken
ist, dass das Ressourcenmanagement-Untersystem 220 zwar
logische POSIX.4-Semaphor- und Nachrichtenwarteschlangen-Schnittstellen
verwendet, dies aber nicht unbedingt bedeutet, dass darunter ein
physikalischer Semaphor oder eine Nachrichtenwarteschlange verwendet
wird. Verglichen mit der Verwendung eines physikalischen Semaphors
kann es beispielsweise schneller und/oder leichter sein, während einer
kritischen Codesektion, wie beispielsweise Lesen oder Aktualisieren
einer gemeinsam genutzten Cachekontrollstruktur, Interrupts einfach
zu deaktivieren und sie danach erneut zu aktivieren. In einer bevorzugten
Ausführungsform
ist die Verwendung von Interrupts auf vorhersagbar kurze Aktionen
begrenzt, um jegliche Auswirkungen auf andere Tasks zu begrenzen.
Alternativ kann die E/A-Warteschlange als gemeinsam genutzter „semaphorgeschützter" Speicherpuffer anstatt
einer Nachrichtenwarteschlange implementiert werden, wenn der E/A-Manager 270 vollständig in
der statisch verknüpften
Softwarebibliothek der Datenzugriffs-Schnittstellenschicht 41 implementiert
wird. Eine Beschreibung dieser alternativen Ausführungsform folgt weiter unten.
Bei noch einer weiteren Alternative wird eine Schnittstellenschicht-Singletask
ohne jegliche Multitasking-Konkurrenz um diese internen Ressourcenmanagement-Strukturen
bereitgestellt.
-
Die
Betriebssystem-Isolierschicht 302 erlaubt eine Definition
für die
Standardschnittstellen, für
die die Datenzugriffs-Schnittstellen-Softwarebibliothek 41 geschrieben
werden kann. Einige der Betriebssysteme, auf die die Datenzugriffs-Schnittstellenschicht 41 portiert
werden kann, stellen einige oder alle dieser Schnittstellen bereit.
In diesen Fällen
kann anstatt der entsprechenden durch die Betriebssystem-Isolierschicht 302 bereitgestellten
Funktion der vom BS bereitgestellte Schnittstellendienst verwendet
werden. Einige UNIX-Varianten und einige einbettungsorientierte
Betriebssysteme stellen vollständige
ANSI-C-stdlib- und POSIX.4-Dienste zur Verfügung.
-
G. Trägervorrichtungs-Isolierschicht
(MDIL) 300
-
Die
Trägervorrichtungs-Isolierschicht
(MDIL) 300 übt,
mit Ausnahme der Trägervorrichtungstreiber-Schnittstelle,
eine ähnliche
Funktion aus wie die Betriebssystem-Isolierschicht 302.
Im Allgemeinen wird insbesondere bei langsamen CD-ROM-Trägern die
Leistung deutlich erhöht,
wenn durch den Vorrichtungstreiber gestreutes oder übersprungenes
Lesen unterstützt
wird. Dieses Merkmal ermöglicht
es, eine bestimmte Anzahl nicht zusammenhängender, aber nahe liegender
Sektoren in dieselbe Anzahl separater von der Aufrufanwendung bereitgestellter
Speicherpuffer zu lesen. Dieses Merkmal ermöglicht annähernd sequentielle Zugriffsleistung,
ohne dass jede Anfrage separat versendet werden muss. Bei Verwendung
auf Trägern
wie einer CD-ROM kann durch dieses Merkmal eine gewisse zusätzliche
Drehwartezeit entstehen und unter Umständen eine Rückwärtssuche erforderlich werden,
da die Daten auf solchen Trägern
physikalisch in einer Spirale gespeichert sind. Darüber hinaus
kann es aufgrund dieses Merkmals erforderlich sein, einen größeren zusammenhängenden
Speicherpuffer zum Halten der gewünschten Sektoren sowie eventueller
ungewünschter
Pufferfelder zuzuweisen.
-
Die
Trägervorrichtungs-Isolierschicht 300 unterstützt eine
Vorrichtungsfähigkeit
zum gestreuten Lesen, ohne dass die tatsächliche Vorrichtung gestreutes
Lesen unterstützen
muss. Die E/A-Managerkomponente 270 des Ressourcenmanagements 220 schreibt
an eine einzige Geräteschnittstelle,
die ein Array annimmt, das eine Sequenz von physikalischen Trägeradressen,
Umfang und Speicherpufferzeigern darstellt. Die Größe dieser
Sequenz ist konfigurierbar. Wenn die Trägervorrichtung des Navigationssystems
diese Art Schnittstelle für
gestreutes Lesen akzeptiert, kann auf die Trägervorrichtungs-Isolierschicht 300 verzichtet
werden. Es kann allerdings sein, dass die vom Navigationssystem 10 bereitgestellte
Vorrichtungsschnittstelle dieses Merkmal nicht aufweist, selbst
wenn Unterstützung
für gestreutes
Lesen vorgesehen ist. Beispielsweise kann eine verknüpfte Liste
mit diesen Informationen anstelle von Array und Größe angefordert
werden. Alternativ kann die Datenstruktur anders geordnet sein.
Dementsprechend kann in einer vorliegenden Ausführungsform diese Art der Umsetzung
innerhalb der Trägervorrichtungs-Isolierschicht 300 durchgeführt werden.
-
Es
gibt auch Trägervorrichtungstreiber,
die gestreutes Lesen nicht unterstützen. Dies kann der Fall bei schnellen
Treibern oder bei Lese-/Schreib-Trägern sein.
Alternativ kann eine relativ langsame Leistung der Vorrichtung durch
mehr Speicher zum Cachen ausgeglichen werden. In diesen Fällen sendet
die Trägervorrichtungs-Isolierschicht 300 jede
der E/A-Transaktionen einzeln in das Eingangsarray.
-
Dementsprechend
ist die Trägervorrichtungs-Isolierschicht 300,
wie die Betriebssystem-Isolierschicht 302 auch, auf einen
spezifischen Trägertyp
zugeschnitten und kann für
den Prozess des Portierens der Datenzugriffs-Schnittstellenschicht 41 auf
eine jeweilige Plattform speziell erstellt werden. In einer bevorzugten Ausführungsform
sind die Trägervorrichtungs-Isolierschicht 300 und
die Betriebssystem-Isolierschicht 302 die einzigen zwei
Komponenten, die plattformabhängig
sind. Ferner weisen in der bevorzugten Ausführungsform die übrigen die
Datenzugriffsschnittstelle 41 umfassenden Bibliotheksfunktionen
einen identischen Quellcode für
alle Plattformen auf.
-
VII. Betrieb
-
Initialisierung und Zuweisung
von Speicherpool
-
In
einer bevorzugten Ausführungsform
ist die für
die Schnittstellenschicht verfügbare
Speichermenge teilweise von der jeweiligen Hardware-Plattform des
Navigationssystems abhängig.
Ferner kann in einer bevorzugten Ausführungsform die der Schnittstellenschicht
zur Verfügung
gestellte Speichermenge in begrenztem Maße von der Navigationsanwendung
gesteuert werden. In den 3 und 5 kann,
in einer Ausführungsform,
die Navigationsanwendung 200 bei der Systeminitialisierung
einen API-(Anwendungsprogrammierschnittstelle)-Aufruf an den Speichermanager 280 verwenden.
An diesem Punkt kann der Speichermanager 280 eine gewisse
Speichermenge zur Nutzung durch die Schnittstellenschicht zuweisen.
Ein Weg, wie der Speichermanager Speicher zur Nutzung durch die
Schnittstellenschicht zuweisen kann, besteht in der Verwendung eines
Funktionsaufrufs, wie malloc(), an das Betriebssystem der Navigationsanwendung,
um Speicher zugewiesen zu bekommen.
-
Der
bei der Initialisierung durch den Speichermanager 280 zugewiesene
Speicher bildet den Schnittstellenschicht-Speicherpool 278.
Der Speichermanager 280 unterteilt den Speicher in diesem
Speicherpool 278 in mehrere Speicherblöcke. In einer bevorzugten Ausführungsform
ist jeder Block ein zusammenhängender
Speicherbereich von vorbestimmter, fester Größe. Die vorbestimmte Speicherblockgröße kann
1 KByte oder 2 KByte oder von sonstiger Größe sein, die mit der Hardware
und Software des Navigationssystems übereinstimmt. In einer Ausführungsform
erhält
der Speichermanager 280 zunächst eine für die Schnittstellenschicht
erforderliche Mindestspeichermenge und weist diese zu und erhält dann
zusätzliche
Speicherblöcke durch
einen erneuten Funktionsaufruf (z.B. malloc()) an das Betriebssystem,
um zusätzlichen
Speicher zu erhalten, bis er all den Speicher zugewiesen hat, den
die Navigationsanwendung für
die Schnittstellenschicht konfiguriert hat. Dadurch, dass ein einziger
Speicherbereich zur Mindestverwendung zum Zeitpunkt der Initialisierung
und dann zusätzlicher
Speicher zu einem späteren
Zeitpunkt zugewiesen wird, kann die Speicherfragmentierung reduziert
werden, da spätere
Freigabe und erneute Zuweisung zu einer Veränderung des Umfangs der Speichernutzung
durch die Schnittstellenschicht führt, wie unten erklärt wird.
-
Freigabe und erneute Zuweisung
-
In
einer vorliegenden Ausführungsform
sorgt die Schnittstellenschicht in vorteilhafter Weise für eine dynamische
Anpassung der von ihr verwendeten Speichermenge. Dadurch kann ein
Teil des Speichers im Navigationssystem abwechselnd entweder von
der Schnittstellenschicht oder den Navigationsanwendungsprogrammen
benutzt werden, je nachdem, wo größerer Speicherbedarf herrscht.
In einer bevorzugten Ausführungsform
kann einer oder mehrere der zusätzlichen
Speicherblöcke über der
durch die Schnittstellenschicht zugewiesenen Mindestmenge anschließend an
die Navigationsanwendung zurückgegeben
werden, wenn die Navigationsanwendung zusätzlichen Speicher anfordert.
Gemäß dieser
Ausführungsform
kann das Navigationsanwendungsprogramm 200 während des
Betriebs die Rückgabe
einer Speichermenge von der Schnittstellenschicht fordern. Die Navigationsanwendung
kann diesen zusätzlichen
Speicher für
einen speicherintensiven Task anfordern, wie beispielsweise die
Anzeige einer großen
Anzahl Elemente. Nach Erhalt der Anfrage überprüft der Speichermanager 280,
ob der Schnittstellenschicht zusätzlicher
Speicher im Speicherpool 278 über dem erforderlichen Minimum
zugewiesen ist. Ist dies der Fall, dann identifiziert der Speichermanager 280 eine
Menge, die gleich einem oder mehreren Blöcken ist, aufgerundet auf den
nächst
höheren
ganzen Block über
der vom Navigationssystem angeforderten Menge. (In einer bevorzugten
Ausführungsform
bearbeitet der Speichermanager 280 bei Zuweisung oder Freigabe
von Speicher vom Navigationssystem ganze Blöcke.) Durch Rückgabe einer
auf den nächst
höheren
ganzen Block aufgerundeten Menge über der von der Navigationsanwendung
angeforderten Menge stellt die Schnittstellenschicht sicher, dass
die Navigationsanwendung zumindest die Speichermenge erhält, die
sie benötigt.
Der Speichermanager gibt den Speicher an die Navigationsanwendung
unter Verwendung eines Funktionsaufrufs, wie free(), an das Betriebssystem
des Navigationssystems zurück.
Entsprechend kann er, wenn das Navigationsanwendungsprogramm den
zusätzlichen Speicher
nicht mehr benötigt,
den Speicher an die Schnittstellenschicht zurückgeben. Die Rückgabe von
Speicher von der Navigationsanwendung an die Schnittstellenschicht
kann auf einen Prozess folgen, der dem oben beschriebenen anfänglichen
Speicherzuweisungsvorgang ähnlich
ist. Auf diese Weise ist sichergestellt, dass die Schnittstellenschicht
eine Mindestspeichermenge zur eigenen Nutzung als auch eine zusätzliche
Speichermenge zur routinemäßigen Verwendung
zur Verfügung
hat, wodurch für
eine relativ hohe Gesamtleistung gesorgt ist. Ferner kann die Navigationsanwendung
bei Vorliegen eines intensiven Tasks vorübergehend einen Teil oder den
gesamten der Schnittstellenschicht über der Mindestmenge zugewiesenen
Speicher verwenden. Dieses Merkmal der Schnittstellenschicht bietet
eine vorteilhafte Nutzung der Navigationssystemressourcen, indem
es eine dynamische Anpassung der Speichernutzung gestattet.
-
Speicherpoolnutzung
-
Der
Speichermanager 280 stellt Speicher aus dem Speicherpool 278 für zwei verschiedene
Task-Arten bereit. Erstens wird Speicher im Pool für privaten
Arbeitsplatz zur Verwendung durch die Schnittstellenschicht-Untersysteme
verwendet. Zweitens wird Speicher im Pool zum Cachen verwendet,
d.h. um vom Träger gelesene
Daten zu halten. Wenn ein Datenpaket vom Träger gelesen wird, wird es in
einem Cachepuffer gespeichert. Der Speichermanager 280 verfolgt
die Anzahl der verfügbaren
Speicherblöcke
im Speicherpool und die Anzahl der Blöcke, die für privaten Arbeitsplatz zugewiesen
werden können.
In einigen Ausführungsformen werden
neu zugewiesene oder freigegebene Blöcke vorzugsweise zum Cachen
anstatt für
privaten Arbeitsplatz verwendet.
-
Der
Speichermanager 280 weist in Antwort auf Taskanfragen nach
Puffer Speicher aus dem Speicherpool 278 sowohl zum Cachen
als auch für
privaten Arbeitsplatz zu. Ein angeforderter Puffer kann kleiner,
größer oder
gleich groß sein
wie einer der Speicherblöcke
im Speicherpool. Wenn der Speichermanager einer Anfrage nach einem
Speicherpuffer entsprechen will, dessen Größe über der festen Speicherblockgröße liegt, dann
versucht er, einen Satz zusammenhängender Speicherblöcke zu lokalisieren,
die der angeforderten Puffergröße entsprechen,
und diese zusammenhängenden
Mehrfachblöcke
zur Bedienung der Anfrage zuzuweisen. Eine angeforderte Speichermenge
kann auch kleiner sein als die Größe eine ganzen Blocks. Um kleineren
Anfragen zu entsprechen, unterteilt der Speichermanager einen Speicherblock.
Anfragen nach kleineren Speichermengen erfolgen typischerweise eher
für privaten
Arbeitsplatz als zum Cachen.
-
Jedem
ob zum Cachen oder für
privaten Arbeitsplatz zugeteilten Puffer wird eine Puffer-ID zugewiesen.
Diese Puffer-ID ist ein konstantes Handle, das mit dem Puffer während der
Lebensdauer des Puffers verknüpft
ist. Speicherzeiger auf den Puffer können sich aufgrund von Speicherverdichtung ändern. In
einer bevorzugten Ausführungsform
wird für
Puffer, die zum Cachen verwendet werden, die Paket-ID als Puffer-ID
verwendet. Für
Puffer, die für
internen Arbeitsplatz verwendet werden, wird eine eindeutige Pufferkennung
generiert.
-
Taskpufferanzahl und Taskpufferstatus
-
Das
Ressourcenmanagementsystem verfolgt die Cachepufferanzahl eines
jeden Tasks. Die Pufferanzahl eines Tasks entspricht der Anzahl
der Puffer, die ein Task „besitzt". Ein Task besitzt
immer dann Puffer, wenn ein Task Daten in einem Puffer anfordert
beziehungsweise liest oder wenn ein Puffer mit einem anderen Task
geteilt wird, der im Besitz war, und der andere Task den Besitz
anschließend
freigibt. Wird der Puffer zum Cachen verwendet, so umfassen die
Daten im Puffer ein vom Träger
gelesenes Paket, und die Inhaberschaft am Puffer wird durch den
Task bestimmt, der das Paket angefordert hat. Wenn mehr als ein
Task Daten in einem Puffer anfordern, so weist der Speichermanager
die Pufferinhaberschaft dem letzten Task zu, der die Daten im Puffer
angefordert beziehungsweise dem letzten Task, der Daten aus dem
Puffer gelesen hat. Ein Task verliert die Inhaberschaft an einem
Puffer, wenn ein anderer Task die Inhaberschaft am Puffer übernimmt
oder wenn der Task die Daten (d.h. das Paket) im Puffer ignoriert.
Ein Task verliert die Inhaberschaft an einem Puffer auch bei Auslagerung
des Puffers. Die Cachepufferanzahl eines Tasks ändert sich jedes Mal, wenn
der Task die Kontrolle über
einen Puffer übernimmt
beziehungsweise ihn verliert.
-
Tasks
können
zugewiesene Mindest- und Höchst-Cachepuffergrenzen
aufweisen. Diese Grenzen beziehen sich darauf, wie viele Puffer
ein Task „besitzen" kann. Diese Grenzen
können
nur geltend gemacht werden, wenn Konkurrenz um die verfügbaren Speicherressourcen
besteht. Ansonsten ist es jedem Task gestattet, so viel Speicher
zu verwenden, wie zur Verfügung
steht. Besteht Konkurrenz um Speicherressourcen, so verlieren Tasks,
die ihre Pufferhöchstgrenzen überschreiten,
Puffer. Sind Tasks lediglich an ihren Puffermindestgrenzen, verlieren
sie keine Puffer.
-
Jeder
Puffer hat einen Status. Der Speichermanager 280 verfolgt
den Status eines jeden Puffers. Der Status eines Puffers leitet
sich vom Status der Tasks ab, die den Puffer verwenden. Ein einziger
Puffer kann von mehr als einem Task benutzt werden. Der Speichermanager 280 behält einen
Status von jedem Task, der auf das Paket zugreift.
-
Der
Status eines Puffers kann „gesperrt", „aktiv" oder „ignorieren" sein. Werden die
Inhalte des Puffers momentan von einem Task benutzt, werden Taskstatus
und Pufferstatus auf „gesperrt" gesetzt. Wenn ein
Task, der ein Paket in einem Puffer benutzt, gesperrt ist, so ist
der Puffer ebenfalls gesperrt. Wenn ein Puffer gesperrt ist, steht
er nicht zum Auslagern aus dem Cache zur Verfügung. Zudem kann in einer bevorzugten
Ausführungsform
ein gesperrter Puffer nicht bewegt werden, wie zum Beispiel während der
Speicherverdichtung.
-
Ein
Puffer mit dem Status „aktiv" zeigt an, dass ein
oder mehrere Tasks möglicherweise
noch immer an den Inhalten des Puffers interessiert sind, der Puffer
jedoch ausgelagert werden kann, wenn der Speicher darin benötigt wird.
Informationen über
den Task, seine Ressourcenpriorität und so weiter bleiben mit
dem Puffer verknüpft,
so dass diese Faktoren vom Speichermanager ausgewertet werden können, wenn
der Manager nach auslagerbarem Speicher sucht. Wird der Puffer nicht
für andere
Tasks benötigt,
bleiben die Daten im Cachepuffer und der Puffer steht bei Bedarf
anderen Tasks zur Verfügung,
die möglicherweise
auf die Daten im Puffer zugreifen müssen.
-
Ein
Puffer mit dem Status „ignorieren" zeigt an, dass der
Speicher im Puffer derzeit von keinem Task benutzt wird. Dieser
Puffer kann daher für
andere Tasks verwendet werden oder ausgelagert werden. Ignorierte
Puffer können
auch bewegt und/oder verdichtet werden.
-
Verdichtung
-
Der
Ressourcenmanager sorgt auch für
Verdichtung und so genannte „Speicherbereinigung" des Schnittstellenschicht-Speicherpools 278.
Bei der Zuweisung und Freigabe von Speicherblöcken kann es innerhalb des
Speicherpools zu Fragmentierung kommen. Der Speichermanager 280 gruppiert
benachbarte unbenutzte Speicherblöcke und Speicherblöcke mit
dem Status „ignorieren" für nachfolgende
Wiederverwendung zum Cachen oder für privaten Arbeitsplatz zusammen.
Zusätzlich
kann der Speichermanager zur Reduzierung der Fragmentierung ungesperrte
Puffer physikalisch bewegen.
-
Bei
der Entscheidung über
Auslagerung oder Verdichtung von Speicher berücksichtigt der Speichermanager
Ressourcenpriorität,
Taskpufferanzahl und Pufferstatus. Im Allgemeinen besteht bei einer
Anwendung mit hoher Priorität
oder einer Anwendung, die häufig
auf ihren Cache zugreift, eine geringere Wahrscheinlichkeit, dass
ihre Puffer ausgelagert werden.
-
Bei
der Freigabe oder Verdichtung von Speicher kann es vorzuziehen sein,
den Speicher in dem Bereich auszuwählen, der der ursprünglichen
Grenze zwischen dem zugewiesenen Speicher 278 der Schnittstellenschicht
und dem zugewiesenen Speicher 283 der Anwendung am nächsten liegt.
-
Verarbeiten eines Abfrage-Tasks
-
Wie
oben erwähnt,
definiert die Schnittstellenschicht einen Satz von Aufrufen, die
von einem Navigationsanwendungsprogramm für den Zugriff auf einen Satz
geographischer Datenentitäten
auf einem physikalischen Speicherträger verwendet werden können. Der
von der Schnittstellenschicht zurückgegebene Satz kann leer sein,
eine einzige Entität
enthalten oder eine Liste mit mehreren Entitäten zurückgeben. Diese zurückgegebenen
Entitäten
entsprechen dem oben beschriebenen logischen Datenmodell, welches
ein dekomprimiertes Format ist. Die Schnittstellenschicht akzeptiert
Aufrufe, die es der Navigationsanwendung gestatten, eine Datenabfrage
zu formulieren. Diese Aufrufe können
durch räumliche
als auch nicht-räumliche
Attribute der gewünschten
Entitäten
näher bestimmt
sein. Die zur näheren
Bestimmung einer Abfrage verwendeten Attribute können einzeln oder in Kombination
verwendet werden und einen Bereich oder einen einzigen Wert spezifizieren.
-
In
einer bevorzugten Ausführungsform
sind die geographischen Daten auf dem Träger in einer oder mehreren
Dateien organisiert. Die Daten umfassen räumlich organisierte Daten,
nicht-räumlich
organisierte Daten und Indexdaten. Der Speicherträger kann
auch noch andere Datentypen umfassen. Die räumlich organisierten Daten
umfassen Daten wie beispielsweise Straßensegmente und Knoten. In
einer bevorzugten Ausführungsform
sind diese Daten in Pakete organisiert, welche die Datenentitäten beinhalten,
die in physikalischen geographischen Örtlichkeiten innerhalb der
geographischen Region enthalten sind. Nicht-räumlich organisierte Daten können Daten
wie beispielsweise Namen von navigierbaren Merkmalen umfassen. Diese
Daten können
so organisiert sein, dass ihre Verwendung erleichtert wird, zum
Beispiel alphabetisch oder nach Gemeinde. Indexdaten umfassen Indizes,
die die verschiedenen räumlichen
und nicht-räumlichen
Daten miteinander in Beziehung setzen. Diese Indizes können kd-Baum-Indizes, B-Baum-Indizes
und so weiter umfassen. In einer bevorzugten Ausführungsform
sind all diese Datentypen in Paketen enthalten, die jeweils durch eine
eindeutige Paket-ID identifiziert sind. In einer bevorzugten Ausführungsform
steht die Paketgröße mit einer
physikalischen Sektorgröße auf dem
physikalischen Träger
in Beziehung. Bei CD-ROM-Trägern
beispielsweise beträgt
die Sektorgröße 2 KBytes,
und die Paketgröße ist ein
Vielfaches der Sektorgröße, z.B.
16 KBytes. In einer bevorzugten Ausführungsform greift die Schnittstellenschicht
auf Daten vom Träger
in ganzen Paketen zu und lädt
in einem einzigen physikalischen Einlesevorgang ganze Pakete in
den Speicher, um eine Abfrage aufzulösen. Zur Auflösung einer
Abfragetransaktion können
mehrere Pakete in den Speicher gelesen werden.
-
Empfängt das
Abfragelogik-Untersystem 210 vom Navigationsanwendungsprogramm 200 einen
Aufruf für
geographische Daten, so kann die Anfrage in Form einer „geo-codierten" Anfrage sein. Dies
bedeutet, dass die Navigationsanwendung 200 Daten wünscht, die
sich auf gewisse geographische Zustände oder Grenzen beziehen.
Das Abfragelogik-Untersystem 210 löst die Anfrage durch Abbildung
der Anfrage auf einen Paketsatz in Paket-IDs auf, so dass die Daten
aus dem Träger
abgerufen werden können.
Dies erfolgt unter Verwendung des Indexmanagement-Untersystems 242.
Dementsprechend kann es erforderlich sein, zunächst auf die Indexdaten zuzugreifen,
um die Paket-IDs der zur Beantwortung der Abfrage notwendigen geographischen
Daten zu identifizieren. Häufig
verwendete Indexdaten können
zum Zeitpunkt der Initialisierung in den Speicher gelesen werden.
Befinden sich die gewünschten
Indexdaten noch nicht im Speicher, werden sie vom Träger gelesen.
-
Sobald
die Paket-ID der gewünschten
Daten identifiziert ist, wird die Anfrage nach dem Paket an den Speichermanager 280 gerichtet.
Der Speichermanager untersucht den Cacheteil des Speicherpools,
um festzustellen, ob das angeforderte Paket in Antwort auf eine
Anfrage eines vorhergehenden Tasks bereits im Cachespeicher gespeichert
wurde. Befindet sich das angeforderte Paket bereits im Cache, so
gibt der Speichermanager 280 einen Zeiger auf den Cachepuffer
an den anfragenden Task zurück
und sperrt den Puffer (wie oben erläutert). Befindet sich das angeforderte
Paket noch nicht im Cache, so sendet der Speichermanager 280 die
Anfrage an den E/A-Manager 270. Im E/A-Manager 270 wird
das angeforderte Paket mit einer Liste von Paketen verglichen, die
bereits angefordert, aber noch nicht zum Trägertreiber gesendet wurden.
Befindet sich das Paket auf der Liste der angeforderten Pakete,
so wird die Kennung des Tasks (des Klienten) zu der mit dem Paket
verknüpften
Information hinzugefügt.
Befindet sich das Paket nicht in der Liste, so wird das Paket mit
in die Liste aufgenommen, und zwar zusammen mit einer Kennung des
das Paket anfordernden Tasks (Klienten) sowie mit Informationen,
die Sektorstelle und Länge
des Pakets angeben. Fordert ein Task eine Mehrzahl Pakete an, so
wird die Paketauflistung als Gruppe an den E/A-Manager zum Abruf
gesendet, um gleichzeitig der Anfrage zu entsprechen.
-
Der
E/A-Manager 270 ruft für
jedes angeforderte Paket den Mapper physikalischer Adressen 296 auf. Der
Mapper physikalischer Adressen 296 setzt die Paket-ID um
und gibt Paketgröße und physikalischen
Ausgangssektor (oder Sektoren, wenn das Paket redundant gespeichert
ist) zurück.
Unter Verwendung dieser Informationen sortiert der E/A-Manager 270 die
E/A-Anfragen nach Priorität
und Sektornähe-Reihenfolge
unter Berücksichtigung
der aktuellen Lesekopfposition. Bei redundant gespeicherten Paketen
wählt der
E/A-Manager 270 den Sektor aus, der die geringste Suchzeit
ergibt.
-
Für die Zuweisung
von Cache ruft der E/A-Manager 270 den Speichermanager 280 auf.
Der Speichermanager 280 durchsucht eine Liste mit freiem
Speicher im Speicherpool 278, um verfügbaren Speicher zu finden,
und fügt
den verfügbaren
Speicher zum Cache hinzu. Wie oben beschrieben, sperrt der Speichermanager 280 einen
Puffer, um anzuzeigen, dass der zum Puffer gehörige Speicher für die E/A
reserviert ist. Es werden auch Daten gespeichert, die den Kliententask,
welcher die E/A anforderte, identifizieren.
-
Findet
der Speichermanager 280 keinen verfügbaren Speicher, so versucht
er, Speicher auszulagern. Wie oben erwähnt, werden gesperrte Puffer
nicht ausgelagert. Sind Puffer mit dem Status „ignorieren" vorhanden, werden
diese zuerst ausgelagert. Wird für
die Zuweisung von Cache für
eine neue E/A immer noch Speicher benötigt, so wird die Taskliste
untersucht, um festzustellen, ob es Tasks gibt, die ihre Pufferhöchstgrenze überschritten
haben. Ist dies der Fall, so sucht der Speichermanager 280 nach
nicht gesperrten vom Task benutzten Puffern und wählt diese
zum Auslagern aus. Wird für
neue Daten immer noch Speicher zum Zuweisen benötigt, so werden Puffer mit
dem Status „aktiv" untersucht, und
diese werden zur Verwendung für
die neuen Daten ausgelagert.
-
Kann
der Anfrage nach Speicherpuffer für die neue E/A mit dem im Speicherpool 278 verfügbaren Speicher
nicht entsprochen werden, so kann der Speichermanager 280 eine
Verdichtung des Speicherpools durchführen. Wie oben beschrieben,
stehen nur nicht gesperrte Puffer für die Verdichtung zur Verfügung.
-
Es
kann vorkommen, dass selbst nach der Verdichtung kein Speicher in
der vom E/A-Manager für
die neue E/A angeforderten Größe zur Verfügung steht.
Wenn dies geschieht, gibt der Speichermanager 280 an den
E/A-Manager 270 eine Information über den größten verfügbaren Cacheplatz zurück. Der
E/A-Manager 270 durchsucht dann die E/A-Anfrageliste, um
festzustellen, ob es eine auf Abarbeitung wartende E/A-Anfrage gibt,
der mit dem verfügbaren
Cache entsprochen werden kann. Wenn es eine auf Abarbeitung wartende E/A-Anfrage
gibt, der mit der verfügbaren
Cachegröße im Speicher
entsprochen werden kann, wird diese E/A-Anfrage bedient. Der E/A-Manager 270 sendet
an den Speichermanager 280 eine Meldung, den in der angeforderten
Größe verfügbaren Cachespeicher
zu sperren. Dann sendet der E/A-Manager 270 die E/A-Anfrage
an den Trägertreiber
zum Abruf.
-
Entspricht
keine E/A-Anfrage in der E/A-Anfrageliste dem verfügbaren Speicher,
stellt der E/A-Manager 270 die Generierung von neuen Cache-Anfragen
an den Speichermanager 280 vorübergehend ein. Bei der Beendigung
von Tasks entsperrt beziehungsweise gibt der Speichermanager 280 dann
Speicher frei, und mit der Verfügbarkeit
von Speicher werden die anstehenden E/A-Anfragen bedient.
-
Wenn
der Speichermanager 280 dem E/A-Manager 270 anzeigt,
dass Cache für
die Bedienung einer E/A-Anfrage zur Verfügung steht, wird der Puffer
reserviert. Der E/A-Manager arbeitet die E/A-Anfrageliste durch
Erstellen von Anfragen für
gestreutes Lesen ab. Mehrere Lesevorgänge können miteinander verkettet werden.
Sobald diese Information an den Trägertreiber gesandt ist, werden
die E/A-Anfragen von der E/A-Anfrageliste entfernt.
-
Der
Speichermanager 280 setzt den Status des Cachepuffers auf „aktiv". Der Speichermanager
gibt einen Zeiger auf den Puffer an den Task zurück, der die Daten anforderte,
z.B. ein Aufruf vom Abfragelogik-Untersystem. Sobald der Zeiger
auf den Puffer an den ihn anfordernden Task zurückgegeben ist, wird der Status des
Puffers auf „gesperrt" gesetzt. Die Daten
im Cachepuffer werden nach Bedarf verwendet. Der Zeiger auf den
Puffer wird erst geändert,
wenn der Task den Puffer entsperrt, z.B. indem er anzeigt, dass
er mit den Daten im Puffer fertig ist. Wenn die Daten (im logischen
Datenmodellformat) an die Navigationsanwendung zurückgegeben
werden, und die Daten im Cachepuffer somit nicht mehr vom Task benötigt werden,
gibt der Task im Abfragelogik-Untersystem 210 auch eine
Meldung an den Speichermanager, den Cachepuffer von „gesperrt" auf „aktiv" oder „ignorieren" zurückzustellen,
womit anzeigt wird, dass die Daten derzeit nicht benötigt werden. Wenn
der Puffer nicht mehr „gesperrt" ist, kann er verdichtet,
bewegt oder freigegeben werden.
-
Im
Allgemeinen werden Daten so lange wie möglich in Übereinstimmung mit anderen
Bedingungen im Cache bewahrt. Dies hat den Vorteil, dass Daten,
sobald sie im Speicher sind, in einem Cache gespeichert werden,
weil die Daten möglicherweise
für einen
nachfolgenden Task benötigt
werden könnten.
Die Daten können
daher über
einen mehrere von der Navigationsanwendung getätigte Aufrufe umfassenden Zeitraum
im Cache fortbestehen. Um Speicherverdichtung und Defragmentierung
zu gewährleisten,
können
nicht gesperrte Daten vom Speichermanager 280 von einer
Speicherstelle an eine andere verschoben werden. Um die sich möglicherweise
im Cache befindlichen Daten zu finden, fordert ein Task die Daten
anhand der Puffer-ID an, welche in einer bevorzugten Ausführungsform
dieselbe wie die Paket-ID für
Cache-Daten ist. Wenn ein Task ein Paket anfordert, erhält er daher
einen Zeiger auf eine Adresse eines Puffers. Der „angezeigte" Puffer weist eine
Puffer-ID auf, welche dieselbe ist wie die angeforderte Paket-ID.
Auf diese Art und Weise gibt der Speichermanager 280, indem
er sich über
Puffer-IDs und ihre Adressen auf dem Laufenden hält, an den Task einen Zeiger
zurück,
der angibt, wo sich der Puffer befindet. Verschiebt der Speichermanager 280 einen
Puffer während
der Verdichtung, verfolgt er den neuen Standort des Puffers, so
dass der passende Zeiger an jeden diesen bestimmten Puffer anfordernden
Task zurückgegeben
werden kann. Im Speicherpuffer selbst beibehaltene Zeiger sind durch
Offset und nicht durch absolute Adresse definiert, da sich die Basisblockadresse
verschieben kann.
-
Verarbeitung eines privaten
Arbeitsplatz anfordernden Tasks
-
Wie
oben erwähnt,
weist der Speichermanager 280 auch Puffer für privaten
Arbeitsplatz für
Schnittstellenschicht-Funktionen zu. Wie oben erwähnt, unterteilt
der Speichermanager 280, wenn der von einer Schnittstellenschicht-Funktion
angeforderte Speicher kleiner ist als einer der Blöcke mit
fester Größe im Speicherpool 278,
den Block in Stücke
kleinerer Größe. Wenn
eine Anfrage nach privatem Arbeitsplatz erfolgt, durchsucht der
Speichermanager 280 zunächst
Speicherblöcke,
die von privaten Speicherfunktionen bereits genutzt werden, um festzustellen,
ob im Block ausreichend Platz zur Verfügung steht, um den Speicherbedarf der
neuen Anfrage zu decken. Bei Bedarf können zusätzliche Blöcke für privaten Arbeitsplatz zugewiesen
werden.
-
Der
Speichermanager 280 weist jedem für privaten Arbeitsplatz verwendeten
Block eine eindeutige Puffer-ID zu. Diese Puffer sind während der
Nutzung durch die Schnittstellenschicht-Funktion gesperrt.
-
Betrieb des Untersystems
zur physikalisch-logischen Datenumsetzung
-
Das
physikalisch-logische Untersystem 244 ist für die Umsetzung
von Informationen aus dem optimierten physikalischen Speicherformat
zuständig,
das bei Paketen vorliegt, die vom Ressourcenmanagement-Untersystem 220 aus
dem Träger
in den Speicher gelesen wurden. Diese Umsetzung erfolgt in zwei
Phasen. Die erste Phase erfolgt vom komprimierten physikalischen
Speicherformat in das dekomprimierte Zwischenformat (DIF), das zur
Auflösung
von Abfragen untersucht werden kann. Die zweite Phase erfolgt vom dekomprimierten
Zwischenformat in das endgültige
logische Datenmodellformat, das an die Anwendung über das
Abfragelogiksystem 210 zurückgegeben wird.
-
Betrieb des Cursormanagementsystems
-
Die
Daten anfordernden Tasks können,
wie oben beschrieben, im Ergebnis dazu führen, dass entweder kleine
oder große
Datenmengen gefunden werden. Das Cursormanagement-Untersystem 249,
welches Teil des Abfragelogik-Untersystems 210 ist, bearbeitet
diese Ergebnisse unabhängig
von der aus einer Anfrage resultierenden Datenmenge. Der Betrieb
des Cursor-Untersystems beginnt mit einer Funktion im Abfragelogik-Untersystem,
die damit rechnet, in Verbindung mit einer Datenanfrage eine Benutzung
des Cursor-Untersystems anzufordern. Es können mehrere verschiedene Funktionen
im Abfragelogik-Untersystem 210 damit rechnen, einen Datenabruf
zu tätigen,
der die Verwendung des Cursormanagement-Untersystems bedingt. Die Funktion im
Abfragelogik-Untersystem initialisiert zunächst Speicher, d.h. einen Puffer,
für den
Cursor. Der Cursorcache ist ein Teil des Speichers, der ein Datenstrukturarray
hält. Die
Strukturen werden von der Abfragefunktion auf Grundlage des Abfragetyps
bestimmt. Informationen über
die Strukturen werden an das Cursormanagement-Untersystem weitergeleitet.
Die Informationen können
die Anzahl der in einem Cursorcache zu verwendenden Datensätze, Datensatzgröße, Anzahl
der Datenentitäts-IDs
(DBIDs), die im Cursorspeicher gespeichert sein könnten, und
so weiter beinhalten. Einige dieser Informationen können von
fester Größe sein, wie
z.B. die DBID. In der 5A wird diese Information zur
Erstellung der Arrays 511 und 513 verwendet, um die
dekomprimierten Datenentitäten
beziehungsweise die Datenentitäts-IDs
zu halten.
-
Nachdem
der Cache des Cursors zugewiesen ist, wird, wie oben beschrieben,
die Abfrage verarbeitet, um die Datenergebnisse zu erhalten. Werden
mehrere der Anfrage entsprechende Entitäten lokalisiert, so wird jede
der abgerufenen Datenentitäten
im vollständig
dekomprimierten logischen Datenformat im Array 511 gespeichert,
bis das Array voll ist. Die Datenentitäts-IDs (DBIDs oder Datenbankkennungen)
für die
im Array 511 gespeicherten Datensätze sind im zweiten Array 513 enthalten.
Darüber
hinaus werden, wenn die Anzahl der identifizierten auf die Abfrage
passenden Datenentitäten
die Anzahl der Datenentitäten übersteigt,
die in dekomprimierter Form im ersten Array 511 gespeichert
werden können,
die Datenentitäts-IDs
für diese
zusätzlichen
Datenentitäten
im zweiten Array 513 nach den IDs der im ersten Array gespeicherten
Datenentitäten
gespeichert. Im Beispiel der 5A sind
zwanzig Datenentitäten
in vollständig
dekomprimierter Form im ersten Array 511 gespeichert, und
die Entitäts-IDs von 100 Datenentitäten (einschließlich der
ersten zwanzig) sind im zweiten Array 513 gespeichert.
Jede dieser Datenentitäten
im ersten Array 511 kann sofort an das Navigationsanwendungsprogramm
zurückgegeben
werden, da sie vollständig
dekomprimiert sind. Sowohl die Anzahl von Entitäten, die im dekomprimierten
Array 511 gespeichert werden können, als auch die Anzahl der
Datenbank-IDs, die im Array 513 gespeichert werden können, werden
durch die das Cursormanagementsystem aufrufende Abfragefunktion
bestimmt.
-
In
einer bevorzugten Ausführungsform
unterstützt
das erste Array 511 sowohl FIFO (Erster-Rein-Erster-Raus)
als auch LIFO (Letzter-Rein-Erster-Raus) während der Verwendung des Cursorcaches.
Wenn ein Datensatz hinter dem letzten Datensatz im Array angefordert
wird, zum Beispiel Datensatz 21, wird diese Datenentität aufgefunden
(unter Verwendung der Entitäts-DBID
im zweiten Array 513), in das logische Datenformat dekomprimiert
und in dekomprimierter Form im ersten Array 511 gespeichert
und ersetzt somit den ältesten
Datensatz (z.B. Datensatz 1). Entsprechend wird bei Anforderung
des Datensatzes 22 dieser unter Verwendung der Datenentitäts-ID vom
zweiten Array 513 aufgefunden, in das logische Datenformat
dekomprimiert und gespeichert und ersetzt so den Datensatz 2 im
ersten Array 511. Diese Art des Zugriffs erfolgt in der Vorwärtsrichtung
und würde
FIFO verwenden. Anderseits würde,
wenn Datensatz 1 dann angefordert würde, der Datensatz 1 abgerufen,
dekomprimiert und in dekomprimierter Form im ersten Array 511 gespeichert
werden und dabei den Datensatz 20 ersetzen. Der Datensatz 20 würde ersetzt
werden, da er der älteste
Datensatz im ersten Array 511 ist. Diese Art des Zugriffs
erfolgt in Rückwärtsrichtung
und würde
LIFO verwenden.
-
Ein
weiteres Beispiel ist in der 5B gezeigt.
In der 5B ist das erste Array 511 so
dargestellt, dass es mit den Datensätzen 25 bis 44 belegt ist.
Würde der
Datensatz 24 angefordert, würde
er dekomprimiert und im ersten Array 511 gespeichert und
so den Datensatz 44 ersetzen. Würde
dann der Datensatz 23 angefordert, so würde dieser dekomprimiert und
im Array 511 gespeichert und so den Datensatz 44 ersetzen
und so weiter.
-
In
den 5A und 5B ist
das zweite Array 513 (d.h. das Array, das nur die Datenentitäts-IDs aufnimmt)
in einer Größe dargestellt,
die die Aufnahme von lediglich 100 Datenentitäts-IDs ermöglicht. Die Abfrage kann unter
Umständen
mehr als 100 Entitäten
ergeben. Wenn es mehr Entitäts-IDs
gibt, als in das zweite Array 513 passen, behält das Cursor-Untersystem
eine Information zur Bereitstellung von einer oder mehreren zusätzlichen
Seiten mit Datenentitäts-IDs.
-
Das
nachfolgende Beispiel zeigt die Seitenwechselfunktion des Cursorsystems.
Der Zweckmäßigkeit halber
wird in diesem Beispiel angenommen, dass das erste Array 511 20
dekomprimierte Datenentitäten
und das zweite Array 513 100 Datenentitäts-IDs fassen kann, das Abfrageergebnis
jedoch 1000 Datensätze
ergibt.
-
-
Im
Beispiel umfasst das erste Array 511 zunächst die
Datensätze
80–100
in dekomprimierter Form und das zweite Array 513 die ersten
100 Datenentitäts-IDs.
An diesem Punkt umfasst weder das erste noch das zweite Array Datenentitäten oder
IDs nach dem Datensatz 100. Wenn die Anwendung auf den 101. Datensatz zugreifen
möchte,
muss die Abfrage erneut aufgelöst
werden. Alle Datenentitäts-IDs
im zweiten Array 513 werden gelöscht und mit Entitäts-IDs für die Datensätze 80–180 ersetzt.
Der Datensatz 101 wird dekomprimiert und im ersten Array 511 gespeichert
und ersetzt somit den Datensatz 80. Die Tabelle zeigt die Bereiche
für jede
Seite, wenn 1000 Datensätze
vorhanden sind und die Arrays 511 und 513 20 Datensätze beziehungsweise
100 Entitäts-IDs
halten.
-
Die
oben beschriebenen Arrays können
mit verschiedenen Datentypen verwendet werden, einschließlich Datentypen,
die keine eigene Entitäts-ID
aufweisen. Diese Datentypen können
Attribute sein, die mit Entitäten
in der Datenbank verknüpft
sind oder diese beschreiben. Beispiele für diese Datentypen umfassen
Blöcke,
Landmarken und Text. Diesen Datentypen teilt das Cursormanagementsystem
eine virtuelle ID zu. Bis auf die Tatsache, dass sie keinen Entitätstyp, sondern
einen Offset oder anderen Informationstyp repräsentieren würde, wäre die virtuelle ID einer regulären Datenentitäts-ID ähnlich.
-
Gewisse
Datentypen werden vom Cursormanagementsystem möglicherweise nicht bearbeitet,
sie würden
stattdessen das Cursormanagementsystem umgehen und direkt an die
Navigationsanwendung gesendet. Diese Datentypen können Shape-Punkte
umfassen. Zur Annahme der Informationen in Form von Shape-Punkten würde die
Navigationsanwendung geeignete Speicherpuffer bereitstellen.
-
VIII. Portieren und Konfiguration
-
Die 7 ist
ein Flussdiagramm und zeigt einen Prozess zum Kompilieren des Quellcodes
für die
Datenzugriffs-Schnittstellenschicht und die Navigationsanwendungs-Softwareprogramme,
um ein ausführbares Modul
zu bilden. In einer bevorzugten Ausführungsform wird der Quellcode
für die
Navigationsanwendungsfunktionen in Form von Bibliotheken der Quellcodefunktionen 502 geschrieben
und gesichert. Diese Bibliotheken werden zur Bildung eines Objektcodemoduls 504 für die Navigationsanwendungsfunktionen
kompiliert. Dieser Objektcode wird dann statisch mit dem Quellcode 506 für die Schnittstellenbibliotheksfunktionen
verknüpft,
um ein ausführbares
für eine
jeweilige Navigationssystemplattform spezifisches Modul 510 zu
bilden. Das ausführbare
Modul 510 kann auf der Navigationssystemplattform auf verschiedene
Arten installiert werden. So kann das ausführbare Modul beispielsweise
von einem zusätzlichen
Laufwerkseinschub kopiert oder in eine bestimmte Form nichtflüchtigen
Speichers im Navigationssystem vorinstalliert werden.
-
In
einer bevorzugten Ausführungsform
umfasst die Datenzugriffs-Schnittstellenschicht-Software
mehrere abstimmbare Parameter, deren Werte zur Leistungsoptimierung
auf einer jeweiligen Plattform angepasst werden können. Diese
Parameter können
als Teil des Portierungsprozesses angepasst werden. Der Portierungsprozess
umfasst die Optimierung dieser abstimmbaren Parameter für die Kombination
aus Navigationsanwendungssoftware, BS, Trägervorrichtungstreiber und
Hardware.
-
Die
Datenzugriffsschnittstellen-Softwarebibliotheks-Untersysteme sind
dafür geeignet,
entweder zum Zeitpunkt der Kompilierung, während der Laufzeit oder zu
beiden Zeitpunkten konfiguriert zu werden. Einige der Konfigurationsinformationen
können
die Form eines Satzes von C-Code-Variablen annehmen, die in einem separaten
Quellcodemodul residieren können.
Die Werte dieser Variablen können
sich auf das Laufzeitverhalten eines bestimmten Untersystems auswirken.
Diese Variablen können
anfangs auf Standardwerte gesetzt und in Quellcodeform angepasst
werden. Die resultierende optimierte Konfigurationsinformation wird
dann mit der Implementierung des jeweiligen Navigationuntersystems
verknüpft.
Zusätzliche
Konfigurationsinformationen nehmen die Form von bedingten Kompilierungsanweisungen
und präprozessor-definierten
Konstanten an, die dazu dienen, das Untersystemverhalten zum Zeitpunkt
der Kompilierung zu optimieren.
-
IX. Aktualisierung und
Kompatibilität über Versionsänderungen
-
Wie
oben erwähnt,
besteht einer der Vorteile, die die Datenzugriffs-Schnittstellenschicht
bietet, darin, dass sie eine Aktualisierung der geographischen Datenbank
ermöglicht.
Die Aktualisierung kann in mehreren Zusammenhängen erfolgen. Im Zusammenhang
mit neuen Navigationssystemen kann es beispielsweise sein, dass
eine bestimmte Navigationssystemplattform über mehrere Jahre zum Verkauf
angeboten wird. Beim Verkauf des Navigationssystems sollte die mit
dem System zur Verfügung
gestellte geographische Datenbank aktuell sein. Dieses Ziel kann
durch Verwendung der oben beschriebenen Datenzugriffs-Schnittstellenschicht
erreicht werden, indem zum Zeitpunkt der Auslieferung an den Endkunden
ein Speicherträger
in das Navigationssystem installiert wird, auf dem eine aktuelle
geographische Datenbank gespeichert ist. Aus Sicht des Endanwenders
ist es ferner wünschenswert,
dass der Endanwender nach Installation des Navigationssystems aktualisierte
geographische Daten während
der Lebensdauer des Navigationssystems beziehen kann. Um dieses
letztgenannte Ziel zu erreichen, können Abonnements angeboten
werden, mit denen Endanwendern regelmäßig Aktualisierungen zur Verfügung gestellt
werden. Die Datenzugriffs-Schnittstellenschicht
ermöglicht es
dem Endanwendersystem, aktualisierte geographische Daten zu verwenden.
-
Aktualisierungstransaktionen
können
unter Verwendung mehrerer Alternativen durchgeführt werden. Eine Alternative
besteht darin, die geographischen Daten an einer zentralen Stelle
zu aktualisieren, eine völlig neue
geographische Datenbank zusammenzustellen und neue Kopien des Speicherträgers mit
der neuen Datenbank zu erstellen. Diese neuen Träger würden anschließend an
Endanwender-Abonnenten
vertrieben, die ihre alten Speicherträger dann mit den neuen Trägern ersetzen.
Diese Alternative kann zum Einsatz kommen, wenn der Träger nicht
wiederbeschreibbar ist, wie beispielsweise eine CD-ROM. Wenn der
Träger
wiederbeschreibbar ist, wie beispielsweise eine PCMCIA-Karte, so
kann die neue geographische Datenbank direkt auf den alten Träger angewendet
werden. Eine weitere Alternative besteht darin, aktualisierte geographische
Daten in Form einer separaten Datei oder Datenbank bereitzustellen,
die eine Auflistung der Änderungen
bezogen auf die Version der geographischen Datenbank im Endanwendersystem
enthält.
Diese separate Datei kann sich auf demselben Träger befinden wie die ursprüngliche
geographische Datenbank (im Fall von mehrfach beschreibbaren Trägern) oder
auf einem separaten Träger
(im Fall eines ursprünglichen
Trägers,
der schreibgeschützt
ist). Sobald auf die separate Datei im Navigationssystem zugegriffen
werden kann, wird sie zusammen mit der ursprünglichen geographischen Datenbank
verwendet. Die aktualisierten Daten der separaten Datei werden transparent
auf die entsprechenden Datenentitäten angewendet, wenn das Navigationssystem über die
Datenzugriffs-Schnittstellenschicht (z.B. ein „Look-Aside") darauf zugreift. Diese Funktion 811 kann
im physikalisch-logischen Untersystem 244 der Schnittstellenschicht
implementiert werden. Die aktualisierten geographischen Daten können über verschiedene
Wege vertrieben werden, einschließlich drahtloser Übertragung
oder Aktualisierungsstationen, wie in der gleichzeitig anhängigen,
am 26. Januar 1996 eingereichten Anmeldung, Anmelde-Nr. 08/592,737,
mit dem Titel „SYSTEM
AND METHOD FOR DISTRIBUTING INFORMATION FOR STORAGE MEDIA" offenbart ist.
-
Die
Datenzugriffs-Schnittstellenschicht gestattet es dem Navigationssystem
nicht nur, aktualisierte geographische Daten, sondern auch in neuen
Formaten bereitgestellte geographische Daten zu verwenden. Die Datenzugriffs-Schnittstellenschicht 41 und
das logische Datenmodell können
erweitert werden, um von neuen Datenattributen oder -werten zu profitieren,
die der Geodatenbank zukünftig
hinzugefügt
werden, um neuen Anforderungen Rechnung zu tragen. Neue Attribute
oder Werte können
in den Kartengeltungsbereichsdaten oder im physikalischen Speicherformat
erscheinen. Wenn neue Kartendatenmerkmale erscheinen, können sie auf
den Trägern
mit geographischen Kartendaten aufgenommen und von jedem Navigationssystem
verwendet werden, das diese unterstützt. Das physikalische Speicherformat
kann sich also dahingehend weiterentwickeln, zusätzliche, über den derzeitigen Stand hinausgehende Informationstypen
aufzunehmen. Da die Datenzugriffs-Schnittstellenschicht die Navigationsanwendung
von der physikalischen Geodatenbank isoliert, entfällt für den Navigationsanwendungshersteller
jedoch die Notwendigkeit, seine Navigationsanwendungssoftware bei
jeder Aktualisierung der Geodatenbank aufzurüsten. Darüber hinaus kann der Endanwender,
der im Besitz eines installierten Navigationssystems ist, im Laufe
der Jahre aktualisierte Geodatenbanken erwerben und sicher sein,
dass diese in seinem Navigationssystem auch dann funktionieren,
wenn die aktualisierten Geodatenbanken neue Informationstypen umfassen.
Da für
den Herausgeber-Vertreiber von geographischen Datenbanken keine
Notwendigkeit besteht, mehrere unterschiedliche Geodatenbankformate
für verschiedenste Hardwareplattformen
herzustellen, können
die geographischen Datenbanken den Endanwendern potenziell kostengünstiger
und möglicherweise
auch häufiger,
mit weniger Vertriebsaufwand und weiteren Vorteilen zur Verfügung gestellt
werden.
-
Wenn
dem physikalischen Speicherformat neue Attribute hinzugefügt oder
andere Änderungen
am physikalischen Speicherformat vorgenommen werden, kann die Versionsstufe
des physikalischen Speicherformats in der Entwicklung weiter sein
als die Versionsstufe des Navigationsanwendungsprogramms. Bei der
Installation einer aktualisierten Geodatenbank in einem Navigationssystem
können
die Versionsstufen des logischen Datenmodellformats und des physikalischen
Speicherformats also unterschiedlich sein. Bei weiter ansteigenden
Versionsstufen von Datenbanken, wie sich dies im physikalischen
Speicherformat widerspiegelt, ermöglicht die Datenzugriffs-Schnittstellenschicht
Aufwärtskompatibilität, damit
das Endanwendersystem brauchbar bleibt. Aufwärtskompatibilität kann auf
diese Weise langfristig unterstützt
werden, möglicherweise bis
zu 10 Jahre. Datenversionsänderungen
können
zum Beispiel das Hinzufügen
neuer Attribute oder Werte umfassen, und daher besteht eine Methode,
mittels derer die Datenzugriffs-Schnittstellenschicht
neue Attribute oder Werte aufnehmen kann, darin, die neuen Daten
auszufiltern und sie umzuordnen und umzuwandeln, damit sie auf die
alte Vorlage passen.
-
Kompatibilität über verschiedene
Versionsstufen wird durch Meta-Umsetzung ermöglicht. Bei der Meta-Umsetzung
wird für
jede Versionsstufe ein Tabellensatz verwendet. In der 3 residieren
diese Metadaten-Tabellen 259 auf dem Speicherträger 22 (z.B.
auf der CD-ROM oder der PCMCIA-Karte). Die Metadatentabellen umfassen
Informationen, die Ort, Größe, Typ
sowie Inhalt der verschiedenen in einer gegebenen Datenbankentität erscheinenden
Datenattribute und -werte beschreiben. Für die Konvertierung aus dem
komprimierten physikalischen Speicherformat auf dem Träger in das
vom Abfragelogik-Untersystem 210 verwendbare dekomprimierte
Zwischenformat wird im Untersystem zur physikalisch-logischen Datenumsetzung 244 für jede Datendarstellung
im physikalischen Speicherformat eine Metadaten-Tabelle verwendet.
Die Metadaten im physikalischen Speicherformat dienen zur Extrahierung
eines Datenelements bezogen auf den Anfang einer bestimmten Entität im physikalischen
Speicherformat. Das Datenelement wird dann einem Umsetzungs- oder Konvertierungsprozess
unterzogen, der von den Informationen in den Metadaten-Tabellen
gesteuert wird.
-
Auf
dem Speicherträger
können
sich für
jede Datenversion, von der frühesten
bis zu einer aktuellen, Metadaten-Tabellen befinden. Die Versionsstufe
der die Datenzugriffs-Schnittstellenschicht 41 bildenden
Software-Bibliothek wird zur Identifizierung des zu verwendenden
geeigneten Metadatensatzes verwendet.
-
Die
Metadaten-Tabellen werden aus dem Speicherträger über den Betriebssystemkernel
und das Untersystem der physikalischen Vorrichtung (d.h. die Betriebssystem-Isolierschicht 302 und
die Trägervorrichtungs-Isolierschicht 300)
gelesen. Von diesen Untersystemen liefert das Ressourcenmanagement-Untersystem 220 die
Metadaten an das Untersystem zur physikalisch-logischen Datenumsetzung 244,
wo die Meta-Umsetzung durchgeführt
wird. In einer bevorzugten Ausführungsform
werden die Metadaten nur zum Zeitpunkt der Initialisierung physikalisch
vom Träger
gelesen. Die Metadaten-Tabellen werden in den von der Halde semipermanent
zugewiesenen Speicher gelesen, so dass der Meta-Umsetzungsprozess
für jeden
Datenzugriff effizient auf die Tabellen zugreifen kann.
-
Metadaten-Tabellen
können
auch zur Bereitstellung von Abwärtskompatibilität dienen.
Manche Navigationssystementwickler bilden ihre Systeme möglicherweise
so aus, dass die Navigationsanwendungssoftware nach Verkauf des
Navigationssystems im Laufe der Zeit aufgerüstet oder aktualisiert werden
kann. Diese Möglichkeit
zum Aufrüsten
kann angeboten werden, um von neuen Merkmalen in der Geodatenbank
zu profitieren. Damit ein neueres Navigationsanwendungs-Softwareprogramm
eine ältere
Version einer geographischen Datenbank verwenden kann, kann in der
neuen Version der Navigationsanwendungssoftware eine Metadaten-Tabelle,
zum Beispiel Tabelle 813, vorgesehen sein. Wie auch die
auf dem Speicherträger
vorgesehene Metadaten-Tabelle wird die Information in der mit der
neueren Version der Navigationsanwendungssoftware bereitgestellten
Metadaten-Tabelle zum Vergleich der Versionsstufen der Navigationssoftware
und des physikalischen Speicherformats verwendet. Die Informationen
in diesen Metadaten-Tabellen werden dem physikalisch-logischen Untersystem 244 zum
Zeitpunkt der Initialisierung zur Durchführung notwendiger Attributkonvertierungen
zur Verfügung
gestellt. Sind, wie oben erwähnt,
die Versionsstufen des Navigationsanwendungsprogramms und des physikalischen
Speicherformats gleich, so ist der Schritt der Metadatenkonvertierung
unnötig
und das physikalisch-logische Untersystem kann diesen Konvertierungsschritt überspringen.
-
X. Weitere alternative
Ausführungsformen
-
Die
oben genannten Ausführungsformen
offenbaren ein Schnittstellenschicht-System, das in einem Navigationssystem
verwendet werden kann. In einer vorliegenden Ausführungsform
ist das Navigationssystem ein fahrzeuginternes Navigationssystem,
das im Fahrzeug eines Endanwenders eingebaut ist und sich dort befindet.
Die Art des Fahrzeugs kann Autos, Lastkraftwagen, Busse und so weiter
umfassen. Die Endanwender eines derartigen Systems können sowohl
Personen sein, die eigene Fahrzeuge besitzen oder leasen, als auch Fuhrparkbesitzer,
Betriebe, Autovermietungen, Straßentransportunternehmen, Speditionsfirmen
und so weiter. In alternativen Ausführungsformen kann das Navigationssystem
ein Navigationssystem sein, das nicht in ein Fahrzeug eingebaut
ist. Das Navigationssystem kann beispielsweise eine Handeinheit
sein, die eine Person mit sich trägt. Das Navigationssystem kann
auch an einem nicht mobilen Standort installiert sein, wie beispielsweise
in einer Großtankstelle,
einer Autovermietung, einem Personalcomputer und so weiter. Des
Weiteren kann das Navigationssystem zur Verwendung durch Verkehrsregelungsstellen,
Polizei, Zustelldienste und so weiter installiert sein.
-
In
einer bevorzugten Ausführungsform
ist die Schnittstellenschicht nach Kompilierung der Anwendungsprogramme
statisch mit den Navigationsanwendungsprogrammen verknüpft, um
ein ausführbares
Modul zu bilden. In einer alternativen Ausführungsform kann die Schnittstellenschicht
mit den Navigationsanwendungen dynamisch verknüpft sein.
-
Eine
alternative Ausführungsform
ist in der 8 gezeigt. In dieser alternativen
Ausführungsform
unterstützt
der Trägervorrichtungstreiber 609 des
Navigationssystems asynchrone E/A. Die Implementierung asynchroner
E/A bedingt, dass der die Anfrage aufrufende Prozess weiterlaufen
kann, wenn eine Platten-E/A an den Kernel gegeben wird, und bei
Beendigung der E/A-Anfrage benachrichtigt wird. In einer derartigen
Alternative veranlasst eine Version des E/A-Managers als gemeinsam
genutzter Code die E/A-Anfrage und gibt die Kontrolle an die Navigationsanwendung
zurück.
Bei Beendigung der E/A würde
ein asynchrones Ereignis in eine Klienten-Nachrichtenwarteschlange
zur Abarbeitung gestellt.
-
Bei
dieser Alternative kann der E/A-Manager 270 vollständig im
statisch verknüpften
Teil 271 des Ressourcenmanagement-Untersystems 220 existieren,
d.h. der E/A-Manager 270 wäre mit jedem der Navigationsanwendungsprogramme 200 verknüpft. In
dieser Alternative wird die E/A-Warteschlange als Kontrollstruktur 611 im
Speicherpool implementiert. In diesem Fall werden Interprozesskommunikationstechniken,
wie Semaphor-Schutz, verwendet, um Konkurrenz um die E/A-Warteschlange
von mehreren Prozessen zu verwalten. Die übrigen Merkmale der Schnittstellenschichtsysteme
wären den
oben beschriebenen ähnlich.
-
XI. Schlussbemerkung
-
Die
oben beschriebene Datenzugriffs-Schnittstellenschicht stellt eine
einheitliche in einem Navigationssystem integrierte Schnittstelle
bereit. Die Datenzugriffs-Schnittstellenschicht kann auf verschiedenen
von verschiedenen Herstellern entwickelten Navigationssystemplattformen
verwendet werden. Die Datenzugriffs-Schnittstellenschicht funktioniert
unabhängig
von der Hardware-Plattform
oder Endanwender-Funktionalität
des Navigationssystems. Die Datenzugriffs-Schnittstellenschicht
stellt einen gemeinsamen transparenten Mechanismus für den Zugriff
auf geographische Daten bereit, die auf einem physikalischen Träger gespeichert sind.
Die Datenzugriffs-Schnittstellenschicht isoliert die Navigationsanwendungsprogramme
von den Details der Geodatenorganisation und den physikalischen
Bedingungen der spezifischen Speicherträgerimplementierung.
-
Da
die Datenzugriffs-Schnittstellenschicht eine einheitliche, konsistente
Ansicht der Geodatenbank präsentiert,
können
Navigationssystementwickler ihre Navigationssysteme mit Hinsicht
auf neue und bessere Funktionalität weiterentwickeln und verbessern,
ohne sich mit der Abstimmung auf den physikalischen Träger und
das Speicherformat der Geodatenbank befassen zu müssen. Navigationssystementwickler
können
ihr Augenmerk daher auf die Bereitstellung neuer Navigationsanwendungsprogrammtypen
sowie neuer Hardware-Plattformen
und Betriebssysteme, die auf eine konsistente Geodatenschnittstelle
zugreifen können,
richten. Aus Sicht des Endanwenders wird durch die Datenzugriffs-Schnittstellenschicht
die Verwendbarkeit aktualisierter geographischer Daten im Navigationssystem
des Endanwenders sichergestellt und dadurch das Risiko vermindert,
dass das Navigationssystem veraltet, weil die Geodatenversion überholt
ist.