DE69636291T2

DE69636291T2 - Telematik Endgerät für Strassenverkehrsanwendungen

Info

Publication number: DE69636291T2
Application number: DE69636291T
Authority: DE
Inventors: Dr. Ing. Werner Kremer; Georg Fuchs; Bernd Günther; Uwe Köhler; Thorsten Gill; Rudolph Braun; Heiz-Joseph Fahle; Dr. Gerd Pfeiffer; Arjen Klein; Gerd Grendel; Dieter Klose; DR.-Ing. Harald Bochmann
Original assignee: T Mobile Deutschland GmbH
Current assignee: Telekom Deutschland GmbH
Priority date: 1996-03-14
Filing date: 1996-03-14
Publication date: 2007-06-14
Anticipated expiration: 2016-03-15
Also published as: EP0953261A1; EP0953261B1; DE69636291D1; ES2270436T3; WO1997034431A1

Description

Die Telematik wird für die mobile Kommunikation zu einem Wachstumsmarkt werden; die Vorhersagen für das nächste Jahrzehnt sprechen von über zehn Millionen Kunden. Die Hersteller werden in der Lage sein, Endgeräte zu einem angemessenen Preis anzubieten, vorausgesetzt, dass es ökonomische Mittel zur Entwicklung und Fertigung gibt. Der weltweite Erfolg der mobilen Kommunikation, so wie der GSM-Standard, hat bewiesen, dass es möglich ist, den Markt schnell zu durchdringen und eine große Anzahl an Teilnehmern durch die Koordinierung von Spezifikationskommissionen zu erreichen. Mit diesem gemeinsamen Dokument, das mit Endgerätespezifikationen zu tun hat, ist es möglich geworden, den zweckdienlichen Rahmen für die technischen Vorbereitungen für den Verkehr des Telematik Marktes, einschließlich aller Partner (Kunden, Service-Anbieter und Ausrüstungshersteller) zu schaffen.
Ein wesentliches Merkmal der Spezifikation ist die offene Bauweise des Systems, da nur ein Massenmarkt für eine Vielfalt an Verkehrstelematikdienstleistungen sowohl auf dem kommerziellen als auch auf dem privaten Sektor entwickelt werden kann, wenn offene und standardisierte Schnittstellen-Spezifikationen geschaffen werden.
Die Mobilität der am Verkehr Beteiligten wird als wirtschaftlicher Faktor immer wichtiger. Intelligente und flexible Verkehrsleitsysteme sind daher notwendig, um einen reibungslosen Verkehrsfluss aufrecht zu erhalten, während sich der Umfang des Verkehrs ständig erhöht. Das Ziel ist, zum frühestmöglichen Punkt ein Verkehrstelematiksystem einzuführen, das sowohl flexibel als auch offen ist, um zukünftige Entwicklungen zu berücksichtigen. Dieses System sollte offene, standardisierte Schnittstellen besitzen, wodurch es die Verwirklichung einer Anzahl von Verkehrsmanagementoperationen sowohl im kommerziellen als auch im privaten Sektor ermöglicht. Es kann dann kollektive Leit- und Informations-, sowie persönliche Dienstleistungen unterstützen.
Das Konzept basiert auf mobiler Kommunikation, z. B. die digitalen, zellularen, mobilen Kommunikations-Standard-GSM- und Navigationssysteme, z. B. das Satellitennavigationssystem GPS, wobei letzteres der dominante Vertreter des Global Navigation Satellit System (GNSS) ist. Die Anwendung des Konzepts ist offensichtlich nicht nur auf jene besonderen Kommunikations- und Navigationssysteme beschränkt, da jede andere Art von elektromagnetischer Kommunikation wie selbst Mikrowelle oder Infrarot verwendet werden kann. Ebenso wird sich irgendeine Art von Navigation in das Konzept offener Standards, wie beispielsweise autonome, im Auto befindliche Navigation durch die Verwendung von Sensoren oder irgendeine andere Art von externen und/oder kombinierten internen/externen Navigationssystemen wie das Feststellen der Position durch die Verwendung von elektromagnetischen Übertragungsmitteln einfügen. Im nachfolgenden Text wird auf GSM und GPS als nur ein Beispiel jener verschiedenen Typen der Kommunikation Bezug genommen werden, insbesondere Mobilfunk und Navigationsmittel, insbesondere Satellitennavigation, die in diesem Konzept möglich sind.
GSM wird bereits als ein universaler Standard für Sprach- und Datendienstleistungen in Europa und darüber hinaus verwendet. GPS ist ein standardisiertes Verfahren, das weltweit verfügbar ist. Die hohe Deckung der GSM-Netzwerke bedeutet, dass die hauptsächlichen Investitionen in die Infrastruktur bereits getätigt worden sind, wodurch die schnelle Einführung von auf GSM basierender Verkehrstelematik garantiert ist. Es muss unterstrichen werden, dass die Verkehrstelematik-Fahrzeugendgeräte insbesondere grenzüberschreitend verwendet werden können. Das multi-funktionale Design dieser Endgeräte bildet die Grundlage für eine breite Vielfalt an Angeboten und zusätzlichen Dienstleistungen für zu erwartende Kunden.
Das Schriftstück „Pacific Rim TransTech Conference", 1995, Vehicle Navigation and Information Systems Conference Proceedings, 6. Internationale VNIS, 30.
Juli 1995 – 2. August 1995, ISBN 0-7803-2587-7, 1995, New York, N.Y., U.S.A., Seite 442–449; Hong Lo et al: „Ein struktureller Lösungsweg für ITS-Architekturvorlage und Bewertung" legt ein Verkehrstelematiksystem offen, das ein Basissystem mit zahlreichen austauschbaren und untereinander tauschbaren Zwischensystemen, insbesondere ein Zwischensystem für Kommunikation, ein Zwischensystem für die Ortsbestimmung und ein Zwischensystem für Input/Output umfasst, das Basisfunktionen bereitstellt.
Das Schriftstück „Proceedings of the Vehicular Technology Conference", Stockholm, 8.–10. Juni 1994, Band 1, 8. Juni 1994, Institute of Electrical and Electronics Engineers, Seite 405–409, Wichtel E. et al: „AVL-Zwischensystem-Schnittstellen" zielt auf ein Verkehrstelematiksystem ab und legt eine Standard-Schnittstelle gegenüber der Anwendung sowie ein Zentralgerät offen, das Wegsuche- und Systemsteuerungsfunktionen durchführt.
Das Papier PHILIPS JOURNAL OF RESEARCH, Band 48, Nr. 4, Januar 1994, Seite 299–313, XP495036, BIESTERBOS JWM et al: „SOCRATES: EIN DYNAMISCHES AUTONAVIGATIONS-, FAHRERINFORMATIONS- UND FLOTTEN-MANAGEMENTSYSTEM" legt ein Endgerät für ein Verkehrstelematiksystem offen.
Es ist daher ein Gegenstand der vorliegenden Erfindung, ein Verkehrstelematikendgerät mit einer leicht variablen Konzeption bereitzustellen. Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verkehrstelematikendgerät bereitgestellt, so wie in Anspruch 1 vorgeschlagen. Gemäß einem anderen Aspekt wird ein Verfahren zum Betreiben eines Verkehrstelematikendgerätes bereitgestellt, so wie in Anspruch 7 vorgeschlagen. Das Verkehrstelematiksystem besteht aus einem oder mehreren Zwischensystemen. Jedes der Zwischensysteme kann konstruiert werden, um innerhalb des gesamten Systems besondere Aufgaben wie Kommunikation, Ortsbestimmung, Zugangssteuerung, Input/Output zu erfüllen. Eine Möglichkeit der Anordnung der Zwischensysteme ist, ein Basissystem aufzubauen, dem ein Zwischensystem oder mehrere Zwischensysteme zugeordnet ist/sind. Das gesamte System kann in der Weise betrieben werden, dass Basisfunktionen dem Basissystem zugeordnet sind, und jene Funktionen werden verwendet, um Unterfunktionen des einen Zwischensystems oder mehrerer Zwischensysteme zu betreiben. Es wird vorgeschlagen, standardisierte Schnittstellen für das Telematiksystem zu konstruieren, um die Kommunikation und/oder Verbindung zu vereinfachen. Ein besonderes Beispiel einer Konzeption eines solchen Grundsystems, solcher Zwischensysteme und Schnittstellen wird weiter unten im Detail ausgewiesen.
Gegenstand der Spezifikation
So wie in 1 gezeigt, konzentriert sich diese Spezifikation insbesondere auf die funktionelle Beschreibung der Endgerätplattform als Verbindungsglied zwischen der Endgerätfertigung und den Anwendungen. Mit diesem Konzept wird es möglich sein, Anwendungen an verschiedene Endgeräte zu transferieren, was die Grundlage für die Verfügbarkeit von Endgeräten auf einem Massenmarkt ist. Darüber hinaus können bestehende Dienstleistungen von verschiedenen Herstellern in Endgeräte implementiert werden, wodurch die individuelle Konstruktion des Produkts möglich wird.
Das Verkehrstelematikendgerät ist ein vollständiges System, das in das Fahrzeug integriert werden kann. Das Verkehrstelematikbasisendgerät, das in diesem Dokument spezifiziert ist, ist das Endgerät ohne die Teile, die zu den Anwendungen gehören. Die Endgeräteplattform beinhaltet Zwischensysteme, die für viele Verkehrstelematikanwendungen sowie für das Cross-Section Routing + das System Steuerungs- und Prioritätsmanagement erforderlich sind. Mit Bezug auf die Architektur des Basis-Endgeräts, das in Kapitel 1.2 eingeführt wird, legt diese Spezifikation die Basisfunktionen für die Steuerung und die Verwendung der Zwischensysteme wie Kommunikation, Standort, Chip-Kartenleser und Input/Output fest.
Die Basisfunktionen ermöglichen den definierten Zugang zu den Zwischensystemen, während mehrere Anwendungen gleichzeitig laufen, ohne dass die eine die andere blockiert. Zusätzliche externe Anwendungen können diese Zwischensysteme ebenfalls über eine standardisierte Schnittstelle, die Standard-Kommunikations-Schnittstelle (SCI), verwenden und eine Verdoppelung des GSM- oder des GPS-Moduls verhindern.
Das Ziel ist, einen Standard für Anwendungsfolgen durch Ansprechen und Verwendung der Basisfunktionen festzulegen. Mögliche Anwendungen für die Verkehrstelematik sind in (4), (5), (6) und (9) beschrieben.
Darüber hinaus muss die Spezifikation der Basisfunktionen die Hardware des multi-funktionellen Basis-Endgeräts nicht definieren. Weder das CPU- noch das Betriebssystem noch die Bus-Struktur sind festgelegt, weshalb die Basisfunktionen in eine Vielfalt an integrierten oder modularen Endgeräteverwirklichungen inkorporiert werden. Infolgedessen ist es für Firmen nicht erforderlich, Anwendungen und Dienstleistungen zu entwickeln, um sich ein gründliches technisches Wissen über Basistechnologien und der Konstruktion von Hardware zu beschaffen.
Die wirksame Übertragung von Anwendungen zu verschiedenen Verwirklichungen von Endgeräten ist lediglich auf der Grundlage einer Standardisierung der Basisfunktionen möglich.
Funktionelle Architektur
Ein wichtiger Teil dieser Spezifikation ist der Aufbau der Schnittstellen zwischen Anwendungen und Basisfunktionen, das in bevorzugter Weise als Extra-Schnittstelle, die Anwendungsprogrammier-Schnittstelle (API) (siehe 2), gewählt wurde. Es kann nichtsdestoweniger in einigen Fällen nützlich sein, innerhalb des Systems nur eine gemeinsame Schnittstelle zu definieren. In bevorzugter Weise beinhalten die Basisfunktionen das Zwischensystemkommunikations-, das Ortsbestimmungs-, das Zugangssteuerungs-, das Input-/Output- sowie die Standard-Kommunikations-Schnittstelle (SCI). Die Verbindung zwischen den Anwendungen und den Zwischensystemen wird durch die Cross Section Function Routing- und die Systemsteuerung festgelegt. Während die Wegsuche (routing) auf das Ansprechen/die Adressierung von Aufgaben begrenzt ist, übernimmt die Systemsteuerung die Überwachung von Funktionen und die Aufzeichnung von Ausfällen und Fehlern.
Mit Hilfe des KommunikationsZwischensystems können Verbindungen zum GSM-Netzwerk durch das Hinzufügen eines GSM-Moduls festgelegt werden. Es muss erneut unterstrichen werden, dass GSM sowie GPS lediglich Beispiele für das bereits oben erwähnte Kommunikations- und Navigationsmittel sind, die in diesem Konzept verwendet werden können. Daten können mit Zentraldienstleistungsgeräten, die im Landleitungsnetzwerk örtlich festgelegt wurden, ausgetauscht werden. Grundsätzlich können andere Netzwerke mit dem KommunikationsZwischensystem ebenfalls verbunden werden, vorausgesetzt, dass die Funktionsbefehle angepasst werden. Der GPS-Empfänger liefert Daten vom satellitengestützten Navigationssystem GPS, was die Bestimmung der Position des Fahrzeugs ermöglicht. Im Gegensatz zum GSM-Kartenleser, der gegenwärtig verwendet wird, kann ein zusätzliches Chipkartengerät implementiert werden, um die zusätzliche Funktion der Verarbeitung einer Verkehrstelematik-Chipkarte (siehe (8)) durchzuführen, wobei dies eine Kombination einer GSM- und einer Verkehrstelematik-Chipkarte sein kann. Die hauptsächliche Funktion der Chipkarte besteht dann darin, die Verkehrstelematikanwendungen (6) zu unterstützen. Das Input-/Outputgerät beliefert den Nutzer mit Informationen. Darüber hinaus kann er oder sie Informationen eingeben, um das Basis-Endgerät zu steuern. Das SCI ermöglicht den externen Peripheriegerätezugang zu so vielen Funktionen des Basisgeräts wie möglich.
Gewisse Zwischensysteme können konstruiert werden, um ein Prioritätsmanagement zu inkorporieren, wobei Anfragen des Nutzers mit höchster Priorität sofort bearbeitet werden können; dies bedeutet, dass es möglich ist, andere Funktionen wie die Verwendung des Displays oder einer GSM-Verbindung zu unterbrechen.
Die Feststellung der Position des Fahrzeugs kann mit Sensoren (z. B. Dead Reckoning (ungefähre Berechnung)) unterstützt werden. Eine noch genauere Feststellung kann durch die Verwendung von unterschiedlichen Informationen im RTCM-Format erreicht werden.
Für den Betrieb des GSM-Moduls kann das systemeigene Input-/Output-Gerät direkt verbunden werden. Unter der Voraussetzung, dass es mit ETSI GSM 07.07 in Einklang steht, kann dieses Gerät ebenfalls als Input-/Output-Gerät für Verkehrstelematikanwendungen verwendet werden.
Die API ist über die Standard-Kommunikation-Schnittstelle (SCI) (siehe 3) mit externen Geräten verbunden. Über die SCI können zusätzliche externe Verkehrstelematikanwendungen die Zwischensysteme ebenfalls nutzen. Darüber hinaus werden Fax- und Daten-Services unter Verwendung dieser Schnittstelle grundsätzlich betrieben werden. Im Fahrzeug befindliche Bus-Systeme können über eine Adaption (Fahrzeug-Bus-Adaption) verbunden werden.
Zusätzlich zu den GSM-Datendienstleistungen ist ein Sprach-Service ein optionaler Teil des Grundgeräts.
Diese Spezifikation enthält keine Einschränkungen hinsichtlich der Architektur der Hardware des Geräts, und deshalb können die Basisfunktionen sowohl in ein integriertes Verkehrstelematikgrundgerät als auch in ein Gerät implementiert werden, das sich aus verschiedenen Komponenten zusammensetzt. Die Spezifikation definiert die Schnittstelle zwischen dem Querschnitt von Komponenten, die für Verkehrstelematik- und deren funktionale Anforderungen einerseits und jenen Verkehrstelematikanwendungen benötigt werden, die andererseits auf definierten funktionalen Folgen ihrer Basiskomponenten basieren.
Die folgende Beschreibung gibt ein detailliertes Beispiel der vorliegenden, beanspruchten Erfindung.
2. Umfang der Grundfunktionen
2.1 Zusammenfassung der Basisfunktionen und der externen Schnittstellen
Die gemeinsamen Funktionen des multi-funktionalen Basisgeräts werden als Basisfunktionen geliefert. Sie haben eine Schnittstelle zu den Service-Anwendungen (API) und verwenden verschiedene Hardware-Komponenten wie GSM, GPS, Chipkartenleser, Input-/Output-Geräte usw. Die Basisfunktionen können unter den folgenden Überschriften zusammengefasst werden:
GSM-Kommunikation:
Die Basisfunktion für die GSM-Kommunikation plus GSM-Modul bilden den Zugang zum GSM-Netzwerk.
GPS-Standort:
Die Basisfunktion für die GPS-Ortsbestimmung plus GSM-Modul, dass das Rechenverfahren für die Bestimmung und Identifizierung der Position beinhaltet, bilden das Zwischensystem Ortsbestimmung. Andere GNSS-Positioniersysteme können neben der GPS-Positionsbestimmung in dieses StandortZwischensystem implementiert werden. In erster Linie wird jedoch lediglich das GPS-Modul berücksichtigt. Es ist wichtig, das Zwischensystem Ortsbestimmung dergestalt zu konstruieren, dass die Service-Anwendungen nicht beeinträchtigt werden, wenn weitere Ortsbestimmungsverfahren künftig hinzugefügt werden. Die GPS-Ortsbestimmung kann durch andere Verfahren wie GSM-Triggerung über die Underlay Broadcast Cell ergänzt werden. Das Zwischensystem Ortsbestimmung bleibt unverändert, wenn die Satellitennavigation durch externe Sensoren und unterschiedliche Informationen unterstützt wird. Unterschiedliche Informationen können entweder direkt in das Zwischensystem Ortsbestimmung eingegeben oder sie können über die API (bei externen Quellen über die SCI) abgefragt und dann an das Zwischensystem Ortsbestimmung weitergegeben werden.
Zugangssteuerung:
Das Zwischensystem "Zugangssteuerung" beinhaltet die Basisfunktionen für die Handhabung der Chipkarte.
Input/Output:
Dies beinhaltet Input-/Output-Funktionen für Display- und Betriebselemente.
Darüber hinaus werden allgemeine Funktionen bereitgestellt.
Wegsuche- + Systemsteuerung
Die Wegsuche organisiert den Informationsfluss von den Anwendungen zu den Grundfunktionen, von den Basisfunktionen zu den Anwendungen, zwischen den Anwendungen und zwischen den Basisfunktionen. Die Systemsteuerung führt Aufgaben wie Initialisierung (Konfiguration), Statussteuerung (Fehlerstatus), Diagnose, Versionsverwaltung und Überwachung von individuellen Verfahren (Überwachungseinheit (watch-dog)) durch.
Prioritätsmanagement
Das Prioritätsmanagement reguliert den Zugang zu den Basisfunktionen.
2.2 Funktionelle Beschreibung
2.2.1 Basisfunktionen des KommunikationsZwischensystems
Viele Verkehrstelematikanwendungen haben die Notwendigkeit für die mobile Kommunikation gemeinsam. Das Global System for Mobile Communication (GSM) stellt die Grundlage für die Zwischensystemkommunikation, die europaweit zu verwenden ist, bereit. Die Zwischensystemkommunikation ist derart konstruiert worden, dass alternative Netzwerke hinzugefügt werden können, wobei das System für besondere mobile Kommunikationsnetzwerke, wie Inmarsat offen gelassen wird. Die funktionale Architektur ist so lange transferierbar, wie die Funktionsbefehle entsprechend modifiziert worden sind.
Die Zwischensystemkommunikation bietet den Zugang zu Daten-Services an (sie unterstützen beim Austausch von Informationen mit dem Zentralservicegerät) und hat mit der Handhabung der Verbindung zu tun. Die Basisfunktionen sind grundsätzlich frei, ihren Zugang zum GSM-Modul zu wählen. Wir schlagen jedoch die Verwendung von AT-Befehlen vor (so wie dies in den GSM-Empfehlungen 07.05 (2) und 07.07 (3) niedergelegt ist). Es existiert ebenfalls ein Kommunikations-Service-Verzeichnis (CST), das die Anwendungen über die Verfügbarkeit von Daten-Services informiert.
Die Basisfunktion „indirekter AT-Befehl-Zugang" ermöglicht den indirekten Zugang von Anwendungen zum GSM-Modul durch die Verwendung gewisser AT-Befehle. Dieser Zugang ist auf die Abfrage von Statusinformationen begrenzt.
Die Basisfunktion „Anruf-Management" enthält Rückstellmechanismen (retrail?-eher: retain mechanisms) im Falle einer falschen Verbindung. Dies entbindet die Anwendung von der Aufgabe, sich mit Neuwahl- und Verbindungsfehlern selbst zu beschäftigen.
Um die Verwendung von verbindungsorientierten Bearer Services mit TASP4 (Telematic Application Security Protocol, layer 4 = telematisches Anwendungssicherheitsprotokoll, Schicht 4) zu unterstützen, ist ein zusätzliches End-zu-End-Protokoll für die sichere Übertragung von der Basisvorrichtung zum Center definiert worden. Die Zwischensystemkommunikation (subsystem commincation) enthält die folgenden Basisfunktionen:

1. GSM-Datentransfer
2. indirekter AT-Befehl-Zugang
3. Kommunikations-Service-Verzeichnis
4. Anruf-Management
5. End-zu-End-Protokoll

Die 2.2.1-1 zeigt die funktionelle Architektur der Zwischensystem-Kommunikation (?)
2.2.1-1: Funktionelle Architektur der Teilsystemkommunikation
Gewisse Daten-Services für Verkehrstelematikanwendungen werden zur Verwendung innerhalb des GSM-Netzwerks empfohlen; diese beinhalten Teleservice 21 (SMS-MT), Teleservice 22 (SMS-MO), Bearer Service 24 (2400 Bits) und Bearer Service 26 (9600 Bit/s), die sowohl transparent als auch nicht transparent sind. Künftige Dienstleistungen beinhalten Teleservice 23 (SMG Cell Broadcast) und GPRS (General Packet Radio Service) mit der Variante PDSS.
Die zur Verfügung stehenden Daten-Services hängen vom Land und vom Netzwerk ab. Die Anwendung wählt den Daten-Service (z. B. SMS, BS24 oder BS 26) und wird als ein Parameter zur Basisfunktion zusammen mit der Nachricht übergeben.
Eine Anwendung kann zwischen verschiedenen Daten-Services wählen, wenn sie mit dem Center kommuniziert. Die Endgerätanwendung muss über das Center informiert werden, welcher Daten-Service zu bevorzugen ist.
Da es keine Garantie gibt, dass der bevorzugte Daten-Service lokal verfügbar ist, wird von der Zwischensystemkommunikation ein Kommunikations-Service-Verzeichnis unterhalten. Der Zweck des Verzeichnisses ist, den Erfolg (oder den Misserfolg) beim Versuch der Kontaktaufnahme mit einem gewissen Service aufzuzeichnen; es ist daher in der Lage, eine Anwendung davon zu unterrichten, ob der geforderte GSM-Service verfügbar ist, ohne dass die Anwendung mit ihm Verbindung aufnehmen muss. Gibt es irgendwelche Zweifel, wird die Versuch- und Irrtum-Methode angewendet.
Das Kommunikations-Service-Verzeichnis zeichnet ebenfalls auf, welche Daten-Services von der Basisvorrichtung unterstützt werden. Es kann dann die Anwendung davon unterrichten, welche Dienstleistungen implementiert and daher bevorzugt werden.
Die Anwendungen entscheiden selbst, ob sie dem Vorschlag des Verzeichnisses folgen möchten oder ob sie einen alternativen Service bevorzugen.
Der Fehler-Handling-Mechanismus wird konstruiert, um sich mit den Problemen hinsichtlich der Handhabung der GSM-Verbindung zu befassen. Das TASP4-Gesamtprotokoll wird in die Zwischensystemkommunikation implementiert, die – wenn die Bearer Services (transparent oder nicht transparent) verwendet werden – einen sicheren Datentransfer zwischen der Basisvorrichtung und dem Service-Center (siehe 2.2.1-2) garantiert.
2.2.1-2: Kommunikationskomponenten zwischen dem Basis-Endgerät und dem Center
Neben der indirekten Verwendung des GSM-Moduls mit Hilfe der Befehle der Basisfunktion wird es ebenfalls einen direkten Zugang zum Modul geben. Verkehrstelematikanwendungen werden unter der Verwendung von entsprechenden Befehlen der Basisfunktion immer indirekten Zugang haben.
Anwendungen für den Datentransfer wie PC und Fax, deren Verwendung heute bereits normal ist, nehmen direkten Zugang; ohne Änderung der Software können sie mit der Basisvorrichtung verbunden werden. Der direkte Zugang ist nur über die Standard-Kommunikations-Schnittstelle möglich, weshalb das SCI in der Lage sein muss, eine Anfrage auf direkten Zugang zu erkennen. Andernfalls würde es einen Konflikt geben, wenn eine Verkehrstelematikanwendung mit höchster Priorität (so wie ein Notruf) zum Beispiel durch eine Fax-Übertragung blockiert werden würde. Diese Konflikte werden durch die Anruf-Management-Funktion gelöst.
2.2.1.1 GSM-Datentransfer
Adressierung/Ansprache des Service-Centers
Zahlreiche Service-Center mit verschiedenen Telefonnummern werden bereitgestellt. Wenn eine Verbindung hergestellt werden soll, gibt die Anwendung die Nummer an das entsprechende Service-Center weiter. Es obliegt der Verantwortung der Anwendung, die Nummer erforderlichenfalls auf Stand zu bringen.
Dialogfolge
Sowohl das Service-Center als auch die Endgerätanwendung können einen Dialog beginnen. Wenn es beispielsweise Nachrichten gibt, die an ein Service-Center zu versenden sind, oder wenn Informationen vom Service-Center abgefragt werden müssen, beginnt die Endgerätanwendung einen Dialog. Die Struktur des Dialogs ist mehr oder weniger für alle GSM-Datenservices dieselbe, egal ob ein Bearer Service, eine SMS, der künftige General Packet Radio Service oder der Packet Data on Signalling Channels Service (PDS) verwendet wird. Die 2.2.1-3 zeigt eine Dialogfolge für eine leitungsorientierte Verbindung, die durch eine Anwendung im Endgerät initiiert worden ist. Während die Dialogfolge in der Grundvorrichtung nicht geändert werden kann, kann die Service-Center-Folge variiert werden.
2.2.1-3: GSM-Dialogfolge eines Bearer Services (verbindungsorientiert), die von der Endgerätanwendung mit einer Beispielfolge im Service-Center initiiert wurde.
Die individuellen Anfragen und Nachrichten werden in Kapitel 3 (API-Spezifikation) beschrieben. Der Terminus „Nachricht" bezieht sich sowohl auf Anfragen als auch auf Nachrichten. Genau gesagt sind die beschriebenen Befehle „primitives" (= Grundoperationen), so wie sie durch die Kommunikationstechnologie definiert sind, da sie die Kommunikationsfolge mit der nächsten Ebene regulieren. Da diese jedoch Befehle und Folgen sind, die nur die Beziehung zwischen Anwendungen und Basisfunktionen betreffen, wird der Terminus „Nachrichten" in diesem Dokument durchweg verwendet werden.
Die 2.2.1-3 zeigt, dass die Kommunikationsfolge aus drei Phasen besteht.
Die erste Phase öffnet einen logischen Kommunikationskanal für den Datentransfer zwischen der Anwendung und der Zwischensystemkommunikation. Die Verbindungsanfrage enthält weitere Parameter neben der Nummer des Service-Centers. Informationen hinsichtlich des bevorzugten GSM-Daten-Services und der Anwendungs-Service- Identifizierer (asi) sind zum Beispiel wichtige Parameter. Für jeden Verkehrstelematik-Service gibt es einen gemeinsamen europäischen Standard. Wenn leitungsorientierte Verbindungen betroffen sind, muss der Aufbau der physischen Verbindung über eine Antennenschnittstelle vom Center bestätigt werden, bevor die Basisfunktion einen Kanal öffnen und eine Kanalnummer zuweisen kann. Paketorientierte Services wie SMS benötigen keine Bestätigung seitens des Centers. Da im Falle dieser Services das SMS-Center eine sichere Verbindung unterstützt, ist es nicht erforderlich, dass das TASP4-End-zu-End-Protokoll verwendet wird. Der Anfrage nach der Öffnung eines Kommunikationskanals folgt sofort die Bestätigung durch die Basisfunktion und die Zuweisung einer Kanalnummer.
Die zweite Phase ermöglicht einen Zwei-Wege-Austausch von Daten (Übermittlung und Empfang). Die Bestätigung des Empfangs wird von verbindungsorientierten Services und paketorientierten Services unterschiedlich gehandhabt. Weil Bearer Services das End-zu-End-Protokoll anwenden, bestätigt dieses Protokoll den Empfang an den Sender. So wie bei der SMS wird der Empfang vom SMS-Center bestätigt, ohne dass die Nachricht an das Verkehrstelematik-Center übermittelt worden ist.
In der dritten Phase wird der bestehende Kommunikationskanal geschlossen. Sowohl das Center als auch die Basisvorrichtung können die Verbindung trennen. In der Regel wird die Verbindung von der Partei getrennt, die die Kommunikation initiierte. Es gibt jedoch Ausnahmen von dieser Regel; zum Beispiel, wenn eine bestehende Verbindung unterbrochen wird (Prioritäts-Management), wenn bestehende Verbindungen von einigen Verkehrstelematikanwendungen gleichzeitig verwendet werden oder wenn eine Verbindung von der anderen Partei oder dem Netzwerk (z. B. Funkschatten) aktiviert wird. Wenn es darüber hinaus während eines definierten Zeitraums keinen Datentransfer gibt oder wenn die Verbindung die definierte Maximallänge überschreitet, wird dies aufgezeichnet (Funktion der Überwachungseinheit), und eine Trennung wird von der Basisfunktion initiiert werden. Wenn eine Anfrage auf die Schließung des Kanals in einer paketorientierten Kommunikation besteht, wird lediglich der logische Kanal zwischen der Anwendung und der Basisfunktion geschlossen. Daher kann die Basisfunktion die Anfrage sofort bestätigen. Dasselbe gilt für die verbindungsorientierte Kommunikation: Der Bestätigung der Schließung des logischen Kanals zwischen der Anwendung und der Grundfunktion folgt sofort das Freischalten der Verbindung. Das End-zu-End-Protokoll informiert das Center über das Freischalten, und das Center bestätigt dies dann.
Ein Dialog kann ebenfalls durch einen Anruf vom Center begonnen werden, wenn es erst einmal die Call-Management-Funktion (siehe Kapitel 2.2.1.4) weitergegeben hat. In diesem Fall gilt das Spiegelbild der 2.2.1-3; wiederum wird die Dialogfolge für die Basisvorrichtung reguliert, die Folge für das Center ist lediglich ein Beispiel. Unter Verwendung des Anwendungs-Service-Identifizierer (asi) informiert die Basisfunktion die Anwendung über einen eingehenden Anruf, indem die Nachricht „gsm_open_indication" (GSM-Anzeige öffnen) gesendet wird. Der Öffnungsbefehl hängt nicht von irgendeinem besonderen Datenservice (Bearer Services oder SMS) ab. Wird das Strecken-/Gesamtprotokoll verwendet, sendet die Basisfunktion die Nachricht „gsm_close_ind" (GSM-Anzeige schließen) nur, wenn die End-zu-End-Verbindung aktiviert ist. Bei einer SMS initiiert das Call-Management die Nachricht „gsm_closr_ind". Dies geschieht entweder sofort nach der Übermittlung des SMS-Pakets oder nach einem definierten Wartezeitraum, falls eine Folgenachricht erwartet wird.
Prioritätskonflikte
Sich widersprechende Kommunikationsanforderungen werden innerhalb des Zwischensystems durch die Prioritäts-Management-Funktion geregelt. Die Priorität einer jeden neuen Kommunikationsanfrage wird mit laufenden Kommunikationen verglichen. Wenn eine Übertragungsanfrage mit höherer Priorität registriert wird, wird die bestehende physische Verbindung unterbrochen und die Anwendung, deren Kommunikation unterbrochen worden ist, wird unterrichtet werden. Die logische Verbindung zwischen der Anwendung und der Basisfunktion (sowie die Kanalnummer) bleiben jedoch unbeeinträchtigt. Wenn die Kommunikation mit höherer Priorität erst einmal abgeschlossen worden ist (Verbindungsanfrage, Datentransfer, Freischalten der Verbindung), wird die physische Verbindung wieder hergestellt, und der Anwendung (Kanalnummer) wird erneut eine Nachricht übersandt werden. Die Kommunikation wird dann wiederholt werden.
In dem Fall, dass Daten mit höherer Priorität an dasselbe Center gesandt werden müssen, wird der Datentransfer unterbrochen werden. Die Anwendung, deren Kommunikation unterbrochen wurde, wird hierüber unterrichtet werden. Sowohl der logische Kanal als auch die physische Verbindung mit dem Center bleiben offen. Die Daten mit höherer Priorität werden dann übermittelt werden; wenn dies erst einmal abgeschlossen ist, wird der Kanal mit höherer Priorität geschlossen. Gleichzeitig wird die Anwendung, deren Kommunikation unterbrochen wurde, unterrichtet werden. Das End-zu-End-Protokoll wird reimplementiert und die unterbrochene Kommunikation wird fortgesetzt werden.
Die Basisfunktion setzt Rückhaltemechanismen (retrail mechanisms) ein, die garantieren, dass ein unterbrochener Datentransfer wirkungsvoll fortgesetzt werden kann. Es macht Sinn, die Verbindung offen zu halten, wenn dieselbe Dienstleistung verwendet werden soll. Wenn beispielsweise eine BS26-Verbindung aufgebaut worden ist und die Anwendung mit hoher Priorität über BS24 übermitteln wird, kann die bestehende Verbindung so lange verwendet werden, wie sie von der Anwendung unterstützt wird. Andernfalls wird ein Freischalten der Verbindung und ein neuer Aufbau notwendig sein. Die betroffene Anwendung wird über die Trennung informiert werden.
Mehrfachverwendung einer bestehenden Verbindung
Eine bestehende Verbindung kann gleichzeitig von mehreren Anwendungen verwendet werden, vorausgesetzt, dass alle denselben Service verwenden und dasselbe Service-Center ansprechen. Innerhalb einer bestehenden Verbindung können mehrere Nachrichten von einer Anwendung oder von mehreren Anwendungen in Folge sowohl übermittelt als auch empfangen werden.
Wenn eine Nachricht zu lang ist, um sie übermitteln zu können, kann sie in Pakete aufgeteilt werden. Allerdings müssen alle Pakete, die zu einer Nachricht gehören, übersandt werden, und die korrekte Übermittlung muss vom End-zu-End-Protokoll bestätigt werden, bevor eine andere Nachricht empfangen oder übermittelt werden kann. Es wird keine Möglichkeit für eine komplexe Übermittlung von mehreren Nachrichten durch dieselben oder verschiedene Anwendungen (Multiplex-Operation) geben.
Um die Kommunikation zu beenden, sendet die Anwendung einen Befehl an die Basisfunktion, um den Kanal zu schließen. Der logische Kommunikationskanal zwischen der Anwendung und der Basisfunktion wird dann geschlossen werden (so wie unter der Überschrift „Dialogfolge" beschrieben). Wenn dieselbe Verbindung noch von anderen Anwendungen verwendet wird, wird lediglich die physische Verbindung unterbrochen, wenn diese Anwendungen ihren Dialog mit dem Service-Center erst einmal beendet haben.
Funktion der Überwachungseinheit (watch-dog)
Die Funktion der Überwachungseinheit überwacht bestehende GSM-Verbindungen. Diese Funktion hat die Möglichkeit, Verbindungen zu unterbrechen, wenn sie Systemfehler entdeckt. Zwei Zeitgeber sind implementiert worden, um dies durchzuführen. Ein Zeitgeber ermittelt den Zeitraum, nach dem eine Verbindung unterbrochen wird, wenn der Datenfluss stoppt. Der andere Zeitgeber ermittelt die maximale Länge einer Verbindung. So bald diese Länge überschritten wird, wird die Verbindung unterbrochen, selbst wenn noch zu übermittelnde Daten vorhanden sind.
2.2.1.2 Indirekter AT-Befehl-Zugang
Der indirekte AT-Befehl-Zugang ermöglicht es Anwendungen, das GSM-Modul unter Verwendung von gewissen AT-Befehlen anzusprechen. Informationen hinsichtlich des Status und der Initialisierung des GSM-Moduls können auf diese Weise angefordert werden. Um Zugang zum GSM-Modul zu erlangen, wird empfohlen, die erweiterten AT-Befehle zu verwenden, so wie dies in den GSM-Empfehlungen 07.05 (3) und 07.07 (2) beschrieben ist.
Eine Liste der zur Verfügung stehenden AT-Befehle ist in der Anlage 2 zu diesem Dokument (siehe Kapitel 5.2) enthalten.
Eine Liste von verfügbaren AT-Befehlen ist in der Anlage 2 dieses Dokuments enthalten (siehe Kapitel 5.2).
2.2.1.3 Zugang zum Kommunikations-Service-Verzeichnis
Die Anwendung entscheidet, welches Datensystem sie verwenden möchte. Nichtdestoweniger stellt die Zwischensystemkommunikation ein Kommunikations-Service-Verzeichnis (CST) bereit, um die Verfügbarkeit von Dienstleistungen zu dokumentieren, die von den Anwendungen gefordert wurden.
Die Anwendungen haben über einen Funktionsbefehl Zugang zum Inhalt dieses Verzeichnisses und können den Inhalt auch teilweise ändern, z. B. um die Telefonnummer eines Verkehrstelematik-Centers (Anrufs-Leitungs-Identität ((CLI))) einzufügen.
Eine Anwendung kann anfragen, ob ein gewisser Kommunikationsservice im Basis-Endgerät implementiert und ob der Service gegenwärtig verfügbar ist. Es ist daher wichtig, dass das CST die Möglichkeit besitzt, sowohl die derzeitigen als auch die möglichen Dienstleistungen einzuschließen.
Wir empfehlen, folgende Kommunikationsservices zu unterstützen:
Bearer Services BS24, BS26 (transparent und nicht transparent)
Teleservices TS11, TS21, TS22, TS23
sowie zusätzliche Services
CLIP/CLIR und Call Wait sind als zusätzliche Services vorgesehen.
Initialisierung
Das Verzeichnis wird in einem flüchtigen, änderbaren Speicher geführt, und jedes Mal dann, wenn die Vorrichtung eingeschaltet wird, wird das Verzeichnis in Übereinstimmung mit dem GMS-Modul auf den neuesten Stand gebracht. Wenn die Software des Basis-Endgeräts implementiert oder heruntergeladen oder wenn das Endgerät aktualisiert wird, werden die Dienstleistungen, die vom Grundendgerät unterstützt werden, in das CST eingetragen.
Das Bringen "Auf-den-neuesten-Stand" (Aktualisierung)
Im Netzwerk verfügbare Daten-Services werden nur auf den neuesten Stand gebracht, wenn das GSM-Modul in Betrieb ist. Jedes Mal dann, wenn ein Datentransfer stattfindet oder abgelehnt wird, wird der Status des angefragten oder angewendeten Daten-Services auf den neuesten Stand gebracht. Die Anwendung erhält Informationen darüber, ob der Transfer stattfindet oder ob der Daten-Service nicht zur Verfügung stand. Die Anwendung entscheidet dann, ob sie eine Alternative anwenden möchte.
Da sich die Verfügbarkeit ändern kann (z. B. wegen eines Netzwerktransfers oder eines örtlichen Ausfalls), sind die Einträge ins Verzeichnis nur für einen begrenzten Zeitraum gültig.
2.2.1.4 Anruf-Management
Das Anruf-Management führt zwei wesentliche Funktionen durch. Zuerst überprüft es eingehende Anrufe und stellt fest, ob sie von einem Verkehrstelematik-Center weitergegeben worden sind oder ob ein Zugang zu einer externen PC- oder Fax-Anwendung erfolgen muss. Zweitens befasst sich das Anruf-Management mit allen Arten von Kommunikationsfehlern.
Überprüfung von eingehenden Anrufen
Ein eingehender Anruf kann entweder an Verkehrstelematikanwendungen oder an andere Anwendungen wie PC-Anwendungen, Fax usw. adressiert werden. Wenn das GSM-Modul die Anruf-Leitungs-Identität (CLI) unterstützt und das Center entweder direkt oder über ISDN mit dem Netzwerk verbunden ist, wird das Service-Center über die Nummer unterrichtet werden. Weitere Informationen werden in Daten-Pakete (so genannte „in-band-information"-bandintern) integriert. Die entsprechende CLI wird im CST abgelegt.
Bei jedem eingehenden Anruf muss entschieden werden, wie die nachfolgende Kommunikationsfolge stattfinden muss und an wen der Anruf adressiert ist. Was folgt ist eine Beschreibung des Verfahrens.

(1) Zunächst einmal muss festgestellt werden, ob der eingehende Anruf eine Kurznachricht ist oder nicht. Wenn es keine SMS ist:
(2) entscheidet das Anruf-Management, ob die Anruf-Leitungs-Identität geliefert wurde. In dem Fall, dass die CLI geliefert wurde, muss es prüfen, ob es einem Verkehrstelematik-Center zugeordnet werden kann. Wenn ja, wird der Anruf entgegengenommen (weiter mit (4), obgleich die Prüfung der Verkehrstelematikidentifikation optional ist). Wenn nicht, wird der Anruf zur Standard-Kommunikations-Schnittstelle (SCI) weitergeschaltet.
(3) In dem Fall, dass die CLI nicht geliefert worden ist, wird die Dienstleistung überprüft: Wenn es ein Fax-Anruf ist, wird der Anruf zum SCI weitergeschaltet. Andernfalls wird der Anruf entgegengenommen (weiter mit (4)).
(4) Der Anruf wurde entgegengenommen, und es wird geprüft, ob eine TT-Identifikation empfangen worden ist (in Form von in-band-information). Wenn dies der Fall ist, werden die empfangenen Informationen an die angesprochene Verkehrtelematikanwendung weitergegeben. Besteht keine TT-Identifikation, werden die Informationen an die SCI weitergeleitet.

Wenn es eine ist:
Im Falle einer empfangenen Kurznachricht hängt das Verfahren davon ab, welcher Tele-Service verwendet wird:

(A) Wird ein TS 21 (SMS MT) verwendet, prüft das Anruf-Management, ob es das TT-Center von der Erzeugernummer herleiten kann. Wenn ja, wird eine Kurznachricht an die entsprechenden Anwendungen weitergeleitet werden. Andernfalls wird die Kurznachricht an die SCI weitergeleitet werden.
(B) Wird kein TS 21 verwendet, wird die Kurznachricht als ein TS23 (cell broadcast-Zellenübertragung) behandelt, und nach der Auswertung des Identifizierers kann sie an eine Anwendung weitergeleitet werden.

Behandlung von Kommunikationsfehlern
Der Zugang zum Service-Center ist nicht immer möglich. Hierfür gibt es mehrere Erklärungen: Die Verbindung kann gestört oder unterbrochen sein, oder das Center ist besetzt.
Aus diesem Grund ist es erforderlich, neben dem GSM-spezifischen Fehlerbehandlungsmechanismus weitere, individuelle Mechanismen für die Berichtigung, so wie zyklische Neuversuche, zu implementieren, wenn eine Verbindung aufgebaut wird. Die erneuten Wählversuche werden in Übereinstimmung mit dem GSM-Standard durchgeführt. Abhängig von der Priorität der Anwendung sind Abweichungen möglich.
Das CST bewahrt und verwaltet Informationen (Neuwahlzähler mit Telefonnummer, Zeitstempel und Grund für die "Refektion", die die Zwischensystemkommunikation benötigt, um sich an die Einschränkungen für Neuwählversuche zu halten, so wie dies in den GSM-Empfehlungen 02.07 festgehalten ist (Anlage „Automatic calling repeat call attempt restrictions"= Einschränkungen bzgl. automatischer/m Anrufwiederholung/Anrufsversuch). Auszüge aus diesen Einschränkungen befinden sich in der Anlage 1.
Nach einem erfolgreichen Datentransfer erhält die Anwendung eine Bestätigung. Gibt es irgendwelche Fehler, die von der Grundfunktion nicht gleichgerichtet werden können, wird die Anwendung über die Gründe unterrichtet. Die Anwendung entscheidet, ob Informationen über diesen Fehler an den Nutzer weitergeleitet werden oder nicht.
Darüber hinaus kann die Anwendung Zugang zu weiteren Fehlerinformationen über die Netzwerkauslösegründe bekommen (z. B. Grund 63, d. h. der Teilnehmer hat für diesen Service kein Abonnement). Die entsprechenden Mechanismen für eine Anruffortsetzungs- und Neuwählvorrichtung finden sich andererseits in den Basisfunktionen.
In der Anlage 1 findet sich eine Liste von möglichen Fehlernachrichten (GSM 04.08., Verzeichnis 10.86), die die Basisfunktionen annehmen, verdichten und an die Anwendungen weiterleiten.
Wenn die Verbindung erst einmal eingerichtet ist, folgt das Verfahren dem End-zu-End-Protokoll, das im nachfolgenden Kapitel beschrieben ist.
2.2.1.5 TASP4-End-zu-End-Protokoll
Das Transportanwendungssicherheitsprotokoll bietet eine End-zu-End-Sicherheit, und seine Aufgaben entsprechen jenen des OSI-Protokolls der Stufe 4. Es nennt sich TASP4. Lediglich eine der Funktionen des TASP4-Protokolls wird von Verkehrstelematikanwendungen benötigt, und es führt weniger Funktionen durch als ein klassisches Transportprotokoll, so wie das TCP.
Das TASP4-Protokoll basiert auf dem LAPB-Protokoll, das in der X.25-Spezifikation (7) (Stufe 2) gefunden werden kann. Das LAPB-Protokoll wurde entsprechend der besonderen Anforderungen der Stufe 4 modifiziert.
2.2.1-4: GSM-Dialogfolge der Bearer Services (verbindungsorientiert), die durch ein Endgerätanwendung mit einem Beispieldialog im Service-Center initiiert wurde.
Die 2.2.1-4 zeigt eine Kommunikationsfolge, die über die API-Schnittstelle hinausgeht (Anwendung <-> Basisfunktion). Es zeigt die involvierten Abhängigkeiten mit besonderer Hervorhebung des TASP4-End-zu-End-Protokolls. Die Dialogfolge im Basis-Endgerät ist strikt definiert, während die Centerfolge als ein Beispiel zu verstehen ist.
Umfang der Funktionen:

– Standardisierung: TASP4 ist ein modifiziertes HDLC-Protokoll in vollständigem Duplexbetrieb. Es arbeitet im ausgeglichenen Modus.
– Anwendung: Lediglich die Anwendungen, die mit einer verbindungsorientierten Übertragung (Bearer Services) arbeiten, können das Transportprotokoll TASP4 anwenden. Es kann mit dem Short Message Service (SMS) nicht verwendet werden.
– Multiplex: Multiplex (mehrere Nutzer haben zur gleichen Zeit Zugang zu derselben TASP4-Einheit) wird durch eine Funktion durchgeführt, die oberhalb der Transportebene aufgefunden/geortet wurde. Der TASP4-Header beinhaltet daher nicht irgendwelche Adresseninformationen.
– Verbindungssteuerung: Die Verbindungssteuerung beinhaltet jene Elemente eines Protokolls, die mit einem sicheren Aufbau und der Beendigung der End-zu-End-Verbindung zu tun haben.
– Bestätigungsinformationsübermittlung: Der positive Bestätigungsmechanismus mit Zeitprüfung garantiert, dass die Pakete den Empfänger sicher erreichen. Pakete, die nicht bestätigt werden, werden erneut versandt werden.
– Unbestätigte Informationsübermittlung: Die unbestätigte Informationsübermittlung über Datagramme wird durch Übertragung/Senden und andere vereinfachte Verfahren angewendet.
– Flusssteuerung: Diese wird durch die herkömmlichen Mittel (d. h. Fenster, RNR) sichergestellt.
– Fehlersteuerung: CRC-16 ist für den Schutz der Datenübermittlung verantwortlich.
– Priorität: Da es nur einen Anwender gibt, ist keine Möglichkeit für die Handhabung der Priorität auf der Transportebene implementiert. Die Handhabung des Transports erfolgt auf der Anwendungsebene, indem beispielsweise eine Verbindung beendet wird (DISC), um eine andere mit höherer Priorität (SABM) einzurichten.
– Leitungsorientierte Transmissions-Links: Der Transfer über leitungsorientierte Transmissions-Links wird durch Paketmontage (Beginn-Flag + Längenindikator) ermöglicht.
– Transparenz: Byte-Einschränkungen sind einzuhalten; es wird jedoch nicht empfohlen, Bits zu überfüllen, sondern Transparenz mit Hilfe eines Längenindikators zu erreichen.
– Segmentation: Lange Nachrichten können in mehrere Segmente aufgeteilt, separat übermittelt und beim Empfänger erneut zusammengesetzt werden. Die maximale Länge eines Segments hängt vom Bearer Service ab.
– Nachrichtenreihenfolge: Wir gehen davon aus, dass die Reihenfolge der Nachrichten während der Übertragung nicht geändert wird. Dies gilt sowohl für die leitungsorientierte Übermittlung (BS24) als auch für die verbindungsorientierte Übermittlung über X.25 (7).

Die Nachrichtenfolge und die Service-Basisoperationen des TASP4-Protokolls sind in der Anlage 3 beschrieben.
2.2.2 Basisfunktionen im Zwischensystem Ortsbestimmung
Ein gemeinsames Merkmal vieler Verkehrstelematikanwendungen ist die Notwendigkeit, den Standort des Fahrzeugs zu bestimmen. Das Global Positioning System (GPS) bildet die technische Grundlage für das Zwischensystem Ortsbestimmung. Das Zwischensystem ist jedoch in einer Weise konstruiert worden, die die Verwendung anderer Ortsbestimmungsverfahren ermöglicht. Dies bedeutet, dass – wenn andere Ortsbestimmungssysteme künftig entwickelt werden – sie in das System implementiert werden können. Die funktionale Architektur des Systems ist auf die Bedingung übertragbar, dass modifizierte Funktionsbefehle hinzugefügt werden. Alle Basisfunktionen des Zwischensystems Ortsbestimmung basieren auf einer fortlaufenden Positionsfeststellung durch den GPS-Empfänger.
Das Zwischensystem Ortsbestimmung umfasst insbesondere die folgenden Basisfunktionen:

1. Basisfunktion GPS-Basisdaten
2. Basisfunktion Geometrie
3. Basisfunktion Annäherung
4. Basisfunktion Weglänge
5. Basisfunktion Wegpunkt

Die nachfolgende 2.2.2-1 zeigt die funktionelle Architektur des Zwischensystems Ortsbestimmung.
2.2.2-1: Funktionelle Architektur des Zwischensystems Ortsbestimmung
Die in diesem Teil beschriebenen Basisfunktionen bilden zwei Gruppen: Anruf und Antworten/Reaktionen. Bei den zwei Funktionen GPS-Basisdaten und Geometrie folgt des Ergebnis sofort auf die Anfrage der Anwendung. Die Basisfunktion Annäherung läuft im Hintergrund, falls das GPS-Modul keine GPS-Positionen bereitstellt (z. B. wegen Signalausfall oder Spiegelung), und die Position muss angenähert werden. Andere Basisfunktionen können Operationen im Hintergrund laufen lassen, wenn hiernach verlangt wird. Die Ergebnisse werden an die Anwendung gesendet, die die Anfrage zu einem späteren Punkt machte.
Die Zwischensystem-Ortsbestimmung verarbeitet die Prioritätsinformationen nicht, die im Telegramm der Nachricht enthalten sind (siehe Kapitel 3.2.1). Da die Basisfunktionen GPS-Basisdaten und Geometrie sofort Ergebnisse bereitstellen, würde eine Unterbrechung keinen Sinn machen. Andere Grundfunktionen, die im Hintergrund laufen, verwenden den GPS-Empfänger nicht allein; dies bedeutet, dass eine parallel verlaufende Verarbeitung keinerlei Probleme verursacht.
Die Ortsbestimmung kann durch Sensoren (so wie ungefähre Berechnung, Lesen des Geschwindigkeitsmessers, Beschleunigungssensoren) unterstützt werden. Mit der ungefähren Berechnung kann die Position festgestellt werden, selbst wenn es einen vorübergehenden Ausfall des GPS-Moduls gibt. Die Verfügbarkeit des Zwischensystems Ortsbestimmung wird dadurch erhöht.
Die Genauigkeit der Feststellung der Position kann durch die Verwendung von unterschiedlichen Informationen erhöht werden. Unterschiedliche Informationen können auf zwei Arten weitergegeben werden: entweder direkt in das GPS-Modul (vorausgesetzt, dass dies technisch durchführbar ist) oder das API (SCI für externe Quellen). Wenn eine Anwendung DGPS-korrigierte Positionsdaten benötigt, kann es unterschiedliche Informationen vom Center über die Zwischensystemkommunikation abfragen. Korrekturdaten, die vom Center kommen, werden mit einer entsprechenden Nachricht an das Zwischensystem für die Ortsbestimmung gesendet.
Da die Verarbeitungsenergie des Systems begrenzt ist, ist es wichtig, ein intelligentes Ressourcen-Steuersystem zu schaffen. Dies ist jedoch nicht Gegenstand dieser Spezifikation.
2.2.2.1 Basisfunktion GPS-Basisdaten
Die Basisfunktion GPS-Basisdaten befindet sich genau neben der Schnittstelle zum GPS-Modul. Sie liefert sowohl TT-Anwendungen als auch GPS-Basisfunktionen mit GPS-Positionsdaten.
Die Basisfunktion GPS-Basisdaten verarbeitet GPS-Datensätze, die in verschiedenen Formaten abhängig vom GPS-Modul geliefert werden, und sie überträgt diese in einen Standard-Datensatz.
Auf Anfrage haben Anwendungen die folgenden Datenelemente zu ihrer Verfügung:

– Datum und Zeit (UTC);
– den geographischen Breitengrad;
– den geographischen Längengrad;
– Höhe (gemessene See-Ebene);
– horizontale Präzisionsauflösung (HDOP);
– geschätzter Positionsfehler in südlich-nördlicher Richtung (EPE(x));
– geschätzter Positionsfehler in westlich-östlicher Richtung (EPE(y));
– horizontaler Geschwindigkeitswert;
– Richtung (heading);
– Anzahl der Satelliten (jene, die theoretisch verwendet werden, und jene, die derzeit verwendet werden);
– Positionstyp (TOP);
– empfängerspezifische Daten;
– Pseudobereichsdaten und Pseudobereichsmenge.

Es gibt immer mehr Daten, als eine Anwendung tatsächlich benötigt. Jede Anwendung wählt die Elemente, die sie benötigt, mit Hilfe einer Bit-Karte aus, und dann gibt sie lediglich eine Anfrage nach diesen Elementen ein. Wenn mehrere TT-Anwendungen verschiedene Datenelemente anfragen, wird der ganze Datensatz an die Anwendung gesendet. Eine Bit-Karte gibt an, welche Daten der Satz beinhaltet.
Das Datum und die Zeit eines jeden Messpunktes werden direkt von der internen Wählscheibe (internal dial) des GPS-Empfängers ermittelt. Einmal alle vier Jahre werden Anwendungen auf die Schaltsekunde achten müssen, da zwei aufeinanderfolgende Datensätze an diesem Punkt denselben Zeitstempel haben werden.
Der geographische Längen- und Breitengrad (die sich auf WGS 84 beziehen) des Messpunktes sind für die Positionsermittlung Schlüsselparameter.
Der DOP-Wert ist das Verhältnis zwischen dem Fehler der Empfängerposition und dem Fehler der Satellitenposition. Er ermöglicht Schlussfolgerungen hinsichtlich der geometrischen Konstellation von Satelliten und daher in Bezug auf die Genauigkeit der gegenwärtigen Position. Von den verschiedenen DOP-Werten wird lediglich die horizontale Präzisionsauflösung (HDOP) bereitgestellt, da nur dieser Wert für die Positionsermittlung im Flachland relevant ist.
Der geschätzte Positionsfehler ist ein statistischer 1-Sigma-Wert einer Gaußschen Verteilung und gibt unter Verwendung des metrischen Systems den geschätzten horizontalen Positionsfehler an. Er besteht aus zwei Werten, dem Positionsfehler in südlich-nördlicher Richtung (EPE(x)) und den Positionsfehler in westlich-östlicher Richtung (EPE(y)). Wenn ein Empfänger nur einen EPE-Wert ermitteln kann, sind die beiden Positionsfehler identisch.
Die Geschwindigkeit wird hier als der horizontale Geschwindigkeitswert definiert. Die Richtung (heading) ist ein Winkel (in Grad) des horizontalen Geschwindigkeitsvektors in nördlicher Richtung (d. h. 0 Grad ist „Norden"). Die Drehung erfolgt im Uhrzeigersinn. Wenn die Geschwindigkeit unter einen gewissen Wert fällt (minimale Geschwindigkeit), wird die Geschwindigkeit mit 0 m/s aufgezeichnet, und die Richtung wird als „ungültig" erscheinen. Die minimale Geschwindigkeit hängt vom Typ des GPS-Moduls und davon, ob Unterstützungssensoren vorhanden sind.
Die Parameter, die eine Änderung der Satellitenkonstellation anzeigen, haben entweder den Wert 0 („keine Änderung der Konstellation") oder 1 („Änderung der Konstellation"). Dieser Parameter dient als Indikator für eine Positionsänderung.
Pseudobereichsdaten beinhalten Informationen hinsichtlich der Signallaufzeit individueller Satelliten; mit diesen Daten kann die differentiale GPS-Position im Rückblick berechnet werden.
Der Positionstyp (TOP)
beschreibt, wie die Position zu ermitteln ist. Der TOP ist eine Bit-Karte und beinhaltet die folgenden Flags:

– ungültige Position (keine derzeitige Positionsermittlung erforderlich);
– dreidimensionale unabhängige Position;
– zweidimensionale unabhängige Position;
– dreidimensionale differentiale Position;
– zweidimensionale differentiale Position;
– zweidimensionale Positionsberechnung mit fester Höhe;
– durch nach vorne gerichtete Annäherung erzeugte Position;
– durch nach hinten gerichtete Annäherung erzeugte Position;
– mit Sensorunterstützung berechnete Position.

Wenn die Basisfunktion GPS-Basisdaten vom GPS-Empfänger mit einer ungültigen Position geliefert wird (d. h. eine derzeitige Positionsermittlung ist nicht möglich), berechnet die Basisfunktion Annäherung die nach vorn angenäherten Positionen und sendet diese Daten an die Anwendungen. Die Annäherung wird auf der Grundlage der letzten gültigen Positionen n (n ≥ 2) durchgeführt, die zu diesem Zweck gespeichert werden müssen. Die Mindestanforderung ist eine lineare Annäherung (d. h. n = 2)
Sobald gültige Positionen wieder verfügbar sind, wird die Basisfunktion Annäherung eine nach hinten gerichtete Annäherung durchführen, um die Lücke zu füllen. Auf Anfrage hin werden diese Daten an die Anwendung weitergegeben.
Sowohl die nach vorn als auch die nach hinten gerichteten, angenäherten Positionen sind in der TOP-Bit-Karte ausgewiesen.
Die zweidimensionale Positionsberechnung kann auf zwei Arten durchgeführt werden. Erstens: Wenn keine Satelliten zu irgendeinem besonderen Moment verfügbar sind, wird der GPS-Empfänger die letztgültige Höhe verwenden, um die Position zu ermitteln. Zweitens: Eine Anwendung kann eine Höhe bereitstellen, die dann vom GPS-Empfänger als zusätzliche Information verwendet wird, um die Genauigkeit der Positionsermittlung zu verbessern.
Eine Anwendung kann eine Höhe festlegen, wenn sie die genaue Höhe im Verhältnis zum Breiten- und Längengrad der gegenwärtigen Position kennt. Die Anwendung sendet die Höhenangabe zur Basisfunktion GPS-Basisdaten zusammen mit dem Radius des Kreises, der die derzeitige Position umringt, innerhalb dessen die definierte Höhe noch stimmt. Die Basisfunktion GPS-Basisdaten prüft, ob die nächste Position noch innerhalb des Kreises liegt, indem sie die derzeitige Geschwindigkeit und die Zeitstufe analysiert. Nur wenn dies der Fall ist, wird die Anwendung die Höhenangabe an den GPS-Empfänger weitergeben. Dieses Verfahren wird bei jeder neuen Position wiederholt. Wenn die Analyse ergibt, dass sich die nächste Position außerhalb des Kreises befinden wird, wird die ermittelte Höhe entweder durch die Basisfunktion oder unter Verwendung einer entsprechenden Nachricht von der Anwendung gelöscht. Irgendwelche Widersprüchlichkeiten hinsichtlich der Höhe zwischen verschiedenen Anwendungen müssen innerhalb des Basis-Endgeräts gelöst werden. Dies kann sogar zu einer Situation führen, wo keine der Höhenangaben verwendet werden kann.
2.2.2.2 Basisfunktion Geometrie
Die Basisfunktion Geometrie beinhaltet mathematische Basisfunktionen, die sowohl anderen Basisfunktionen als auch Verkehrstelematikanwendungen zur Verfügung gestellt werden. Die Berechungen erfolgen in Übereinstimmung mit WGS 84.
Die folgenden mathematischen Funktionen sind implementiert worden:

– Berechnung der radialen Entfernung zwischen zwei Positionen;
– Berechnung der Längenentfernung zwischen zwei Positionen;
– Berechnung der Breitenentfernung zwischen zwei Positionen;
– Berechnung des Richtungswinkels von einer Position zur anderen.

Die Funktionsanfrage kann zwei Formen annehmen:

– Berechnung der Entfernung und des Winkels von zwei Positionen, die während der Anfrage gesendet werden;
– Berechnung der Entfernung und des Winkels der gegenwärtigen Position in Bezug auf eine andere Position, die während der Anfrage ermittelt wird.

Bei all diesen Berechnungen wird empfohlen, Annäherungsformeln für geringe Entfernungen und Winkel zu verwenden, die weniger genau sind, aber Zeit bei der Berechnung sparen.
2.2.2.3 Basisfunktion Annäherung
Die Positionsannäherung wird bei jenen Situationen angewendet, wenn es nicht genügend Messpunkte gibt (z. B. bei Satellitenschatten oder Spiegelungen).
Auf der Grundlage von Annäherungswerten können Geschwindigkeit und Richtungsbewegung für jede angenäherte Position berechnet werden.
Es gibt zwei verschiedene Annäherungsverfahren:

– nach vorne gerichtete Annäherung in Echtzeit und
– nach hinten gerichtete Annäherung.

Die nach vorne gerichtete Annäherung in Echtzeit wird automatisch durchgeführt, und die angenäherte Position wird an die Basisfunktion GPS-Basisdaten gesendet. Alle TT-Anwendungen, die GPS-Positionen angefragt haben, werden ohne erneute Anfrage mit der nach vorne angenäherten Position beliefert. Nach hinten gerichtete, angenäherte Positionen werden andererseits nur auf ausdrückliche Anfrage hin an Anwendungen geliefert.
Als Mindestanforderung muss die Basisfunktion Annäherung in der Lage sein, eine lineare Annäherung durchzuführen. Dies kann unter Verwendung des polynomischen Verfahrens erfolgen, das unten beschrieben ist, bei dem angenommen wird, dass der Polynomgrad 1 ist. Die polynomische Annäherung ist als ein Vorschlag für ein verbessertes Annäherungsverfahren zu verstehen. Andere Verfahren können jedoch vom Hersteller implementiert werden.
Wenn die Basisfunktion GPS-Basisdaten einen ungültigen Datensatz empfängt, stellt die Grundfunktion Annäherung eine geschätzte Position bereit.
Zunächst wird eine nach vorne gerichtete Annäherung durchgeführt, und die berechneten Positionen werden zur Basisfunktion GPS-Basisdaten zurückgeleitet. Die Grundfunktion kann nur eine begrenzte Anzahl an nach vorne gerichteten, angenäherten Positionen erstellen. Eine Maximalanzahl muss ermittelt werden; ist dieses Maximum erst einmal überschritten, werden ungültige Daten geliefert werden.
Der geschätzte Positionsfehler (EPE) wird für jede Position berechnet (dies trifft ebenfalls für angenäherte Positionen zu). Bei nach vorne gerichteten Annäherungen steigt der EPE-Wert mit jeder Annäherung.
Wenn die erste gültige Position erst einmal nach einer Anzahl von ungültigen Positionen geliefert ist, wird eine nach hinten gerichtete Annäherung durchgeführt, um die Lücke bei Fahrzeugpositionen zu füllen. Falls eine Anwendung die erste gültige Position durch ihr TOP erkennt, muss sie von der Basisfunktion Annäherung die nach hinten gerichteten, angenäherten Positionen anfragen, wenn sie diese Daten benötigt.
Nach hinten gerichtete Annäherungen werden nur durchgeführt, wenn der Zeitraum, in dem keine gültigen Positionen erzeugt worden sind, nicht ein gewisses definiertes Limit überschreitet.
Wenn die Zwischensystemortsbestimmung von Sensoren unterstützt wird, die im Falle des Ausfalls des GPS-Moduls weiter fortlaufende Positionen über einen gewissen Zeitraum hinweg liefern, werden nach vorne und nach hinten gerichtete Annäherungen während dieser Zeit nicht verwendet werden. Annäherungs-„Routines" (?) werden nur angewendet, nachdem die Positionsermittlung durch Sensoren nicht fortgesetzt worden ist.
Beim folgenden Vorschlag für ein verbessertes, polynomisches Annäherungsverfahren werden polynomische Funktionen desselben Grades für eine nach vorne und eine nach hinten gerichtete Annäherung verwendet. Der Grad der polynomischen Funktion kann als Parameter verwendet und muss definiert werden. Um die Berechnung so einfach wie möglich zu halten, wird empfohlen, den Polynomgrad auf einer Skale zwischen 1 und 5 zu ermitteln.
a) Nach vorne gerichtete Annäherung in Echtzeit
Nach einem Signalausfall wird eine nach vorne gerichtete Annäherung von Positionen als Folge der Bewegung des Fahrzeugs durchgeführt werden (siehe 2.2.2-2).
Die nach vorne gerichtete Annäherung wird unter Verwendung einer polynomischen Funktion mit dem Grad m durchgeführt. Um die sich daraus ergebende Gleichung zu lösen, müssen die letztgültigen (m+1) Positionen verfügbar sein.
In den folgenden Gleichungen für die Breitenkoordinate wird x (x-Achse in nördlicher Richtung) als Beispiel verwendet. Ein analoges Verfahren kann für die Längenkoordinate y (y-Achse in östlicher Richtung) angewendet werden.
Die letztgültigen (m+1) Positionen („alte Positionen") sind:

x₀ = x(t₀) Position zum Zeitpunkt t₀

x_i = x(t_i) Position zum Zeitpunkt t_i

x_m = x(t_m) Position zum Zeitpunkt t_m
Der GPS-Empfänger wird zu einem definierten Zeitpunkt angepasst und regelt dadurch die Lücke zwischen den einzelnen Punkten.
2.2.2-2: Polynomische, nach vorne gerichtete Annäherung
Im Falle eines Signalausfalls des GPS-Empfängers kann die erste angenäherte Position x_m-1 zum Zeitpunkt t_m-1 unter Verwendung der polynomischen Formulierung berechnet werden. x = a0 + a1t + a2t2 + a3t3 + ... + amtm
Die Koeffizienten a₀, a₁, a₂, ... a_m werden unter Verwendung der alten Positionen berechnet.
Die nach vorne gerichteten, angenäherten Positionen xm+1, xm+2, xm+3 ... zu verschiedenen Zeitpunkten tm+1, tm+2, tm+3 werden unter Verwendung der Formel xi = ai + a1ti + a2ti 2 + a3ti 3 + ... + amti m mit i = m+1, m+2, m+3, ... ermittelt.
b) Nach hinten gerichtete Annäherung
Eine nach hinten gerichtete Annäherung wird nach einem Signalausfall durchgeführt, wenn erst einmal die erste gültige Position nach der Lücke verfügbar wird (siehe 2.2.2-3). Die nach hinten gerichtete Annäherung basiert auf demselben Verfahren wie dem für die nach vorne gerichtete Annäherung.
Die nach hinten gerichtete Annäherung wird mit Hilfe einer polynomischen Funktion gleichen Grades durchgeführt. Um die sich ergebenden Gleichungen zu lösen, müssen sowohl die letztgültigen Positionen m vor der Lücke („alte Positionen") als auch die erste gültige Position („neue Position") nach der Lücke verfügbar sein. Das Annäherungsverfahren ist dasselbe Verfahren, das für die nach vorne und nach hinten gerichtete Annährung angewendet wird.
Die folgenden Gleichungen werden für die Breitenkoordinate x (x-Achse in nördlicher Richtung) festgelegt. Das Verfahren gilt analog für die Längenkoordinate y (y-Achse in östlicher Richtung).

Wenn die Anzahl der fehlenden Positionen nhole ist, lauten die letztgültigen Positionen m vor der Lücke („alte Positionen") und die erste gültige Position nach der Lücke („neue Position")

x₀ = x(t₀)	alte Position zum Zeitpunkt t_o
x₁ = x(t₁)	alte Position zum Zeitpunkt t₁
x_m-1 = x(t_m-1)	alte Position zum Zeitpunkt t_m-1
x_m+nhole = x(t_m+nhole)	neue Position zum Zeitpunkt t_m+nhole

Der zwischen diesen Punkten verstrichene Zeitraum (normalerweise ungefähr eine Sekunde) wird ermittelt, und der GPS-Empfänger wird entsprechend angepasst. Die erste gültige Position nach der Lücke xm+nhole befindet sich genau (nhole+1) Zeitsegmente nach der letzten Position vor der Lücke xm-1.
2.2.2-3: Polynomische, nach hinten gerichtete Annäherung
Die erste nach hinten gerichtete, angenäherte Position der Lücke x1 kann unter Verwendung der polynomischen Formulierung x = a + at + a2t2 + a3t3 + ... + amtm berechnet werden.
Die Koeffizienten a₀, a₁, a₂, ... a_m werden unter Verwendung der gültigen Positionen
berechnet.
Durch Vervollständigung der folgenden Formulierung können alle nach hinten gerichteten, angenäherten Positionen der Lücke xm, xm+1, xm+2 ... xm+nhole-1 zu den Zeitpunkten tm, tm+1, tm+2 ... tm+nhole-1 ermittelt werden: xi = a0 + a1ti + a2ti 2 + a3ti 3 + ... + amti m mit i = m, m+1, ..., m+nhole-1
2.2.2.4 Basisfunktion Weglänge
Die Basisfunktion Weglänge enthält Funktionen, die ähnlich der des Meilenindikators des Fahrzeugs sind. Es fordert GPS-Datensätze von der Basisfunktion GPS-Basisdaten an und wendet für die Berechnung von Entfernungen die Basisfunktion Geometrie an.
Entfernungen zwischen Positionen werden unter Verwendung von Breiten- und Längenkoordinaten der Messpunkte berechnet. Die Weglänge ist die Summe der Entfernungen zwischen einzelnen Positionen (Antennenverbindung). Die Grundfunktion enthält beide Variationen der Weglänge: Zuwachs und Verringerung.
Zuwachs bedeutet, dass das Weglängenmessinstrument vor dem Start auf null gestellt wird. Bei jeder neuen Position wird die Entfernung zur vorhergehenden Position (Antennenverbindung) berechnet und dann addiert. Wenn eine gewisse Markierung von der Anwendung ermittelt worden ist, wird die Anwendung informiert, wenn die Markierung erst einmal passiert worden ist. Zusätzlich kann die Anwendung jederzeit eine Instrumentenlesung anfordern.
Bei einem Zuwachs kann die Anwendung das Messinstrument unterbrechen, wenn es nicht länger benötigt wird. Nur dann kann das Messinstrument erneut in Betrieb genommen werden. Wenn das Messinstrument nicht unterbrochen worden ist, wird die Basisfunktion das Messinstrument dann deaktivieren, wenn sie eine gewisse maximale Lesung passiert hat.
Die Verringerung wird als ein Zuwachs mit negativen Werten verwirklicht. In diesem Fall ermittelt die Anwendung die zurückzulegende Weglänge als einen negativen Wert. Bei jeder neuen Position wird die Entfernung zur vorhergehenden Position zu diesem negativen Wert addiert. Wenn das Messinstrument die Markierung „0 Meter" erst einmal passiert, d. h. das Fahrzeug hat die definierte Weglänge zurückgelegt, wird eine Nachricht gesendet. Eine Anwendung kann gewisse Markierungen als negative Werte definieren, und sie wird in diesem Fall unterrichtet, wenn jene Markierung erst einmal überschritten ist. Darüber hinaus kann die Anwendung eine Weglängemessinstrumentenlesung jederzeit ausdrücklich anfragen.
Beispiel: Eine Anwendung fragt eine Nachricht an, wenn eine Weglänge von 2.000 m zurückgelegt worden ist. Zusätzliche Nachrichten müssen gesandt werden, wenn noch 200 m, 100 m und 50 m zurückzulegen sind. Zu diesem Zweck muss die Anwendung die gesamte Weglänge von –2.000 m sowie die Messinstrumentmarkierungen bei –200 m, –100 m und –50 m ermitteln. Die Grundfunktion wird dann die Anwendung über eine Messinstrumentenlesung bei –200 m, –100 m, 50 m und 0 m („zurückgelegte Weglänge") informieren. (0141)
Das Weglängenmessinstrument wird von der Basisfunktion automatisch unterbrochen, wenn erst einmal die Markierung „0 Meter" passiert wurde. Das Messinstrument kann vor diesem Punkt unterbrochen werden, wenn die Anwendung keine weiteren Informationen benötigt. Die Anwendung kann jedes Messinstrument allein oder alle Messinstrumente auf einmal unterbrechen.
Bei einem Ausfall der GPS-Daten wird die laufende Messinstrumentenlesung mit Hilfe der nach hinten gerichteten, berechneten Positionen während der Ausfallzeit berechnet. Wenn eine Markierung oder mehrere der Markierungen während des Signalausfalls überschritten worden ist/sind, wird die Anwendung mit der derzeitigen Messinstrumentenlesung eine Nachricht erhalten Wenn die gesamte Weglänge während des Ausfalls zurückgelegt worden ist, wird das Messinstrument – bei der Berechnung der Weglänge unter Verwendung der während des Ausfalls angefallenen Positionen- weiterhin nach dem Überschreiten der Markierung „0 Meter" bis zur laufenden Messinstrumentenlesung einen Zuwachs messen (z. B. „+200 m" für „die ganze Weglänge plus zusätzlich zurückgelegte 200 m"). Die Grundfunktion wird die Anwendung über diese Messinstrumentenlesung unterrichten und das Messinstrument dann unterbrechen.
Jede Anwendung kann mehrere Weglängenmessinstrumente gleichzeitig initialisieren, denen sie logische IDs zuweisen muss. Die Basisfunktion Weglänge wird in der Lage sein zu erkennen, welches Messinstrument zu welcher Anwendung gehört.
Zusätzlich zu den Weglängenmessinstrumenten, die von der Anwendung initialisiert und unterbrochen werden können, wird ein globales Weglängenmessinstrument eingesetzt werden, das Zuwächse in Segmenten von je einem Meter misst. Dies wird initialisiert werden, wenn das Basis-Endgerät mit einem auf 0 Meter eingestellten Wert in Betrieb genommen wird, und es wird während gesamten Betriebszeit aktiv bleiben. Wenn das Endgerät abgeschaltet und wieder eingeschaltet wird, bleibt die Messinstrumentenlesung gleich. Weder das Basisendgerät noch die Anwendungen können dieses Weglängenmessinstrument stoppen oder zurückstellen. Die Anwendungen können eine laufende Messinstrumentenlesung des globalen Weglängenmessinstruments ausdrücklich anfordern.
2.2.2.5 Basisfunktion Wegpunkt
Die Basisfunktion Wegpunkt berechnet die Entfernung zwischen dem Fahrzeug und einem gewissen Wegpunkt, der von einer Anwendung ermittelt worden ist. Jeder Wegpunkt ist ein Bereich mit einer begrenzten Ausdehnung (Kreis oder Rechteck). Die Größe des Wegpunkts kann einen Meter oder mehrere hundert Meter betragen. Die Anwendung wird unterrichtet werden, wenn das Fahrzeug diesen Bereich erreicht oder verlässt und wenn es die CENTER-Linie passiert (normale bis bevorzugte Richtung durch das Zentrum des Wegpunktes).
Die Basisfunktion Wegpunkt verwendet die GPS-Positionsdaten, die von der Basisfunktion GPS-Basisdaten bereitgestellt wurden. Die erforderlichen Entfernungsberechnungen können unter Verwendung der Basisfunktion Geometrie durchgeführt werden.
Die erste Variante des Wegpunkts, die die Verkehrstelematikanwendung ermittelt, wird durch Festsetzen eines Center-Punktes und eines Radius definiert. Die zweite Variante ist ein Rechteck, das durch die Anwendung durch Festsetzen des Center-Punktes sowie durch die Länge und die Breite definiert wird. Der Kreis oder das Rechteck wird durch den Hysteresebereich eingerahmt, um zu verhindern, dass eine Nachricht über unbedeutende Positionsänderungen (z. B. Strömungsschleifen) freigegeben wird. Der Hysteresebereich wird von der Anwendung ermittelt.
Darüber hinaus definiert die Anwendung eine bevorzugte Richtung und einen Öffnungswinkel. Anwendungen, die eine bevorzugte Richtung nicht ermitteln möchten, können den Öffnungswinkel bei 360 Grad festlegen. Wenn der Wegpunkt als ein Rechteck definiert wird, wird die Längsachse des Rechtecks mit der bevorzugten Richtung ausgerichtet (siehe 2.2.2-4 und 2.2.2-5).
2.2.2-4: Wegpunktgeometrie bei einem Kreis
2.2.2-5: Wegpunktgeometrie bei einem Rechteck
Für jede laufende Position berechnet die Basisfunktion die Entfernung zum Zentrum des Wegpunkts und vergleicht dies mit der Ausdehnung des Wegpunkts.
Wenn das Fahrzeug den inneren Bereich erreicht, wird die Nachricht „Status IN" gesendet (siehe 2.2.2-6 und 2.2.2-7). In dem Fall, dass eine Position momentan zum Hysteresebereich wechselt (d. h. als Ergebnis von Strömungsschleifen) und dann zurück zum inneren Bereich, wird keine Nachricht „Status IN" gesendet.
Wenn das Fahrzeug die CENTER-Linie kreuzt (normale bis bevorzugte Richtung durch das Zentrum), wird die Nachricht „Status CENTER" erzeugt (siehe 2.2.2-6 und 2.2.2-7). Darüber hinaus wird die Anwendung informiert, ob die Richtung des Fahrzeugs innerhalb des Öffnungskegels der bevorzugten Richtung bleibt. Die augenblickliche Richtung wird ebenfalls erscheinen.
Wenn ein Fahrzeug den Hysteresebereich verlässt, wird die Nachricht „Status OUT" freigegeben (siehe 2.2.2-6 und 2.2.2-7). Falls der Wegpunkt durch die Anwendung mittels Versenden einer entsprechenden Nachricht deaktiviert wird, bleibt der Wegpunkt noch aktiv, d. h. wenn das Fahrzeug den Wegpunkt erneut erreicht, wird das oben beschriebene Verfahren wiederholt.
Die Wegpunktbeobachtung wird sowohl bei gültigen Positionen als auch bei angenäherten Positionen (nach vorne und nach hinten gerichtet) durchgeführt. Die Anwendung wird unterrichtet – bei Ankunft an (IN-Nachricht), Kreuzen (CENTER-Nachricht) und beim Verlassen eines Wegpunkts-, auf welcher Art von GPS-Positionen (TOP-Wert TOP (x), TOP (y)) die Berechnung basiert.
Insbesondere wird die Anwendung herausfinden, ob die Berechnung auf derzeit gemessenen oder angenäherten Positionen basiert.
Wenn das Fahrzeug an einem Wegpunkt ankommt und/oder die CENTER-Linie kreuzt und/oder den Wegpunkt verlässt, wird die Anwendung hierüber mittels einer entsprechenden Nachricht später unterrichtet.
Alle drei Nachrichten („IN", „CENTER" und „OUT") werden der Anwendung ebenfalls den Zeitstempel der GPS-Position mitteilen, die die Mitteilung auslöste, sowie die Entfernung der Position zu der CENTER-Linie. Diese bringt die Nachrichten in einen zeitlichen und räumlichen Zusammenhang, der im Falle von nach vorne und nach hinten gerichteten, angenäherten Positionen von besonderer Bedeutung ist. Wenn ein Situation eintritt, wobei während der verspäteten Wegpunktberechnung mit nach hinten gerichteten, angenäherten Positionen die Nachrichten „IN" und „CENTER" oder „IN", „CENTER" und „OUT" gleichzeitig berichtet werden, werden weitere Informationen bereitgestellt, d. h. der TOP-Wert, der linear angenäherte Zeitpunkt, die Richtung und die Entfernung der GPS-Position, die die CENTER-Nachricht an die CENTER-Linie auslöste.
Es wird keine Nachricht geben, wenn das Fahrzeug lediglich den Hysteresebereich überquert.
2.2.2-6: Beispiel für ein einen Kreis überquerendes Fahrzeug:

Punkt 1: Fahrzeug kommt am inneren Bereich an, Nachricht „Status IN"
Punkt 2: Fahrzeug überquert die normale bis bevorzugte Richtung, Nachricht „Status Center" und „Richtung innerhalb des Öffnungskegels der bevorzugten Richtung".
Punkt 3: Fahrzeug verlässt Hysteresebereich, Nachricht „Status OUT"

2.2.2-7: Beispiel für ein Rechteck überquerendes Fahrzeug

Punkt 1: Fahrzeug kommt am inneren Bereich an, Nachricht „Status IN"
Punkt 2: Fahrzeug überquert die normale bis bevorzugte Richtung, Nachricht „Status Center" und „Richtung innerhalb des Öffnungskegels der bevorzugten Richtung"
Punkt 3: Fahrzeug verlässt den Hysteresebereich, Nachricht „Status OUT".

Die IN-Nachricht wird erzeugt, wenn ein Wegpunkt aktiviert wird und die laufende GPS-Position anzeigt, dass sich das Fahrzeug innerhalb des Wegpunkts befindet.
Jede Anwendung kann mehrere Wegpunkte ermitteln (denen sie logische IDs zuweisen muss), die von der Basisfunktion gleichzeitig verarbeitet werden können. Die Basisfunktion erkennt, welcher Wegpunkt zu welcher Anwendung gehört. Die Anwendung kann jeden Wegpunkt einzeln oder alle Wegpunkte auf einmal deaktivieren.
Eine Anwendung ist in der Lage, Wegpunkte einzurichten, die automatisch aktiviert werden, selbst wenn das System abgeschaltet und erneut initialisiert wird. Dies kann für eine potentielle Anwendung „Aufzeichnen von Verkehrsdaten" nützlich sein.
2.2.3 Basisfunktionen des Zwischensystems Zugangssteuerung
Die TT-Chipkarte führt mehrere wichtige Aufgaben durch, um den reibungslosen Betrieb des Verkehrstelematiksystems im ganzen zu garantieren. Diese Aufgaben beinhalten die Freigabe neuer Verkehrstelematik-Services, Prüfung der Authentität eines Teilnehmers, das Sichern des Kommunikationsweges zwischen dem Basis-Endgerät und dem Center und Erhebung von Gebühren über ein lokales „elektronisches Portemonnaie".
Die Zwischensystemzugangssteuerung (Chipkarten-Schnittstellen-Modul (CIM)) kann von den Anwendungen mittels der folgenden Basisfunktionen angesprochen werden:

1. Öffnen einer Chipkartenanwendung
2. transparenter Befehls- und Datentransfer
3. Schließen einer Chipkartenanwendung

Die Basisfunktionen beinhalten keine zusätzlichen Funktionen wie das Aktivieren und Deaktivieren der Chipkarte.
Die oben aufgeführten Basisfunktionen ermöglichen eine Kommunikation zwischen den sich im Endgerät befindenden Anwendungen und dem Chip-Karten-Schnittstellen-Modul (CIM), ohne dass die Anwendungen das Betriebssystem der Chipkarte wissen müssen. Daraus folgt einerseits, dass verschiedene Anwendungen ihre eigene, besonders entwickelte Chipkarte verwenden können. Andererseits ist es möglich, eine multifunktionelle Intra GSM-Chipkarte anzuwenden, die den Zugang zu zahlreichen Verkehrstelematikanwendungen ermöglicht.
Das Chipkarten-Schnittstellen-Modul kann prinzipiell von mehreren Anwendungen gleichzeitig angewendet werden.
2.2.3.1 Öffnen einer Chipkartenanwendung
Um eine Chipkartenanwendung im CIM zu öffnen, benötigt diese Basisfunktion einen Anwendungsidentifizierer (aid). Wenn diese Chipkartenanwendung bereits geöffnet worden ist oder wenn keine solche Anwendung existiert, wird eine Fehlermeldung erzeugt. Dies geschieht ebenfalls, wenn die Chipkarte nicht eingesteckt worden ist.
2.2.3.2 Schließen einer Chipkartenanwendung
Mit Hilfe dieser Basisfunktion kann eine Chipkartenanwendung geschlossen werden. Das Ausführen dieser Funktion hat denselben Effekt wie die Rückstellung der Karte, d. h. alle Zugangsbedingungen (z. B. „eine externe Authentifikation wird durchgeführt") werden zurückgesetzt. Darüber hinaus wird die Anwendung der CIM nicht mehr verwaltet.
2.2.3.3 Transparenter Befehls- und Datentransfer
Mittels dieser Basisfunktion werden Chipkartenbefehle (abhängig vom Betriebssystem der Chipkarte) und Daten über das Chipkarten-Schnittstellen-Modul zur Chipkarte transparent transferiert, und die angefragten Daten werden von der Chipkarte abgelesen und an die Anwendung weitergegeben, d. h. das CIM arbeitet lediglich als Protokoll-Browser.
Unerwartete Vorkommnisse, so wie das Entfernen der Chipkarte während einer Anwendung, werden durch Status-Nachrichten angezeigt. Informationen über den Status des CIM können jederzeit angefordert werden (selbst wenn keine Chipkartenanwendung in Betrieb ist).
2.2.4 Basisfunktionen des Zwischensystems Input/Output
Input-/Output-Funktionen werden benötigt, um das Basis-Endgerät zu betreiben. Diese sind sowohl für die Gewinnung des Zugangs zu den Verkehrstelematikanwendungen als auch für die Verwaltung des Basis-Endgeräts notwendig. Es wird empfohlen, dass die Anzahl der Input-/Output-Geräte auf einem Minimum gehalten werden. Darüber hinaus muss es möglich sein, zusätzliche Input-/Outputvorrichtungen zu implementieren, was von den Anforderungen der einzelnen Anwendungen abhängt. Solche internen Input-/Outputvorrichtungen können über das SCI verbunden und sowohl von internen als auch von externen Anwendungen angewendet werden.
Darüber hinaus ist es wünschenswert, dass bereits bestehende Input-/Outputgeräte innerhalb des Fahrzeugs ebenfalls angewendet werden können. Zum Beispiel wird es möglich sein, einen durch RDS gestützten Funk oder irgendwelche anderen fahrzeugspezifischen Lösungen wie eine Input-/Outputvorrichtung zu verwenden. Diese Vorrichtungen werden auch über das SCI mittels API-Funktionsbefehlen gesteuert. Die verfügbaren Input-/Outputvorrichtungen müssen den Anforderungen der Anwendung hinsichtlich Funktionalität, Ergonomie und Geeignetheit für die Verwendung entsprechen, um einen reibungslosen Betrieb der Anwendung zu garantieren.
Einzelne Komponenten des Basisendgeräts können bereits eine Möglichkeit für Input und Output besitzen, z. B. ein GSM-Handy kann im Endgerät implementiert sein. Es ist wünschenswert, diese Module als Input-/Outputgerät zu verwenden. Offensichtlich wird es beim Betrieb wegen der physischen Aktualität der Vorrichtung, des Einbauplatzes und der Nutzerergonomie Einschränkungen geben.
Technische Daten werden bereitgestellt werden müssen, so dass die verschiedenen Anwendungen Zugang zu mehreren Input-/Outputgeräten bekommen können. Daran liegt es, dass Input-/Output-Funktionen in den Basisfunktionen kombiniert sind und den Anwendungen über API zur Verfügung gestellt werden. Daher können interne und externe Verkehrstelematikanwendungen sowohl im Endgerät integrierte als auch externe Input-/Outputgeräte anwenden.
Dem/der Anwender/in werden zwei Funktionen zur Verfügung stehen: Einerseits die Output-Funktion, die die Darstellung von Informationen auf einem Displaygerät ermöglichen (Schirm, Licht, Lautsprecher), und andererseits die Input-Funktion, die den Eintrag von Daten über ein Inputgerät unterstützt (Tastatur, Pfeiltasten, Steuerknopf). Ein Übersetzer greift ein, um eine zusammengeschlossene Ansprache des Geräts zu garantieren, selbst wenn einige der Input-/Outputgeräte zweckdienlicher als die anderen sind. Die Architektur des Zwischensystems Input/Output, das aus einem Input-/Outputgerät und einem Übersetzer besteht, ist in der 2.2.4-1 gezeigt.
2.2.4-1: Bockschaltabbildung (bock switching ???) (Anm. d. Übs.: muss wahrscheinlich „Blockschaltabbildung" heißen) des Zwischensystems Input/Output mit Übersetzer
2.2.4-2: Mögliche Verwirklichung des Input-/Outputgeräts
So wie in der 2.2.4-2 gezeigt, kann das Input-/Outputgerät aus verschiedenen Displayelementen, Lautsprechern usw. bestehen, wobei alle unter Verwendung von API-Befehlen zugänglich sind.
Ein oder mehrere Input-/Outputgeräte können von den Basisfunktionen oder durch die Anwendungen entweder direkt oder über das SCI gesteuert werden.
Die funktionelle Architektur des Input-/Output-Zwischensystems ist in der 2.2.4-2 gezeigt.
2.2.4-3: Funktionelle Architektur des Zwischensystems Input/Output
Zwei Basisfunktionen sind im Zwischensystem Input/Output inkorporiert („Display-Informationen" und „Input-Empfang"). Diese können verwendet werden, um Zugang zur Input-/Output-Vorrichtung zu bekommen (siehe 2.2.4-3).
2.2.4.1 Basisfunktion „Display Information" (Informationen darstellen)
Jede Verkehrstelematikanwendung hat verschiedene Anforderungen hinsichtlich der Darstellung von Informationen. Diese beinhalten die Darstellung von Diagrammen, Texten und Symbolen, manchmal in Verbindung mit akustischen Signalen und Informationen. Abhängig von den Anforderungen der Anwendungen muss es möglich sein, Output-Vorrichtungen in Form von einfachen Leitungsdisplays, graphischen Displays und Displays von externen Ausrüstungen zu verwenden (wie von RDS gestützter Funk, Messinstrumente usw.). Es ist daher ein universelle Lösung gefordert, um die Darstellung von Informationen mittels verschiedener Arten von Displays zu ermöglichen. Zu diesem Zweck wird ein Satz verschiedener Informationstypen definiert werden.
Wenn eine Information auf einem Display erscheinen muss, wird der Übersetzer über die Art der Information und über die Daten, die darzustellen sind, unterrichtet. Der Übersetzer entscheidet dann, welches Format verwendet werden wird, um die Informationen auf einem Display darzustellen.
Darüber hinaus können Informationen in Bändern (strings) dargestellt werden, um künftigen Anwendungen den Zugang zum Display zu ermöglichen, das nicht zu dem Zeitpunkt berücksichtigt werden kann, zu dem der Übersetzer entwickelt wird. Es muss berücksichtigt werden, dass – als Minimalanforderungein Leitungsdisplay mit acht Leitungen (z. B. durch RDS gestützter Funk) implementiert werden muss. Das darzustellende Band muss aus einem Format von 8 Schriftzeichen für das statische Display bestehen. Ein Header wird vor dem Band platziert, der von der Anwendung verwendet werden kann, um das Input-/Outputgerät über dessen Formatierungsanforderungen zu informieren. Wieder wird der Übersetzer des Displays über das Format der Darstellung für das Band entscheiden. Für die Darstellung von längeren Bändern stellt der Übersetzer eine „running text function" (Funktion für laufenden Text) bereit; diese Funktion muss vom Display gestützt werden („soft scrolling").
Wenn eine Anwendung Informationen auf dem Display des Input-/Outputgeräts darstellen möchte, wird sie diese Informationen zum Zwischensystem Input/Output transferieren. Zwei Zeitgeber werden dieser Nachricht hinzugefügt werden: Der erste Zeitgeber zeigt an, wie lange die Informationen auf dem Display darzustellen angenommen werden (t_dur); der zweite Zeitgeber ermittelt den maximalen Zeitraum, nach dem ... (Anm. d. Übs.: Rest des Satzes unverständlich.) (t_queue).
Das Zwischensystem Input/Output bestätigt den Erhalt der Nachricht. Wenn das erforderliche Display verfügbar ist und wenn die Informationen für eine gewisse Zeit t_dur auf dem Display erscheinen können, wird das Zwischensystem Input/Output den Abschluss der Displayanfrage bestätigen.
Da mehrere Anwendungen (z. B. interne/externe Anwendungen, periphere Ausrüstungen und Anwenderanweisungen, falls ein durch RDS unterstützter Funk als Input-Vorrichtung verwendet wird) zum selben Display Zugang haben, muss es möglich sein, dringenderen Nachrichten Vorrang einzuräumen. Daher werden variable Prioritäten den verschiedenen Arten von Informationen zugeordnet, die sich entsprechend des derzeitigen Status des Displays ändern können.
Eine Information mit geringer Priorität kann ein Display mit höherer Priorität nicht unterbrechen. In diesem Fall wartet die Information mit geringer Priorität in der Warteschlange. Wenn das Display innerhalb des maximalen Zeitraums t_queue verfügbar wird, der dem Display für Informationen mit geringer Priorität zugestanden ist, wird die Information auf dem Display erscheinen; andernfalls wird die Information zurückgewiesen, und eine entsprechende Nachricht wird an die Anwendung gesendet. Die Anwendung entscheidet dann, ob es ihre Anfrage hinsichtlich des Erscheinens der Information auf dem Display erneuern möchte. In diesem Fall muss die Anwendung die jüngste Nachricht, die sie auf dem Display darstellen möchte, speichern.
Eine Information mit hoher Priorität kann ein laufendes Display mit geringer Priorität unterbrechen, und sie wird sofort auf dem Display erscheinen. Die Information mit geringer Priorität wartet wiederum in der Warteschlange. Wenn das Display betreffend der Information mit hoher Priorität zum Abschluss gekommen ist, wird die unterbrochene Information erneut gespeichert, vorausgesetzt, dass der maximale Zeitraum t_queue, der dem Display für die Information mit geringer Priorität zugestanden wurde, nicht überschritten worden ist. Andernfalls wird das unterbrochene Display nicht erneut gespeichert, und die Anwendung wird hiervon unterrichtet werden. Wiederum kann die Anwendung ihre Anfrage erneuern, um die Information auf dem Display erscheinen zu lassen, wenn sie sich so entscheidet.
Wenn ein Display unterbrochen werden muss, muss es noch sicherstellen, dass die Information über einen gewissen Minimalzeitraum hinweg erscheint. Die genaue Folge von Ereignissen (events) wird in Kapitel 32.6 unten beschrieben.
2.2.4.2 Basisfunktion „receive input" (Eingabe empfangen)
Auch die Input-Funktion kann mit Hilfe eines Übersetzers universal verwendet werden, weil verschiedene Varianten von Betriebselementen implementiert worden sind. Beim Medium Display muss zwischen Input-Vorrichtungen, die den Minimalanforderungen entsprechen, und jenen unterschieden werden, die eine optimale Unterstützung für komplexe Anwendungen bereitstellen. Die Minimalanforderungen für eine interaktive Operation des Input-/Outputgeräts, wobei mindestens Nummern und Buchstaben eingegeben werden können, müssen zu einem späteren Zeitpunkt definiert werden.
Input-Vorrichtungen sind aus zwei Gründen notwendig. Erstens: Anwendungen brauchen Inputs vom Nutzer. In diesem Fall bittet die Anwendung den Nutzer (über das Medium Display oder akustisch), Informationen einzugeben. Zweitens: Der Nutzer kann die Initiative ergreifen (z. B. Wahl der Menüführung), die das Zwischensystem Input/Output an die entsprechende Anwendung weitergibt.
Ist die Anwendung vom Nutzer gefragt worden, kann das Zwischensystem Input/Output sagen, wohin die Informationen von der Adresse des Senders aus transferiert werden sollen. Hat der Nutzer den Input initiiert, können die Informationen lediglich an jene Anwendungen gesendet werden, die dem Übersetzer bekannt sind (durch Definition oder weil die Anwendung registriert worden ist). Abhängig von der Verfügbarkeit von Input-/Outputgeräten stellt das Zwischensystem Input/Output für Inputs, die vom Nutzer initiiert wurden, eine geeignete Nutzerführung bereit; es steuert ebenfalls Nutzeranfragen und folgt Nutzerbefehlen. Abhängig davon, wie die Vorrichtungen gegenwärtig implementiert wurden, wird der Nutzer in der Lage sein, alle verfügbaren Anwendungen auf dem Display zu sehen, bevor er sich für ein Menü entscheidet.
Wenn eine Anwendung die Nachricht „Menü" erhält, wird sie alle Menüteile ihres Hauptmenüs (wenn verfügbar) an das Zwischensystem Input/Output transferieren. Dieses Verfahren ist notwendig, weil andernfalls eine Auswahl an Menüteilen auf einem größeren Display nicht zweckdienlich dargestellt werden kann. Wie die anderen Input-Anfragen werden die Menüteile als definierte Informationstypen transferiert werden. Darüber hinaus ist es möglich, ein oder mehrere Menüteile als eine Folge von ASCII-Schriftzeichen zu transferieren. Die Anwendung transferiert dann alle Menüteile des Untermenüs (wenn verfügbar) an das Zwischensystem Input/Output. Dieses Verfahren wird fortgesetzt, bis der Nutzer die niedrigste Menü-Ebene erreicht, sich für ein Menü-Teil entschieden oder die Menü-Führung aufgerufen hat.
Wenn eine Anwendung den Nutzer fragen möchte, einen Input zu tätigen, muss er das Medium Input in Anspruch nehmen. Wenn das Medium verfügbar ist und nicht von einer anderen Anwendung bereits beansprucht worden ist, wird es vom Zwischensystem Input/Output namens der Anwendung beansprucht, die die Anfrage macht, d. h. es steht nicht mehr für Input-Anfragen anderer Anwendungen zur Verfügung. Die Anwendung sendet dann eine Input-Anfrage an das Zwischensystem Input/Output, was dem Nutzer entweder optisch oder akustisch angezeigt wird. Die Dateneingabe durch den Nutzer wird an die Anwendung transferiert. Wenn die Interaktion zwischen dem Nutzer und der Anwendung erst einmal abgeschlossen ist, wird das Medium Input von der Anwendung freigegeben.
Eine Situation kann auftreten, bei der das Medium Input bereits entweder von einer Anwendung, die um eine Eingabe anfragt, oder von einem Nutzer, der eine Eingabe initiiert, beansprucht wurde. Alle Input-Anfragen haben dieselbe Mediumpriorität, d. h. eine Input-Anfrage kann von einer anderen nicht unterbrochen werden. Wenn das Medium Input beansprucht ist, erhält die Anwendung eine negative Nachricht. Es liegt dann an der Anwendung, die Input-Anfrage zu einem späteren Zeitpunkt zu wiederholen.
Input-Anfragen können durch Output-Anfragen mit höherer Priorität unterbrochen werden. Wenn dies geschieht, obliegt es der Verantwortung des Zwischensystems Input/Output, die Input-Anfrage und die Informationen, die der Nutzer bis zu jenem Punkt eingegeben hat, für die Dauer der Unterbrechung zu speichern. Wenn sich die Priorität der Output-Anfrage ändert und unter jene der Input-Anfrage fällt, wird die gespeicherte Input-Anfrage erneut dargestellt. Input- und Output-Anfragen werden unterschiedlich behandelt, weil es wichtig ist, dass das Input-Verfahren unterbrochen werden kann, wenn Informationen mit hoher Priorität auf dem Display erscheinen müssen (z. B. eingehende Verkehrsdaten), während Unterbrechungen bei Input-Anfragen den Nutzer nur durcheinander bringen würden.
Es ist wiederum wichtig sicherzustellen, dass -selbst im Falle von Unterbrechungen- die Informationen über einen gewissen Minimalzeitraum auf dem Display erscheinen. Darüber hinaus muss jede Änderung von Informationen, die auf dem Display erscheinen, ergonomisch sensibel und für den Nutzer leicht erkennbar sein.
Die genaue Folge von Ereignissen (events) ist in Kapitel 3.2.6 unten beschrieben.
2.2.5 Allgemeine Funktionen Wegsuche- + Systemsteuerung
2.2.5.1 Wegsuche
Die Wegsuche ist eine zentrale Funktion des Basis-Endgeräts. Es verbindet das AFI-Schnittstelle mit den Basisfunktionen. Es führt die Aufgaben der Verteilung von Informationen in folgenden Richtungen durch:

– von Anwendungen zu Basisfunktionen;
– von Basisfunktionen zu Anwendungen;
– zwischen Anwendungen;
– zwischen Basisfunktionen.

Die verschiedenen Anwendungen haben gemeinsam Zugang zu den Basisfunktionen, und deshalb muss der Zugang zu den Basisfunktionen koordiniert werden.
Wegsuche von Anwendungs-Services zu Basisfunktionen
Alle Nachrichten von Anwendungs-Services werden an die entsprechenden Basisfunktionen weitergegeben. Die Adresse der Basisfunktion befindet sich im Header des Telegramms, die über die API-Schnittstelle (siehe Kapitel 3.2.1) weitergegeben wird.
Wenn eine Anwendung versucht, Zugang zu einer fehlerhaften Komponente des Endgeräts zu bekommen, wird sie eine Fehlermeldung erhalten, die von der Systemsteuerung herausgegeben wurde.
Wegsuche von Basisfunktionen zu Anwendungs-Services
Informationen, die von den Basisfunktionen zu den Anwendungs-Services transferiert werden müssen, enthalten:

– von den Basisfunktionen selbst erzeugte Informationen;
– von externen Centern eingehende Informationen (bei der Zwischensystemkommunikation);
– vom Nutzer eingegebene oder von der Anwendung initiierte Daten (im Zwischensystem Input/Output).

Die Wegsuche wird mittels einer internen Zuordnung von Adressen durchgeführt; ihre Funktion ist, in dem Superrahmen einer Nachricht enthaltene Ursprungs- und Zieladressen zu analysieren und weiterzugeben (siehe Kapitel 3.2.1).
Wenn die Wegsuchefunktion eine Nachricht von einem Service-Center über ein GSM-Modul erhält, muss sie den Anwendungs-Service-Identifizierer (ASI), der in der Nachricht enthalten ist, analysieren (die ASI ist für alle Service-Center und Endgeräteanwendungen dieselbe) und die entsprechende Zieladresse im Endgerät ermitteln, um die Nachricht weiterzugeben. Falls eine Nachricht von einer Endgerätanwendung zu einem Service-Center transferiert wird, ist das Verfahren gleich, d. h. die in der ASI enthaltene Nachricht muss analysiert werden, um die Nachricht an das richtige Center weiterzugeben.
Wegsuche zwischen Anwendungen
Wenn der Header des Rahmens, der über die API-Schnittstelle empfangen wurde, die Adresse eines Anwendungsidientifizierers enthält, wird die Nachricht zu der angesprochenen Anwendung transferiert. In diesem Fall wird die Grundfunktion nicht angesprochen werden.
Wegsuche zwischen Basisfunktionen
Grundsätzlich ist es möglich, Nachrichten zwischen Basisfunktionen auszutauschen. Beispielsweise können Statusinformationen hinsichtlich des GSM-Moduls (z. B. Signalstärke) direkt an das Zwischensystem Input/Output transferiert werden.
2.2.5.2 Systemsteuerung
Um das Basis-Endgerät zu betreiben, sind Funktionen notwendig, die unabhängig von den Verkehrstelematikanwendungen arbeiten. Diese Funktionen sind:

– Initialisierung des Systems;
– Initialisierung und Steuerung von Anwendungen;
– Führung und Steuerung des Status (Hardware und Software);
– "Built-in" (installiert) in Test und Diagnose;
– Energie-Management (Warmstart, Kaltstart, Runterfahren der Energie, Notabschaltung);
– Software-Versionen-Management;
– Fehler-Management.

Die Mehrheit der Funktionen wird vom Hersteller in Übereinstimmung mit der Struktur des Endgeräts implementiert werden. Die Basisfunktionen für diesen Komplex an Funktionen müssen noch im Detail beschrieben werden.
Fehler-Management
Das Fehler-Management umfasst alle Maßnahmen, die getroffen werden, um Fehler zu erkennen, aufzuzeichnen und zu berichtigen und um den Nutzer zu unterrichten. Es enthält die Statusanfrage und die Statussteuerung von Hardware, Basisfunktionen und Anwendungen. Wenn erst einmal Fehler erkannt worden sind, werden, wenn dies möglich ist, Maßnahmen getroffen, um sie zu berichtigen (z. B. Rückstellung und Neustart).
Die Überwachungseinheit (watch-dog) überwacht alle Anwendungen, die registriert worden sind, und sie stellt sie zurück, wenn dies notwendig ist.
Aufbewahrung eines Fehlerprotokolls
Eine Basisfunktion muss implementiert werden, um Fehler aufzuzeichnen, die im Basis-Endgerät auftreten.
Wenn ein Fehler entdeckt worden ist, wird die Basisfunktion unterrichtet. Wenn die Basisfunktion angesprochen wird, werden Parameter transferiert, die im Fehlerprotokoll vermerkt werden.
Mögliche Parameter sind

– Zeitstempel;
– Fehlercode;
– Fehlerklassifizierung;
– fehlerhafte Komponente (Hardware-Gerät, Software-Modul) und
– durchgeführte Maßnahmen, um Fehler zu beheben.

Das Fehler-Logbuch kann von einem Servicepunkt gelesen werden. Daten werden über die SCI (Standard-Kommunikations-Interface) transferiert.
Die Mechanismen und Parameter des Fehlerprotokolls sind noch festzulegen.
2.2.6 Prioritätsmanagement
Das Prioritätsmanagement wird erforderlich, wann immer mehr als eine Anwendung Zugang zur selben Quelle benötigt. Neben den internen Quellen des Systems wie Speicher und Rechenzeit brauchen die Anwendungen ebenfalls Zugang zu den Basisfunktionen. Das Management der internen Quellen übernimmt das Betriebssystem und wird deshalb in dieser Spezifikation nicht weiter erörtert werden.
Das Konzept dieses Systems basiert auf der Voraussetzung, dass Anwendungen unabhängigen Zugang zu den Basisfunktionen haben sollten und dass mehrere Anwendungen in der Lage sein sollten, diese Funktionen gleichzeitig zu nutzen. Gewissen Anforderungen muss entsprochen werden, um ein solches System zu schaffen (z. B. Systeme und Anwendungen, die verschiedene Aufgaben bewältigen).
Das Prioritätsmanagement garantiert, dass – im Falle hoher Priorität- die Basisfunktion, die nach bestehenden Zuordnungen zu Quellen innerhalb des Systems verlangt, angepasst werden kann, um den Anforderungen der augenblicklichen Situation zu entsprechen.
Basisfunktionen, die den Zugang zu Quellen regeln, werden dem Prioritätsmanagement unterworfen. Die zu berücksichtigenden Quellen sind

– Zwischensystem Kommunikation,
– Zwischensystem Zugangssteuerung,
– Zwischensystem Input/Output,
– Standard-Kommunikations-Schnittstelle (SCI).

Die Zwischensystem Ortsbestimmung ist nicht Gegenstand des Prioritätsmanagements.
Das Prioritätsmanagement kann entweder für jede Quelle einzeln oder für alle Basisfunktionsanfragen zusammen zentral implementiert werden, wobei dies von Faktoren wie Software-Konstruktion und -herstellung, Betriebssystem abhängt. Dies kann und sollte jedoch an diesem Punkt nicht spezifiziert werden. Es sind Regelungen aufzustellen, um sicherzustellen, dass es nur gewissen Anwendungen mit hoher Priorität zu arbeiten ermöglicht wird.
Darüber hinaus müssen Anwendungen, die über die SCI verbunden sind, diesen Regelungen ebenfalls folgen.
3 Anwendungs-Programmierungs-Schnitstelle (API)
3.1 Überblick
Die Anwendungs-Programmierungs-Schnittstelle (API) ist eine offene Schnittstelle, zugänglich und nützlich für jeden Provider, der der API-Spezifikation entspricht. Die API ermöglicht die Implementierung von heutigen und künftigen Anwendungen. Anwendungen können herstellerspezifisch als Teil der IntraGSM-Basisvorrichtung integriert werden, um eine kosteneffiziente Vorrichtung zu schaffen. Dennoch muss die Basisvorrichtung mit einer leistungsfähigen Schnittstelle, die den API-Spezifikationen entspricht, ausgestattet werden, um Anwendungen zu dienen, die von anderen Lieferanten hergestellt wurden. Die API unterstützt die folgenden Kommunikationsinteraktionen:

1. von den Zwischensystemen der Basisvorrichtung zu den Anwendungsmodulen;
2. von den Anwendungsmodulen zu den Zwischensystemen der Basisvorrichtung;
3. von den Service-Centern zu den Anwendungsmodulen (über das Zwischensystem Kommunikation);
4. von den Anwendungsmodulen zu den Service-Centern (über das Zwischensystem Kommunikation);
5. zwischen den Anwendungsmodulen desselben Herstellers sowie zwischen Anwendungsmodulen verschiedener Hersteller (d. h. der Wegpunkt-Algorithmus wird von den Anwendungsmodulen „dynamische Routenführung" und „Beschaffung von Daten eingesetzter Autos") gemeinsam genutzt.

Neben den Software-Schnittstellen wird eine universelle, kosteneffektive Hardware-Schnittstelle, die Standard-Kommunikations-Schnittstelle (SCI), spezifiziert. Die SCI erweitert die Möglichkeiten (für die Bearbeitung und Funktionen der Grundvorrichtungskonfiguration) durch Hinzufügung weiterer Services.
Die Basisfunktionen der verschiedenen Zwischensysteme werden durch API-Anrufe initialisiert, die in den folgenden Abschnitten als „Nachrichten" (messages) definiert sind. Diese Anrufe haben eine besondere Rahmenstruktur, die API-Telegrammstruktur (API Super Frame Structure) genannt wird.
3.1 API-Rahmenstruktur
Die Telegramme (super frames) werden für den Datenaustausch zwischen den Anwendungen und den Basisfunktionen und untereinander verwendet. Die Überrahmen enthalten die Nachrichten, die über die API transferiert werden müssen. Alle Superrahmen bestehen aus einem Header und einer Nachricht. Alle Rahmen haben dieselbe Header-Struktur, die entweder von einer Anwendung oder einer Basisfunktion erzeugt wurde. Jede Nachricht hat eine allgemeine Struktur mit einem Satz an Parametern, wobei dies von der Nachrichtenart abhängt.
3.2.1 Superrahmenstruktur
Allgemeine Struktur:

<SRC>, <DEST>, <TRANS_NO>, <PRIO>, <TIME>, <message>

Beschreibung:

<SRC>: der Identifizierer der Quelle des Superrahmens. Er benennt die Anwendung oder die Basisfunktion, die den Transfer des Superrahmens initiiert.
<DEST>: der Identifizierer des Ziels des Superrahmens. Er benennt die Anwendung oder die Basisfunktion, die den Superrahmen erhalten muss.
<TRANS_NO>: die Transaktionsnummer ist eine Serialnummer. Sie wird in Antworten zum einmaligen Bezug auf einen kürzlich empfangenen Befehl verwendet. Darüber hinaus ist es von Nutzen, wenn mehrere Anwendungen eine GSM-Verbindungsleitung (Mehrfachzugang) nutzen.
<PRIO>: der Prioritätsindikator in einem Superrahmen. Er muss vom Prioritätsmanagement analysiert werden, um bei gleichzeitigem Zugang zur selben Basisfunktion Konflikte zu lösen. Der Prioritätsindikator wird in Nachrichten von Basisfunktionen gegenüber Anwendungen nicht analysiert. Darüber hinaus wird er in Nachrichten nicht analysiert, die sich auf das Zwischensystem Ortsbestimmung beziehen.
<TIME>: ein Zeitstempel, der beispielsweise für die zeitabhängige Änderung der Prioritätsebene oder für die Funktion der Überwachungseinheit verwendet wird.
<message>: die Nachricht soll über die API transferiert und an der angesprochenen Anwendung oder Basisfunktion verarbeitet werden. Die Nachricht ist für jedes Modul individuell strukturiert und in separaten Abschnitten beschrieben.

Die Werte für die Superrahmen sind in der Anlage 4 definiert.
3.2.2 Allgemeine Struktur der Nachrichten
Die Nachrichten innerhalb der Superrahmen haben eine individuelle Struktur.
Im Allgemeinen existiert für jede Nachricht
ein Name
(z. B. „cim_data_transfer_req"),
eine Nachricht_id,
eine Liste von Parametern (optional).
Jeder Nachrichtenname hat ein charakteristisches Präfix:
gsm_ für GSM-bezogene Nachrichten,
gps_ für GPS-bezogene Nachrichten,
cim_ für Chipcard-Schnittstellen-Modul-bezogene Nachrichten,
io_ für Input-/Output-bezogene Nachrichten.
Jeder Nachrichtenname hat ein charakteristisches Präfix:
_req für requests (Anfragen),
_res für responses (Antworten) (d. h. Antworten auf eine Anfrage),
_con für confirmations (Bestätigungen) (z. B. als Zwischenantwort),
_ack für acknowledgement (Bestätigung) (wenn eine Anfrage erfolgte),
_ind für indications (Anzeigen) (d. h. spontane Ereignisanzeige),
_rej für rejects (Rückweisungen) (z. B. durch das Prioritätsmanagement)
Allgemeine Struktur der Nachricht:

<msg_id>, [<par_1, [<par_2>, ... [<par_n]]]

Beschreibung:

<msg_id>: der alleinige Identifizierer einer Nachricht. Es wird ein Byte-Wert vorgeschlagen.
<par_x>: der/die Parameter einer Nachricht; soviel wie nötig

3.2.3 Nachrichten, die sich auf das Zwischensystem Kommunikation beziehen
In den folgenden Abschnitten werden die Nachrichten beschrieben, die verwendet werden, um die GSM-bezogenen Basisfunktionen, die Antworten und die ungebetenen Anzeigen anzufragen, die von den Basisfunktionen erzeugt oder vom Anwendungs-Center empfangen wurden.
Es wird empfohlen, GSM-Vorrichtungen in Übereinstimmungen mit den Normen GSM 07.07 (2) und GSM 07.05 (3) zu verwenden.
Ein Satz an Befehlen, der den at-Befehlssatz verwendet, die in den GSM-Empfehlungen 07.05 und 07.07 beschrieben sind, kann an der API zugelassen werden, aber er ist hier nicht beschrieben, z. B. der Befehl +CPIN, der ein Passwort an das GSM-Modul sendet, weil in dieser Spezifikation auf solche Befehle nicht Bezug genommen wird.
Die GSM-Aktivitiäten kümmern sich um die Eingaben in das Kommunikations-Service-Verzeichnis, das vom Zwischensystem Kommunikation bereitgestellt wird. Das Service-Verzeichnis zeigt, welche Daten-Services augenblicklich verfügbar sind und welche von ihnen in der Kommunikationsvorrichtung implementiert sind.
Alle Nachrichten beinhalten das Präfix gsm_..., um anzuzeigen, dass die Nachrichtenparameter für die Verwendung der GSM-Kommunikation geeignet sind. Nachrichten für andere Kommunikationsvorrichtungen, so wie inmarsat oder mobitex müssen definiert werden. Sie können genau dieselbe Struktur verwenden, aber können nach verschiedenen Nachrichtenparametern verlangen.
Der Nachrichtentransfer zwischen Anwendungen und GSM-Basisfunktionen wird von den folgenden Nachrichten gehandhabt:
bezogen auf die GSM-Basisfunktion gsm.dialog

– gsm_open_request (Anfrage öffnen)
– gsm_open_confirmation (Bestätigung öffnen)
– gsm_open_indication (Anzeige öffnen)
– gsm_open_response (Antwort öffnen)
– gsm_data_request (Datenanfrage)
– gsm_data_confimation (Datenbestätigung)
– gsm_data_indication (Datenanzeige)
– gsm_status_indication (Anzeigestatus)
– gsm_close_request (Anfrage schließen)
– gsm_close_confimation (Bestätigung schließen)
– gsm_close_indication (Anzeige schließen)

– gsm_AT_command_request (Befehl Anfrage)
– gsm_AT_command_response (Befehl Antwort)

– gsm_write_service_table_request (Service-Verzeichnis-Anfrage schreiben)
– gsm_read_service_table_request (Service-Verzeichnis-Anfrage lesen)
– gsm_read_service_table_response (Service-Verzeichnis-Antwort lesen)

Einige Beispiele für den Nachrichtentransfer zwischen einer Anwendung und einer GSM-Basisfunktion sind im Zeitfolgediagramm auf den folgenden Seiten beschrieben.

3.2.3-1: Zeitfolgediagramm bezogen auf die GSM-Basisfunktion GSM dialog
3.2.3-2: Zeitfolgediagramm bezogen auf die GSM-Basisfunktion GSM dialog
3.2.3-3: Zeitfolgediagramm bezogen auf die GSM-Basisfunktion GSM dialog
3.2.3.-4: Zeitfolgediagramm bezogen auf die GSM-Basisfunktion GSM dialog
3.2.3-5: Zeitfolgediagramm bezogen auf die GSM-Basisfunktion GSM dialog
3.2.3-6: Zeitfolgediagramm bezogen auf die GSM-Basisfunktion GSM dialog

3.2.3.1 Nachricht „gsm_open_request" (GSM-Anfrage öffnen)

Nachrichtenname: „gsm_open_req"
Quelle: Anwendung
Ziel: Basisfunktion gsm dialog
Antwort: „gsm_open_confirmation"
Beschreibung: Diese Nachricht wird von der Anwendung verwendet, um eine Kommunikation mit dem Service-Center zu initiieren. Diese Nachricht wird in jedem Fall vor der Übersendung von Daten verwendet, ob es sich um einen Bearer Service, eine SMS oder um einen General Packet Radio Service handelt.

Wenn der Versuch des Aufbaus einer Verbindung nicht erfolgreich ist, muss die Basisfunktion die Fehlergründe analysieren und/oder versenden (z. B. Netzwerkfehlergründe, beschrieben in der GSM TS 04.08, Verzeichnis 10.86), und sie wird in Übereinstimmung mit der GSM TS 02.07 reagieren.
Mit dem Erhalt dieser Nachricht durch die Basisfunktion wird ein logischer Kanal zur Kommunikation zwischen der Anwendung und der Basisfunktion geschaffen. Eine Bestätigungsnachricht, die die logische Kanalnummer oder den möglichen Fehlergrund enthält, muss an die anfragende Anwendung gesendet werden. Wenn die Anwendung unter Verwendung einer SMS kommunizieren möchte, wird die Nachricht „gsm_open_con" sofort erzeugt, nachdem die Nachricht „gsm_open_req" empfangen worden ist. Wenn ein BS2X für die Kommunikation verwendet werden sollte, muss die Verbindung zum angefragten Service-Center geschaffen werden, bevor die Nachricht „gsm_open_con" an die anfragende Anwendung gesendet wird.
Passiert ein Fehler, wird eine „gsm_status_ind"-Nachricht an die anfragende Anwendung gesandt.
Die Nachricht enhält den Nachrichtenidentifizierer <msg_id>, den Anwendungs-Seivice-Identifizierer <asi>, den Kommunikationsseivice <service>, die Wählnummer <dial_string>; bei Bearer Services die Parameter <speed>, <name> und <ce>. Die Datenelemente <speed>, <name> und <ce> und deren mögliche Werte entsprechen dem Kapitel 6.7 der GSM 07.07. Bei einer SMS enthält die Nachricht die SMS-Center-Adresse <SMS_center_address>.

Syntax: <msg_id>, <asi>, <service>, <dial_string>, <speed>, <name>, <ce>, <SMS_center_address>

Definierte Werte: <msg_id> ist zu definieren.
<asi>: Die Anwendungsservice-Identfiziererwerte müssen für alle möglichen Verkehrstelematikanwendungen definiert werden. Werte müssen mindestens definiert werden für:

– dynamic route guidance (dynamische Routenführung)
– floating car data acquisition (Datenbeschaffung für eingesetztes Fahrzeug)
– fleet management (Flotten-Management)
– traffic information (Verkehrsinformationen)
– emergency break-down services (Notfall-Pannen-Services)
– vehicle theft protection (Fahrzeugdiebstahlsschutz)
– automatic tolling (automatisches Bezahlen von Straßengebühren)

<service>: Service, der für die Kommunikation zu verwenden ist. Die empfohlenen Werte lauten:

0 – Bearer Service (benötigt Werte für <dial_string>, <speed>, <name>, <ce>
1 – SMS (benötigt Werte für <dial_string>, <SMS_center_address>)

<dial_string>: Wählnummer des angefragten Service-Centers
<speed>: Auswahl der Datenmenge und der Informationstransfermöglichkeiten empfohlene Werte (so wie in Kapitel 6.7 der GSM 07.07 definiert) sind:
4–2.400 bps (V.22bis)
7–9.600 bps (V.32)
68–2.400 bps (V.110)
71–9.600 bps (V.110)
<name>: Wahl des Bearer-Services
empfohlene Werte (so wie in Kapitel 6.7 der GSM 07.07 definiert) sind:
0 – asynchronisches Modem
<ca>: Wahl des Verbindungselements
Werte (wie in Kapitel 6.7 der GSM 07.07 definiert); mögliche Werte sind:

0 – transparent
1 – nicht transparent

<SMS_center_address>: Wählnummer des angefragten SMS-Centers

3.2.3.2 Nachricht „gsm_open_confirmation" (GSM-Bestätigung öffnen)

Nachrichtenname: „gsm_open_con"
Quelle: Basisfunktion gsm_dialog
Ziel: Anwendung
Beschreibung: Diese Nachricht wird verwendet, um zu bestätigen, dass ein logischer Kanal für die anfragende Anwendung zum Senden von Daten zum Service-Center (mit einer „gsm_data_req"-Nachricht) geöffnet wurde. Die „gsm_open_con"-Nachricht enthält eine <channel_no>. Diese Kanalnummer wird von nachfolgenden Nachrichten zur Ansprache des logischen Kommunikationskanals verwendet.
Im Falle von unlösbaren Problemen, d. h. die Verbindung wurde nach wiederholtem Wählen der definierten Nummern nicht hergestellt, zeigt die Basisfunktion den Ausfallgrund mit einer „gsm_status_ind"-Nachricht an. Wenn kein logischer Kanal geöffnet worden ist, muss infolgedessen keine „gsm_open_con"-Nachricht an die Anwendung gesandt werden.
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id> ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation

3.2.3.3 Nachricht „gsm_open_indication" (GSM-Anzeige öffnen)

Nachrichtenname: „gsm_open_ind"
Quelle: Basisfunktion gsm_dialog
Ziel: Anwendung
Beschreibung: Diese Nachricht wird von der Basisfunktion verwendet, um der Destinationsanwendung anzuzeigen, dass ein Service-Center Daten senden möchte.
Wenn das Service-Center eine verbindungsorientierte Kommunikation erzeugt, empfängt die Basisfunktion einen Identifizierer für die Zielanwendung. Die Basisfunktion öffnet einen logischen Kommunikationskanal für diese Anwendung und sendet eine Kanalnummer. Die Anwendung muss die Nachricht mit der Antwortnachricht „gsm_open_res" bestätigen, die durch die Basisfunktion an das anfragende Service-Center transferiert wird.
Wenn ein Service-Center-Anruf unter der Verwendung einer SMS vom Verkehrstelematikendgerät empfangen wird, wird von der Basisfunktion ebenfalls ein logischer Kommunikationskanal zur Zielanwendung eingerichtet. Wiederum muss die Anwendung mit der „gsm_open_res"-Nachricht bestätigen, bevor die Daten von der Basisfunktion angezeigt werden.
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id>: ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.3.4 Nachricht „gsm_open_response" (GSM-Antwort öffnen)

Nachrichtenname: „gsm_open_res"
Quelle: Anwendung
Ziel: Basisfunktion gsm_dialog
Beschreibung: Diese Nachricht wird dazu verwendet, der Grundfunktion zu bestätigen, dass die Anwendung zum Empfang einer Nachricht vom Service-Center bereit ist.
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id>: ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.3.5 Nachricht „gsm_data_request" (GSM-Datenanfrage)

Nachrichtenname: „gsm_data_request"
Quelle: Anwendung
Ziel: Basisfunktion gsm_dialog
Antwort: „gsm_data_con"
Beschreibung: Mit dieser Nachricht werden Daten, die an das Service-Center zu übermitteln sind, an die Basisfunktion gesendet. Bei einer erfolgreichen Übertragung wird eine „gsm_data_confirmation"-Nachricht an die Anwendung gesendet. Wenn Daten beim Durchlauf durch den Rückschleppmechanismus (retrail mechanism) nicht korrekt transferiert werden können, wird eine „gsm_status_ind"-Nachricht an die Anwendung gesendet.
Syntax: <msg_id>, <channel_no>, <data_length>, <data>
Definierte Werte: <mas_id> ist zu definieren
<channel_no": Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.
<data_length>: Länge der Daten in Byte
<data>: Daten, die an das Service-Center zu senden sind.

3.2.3.6 Nachricht „gsm_data_confirmation" (GSM-Datenbestätigung)

Nachrichtenname: „gsm_data_con"
Quelle: Basisfunktion gsm_dialog
Ziel: anfragende Anwendung
Beschreibung: Diese Nachricht wird verwendet, um der anfragenden Anwendung zu bestätigen, dass Daten an das Service-Center gesendet worden sind.
Wenn Daten unter Verwendung einer SMS übermittelt wurden, wird eine „gsm_data_con"-Nachricht an die Anwendung gesendet, wenn die übertragene Nachricht durch das SMS-Service-Center bestätigt wurde. Wenn Daten unter Verwendung einer verbindungsorientierten Kommunikation übermittelt wurden, wird eine Bestätigung über die Lieferung derselben an das Service-Center vom Gesamtprotokoll abgegeben.
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id>: ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.3.7 Nachricht „gsm_data_indication" (GSM-Datenanzeige)

Nachrichtenname: „gsm_data_ind"
Quelle: Basisfunktion gsm_dialog
Ziel: Anwendung
Beschreibung: Mit dieser Nachricht wird eine Anwendung über eine Nachricht unterrichtet, die vom Service-Center empfangen worden ist. Das Service-Center hat eine Verbindung hergestellt, um Daten an eine Anwendung zu senden.
Die Basisfunktion empfängt diese Daten vom Service-Center und identifiziert die Zielanwendung. Wenn für diese Anwendung bereits ein logischer Kanal geöffnet ist, werden die Daten unter Verwendung dieses Kanals transferiert. Gibt es keinen offenen Kanal, muss ein Kanal von der Basisfunktion eingerichtet werden. Unter Verwendung dieses neuen Kanals werden die empfangenen Daten an die Anwendung transferiert.
Wenn ein Service-Center innerhalb einer bestehenden Kommunikation Daten an die Endgerätausrüstung sendet, empfängt die Grundfunktion diese Daten und identifiziert die Zielanwendung, an die die Daten gesendet werden müssen. Wenn die Zielanwendung innerhalb einer bestehenden Kommunikation bereits über einen geöffneten Kommunikationskanal verfügt, ist diese Kanalnummer Teil der „gsm_data_ind"-Nachricht. Wenn die Zielanwendung nicht über einen offenen Kommunikationskanal verfügt, wird von der Basisfunktion ein neuer logischer Kommunikationskanal erzeugt.
Wenn ein Service-Center eine verbindungsorientierte Kommunikation erzeugt, bestätigt die Basisfunktion die Verbindung automatisch und erzeugt einen logischen Kommunikationskanal zur Zielanwendung. Nachdem das Service- Center die Daten gesendet hat, sendet die Basisfunktion eine „gsm_data_ind"-Nachricht an die Zielanwendung.
Wenn ein Service-Center eine verbindungslose Kommunikation erzeugt, empfängt die Basisfunktion die Daten, erzeugt einen neuen logischen Kommunikationskanal und sendet eine „gsm_data_ind"-Nachricht an die Zielanwendung. Zu Bestätigungszwecken wird eine „gsm_get_data_con"-Nachricht von der Anwendung an die Basisfunktion gesendet. Die Basisfunktion sendet keine Bestätigungsnachricht an das Service-Center. Nur die Anwendung muss entscheiden, ob das Service-Center eine Bestätigung benötigt und erforderlichenfalls eine neue Kommunikation initiieren muss.
Die Nachricht enthält den Nachrichtenidentifizierer <msg_id>, den Datentyp <data_typ>, die Länge der nachfolgenden Daten <data_length>, die Daten <data> selbst und die Kanalnummer <channel_no>.
Syntax: <msg_id>, <channel_no>, <data_length>, <data>
Definierte Werte: <msg_id> ist zu definieren
<channel_no>. Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.
<data_length>: Länge der Daten in Byte
<data>: Daten, die an die Zielanwendung zu senden sind.

3.2.3.8 Nachricht „gsm_status_indication" (GSM-Statusanzeige)

Nachrichtenname: „gsm_status_ind"
Quelle: Basisfunktion gsm_dialog
Ziel: Anwendung
Beschreibung: Die Nachricht wird verwendet, um die Anwendung über einen Fehler zu informieren (Werte gem. GSM TS 04.08, Verzeichnis 10.86, und GSM TS 07.07, Abschnitt 9.2) oder um mitzuteilen, dass eine unerwartete Aktion geschah oder um über eine Statusänderung der Ausrüstung zu informieren Wenn die Anwendung die „gsm_status_ind"-Nachricht empfängt, muss sie über weitere Aktionen entscheiden.
Die Nachricht enthält den Nachrichtenidentifizierer <msg_id>, die Statusinformationen <status> und die Kanalnummer <channel_no> (wenn verfügbar).
Syntax: <msg_id>, <channel_no>, <status>
Definierte Werte: <msg_id> ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.
<status>: Statusinformationen hinsichtlich eines Fehlers, einer unerwarteten Aktion oder eines Ausrüstungsstatusses; mögliche Werte sind in der Anlage 1 definiert:
### – Statusinformationen

3.2.3.9 Nachricht „gsm_close_request" (GSM-Anfrage schließen)

Nachrichtenname: „gsm_close_req"
Quelle: Anwendung
Ziel: Basisfunktion gsm_dialog
Antwort: „gsm_close_con"-gsm_status_ind"
Beschreibung: Diese Nachricht wird von der Anwendung verwendet, um den logischen Kommunikationskanal zwischen der Anwendung und der Basisfunktion zu schließen. Eine verbundene Kommunikationsleitung wird sofort unterbrochen, wenn kein anderer Kommunikationsweg (logischer Kanal) geöffnet wird.
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id> ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.3.10 Nachricht „gsm_close_confirmation" (GSM-Bestätigung schließen)

Nachrichtenname: „gsm_close_con"
Quelle: Basisfunktion gsm_dialog
Ziel: Anwendung
Beschreibung: Diese Nachricht wird verwendet, um einer anfragenden Anwendung zu bestätigen, dass der logische Kommunikationskanal zwischen der Anwendung und der Basisfunktion geschlossen worden ist. Falls kein anderer Kommunikationsweg (logischer Kanal) geöffnet wurde, ist die Kommunikation mit dem Service-Center beendet worden.
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id> ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.3.11 Nachricht „gsm_close_indication" (GSM-Anzeige schließen)

Nachrichtenname: „gsm_close_ind"
Quelle: Basisfunktion gsm_dialog
Ziel: Anwendung
Beschreibung: Diese Nachricht wird von der Basisfunktion verwendet, um einer Anwendung anzuzeigen, dass die Kommunikation, die durch die logische Kanalnummer an das Service-Center identifiziert wurde, beendet ist.
Wenn ein Service-Center eine verbindungsorientierte Kommunikation trennen möchte, wird eine Schließungsanfrage an das Verkehrstelematikendgerät gesendet. Wenn das Gesamtprotokoll der Basisfunktion diese Anfrage erhält, wird dem Service-Center sofort eine Bestätigung zugesandt. Um die Trennung anzuzeigen, wird eine „gsm_close_ind"-Nachricht an die betroffene Anwendung gesandt. Der logische Kanal wird geschlossen.
Wenn innerhalb einer verbindungslosen Kommunikation keine Daten über die Dauer einer Zeit „t" empfangen wurden, wird ebenfalls eine „gsm_close_ind"-Nachricht an die betroffene Anwendung gesandt, um den logischen Kommunikationskanal zu schließen.
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id>: ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.3.12 Nachricht „gsm_AT_command_equest" (GSM-AT-Befehl Anfrage)

Nachrichtenname: „gsm_AT_command_req"
Quelle: Anwendung
Ziel: Basisfunktion gsm indirekt AT-command access
Antwort: „gsm_AT_command_res"
Beschreibung: Diese Nachricht wird von der Anwendung verwendet, um einen AT-Befehl an eine GSM-Basisfunktion transparent zu versenden. AT-Befehle sollen in Übereinstimmung mit den GSM-Empfehlungen 07.05 und 07.07 stehen. Um eine „gsm_at_command_req" zu senden, ist kein logischer Kanal erforderlich. Der Befehl kann parallel zu offenen Kanälen verwendet werden. Nicht alle Befehle sind durch diesen Befehl erlaubt. Z. B. der ATD-Befehl kann nur von der Basisfunktion selbst nach einer „gsm_open_request" (siehe Anlage 2) erzeugt werden.
Syntax: <msg_id>, <cmd_len>, <AT_command>
Definierte Werte: <msg_icb ist zu definieren
<cmd_len>: Länge des Befehls, der folgt.
<AT_command>: AT-Befehl, der an die Basisfunktion zu senden ist. Der Satz an möglichen Befehlen wird in der Anlage 2 empfohlen.

3.2.3.13 Nachricht „gsm AT_command_response" (GSM-AT-Befehl Antwort)

Nachrichtenname: „gsm_AT_command_res"
Quelle: Basisfunktion gsm_indirect_AT-command access
Ziel: betroffene Anwendung
Beschreibung: Diese Nachricht wird von den GSM-Basisfunktionen verwendet, um die Antwort auf einen AT-Befehl, der von einem GSM-Modul empfangen wurde, an die angesprochene Anwendung transparent zu übersenden.
Syntax: <msg_id>, <data_length>, <data>
Definierte Werte: <msg_id> ist zu definieren
<data_length>: Länge der Daten in Byte
<data>: Daten, die von der Basisfunktion zu übersenden sind.

3.2.3.14 Nachricht „gsm_write_service_table_request" (GSM-Service-Verzeichnis-Anfrage schreiben)

Nachrichtenname: „gsm_write_service_table_req"
Quelle: Anwendung
Ziel: Basisfunktion gsm communication service table access"
Beschreibung: Diese Nachricht wird verwendet, um den Inhalt des Kommunikations-Service-Verzeichnisses zu schreiben/ändern, das von der Basisfunktion gesteuert wird. Um diese Nachricht zu senden, ist kein logischer Kanal erforderlich. Der Befehl kann parallel zu offenen Kanälen verwendet werden.
Syntax: <msg_id>, <object>, <service>, <status>, <data>
Definierte Werte: <msg_id> ist zu definieren
<object> ist der Selektor für <service> empfohlene Werte sind:

1 – Netzwerk
2 – GSM-Modul
3 – Teilnehmer
4 – Anrufwiederholzähler
5 – Anrufleitungsidentität der Service-Center-Anwendung

<service/dial_string>: Selektor für Service- oder Dial_String-Informationen
Die Empfehlungen für angefragte Werte lauten:
Falls der <object>-Wert 1, 2 oder 3 ist, kann die Verfügbarkeit festgelegt werden für:

– BS24
– BS26
– TS11
– TS21
– TS22
– TS23
– GPRS/PDS
– CLIP
– CLIR
– COLP
– COLR
– Call Wait

Falls der <object>-Wert 4 beträgt, ist der Wert von <service> der Dial_String, wofür der Anrufwiederholzähler auf einen bestimmten Wert einzustellen ist. -dial_string für „call repeat counter" (Anrufwiederholzähler)
Falls der <object>-Wert 5 beträgt, ist der Wert von <service> die application_id, wofür die Anrufleitungsidentität einzustellen ist. -application_id für Anrufleitungsidentität
<data>: Daten, die an das Kommunikations-Service-Verzeichnis zu schreiben sind. Die empfohlenen Werte lauten:

– Falls der <object>-Wert 1, 2 oder 3 ist, werden die folgenden Werte empfohlen: 0 – unbekannt 1 – verfügbar 2 – nicht verfügbar
– Falls der <object>-Wert 4 beträgt, werden die folgenden Werte empfohlen: # – Wert des Anrufwiederholzählers
– Falls der <object>-Wert 5 beträgt, werden die folgenden Werte empfohlen: „calling_line_identity" für die Service-Center-Anwendung

3.2.3.15 Nachricht „gsm_read_service_table_request" (GSM-Service-Verzeichnis-Anfrage lesen)

Nachrichtenname: „gsm_read_service_table_req"
Quelle: Anwendung
Ziel: Basisfunktion gsm communication service table access (Kommunikations-Service-Verzeichnis-Zugang)
Antwort: „gsm_read_service_table_req"
Beschreibung: Diese Nachricht wird verwendet, um Daten aus dem Kommunikations-Service-Verzeichnis zu lesen, das unter der Kontrolle des Basisfunktion steht. Das Ergebnis wird an die anfragende Anwendung unter Verwendung der Nachricht „gsm_read_service_table_inq" gesendet. Um diese Nachricht zu senden, ist kein logischer Kanal erforderlich. Der Befehl kann parallel zu geöffneten Kanälen verwendet werden.
Syntax: <msg_id>, <object>, <service/dial_string>
Definierte Werte: <msg_id> ist zu definieren
<object>: Selektor für <service>-empfohlene Werte lautet:

1 – Netzwerk
2 – GSM-Modul
3 – Teilnehmer
4 – Anrufwiederholzähler
5 – Anrufs-Leitungs-Identität der Service-Center-Anwendung

<service/dial_string>-angefragter Service oder dial_string-Informationsempfehlung für angefragte Werte lautet:
Falls der <object>-Wert 1, 2 oder 3 beträgt, können Serviceinformationen angefragt werden für:

– BS24
– BS26
– TS11
– TS21
– TS22
– TS23
– GPRS/PDS
– CLIP-CLIR
– COLP
– COLR
– Call Wait

Falls der <object>-Wert 4 beträgt, können die Anrufwiederholzählerwerte für ein spezielles dial string angefragt werden: -dial_string für „Anrufwiederholinformationen"
Fall der <object>-Wert 5 beträgt, kann die Anruf-Leitungs-Identität eines speziellen Service-Centers für eine Verkehrstelematikanwendung angefragt werden. -application-id für die Anfrage nach einer Anruf-Leitungs-Identität

3.2.6.16. Nachricht „gsm-read_service_table_response" (GSM-Service-Verzeichnis-Antwort lesen)

Nachrichtenname: „gsm_read_service_table-res"
Quelle: Basisfunktion gsm communication service table access (Übs.: s. o.)
Ziel: Anwendung
Beschreibung: Diese Nachricht wird verwendet, um das Ergebnis einer „gsm_read_service_table_req" an die anfragende Anwendung zu senden.
Die Nachricht enthält den Nachrichtenidentifizierer <msg_id> und den Status des angefragten Services <status>. Wenn der Anrufwiederholzähler von einem dial_string angefragt wird, enthält die Nachricht ebenfalls den augenblicklichen Zählwert <counter>, die Zeit des letzten Versuchs <time> und den Freigabegrund <reason>. Wenn die Anrufs-Leitungs-Identität eines speziellen Service-Centers für eine Verkehrstelematikanwendung angefragt wurde, enthält die Nachricht ebenfall eine Anrufs-Leitungs-Identität <CLI>.
Syntax: <msg-id>, <status>, <counter>, <time>, <reason>, <CLI>
Definierte Werte: <msg_id> ist zu definieren
<status>: Status der möglichen Werte des angefragten Services:

0 – unbekannt
1 – verfügbar
2 – nicht verfügbar

<counter>: augenblicklicher Wert des Wiederholzählers
<time>: Zeit des letzten Versuchs mögliche Werte sind: Zeit (hh:mmas) (Stunde/Stunde:Minute/Minute:Sekunde/Sekunde)
<reason>: Freigabegrund mögliche Werte sind: # – Freigabegründe in Übereinstimmung mit den GSM-Empfehlungen 04.08, 07.05 und 07.07
<CLI>: Anruf-Leitungs-Identität des Service-Centers für den angefragten Verkehrstelematikservice

3.2.4 Nachrichten, die auf das Zwischensystem Ortsbestimmung bezogen sind
In diesem Kapitel sind die Nachrichten beschrieben, die sich auf die verschiedenen GPS-Basisfunktionen beziehen. Die Nachrichtenübermittlung zwischen den Anwendungen und den GPS-Basisfunktionen erfolgt mit den folgenden Nachrichten:
bezogen auf die GPS-Basisfunktion GPS-Basisdaten:

– gps_data_start_request (GPS-Datenstartanfrage)
– gps_data_indication (GPS-Datenanzeige)
– gps_data_stop-request (GPS-Datenanfragestopp)
– gps_send_dgps_correct_indication (Übs. = ?, weil dgps = ?)
– gps_data_set_height_request (GPS-Anfrage über die Datensatzhöhe)
– gps_data_del_height_request (GPS-Anfrage über die Datenlieferhöhe)

– gps_geometry_request (GPS-Geometrieanfrage)
– gps_geometry_indication (GPS-Geometrieanzeige)

– gps_approx_data_backward_request (nach hinten gerichtete Annäherung in Bezug auf Ca.-GPS-Daten)
– gps_approx_data_backward_indication (Anzeige der nach hinten gerichteten Annäherung in Bezug auf Ca.-GPS-Daten)

– gps_waylength_start_request (GPS-Weglängenstartanfrage)
– gps_waylength_request (GPS-Weglängeanfrage)
– gps_waylength_indication (GPS-Weglängeanzeige)
– gps_waylength_stop_request (GPS-Weglängestoppanfrage)
– gps_waylength_global_request (GPS-Weglängeglobalanfrage)
– gps_waylength_global_indication (GPS-Weglängeglobalanzeige)

– gps_waypoint_start_request (GPS-Wegpunktstartanfrage)
– gps_waypoint_status_request (GPS-Wegpunktstatusanfrage)
– gps_waypoint_stop_request (GPS-Wegpunktstoppanfrage)

Einige Beispiele von Nachrichtenübermittlungen zwischen einer Anwendung und einer GPS-Basisfunktion sind im Zeitfolgediagramm auf den folgenden Seiten beschrieben.

3.2.4-1: Zeitfolgediagramm bezogen auf die GPS-Basisfunktionen GPS-Basisfunktion und Annäherung
3.2.4-2: Zeitfolgediagramm bezogen auf die GPS-Basisfunktion Weglänge
3.2.4-3: Zeitfolgediagramm bezogen auf die GPS-Basisfunktion Wegpunkt

3.2.4.1 Nachricht „gps_data_start_request" (GPS-Datenstartanfrage)

Nachrichtenname: „gps_data_start_req"
Nachrichtenname: Nachrichtenname: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion GPS-Basisdaten
Beschreibung: Diese Nachricht wird verwendet, um GPS-Datensätze anzufordern.
Wenn der Parameter <par> den Wert 0 hat, wird lediglich der aktuelle GPS-Datensatz angefragt. Wenn <par> den Wert 1 hat, wird gefordert, dass der aktuelle GPS-Datensatz und der nachfolgende alle <time_diff>-Sekunden zu übersenden ist. Mit der Bit-Karte <mask> spezifiziert die Anwendung die speziellen Datenelemente des gesamten GPS-Datensatzes, der benötigt wird.
Syntax: <msg_id>, <par>, <time_diff>, <mask>
Definierte Werte: <msg_id>; ist zu definieren
<par>: 0: nur der aktuelle GPS-Datensatz wird angefragt; 1: der aktuelle GPS-Datensatz wird angefragt und der nachfolgende alle <time_diff>-Sekunden.
<time_diff>: Zeitdauer zwischen zwei angefragten GPS-Datensätzen
<mask>: Bit-Karte, die die speziellen Datenelemente anzeigt, die von der Anwendung angefragt wurden. Der ganze GPS-Datensatz enthält die Elemente: Datum, Zeit (UTC), geographischer Breitengrad, geographischer Längengrad, Höhe (gemessene See-Ebene), horizontale Präzisionsauflösung (HDOP), geschätzter Positionsfehler in südlich-nördlicher Richtung (EPE(x)), geschätzter Positionsfehler in westlich-östlicher Richtung (EPE(y)), absolute horizontale Geschwindigkeit, Richtung (0 Grad = Norden, im Uhrzeigersinn), Anzahl der theoretisch sichtbaren Satelliten, Anzahl der Satelliten, die die Positionsberechnung betreffen, Indikator für eine Änderung der Satellitenkonstellation (0 = keine Änderung der Konstellation, 1 = Änderung der Konstellation), Positionstyp (TOP), spezielle Daten des Empfängers, Pseudobereichsdaten, Pseudobereichsmenge.

3.2.4.2 Nachricht „gps_data_indication" (GPS-Datenanzeige)

Nachrichtenname: „gps_data_indication"
Quelle: Basisfunktion GPS-Basisdaten
Ziel: Anwendung (oder eine andere Basisfunktion)
Beschreibung: Diese Nachricht wird verwendet, um die speziellen Datenelemente <data_set> des aktuelle GPS-Datensatzes zu übersenden, die von der/den Anwendung/en angefragt wurden.
Die Positionen des aktuellen GPS-Datensatzes könnten entweder gültige Positionen, gemessen vom GPS-Empfänger, oder nach vorne gerichtete, angenäherte Positionen der Basisfunktion Annäherung sein. Die speziellen Datenelemente, die gesendet werden, werden von der anfragenden Anwendung ausgewählt (siehe Nachricht „gps_data_start_req") und von der Bit-Karte <mask> angezeigt.
Wenn mehr als eine Anwendung Datenelemente des GPS-Datensatzes anfragt, werden alle angefragten Datenelemente durch diese eine Nachricht an alle Anwendungen übersandt. Die speziellen Datenelemente, die übersandt werden, werden mit Hilfe der Bit-Karte <mask> angezeigt. Jede Anwendung muss jene Datenelemente aussuchen, die sie angefragt hat. Wenn der Parameter <par> der Nachricht „gps_data_start_req" den Wert 1 hat, werden ebenfalls die Datenelemente der folgenden GPS-Datensätze, die von der Bit-Karte spezifiziert wurden, alle <time_diff>-Sekunden gesendet werden.
Syntax: <msg_id>, <mask>, <data_set>
Definierte Werte: <msg_id>: ist zu definieren
<mask>: Bit-Karte, die die spezielle Datenelemente des ganzen Datensatzes anzeigt, die gesendet werden.
<data_set>: spezielle Datenelemente des ganzen GPS-Datensatzes, angezeigt durch die Bit-Karte <mask>.

3.2.4.3 Nachricht „gsm_data_stop_request" (GPS-Datenstoppanfrage)

Nachrichtenname: „gps_data_stop_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion GPS-Basisdaten
Beschreibung: Diese Nachricht wird verwendet, um die Übermittlung von GPS- Datensätzen zu stoppen. Gibt es andere Anwendungen, die noch GPS-Datensätze anfragen, werden sie bedient, bis sie diese Nachricht ebenfalls versenden.
Syntax: <msg_id>
Definierte Werte: <msg_id>: ist zu definieren

3.2.4.4 Nachricht „gps_send_dgps_correct_indication"

Nachrichtenname: „gps_send_dgps_correct_ind"
Quelle: Basisfunktion GSM-Dialog oder Anwendung
Ziel: Basisfunktion GSM-Basisdaten
Beschreibung: Wenn eine Anwendung Korrekturdaten (DGPS) bereitstellen kann, wird diese Nachricht verwendet, um die unterschiedlichen Daten für die DGPS-Positionen (im Format RTCM) an die Grundfunktion GPS-Grunddaten zu senden.
Syntax: <msg_id>, <dgps_data>
Definierte Werte: <msg_id>: ist zu definieren
<dgps_data>: unterschiedliche Daten für DGPS-Positionen (im Format RTCM)

3.2.4.5 Nachricht „gps_data_set_height_request" (GPS-Anfrage über die Höhe des Datensatzes)

Nachrichtenname: „gps_data_set_height_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion GPS-Basisdaten
Beschreibung: Wenn eine Anwendung die genaue Höhe der aktuelle GPS-Position kennt, ist sie in der Lage, die genaue Höhe mit dieser Nachricht bereitzustellen. Darüber hinaus sendet die Anwendung den Radius des Kreises um die aktuelle Position herum, bei der die festgesetzte Höhe nach wie vor genau ist.
Die Basisfunktion GPS-Basisdaten überprüft durch Schätzung der aktuellen Geschwindigkeit und der Zeitstufe, ob sich die folgende Position noch innerhalb des Kreises befindet. Wenn ja, setzt sie diese Höhe beim GPS-Empfänger fest, der jetzt in der Lage ist, eine genauere GPS-Position mit dieser zusätzlichen Information zu generieren.
Bei jeden neuen GPS-Daten wird diese Überprüfung wiederholt. Wenn sich die nächste Position außerhalb des Kreises befindet, löscht die Basisfunktion die festgesetzte Höhe beim GPS-Empfänger. Die Anwendung kann die festgesetzte Höhe ebenfalls mit Hilfe der Nachricht "„ps_data_del_height_req" löschen.
Die festgesetzte Höhe wird allen Anwendungen angezeigt, die GPS-Daten mit dem Positionstyp (TOP) anfragen.
Syntax: <msg_id>, <height>, <radius>
Definierte Werte: <msg_id>: ist zu definieren
<height>: festgesetzte Höhe
<radius>: Radius des Kreises um die aktuelle Position herum, in dem die festgesetzte Höhe genau ist.

3.2.4.6 Nachricht „gps_data_del_height_request" (GPS-Anfrage über die Höhe des Datensatzes)

Nachrichtenname: „gps_data-del_height_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion GPS-Basisdaten
Beschreibung: Mit dieser Nachricht löscht die Anwendung die festgesetzte Höhe, die die Höhe der GPS-Position festgesetzt hat.
Syntax: <msg_id>, <height>
Definierte Werte: <msg_id>: ist zu definieren
<height>: Festgesetzte Höhe, die zu löschen ist.

3.2.4.7 Nachricht „gps_geometry_request" (GPS-Geometrieanfrage)

Nachrichtenname: „gps_geometry_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion Geometrie
Beschreibung: Diese Nachricht wird verwendet, um die Entfernung oder den Winkel zwischen zwei Positionen anzufragen.
Mit der Bit-Karte <cal> kann die Berechnung der radialen Entfernung, der Längengradentfernung, der Breitengradentfernung und/oder der Winkel zwischen den beiden Positionen angefordert werden.
Wenn der Parameter <par> den Wert 2 hat, werden die beiden Positionen durch die Anwendung gegeben. Wenn der Paremeter <par> den Wert 1 hat, wird eine Position von der Anwendung gegeben und die andere Position ist die aktuelle Position.
Syntax: <msg_id>, <cal>, <pos>, <position>
Definierte Werte: <msg_id>: ist zu definieren
<cal>: Bit-Karte, die die angefragte Berechnung anzeigt. Die folgenden
Berechnungen sind möglich: radiale Entfernung, längs verlaufende Entfernung, latitudinale Entfernung, Winkel zwischen den beiden Positionen im Uhrzeigersinn, bezogen auf den Norden
<pos>: 2 zwei Positionen werden von der Anwendung gegeben: <position> long1 Länge der Position 1 lat1 Breitengrad der Position 1 long2 Länge der Position 2 lat2 Breitengrad der Position 2
<pos>: 1 Eine Position wird von der Anwendung gegeben, die andere Position ist die aktuelle Position.
<position>: long1 Länge der Position 1 lat1 Breitengrad der Position 1

3.2.4.8 Nachricht „gps_geometry_indication" (GPS-Geometrieanzeige)

Nachrichtenname: „gps_geometry_ind"
Quelle: Basisfunktion Geometrie
Ziel: Anwendung (oder eine andere Basisfunktion)
Beschreibung: Diese Nachricht wird verwendet, um das/die Ergebnis/se der Entfernungs- und/oder Winkelberechnung/en zwischen zwei Positionen zu senden, das/die durch die Nachricht „gps_geometry_req" angefragt wurde/n.
Syntax: <msg_id>, <cal>, <result_data>
Definierte Werte: <msg_id>: ist zu definieren
<cal>: Bit-Karte, die das/die Ergebnis/se der Berechnung/en anzeigt.
<result data>: Ergebnis/se der Entfernungs- und/oder Winkelberechnung/en (siehe Nachricht „gps_geometry_req")

3.2.4.9 Nachricht „gps_approx_data_backward_request" (GPS-Anfrage nach nach hinten gerichteten Ca.-Daten)

Nachrichtenname: „gps_approx_data_backward_request"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion Annäherung
Beschreibung: Nach dem Empfang der nach vorne angenäherten oder der ungültigen Positionen und dann der ersten gültigen Position, kann eine Anwendung die nach hinten gerichteten, angenäherten Positionen der Lücke mit dieser Nachricht anfragen.
Mit der Bit-Karte <mask> spezifiziert die Anwendung die speziellen Datenelemente des gesamten GPS-Datensatzes, die benötigt werden.
Syntax: <msg_id>, <time_diff>, <mask>
Definierte Werte: <msg_id>: ist zu definieren
<time_diff>: Dauer der Zeit zwischen zwei angefragten GPS-Datensätzen
<mask>: Bit-Karte, die die speziellen Datenelemente anzeigt, die von der Anwendung angefragt wurden.
Der ganze GPS-Basis-Datensatz enthält die Elemente: Datum, Zeit (UTC), geographischer Breitengrad, geographischer Längengrad, Höhe (gemessene See-Ebene), horizontale Präzisionsauflösung (HDOP), geschätzter Positionsfehler in südlich-nördlicher Richtung (EPE(x)), geschätzter Positionsfehler in westlich-östlicher Richtung (EPE(y)), absolute horizontale Geschwindigkeit, Peilung (0 Grad = Norden, im Uhrzeigersinn), Positionstyp (TOP) spezielle Daten des Empfängers.

3.2.4.10 Nachricht „gps-approx-data_backward_indication"
(GPS-Anzeige der nach hinten gerichteten Ca.-Daten)

Nachrichtenname: „gps_approx_data_backward_ind"
Quelle: Basisfunktion Annäherung
Ziel: Anwendung (oder eine andere Basisfunktion)
Beschreibung: Mit dieser Nachricht sendet die Basisfunktion GPS-Basis-Daten eine Anzahl von N_pos nach hinten gerichteter, angenäherter Positionen der letzten Lücke zur Anwendung.
Die speziellen Datenelemente, die gesendet werden, werden von der anfragenden Anwendung ausgewählt (siehe Nachricht „gps_approx_data_backward_req") und von der Bit-Karte <mask> angezeigt.
Syntax: <msg_id>, <mask>, <time_diff>, <N_pos>
<data_set_1; data_set_2; ...; data_set_N_pos>
Definierte Werte: <msg_Id>: ist zu definieren
<mask>: Bit-Karte, die die speziellen Datenelemente der nach hinten gerichteten, angenäherten GPS-Datensätze anzeigt. Die Bit-Karte gilt für jeden der Datensätze.
<time_diff>: Zeitdauer zwischen zwei angefragten GPS-Datensätzen.
<N_pos>: Anzahl der nach hinten gerichteten, angenäherten Positionen, die gesendet wird.
<data_set_1; data_set_2; ...; data_N_pos> Die nach hinten gerichteten, angenäherten Datensätze, die gesendet werden. Jeder Datensatz beinhaltet die speziellen Datenelemente, die von der Bit-Karte <mask> angezeigt werden.

3.2.4.11 Nachricht „gps_waylength_start_request" (GPS-Weglängen-Startanfrage)

Nachrichtenname: „gps_waylength_start_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion Weglänge
Beschreibung: Diese Nachricht wird verwendet, um den Weglängenzähler auf den Wert „0 Meter" zu Zwecken des Zuwachses oder auf eine festgesetzte Weglänge (als negative Weglänge) zurückzustellen, die zu Zwecken des Zuwachses zurückgelegt werden sollte (realisiert als Zuwachs von negativen Werten).
Die Anwendung wählt die Zählermarkierungen <val_1, val_2, ..., val_n> aus, so dass eine Anzeige gesendet wird, wenn eine Markierung überschritten wurde. D. h. die festgesetzte Weglänge, die zurückgelegt werden sollte, beträgt 2.000 Meter, und Anzeigen sollten gesendet werden, wenn noch 200 m, 100 m und 50 m der gesamten Weglänge zurückzulegen sind. Dann stellt die Anwendung in dieser Nachricht <star_-val> = <–200 m> und <val_1, val_2, val_3, val_4> = <–200 m, –100 m, –50 m, 0 m> ein, um an diesen Punkten eine Anzeige zu erhalten.
Die Anwendung stellt einen ID-Zähler ein. Die Basisfunktion merkt sich, welcher Weglängenzähler zu welcher Anwendung gehört.
Die Weglängenberechnung muss von der Anwendung mit der Nachricht „gps-waylength_stop_req" gestoppt werden. Nur nach diesem Stopp kann der Weglängenzähler zurückgestellt werden.
Der Weglängenzähler wird von der Basisfunktion automatisch gestoppt, wenn er den Zählwert „0 Meter" überquert. Er wird bei einem festgelegten Maximalwert ebenfalls gestoppt.
Syntax: <msg_id>, <counter_id>, <start_val>, <n>, <val_1, val_2, ..., val_n>
Definierte Werte: <msg_id>: ist zu definieren
<counter_id>: der von der Anwendung eingestellt ID-Zähler
<start_val>: Startwert des Weglängenzählers. Er beträgt 0 Meter zu Zwecken des Zuwachses oder eine festgesetzte Weglänge als negativer Wert zwecks Zuwachs.
<n>: Anzahl der Zählmarkierungen
<val_1, val_2, ..., val_n>: Zählmarkierungen

3.2.4.12 Nachricht „gps_waylength_request" (GPS-Weglängenanfrage)

Nachrichtenname: „gps_waylength_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion Weglänge
Beschreibung: Diese Nachricht wird verwendet, um den aktuellen Zählwert des
Zählers mit dem ID-Zähler <counter_id> anzufragen.
Syntax: <msg_id>, <counter_id>
Definierte Werte: <msg_id>: ist zu definieren
<counter_id>: ID-Zähler

3.2.4.13 Nachricht „gps_waylength_indication" (GPS-Weglängen-Anzeige)

Nachrichtenname: „gps_waylength_ind"
Quelle: Basisfunktion Weglänge
Ziel: Anwendung (oder eine andere Basisfunktion)
Beschreibung: Diese Nachricht wird verwendet, um den aktuellen Zählwert des Zählers mit dem ID-Zähler <counter_id> zu senden. Die Nachricht wird nach der Anfrage „gps_waylength_req" oder dann gesendet, wenn der aktuelle Zählwert eine der Markierungen <val_1, val_2, ..., val_n> der Nachricht „gps_waylength_start_req" überquert hat.
Syntax: <msg_id>, <counter_id>, <counter_value>
Definierte Werte: <msg_id>: ist zu definieren
<counter_id>: ID-Zähler
<counter_value>: der aktuelle Zählwert

3.2.4.14 Nachricht „gps_waylength_stop_request" (GPS-Stopp der Weglängenanfrage)

Nachrichtenname: „gps_waylength_stop_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion Weglänge
Beschreibung: Diese Nachricht wird verwendet, um den Weglängenzähler zu stoppen. Wenn der Parameter <par> den Wert 1 hat, wird lediglich der Weglängenzähler mit dem ID-Zähler <counter_id> gestoppt. Wenn der Parameter <par> den Wert 0 hat, werden alle von der Anwendung eingestellte Weglängenzähler gestoppt.
Syntax: <msg_id>, <par>, (wenn <par> = 1; <counter_id>)
Definierte Werte: <msg_id>: ist zu definieren <par> 0 Alle von der Anwendung eingestellten Weglängenzähler werden gestoppt 1 Der Weglängenzähler mit dem ID <counter_id> wird gestoppt.
<counter_id>: ID-Zähler

3.2.4.15 Nachricht „gps_waylength_global_request" (GPS-globale Weglängenanfrage)

Nachrichtenname. „gps_waylength_global_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion Weglänge
Beschreibung: Diese Nachricht wird verwendet, um den aktuellen Zählwert des globalen Weglängenzählers abzufragen.
Syntax: <msg_id>
Definierte Werte: <msg_id>: ist zu definieren

3.2.4.16 Nachricht „gps_waylength_global_indication" (GPS-globale Weglängenanzeige)

Nachrichtenname: „gps_waylength_global_ind"
Quelle: Basisfunktion Weglänge
Ziel: Anwendung (oder eine andere Basisfunktion)
Beschreibung: Diese Nachricht wird verwendet, um den richtigen Zählwert des globalen Weglängenzählers zu senden.
Syntax: <msg_id>, <global_counter_value>
Definierte Werte: <msg_id>: ist zu definieren
<global_counter_value>: der aktuelle Zählwert des globalen Weglängenzählers

3.2.4.17 Nachricht „gps_waypoint_start_request" (GPS-Wegpunktstart-Anfrage)

Nachrichtenname: „gps_waypoint_start_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion Wegpunkt
Beschreibung: Diese Nachricht wird verwendet, um durch Übersenden der Wegpunktdaten die Basisfunktion „gps_waypoint" zu initialisieren. Wenn der Parameter <geom> den Wert 1 hat, werden die Daten des Kreises gesendet (Längen- und Breitengrad der Kreismitte, Radius, Hyperesis, bevorzugte Richtung (0 Grad = Norden, im Uhrzeigersinn) und der Öffnungswinkel der bevorzugten Richtung).
Wenn <geom> den Wert 2 hat, werden die Daten eines Rechtecks gesandt (Längen- und Breitengrad der Mitte des Rechtecks, Länge und Breite des Rechtecks, Hysteresis, bevorzugte Richtung (0 Grad = Norden, im Uhrzeigersinn) und Öffnungswinkel der bevorzugten Richtung).
Die Anwendung stellt den Wegpunkt ID ein. Die Basisfunktion merkt sich, welche/r Wegpunkte zu welcher Anwendung gehört/gehören.
Die Wegpunktberechnung wird durch die Anwendung mit der Nachricht „gps_waypoint_stop_req" gestoppt. Mit dem Parameter <status> kann die Anwendung den Wegpunkt aktiv belassen, selbst wenn das System abgeschaltet und neu initialisiert wird.
Syntax: <msg_id>, <wayp_id>, <geom>, <waypoint_date>, <status>
Definierte Werte: <msg_id>: ist zu definieren
<wayp_id>: von der Anwendung eingestellter ID-Wegpunkt
<geom>: Geometrie des Wegpunktes
s<geom>=1: Kreis
<geom>=2: Rechteck
<waypoint_data>: Wegpunktdaten
<geom>=1: „circle": Längen- und Breitengrad der Kreismitte, Radius, Hysteresis, bevorzugte Richtung (im Uhrzeigersinn, 0 = Norden), Öffnungswinkel der bevorzugten Richtung
<geom>=2: „rectangle": Längen- und Breitengrad der Mitte des Rechtecks, Länge und Breite des Rechtecks, Hysteresis, bevorzugte Richtung (0 Grad = Norden, im Uhrzeigersinn) und Öffnungswinkel der bevorzugten Richtung.
<status>

0 Die Wegpunktberechnung ist nur während des aktuellen Betriebs aktiv.
1 Die Wegpunktberechnung bleibt aktiv, selbst wenn das System abgeschaltet oder neu initialisiert wird.

3.2.4.18 Nachricht „gps_waypoint_status_indication" (GPS-Wegpunkt-Statusanzeige)

Nachrichtenname: „gps_waypoint_status_ind"
Quelle: Basisfunktion Wegpunkt
Ziel: Anwendung (oder eine andere Basisfunktion)
Beschreibung: Erstens wird diese Nachricht verwendet, um die Ankunft im inneren Bereich des Wegpunkts (<status>=1) anzuzeigen. Zweitens zeigt sie an, ob das Fahrzeug die CENTER-Linie (normale Linie zur bevorzugten Richtung durch die Mitte des Wegpunkts) (<status>=2) überquert. Mit diesem Status wird angezeigt, ob sich die Richtung des Fahrzeugs entlang der bevorzugten Richtung (das ist innerhalb des Öffnungskegels der bevorzugten Richtung) (<par_heading>=1) oder nicht entlang der bevorzugten Richtung befindet (das ist außerhalb des Öffnungskegels der bevorzugten Richtung) (<par_heading>=0). Die aktuelle Richtung <heading> wird ebenfalls gesendet. Drittens wird die Abweichung die Hysteresisbereichsrichtung außerhalb des Wegpunkts gesendet (<status>=3).
Viertens: Im Falle von nach hinten gerichteten, angenäherten Positionen wird angezeigt, dass das Fahrzeug im inneren Bereich des Wegpunkts angekommen ist und die CENTER-Linie (<status>=4) gekreuzt hat. Mit diesem Status wird angezeigt, ob die Richtung des Fahrzeugs innerhalb des Öffnungskegels die bevorzugten Richtung (<par_heading>=1) oder außerhalb des Öffnungskegels der bevorzugten Richtung (<par_heading>=0) gewesen ist. Die aktuelle Richtung <heading> wird ebenfalls gesendet.
Fünftens: Bei nach hinten gerichteten, angenäherten Positionen wird angezeigt, dass das Fahrzeug im inneren Bereich des Wegpunkts angekommen ist, die CENTER-Linie gekreuzt und den Hysteresisbereich Richtung außerhalb des Wegpunkts (<status>=5) gelassen hat. Mit diesem Status wird angezeigt, ob die Richtung des Fahrzeugs innerhalb des Öffnungskegels der bevorzugten Richtung (<par_heading>=1) oder außerhalb des Öffnungskegels der bevorzugten Richtung (<par_heading>=0) gewesen ist. Die aktuelle Richtung <heading> wird ebenfalls gesendet. Der Positionstyp (<top(x), top(y)>) der entsprechenden GPS-Position, die Zeit (<time>) dieser Position und die Entfernung (<dist>) dieser Position zur CENTER-Linie (normal zur bevorzugten Richtung durch die Mitte des Wegpunktes) werden mit der Nachricht gesendet. Beim Status 4 und Status 5 werden TOP (<top(x), tp(y>), die Zeit (<time>), die CENTER-Linienentfernung (<dist>), der Parameter <per_heading> und die Richtung (<heading>) der GPS-Position, worauf die CENTER-Nachricht basiert, gesendet.
Syntax: <msg_id>, <wayp_id>, <status>, <top(x), top(y)>, <time>, <dist> (wenn <status>=2, 4, 5. <par_heading>, <heading>)
Definierte Werte: <msg_id>: ist zu definieren
<wayp_id>: ID-Wegpunkt
<status>

1 „IN": Ankunft im inneren Bereich des Wegpunktes
2 "CENTER": Überqueren der CENTER-Linie (normale Linie zur bevorzugten Richtung durch die Mitte des Wegpunktes)
3 „OUT": Abweichung der Hysteresebereichsrichtung außerhalb des Wegpunktes
4 Bei nach hinten gerichteten, angenäherten Positionen: Fahrzeug hat den inneren Bereich des Wegpunktes erreicht und die CENTER-Linie überquert.
5 Bei nach hinten gerichteten, angenäherten Positionen: Fahrzeug ist im inneren Bereich des Wegpunktes angekommen, hat die CENTER-Linie überquert und die Hysteresebereichsrichtung außerhalb des Wegpunktes gelassen.

<top(x), top(y)>: Positionstyp der entsprechenden GPS-Position, top(x) TOP in südlich-nördlicher Richtung
top(y) TOP in westlich-östlicher Richtung
<dist>: Entfernung der entsprechenden GPS-Position zur CENTER-Linie (normale Linie zur bevorzugten Richtung durch die Mitte des Wegpunktes)
<time>: Zeit der entsprechenden GPS-Position, wenn <status>=2, 4, 5
<par_heading>:

1 Richtung des Fahrzeugs ist gewesen: entlang der bevorzugten Richtung (das ist innerhalb des Öffnungskegels der bevorzugten Richtung)
0 Richtung des Fahrzeugs ist gewesen: nicht entlang der bevorzugten Richtung (das ist außerhalb des Öffnungskegels der bevorzugten Richtung)

<heading>: Richtung bei der entsprechenden GPS-Position

3.2.4.19 Nachricht „gps_waypoint_stop_request" (GPS-Wegpunkt-Stoppanfrage)

Nachrichtenname: „gps_waypoint_stop_req"
Quelle: Anwendung (oder eine andere Basisfunktion)
Ziel: Basisfunktion Wegpunkt
Beschreibung: Diese Nachricht wird verwendet, um die Wegpunktberechnung zu stoppen. Wenn der Parameter <par> den Wert 1 hat, wird nur die Wegpunktberechnung in Übereinstimmung mit dem Wegpunkt mit dem ID-Wegpunkt <wayp_id> gestoppt. Wenn der Parameter <par> den Wert 0 hat, wird die Wegpunktberechnung aller Wegpunkte gestoppt, die von der Anwendung eingestellt wurden.
Syntax: <msg_id>, <par>, (wenn <par>=1: <wayp_id>)
Definierte Werte: <msg_id>: ist zu definieren
<par>

0 Alle Wegpunkte, die von der Anwendung eingestellt wurden, werden deaktiviert.
1 Der Wegpunkt mit dem ID-Wegpunkt <wayp_id> wird deaktiviert.

Wenn <par>=1: <wayp_id>: ID-Wegpunkt

3.2.5 Nachrichten, die sich auf die Zugangssteuerung des Zwischensystems beziehen
In diesem Kapitel werden die Nachrichten beschrieben, die sich auf verschiedene Basisfunktionen des Chipkarten-Schnittstellenmoduls (CIM) beziehen. Die Nachrichtenübertragung zwischen Anwendungen und CIM-Basisfunktionen erfolgt mit den folgenden Nachrichten:
bezogen auf die CIM-Grundfunktion CIM-Anwendung öffnen:

– cim_open_application_request (CIM-Anwendungsanfrage öffnen)
– cim_open_application_confirmation (CIM-Anwendungsbestätigung öffnen)

– cim_send_data_request (CIM-Datenanfrage senden)
– cim_send_data_response (CIM-Datenantwort senden)
– cim_status_request (CIM-Statusanfrage)
– cim_status_indication (CIM-Statusanzeige)

– cim_close_application_request (CIM-Anwendungsanfrage schließen)
– cim_close_application_confirmation (CIM-Anwendungsbestätigung schließen)

Ein Beispiel von Nachrichtenübermittlungen zwischen einer Anwendung und einer CIM-Basisfunktion ist in einem Zeitfolgediagramm auf der folgenden Seite beschrieben.
3.2.5-1: Zeitfolgediagramm, bezogen auf das Zwischensystem Zugangssteuerung
3.2.5.1 Nachricht „cim_open_application_request"
(CIM-Anwendungsanfrage öffnen)

Nachrichtenname: „cim_open_application_req"
Quelle: Anwendung
Ziel: Basisfunktion CIM-Anwendung öffnen)
Antwort: „cim_open_application_con" (die geöffnete Bestätigung ist entweder positiv oder negativ)
Beschreibung: Diese Nachricht wird von der Anwendung verwendet, um eine Kommunikation mit einer Chipkartenanwendung zu initiieren. Wenn der Versuch eines Aufbaus einer Verbindung scheitert, muss die Basisfunktion die Fehlergründe (z. B. unbekannte Anwendung, keine Chipkarte verfügbar) analysieren und weiterleiten.
Mit dem Empfang dieser Nachricht wird ein logischer Kanal für die Kommunikation zwischen der Anwendung und der Basisfunktion eingerichtet. Eine Bestätigungsnachricht, die die Nummer des logischen Kanals oder den möglichen Fehlergrund enthält, muss an die anfragende Anwendung gesendet werden.
Die Nachricht enthält den Nachrichtenidentifizierer <msg_id> und den Anwendungsidentifizierer <ais>.
Syntax: <msg_id>, <aid>
Definierte Werte: <msg_id>: ist zu definieren
<aid>: ist zu definieren

3.2.5.2 Nachricht „cim_open_application_confirmation" (CIM-Anwendungsbestätigung öffnen)

Nachrichtenname: „cim_open_application_con"
Quelle: Basisfunktion CIM-Anwendung öffnen
Ziel: anfragende Anwendung
Beschreibung: Diese Nachricht wird verwendet, um zu bestätigen, dass ein logischer Kanal für die anfragende Anwendung zum Senden von Befehlen oder Daten an die Chipkarte (mit „cim_send_data_req"-Nachrichten) geöffnet wurde. Die „cim_open_application_con"-Nachricht enthält eine <channel_no> (Kanalnummer). Diese <channel_no> wird von den folgenden Nachrichten verwendet, um den logischen Kommunikationskanal anzusprechen.
Syntax: <msg_id>, <status>, <channel_no>, <cause>
Definierte Werte: <msg_id>: ist zu definieren
<status>: ACK (ist zu definieren), der nächste Parameter soll als channel_no interpretiert werden
NAK (ist zu definieren), der nächste Parameter soll als Grundwert interpretiert werden.
<cause>: ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.5.3 Nachricht „cim_send_data_request" (CIM-Datenanfrage senden)

Nachrichtenname: „cim_send_data_req"
Quelle: Anwendung
Ziel: Basisfunktion CIM-Befehl Datenübertragung
Antwort: „cim_send_data_res" (Antwort der Chipkarte) „cim_status_ind" (ein Fehler ist passiert)
Beschreibung: Mit dieser Nachricht werden Befehle oder Daten, die an die Chipkarte zu übermitteln sind, an die Grundfunktion gesendet. Die Nachricht wird entweder durch die Antwort der Chipkarte (positive Bestätigung) oder durch die Statusnachricht (negative Bestätigung) bestätigt.
Die „cim_send_data_req"-Nachricht enthält einen Nachrichtenidentifizierer <msg_id>, die Kanalnummer <channel_no>, die Datenlänge <data_length> und die Daten <data>.
Syntax: <msg_id>, <channel_no>, <data_length>, <data>
Definierte Werte: <msg_id>: ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.
<data_length>: Länge der <data> in Bytes
<data>: Befehl/Daten, der/die an die Chipkarte zu senden ist/sind.

3.2.5.4 Nachricht „cim_send_data_response" (CIM-Datenantwort senden)

Nachrichtenname: „cim_send_data_res"
Quelle: Basisfunktion CIM-Befehl Datenübermittlung
Ziel: Anwendung
Beschreibung: Mit dieser Nachricht werden die Antwortdaten der Chipkarte an die anfragende Anwendung gesendet. Die „cim_send_data_res"-Nachricht enthält den Nachrichtenidentifizierer <msg_id>, die Kanalnummer <channel_no>, die Datenlänge <data_length> und die Daten <data>.
Syntax: <msg_id>, <channel_no>, <data_length>, <data>
Definierte Werte: <msg_id>: ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation
<data_length>: Länge der <data> in Bytes
<data>: Befehl/Daten, der/die an die Chipkarte zu senden ist/sind.

3.2.5.5 Nachricht „cim_status_request" (CIM-Statusanfrage)

Nachrichtenname: „cim_status_req"
Quelle: Anwendung
Ziel: Basisfunktion CIM-Befehl Datenübertragung
Antwort: „cim_status_ind"
Beschreibung: Diese Nachricht wird verwendet, um den Status von CIM anzufragen.
Die Nachricht enthält lediglich den Nachrichtenidentifizierer <msg_id>.
Syntax: <msg_id>
Definierte Werte: <msg_id>: ist zu definieren

3.2.5.6 Nachricht „cim_status_indication" (CIM-Statusanzeige)

Nachrichtenname: „cim_status_ind"
Quelle: Basisfunktion CIM-Befehl Datenübertragung
Ziel: Anwendung
Beschreibung: Diese Nachricht wird verwendet, um die Anwendung über einen Fehler oder eine vorgekommene unerwartete Aktion oder über die Änderung des Statusses der Ausrüstung zu informieren.
Wenn die „cim_status_ind"-Nachricht empfangen wird, muss die Anwendung über weitere Aktionen entscheiden, wenn ein Fehler passiert.
Die Nachricht enthält den Nachrichtenidentifizierer <msg_id> und die Statusinformation <status>.
Syntax: <msg_id>, <status>
Definierte Werte: <msg_id>: ist zu definieren
<status>: Statusinformation hinsichtlich eines Fehlers, einer unerwarteten Aktion oder des Statusses der Ausrüstung.

3.2.5.7 Nachricht „cim_close_application_request" (CIM-Anwqendungsanfrage schließen)

Nachrichtenname: „cim_close_application_req"
Quelle: Anwendung
Ziel: Basisfunktion CIM-Anwendung schließen
Beschreibung: Diese Nachricht wird von der Anwendung verwendet, um den logischen Kommunikationskanal zwischen der Anwendung und der Grundfunktion zu schließen.
Die Nachricht enthält den Nachrichtenidentifizierer <msg_id> und die Kanalnummer <channel_no>,
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id: ist zu definieren <channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.5.8 Nachricht „cim_close_application_confirmation" (CIM-Anwendungsbestätigung schließen)

Nachrichtenname: „cim_close_application_con"
Quelle: Basisfunktion CIM-Anwendung schließen)
Ziel: Anwendung
Beschreibung: Diese Nachricht wird verwendet, um der anfragenden Anwendung zu bestätigen, dass der logische Kommunikationskanal zwischen der Anwendung und der Basisfunktion geschlossen worden ist. Die Kommunikation mit der Chipkarte ist beendet worden.
Die Nachricht enhält den Nachrichtenidentifizierer <msg_id> und die Kanalnummer <channel_no>.
Syntax: <msg_id>, <channel_no>
Definierte Werte: <msg_id>: ist zu definieren
<channel_no>: Identifizierer des logischen Kommunikationskanals für die angefragte Kommunikation.

3.2.6 Nachrichten, die sich auf das Zwischensystem Input/Output beziehen
In diesem Kapitel werden die Nachrichten beschrieben, die sich auf die verschiedenen Input-/Output(I/O)-Basisfunktionen beziehen. Die Übertragung der Nachrichten zwischen den Anwendungen und den I/O-Basisfunktionen erfolgt mit Hilfe der folgenden Nachrichten:
bezogen auf I/O-Basisfunktion I/O-Informationsdarstellung

– io_display_information_request (I/O-Informationsanfrage darstellen)
– io_display_information_confirmation (I/O-Informationsbestätigung darstellen)
– io_display_information_acknowledgement (I/O-Informationsbestätigung darstellen)
– io_display_information_interruption (I/O-Informationsunterbrechung darstellen)
– io_display_information_rejection (I/O-Informationsrückweisung darstellen)
– io_display_information_finish_request (I/O-Informationsbeendigungsanfrage darstellen)
– io_display_information_finish_acknoledgement (I/O-Informationsbeendigungsbestätigung darstellen)
– io_display-type-request (I/O-Typenanfrage darstellen)
– io_display-type-result (I/O-Typenergebnis darstellen)

– io_input_device_request (I/O-Vorrichtungsanfrage eingeben)
– io_input_device_acknowledge (I/O-Vorrichtungsbestätigung eingeben)
– io_input_device_reject (I/O-Vorrichtungsrückweisung eingeben)
– io_enter_data_request (I/O-Datenanfrage eingeben)
– io_enter_data_confirmation (I/O-Datenbestätigung eingeben)
– io_enter_data_result (I/O-Datenergebnis eingeben)
– io_enter_data_acknowledge (I/O-Datenbestätigung eingeben)
– io_enter_data_reject (I/O-Datenrückweisung eingeben)
– io_input_device_type_request (I/O-Vorrichtungstypenanfrage eingeben)
– io_input_device_type_result (I/O-Vorrichtungstypenergebnis eingeben)

Einige Beispiele von Nachrichtenübermittlungen, bezogen auf die Input-/Output-Vorrichtung, sind in einem Flussdiagramm beschrieben, das die allgemeine Arbeitsweise miteinander (interworking) und das Zeitfolgediagramm auf den nachfolgenden Seiten zeigt.

3.2.6-1: Phasendiagramm, bezogen auf die I/O-Basisfunktion Informationsdarstellung
3.2.6-2: Zeitfolgediagramm, bezogen auf die I/O-Basisfunktion Informationsdarstellung
3.2.6-3: Zeitfolgediagramm, bezogen auf die I/O-Basisfunktion Informationsdarstellung
3.2.6-4: Zeitfolgediagramm, bezogen auf die I/O-Basisfunktion Informationsdarstellung
3.2.6-5: Zeitfolgediagramm, bezogen auf die I/O-Basisfunktion Informationsdarstellung
3.2.6-6: Zeitfolgediagramm, bezogen auf die I/O-Basisfunktion Dateneingabe
3.2.6-7: Zeitfolgediagramm, bezogen auf die I/O-Basisfunktion Dateneingabe

3.2.6.1 Nachricht „io_display_information_request" (I/O-nformationsanfrage darstellen)

Nachrichtenname: „io_display_information_req"
Quelle: Anwendung oder irgendeine andere Basisfunktion
Ziel: Basisfunktion: I/O-Informationen darstellen
Antwort: „io_display_information_con" „io_display-information_ack" „io_display_information_int" „io_display_information_rej"
Beschreibung: Diese Nachricht wird von Anwendungen und Basisfunktionen verwendet, um Daten auf der Input-/Output-Vorrichtung darzustellen. Die Anfrage enthält Informationen, die darzustellen sind, als auch die Steuerinformationen des Displays.
Wenn eine Anwendung eine Informationsanfrage zur Darstellung an ein Displaygerät sendet, das zur Anfragezeit außer Betrieb ist oder zu dem die Anwendung kein Zugangsrecht hat, weist die Grundfunktion die Anfrage zurück. Wenn das Display nicht mit einer anderen Aufgabe belegt ist, wird die Informationsanfrage zur Darstellung angenommen, und eine „io_display_information_confirmation"-Nachricht wird an den Absender der Anfrage gesendet. Wenn die Informationen über einen Zeitraum von <t_dur> dargestellt werden, wird eine „io_display_information_acknowledgement"-Nachricht gesendet.
Wenn eine „io_display-information_request" einer anderen Anwendung mit höherer Anfragepriorität während des Zeitraums <t_dur> anfällt, wird die aktuelle Informationsdarstellung unterbrochen, und eine „io_display_information_interruption"-Nachricht wird an den Urheber der entsprechenden Anwendung gesendet.
Wenn die „io_display_information_request" eine geringere oder gleiche Anfragepriorität hat als die aktuell dargestellten Informationen, wird die Anfrage in eine Wartechlange gestellt. Wenn die Zeitdauer in der Warteschlange länger als der vordefinierte Wert ist, wird die „io_display_information_request" zurückgewiesen.
Syntax: <msg_id>, <io_id>, <info_typ>, <t_dur>, <t_queue>, >session_id>, <finish_typ>, <info_length>, <info>, <adj>, <format>, , <size>
Definierte Werte: <msg_id>: ist zu definieren
<io_id>: Identifizierer der Input-/Output-Vorrichtung, auf der die Informationen dargestellt werden sollen.
<info_typ>: Informationstyp; mögliche Werte sind:

b – Bit-Karte
c – Schriftzeichen
p – vordefinierte/s Nachricht/Symbol

<t_dur>: Mindestdauer in Sekunden, während der die Informationen dargestellt werden müssen.
<t_queue>: maximale Zeit des Verbleibens in der Warteschlange bis zur Rückweisung seitens des Displays.
<session_id>: ID einer Display-/Input-Session mit einer Anzahl an Informationen, die zusammen darzustellen sind, und Eingabedaten, die vom Nutzer einzugeben sind. Diese Display-/Input-Aktionen gehören zusammen und sollen bei einer Anfrage zur Darstellung mit gleicher Priorität nicht unterbrochen werden.
<finish_type>: Art, die Darstellung von Informationen zu beenden; mögliche Werte sind:

c – weiterlaufende Darstellung von Informationen; wo die Dauer der Darstellung
<t_dur> überschritten wird, wird der Status der Darstellung auf „accessible" (zugänglich) eingestellt, aber das Display hält die alten Informationen fest, bis neue Informationen darzustellen sind.
a – nur über den Befehl „io_display_information_finish_request" der Anwendung oder Basisfunktio des Urhebers zu beenden

<info_length>: Länge der Informationen in Byte
<info>: darzustellende Informationen
<adj>: Anpassungsinformationen mögliche Werte sind: s – Standard v – vertikal zentriert h – horizontal zentriert x – Sonderformatierung der Informationen
Wenn <adj> = „x", dann werden die folgenden zusätzlichen Parameter in die Parameterstruktur mit einbeschlossen:
<format>: Formatierungsinformationen mögliche Werte sind: b – (halb)fett i – kursiv u – unterstrichen
: Schriftzeichen-Schriftsatz
<size>: Schriftzeichengröße mögliche Werte in pt

3.2.6.2 Nachricht „io_display-information_reject" (I/O-Informationsrückweisung darstellen)

Nachrichtenname: „io_display_information_rej"
Quelle: Basisfunktion: I/O-Informationen darstellen
Ziel: anfragende Anwendung oder Grundfunktion
Beschreibung: Eine „io_display_information_reject"-Nachricht wird aus zwei Gründen gesendet:

– Zugang zur Basisfunktion nicht möglich
– t_queue überschritten

Wenn eine Anwendung oder eine Basisfunktion eine Anfrage zur Darstellung von Informationen an ein Displaygerät <io_id> sendet, das zur Anfragezeit außer Betrieb ist oder zu dem die Anwendung kein Zugangsrecht hat, sendet die Basisfunktion die „io_display_information_reject"-Nachricht an die anfragende Anwendung oder Basisfunktion.
Wenn die „io_display_information_request" eine geringere oder gleiche Anfragepriorität als die aktuell dargestellten Informationen hat, wird die Anfrage in eine Warteschlange gesetzt. Wenn die Wartezeit in der Warteschlange länger als der Wert <t_queue> ist, wird die Anfrage zurückgewiesen.
Syntax: <msg_id>, <rej_stat>
Definierte Werte: <msg_id>: ist zu definieren
<rej_stat>: Grund für die Zurückweisung mögliche Werte sind: na – Zugangsverweigerung no – Displaygerät außer Betrieb te – Zeit überschritten (t_queue)

3.2.6.3 Nachricht „io_display_information_confirmation" (I/O-Informationsbestätigung darstellen)

Nachrichtenname: „io_display_information_con"
Quelle: Basisfunktion: I/O-Informationen darstellen
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Wenn das in Betrieb befindliche Display und die anfragende Anwendung oder Basisfunktion eine Zugangsberechtigung haben, wird die „io_display-information_request" angenommen, und eine „io_display_information_confirmation"-Nachricht wird an den Urheber der Anfrage gesendet.
Syntax: <msg_id>, <con_status>
Definierte Werte: <msg_id>: ist zu definieren
<con_status>: Status der Bestätigung mögliche Werte sind: d – Informationen dargestellt q – Informationsanfrage befindet sich in der Warteschlange

3.2.6.4 Nachricht „io_display_information_interruption" (I/O-Informationsunterbrechung darstellen)

Nachrichtenname: „io_display_information_int"
Quelle: Basisfunktion: I/O-Informationen darstellen
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Wenn eine „io_display_information_request" einer anderen Anwendung mit einer höheren Anfragepriorität während des Zeitraums <t_dur> anfällt, werden die aktuell dargestellten Informationen unterbrochen, und eine „io_display_information_interruption"-Nachricht wird an den Urheber des unterbrochenen Anwendungsdisplays gesendet.
Syntax: <msg_id>, <int_reason>
Definierte Werte: <msg_id>: ist zu definieren
<int_reason>: Grund für die Unterbrechung mögliche Werte sind: nr – neue Anfrage einer Anwendung oder Basisfunktion mit höherer Anfragepriorität qr – Die Priorität einer in der Warteschlange befindlichen „io_display_information_request" ist höher als die Priorität der aktuell dargestellten Informationen.

3.2.6.5 Nachricht „io_display_information_acknowledge" (I/O-Informationsbestätigung darstellen

Nachrichtenname: „io_display_information_ack"
Quelle: Basisfunktion: I/O-Informationen darstellen
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Wenn die Informationen über einen Zeitraum von <t_dur> hinweg dargestellt werden, wird diese Nachricht an den Urheber der Anfrage gesendet. Mit dieser Nachricht ist die Arbeit des Displays, die angefragten Informationen darzustellen, beendet.
Wenn <finish_type> = „c" (Parameter der „io_display_information_request"), wird das Display auf „accessible" (zugänglich) eingestellt. Mit einer neuen „io_display_information_request" wird der aktuelle Inhalt des Displays gelöscht. Wenn <finsih_type> = „a" (Parameter der „io_display_information-request") ist, verbleibt der Status des Displays bei „busy" (besetzt), bis der Urheber der dargestellten Nachricht die dargestellten Informationen mit einer „io_display_information_finish-request" unterbricht.
Syntax: <msg_id>
Definierte Werte: <msg_id>: ist zu definieren

3.2.6.6 Nachricht „io_display_information_finish_request" (I/O-Anfrage über das Ende der Informationsdarstellung)

Nachrichtenname: „io_display_information_finish-req"
Quelle: anfragende Anwendung oder Basisfunktion
Antwort: „io_display-information_finish_ack"
Beschreibung: Mit dieser Nachricht werden die folgenden Aktionen initiiert:
Wenn die „io_display_information_request" bereits beendet ist, werden die dargestellten Informationen in der Input-/Output-Vorrichtung entfernt.
Wenn sich die „io_display_information_request" noch in der Warteschlange befindet und auf den Zugang zum Display wartet, wird sie jetzt aus der Warteschlange herausgenommen (Anwendung initiiert).
Wenn die zu beendende „io_display_information_request" Teil einer Anzahl von unabhängigen „io_display_information-requests" (Parameter <session_id> in der „io_display_information_request") ist, wird mit dem Parameter <del_session> definiert, welche Aktion mit der anderen „io_display_information_request" dieser Session stattfindet.
Syntax: <msg_id>, <io_id>, <del_session>
Definierte Werte: <msg_id>: ist zu definieren
<io_id>: Identifizierer der Input-/Output-Vorrichtung, von der die Informationen darzustellen sind.
<del_session>: Aktion für die anderen Anfragen mit derselben ID-Session id; mögliche Werte sind: n – keine Beendigung der anderen „io_display_information_requests" derselben Session; nur die identifizierte „io_display_information_request" wird aus der Warteschlange herausgenommen oder aus dem Display entfernt. y – Alle „io_display_information_requests" derselben Session und desselben Urhebers werden aus der Warteschlange herausgenommen oder aus dem Display entfernt.

3.2.6.7 Nachricht „io_display_information_finish_acknowledge" (I/O-Bestätigung des Endes der Informationsdarstellung)

Nachrichtenname: „io_display_information_finish_ack"
Quelle: Basisfunktion: I/O-Informationen darstellen
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Wenn die mit „io_display_information_finish_req" angefragten Aktionen durchgeführt wurden, wird die „io_display_infomation_finish_ack"-Nachricht an den Urheber der Anfrage gesendet.
Syntex: <msg_id>
Definierte Werte: <msg_id>: ist zu bestätigen

3.2.6.8 Nachricht „io_display_type_request" (I/O-Typenanfrage darstellen)

Nachrichtenname: „io_display_type_req"
suelle: anfragende Anwendung oder Basisfunktion
Ziel: Basisfunktion: I/O-Informationen darstellen
Antwort: „io_display_type_res"
Beschreibung: Mit dieser Nachricht fragt die Anwendung oder die Basisfunktion die Verwendung der Input-/Outputvorrichtung an, die mit <io_id> identifiziert worden ist. Mit der Antwortnachricht „io_display_type_res" wird die Anwendung über ihr Zugangsrecht zur erwähnten Input-/Output-Vorrichtung informiert
Syntax: <msg_id>, <io_id>
Definierte Werte: <msg_id>: ist zu definieren
<io_id>: Identifizierer der Input-/Output-Vorrichtung, von der die Informationen darzustellen sind.

3.2.6.9 Nachricht „io_display_type_result" (I/O-Typenergebnis darstellen)

Nachrichtenname: „io_display_type_res"
Quelle: Basisfunktion: I/O-Informationen darstellen
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Mit dieser Nachricht informiert die Basisfunktion die anfragende Anwendung oder Basisfunktion über ihr Zugangsrecht zur entsprechenden Input-/Output-Vorrichtung.
Syntax: <msg_id>, <access_stat>
Defineirte Werte: <msg_id>: ist zu definieren
<access_stat>: Zugangsstatus für die Input-/Output-Vorrichtung mögliche Werte sind: n – kein Zugang y – Zugang gewährt; nur anfragende Anwendung c – Zugang gewährt; herkömmlich verwendete Input-/Output-Vorrichtung (alle Anwendungen) m – Zugang gewährt; wird von Mehrfachanwendungen verwendet

3.2.6.10 Nachricht „io_input_device_request" (I/O-Anfrage über die Eingabevorrichtung)

Nachrichtenname: „io_input_device_req"
Quelle: anfragende Anwendung oder Basisfunktion
Ziel: Basisfunktion I/O-Dateneingabe
Antwort: „io_input_device_ack", „io_input_device_rej"
Beschreibung: Wenn eine Anwendung oder eine Basisfunktion um die Eingabe von Daten anfragt, muss zuerst geprüft werden, ob die Input-Vorrichtung zugänglich ist oder ob sie für eine andere Anwendung in Betrieb ist. Eine „io_input_device_req" wird an die Input-Vorrichtung gesendet.
Wenn die Input-Vorrichtung zugänglich ist, wird die Input-Vorrichtung verbunden, und eine „io_input_device_ack"-Nachricht wird an die anfragende Anwendung gesendet.
Die Input-Vorrichtung ist für Anfragen anderer Anwendungen blockiert. Ihr Status wird auf „busy" (besetzt) gestellt.
Wenn die Input-Vorrichtung besetzt ist, wird eine „io_input_device_rej" an die anfragende Anwendung gesendet. Der Grund für die Zurückweisung wird ebenfalls als Statusparameter gesendet. Der Status kann „busy" (besetzt) oder „access_not_allowed" (Zugang nicht gewährt) sein.
Eine Anwendung trennt sich von einer Input-Vorrichtung ebenfalls mit einer „io_input_device_req"-Nachricht (<attach>=no)
Syntax: <msg_id>, <in_dev_id>, <attach>
Definierte Werte: <msg_id>: ist zu definieren
<in_dev_id>: Identifizierer der ausgewählten Input-Vorrichtung, von der aus Daten eingegeben werden sollten.
<attach>: unterscheidet zwischen verbinden mit und trennen von der Input-Vorrichtung. yes – mit Input-Vorrichtung verbinden no – von Input-Vorrichtung trennen

3.2.6.11 Nachricht „io_input_device_acknowledge" (I/O-Eingabevorrichtungsbestätigung)

Nachrichtenname: „io_input_device_ack"
Quelle: Basisfunktion I/O-Dateneingabe
Ziel: Anfrage der Anwendung oder Basis
Antwort: keine
Beschreibung: Diese Nachricht ist die Antwort auf eine „io_input_device_request". In dem Fall, dass die Input-Vorrichtung zugänglich ist und die anfragende Anwendung das Zugangsrecht zur Input-Vorrichtung hat, wird die Input-Vorrichtung mit der anfragenden Anwendung verbunden. Der Status der Input-Vorrichtung wird auf „busy" (besetzt) gestellt, und die io_input_device_ack"-Nachricht wird an die anfragende Anwendung gesendet.
Syntax: <msg_id>
Definierte Werte: <msg_id>: ist zu definieren

3.2.6.12 Nachricht „io_input_device_reject" (I/O-Rückweisung der Eingabevorrichtung)

Nachrichtenname: „io_input_device_req"
Quelle: Basisfunktion I/O-Dateneingabe
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Diese Nachricht ist die Antwort auf eine „io_input_device_request". In dem Fall, dass die Input-Vorrichtung „busy" (besetzt) ist oder die anfragende Anwendung hat kein Zugangsrecht zur Input-Vorrichtung, wird die Anfrage zurückgewiesen. Eine „io_input_device_rej"-Nachricht wird an die anfragende Anwendung oder Basisfunktion gesendet. Die Nachricht enthält einen Parameter <status> mit der Angabe des Grundes der Zurückweisung.
Syntax: <msg_id>, <status>
Definierte Werte: <msg_id>: ist zu definieren
<status>: Grund für die Rückweisung mögliche Werte sind: busy (besetzt) – Vorrichtung wird derzeit mit einer anderen Anwendung verbunden na – Zugang zur ausgewählten Input-Vorrichtung wird nicht gewährt no – die Input-Vorrichtung ist derzeit nicht verfügbar

3.2.6.13 Nachricht „io_enter_data_request" (I/O-Datenanfrage eingeben)

Nachrichtenname: „io_enter_data_req"
Quelle: anfragende Anwendung oder Basisfunktion
Ziel: Basisfunktion I/O-Dateneingabe
Antwort: „io_enter_data_con", „io_enter_data_res", „io_enter_date_rej"
Beschreibung: Wenn die Anwendung oder eine Basisfunktion Input-Daten vom Nutzer benötigt, muss sie die folgenden Aktionen durchführen:

a. prüfen, ob die Input-Vorrichtung für eine Verbindung zugänglich ist („io_input_device_req");
b. eine „enter data message" (Datennachricht eingeben) auf der input-/Output-Vorrichtung darstellen („io_display_information_req")
c. eine „enter data request" (Datenanfrage eingeben) an die Input-/Output-Vorrichtung erzeugen („io_enter_data_req")

Die erste durchzuführende Aktion ist die Verbindung mit einer Input-Vorrichtung. Dann muss als zweite Aktion dem Nutzer gesagt werden, dass eine Anwendung Eingabedaten benötigt. Dies wird vielleicht mit einem akustischen Signal (Anfrage durch Pieper oder Stimme) und mit einer Informationsdarstellung durchgeführt, die die erwartete Aktion seitens des Nutzers beschreibt.
Wenn die „enter data message" (Datennachricht eingeben) dargestellt wird („io_display_enter_con"), fragt die Anwendung die Eingabedaten an. Eine „io_enter_dat_req" wird an die ausgewählte Input-Vorrichtung gesendet. Die Input-Vorrichtung antwortet mit einer „io_enter_data_con"-Nachricht.
Mit der Annahme der „io_enter_data_req" („io_data_req_con") wird eine Übenwachungseinheit in der Übersetzer-/Input-Vorrichtung aktiviert. Dies geschieht zur Kontrolle, dass der Nutzer die Eingabedaten innerhalb eines maximalen Zeitraums eingibt. Der Zeitgeberparameter für die Überwachungseinheit ist Teil der „io_enter_data_req" (<timer>). Wenn der Nutzer eine Daten- oder Event-Taste drückt, wird die Überwachungseinheit stets mit dem Inhalt des <timer> neu gestartet. Wenn der Nutzer keine Taste innerhalb des Zeitraums <timer> drückt, weist die Überwachungseinheit die Datenanfrage mit einer „io_enter_data_rej"-Nachricht zurück.
Mit dem Parameter <typs> der „io_enter_data_req" wird unterschieden, ob die Anwendung ein einzelnes Schriftzeichen oder ein Schriftzeichenband als Antwort erwartet. Wenn die Anwendung ein Schriftzeichenband erwartet, müssen alle Schriftzeicheneingaben in der Übersetzer-/Input-Vorrichtung gesammelt werden, bis der Nutzer eine Event-Taste drückt. Wenn der Nutzer die Event-Taste „enter" (eingeben) drückt, werden die gesammelten Daten mit der Nachricht „io_enter_data_res" an die anfragende Anwendung gesendet. Wenn der Nutzer die Event-Taste „cancel" (annullieren) drückt, werden die gesammelten Daten gelöscht, und eine „io_enter_data_rej"-Nachricht wird an die Anwendung gesendet.
Falls die Anwendung ein einzelnes Schriftzeichen erwartet, sendet die Input-Vorrichtung jedes eingegebene Schriftzeichen mit einer entsprechenden „io_enter_data_res"-Nachricht an die Anwendung. Die Anwendung kann das Schriftzeichen jetzt prüfen und über das Senden einer neuen „input-data-message" (Datennachricht eingeben) entscheiden (d. h. das neue mögliche Schriftzeichen, um den Namen einer Stadt an dritter Position abhängig von den beiden ersten Schriftzeichen einzugeben, die der Nutzer eingegeben hat). Dies wird wiederholt, bis die Event-Taste gedrückt wird.
Wenn eine weitere Event-Taste wie „menue" gedrückt wird, sendet die Input-/Übersetzer-Vorrichtung eine „io_denter_data_ind"-Nachricht an die anfragende Anwendung. Die Anwendung entscheidet über die nachfolgenden Aktionen. Wenn es derzeit keine „enter_data_request" (Datenanfrage eingeben) gibt, werden die Event-Tasten von einer besonderen Anwendung gesteuert, die die Aktion des Nutzers interpretiert und Anwendungsaktionen initiiert.
Im Allgemeinen müssen alle vom Nutzer eingegebenen Schriftzeichen auf einem entsprechenden Display <io_id> dargestellt werden. Abhängig von der Input-Output-Vorrichtung ist es möglich, dass die „enter data message" (Datennachricht eingeben) zusammen mit den eingegebenen Daten auf der Input-Output-Vorrichtung dargestellt wird oder dass die „io_enter_data"-Nachricht mit dem ersteingegebenen Schriftzeichen gelöscht wird. Für besondere Zwecke, d. h. Eingabe eines Pins, muss dieses Merkmal <displ_ch> verhindert/zurückgehalten werden. In diesem Fall muss ein besonderes Schriftzeichen wie """ auf der Input-Output-Vorrichtung dargestellt werden.
Wenn ein Nutzer die angefragten Daten eingegeben hat, beendet er seine Eingabeaktion mit der Event-Taste „enter". Wenn die eingegebenen Daten an die anfragende Anwendnung gesendet wurden, wird die „enter data request" (Datenanfrage eingeben) durch Senden einer „io_enter_data_ack"-Nachricht beendet.
Syntax: <msg_id>, <in_dev_id>, <io_id>, <type>, <timer>, <displ_char>, <session_id>, <finish_typ>, <adj>, <format>, , <size> Definierte Werte: <msg_id>: ist zu definieren
<in_dev_id>: Identifizierer der ausgewählten Input-Vorrichtung, von der Daten eingegeben werden sollten.
<io_id>: Identifizierer der Input-Output-Vorrichtung, auf der die Informationen darzustellen sind.
<type>: Identifizierer für die Art der erwarteten Eingabedaten; mögliche Werte sind. c – erwartetes einzelnes Schriftzeichen s – erwartetes Band
<timer>: Zeitgeberkonstante für die Überwachungseinheit (in Sekunden)
<displ_char>: ermittelt, ob das eingegebene Schriftzeichen auf der Input-/Output-Vorrichtung dargestellt wird; mögliche Werte sind: yes – eingegebenes Schriftzeichen wird auf der Input-/Output-Einrichtung (Fehler) dargestellt no – eingegebenes Schriftzeichen wird nicht auf der Input-/Output-Vorrichtung dargestellt; als Ersatz muss das Schriftzeichen "*" dargestellt werden.
<sesssion-id>: ID der Darstellungs-/Input-Session mit einer Anzahl von Informationen, die zusammen darzustellen sind, und vom Nutzer einzugebende Eingabedaten. Diese Darstellungs-/Input-Aktionen gehören zusammen und sollen nicht durch eine Darstellungsanfrage mit gleicher Priorität gestört werden.
<finish_typ>: Art der Beendigung der Darstellung von Informationen; mögliche Werte sind:

a – nur durch den Befehl „io_display_information_finish_request" der Anwendung oder Basisfunktion zu beenden, die die „io_display_information_request" veranlasst hat.

<adj>: Anpassung von eingegebenen Daten mögliche Werte sind: s – Standard v – vertikal zentriert h – horizontal zentriert x – Sonderformatierung der Informationen; wenn <adj>= „x" ist, dann sind die nachfolgenden Parameter in der Parameterstruktur enthalten: <format>: Formatierungsinformationen mögliche Werte sind: b – (halb)fett i – kursiv u – unterstrichen : Schriftzeichen-Schriftsatz Schriftzeichengröße mögliche Werte in pt

3.2.6.14 Nachricht „io_enter_data_confirmation" (I/O-Datenbestätigung eingeben)

Nachrichtenname: „io_enter_data_con"
Quelle: Basisfunktion I/O-Dateneingabe
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Wenn eine Anwendung nach Eingabedaten anfragt, wird eine „io_enter_data_req"-Nachricht an die ausgewählte Input-Vorrichtung gesendet. Im Falle der Bestätigung antwortet die Input-Vorrichtung der Anwendung mit einer „io_enter_data_con"-Nachricht. Die Input-Vorrichtung ist nun bereit, Eingabedaten vom Nutzer zu empfangen. Die Funktion der Überwachungseinheit zur Steuerung der Dauer zwischen der einzelnen Eingabeaktion wird aktiviert.
Syntax: <msg_id>
Definierte Werte: <msg_id>: ist zu definieren

3.2.6.15 Nachricht „io_enter_data_acknowledge" (I/O-Datenbestätigung eingeben)

Nachrichtenname: „ie_enter_data_ack"
Quelle: Basisfunktion I/O-Dateneingabe
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Wenn ein Nutzer die angefragten Daten eingegeben hat, beendet er seine Eingabeaktion mit der Event-Taste „enter". Wenn die eingegebenen Daten zur anfragenden Anwendung gesendet werden, wird die „enter data request" (Datenanfrage eingeben) durch das Senden einer „io_enter_data_ack"-Nachricht beendet.
Syntax: <msg_id>
Definierte Werte: <msg_id>: ist zu definieren

3.2.6.16 Nachricht „io_enter_data_result" (I/O-Datenergebnis eingeben)

Nachrichtenname: „io_enter_data_res"
Quelle: Basisfunktion I/O-Dateneingabe
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Mit dem Parameter <type> der „io_enter_data_req" wird unterschieden, ob die Anwendung ein einzelnes Schriftzeichen oder ein Schriftzeichenband als Antwort erwartet. Falls die Anwendung ein Schriftzeichenband erwartet, müssen alle Schriftzeicheneingaben in der Übersetzer-/Input-Vorrichtung gesammelt werden, bis der Nutzer die Event-Taste drückt. Wenn der Nutzer die Event-Taste „enter" drückt, werden die gesammelten Daten an die anfragende Anwendung mit der Nachricht „io_enter_data_res" gesendet.
Falls eine Anwendung ein einzelnes Schriftzeichen erwartet, sendet die Input-Vorrichtung jedes einzelne Schriftzeichen mit einer entsprechenden „io_enter_data_res"-Nachricht (d. h. das neue mögliche Schriftzeichen, um den Namen einer Stadt an dritter Position, abhängig von den beiden ersten Schriftzeichen, einzugeben, die der Nutzer eingegeben hat). Dies wird wiederholt, bis die Event-Taste gedrückt wird.
Syntax: <msg_id>, <data_length>, <data>
Definierte Werte: <msg_id>: ist zu definieren
<data_length>: Länge der eingegebenen Eingabedaten
<data>: Eingabedaten des Nutzers

3.2.6.17 Nachricht „io_enter_data_reject" (I/O-Datenrückweisung eingeben)

Nachrichtenname: „io_enter_data_rej"
Quelle: Basisfunktion I/O-Dateneingabe
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Um Eingabedaten von einem Nutzer zu bekommen, wird eine „io_enter_data-request" (I/O-Datenanfrage eingeben) an die Input-Vorrichtung gesendet. Eine „io_enter_data_rej"-Nachricht (Datenrückweisung eingeben) wird von der Basisfunktion an die anfragende Anwendung in den nachfolgend beschriebenen Fällen gesendet. Wenn eine Anwendung Zugang zu einer Input-Vorrichtung haben möchte und diese Vorrichtung ist nicht in Betrieb oder die Anwendung hat kein Zugangsrecht zu jener Input-Vorrichtung (derzeit oder ständig), wird eine „io_enter_data_rej"-Nachricht gesendet. Der Grund für die Zurückweisung ist in jener Nachricht <con_status> enthalten. Wenn während der Zeit der Eingabe ein Fehler auftritt, werden Aktionen stattfinden, obgleich eine „io_enter_data_rej"-Nachricht gesendet wird. Wenn die Zeit zwischen zwei Eingabeaktionen (d. h. das Drücken einer Datentaste) das Limit überschreitet, unterbricht eine Funktion der Überwachungseinheit die „io_enter_data_request" und sendet eine „io_enter_data-rej"-Nachricht.
Wenn ein Nutzer die Eingabe von Daten unterbricht, indem er die Event-Taste <cancel> drückt, wird eine „io_enter_data_rej"-Nachricht an die anfragende Anwendung gesendet werden.
Syntax: <msg-id>, <rej_status>
Definierte Werte: <msg_id>: ist zu definieren
<rej_status>: Grund für die Zurückweisung der „io_enter_data_request"; mögliche Werte sind: c – annullieren (Event-Taste), vom Nutzer initiiert t – Zeitbegrenzung (Zeit überschritten) na – kein Zugang gewährt no – nicht in Betrieb

3.2.6.18 Nachricht „io_enter_data_indication" (I/O-Datenanzeige eingeben)

Nachrichtenname: „io_enter_data_ind"
Quelle: Basisfunktion I/O-Dateneingabe
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Wenn der Nutzer eine Event-Taste wie „menue" drückt, sendet die Übersetzer-/Input-Vorrichtung eine „io_enter_data_ind"-Nachricht an die anfragende Anwendung. Die Anwendung entscheidet über die nachfolgenden Aktionen. Wenn es derzeit keine "enter data request" (Datenanfrage eingeben) gibt, die auszuarbeiten ist, werden die Event-Tasten von einer Sonderanwendung gesteuert, die die Aktion des Nutzers interpretiert und Anwendungsaktionen initiiert.
Syntax: <msg_id>, <key_code>, <req_status>
Definierte Werte: <msg_id>: ist zu definieren
<key_code>: Identifizierer für die Taste, die der Nutzer betätigt hat mögliche Werte sind: menue – Taste zur Eingabe eines Menüs up-cursor – Cursor nach oben down-cursor- Cursor nach unten help – Taste für Hilfe
<req_status>: Zugangsstatus der Input-Vorrichtung mögliche Werte sind: a – zugänglich b – besetzt

3.2.6.19 Nachricht „io_input_device_type_request" (I/O-Vorrichtungstypanfrage eingeben)

Nachrichtenname: „io_input_device_type_req"
Quelle: anfragende Anwendung oder Basisfunktion
Ziel: Basisfunktion I/O-Dateneingabe
Antwort: „io_input_device_type_res"
Beschreibung: Mit dieser Nachricht fragt die Anwendung oder die Basisfunktion die Verwendung der Input-Vorrichtung an, die mit <in_dev_id> identifiziert wurde. Mit der Antwortnachricht „io_input_device_type_res" wird die Anwendung über ihr Zugangsrecht zur erwähnten Input-Vorrichtung informiert.
Syntax: <msg_id>, <in_dev_id>
Definierte Werte: <msg_id>: ist zu definieren
<in_dev_id>: Identifizierer der ausgewählten Input-Vorrichtung, von der aus Daten eingegeben werden sollten.

3.2.6.20 Nachricht „io_input_device_type_result" (I/O-Vorrichtungstypergebnis eingeben)

Nachrichtenname: „io_input_device_type_res"
Quelle: Basisfunktion I/O-Dateneingabe
Ziel: anfragende Anwendung oder Basisfunktion
Antwort: keine
Beschreibung: Mit dieser Nachricht informiert die Basisfunktion die anfragende Anwendung oder Basisfunktion über ihr Zugangsrecht zur erwähnten Input-Vorrichtung.
Syntax: <msg_id>, <access_stat>
Definierte Werte: <msg_id>: ist zu definieren
<access_stat>: Zugangsstatus für die Input-Vorrichtung mögliche Werte sind: n – kein Zugang y – Zugang gewährt; nur anfragende Anwendung c – Zugang gewährt; herkömmlich verwendete Input-Vorrichtung (alle Anwendungen) m – Zugang gewährt; wird von Mehrfachanwendungen angewendet

4 Standard-Kommunikations-Schnittstelle
Die Basisvorrichtung wurde konstruiert, um die Integration von Verkehrstelematikanwendungen und entsprechenden Input-/Output-Vorrichtungen zu ermöglichen, aber auch, um eine Standard-Kommunikations-Schnittstelle (SCI) zur Verbindung von externen Vorrichtungen bereitzustellen. Dies ist nützlich, um die Basisvorrichtung mit Anwendungen zu erweitern, die derzeit verfügbar sind, oder um neue Anwendungen oder Vorrichtungen hinzuzufügen, wenn sie künftig zur Verfügung stehen werden.
Eine externe Vorrichtung kann eine weitere Verkehrstelematikanwendung, eine andere Input-/Output-Vorrichtung, eine Fax-Endgerät, ein PC oder ein adaptierbares Auto-Bus-System sein, z. B. der CAN-Bus.
Einige PC-basierende Anwendungen können den direkten Kommunikationsweg verwenden, der vom GSM-Modul bereitgestellt wird. Andere PC-basierende Anwendungen können verbunden werden, um den Zugang zu internen Geräten der Basisvorrichtung zu ermöglichen: zum Beispiel, um diagnostische Funktionen zu starten und zu überwachen oder um das Fehlerprotokoll zu lesen (nur durch das Service-Personal).
Es ist das Ziel, einen herstellerunabhängigen Zugang zur Basisvorrichtung anzubieten. Aus diesem Grund ist die Standard-Kommunikations-Schnittstelle ein Serial-Bus, der die Verbindung von mehreren externen Vorrichtungen ermöglicht. Es wird vorgeschlagen, einen RS485-Bus zu diesem Zweck zu verwenden.
Die Basisvorrichtung beinhaltet die Standard-Kommunikations-Schnittstelle (SCI). Diese wird verwendet, den externen Bus mit dem API zu verbinden.
4.1 Das SCI-Modul und die Kommunikationswege
Alle externen Vorrichtungen haben einen einzigen gemeinsamen Zugang über das SCI-Modul zur API, das alle externen Vorrichtungen bei der API vertritt. Aus diesem Grund verwaltet das SCI-Modul die Verbindungen zwischen den externen Vorrichtungen und den integrierten Anwendungen oder Grundfunktionen.
Grundsätzlich gibt es zwei verschiedene Arten des Zugangs von einer externen Vorrichtung: Zugang über die API und direkter Zugang.
Der Zugang über die API wird für die normalen Kommunikationen zwischen den externen Vorrichtungen und den Anwendungen oder Grundfunktionen innerhalb der Basisvorrichtung verwendet.
Der direkte Zugang wird für die transparente GSM-Datenverbindung zwischen einer externen Vorrichtung und einem externen Nutzer verwendet, z. B. für PC- oder Fax-Anwendungen. Der direkte Zugang wird lediglich über die SCI bereitgestellt.
4.2 Aufgaben des SCI-Moduls
Es ist die Aufgabe des SCI-Moduls, entweder das reine API-Verbindungsprofil oder das direkte Zugangsprofil bereitzustellen, wobei dies von den Anforderungen der Anwendungen (siehe Bild 4.2-1) abhängt. Zu diesem Zweck gibt es einen Schalter, um den Verbindungsweg zu steuern. Die in dem Bild gezeigte Schalterposition gilt für die normale Verbindung zur API. Eine andere Schalterposition wird verwendet, um es einem Protokoll zu ermöglichen, die Datenintegrität sicherzustellen, indem ein Schutz gegen die Übertragungsstörung auf dem externen Bus bereitgestellt wird. Das Schalten zur dritten Position resultiert in einem „direkten Zugang" über das Kommunikationsmodul und die API zum GSP-Funkweg.
4.2-1: Standard-Kommunikations-Schnittstelle (SCI)
Das SCI-Modul hat die Aufgabe, die Schalter, so wie von den Anwendungen angefragt, zu verwalten.
Eine andere Aufgabe des SCI-Moduls ist, am Prioritätsmanagement teilzunehmen. Wenn von einer externen Vorrichtung ein Befehl an die Basisfunktion gesendet und von dem entsprechenden Prioritätsmanagement zurückgewiesen wird, ist es die Aufgabe des SCI-Moduls, die Zurückweisungsnachricht anzunehmen und entsprechend zu reagieren. Wenn andersherum mehr als eine Anwendung oder Basisfunktion gleichzeitig versucht, Zugang zu bekommen, z. B. zu einer externen Input-/Output-Vorrichtung, ist es die Aufgabe des SCI-Moduls, den Konflikt beizulegen.
5 Anhang
5.1 Anhang 1: Auszug aus der GSM TS 02.07:

Anhang A (als Richtschnur dienend): Rufwiederhol-, Rufversuchseinschränkungen

Es wird angenommen, dass Rufaufbauversuche, auf die in diesem Anhang Bezug genommen wird, von peripherischen Ausrüstungen oder automatisch vom MT selbst initiiert wurden.
Ein Rufwiederholversuch kann gemacht werden, wenn ein Rufversuch aus den Gründen nicht erfolgreich ist, die unten aufgeführt sind (so wie in der GSM 04.08 definiert).
Diese Gründe werden in drei Hauptkategorien klassifiziert:

1. „Destination besetzt" Grund Nr. 17, Nutzer ist besetzt
2. „Nicht erreichbare Destination-vorübergehend" Grund-Nr. 1 nicht zugeordnete (nicht zugewiesene) Nummer 3 keine Route zur Destination 22 Nummer hat sich geändert 28 ungültiges Nummernformat (unvollständige Nummer) 38 Netzwerk ist außer Betrieb 18 kein Nutzer antwortet 19 Nutzer alarmiert, keine Antwort 27 Destination ist außer Betrieb 34 kein Schaltung/kein Kanal verfügbar 41 vorübergehender Ausfall 42 Anhäufung von Schaltausrüstungen 44 angefragte/r Schaltung/Kanal nicht verfügbar 47 Quellen nicht verfügbar, nicht spezifiziert
3. „Nicht erreichbare Destination-ständig/langfristig" Grund-Nr.

ANMERKUNG: Optional ist es gestattet, den Grund Nr. 27 in die Kategorie 3 anstelle von Kategorie 2 zu implementieren, da dies bereits in Phase 1 wünschenswert ist.
Das untere Verzeichnis beschreibt ein Rufwiederholeinschränkungsmuster zu irgendeiner B-Nummer. Dieses Muster definiert eine Maximalzahl (n) von Rufwiederholversuchen; wenn diese Zahl n erreicht ist, soll die assoziierte B-Nummer von der MT schwarz aufgelistet werden, bis eine manuelle Rücksetzung des MT in Bezug auf jene B-Nummer durchgeführt wurde. Wenn ein Wiederholversuch zu irgendeiner B-Nummer fehlschlägt oder schwarz aufgelistet wird, verhindert dies nicht, dass Anrufe zu anderen B-Nummern getätigt werden.
Für die Kategorien 1 und 2 oben soll n gleich 10 sein; für die Kategorie 3 soll n gleich 1 sein. Rufversuch fordert Initialrufversuch heraus Mindestdauer zw. Rufvers.

1. Wiederholversuch 5 Sek.

2. Wiederholversuch 1 Min.

3. Wiederholversuch 1 Min.

4. Wiederholversuch 1 Min.

5. Wiederholversuch 3 Min.

6. Wiederholversuch 3 Min.
Die Anzahl von B-Nummern, die in der schwarzen Liste beibehalten werden können, obliegt der Wahl der Hersteller, doch es sollen mindestens 8 sein. Wenn die schwarze Liste jedoch voll ist, soll die MT weitere automatische Rufversuche an irgendeine Nummer verbieten, bis die schwarze Liste beim MT hinsichtlich einer oder mehrerer B-Nummern manuell gelöscht ist.
Wenn ein automatischer Rufapparat mit einer MT1 oder MT2 verbunden ist oder wenn ein MTO selbst wählen kann, dann soll die MT die Rufanfragen in Übereinstimmung mit der Folge der oben genannten Wiederholversuchen bearbeiten, d. h. Anfragen nach Wiederholversuchen mit weniger als der minimal zugestandenen Dauer zwischen ihnen sollen von der MT zurückgewiesen werden.
Ein erfolgreicher Rufversuch zu einer Nummer, die Gegenstand der oben ausgewiesenen Rufeinschränkungen gewesen ist (d. h. ein nicht erfolgreicher Rufaufbauversuch hat kürzlich stattgefunden), soll den „Zähler" für die Nummer zurückstellen.
Der „Zähler" für einen fehlgeschlagenen Versuch, eine B-Nummer zu erreichen, soll 24 Stunden oder bis die MT abgeschaltet wird beibehalten werden. Die Einschränkungen für eine/n automatische/n Rufwiederholung oder Rufversuch gelten für Sprach- und Daten-Services.
ANMERKUNG: Die Einschränkungen gelten nur für eine fehlgeschlagene Rufkontrollaktivität und nicht für Funk-Resource-Management oder Mobilitäts-Management; somit werden Mehrfachversuche hinsichtlich des Zugangs zum Funkkanal durch diesen Mechanismus nicht eingeschränkt.
Freigabegründe, die in der GSM TS 04.08 definiert sind; siehe Tabelle 5.1-1

Alle anderen Werte im Bereich von 0 bis 31 sollen als Grund 31 behandelt werden.
Alle anderen Werte im Bereich von 32 bis 47 sollen als Grund 47 behandelt werden.
Alle anderen Werte im Bereich von 48 bis 63 sollen als Grund 63 behandelt werden.
Alle anderen Werte im Bereich von 64 bis 79 sollen als Grund 79 behandelt werden.
Alle anderen Werte im Bereich von 80 bis 95 sollen als Grund 95 behandelt werden.
Alle anderen Werfe im Bereich von 96 bis 111 sollen als Grund 111 behandelt werden.
Alle anderen Werte im Bereich von 112 bis 127 sollen als Grund 127 behandelt werden.

Freigabegründe, die in der GSM TS 07.07 definiert sind; siehe Tabelle 5.1-2

Andere Werte zwischen 128 und 255 sind reserviert.

Zusätzlich empfohlene Gründe – siehe Tabelle 5.1.3
5.2 Anlage 2: Indirekter/direkter Zugang zum AT-Befehlssatz
Die AT-Befehle, die in der Tabelle 5.2-1 aufgelistet sind, sind ein Auszug aus der GSM 07.07, „AT-Befehlessatz für GSM-mobile Ausrüstungen (ME)" (2). Sie werden im Zwischensystem Kommunikation verwendet.
5.3 Anlage 3: Nachrichtenfolge und Service-Grundoperationen des TASP4-Protokolls
Die Nachrichtenfolge und die Service-Grundoperationen des TASP4-Protokolls, die in Kapitel 2.2.1-5 dargestellt wurden, sind unten beschrieben.
Nachrichtenfolge – siehe 2.2.1-5

2.2.1-5: Gitterwerk des TASP4-Levels
Start-Flag

Die Start-Flag markiert den Beginn eines Gitters. Es besteht aus der Bit-Folge 01111110. Es gibt keine Ende-Flag. Das Ende der Nachricht wird mittels eines Längenindikators angezeigt.
Die Start-Flag ist normalerweise nicht Teile des Levels 4; sie macht jedoch den leitungsorientierten Transfer auf Routen ohne ein Protokoll des Levels 2 (transparenter Datenkanal) möglich.
LAPB-Adressenfeld nicht notwendig
Da nur ein Nutzer Zugang zum Transportprotokoll haben muss, ist kein Adressenfeld erforderlich. Die Aufgabe des Adressenfeldes im LAPB-Protokoll, zwischen Befehl und Antwort zu unterscheiden, wird durch den C/R-Bit im Längen-Indikator-Feld erfüllt Der Mehrfachbetrieb von mehreren Verbindungen kann von der Anwendung übernommen werden, die innerhalb des Datenfeldes (vom Standpunkt des TASP4-Levels aus) ein Adressenfeld verwaltet.
Steuerungsfeld
Das Steuerungsfeld besteht aus einem Oktett. Es gibt drei verschiedene Formate (I-, S- und U-Format) (siehe 2.2.1-6).
2.2.1-6: Steuerungsfeld

N(S): Sender sendet Folgenummer
N(R): Sender empfängt Folgenummer
I: Informationsrahmen
S: Überwachungsrahmen
U: nicht nummerierte Rahmen
P/F: Abfrage-Bit, wenn als ein Befehl ausgegeben. Final-Bit, wenn als eine Antwort ausgegeben.

Die genaue Bit-Codierung ist in der 2.2.1-7 gezeigt; sie entspricht dem LAPB-Format.
2.2.1-7: Kodierung in Übereinstimmung mit dem LAPB-Format

I: Information/en
RR: empfangsbereit
RNR: nicht empfangsbereit
REJ: Rückweisung
SABM: asynchronischen, abgeglichenen Modus einstellen
DM: Modus trennen
UI: nicht nummerierte Information/en
DISC: trennen
UA: nicht nummerierte Bestätigung
N(S): Sender sendet Folgenummer
N(R: Sender empfängt Folgenummer
P/F: Abfrage-Bit, wenn als ein Befehl, wenn als eine Antwort ausgegeben
P: Abfrage-Bit
F: Final-Bit

Das Protokoll für den Nutzer des Steuerungsfeldparameters ist in der CCITT-Empfehlung X.25 (7) oder in Q.921 beschrieben.
Definition der Parameter:

Fenstergröße = 3
Anzahl der Wiederholungen, bevor eine Fehlermeldung an einen höheren Level gesendet wird = 6 Wiederholungen
Zeitgeber = ist zu definieren, hängt vom Bearer Service ab

Längen-Indikator-Feld
Das Längen-Indikator-Feld besteht aus dem Längenindikator, dem C/R-Bit, dem M-Bit und dem EL-Bit (siehe 2.2.1-6).
2.2.1-6: Längenindikatorfeld

L Längenindikator
C/R Befehls-/Antwort-Bit
M Mehrdaten-Bit
EL Längenindikatorfelderweiterungsbit

L Längenindikator
In UI- und I-Rahmen definiert der Längenindikator die Länge des Datenfelds in Oktett. Wenn der Längenindikator 5 Bit beträgt (siehe 2.2.1-8), ist die Länge des Datenfeldes zwischen 0 und 31 Oktett. Wenn das Datenfeld größer als 31 Oktett ist, wird das Längenindikatorfeld vergrößert (siehe EL-Bit).
Bei Nachrichten, die kein Informationsfeld beinhalten, ist der Längenindikator 0.
C/R-Befehls-/Antwort-Bit
Der C/R-Bit wird auf 0 eingestellt, wenn ein Befehl gesendet wird; er wird auf 1 eingestellt, wenn eine Antwort gesendet wird.
M Mehrdaten-Bit
Die Funktion des Mehrdaten-Bits ist die Segmentierung von Nachrichten.
Der M-Bit-Satz bei 1 zeigt an, dass dies Teil (ein Segment) einer langen zusammenhängenden Nachricht ist.
Wenn der M-Bit andererseits auf 0 eingestellt wird und der M-Bit der vorhergehenden Nachricht war ebenfalls 0, enthält das Informationsfeld die ganze Nachricht.
Wenn der M-Bit auf 0 eingestellt wird und der M-Bit der vorhergehenden Nachricht 1 ist, enthält das Informationsfeld den letzten Teil (Segment) einer längeren Nachricht.
Der M-Bit ist nur so lange relevant wie 1-Rahmen betroffen sind. Im Falle aller anderen Rahmen wird der M-Bit auf 0 eingestellt.
EL Längenindikatorfelderweiterungsbit
Die Funktion des EL-Bits ist, den Längenindikator zu verlängern. Wenn er auf 0 eingestellt wird, zeigt er das letzte Oktett des Längenindikators an. Wenn er auf 1 eingestellt wird, folgt ein weiteres Oktett, das zum Längenindikatorfeld gehört.
Wenn sich ein Datenfeld in der Länge zwischen 0 und 31 Oktett befindet, ist die nachfolgende Kodierung des Längenfelds (2.2.1-9) ausreichend. Der EL-Bit wird hier auf 0 eingestellt.
2.2.1-9: Längenindikatorfeld für ein Datenfeld zwischen 0 und 31 Oktett in der Länge
Wenn das Datenfeld größer als 31 Oktett ist, kann das Längenindikatorfeld mit Hilfe des EL-Bits (siehe 2.2.1-10) vergrößert werden. Die Länge des Datenfelds kann dann zwischen 16 und 3.095 Oktett liegen Informationsfeld
Das Informationsfeld enthält Daten der Anwendungsebene (level). Es kann so lang wie 4.095 Oktett sein.
Rahmenprüffolgefeld
Das Rahmenprüffolgefeld beträgt zwei Oktett in der Länge.
Der Polynomerzeugende beträgt x¹⁶ + x¹² + x⁵ + 1.
Service-Grundoperationen (primitives)
Die Service-Grundoperationen zwischen dem überlagerten (superior) Level und dem Transportlevel sind:
T-Connect-Request (T-Verbindung-Anfrage)
T-Connect-Indication (T-Verbindung-Anzeige)
T-Connect-Response (T-Verbindung-Antwort)
T-Connect-Confirm (T-Verbindung-Bestätigung)
T-Data-Request (T-Daten-Anfrage)
T-Data-Indication (T-Daten-Anzeige)
T-Unitdata-Request (T-Gerätedaten-Anfrage)
T-Unitdata-Indication (T-Gerätedaten-Anzeige)
T-Disconnet-Request (T-Trennung-Anfrage)
T-Disconnect-Indication (T-Trennung-Anzeige)
T-Disconnect-Confirm (T-Trennung-Bestätigung)
T-Error-Indication (T-Fehler-Anzeige)
Die Service-Grundoperationen zwischen dem Transport- und dem überlagerten Level (Netzwerkschicht) sind:
N-Data-Request (N-Daten-Anfrage)
N-Data-Indication (N-Daten-Anzeige)
5.4 Anlage 4: Definierte Werte für Superrahmenstruktur
Die folgenden Werte sind für die Superrahmenstruktur definiert. Eine detaillierte Spezifikation über diese Werte ist für weitere Studienzwecke.
<TIME>: mm_dd_hh_mm_ss:

mm: Monat: 0...12
dd: Tag: 0...31
hh: Stunden: 0...23
mm: Minuten: 0...59
ss: Sekunden: 0...59

Der Wertbereich für die Anwendungen könnte ebenfalls als Werte das asi verwendet werden.
6 Referenzdokumente

(Anm. d. Übs.: (1) bis (9) ohne Übersetzung – siehe Original)

Abkürzungen

API

Anwendungs-Programmierungs-Schnittstelle

ASI

Anwendungs-Service-Identifizierer

BS

Bearer Service

CIM

Chipkarten-Schnittstellen-Modul

CLI

Chipkarten-Leitungs-Identität

CLIP

Rufleitungs-Identitäts-Präsentation

CLIR

Rufleitungs-Identitäts-Einschränkung

CPU

Zentralverarbeitungseinheit

CRC

zyklische Redundanzprüfung

CST

Kommunikations-Service-Verzeichnis

DGPS

differentiales globales Positionierungssystem

DISC

Trennungsnachricht

EPE

geschätzter Positionsfehler

ETSI

europäisches Telekommunikationsnormeninstitut

GPS

globales Positionierungssystem

GNSS

globales Navigationssatellitensystem

GPRS

General Packet Radio Service

GSM

globales System für mobile Kommunikationen

HDLC

Daten-Link-Steuerung auf hoher Ebene

IntraGSM

internationales globales Verkehrssystem für mobile Kommunikationen

I/O

Input/Output

LAPB

Leitungszugangsverfahren auf dem B-Kanal

MCC

mobiler Landes-Code

MNC

mobiler Netzwerk-Code

MO

mobil-erzeugt

MOC

mobil-erzeugter Anruf

MT

mobil-beendet

MTC

mobil-beendeter Anruf

OSI

offene Systemzusammenschaltung

PDS

Packet Data on Signalling Channels Service

PLMN

öffentliches, auf Land befindliches Mobilnetzwerk

RNR

nicht empfangsbereit

RTCM

Funktechnische Kommission für Seedienste

SABM

asynchronischen, abgeglichenen Modus einstellen

SCI

Standard-Kommunikations-Schnittstelle

SMS

SMS-Service

SMS-MO

SMS-Service-mobil erzeugt

SMS-MT

SMS-Service-mobil beendet

SS

zusätzlicher Service

TASP4

telematisches Anwendungs-Sicherheitsprotokoll

TCP

Transport-Kommunikationsprotokoll

TOP

Positionsart

TS

Tele-Service

VT

Verkehrstelematik

Tabelle 5.1-1: Fortsetzung auf der nächsten Seite
Tabelle 5.1-1
Tabelle 5.1-2
Tabelle 5.1-3

Claims

Ein Verkehrstelematikendgerät, bestehend aus einem Basissystem mit verschiedenen auswechselbaren und/oder gegenseitig austauschbaren Zwischensystemen, die mindestens – ein Zwischensystem für die Kommunikation, – ein Zwischensystem für die Ortsbestimmung – ein Zwischensystem für die Zugangssteuerung und – ein Zwischensystem für die Eingabe/Ausgabe aufweisen, wobei jedes Zwischensystem mehrere Basisfunktionen aufweist, gekennzeichnet durch eine Anwendungsprogrammierschnittstelle, API, die zur Implementierung spezifischer Anwendungen und darüber hinaus zur Unterstützung von Kommunikationsinteraktionen von den Zwischensystemen des Basissystems zu den Anwendungsmodulen, von den Anwendungsmodulen zu den Zwischensystemen des Basissystems, von den Service-Centern zu den Anwendungsmodulen und von den Anwendungsmodulen zu den Service-Centern über das Zwischensystem zur Kommunikation, als auch zwischen den Anwendungsmodulen sowohl desselben Herstellers als auch zwischen Anwendungsmodulen verschiedener Hersteller geeignet ist, und eine Routing- und Systemsteuereinheit mit einem Routing-Steuerteil zur Verknüpfung der Anwendungsprogrammierschnittstelle, API, mit den Zwischensystemen und den Basisfunktionen, die durch das Zwischensystem zur Kommunikation zwischen den implementierten Anwendungen und den Basisfunktionen zur Verfügung gestellt werden, und ein Systemsteuerteil zum Betrieb der Basisfunktionen.
Ein Verkehrstelematikendgerät nach Anspruch 1, dadurch gekennzeichnet, dass das Zwischensystem zur Kommunikation über ein GSM-Modul mit einem GSM-Netzwerk verbunden ist.
Ein Verkehrstelematikendgerät nach Anspruch 1, dadurch gekennzeichnet, dass das Zwischensystem zur Ortsbestimmung eine Schnittstelle zu einem GPS-Modul aufweist.
Ein Verkehrstelematikendgerät nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass das Zwischensystem zur Zugangssteuerung eine Schnittstelle zu einem Chipkartenleser hat.
Ein Verkehrstelematikendgerät nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das Zwischensystem zur Ein-/Ausgabe eine Eingabe-/Ausgabevorrichtung aufweist.
Ein Verkehrstelematikendgerät nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass jedes Zwischensystem mit einer Standard- Kommunikations-Schnittstelle, SCI, zum direkten oder indirekten Zugang von/zu externen Anwendungen oder Vorrichtungen ausgestattet ist.
Ein Verfahren zum Betrieb eines Verkehrtelematikendgerätes, so wie es in den Ansprüchen 1 bis 6 definiert ist, worin die Basisfunktionen, die durch die Zwischensysteme zur Kommunikation, zur Ortsbestimmung, zur Zugangssteuerung, zur Eingabe/Ausgabe und durch eine Standard-Kommunikations-Schnittstelle, SCI, bereit gestellt werden, dem Basissystem zugewiesen sind, dadurch gekennzeichnet, dass jene Basisfunktionen für den Betrieb und/oder zur Betriebssteuerung eines oder mehrerer Zwischensysteme in Übereinstimmung mit spezifischen Anwendungen verwendet wird/werden, das/die durch die Benutzung der Anwendungsprogrammierschnittstelle, API, implementiert ist/sind, wobei eine Routing- und Systemsteuereinheit eine Schnittstelle zwischen den Anwendungen und den Basisfunktionen bildet, während zur gleichen Zeit mehrere Anwendungen unter der gemeinsamen Nutzung desselben Zwischensystems ablaufen können.
Ein Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass die Standard-Kommunikations-Schnittstelle, SCI, zur Verbindung zu und zur Kommunikation mit und zwischen den Zwischensystemen eingesetzt wird.
Ein Verfahren nach einem der Ansprüche 7 oder 8, dadurch gekennzeichnet, dass die Verbindung zwischen den Anwendungen und den Zwischensystemen durch eine Routing- und Systemsteuerfunktion hergestellt wird, während das Routing auf die Adressierung von Aufgaben beschränkt ist, wobei die Systemsteuerung die Überwachgung von Funktionen und die Erfassung von Störungen und Fehlern übernimmt.
Ein Verfahren nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, dass mit dem Zwischensystem zur Kommunikation Verbindungen zu einem GSM-Netzwerk hergestellt werden können.
Ein Verfahren nach einem der Ansprüche 7 bis 10, dadurch gekennzeichnet, dass das Zwischensystem zur Ortsbestimmung seine Lokalisierungsdaten von einem GPS-Empfänger erhält.