DE69732755T2

DE69732755T2 - Zwischenebene für Navigationssystem

Info

Publication number: DE69732755T2
Application number: DE69732755T
Authority: DE
Inventors: Richard A. Hebron Ashby; Vijay S. Hoffman Estates Israni; David S. Highland Park Lampert; Senthil K. Natesan; Grant S. Westmont Killey; John C. Arlington Heights Jasper; Jerry S. Chicago Feigen; Paul M. Chicago Bouzide; Robert P. Wooddale Fernekes
Original assignee: Navteq North America LLC
Current assignee: Here North America LLC
Priority date: 1996-10-25
Filing date: 1997-10-24
Publication date: 2006-04-06
Anticipated expiration: 2017-10-25
Also published as: EP0838771B1; DE69732755D1; US6047280A; EP0838771A2; EP0838771A3; US6370539B1; US6173277B1; CA2219037A1; JPH10253367A; CA2219037C

Description

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.

Claims

Rechnerprogrammerzeugnis zur Verwendung in einem Navigationssystem (10), wobei das Navigationssystem (10) ein Navigationsanwendungsprogramm (200) zur Bereitstellung von Navigationsmerkmalen für einen Anwender des Navigationssystems (10) sowie eine auf einem physikalischen Speicherträger (22) in einem rechnerlesbaren physikalischen Speicherformat gespeicherte geographische Datenbank (40) umfasst, wobei das Rechnerprogrammerzeugnis dadurch gekennzeichnet ist, dass es eine zwischen dem Navigationsanwendungsprogramm (200) und der geographischen Datenbank (40) logisch angeordnete Schnittstellenschicht (41) umfasst, die Folgendes umfasst: Mittel (210) zum Annehmen und Verarbeiten von Anfragen des Navigationsanwendungsprogramms (200) nach geographischen Daten sowie Mittel (216) zum Umsetzen geographischer Daten aus dem physikalischen Speicherformat und Bereitstellen der geographischen Daten für das Navigationsanwendungsprogramm (200) in einem logischen Datenmodellformat.
Rechnerprogrammerzeugnis nach Anspruch 1, worin das Mittel (210) zur Anfragenannahme und -verarbeitung ferner Folgendes umfasst: Mittel (249) zum Bereitstellen eines Cursors für das Navigationsanwendungsprogramm (200) in Antwort auf eine Anfrage des Navigationsanwendungsprogramms (200) nach geographischen Daten, wobei der Cursor Mehrfacheintragungen umfasst und das Cursorbereitstellungsmittel (249) auf das Umsetzungsmittel (216) anspricht und dazu ausgefegt ist, die geographischen Daten von ihm zu empfangen.
Rechnerprogrammerzeugnis nach Anspruch 2, worin das Cursorbereitstellungsmittel (249) ferner Folgendes umfasst: Mittel zum Bereitstellen eines ersten Teils (511) des Cursors im logischen Datenmodellformat sowie Mittel (513) zum Bereitstellen einer Entitätskennung für einen ersten Rest des Cursors, worin der erste Rest in einem komprimierten Format beibehalten wird.
Rechnerprogrammerzeugnis nach Anspruch 3, worin das Cursorbereitstellungsmittel (249) ferner Folgendes umfasst: ein Fetch-Next-Funktions-Mittel, das dazu ausgelegt ist, einen zweiten Teil des Cursors im logischen Datenmodellformat bereitzustellen, wobei der zweite Teil aus dem ersten Rest besteht.
Rechnerprogrammerzeugnis nach Anspruch 1, worin die Schnittstellenschicht ferner Folgendes umfasst: Mittel (242) zur Indexverwaltung, das auf das Mittel (210) zur Annahme und Verarbeitung von Anfragen und Index-Informationen anspricht, wobei das Indexverwaltungsmittel (242) eine Kennung zum Erhalt von geographischen Daten auf dem physikalischen Speicherträger (22) zur Beantwortung der Anfragen des Nagivationsanwendungsprogramms (200) bereitstellt.
Rechnerprogrammerzeugnis nach Anspruch 5, worin sich mindestens ein Teil der Indexinformationen auf dem physikalischen Speicherträger (22) befindet und worin das Indexverwaltungsmittel (242) Paketkennungen zum Erhalt von Zeigern auf Pakete auf dem physikalischen Speicherträger (22) bereitstellt, die geographische Daten zur Beantwortung der Anfragen des Navigationsanwendungsprogramms (200) enthalten.
Rechnerprogrammerzeugnis nach Anspruch 5, worin das Indexverwaltungsmittel (242) ferner Folgendes umfasst: eine Schnittstelle (250) zum Umsetzen einer spezifischen, vom Navigationsanwendungsprogramm (200) an eine Paketkennung für ein Paket auf dem physikalischen Speicherträger (22) weitergegebene Entitätskennung.
Rechnerprogrammerzeugnis nach Anspruch 5, worin das Indexverwaltungsmittel (242) ferner Folgendes umfasst: eine Schnittstelle (248) zur Entnahme eines Index-Spezifikationselements und von Abfrageparametern aus dem Anfrageannahme- und -verarbeitungsmittel (210) sowie zur Rückgabe eines Paketkennungssatzes.
Rechnerprogrammerzeugnis nach Anspruch 5, das ferner Folgendes umfasst: Mittel (220) zum Einlesen von Indexinformationen vom physikalischen Speicherträger (22) in einen Puffer, wobei das Indexverwaltungsmittel (242) mit dem Puffer gekoppelt ist, um von ihm die Indexinformationen zu erhalten.
Rechnerprogrammerzeugnis nach Anspruch 1, worin das Umsetzungsmittel (216) ferner Folgendes umfasst: Mittel (255) zum Entpacken von geographischen Daten in Paketform aus dem physikalischen Speicherformat in ein dekomprimiertes Zwischenformat sowie Mittel (257) zum Umsetzen der geographischen Daten aus dem dekomprimierten Zwischenformat in Datenentitäten im logischen Datenformat zur Rückgabe an das Navigationsanwendungsprogramm (200).
Rechnerprogrammerzeugnis nach Anspruch 1, worin das Umsetzungsmittel (216) ferner Folgendes umfasst: eine erste Schnittstelle (260) zum Umsetzen geographischer Datenbankentitäten aus dem physikalischen Speicherformat in ein dekomprimiertes Zwischenformat sowie eine zweite Schnittstelle (263) zum Umsetzen geographischer Datenbankentitäten aus dem dekomprimierten Zwischenformat in das logische Datenmodellformat, in welchem die geographischen Daten für das Mittel zur Anfragenannahme und -ausführung (210) bereitgestellt werden.
Rechnerprogrammerzeugnis nach Anspruch 11, worin das Umsetzungsmittel (216) ferner Folgendes umfasst: ein Meta-Umsetzungsmittel (261), das auf eine Metadatentabelle (259) auf dem physikalischen Speicherträger (22) und die erste Schnittstelle (260) anspricht und dazu ausgelegt ist, die geographischen Daten (40) im dekomprimierten Zwischenformat einer ersten Versionsstufe in ein dekomprimiertes Zwischenformat einer zweiten Versionsstufe umzusetzen und die geographischen Daten im dekomprimierten Zwischenformat einer zweiten Versionsstufe für die zweite Schnittstelle (263) bereitzustellen.
Rechnerprogrammerzeugnis nach Anspruch 1, worin die Schnittstellenschicht (41) ferner Folgendes umfasst: Mittel (220) zur Ressourcenverwaltung, das Folgendes umfasst: Mittel zur Zuweisung und Freigabe von Speicher (276) des Navigationssystems (10) zur Verwendung als Speicherpool (278) durch die Schnittstellenschicht (41) sowie Mittel zum Zugreifen auf einen Cachespeicherpuffer im Speicherpool (278), der ein aus dem physikalischen Speicherträger (22) gelesenes Paket speichert, wobei das Paket durch eine von einem Indexverwaltungsmittel (242) bereitgestellte Paketkennung identifiziert wird.
Rechnerprogrammerzeugnis nach Anspruch 13, worin das Ressourcenverwaltungsmittel (220) ferner Folgendes umfasst: Mittel (270) zum Starten einer E/A-Transaktion aus dem physikalischen Speicherträger (22), um daraus das Paket zu lesen, wenn das Cachespeicherpuffer-Zugriffsmittel feststellt, dass das Paket nicht im Cachespeicherpuffer gespeichert ist.
Rechnerprogrammerzeugnis nach Anspruch 14, worin das E/A-Startmittel (270) ferner Folgendes umfasst: Mittel zum Speichern von Paketkennungen in einer Warteschlange sowie Mittel zum Umordnen von Paketkennungen, die sich in der Warteschlange befinden.
Rechnerprogrammerzeugnis nach Anspruch 15, worin das E/A-Startmittel (270) ferner Folgendes umfasst: Mittel zum Umsetzen der Paketkennungen in eine physikalische Trägeradresse, während sie in der Warteschlange sind.
Rechnerprogrammerzeugnis nach Anspruch 15, worin das Navigationssystem (10) ferner einen Trägervorrichtungstreiber (300) umfasst und worin das Mittel zum Umordnen der Paketkennungen ferner Folgendes umfasst: Mittel, das auf den Trägervorrichtungstreiber (300) anspricht, um eine physikalische Lesekopfposition zu erhalten, und dazu ausgelegt ist, die physikalische Lesekopfposition an das Umordnungsmittel auszugeben.
Rechnerprogrammerzeugnis nach Anspruch 13, worin das Ressourcenverwaltungsmittel (220) ferner Folgendes umfasst: Mittel zum Sperren eines Cachespeichers, wenn darin ein Paket gespeichert ist und eine Pufferadresse an das Mittel (210) zur Anfragenannahme und -verarbeitung zurückgegeben wird.
Rechnerprogrammerzeugnis nach Anspruch 13, worin das Ressourcenverwaltungsmittel (220) ferner Folgendes umfasst: Mittel (275) zum Ändern der Größe des Speicherpools (278) in Antwort auf einen Aufruf durch das Navigationsanwendungsprogramm (200).
Navigationssystem (10), das Folgendes umfasst: ein Navigationsanwendungsprogramm (200) zum Bereitstellen von Navigationsmerkmalen für einen Anwender des Navigationssystems (10), eine auf einem physikalischen Speicherträger (22) in einem rechnerlesbaren physikalischen Speicherformat gespeicherte geographische Datenbank (40) sowie das Rechnerprogrammerzeugnis nach einem der Ansprüche 1 bis 19.
Rechnerverwendbarer Träger mit einem physikalisch darin integrierten rechnerlesbaren Programmcode, um ein Navigationsanwendungsprogramm (200) dazu zu veranlassen, eine rechnerlesbare auf einem physikalischen Speicherträger (22) in einem physikalischen Speicherformat gespeicherte geographische Datenbank (40) zu verwenden, wobei der rechnerlesbare Programmcode in einem Fabrikerzeugnis dadurch gekennzeichnet ist, dass er Folgendes umfasst: rechnerlesbares Programmcodemittel (210), um einen Rechner dazu zu veranlassen, eine Abfragelogik auszuführen, um Anfragen des Navigationsanwendungsprogramms (200) nach geographischen Daten anzunehmen, sowie rechnerlesbares Programmcodemittel (244), um einen Rechner dazu zu veranlassen, die geographischen Daten aus dem physikalischen Speicherformat umzusetzen und dem Navigationsanwendungsprogramm (200) die geographischen Daten in einem generischen ASCII-Format bereitzustellen.
Erfindung nach Anspruch 21, worin das physikalische Speicherformat der zu verwendenden geographischen Datenbank die geographischen Daten in eine Mehrzahl von Paketen organisiert, und worin die Erfindung ferner Folgendes umfasst: rechnerlesbares Programmcodemittel (242), um den Rechner dazu zu veranlassen, die Anfragen mit Paketen im physikalischen Speicherformat zu verknüpfen, sowie rechnerlesbarer Programmcode (270), um den Rechner dazu zu veranlassen, die Pakete aus dem physikalischen Speicherträger (22) zu lesen.
Erfindung nach Anspruch 21, worin der physikalische Speicherträger (22) eine CD-ROM umfasst.
Schnittstellenschicht (41) zur Verwendung in einem Navigationssystem (20), worin das Navigationssystem (10) einen Navigationsanwendungs-Programmteil (200) umfasst, worin das Navigationssystem (10) geographische Daten manipuliert, die in einer in einem physikalischen Speicherformat auf einem physikalischen Speicherträger (22) gespeicherten geographischen Datenbank (40) bereitgestellt sind, worin die Schnittstellenschicht (41) logisch zwischen dem Navigationsanwendungsprogramm (200) und der geographischen Datenbank (40) angeordnet und dadurch gekennzeichnet ist, dass sie Folgendes umfasst: ein Abfragelogikprogrammmittel (210) zum Empfang von Anfragen des Navigationsanwendungs-Programmteils (200) nach geographischen Daten sowie ein Datenumsetzungsprogrammmittel (244) zum Umsetzen geographischer Daten aus dem physikalischen Speicherformat und zum Bereitstellen der umgesetzten geographischen Daten für den Navigationsanwendungs-Programmteil (200) in Antwort auf die Anfragen.
Schnittstellenschicht (41) nach Anspruch 24, die ferner Folgendes umfasst: Indexverwaltungsprogrammmittel (242), das auf das Abfragelogikprogrammmittel (210) anspricht und dazu ausgelegt ist, die Anfragen des Navigationsanwendungs-Programmteils (200) mit Paketkennungen zu verknüpfen, die mit geographischen Daten (40) enthaltenden Paketen im physikalischen Speicherformat verknüpft sind, und die Paketkennungen einem Speicherverwaltungsbibliotheks-Programmmittel (220) bereitzustellen, um die dem Datenumwandlungsprogrammmittel (244) zur dortigen Umwandlung bereitzustellenden Pakete zu erhalten.
Schnittstellenschicht (41) nach Anspruch 25, worin das Indexverwaltungsprogrammmittel (242) ferner Mittel (248) umfasst, um die Paketkennungen aus dem Speicherträger zu erhalten, und worin das Indexverwaltungsprogrammmittel (242) ferner Mittel umfasst, um Zeiger auf Pakete auf dem physikalischen Speicherträger (22) zu erhalten, die geographische Daten zur Beantwortung der Anfragen des Navigationsanwendungs-Programmteils (200) enthalten.
Schnitstellenschicht (41) nach Anspruch 25, worin das Indexverwaltungsprogrammmittel (242) ferner Folgendes umfasst: Programmmittel (250) zum Umsetzen spezifischer, vom Navigationsanwendungs-Programmteil (200) an Paketkennungen für Pakete auf dem physikalischen Speicherträger (22) weitergegebene Entitätskennungen.
Schnittstellenschicht (41) nach Anspruch 25, worin das Indexverwaltungsprogrammmittel (242) ferner Folgendes umfasst: Programmmittel (248) zur Entnahme von Indexspezifikationselementen und Abfrageparametern aus dem Abfragelogikprogrammmittel (210) sowie zur Rückgabe eines Paketkennungssatzes.
Verfahren zum Verwenden eines rechnergestützten Navigationssystems (10), worin das Navigationssystem (10) Navigationsanwendungs-Programmfunktionen (200) umfasst, worin die Navigationsanwendungs-Programmfunktionen (200) dazu ausgelegt sind, eine auf einem rechnerlesbaren Träger (22) in einem physikalischen Speicherformat gespeicherte geographische Datenbank (40) zu verwenden, mit einer zwischen den Navigationsanwendungs-Programmfunktionen (200) und der geographischen Datenbank (40) logisch angeordneten Schnittstellenschicht, wobei das Verfahren dadurch gekennzeichnet ist, dass es Folgendes umfasst: Annehmen einer Anfrage nach geographischen Daten von einer der Navigationsanwendungs-Programmfunktionen (200), Verwenden eines Index zur Identifizierung eines Pakets im physikalischen Speicherformat, das die geographischen Daten zur Beantwortung der Anfrage enthält, Umsetzen von in dem Paket im physikalischen Speicherformat gespeicherten geographischen Daten in ein von den Navigationsanwendungs-Programmfunktionen (200) verwendbares Format sowie Bereitstellen der umgewandelten geographischen Daten für die eine der Navigationsanwendungs-Programmfunktionen (200).
Verfahren nach Anspruch 29, worin der Bereitstellungsschritt ferner Folgendes umfasst: Umsetzen der geographischen Daten aus dem physikalischen Speicherformat in ein dekomprimiertes Zwischenformat sowie Umsetzen der geographischen Daten aus dem dekomprimierten Zwischenformat in das von den Navigationsanwendungs-Programmfunktionen (200) verwendbare Format.
Verfahren nach Anspruch 29, das ferner den folgenden Schritt umfasst: vor Annahme der Anfrage der Navigationsanwendungs-Programmfunktionen (200) Lesen einer Metadatendatei (259) aus dem rechnerlesbaren Träger (22), Speichern eines Teils der Metadatendatei (259) im Speicher sowie Verwenden der Metadatendatei (259) zum Umsetzen aus einer Versionsstufe des physikalischen Speicherformats in eine Versionsstufe der Navigationsanwendungs-Programmfunktionen (200).
Verfahren nach Anspruch 29, das ferner Folgendes umfasst: nachdem eine Mehrzahl von Datenentitäten in Antwort auf die Anfrage der einen der Navigationsanwendungs-Programmfunktionen (200) identifiziert sind, Bereitstellen eines ersten Teilergebnissatzes (511) der Mehrzahl von Datenentitäten in dem von den Navigationsanwendungs-Programmfunktionen (200) verwendbaren Format für die eine der Navigationsanwendungs-Programmfunktionen (200).
Verfahren nach Anspruch 32, das ferner den folgenden Schritt umfasst: wenn die Mehrzahl von Datenentitäten eine erste Schwelle überschreitet, Bereitstellen eines ersten Teilergebnissatzes (511) der Mehrzahl von Datenentitäten bis zur ersten Schwelle in dem von den Navigationsanwendungs-Programmfunktionen (200) verwendbaren Format für die eine der Navigationsanwendungs-Programmfunktionen (200) sowie Beibehalten von Entitätskennungen für einen Teil der die erste Schwelle überschreitenden Mehrzahl von Datenentitäten.
Verfahren nach Anspruch 32, das ferner den folgenden Schritt umfasst: wenn die Mehrzahl von Datenentitäten eine erste Schwelle und eine zweite Schwelle, die größer ist als die erste Schwelle, überschreitet, Bereitstellen eines ersten Teilergebnissatzes (511) der Mehrzahl von Datenentitäten bis zur ersten Schwelle in dem von den Navigationsanwendungs-Programmfunktionen (200) verwendbaren Format für die eine der Navigationsanwendungs-Programmfunktionen (200), Beibehalten von Entitätskennungen für einen Teil der die erste Schwelle überschreitenden Mehrzahl von Datenentitäten sowie Beibehalten eines Bezugscursors, um die Anfrage nach geographischen Daten für die zweite Schwelle überschreitende Datenentitäten erneut auszuführen.