DE60036650T2

DE60036650T2 - Fahrzeugverfolgungs-, kommunikations-, und flottenmanagementsystem

Info

Publication number: DE60036650T2
Application number: DE60036650T
Authority: DE
Inventors: John R. Gilbert COFFEE; Richard W. Mesa RUDOW; Robert F. Chandler ALLEN; David A. Phoenix DYE; Kevin M. Gilbert MARVIN; Mark Glendale BILLINGS; Mark L. Phoenix KIRCHNER; Robert W. Phoenix LEWIS; Robert D. Laveen Sleeper; Willialm A. Mesa TEKNIEPE
Original assignee: Trimble Navigation Ltd
Current assignee: Trimble Inc
Priority date: 1999-12-19
Filing date: 2000-12-18
Publication date: 2008-07-03
Anticipated expiration: 2020-12-19
Also published as: DE60036650D1; US20060142913A1; HK1115449A1; EP1843161A3; US6611755B1; WO2001046710A9; EP1410364A2; ATE374987T1; EP1843161A2; WO2001046710A3; WO2001046710A2; US7489993B2; EP1410364B1; EP1410364A4; US6892131B2; ES2322627T3; AU2906501A; DE60041727D1; EP1843161B1; ATE424564T1

Description

Die hier offengelegte Erfindung bezieht sich im Allgemeinen auf Anlagenverwaltungssysteme und im Besonderen auf ein System zum Verfolgen von Echtzeitposition und -status von Fahrzeugen einer Flotte und zum Kommunizieren zwischen den Fahrzeugen und einem Fahrzeugabfertiger oder Disponenten in den Flottenbüros.
Betreiber von Flottenfahrzeugbetrieben müssen wissen, wo sich jedes Fahrzeug der Flotte befindet und was es macht, um die Fahrzeuge so effizient wie möglich einsetzen zu können. In den letzten Jahren sind Fahrzeugortungssysteme entwickelt worden, die Satelliteninformationen eines Globalen Positionsbestimmungssystems (GPS) einsetzen und, um größere Genauigkeit zu erzielen, Differential-GPS-Systeme (DGPS-Systeme). Diese Systeme sind hochgenau, wo Sichtlinienverhältnisse (LOS – line of sight – Sichtlinie) herrschen, das heißt, wo das Fahrzeug (oder genauer gesagt, der GPS-Empfänger des Fahrzeugs) über eine klare LOS zu einer angemessenen Zahl von GPS-Satelliten verfügt. Aber solche Verhältnisse sind üblicherweise für ein Fahrzeug, das auf Stadtstraßen fährt, insbesondere in Gebieten, in denen mehrstöckige Gebäude stehen, aufgrund der Abschirmung, die solche Gebäude bewirken, nicht verfügbar oder zumindest weniger häufig verfügbar. Unter solchen Bedingungen kann ein alternatives Navigationssystem, wie zum Beispiel eine Koppelnavigation (DR – dead reckoning) eingesetzt werden, um die Fahrzeugposition und Geschwindigkeitsdaten in Straßenschluchten bereitzustellen (d. h. in Straßen, die von hohen Gebäuden gesäumt werden), wo GPS-Messungen nur mit Unterbrechungen zur Verfügung stehen. Oder es kann ein Verfahren zur Positionsbestimmung durch Kartenvergleich oder Navigationsgitter als weitere oder zusätzliche Möglichkeit eingesetzt werden.
Gegenwärtig ist die drahtlose Sprachkommunikation zwischen Fahrzeugabfertigern und Fahrern das Hauptmittel, um das Bedürfnis des Flottenbesitzers oder -betreibers zu befriedigen, zu wissen, was jedes Fahrzeug tut, d. h. welche Abläufe zu einem beliebigen Zeitpunkt stattfinden und wo sich das Fahrzeug befindet, wenn ein bestimmter Ablauf stattfindet. In Branchen, in denen Fahrzeuge für jede Ladung eine sich wiederholende Abfolge von Ereignissen ausführen, wie zum Beispiel bei Abläufen mit Transportbeton, werden seit kurzem „Statusboxen" eingesetzt. Die Statusboxen erfordern vom Fahrer in jeder Phase des Ablaufs ein Drücken auf eine Taste, wie zum Beispiel „Laden", „Abfahrt von Fabrik", „Ankunft am Einsatzort", „Beginn des Ausschüttens" und so weiter.
Das Hauptproblem sowohl bei der drahtlosen Sprachkommunikation als auch bei den Statusbox-Systemen ist, dass Daten vom Fahrer des Fahrzeugs für den Fahrzeugabfertiger manuell bereitgestellt werden. Dies führt nach von den Flottenbesitzern/-betreibern durchgeführten Analysen in mehr als neunzig Prozent der Fälle zu nicht zeitgerechten (verspäteten) und, was vielleicht schlimmer ist, ungenauen Daten. Die Verfügbarkeit von zeitgerechten, genauen Daten ist wesentlich, damit der Flottenbetreiber sein Unternehmen effizient und wirtschaftlich führen kann.
Drahtlose Netzwerke nach dem Zeitmultiplexverfahren (TDMA – Time Division Multiple Access), die in zahlreichen Anwendungen einschließlich digitaler Mobiltelefone und drahtloser lokaler Funknetzwerke verwendet werden, können für die Kommunikation zwischen Fahrzeugabfertigern und Fahrern eingesetzt werden. Ein TDMA-Netzwerk ermöglicht die Nutzung eines einzelnen Kanals oder einer einzelnen Frequenz durch mehrere Benutzer durch Zuweisen von bestimmten Zeitschlitzen zu jedem Benutzer ausschließlich für die Übertragung. Um eine optimale Leistung von TDMA-Netzwerken zu erzielen, ist eine exakte Zeitsynchronisation zwischen den Mitgliedern des Netzwerks erforderlich. Ein effizienter Einsatz der Bandbreite des Netzwerks erfordert, dass die Lückenzeiten zwischen den Übertragungen jedes Benutzers, die vergeudete Zeit bedeuten, minimiert werden. Ein wesentlicher Teil der Lückenzeit ist die Zeitunsicherheit bei allen Teilnehmern im Netzwerk. Die Synchronisation von drahtlosen Netzwerken ist häufig sehr grob und erfordert große Lücken zwischen den Übertragungen, wenn keine Spezialhardware eingesetzt wird. Darüber hinaus bringt die Synchronisation von Netzwerkelementen mit einer exakten Referenz, wie GPS-basierten Taktinformationen, das Positionieren eines GPS-Empfängers bei jedem Netzwerkelement, sowohl für Mobilfunk als auch für Festnetz, wodurch die Einrichtungskosten und -komplexität sowohl für Festnetzinfrastruktur als auch für Mobilfunknetz-Vorrichtungen erhöht werden, insbesondere wenn keine durch GPS bereitgestellten Navigationsdaten benötigt werden.
Eine genaue Zeitsynchronisation zwischen allen drahtlosen Vorrichtungen im Netzwerk kann auf verschiedene Weisen ausgeführt werden. Üblicherweise befindet sich eine exakte, stabile Zeitreferenz, wie zum Beispiel eine Zeitreferenz auf Basis des Globalen Positionsbestimmungssystems (GPS) oder anderer Zeitverteilungsdienste, in jeder drahtlosen Vorrichtung oder nur in der festen Infrastruktur des Netzwerks, wobei Synchronisationsinformationen an die mobilen Einheiten gesendet werden. In diesen Fällen werden Geräte- oder Infrastrukturkosten erhöht, da die Takteinrichtungen auf die einzelnen Standorte oder Vorrichtungen verteilt werden müssen und an Stellen montiert werden müssen, an denen der Platz und der Zugang für die Wartung begrenzt sind.
Das Senden von so vielen Informationen wie möglich bei einer vorgegebenen Bandbreite ist ein wesentliches Auslegungsziel bei jedem Kommunikationsnetzwerk. Dies gilt insbesondere für drahtlose Netzwerke, bei denen die verfügbare Bandbreite sehr begrenzt ist und die Kundenanforderungen an den Datendurchsatz erheblich sind. Der Betrieb ist in den meisten Funkbändern Beschränkungen durch die belegte Bandbreite unterworfen und erfordert, dass sich das Datensignal in einem sehr schmalen Bereich des elektromagnetischen Spektrums befindet. Bei TDMA-Netzwerken besteht eine Herausforderung darin, die Lückenzeiten zwischen den Übertragungen und dem Overhead, der mit jedem Datenpaket verknüpft ist, zu minimieren, um so viele informationstragende Daten so stetig wie möglich über das Netzwerk zu senden. Die vorliegende Erfindung begegnet diesen beiden Anforderungen mit digitalem Filtern, um die belegte Bandbreite und die Datenwiederherstellung durch das Empfangssystem zu steuern, das keine Übertragung von Synchronisationsmustern erfordert.
Das US-Patent 5.826.195 bezieht sich auf ein Kommunikationsnetzwerk zum Senden von Fahrzeugstandort-Informationen und Fahrzeugstatus-Informationen, wie zum Beispiel den Zustand eines Kühlraums, von Batteriespannungspegeln oder die Diagnose anderer LKW-Untersysteme. Das Patent legt dar, dass das System außerdem den Status des LKW-Aufliegers und seines Inhalts überwachen kann, wie zum Beispiel, ob der Auflieger mit einem Führerhaus verbunden ist und ob unerlaubte Änderungen am Inhalt vorgenommen worden sind. Diese Bezugnahme legt nicht das Bestimmen des Status von Fahrzeug-„Ereignissen” offen, wie zum Beispiel das Laden und Abladen einer Zuladung, die in einer Folge von Ereignissen während des Ablaufs einer Lieferung stattfinden.
Das US-Patent Nr. 5.983.161 bezieht sich auf ein Fahrzeugortungs- und Kollisionsschutzsystem, das Fahrzeugstandort- und Bewegungsablaufinformationen an eine Leitstelle für Kollisionsschutzmanagement sendet. Diese Bezugnahme legt nicht das Bestimmen des Status von Fahrzeug-„Ereignissen” offen, wie zum Beispiel das Laden und Abladen einer Zuladung, die während des Ablaufs einer Lieferung stattfinden.
Übersicht über die Erfindung
Die Erfindung wird in dem Hauptanspruch 1 definiert.
Das Hauptziel des Flottenverwaltungssystems der vorliegenden Erfindung (im Folgenden mitunter als PROTRAK-System oder als Galileo-System (sowohl PROTRAK als auch Galileo sind, für sich oder mit verschiedenen Zusatzkennzeichen, Marken der Firma Fleet Management Services, Inc. in Chandler, Arizona, der die vorliegende Patentanmeldung zugeordnet ist), als Flottenverwaltungssystem oder einfach als System bezeichnet) ist es, Flottenverwaltungsinformationen für Kunden (d. h. die Besitzer, Betreiber, Teilnehmer oder Benutzer der Flotte, die sich die Vorteile eines Fahrzeugortungs-, Kommunikations- und Flottenverwaltungssystems zu Nutze machen möchten) bereitzustellen, um ihnen zu ermöglichen, ihren Besitz Gewinn bringender zu verwalten. Das System stellt für seine Kunden verschiedene Mittel bereit, um dies zu erreichen. Erstens versetzt das PROTRAK-System den Flottenbetreiber in die Lage, Fahrzeuge der Flotte in Echtzeit zu orten. Zweitens ermöglicht das System dem Betreiber, mit diesen Fahrzeugen über ein sehr effizientes und zuverlässiges drahtloses Netzwerk – ein drahtloses Netzwerk nach dem Zeitmultiplexverfahren (ein TDMA-Netzwerk) – zu kommunizieren. Drittens ermöglicht das System dem Betreiber, zeitgerechte, genaue Daten darüber zu empfangen, was jedes Fahrzeug der Flotte tut, d. h. welche Abläufe es zu einem bestimmten Zeitpunkt ausführt. Viertens versetzt das System den Betreiber in die Lage, die durch das System erzeugten Positions- und Messaging-Informationen mit den übrigen Managementinformationssystemen des Betreibers in Beziehung zu setzen, um eine integrierte Informationsquelle für eine verbesserte Flottenverwaltung bereitzustellen.
Mit Bezug auf Letzteres bestehen die vorhandenen Managementsysteme eines Flottenbetreibers üblicherweise aus Elementen zu Buchhaltung, Personal, Warenbestand und anderen Systemen, die möglicherweise nicht gut integriert sind. Darüber hinaus steht dem Betreiber möglicherweise kein zuverlässiges Verfahren zum Messen der Fahrzeug- und Fahrerleistung zur Verfügung, was entscheidend für die Abläufe des Betreibers ist. Das PROTRAK-System stellt die erforderlichen Fahrzeug- und Fahrerinformationen zusammen mit einem Datenbankverwaltungssystem bereit, das in der Lage ist, solche Informationen zu sammeln und sie mit Daten zu integrieren, die aus anderen Informationssystemen des Betreibers in einer Datenbankverwaltungsanwendung abgefragt wurden. Diese Anwendung kann durch den Betreiber eingesetzt werden, um Berichte zu erzeugen, die auf seinen Betrieb zugeschnitten sind und auf allen verfügbaren Daten basieren.
Das PROTRAK-System ist speziell dafür entwickelt, in einer Marktlücke zwischen Mobiltelefon-, spezialisierten Mobilfunk-(SMR – specialized mobile radio) und Funkrufdiensten zu arbeiten. Das System kann eingesetzt werden, um eine nahezu beliebige Zahl von Fahrzeugen in einer Flotte über sämtliche durch das Netzwerk abgedeckte Stadtgebiete zu verfolgen.
Zeitgerechte, genaue Daten können dem Flottenbetreiber automatisch durch Kombinieren von drahtloser Datennetztechnologie, einem drahtlosen Datenrechner (hier auch als Verfolgungscomputer oder einfach als Verfolger bezeichnet), Sensoren und Fahrzeugabfertigungs- und/oder Datenbankberichtssoftware und Computern in den Einrichtungen des Flottenbetreibers verfügbar gemacht werden, um die durch die Fahrzeuge bereitgestellten Daten zu empfangen, anzuzeigen und zu verarbeiten. Der Bordcomputer verfügt über Schnittstellen zu verschiedenen Sensoren, die Abläufe anzeigen, die durch das Fahrzeug ausgeführt werden. Durch die Sensoren bereitgestellte Daten werden von Software-Algorithmen in dem Rechner verarbeitet, um festzustellen, wann relevante Ereignisse stattfinden. Das Ereignis, maßgebliche Parameter und der Zeitpunkt des Ereignisses werden dann unverzüglich über das drahtlose Netzwerk an den Flottenbetreiber gesendet.
Das Netzwerk, das eingesetzt wird, um ereignisgesteuerte Statusberichterstattung zu ermöglichen, ist so gestaltet, dass es sehr effizient häufig kleine Datenpakete von Fahrzeugen für Flottenbesitzer bereitstellt. Bei der Netzwerkarchitektur handelt es sich um eine einzigartige Vollduplex-Ausführung für den Betrieb in Stadtgebieten. Daten werden über einen Unterträger in einer FM-Funkstation an Fahrzeuge gesendet. Fahrzeuge senden ihre Daten unter Verwendung eines TDMA-Protokolls über einen einzelnen UHF-Kanal. Fahrzeugdaten werden von Netzwerk-Hubs empfangen, bei denen es sich um Empfänger handelt, die auf Geschäftshochhäusern innerhalb des relevanten Stadtgebiets positioniert sind. Die empfangenen Daten werden über Telefonleitungen zurück an ein Netzwerk-Verteilungszentrum (Network Distribution Center – NDC, hier gelegentlich als Netzleitstelle bezeichnet) gesendet und werden über das Internet, eine Telefonverbindung oder andere bevorzugt drahtlose Einrichtungen an die Flottenbesitzer weitergegeben. Daten, die von den Besitzern an die Fahrzeuge gesendet werden, werden zunächst an das NDC gesendet, das sie über Telefonleitungen an eine Übertragungsanlage in der Funkstation sendet.
Das TDMA-Protokoll in dem Netzwerk wird durch Server in dem NDC gesteuert. Die von dem TDMA-Netzwerk für einen effizienten Betrieb benötigte exakte Taktung wird durch ein Synchronisationsmuster gesteuert, das in der Unterträger-Datenübertragung, die von den Fahrzeugen und den Netzwerk-Hubs innerhalb des PROTRAK-Systems empfangen wird, enthalten ist. Dadurch wird es möglich, dass alle Fahrzeuge und Hubs eine gemeinsame Zeitreferenz haben, die bis auf ungefähr drei Mikrosekunden genau ist. Dies ermöglicht wiederum eine Vielzahl von (z. B. 50) Fahrzeugberichten in dem TDMA-Netzwerk pro Sekunde. Die Server weisen Fahrzeugen Berichtsperioden und Zeitschlitze zu, so dass sie Daten und Statusänderungen automatisch senden können. Typische periodische Aktualisierungen von Navigationsdaten oder anderen unkritischen Informationen werden in Intervallen von zwei bis drei Minuten bereitgestellt; es ist nicht möglich, dass der Bordcomputer (Verfolger) auf ein periodisches Intervall dieser Länge wartet, um zeitkritische Ereignisdaten zu senden.
Es stehen insgesamt 50 Zeitschlitze von 20 ms Länge für periodische Übertragungen zur Verfügung. Mehrere Fahrzeuge teilen sich Zeitschlitze, wobei die Zahl von der Aktualisierungsrate des Schlitzes abhängt. Es können zum Beispiel 60 Fahrzeuge einen Aktualisierungsintervallschlitz von einer Minute teilen. Schlitze, die keiner periodischen Aktualisierung zugewiesen sind, können von beliebigen Fahrzeugen genutzt werden, um Zugang zu dem Netzwerk anzufordern. Wenn mehr als ein Fahrzeug versucht, dasselbe Intervall in einem bestimmten Schlitz zu nutzen, können trotzdem beide gehört werden, wenn jedes von einer getrennten Hubempfangsstelle gehört wird. Anderenfalls kommt es zu einer Kollision (Störung) von Daten, und die beteiligten Fahrzeuge müssen ihre Anforderungen wiederholen.
Nach einem Aspekt der Erfindung werden ein Verfahren und eine Vorrichtung zum automatischen Bestimmen und Berichten von Ereignissen von einem Fahrzeug an einen Besitzer oder Abfertiger des Fahrzeugs an einem entfernten Standort offengelegt. Zu berichtende Ereignisse sind Änderungen im Status des Fahrzeugbetriebs, des Standortes oder von Messwerten von Fahrzeugsystemen oder Fracht. Ein Computer (ein Verfolgungscomputer, hier im Allgemeinen als Verfolger bezeichnet), der in dem Fahrzeug eingebaut ist, ist an verschiedene Sensoren angeschlossen, die Parameter messen, die für den Fahrzeugabfertiger oder Besitzer relevant sind, und berichtet kritische Änderungen in den Parametern über das drahtlose TDMA-Netzwerk. Computer an einem festen Standort zeigen diese Statusänderungen an, so dass sie von dem Fahrzeugabfertiger verwendet werden können, oder speichern die Daten für eine spätere Analyse. Software in dem Verfolger in dem Fahrzeug zusammen mit Daten, die durch eine geringe oder große Zahl von Sensoren bereitgestellt werden, ermöglichen das Bestimmen und Berichten von mehreren komplizierten und abstrakten Statusereignissen, die sich auf bestimmte Fahrzeug- oder Branchenanwendungen beziehen, durch den Verfolger. Automatisch erzeugte Berichte von den Verfolgern stellen den Flottenverwaltungsbüros des Kunden genauere und zeitgerechtere Daten zur Verfügung, als sie von den Fahrern der Fahrzeuge erhältlich sind.
Der Verfolgungscomputer verfügt über Navigations-Hardware und -Software zum Bestimmen des Standorts, der Geschwindigkeit und der Fahrtrichtung des Fahrzeugs, in dem er eingebaut ist. Die Anwendungssoftware, die von den Betreibern zum Empfangen von Daten von ihren Fahrzeugen eingesetzt wird, ermöglicht ihnen außerdem, „Einsatzortsabfertigungs"-Befehle an die Verfolger zu senden, die einen rechteckigen Bereich angeben, der verwendet werden soll, um anzuzeigen, wo Ereignisse wie zum Beispiel „Laden" oder „Abladen" stattfinden sollen. Standortinformationen werden dann mit den Sensordaten in den Algorithmen verknüpft, um eine Abfolge von Ereignissen zu bestimmen, das Melden von Fehlern bereitzustellen, um anzuzeigen, dass das Fahrzeug einen bestimmten Vorgang am falschen Ort ausgeführt hat, einen unautorisierten Stopp auf dem Weg von oder zu einem Einsatz ausgeführt hat, oder um andere Ereignisse anzuzeigen, die für einen bestimmten Betrieb oder eine bestimmte Branche spezifisch sind.
In einer beispielhaften Ausführungsform dieses Aspektes oder Merkmals der Erfindung werden drei grundlegende Bestandteile verknüpft, um zu ermöglichen, dass Fahrzeugdaten für den Flottenbetreiber verwendbar sind, und zwar:

(1) Sensoren in dem Fahrzeug, um Parameter zu messen, die in einem Computer verknüpft werden sollen, um automatisch zu bestimmen, wann relevante Ereignisse auftreten,
(2) ein drahtloses Netzwerk, das unverzügliche, wirtschaftliche Übertragung von kleinen Datenpaketen an den Flottenbetreiber ermöglicht, die den Ereignisstatus enthalten, und
(3) Software-Anwendungen zum Speichern und weiteren Verarbeiten von Ereignisinformationen für verbesserte Anlagenverwaltung durch den Flottenbetreiber.

Der Verfolger weist verschiedene Eingänge und Ausgänge auf, um ihm das gleichzeitige Erfassen und Steuern zahlreicher Fahrzeugfunktionen zu ermöglichen, mit konfigurierbaren Schnittstellen, die serielle Schnittstellen, analoge Eingänge, diskrete Eingänge, diskrete Ausgänge und eine Schnittstelle für Impulsmessung oder Taktausgänge umfassen. Der Verfolger verfügt darüber hinaus über dedizierte Schnittstellen zum Messen von Batteriespannung, Zündung, Geschwindigkeit und Rückwärtsgang. Diese ermöglichen die Messung einer großen Vielzahl von Fahrzeugfunktionen, entweder auf direktem Weg oder durch Hilfssensormodule, die Daten für die seriellen Schnittstellen des Computers bereitstellen. Die Ausgänge ermöglichen das Fernsteuern von Fahrzeugfunktionen durch ein drahtloses Netzwerk.
Verfolgersoftware gestattet die Verarbeitung und Integration verschiedener Sensoreingaben, um übergeordnete oder abstrakte Statusereignisse zu bestimmen und zu berichten. Bei einem Status „Laden" für einen Betonmischlastwagen wird zum Beispiel ein Ladevorgang aus einer Reihe von Eingaben durch Verknüpfen von „Lastwagenstandort an der Fabrik", „Lastwagen stehend" und „Lastwagentrommel in Füllrichtung drehend mit höherer Geschwindigkeit als eine vorgegebene Mindestgeschwindigkeit über ein Mindestzeitintervall" festgestellt. Beispiele für andere Statusereignisse umfassen „Krankenwagen-Einsatzbeleuchtung an" oder „Allradantrieb eingeschaltet", die, wie andere einfachere Statusereignisse, einfach erfasst und berichtet werden.
Der Verfolger berichtet Ereignisse über das drahtlose Netzwerk, dessen Architektur und Protokolle auf unverzügliches Berichten von Ereignissen zugeschnitten sind, während gleichzeitig langsamere, periodische Aktualisierungsintervalle für weniger kritische Daten unterstützt werden. Wie oben festgestellt wurde, setzt das Netzwerk ein TDMA-Protokoll ein, um einer großen Zahl von Fahrzeugen zu ermöglichen, häufig kurze Datenpakete über einen einzelnen Funkkanal zu senden. Daten werden über einen Unterträger über einen FM-Rundfunkkanal an die Fahrzeuge gesendet. Ein wesentlicher Aspekt der Erfindung ist die Bereitstellung einer exakten, für das TDMA-Protokoll benötigten Zeitsynchronisation für die Fahrzeuge und die Empfangsstellen über die FM-Verbindung. In der beispielhaften Ausführungsform können bis zu fünfzig Fahrzeuge pro Sekunde Daten mit einer Vielzahl von Aktualisierungsintervallen, die zwischen fünf Sekunden und einer Stunde liegen, berichten.
Typische periodische Aktualisierungen von Navigationsdaten und anderen unkritischen Informationen werden in Intervallen von zwei bis drei Minuten bereitgestellt. Es ist jedoch für den Verfolger nicht durchführbar, auf periodische Intervalle dieser Länge zu warten, um zeitkritische Ereignisdaten zu senden. Dementsprechend erhält das Netzwerk für solche Ereignisse eine Anzahl von Zeitschlitzen für zusätzlichen Zugriff auf das Netzwerk auf Anforderung durch jedes Fahrzeug, das Ereignisdaten senden muss, aufrecht. Dem anfordernden Fahrzeug werden dann ausreichend Hilfsberichtszeiten in Intervallen von zwölf Sekunden zum Senden seiner Daten gewährt. Die gesamte Wartezeit zwischen dem Erfassen eines Ereignisses und der Übertragung von Daten bleibt unter dreißig Sekunden.
Besitzer und Abfertiger von Flottenfahrzeugen werden Computersoftware-Anwendungen zur Verfügung gestellt, die eine Verbindung ihres Bürocomputers mit dem TDMA-Netzwerk unter Verwendung des Internets oder anderer Einrichtungen ermöglichen. Von den Fahrzeugen gelieferte Daten werden an diese Anwendungen durch die Netzwerkserver weitergeleitet und werden darüber hinaus in einer lokalen Datenbank gespeichert. Eine dieser Software-Anwendungen gestattet das Anzeigen der Fahrzeugstandorte als Symbole auf einer Karte, die auf einem Bildschirm angezeigt wird, wobei sie Ereignisänderungen für jedes Fahrzeug auf der Karte in Echtzeit in dem Moment, in dem sie stattfinden, anzeigt, und ermöglicht darüber hinaus dem Fahrzeugabfertiger, Nachrichten oder Abfertigungsstandorte an die Fahrzeuge zu senden. Automatisierte Ereignisse können nach Bedarf auch für andere Abfertigungs- oder Fahrzeugverwaltungs-Anwendungen bereitgestellt werden. Zweckmäßigerweise integrieren diese Anwendungen Fahrzeugereignisdaten mit anderen Systemen, die im Betrieb des Flottenbetreibers eingesetzt werden, wie zum Beispiel Auftragseingangs- und Kommunikationsverwaltung. Berichte über Fahrzeugereignisse können aus diesen Anwendungen über das Internet aus in der Netzwerkdatenbank gespeicherten Daten erzeugt werden.
Nach einem weiteren ihrer Aspekte minimiert die vorliegende Erfindung Infrastrukturkosten für Zeitreferenzen in dem drahtlosen TDMA-Netzwerk und ortet die Zeitreferenz in einer zentralen Netzwerksteuerungs-Einrichtung, die leicht gewartet und überwacht werden kann. Die Zeitreferenz setzt GPS-referenzierte Zeit ein, und die TDMA-Netzwerkzeit wird durch einen drahtlosen Phasenregelkreis (phase lock loop – PLL) synchron zu der GPS-Referenz gehalten, so dass die Notwendigkeit beseitigt wird, die Zeitreferenz innerhalb der drahtlosen Sende-/Empfangseinrichtungen oder der Infrastrukturelemente zu orten. Dieser Aspekt der Erfindung ermöglicht eine exakte Zeitsynchronisation aller drahtloser Netzwerkelemente unter Verwendung einer besonderen Takthardware und durch Verteilen einer einzelnen, entfernten GPS-basierten Zeitreferenz überall in dem Netzwerk unter Verwendung eines drahtlosen PLL. Digitale Daten werden in dem TDMA-Netzwerk entfernt synchronisiert, einem Vollduplex-System, das für das häufige, effiziente Senden von kurzen Datenschüben von mobilen Fahrzeugen an ihre Besitzer konstruiert ist. Fahrzeuge senden Daten unter Verwendung eines TDMA-Protokolls in dem UHF-Frequenzband in exakt gesteuerten Zeitschlitzen mit einer Geschwindigkeit von 50 Fahrzeugen pro Sekunde. Fahrzeuge senden Standort-, Status- und Nachrichtendaten an die Flottenbesitzer oder Fahrzeugabfertiger, die über das Internet oder andere Einrichtungen mit dem drahtlosen Netzwerk verbunden sind. An die Fahrzeuge gesendete Daten werden über einen Unterträger einer FM-Funkstation übertragen und umfassen Netztakt- und Steuerinformationen wie auch Nachrichten und Informationen von den Flottenbetreibern.
Die Taktung des TDMA-Teils des Netzwerks wird von einer zentralen Netzwerksteuerungs-Einrichtung gesteuert, in der die Server untergebracht sind, die den Zugriff der Fahrzeuge auf das Netzwerk steuern und die Verbindungen des Flottenbesitzers mit dem Netzwerk verwalten. Die Synchronisation der Fahrzeugeinrichtungen und der festen Hub-Empfängersysteme, die Fahrzeugdaten empfangen, wird durch Synchronisationsinformationen verwaltet, die in der FM-Unterträger-Übertragung enthalten sind. Die FM-Unterträger-Taktdaten werden wiederum auf eine GPS-basierte Zeitquelle in der Netzleitstelle referenziert.
Ein Unterträger-Steuerungsrechner (Subcarrier Control Computer – SCC), der für das Bereitstellen der Daten für den Unterträger-Modulator zuständig ist, befindet sich in dem FM-Funkstationssender oder der Senderaumanlage. Er taktet die Sendedaten in exakten Intervallen auf Basis von Taktbefehlen von einem Netzwerktakt-Steuerungsrechner (Network Timing Control Computer – NTCC), der sich in der Netzleitstelle befindet. Der NTCC und der SCC sind durch ein Modem für Daten- und Taktsteuerbefehle verbunden, die an den SCC gesendet werden. Der NTCC berechnet Taktbefehle auf Basis der Synchronisationsinformationen von einer GPS-Empfänger-Zeitreferenz und derer von einem FM-Unterträger-Empfänger, der Daten von dem SCC empfängt. Die Zeitdifferenz zwischen der GPS-Zeitreferenz und den über den FM-Unterträger empfangenen Synchronisationsdaten wird durch den NTCC unter Verwendung eines PLL-Algorithmus verarbeitet, um eine Taktkorrektur zu erzeugen, die an den SCC gesendet wird.
Dieser drahtlose PLL-Taktregelkreis ermöglicht einer einzelnen, entfernt positionierten Zeitreferenz, das TDMA-Netzwerk zu synchronisieren. Darüber hinaus ermöglicht die in dem Regelkreis inhärente Rückkopplung dem System, Schwankungen in der FM-Funkstations-Gruppenlaufzeit auszugleichen, so dass die übertragenen Synchronisationsdaten auf die FM-Antenne angewendet werden können. Dies ist wichtig für auf dieser Technologie basierende große Netzwerke, die erfordern, dass mehrere FM-Stationen sich überschneidende geografische Gebiete abdecken, da es das Synchronisieren der FM-Stationen ermöglicht.
Die Erfindung bezieht sich außerdem auf Bandbreitenoptimierungen für die Übertragung von Daten über drahtlose TDMA-Datennetze. Die Erfindung verringert die belegte Bandbreite in einem Funkkanal durch digitales Filtern der Daten, die vor der Modulation gesendet werden sollen. Der Filter ist in einem kostengünstigen Mikrocontroller implementiert, der jede Flanke in einem digitalen Datenstrom eines Rechtecksignals durch Übergänge ersetzt, die die Form steigender oder fallender Sinussignale aufweisen. Dies hat den Vorteil, dass Schwingungen höherer Ordnung in dem Datensignal verringert werden, insbesondere bei der höchsten Datenrate, bei der das Rechtecksignal praktisch durch ein Sinussignal ersetzt wird. Ein weiterer Aspekt der Erfindung maximiert die Effizienz des TDMA-Netzwerks, indem das Senden jeglicher besonderer Bitsynchronisierungs-Informationen zusätzlich zu den Daten unterlassen wird. Bei den meisten Systemen wird eine große Zahl ihrer Bits für Synchronisation, Rahmensynchronisation oder Datentakt-Rückgewinnung verwendet. Nach einem Aspekt der vorliegenden Erfindung werden der Bittakt und die Datensynchronisation durch den Empfänger unter Verwendung von vorwärts gerichteten Fehlerkorrekturalgorithmen, spezieller Bitverschachtelung und Hochleistungs-Digitalsignalverarbeitungs-Hardware und -Software ausgeführt. Ein noch weiterer Aspekt der Erfindung setzt Raum-Diversity-Zusammensetzung zwischen mehreren Empfangsstellen ein, um die Zuverlässigkeit des Datenempfangs zu erhöhen. Ein zuverlässigerer Datenempfang spart durch Verringerung der Zahl der Wiederholungsläufe, die zum Bewegen von Daten durch das Netzwerk erforderlich sind, Bandbreite ein.
Kurze Beschreibung der Zeichnungen
Die obigen und weitere Zwecke, Ziele, Merkmale, Aspekte und dazugehörige Vorteile der Erfindung werden aus der folgenden genauen Beschreibung des Verfahrens ersichtlich, das gegenwärtig als das beste betrachtet wird, um die Erfindung anzuwenden, mit Bezug auf gegenwärtig bevorzugte beispielhafte Ausführungsformen und deren Verfahren zusammen mit den beigefügten Zeichnungen, für die gilt:
1 ist ein vereinfachtes Blockschaltbild des gesamten PROTRAK-Systems der Erfindung einschließlich des TDMA-Netzwerks;
2 stellt ein Blockschaltbild der Systemarchitektur für Kundenanwendungsschnittstellen dar;
3 ist eine ausführliche schematische Darstellung der Bestandteile des drahtlosen Netzwerks und der Kundenschnittstellen;
4 stellt Einzelheiten des NDC in dem Netzwerk von 3 dar;
5 ist eine Zeitleiste des Datenflusses in dem Netzwerk;
6 ist ein Blockschaltbild der Basisnachrichten-Rückkopplungsschleife für den Bit-Sync-Takt;
7 ist ein Schaubild des Basisnachrichten-Rundfunkformates;
8 stellt ein Schaubild eines beispielhaften Verfolgermodul-Nachrichtensenderahmens dar;
9 ist ein Schaubild, das die Beziehung des Wiederholungsintervalls zu Schlitzen, Rahmen und Rahmenzyklen für Verfolgernachrichtenpakete darstellt;
10 erläutert die Beziehung zwischen Verfolgern, Schlitzen und Wiederholungsintervallen;
11 ist ein Schaubild eines in dem System der Erfindung eingesetzten nominalen Navigationsgitters;
12 ist ein Schaubild eines Taktphasenregelkreises (phase locked loop – PLL) nach einem Aspekt der Erfindung für das TDMA-Netzwerk in 1;
13 ist ein Taktdiagramm der Synchronisationsimpulsfolge, die durch den SCC über einen FM-Unterträger zu Beginn der Daten jeder Sekunde gesendet wird, für den Regelkreis in 12;
14A-D stellen Ablaufdiagramme einer Taktregelkreisverarbeitung dar, die in den Betriebsmodi der NTCC-Softwaresynchronisation des TDMA-Netzwerks mit der GPS-Zeit ausgeführt werden;
15 stellt ein (mathematisches) Blockschaltbild des Taktregelkreises dar;
16 ist ein Blockschaltbild der TDMA-Sendedatenverarbeitung, die durch den in einem Flottenfahrzeug eingebauten Verfolgungscomputer (Verfolger) ausgeführt wird;
17 ist eine Tabelle, die das TDMA-Sendedaten-Verschachtelungsmuster erläutert;
18A-C stellen Diagramme dar, die eine ursprüngliche TDMA-Datenfolge mit der verzögerungscodierten Version dieser Folge vergleicht und darüber hinaus das Filtern der verzögerungscodierten Folge vor der Modulation erläutert;
19 ist ein Ablaufdiagramm des Filteralgorithmus, der durch einen speziell ausgewählten Mikrocontroller ausgeführt wird, der das Filtern vor der Modulation für das in 18C dargestellte Ergebnis implementiert;
20 ist ein Schaubild, das einen Vergleich des angenäherten relativen Leistungsspektrums der uncodierten, der verzögerungscodierten und der gefilterten Daten in 18A-C darstellt;
21 stellt ein Blockschaltbild dar, das die TDMA-Empfangsdatenverarbeitung erläutert, die durch den Netzwerk-Hubempfänger ausgeführt wird;
22 ist ein Ablaufdiagramm des Raum-Diversity-Algorithmus, der von dem NDC-Server zum Verknüpfen von durch die Netzwerk-Hubs empfangenen Fahrzeugdaten eingesetzt wird;
23 erläutert eine beispielhafte Platzierung des Verfolgers, eines mobilen Datenendgerätes (MDE) und von Antennen in einem typischen Flottenfahrzeug, wobei das Fahrzeug des Weiteren so ausgerüstet ist, dass es verschiedene Sensoren für die Ereignisberichterstattung aufnimmt;
24 ist ein vereinfachtes Blockschaltbild eines in ein in 23 dargestelltes Fahrzeug eingebauten Verfolgers;
25 ist ein Blockschaltbild der Übersicht über die interne Leistungsverteilung des Verfolgers;
26 stellt ein Blockschaltbild der Übersicht der Leistungsverteilung des Verfolgers dar;
27 ist ein Schaubild der Energiemoduszustands-Übergangslogik des Verfolgers;
28 ist ein Schaubild, das den Synchronisationstakt und die Datentaktung für den Verfolger und die Netzwerk-Hubs darstellt;
29 ist ein Taktdiagramm von Verfolgerdatenübertragungen;
30 stellt ein vereinfachtes Blockschaltbild eines Netzwerk-Hubs dar;
31 ist ein vereinfachtes Schaubild eines Unterträger-Steuerungsrechners (Subcarrier Control Computer – SCC);
32 ist ein Schaubild des NTCC-/SCC-Datenflusses;
33 stellt ein Schaubild dar, das verschiedene Sensoren, Eingänge, Ausgänge und Schnittstellen zu dem Verfolger in 24 erläutert;
34 ist ein beispielhafter rechteckiger Bereich auf einer gespeicherten Karte, um die Position des Verfolgers zu bestimmen und anzuzeigen (insbesondere die des Fahrzeugs, in das der Verfolger eingebaut ist);
35 ist ein vereinfachtes Blockschaltbild eines Trommeldrehungssensors für einen Transportbeton-Lastwagen;
36 ist ein Taktdiagramm der Impulse, die aus der Wechselwirkung des Sensors und der Magneten auf die Trommeldrehung resultieren, für die Ausführungsform des Sensors in 35;
37 ist ein Zustandsübergangsdiagramm, das eine Logik definiert, die von dem Verfolger zum Verknüpfen von Sensor- und Navigationsdaten eingesetzt wird, um den Status eines Transportbeton-Lastwagens automatisch abzuleiten; und
38 stellt ein Ablaufdiagramm eines bevorzugten Diversity-Algorithmus dar, der von dem Verfolger für das Wiederherstellen korrumpierter Daten eingesetzt wird.
Genaue Beschreibung beispielhafter Ausführungsformen und Verfahren
I. Das PROTRAK-Gesamtsystem
Es ist wünschenswert, zunächst einen Überblick über das PROTRAK-Fahrzeugortungs-, Kommunikations- und Flottenverwaltungsgesamtsystem zu geben, wozu ein vereinfachtes Blockschaltbild in 1 dargestellt wird. Über Definitionen von Akronymen und anderen abgekürzten Fachbegriffen, die hier vorgestellt werden, hinaus, wird im Anhang A ein Glossar abgekürzter Fachbegriffe, die in allen Teilen dieser Patentschrift verwendet werden, dargelegt. Das „Gehirn" des Systems ist das Netzwerk-Verteilungszentrum (Network Distribution Center – NDC) 10, das für die Verbindung mit Flotten eines Teilnehmers (der hier auch verschiedentlich als Kunde, Besitzer, Betreiber, Flottenteilnehmer oder Benutzer bezeichnet wird) über ein Modem über eine öffentliche Telefonnetzverbindung (public switched telephone network – PSTN), das Internet oder ein anderes Weitverkehrsnetz zuständig ist und das für die Verbindung mit Flottenfahrzeugen durch ein Vielzahl von Netzwerk-Hubs (hier bisweilen als Netz-Hubs oder einfach als Hubs bezeichnet), wie zum Beispiel 11-1, 11-2, ... 11-i, und einer oder mehrerer FM-Funkstationen, wie zum Beispiel 12, zuständig ist.
An Fahrzeuge in einer oder mehreren relevanten Flotten zu übergebende Informationen werden durch ein Flottenabfertigungs-Büroterminal oder eine Kundenbedienstation (customer command station – CCS), wie zum Beispiel 14 für Kunde A, 15 für Kunde B, ... und 16 für Kunde i, für die Auslieferung an die Fahrzeuge, wie zum Beispiel 17-1, 17-2, ... 17-n für Kunde A (und so weiter für die Kunden B, ... i) erzeugt. Die Informationen werden zunächst von der jeweiligen CCS über ein Modem über das PSTN (z. B. die Leitungen 19, 20, 21) oder über das Internet oder andere Einrichtungen an das NDC 10 gesendet. Das NDC priorisiert die Informationen und sendet sie über ein Modem über das PSTN (z. B. über die Leitung 22) oder über andere Einrichtungen dieser Art an die FM-Funkstation 12, von der die Informationen übertragen werden, z. B. über einen FM-Unterträger von 67 kHz oder 92 kHz. Die Informationen werden mit durch GPS-Satelliten-Navigationsinformationen definiertem, exaktem Takt übertragen.
Alle Fahrzeuge in dem Netzwerk empfangen die FM-Unterträger-Übertragung mit binärer Frequenzumtastung (binary frequency shift keyed – BFSK) von 4.664 Bit pro Sekunde (bps) von der FM-Funkstation (und anderen, falls anwendbar) und decodieren die darin enthaltenen Informationen. Jedem Fahrzeug wird ein Zeitschlitz zum Übertragen seines Standortes und von Antworten auf Anforderungen der CCS zugewiesen. Die zugewiesenen Schlitze sind eindeutig, um gleichzeitiges Übertragen durch zwei oder mehr Fahrzeuge auszuschließen, und der Übertragungstakt wird durch GPS- und FM-Unterträger-Synchronisation exakt gesteuert.
Wenn ein Fahrzeug an der Reihe ist zu übertragen, sendet es eine 144-Bit-Nachricht mit einer Rate von 7.812,5 Bit pro Sekunde. Diese Informationen werden von zumindest einem der Netzwerk-Hubs 11-1, ..., 11-i empfangen, der die Nachricht demoduliert und Daten daraus über ein Modem über das PSTN (z. B. über die Leitungen 24, 25, 26) für das NDC 10 bereitstellt. Das NDC 10 analysiert alle empfangenen Daten und stellt die Fahrzeugstandort- und Statusinformationen für jeden bestimmten Flottenteilnehmer für seine jeweilige CCS über das PSTN bereit.
Die Echtzeitverfolgung von Fahrzeugstandort und -status kann durch das PROTRAK-System zum Beispiel alle fünf Sekunden ausgeführt werden, aber im Allgemeinen wird sie eher einmal alle drei Minuten aktualisiert. Fahrzeugstandorte werden durch den Einsatz von DGPS-Informationen, die durch die FM-Unterträger-Übertragung bereitgestellt werden, mit einer Genauigkeit von ungefähr 5 Metern verfolgt. Wo GPS aufgrund von Signalmaskierung periodisch nicht verfügbar ist, wenn Fahrzeuge sich auf Stadtstraßen befinden, die von hohen Gebäuden gesäumt werden, oder aufgrund anderer Blockierungen, setzt das System Koppelnavigation (dead reckoning – DR), Positionsbestimmung durch Kartenvergleich und/oder andere Navigationsverfahren zum Ermitteln des Fahrzeugstandortes ein.
Das drahtlose System stellt ein vielseitiges Medium zum Senden von kurzen Nachrichten dar, die aus kurzen Paketen von Informationen an ein in einem Fahrzeug eingebautes Gerät bzw. von einem in einem Fahrzeug eingebautem Gerät oder an eine andere drahtlose Kommunikationsvorrichtung bzw. von einer anderen Kommunikationsvorrichtung bestehen. Obwohl das System für die Betriebsanlagenverwaltung bestimmt ist, unterstützt der drahtlose Dienst eine Vielzahl von Paketkommunikations-Anforderungen für feste wie auch für mobile Anlagen. Der Einsatz von GPS in der Empfangsvorrichtung ist aufgrund der GPS-Synchronisation der FM-Unterträger-Übertragungen nicht erforderlich.
Die Systemleistungsfähigkeit reicht aus, um zumindest 5.000 einzelne Fahrzeuge aufzunehmen, die in dem Netzwerk jeweils mit Hilfe der Bandbreite verfolgt werden, die durch einen einzelnen FM-Funkstations-Unterträger bei 67 kHz oder 92 kHz für ausgehende Kommunikation und eine einzelne UHF- oder Schmalbandfrequenz von 12,5 kHz Bandbreite eines persönlichen Kommunikationsdienstes (personal communication services – PCS) für eingehende Fahrzeugnachrichten bereitgestellt wird. Es kann eine Systemerweiterung zum Beispiel in Blöcken von 5.000 Fahrzeugen durch Hinzufügen eines weiteren FM-Funkstations-Unterträgers und einer weiteren UHF- oder Schmalband-PCS-Frequenz bereitgestellt werden. Wo es durchführbar ist, werden die Prinzipien der Mehrfachausnutzung der Frequenzbänder auf die UHF- oder Schmalband-PCS-Frequenzen angewandt, bevor eine weitere eingehende Frequenz hinzugefügt wird, um die Kanalkapazität zu maximieren.
Kommunikationsvorgänge in dem PROTRAK-System bieten eine größere Zuverlässigkeit als zellularer oder spezialisierter Mobilfunk (specialized mobile radio – SMR) und möglicherweise als Funkrufdienste mit einem erwarteten verlässlichen Empfang von Nachrichten durch Fahrzeuge und Fahrzeugabfertiger von 97% beim ersten Mal. Wenn Informationen nicht beim ersten Mal empfangen werden, kann das System dies feststellen und wird erneut versuchen zu senden, bis es erfolgreich ist oder bis es feststellt, dass die Auslieferung nicht erfolgen kann. Zumindest einige Flottenbetreiber (z. B. Ambulanzdienste) benötigen einen zuverlässigen Betrieb trotz ungünstiger Bedingungen, wie zum Beispiel bei Ausfällen der Stromversorgung. Das Gesamtsystem verfügt über interne Sicherungen zum Vermeiden von Einzelfehlern.
Die Fahrzeuge von Flottenteilnehmern dürfen von einem Netzwerk zu einem anderen „wandern" (roaming), wie zum Beispiel dort, wo ein Fahrzeug von einem Stadtgebiet zu einem weiteren unterwegs ist. Das System ermöglicht es dem Fahrzeug, das erste Stadtnetz allmählich zu verlassen und in ähnlicher Weise in das zweite Stadtnetz einzutreten, wenn es sich im Bereich der zweiten Stadt befindet.
Systembestandteile werden so entwickelt, dass sie eine Vielzahl von Flottenteilnehmern unterstützen. Fahrzeugverfolger (d. h. Bord-Verfolgermodule) sind in der Lage, eine Anzahl peripherer Funktionen aufzunehmen, wie zum Beispiel eine analoge, digitale, serielle Schnittstelle und Datenerfassung mit höherer Geschwindigkeit, die von einigen Teilnehmern benötigt wird. Netzwerk-Hubs sind in der Lage, verschiedene Antennen- und Empfängeranordnungen zu unterstützen, um die Abdeckung zu erweitern und verschiedene Leistungskonfigurationen zum Unterstützen des Fernbetriebs zu verbessern. Nichtverfügbarkeit von Telefonleitungen stellt kein Problem dar, da drahtlose Einrichtungen für die indirekte oder direkte Verbindung mit dem NDC eingesetzt werden.
II. Die Flottendaten-Verwaltungsanwendung
Die Systemarchitektur und die Datenbankverwaltungs-Anwendungen des PROTRAK-Systems, die mit den vorhandenen Informationssystemen jedes Teilnehmers (jedes Kunden) in Wechselwirkung stehen, umfassen das NDC und die CCSs, die zum Bereitstellen von Echtzeit-Fahrzeugortungs- und Nachrichtenfähigkeit für Fahrzeugabfertiger eingesetzt werden. Die Kundenseite des PROTRAK-Systems besteht aus drei Anwendungen, einschließlich (1) eines Datenbankverwaltungs- und CCS-Servers (database management and CCS server – DMCS), der die Netzwerk- und Kundeninformationen verbindet, (2) der CCSs mit ihren Echtzeit-Ortungs- und Nachrichtendiensten und (3) einer Berichterstellung, die Kunden ermöglicht, auf durch den DMCS verwaltete Daten zuzugreifen und sie zu verarbeiten.
2 stellt ein Blockschaltbild der Systemarchitektur mit Bezug auf Kundenanwendungsschnittstellen dar. Das NDC 10 führt mit zusätzlicher Kapazität für das Antworten auf Anfragen nach historischen Verfolgungsdaten zwei Serveranwendungen aus, und zwar einen NDC-Server 32, der Echtzeitinformationen für angeschlossene Kunden bereitstellt, und einen Verfolgungsdaten-Protokollserver 33, der Verfolgungsinformationen von dem System in Echtzeit sammelt und sie in einer Datenbank mit großer Kapazität speichert. Der Kunde baut eine einzelne herkömmliche TCP/IP-Verbindung (34, 35) zu jedem dieser Server über eine einzelne Wählverbindung direkt mit dem NDC oder durch das Internet (über einen Internetdienstanbieter oder ISP (Internet Service Provider)) auf.
Die Verbindungen mit dem NDC werden durch den DMCS 27 gesteuert, der sich am Betriebsstandort 28 des Kunden entfernt von dem NDC 10 befinden kann. Alle Echtzeitdaten, die für alle Fahrzeuge des Kunden verfügbar sind, werden für diese DMCS-Anwendung bereitgestellt. Der DMCS 27 speichert diese Daten und gibt sie in einem gefilterten Format an die CCS-Anwendungen 30 weiter, so dass die CCS-Betreiber nur solche Fahrzeuge überwachen (z. B. als Symbole auf einer Bildschirmanzeige oder einem Bildschirm in ihren jeweiligen Stationen) und mit ihnen kommunizieren können, für die sie zuständig sind.
Eine weitere Funktion des DMCS 27 ist das Bereitstellen von Schnittstellen zu anderen Verwaltungsanwendungen eines Kunden, wie zum Beispiel zu Buchhaltungs- 31, Personal- 32, Warenwirtschafts- 33 und rechnergestützten Abfertigungssystemen 34. Eine Datenbankberichtsanwendung 36 greift auf Daten zu und erstellt Berichte. Die Schnittstelle zwischen dem DMCS 27 und dem CCS 30 und Datenbankberichtsanwendungen 36 ist eine herkömmliche TCP/IP-Schnittstelle. Diese Anwendungen können unter Verwendung von zum Beispiel Windows (Marke der Microsoft Coporation) 95, Windows 98 oder Windows NT (oder einer beliebigen Weiterentwicklung einer solchen Software oder einer Software anderer Anbieter, die das Ausführen derselben oder ähnlicher Funktionen ermöglicht) auf demselben oder auf getrennten Computern laufen. Die anderen Anwendungen des Betreibers sind mit dem DMCS 27 über Standard- oder benutzerdefinierte Schnittstellenprotokolle verbunden.
Die DMCS-Anwendung ist für das Verknüpfen der NDC-Serveranwendungen, der CCS- und Datenbankberichtsanwendungen und der vorhandenen Anwendungen des Betreibers (z. B. der Managementinformations- und Back-Office-Systeme des Kunden) zu einem integrierten System zuständig. Der DMCS fungiert als Unternehmensanbindung an das NDC 10. Er baut nach Bedarf TCP/IP-Socketverbindungen zu den Echtzeit- und Datenprotokollservern 32 und 33 des NDC auf und erhält den Zugriff auf Daten aufrecht, so dass alle Fahrzeuge des Flottenbetreibers durch das PROTRAK-System verfolgt werden können. Fahrzeugstandort- und Nachrichtendaten werden durch das NDC 10 bereitgestellt, und der DMCS 27 sendet Echtzeitnachrichten und -befehle an die Fahrzeuge und kann archivierte Verfolgungsinformationen von dem NDC für Zeitspannen anfordern, zu denen der DMCS nicht bei dem NDC angemeldet war.
Die CCS (oder jede von mehreren CCSs) 30 ist in erster Linie ein Echtzeit-Fahrzeugstandortanzeige- und Nachrichteninstrument zum Unterstützen von Abfertigungsfunktionen. Der DMCS 27 leitet Befehle und Nachrichten von der CCS 30 an das NDC 10 weiter und stellt Verfolgungsdaten von dem NDC für die CCS nur für diejenigen Fahrzeuge bereit, die der CCS-Betreiber steuert (d. h. Abfertigung, Überwachung, Disposition etc.). Der DMCS unterstützt mehrere CCS-Anwendungen, die gleichzeitig arbeiten, und steuert und prüft unterschiedliche Fahrzeuggruppen in einer Gesamtflotte.
Der DMCS 27 unterstützt darüber hinaus Datenbankabfragen von mehreren CCS- 30 und Datenbankberichtsanwendungen 36. Jede CCS 30 benötigt Echtzeitinformationen von der Datenbank bezüglich der Fahrzeugfahrer, der Abfertigung, der Disposition und der Fracht. Die Datenbankberichtsanwendung erfordert historische Verfolgungsdaten und Informationen von anderen Systemen, die zum Erstellen von Berichten, die den Betrieb des Kunden betreffen, benötigt werden.
III. Das Netzwerk-Verteilungszentrum
Die Architektur des NDC 10 wird kurz mit Bezug auf das beispielhafte NDC-Software- und Hardwaresystem in dem vereinfachten Blockschaltbild in 3 beschrieben, das die durch die NDC-Software-Anwendungen eingesetzten Übertragungsprotokolle hervorhebt. Wie oben vermerkt, steuert das NDC 10 den Informationsfluss zwischen Fahrzeugen (z. B. 17) und der Bedienstation ihres Flottenbetreibers (z. B. den CCSs 14 und 15 am Kundenstandort 13), die bei dem System angemeldet ist. Das HF-Netzwerk wird durch das NDC durch Steuern des Netztaktes und Feststellen der Art der an die Fahrzeuge gesendeten Daten verwaltet. Alle durch die Netzwerk-Hubs (z. B. 11-1, 11-2) empfangenen Daten werden durch das NDC 10 für die Verarbeitung, die Verteilung an Kunden und die Datenarchivierung gesammelt, und das NDC ermöglicht Kunden, sich über das Internet, ein TCP/IP-Netzwerk oder eine andere geeignete Verbindung 40 anzumelden. Eine Schnittstelle zu einem PROTRAK-Rechenzentrum (PROTRAK Data Center – PDC; ohne Abbildung) unterstützt das Roaming (die Erreichbarkeit) zwischen Städten und die Gesamt-Verfolger-Flottenteilnehmer-Identifizierung.
Ein NDC-Server 42 in dem NDC 10 kommuniziert mit den CCSs 14, 15 etc., wie auch mit den NDC-Bedienstationen (ohne Abbildung) innerhalb des NDC, und den Netzwerk-Hubs 11-1, ..., 11-i durch jeweilige Sockets und damit in Beziehung stehende Netzwerkverbindungen einschließlich eines Routers (eines Vermittlungsknotens) und eines Modems und darüber hinaus mit einem Netzwerktakt-Steuerungsrechner (Network Timing and Control Computer – NTCC) 47 durch eine serielle Schnittstelle 49. Der NDC-Server verfügt nur über eine Schnittstelle – ein Datentransferprotokoll, das in Kürze beschrieben wird. NDC-Administratoren setzen zur Anzeige, Steuerung, Analyse und Wartung des NDC-Servers NDC-Bedienstationen ein (die den CCSs ähneln, aber Teil des NDC sind). Dem NDC-Server 42 wird ein registrierter Domänenname und eine IP-Adresse im Internet zugewiesen, um Flottenteilnehmern und/oder NDC-Bedienstationen zu ermöglichen, sich durch das Internet statt unter Verwendung einer Systemmodembank an den Server anzuschließen. Als erläuterndes Beispiel und nicht zum Zwecke der Beschränkung werden drei verschiedene Verbindungsmöglichkeiten in dem Blockschaltbild der NDC-Hardware in 4 dargestellt.
Wie oben vermerkt, ist das DMCS 27 mit den entscheidenden Unternehmensanwendungen 31 des Kunden etc., einschließlich Buchhaltung, Warenwirtschaft, Personal etc. wie auch mit den CCSs 14, 15 etc. und dem NDC 10 verbunden. Der NDC-Server 42 steuert alle Daten, die an Fahrzeuge und Bedienstationen gesendet werden bzw. die von Fahrzeugen und Bedienstationen gesendet werden, und steuert darüber hinaus die Konfiguration des TDMA-Fahrzeugübertragungs-UHF-Funknetzes durch Zuweisen von Fahrzeugen zu bestimmten Zeitschlitzen für die Übertragung und das Steuern, welche Fahrzeuge arbeiten dürfen. Daten von Fahrzeugen 17, die von den Netzwerk-Hubs 11-1 etc. empfangen werden, werden verknüpft und decodiert und dann für die CCSs von Flottenbetreibern für den Einsatz für das Aufrechterhalten der Steuerung des Funknetzes bereitgestellt. Daten von den CCSs werden nach Bedarf an Fahrzeuge gesendet und außerdem eingesetzt, um eine geeignete Stufe des Aktualisierungsdienstes zu terminieren, wobei die Daten über eine serielle Schnittstelle an jeden NTCC-Rechner in dem NDC gesendet werden.
Die Netzwerksteuerfunktion ist die wichtigste Aufgabe des NCS-Servers 42, die in Echtzeit auf Basis von Aufforderungen von dem NTCC 47 ausgeführt wird. Die Systemanforderungen für wesentliche TCP/IP-Unterstützung, Internet und Wartungs- und Unterstützungs-Workstations erfordern den Einsatz einer Plattform, wie zum Beispiel Windows NT, die es dem System ermöglicht, Hardware und Software eines Dritten einzusetzen. Das periodische Ausführen dieser Aufgabe einmal pro Sekunde wird erstens durch Bereitstellen der Netzwerksteuerfunktion mit ausreichendem Vorrang, um die erforderlichen Aufgaben innerhalb des zugelassenen Zeitraums von einer Sekunde abzuschließen; und zweitens durch einen Sendeaufruf an die serielle NTCC-Schnittstelle mit einer hohen Rate, um den Empfang von Taktdaten zu erfassen, die anzeigen, dass der Server die Netzwerksteueraufgabe starten sollte, erreicht.
Der NTCC 47 steuert den Echtzeitanteil des PROTRAK-Systems einschließlich des Sendetaktes der SCC 48 durch eine Rückkopplungsschleife (die in Kürze in Verbindung mit 6 erörtert wird) unter Verwendung eines FM-Empfängers in einem Dachmodul. Es ist ein NTCC-Dachmodul 55 (4) für jede FM-Funkstation 12 vorhanden, die durch das NDC 10 unterstützt wird. Der NTCC 47 ist darüber hinaus für das Einbringen von Rahmen-ID-Daten und Differentialkorrekturdaten in den gesendeten Datenstrom zuständig. Durch den Server 42 erzeugte Datenpakete werden an den NTCC 47 zur Einbeziehung in den Ausgabedatenstrom gesendet. Dadurch dass der NTCC 47 mit der SCC 48 über ein dediziertes Modem 51 und eine Telefonleitung oder eine andere Leitung kommuniziert, das nicht Teil des für die Netzwerk-Hubs und die CCSs eingesetzten Modemregals ist, wird die zeitkritische Schnittstelle für den Takt und Korrekturen von jeglichen unvorhersehbaren Vorgängen des Modemregals oder der Ethernet-Schnittstelle getrennt.
Der NTCC 47 überwacht die Übertragung der FM-Station 12 auf Takt und Inhalt. Wenn die Übertragung mit Bezug auf die ganzzahlige GPS-Sekunde verzerrt empfangen wurde, werden Taktkorrekturbefehle an die SCC 48 gesendet. Der NTCC vergleicht darüber hinaus die empfangenen Übertragungsdaten mit dem Datenblock, der gesendet wurde, um sicherzustellen, dass die Daten korrekt waren. Die empfangene FM-Signalstärke wird ebenfalls überwacht, um Änderungen in der FM-Übertragungsleistung zu erfassen. Der Übertragungs- und der SCC-Status werden für den Server 42 bereitgestellt, so dass er bestimmen kann, welche Maßnahmen im Falle eines Fehlers ergriffen werden sollen.
Eine Reihe von Windows-NT-Workstations bilden die NDC-Bedienstationen (z. B. 43, 45, 4), die über Ethernet mit 100 Mbps oder einen anderen geeigneten Pfad, wie zum Beispiel einem lokalen Netzwerk (local area network – LAN) an den NDC-Server 42 angeschlossen sind. Diese Stationen stellen die Fähigkeit bereit, verschiedene Funktionen, einschließlich des Anzeigens verschiedener Gebiete des Navigationsgitters, Netzwerk- und Modemüberwachung, Datenprotokollanalyse, Benutzerkontenführung und Softwareentwicklung, auszuführen.
Der NDC-Server 42 kann mit den Netzwerk-Hubs und den CCSs über TCP/IP oder über andere Verbindungsmöglichkeiten, wie zum Beispiel die in 4 dargestellten, kommunizieren. Es kann zum Beispiel ein Total-Control-Modemregal von US Robotics zum Bereitstellen von TCP/IP-Verbindungsfähigkeit verwendet werden. Jedes Regal wird implementiert, um 48 Modems über zwei herkömmliche T1-Leitungen zu unterstützen, und es können mehrere Regale gestapelt werden, um eine größere Zahl von Modems zu unterstützen. Der Server kann zum Beispiel über zwei unabhängige Ethernet-Netzwerke verfügen, und das Modemregal befindet sich in einem Netzwerk, das von den NDC-Bedienstationen getrennt ist, so dass die Netzwerkaktivität der NDC-Bedienstationen nicht zu Wartezeit bei den Modemdaten führt. Benutzerverbindungen stellen keine Echtzeitanforderungen, aber Daten, die zwischen dem Server 42 und den Netzwerk-Hubs (z. B. 41-1, ..., 41-l) übertragen werden, müssen regelmäßig in Intervallen von einer Sekunde auftreten.
In 5 wird eine Zeitleiste des Netzwerk-Datenflusses dargestellt. Daten, die durch die Fahrzeuge in dem Rahmen 1 gesendet werden, sind für den NDC-Server 42 (3) zu Beginn des Rahmens 3 verfügbar. Wenn der Status „Beginn des Rahmens" von dem NTCC 47 erfasst wird, werden diese Daten und über Rahmen 2 empfangene Benutzerdaten verarbeitet. An Fahrzeuge zu sendende Datenpakete werden ebenfalls an den NTCC gesendet. Im letzten Teil von Rahmen 3 stellt der NTCC eine Datenblock zusammen, der während des Rahmens 4 an die SCC 48 gesendet wird. Die SCC schließlich überträgt den Datenblock in Rahmen 5.
Die Netzwerksteuerfunktion umfasst Funknetzverwaltung, Fahrzeug- und Benutzer-Eingabedatenverarbeitung und Basisausgabedaten-Verarbeitung. Auf Basis der in 5 dargestellten Zeitleiste müssen diese verknüpften Aufgaben unmittelbar mit der Erfassung des Beginns eines Rahmens beginnen (auf Basis von von dem NTCC empfangenen seriellen Daten) und ungefähr innerhalb einer halben Sekunde abgeschlossen sein.
Das NDC 10 steuert die Zuweisung von Netzwerksendeschlitzen zu den Fahrzeugen und verwaltet das Austreten und das Eintreten von Fahrzeugen aus dem Netzwerk bzw. in das Netzwerk. Es koordiniert außerdem die Übertragung von Netzwerksteuerungs-, Fahrzeugsteuerungs-, Nachrichten- und Systemidentifikationspaketen an die Fahrzeuge. Die Netzwerkverwaltung muss in dem System in Intervallen von einer Sekunde ablaufen und innerhalb einer halben Sekunde abgeschlossen sein. Das System verwaltet Datenstrukturen für alle aktiven Fahrzeuge und Flottenteilnehmer-Bedienstationen und verfügt über eine Fähigkeit zur Querverweisung von Fahrzeugen an Flotten und an zugewiesene Übertragungsschlitze. Die erforderlichen Daten umfassen:

• die Fahrzeugposition für die Übertragung an Flottenteilnehmer und für die Datenprotokollierung; Positionsdaten können außerdem für die UHF-Frequenz-Wiederverwendung oder FM-Kanalzuweisung verwendet werden;
• den/die durch das Fahrzeug belegte(n) Sendeschlitz(e);
• Die Verfolger-ID des Fahrzeugs, die lokale Steuer-ID, Besitzer und Gruppe;
• Nachrichten- und Steuerungsquittungen, Wiederholungen und Timeouts;
• Roaminginfomationen; und
• den Diensttyp einschließlich der Anforderungen an nominale Aktualisierungsraten, den Echtzeitdienst oder den Verfolgungsverlauf.

Der NDC-Server erfordert effiziente und logische Algorithmen, um Fahrzeuge den Sendeschlitzen zuzuweisen. Es müssen die verschiedenen Fahrzeugaktualisierungsraten ebenso wie das Reservieren von Platz für den Netzwerkeintritt und die Fahrzeugübertragungen als Antwort auf einen Sendeaufruf berücksichtigt werden. Eine regelmäßige Defragmentierung der Sendeschlitze kann ebenfalls erforderlich sein. Während das System läuft, treten in der Praxis fortlaufend Fahrzeuge in das Netzwerk ein und verlassen es, und Schlitze müssen für den Gebrauch durch nachfolgende Fahrzeuge neu zugewiesen werden.
Durch die Fahrzeuge, wie zum Beispiel 17 (3), gesendete Daten werden an dem NDC 10 von den Netzwerk-Hubs (z. B. 11-1, 11-2) über ein Modemregal empfangen, in dem die Modems, die an die Hubs angeschlossen sind, die höchste Priorität mit Bezug auf die Datenübertragung zwischen den Hubs und dem NDC-Server 42 haben. Das NDC 10 verarbeitet die Netzwerkdaten in Intervallen von einer Sekunde, und daher müssen die Fahrzeugdaten von jedem Hub für die Verarbeitung durch den NDC-Server während des Intervalls von einer Sekunde verfügbar sein, nachdem die Daten dieses Rahmens durch die Hubs empfangen worden sind.
Der Server 42 führt Raum-Diversity-Verarbeitung, Fehlerüberwachungs-Decodierung und Fehlerkorrektur sowie Entschlüsselung an den empfangenen Fahrzeugdatenpaketen aus. In den Fahrzeugen zugewiesenen Zeitschlitzen empfangene Daten können von mehreren Hubs verfügbar sein. Da nur ein Fahrzeug 17 gesendet hat, sollten die empfangenen Daten an jedem Hub dieselben sein. Mehrweg-Signalverlust und andere Faktoren können Fehler in den empfangenen Daten verursachen, aber diese Fehler sind wahrscheinlich für jeden Hub andere. Das NDC 10 kann dann die Daten von allen Hubs mischen, um eine wahrscheinlichste Lösung zu erzeugen.
Nachdem die Diversity-Verarbeitung abgeschlossen ist, wird eine Fehlererkennungs-/Korrekturverarbeitung ausgeführt. Die Fahrzeugdatenpakete werden so codiert, dass zahlreiche Bitfehler durch Verschachtelung der Datenbits und Vorwärtsfehlerkorrekturcodierung korrigiert werden können. Die Datenpakete werden dann entschlüsselt.
Die empfangenen Datenpakete werden analysiert, und die Informationen werden zum Aktualisieren der NDC-Netzwerksteuerungs-Datenstrukturen verwendet. Zustands- und Statusdaten werden für eine Offline-Analyse protokolliert. Fahrzeugzustandsdaten und Flottenteilnehmerdaten werden bei ihrem Empfang für die Flottenteilnehmer bereitgestellt. Die protokollierten Zustandsdaten können eingesetzt werden, um den Flottenteilnehmern Fahrzeugverfolgungsverlaufs- statt Echtzeitverfolgungsdaten zur Verfügung zu stellen.
In dem Fall, in dem Daten von Kunden (Flottenteilnehmern, Besitzern oder Mietern zum Beispiel) 13 empfangen werden, werden die Daten wie folgt verarbeitet. Befehle und Datenanforderungen von angemeldeten Flottenteilnehmern werden mit Fahrzeuginformationen verknüpft, um an die jeweiligen Fahrzeuge 17 zu sendende Fahrzeugsteuerungs-, Netzwerksteuerungs- und Messaging-Pakete zu erzeugen. Ereignisse wie das An- oder Abmelden von Kunden können steuern, ob Fahrzeugen ermöglicht wird, in das Netzwerk einzutreten, oder ob sie gezwungen werden, es zu verlassen oder nicht. Für Kunden, die nur Echtzeitverfolgungsdaten wünschen, werden die jeweiligen Fahrzeuge nicht in dem Netzwerk zugelassen, sofern sie nicht angemeldet sind. Andere Kunden benötigen möglicherweise Verfolgungsverlaufsinformationen, und in solchen Fällen werden Fahrzeuge zu jeder Zeit, zu der sie sich im Netzwerk befinden, verfolgt. Flottenteilnehmer mit geringen Anforderungen an Aktualisierungsraten, zum Beispiel wenige Male pro Tag, können Fahrzeugpositionen manuell durch ihre Bedienstationen anfordern. Ihre Fahrzeuge werden durch das NDC 10 auf Basis einer Flotten-CCS-Anforderung zum Senden aufgefordert, können aber nicht in den periodischen Teil des Netzwerks eintreten. Einige Teilnehmer, wie zum Beispiel diejenigen, die Notfalldienste zur Verfügung stellen, sind in der Lage, Änderungen in den Aktualisierungsraten der Fahrzeugposition von ihren Bedienstationen anzufordern.
Wenn Roaming implementiert ist, wird den Flotten ermöglicht, Fahrzeuge unabhängig von ihrer NDC-Verbindung in jedem Gitter zu verfolgen. Da Flottenteilnehmer möglicherweise nicht wissen, wo sich ihre Fahrzeuge zu einem bestimmten Zeitpunkt befinden, sammelt das System der Erfindung Daten für alle Fahrzeuge über ein Weitverkehrsnetz, das jedes NDC verbindet, um der CCS zu ermöglichen, alle Fahrzeuge anzuzeigen, unabhängig von dem Abdeckungsgebiet (Stadtgebiet oder anderes Gebiet), in dem sie sich befinden.
Sendedaten werden im Allgemeinen wie folgt verarbeitet. Bei jedem Rahmen von einer Sekunde erzeugt das NDC 10 Basisnachrichten-Datenpakete, die an die Fahrzeuge 17 übertragen werden sollen. Das NDC sendet regelmäßig Gitter-, FM- und UHF-Identifikationspakete. Textnachrichten- und Benutzerdatenpakete werden so gesendet, wie sie von den CCSs, wie zum Beispiel 14, 15, angefordert werden. Netzwerkkonfigurations- und Fahrzeugsteuerungspakete werden von der Netzmanagementfunktion erzeugt. Alle Pakete werden von dem NDC-Server 42 über eine serielle Hochgeschwindigkeits-Schnittstelle 49 an den NTCC 47 gesendet. Der NTCC mischt die NDC-Pakete mit Echtzeitpaketen und Differentialkorrekturen und sendet einen vollständigen Basisnachrichtenblock an die SCC 48. Die SCC 48 sendet daraufhin die Basisnachricht zu Beginn der nächsten Sekunde. Es besteht eine Verzögerung von zumindest zwei Sekunden zwischen der Zeit, zu der der NDC-Server 42 ein Paket an den NTCC 47 sendet, und der Zeit, zu der es durch die SCC 48 gesendet wird.
Da der NDC-Server 42 im Wesentlichen Datenpakete in einer Ausgabewarteschlange auf dem NTCC-Computer platziert, muss der NTCC 47 dem Server den in dem Zwischenspeicher verfügbaren Platz anzeigen. Abhängig von Fahrzeug- und Benutzervorgängen erzeugen einige Rahmen möglicherweise viele Netzwerk-/Fahrzeugsteuerungs- oder Nachrichtenpakete, und andere erzeugen möglicherweise keine. DGPS-Korrekturpakete, die von dem NTCC bereitgestellt werden, nutzen ebenfalls regelmäßig Bandbreite. Dies erzeugt eine variable Verzögerung zwischen der Zeit, zu der die Pakete durch den Server 42 erzeugt werden, und der Zeit, zu der sie tatsächlich von den Fahrzeugen 17 empfangen werden. Der NTCC 47 muss für den Server 42 Informationen bezüglich der Länge der Warteschlange bereitstellen, so dass der Server im Durchschnitt die Ausgabebandbreite der FM-Übertragung von der Station oder vom Mast 12 nicht überflutet.
Es kann ein Prioritätensystem für Datenpakete implementiert werden, so dass einige Pakete früher gesendet werden als Pakete mit niedrigerer Priorität, die zuerst in die Warteschlange eingestellt wurden. Textnachrichtenpakete können zum Beispiel eine niedrigere Priorität haben als Fahrzeugsteuerungspakete. Wenn Pakete in der Warteschlange verzögert werden, wird ihre Priorität erhöht, so dass sichergestellt ist, dass sie mit einer Verzögerung von höchstens einigen wenigen Rahmen gesendet werden.
Daten, die durch den NDC-Server protokolliert werden sollen, umfassen Informationen über die Abrechnung, den Fahrzeugverfolgungsverlauf für einige Teilnehmer und detaillierte Funkpaket-Protokolldaten für Test-, Analyse- und Wartungszwecke.
Ein PROTRAK-Rechenzentrum verknüpft die NDCs 10 einzelner Städte miteinander zu einem integrierten System, um nationales Roaming zu unterstützen, und dient als Mittelpunkt für eine Datenbank von fahrzeugbezogenen Verfolger-IDs und Kunden-IDs mit Querverweis. Teilnehmerprofile geben an, welche Dienste und Aktualisierungsraten jeder Fahrzeugverfolger benötigt. Daten für Fahrzeuge, die ihren Standort verändern, werden von dem NDC 10, an dem sie empfangen werden, an den NDC übertragen, an dem der Teilnehmer durch das PDC geortet wird.
Die NDC-Datenbank, aus der der Server auf Anforderung Informationen an CCSs, NDC-Bedienstationen etc. verteilt, ist ein Hochleistungs-Datenbankprogramm, wie zum Beispiel der Microsoft Structured Query Language Server (Structured Query Language – SQL – strukturierte Abfragesprache) oder Oracle 8 enterprise. Da diese Anwendungen und die mit ihnen verknüpften Benutzer nur auf eine Teilmenge der in der Datenbank gespeicherten Daten zugreifen dürfen, ist der NDC-Server dafür zuständig, Benutzer zu authentifizieren und den unberechtigten Zugriff auf Daten zu verhindern. Eine CCS, die von dem Kunden A verwendet wird, darf zum Beispiel üblicherweise nicht auf Verfolgungsdaten zugreifen, die für den Kunden B protokolliert werden, sofern sie nicht durch den Kunden B autorisiert wird.
IV. Das PROTRAK-Netzwerk
Daten der HF-Netzwerksteuerung nach dem Zeitmultiplexverfahren (time division multiple access – TDMA) des PROTRAK-Systems und Messaging- und Benutzerdaten werden über einen FM-Übertragungs-Unterträger an Verfolgungscomputer (Verfolger) gesendet, die in den jeweiligen zu verfolgenden Flottenfahrzeugen eingebaut sind. Verfolgerübertragungen umfassen die Verfolgerposition, den Netzwerkstatus und Benutzerdaten. Fahrzeugdaten werden unter Verwendung des herkömmlichen UHF Business Band (eines von Unternehmen genutzten UHF-Frequenzbandes in den USA) an Netzwerk-Hub-Orte gesendet. Der Netzwerkrahmentakt und der Verfolger-Sendeschlitztakt werden letztlich durch einen vom GPS abgeleiteten exakten Takt gesteuert. Das NDC verwaltet das Netzwerk und die Verfolger-Schlitz-Zuweisung. Durch das NDC gesendete Daten werden über ein Modem an die FM-Rundfunkstation gesendet, und von den Verfolgern empfangene Daten werden über ein Modem von den Hub-Orten bereitgestellt.
Für die Basisübertragung basiert der TDMA-Netzwerktakt auf einer exakten Zeit von dem GPS. Das Netzwerk ist in eine Sekunde lange Rahmen unterteilt, 3.600 Rahmen befinden sich in einem Rahmenzyklus, und 168 Rahmenzyklen bestehen in einer Woche. Da die Rahmenzyklusperiode ein gerader Divisor von 604.800 (der Zahl der Sekunden in einer Woche) ist, kann die Rahmennummer direkt von der GPS-Zeit abgeleitet werden. Um Netzwerkbenutzer (Flottenteilnehmer) ohne GPS-Empfänger zu unterstützen, wird die Rahmennummer in jeder Basisnachricht gesendet.
Ein Bit-Sync in der Basisübertragung steuert den Takt des gesamten Netzwerks und zeigt den Beginn jedes Netzwerkrahmens den Verfolgern und den Netzwerk-Hubs an, die alle über FM-Empfänger verfügen. Die Hubs und Verfolger, die über Positionsinformationen verfügen, weisen der FM-Sendeantenne ihre Entfernungen nach, um die Rahmenstartzeit abzuleiten.
Die Art und Weise, wie der Regelkreistakt verarbeitet wird, wird mit Bezug auf 6 beschrieben, die die Basisnachrichten-Rückkopplungsschleife für den Bit-Sync-Takt erläutert. Die Basisnachricht enthält ein Bit-Synchronisationsmuster, das zum Steuern des Verfolger-Übertragungstaktes eingesetzt wird. Die Synchronisation wird gesteuert, um jede ganzzahlige GPS-Sekunde durch ein System mit geschlossenem Regelkreis anzuzeigen. Der NTCC 47 in dem NDC setzt einen FM-Empfänger 58 und einen GPS- Empfänger 54 zum Messen der Verzögerung zwischen der ganzzahligen Sekunde und dem Eintreffen des Bit-Sync in der in dem FM-Empfänger empfangenen FM-Unterträger-Übertragung ein. Nach dem Nachweisen der vorgegebenen Entfernung zwischen der FM-Rundfunkantenne 53 und dem NDC wird die Differenz zwischen der durch GPS angezeigten ganzzahligen Sekunde und derjenigen, die durch das Bit-Sync angezeigt wird, über Modem(s) 47 an die SCC 38 in der FM-Station gesendet. Die SCC 38 verschiebt dann die Übertragungsstartzeit, um den gemessenen Fehler zu korrigieren.
Die SCC empfängt Sendedaten und Taktsteuerinformationen von dem NTCC-Computer 47 und taktet die Daten an den Unterträger-Modulator 68 aus. Es wird zum Beispiel ein externes Modem mit 28,8 kbps von USRobotics an eine SCC 48 über eine serielle periphere Kommunikationsschnittstelle (serial communications interface – SCI) 68332 von Motorola angeschlossen. Die SCC 48 beantwortet Rufe von dem NTCC 47, in dem nächsten Rahmen zu sendende Daten werden durch den NTCC bereitgestellt, und die SCC speichert diese Daten für die Übertragung zwischen. Der NTCC 47 stellt darüber hinaus für die SCC 48 Abstimmungs-Steuerbefehle bereit, die die SCC einsetzt, um die Startzeit und -Periode ihres Senderahmentaktes anzupassen, um die Kohärenz mit der ganzzahligen GPS-Sekunde zu erhalten. Die SCC sendet Modus- und Statusinformationen an den NTCC.
Die SCC 48 muss den Takt des Beginns des Ausgabedatenstroms genau steuern, so dass das Bit-Sync-Muster die Sendeantenne zu einem exakten Zeitpunkt mit Bezug auf die ganzzahlige GPS-Sekunde verlässt. Es ist wünschenswert, dass der Beginn der Datenübertragung auf weniger als eine Mikrosekunde (μs) wiederholbar und auf ungefähr 0,4 μs steuerbar ist. Die SCC setzt programmierbare Zeitgeber in der Zeitverarbeitungseinheit (time processing unit – TPU) des Mikroprozessors 68332 von Motorola ein, um die Übertragung von Daten an den Unterträger-Modulator auszulösen. Der NTCC 47 verwendet Daten von dem FM-Empfänger 58 und dem GPS-Empfänger 54, um das Offset und die Periode der Basisübertragung auszuwerten. Synchronisation wird durch Andern der Zeitgeberperiode auf Basis von Befehlen von dem NTCC erreicht. Wenn das System zunächst eingeschaltet wird, wird eine Periode von ungefähr 20-30 Sekunden benötigt, um Synchronisation zu erreichen. Danach werden kleinere Korrekturen an dem SCC-Takt regelmäßig bereitgestellt. Der Datentakt ist bis auf weniger als 2 Teile pro Million (Parts per million – ppm) relativ zu den Empfangsdatentakten auf den entfernten Verfolgern genau. Eine genaue Beschreibung der Taktsteuerungs-Algorithmen, die durch den NTCC und die in den Fahrzeugen eingebauten Verfolger angewandt werden, wird unten in Abschnitt V dargestellt.
In der Praxis wird die SCC 38 zusammen mit dem Unterträger-Modulator 68, dem Modem und einem Gleichstrom-Netzgerät in eine Halterung eingebaut. Der Unterträger-Modulator 68 kann ein Unterträger-Modulationsgenerator SCA-300B, erhältlich bei Circuit Research Labs, Inc. in Tempe, Arizona, sein, der Binärdaten von der SCC 48 an einem Dateneingabeanschluss 61 mit ± 12 V empfängt. Die Binärdaten werden auf einem digital erzeugten Unterträger gefiltert und moduliert. Der Unterträger-Modulator 68 verfügt darüber hinaus über zwei diskrete Schalterschließungseingänge 59 und 60, die durch die SCC 48 zum Einschalten und Ausschalten der Unterträger eingesetzt werden.
Das NTCC-Dachmodul 55 umfasst einen GPS-Empfänger 54, eine PROTRAK-CPU 56 und einen FM-Empfänger 58. Die CPU 56 vergleicht die Zeit, zu der die FM-Bitsynchronisierung durch den Empfänger 58 empfangen wird, mit den Impulsen pro Sekunde (pulse-per-second – PPS) der ganzzahligen Sekunde von dem durch den GPS-Empfänger 54 empfangenen Signal. Die Zeitdifferenz wird durch Aufzeichnen in einem Taktsteuerregister der TPU in dem Mikroprozessor 68332 von Motorola bei Empfang der PPS und bei Empfang des Bit-Sync gemessen. Die TPU-Zeitgeberauflösung befindet sich in der Größenordnung von 0,2 μs. Die für den NTCC 47 bereitgestellte gemessene Zeitdifferenz wird eingesetzt, um Zeitgeberkorrekturen zu berechnen, die die SCC 48 auf ihren Sendezeitgeber anwenden soll.
Der NTCC fungiert als Echtzeitschnittstelle zwischen dem NDC-Server und dem Netzwerk. Der NTCC 47 behält für die Taktsteuerung die auf der GPS-Zeit basierende Netzwerkrahmenanzahl bei und berechnet Aktualisierungen und stellt sie für den SCC-Sendezeitgeber bereit, damit die Basisübertragung an der GPS-Zeit ausgerichtet bleibt. Es sind drei Taktsteuerung wie folgt verfügbar:

(1) Bei einer Rahmenverzögerungs-/-vorlaufsteuerung kann der NTCC für PPS-Bit-Sync-Offsets von mehr als 0,5 Sekunden die Rahmennummer, die in den Ausgabedaten enthalten ist, verzögern oder beschleunigen, so dass die gesendete Rahmennummer mit dem tatsächlichen Rahmen übereinstimmt, wie durch GPS definiert, wodurch die Zeit in Schritten von einer Sekunde angepasst werden kann.
(2) Bei einer SCC-Sendezeitgeberverzögerungs-/-vorlaufsteuerung kann der Sendezeitgeber für Offsets von 0,5 Sekunden oder weniger mit einem längeren oder kürzeren Wert geladen werden, um eine einmalige Verschiebung in der Ausgabezeit mit Bezug auf die ganzzahlige GPS-Sekunde einzubringen.
(3) Bei der SCC-Sendezeitgeber-Periodenausrichtungssteuerung kann das Intervall zwischen Bit-Sync-Zeiträumen und der ganzzahligen PPS-Sekunde gemessen werden, und Skalenfaktorfehler (Frequenzfehler) in dem Sendezeitgeber können durch Anpassen des nominalen Zeitgeberwertes nach oben oder nach unten korrigiert werden.

Es kann eine Periode von 20-30 Sekunden für eine grobe Angleichung unter Verwendung der obigen Steuerungen (1) und (2) erforderlich oder wünschenswert sein. Sobald die SCC synchronisiert ist, werden die Steuerungen (2) und (3) eingesetzt, um feine Korrekturen an der Synchronisation vorzunehmen, um kleine Zeitgeberfehler, die der Temperatur und verbleibenden Synchronisationsfehlern zuzuschreiben sind, zu berücksichtigen.
Bei „Basisnachrichten" handelt es sich um Daten, die von dem NDC über das Rundfunknetz auf dem FM-Unterträger an die Verfolger gesendet werden. Die Basisnachrichtendaten enthalten Netzwerksteuerungs-Informationen, Wiederholungsintervall-Schlitzzuweisungsdefinitionen, DGPS-Korrekturdaten, Messaging-/Funkrufdaten und benutzerspezifische Daten. Das Format der an die Verfolger übertragenen Basisdaten wird in Kürze hier beschrieben.
Für den Informationsfluss werden Nachrichtendaten, die die Netzwerkaktivität steuern (Netzwerk- und Verfolger-Steuerpakete) durch den NDC-Server 42 (4) in Reaktion auf Daten erzeugt, die von den Verfolgern und von den CCSs (z. B. 44) (oder den NDCs, z. B. 43) empfangen werden. Funkruf- und Benutzerdatenpakete werden durch Befehle der Benutzer erzeugt. Diese Pakete werden an den NTCC 47 für das Zusammenfügen zu einer Basisnachricht gesendet. Der NTCC fügt eine Netzwerkrahmennummer und DGPS-Korrekturdaten nach Bedarf hinzu und wendet dann Verschlüsselung, Fehlerüberwachungs-Codierung und Bitverschachtelung an. Die resultierende Nachricht wird an die SCC 48 gesendet, die das Bit-Sync-Muster einfügt und die Nachrichtendaten zu Beginn des nächsten Rahmens sendet. Die Verarbeitungsschritte werden wie folgt zusammengefasst:

1. Das NDC 10 berechnet Basisnachrichten-Datenpakete und sendet sie an den NTCC 47.
2. Bei jedem Intervall von einer Sekunde führt der NTCC 47 Folgendes aus: a) Zusammenstellen der verfügbaren Datenpakete von dem NDC 10, der Rahmennummer und der DGPS-Korrekturen, falls erforderlich, zu einem einzelnen Nachrichtenblock. Unbelegte Bytes werden aufgefüllt. b) Ausführen von Verschlüsselung des Nachrichtenblocks. c) Ausführen von Fehlerüberwachungs-Codierung an dem Nachrichtenblock. In der derzeit bevorzugten Ausführungsform wird ein (23,12)-Golay-Code verwendet, aber es kann auch ein anderer Code eingesetzt werden. d) Ausführen von Bitverschachtelung. Daten werden durch Senden von langen Abschnitten aller Bit 1, gefolgt von den Bit 2 etc. übertragen, wodurch eine erhebliche Bündelfehler-Korrekturfähigkeit bereitgestellt wird. e) Senden des Nachrichtenblocks an die SCC 48 zur Übertragung.
3. Die SCC 48 fügt ein Bit-Synchronisationsmuster vor dem Nachrichtenblock ein, Miller-codiert die Daten und sendet sie am Beginn des Rahmens an den Unterträger-Modulator 68 (6), nachdem der Nachrichtenblock von dem NTCC 47 empfangen worden ist.

Das Format des Nachrichtenblocks ist wie folgt. Die maximale Bitrate für den Unterträger-Modulationsgenerator SCA-300B, der als 68 eingesetzt wird, beträgt 4.800 bps. Es ist wünschenswert, die maximal verfügbare Bitrate zu verwenden, die mit den Modulationsindex-Anforderungen (für die Empfängerempfindlichkeit) und der Datenblockgröße vereinbar ist. Es wird ein (23,12)-Golay-Code mit Bitverschachtelung eingesetzt; Daten werden in Blöcken von 40 × 23 = 920 Bits gesendet. Es werden fünf Blöcke mit insgesamt 4.600 Bits gesendet. Die SCC 48 Miller-codiert die Daten und fügt das Bit-Sync hinzu. Der Miller-Code verdoppelt die Zahl der Bits, so dass die SCC Daten mit einer Geschwindigkeit von ungefähr 9.328,36 bps sendet. Für 4.600 Bits werden 986,24 Millisekunden benötigt. Da eine 8-Bit-Präambel und ein 24 Bit langes Bit-Sync 6,8608 ms erfordern, verfügt die SCC 48 über eine Lückenzeit von 6,8992 Millisekunden, um den Sendetakt mit aktualisierten Synchronisationen neu zu starten, um die nächste Nachricht zu senden.
7 ist ein Schaubild des Basis-(NDC-)Nachrichten-Rundfunkformates. Am Beginn 70 jeder ganzzahligen Sekunde wird das Bit-Sync-Muster 71 gesendet, gefolgt von den Basisnachrichtendaten 72 und schließlich von einem sehr kurzen Intervall 73 an Totzeit bis zum Beginn der nächsten ganzzahligen Sekunde. Bitverschachtelung wird auf die Basisnachricht angewandt, um die Anfälligkeit für Bündelfehler zu verringern. Die Verschachtelung wird blockweise angewandt. Der Golay-Code korrigiert drei Fehler in 23, so dass eine Verschachtelung von 40 Bit Tiefe die Korrektur eines Bündels von 120 Bit oder 25,728 Millisekunden ermöglicht. Diese Zeit reicht aus, um eine Desensibilisierung zu korrigieren, die in der gemeinsamen Sende-/Empfangs-Antenne auftritt, wenn ein Verfolger in seinem TDMA-Schlitz von 20 Millisekunden sendet.
Für die Bitsynchronisation verwenden die Verfolger und die Netz-Hubs das Bit-Sync in der FM-Übertragung, um ihre Takte für das Senden und den Empfang von Verfolgerdaten zu synchronisieren. Verfolger mit gültigen Positionsdaten können die bekannte Entfernung zu dem FM-Übertragungsort verwenden, um ihre Übertragungen auszugleichen, um die Verzögerung beim Empfang des Bit-Sync zu berücksichtigen.
Für die Verfolgeridentifizierung wird allen Verfolgern werksseitig eine Verfolger-ID von 30 Bit zugewiesen, die im gesamten PROTRAK-System eindeutig ist. Während es sich hierbei um die einzige ID handeln könnte, die zur Identifizierung eines Verfolgers verwendet wird, wird den Verfolgern auch eine kürzere ID zugewiesen, wenn sie ihre Hauptwiederholungsintervall-Schlitzzuweisung empfangen, wodurch dem NDC-Server ermöglicht wird, die Verfolger in ihrem HF-Netzwerkgitter mit weniger Datenbits zu identifizieren. Die kürzeren IDs bestehen aus einer Netzwerk-ID und einer Schnittstellen-ID. Da zwei Netzwerkgrößen verwendet werden, wird das höchstwertige Bit der 16-Bit-ID zum Anzeigen der Netzwerkgröße eingesetzt. Tabelle 1 zeigt unten das Netzwerk-/Schnittstellen-ID-Format für die beiden verwendeten Netzwerkgrößen. Tabelle 1. Netzwerk-/Schnittstellen-ID-Format

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

0 Netzwerk-ID Schnittstellen-ID

1 Netzwerk-ID Schnittstellen-ID
Um Unterbrechungen des Texts so gering wie möglich zu halten, werden weitere Tabellen zum größten Teil im Anhang B dargestellt.
Den Verfolgern kann eine ID innerhalb eines der 128 Netzwerke mit 256 Schnittstellen-IDs oder innerhalb eines der 2.048 Netzwerke mit 16 Schnittstellen-IDs zugewiesen werden. Netzwerk-IDs werden von dem NDC-Server eingesetzt, um die Zahl der Bits zu reduzieren, die erforderlich sind, um eine Teilmenge der Verfolgermodule eines Kunden zu identifizieren. Wenn zum Beispiel ein Flottenbetreiber eine Nachricht an zehn seiner Verfolger (Fahrzeuge) sendet, die sich alle in demselben Netzwerk mit 16 Verfolgern befinden, kann der NDC-Server diese Verfolger unter Verwendung von 52 Bits einzeln adressieren, wobei 12 Bits die Netzwerk-ID anzeigen und nur 4 Bits erforderlich sind, um jede Verfolgerschnittstellen-ID zu identifizieren.
Da der DMCS Kundengruppen verwaltet, kann der NDC-Server sich mit dem DMCS abstimmen, um Informationen über Kundengruppen zu erhalten. Oder der NDC-Server kann protokollierte Daten verwenden, um festzustellen, welche Verfolger zusammengefasst worden sind. Als Folge platziert der NDC-Server Verfolger mit derselben Gruppen- und/oder Kunden-ID in demselben Netzwerk. Während Verfolger von unterschiedlichen Kunden und/oder Gruppen in demselben Netzwerk platziert werden können, können Verfolgergruppen, die zusammen in demselben Netzwerk platziert werden, mit einer relativ kleinen Zahl von Bits identifiziert werden.
Das Netzwerk-/Schnittstellen-ID-Zuweisungsschema wird in Datenpaketformaten eingesetzt. Die Basisübertragungsdaten enthalten eine variable Zahl von miteinander verketteten kurzen Datenpaketen, die je nach Typ eine feste oder eine variable Länge aufweisen. Diese Pakete umfassen DGPS-Korrekturdaten, Netzwerkbeschreibungs-Informationen, Benutzerbefehle und -messaging sowie Verfolgersteuerbefehle.
A. Datenpakete und -formate
Datenpaketdecodierung wird nach einer Fehlererkennung-/-korrektur und -entschlüsselung ausgeführt. Jede Basisnachricht (d. h. von dem NDC 10) beginnt mit einer Rahmen-ID. Es folgen Datenpakete, bis der verfügbare Platz in dem Datenblock aufgefüllt ist oder keine zu sendenden Pakete übrig bleiben. Der unbelegte Platz in der Nachricht wird ganz mit Nullen aufgefüllt, die in einem abwechselnden Eins-Null-Muster im Miller-Code codieren. Jedes Paket beginnt mit einem Paket-ID-Byte gefolgt von den Daten in dem Paket und einem Prüfsummen-/Paritätswort. Die Synchronisation der Daten durch den Paketdecodierer wird aufrechterhalten, indem überprüft wird, ob das erste Byte nach der Rahmen-ID eine Paket-ID ist, und dann auf die Zahl der Bytes in dem ersten Paket vorausgeschaut wird, um zu überprüfen, ob die Prüfsumme korrekt ist und das nachfolgende Byte ebenfalls eine gültige Paket-ID ist. Dies dauert an, bis alle Datenpakte decodiert sind. Eine Basispaket-Zusammenfassung wird in Tabelle 2 (Anhang B) dargestellt.
Textnachrichtenpakete werden als Antwort auf Nachrichten/Funkrufbefehle von den Benutzerbedienstationen (d. h. von den CCSs) erzeugt. Als Beispiel für die vorliegende beispielhafte Ausführungsform werden als die maximale Nachrichtenlänge 80 Zeichen angenommen. Darüber hinaus kann ein optionaler Antwortsatz von 28 Zeichen angehängt werden, wie unten mit Bezug auf vordefinierte Nachrichten-Antwortsätze erörtert wird.
Textnachrichten können an die Verfolger (d. h. an in den Fahrzeugen 17 eingebaute Verfolgungscomputer) auf die folgenden Weisen adressiert werden:

• Verfolger-ID
• Netzwerk-/Schnittstellen-ID
• Kunden-ID
• Schnittstellen-ID
• Schnittstellen-ID-Bereich innerhalb eines Netzwerks

Bei der vorliegenden beispielhaften Ausführungsform beträgt die Verfolger-ID-Nummer 30 Bit, die Netzwerk-/Schnittstellen-ID beträgt 16 Bit, und die Kunden-ID beträgt 24 Bit. Eine variable Anzahl von Adressbits ist abhängig von der Adressiermethode und der Zahl der adressierten Verfolger reserviert.
Eine Quittierung von Textnachrichten wird durch den Verfolger durch Anfordern eines Hilfswiederholungsintervall-Zeitschlitzes ausgeführt. Der Hilfsschlitz wiederholt sich in Intervallen von 12 Sekunden und umfasst ausreichend Schlitze, um die Quittierung zu senden, z. B. einen zuzüglich weiterer Schlitze, um Wiederholungen zu ermöglichen. Tabelle 3: „Textnachrichtenpaket – Einzelner Verfolger oder Gesamte Flotte"; Tabelle 4: „Vordefinierte Nachrichten-Antwortsätze"; Tabelle 5: „Testnachrichtenpaket – Verfolgergruppe"; Tabelle 6: „Verfolgergruppen-Nachrichtenschnittstellen-ID-Listenpaket”; und Tabelle 7: „Verfolger-ID-Listenblock", werden in Anhang B dargestellt.
Ein Paket für die „Definition von vordefinierten Nachrichten" (Tabelle 8, Anhang B) stellt für die Verfolger (bisweilen hier als Verfolgermodule bezeichnet) eine Textnachricht bereit, die mit einer vorgegebenen vordefinierten Nachrichten-ID verknüpft werden sollte. Obwohl einzelne Verfolger diese Definition anfordern, wird die Nachricht an alle Verfolger übertragen, die mit einem bestimmten Kunden (Flottenbetreiber, Teilnehmer oder Benutzer, da diese Begriffe hier synonym verwendet werden) verknüpft sind. Verfolger, die diese Nachricht empfangen, speichern die vordefinierte Nachrichtendefinition, wenn die vorgegebene Kunden-ID mit ihrer bekannten Kunden-ID übereinstimmt. Diese gespeicherte Verknüpfung wird dann verwendet, um die bei Empfang eines „Paketes für vordefinierte Nachrichten" geeignete Nachricht anzuzeigen. Letzteres Paket ermöglicht ein kürzeres Nachrichtenformat für „vorgefertigte" Benutzernachrichten, die häufig durch einen einzelnen Kunden gesendet werden. Da die Verfolger den Text dieser Nachrichten von vornherein kennen, brauchen nur eine Nachrichten-ID und eine zyklische Redundanzprüfung (cyclic redundancy check – CRC) durch das NDC gesendet zu werden. Die ID identifiziert die Nachricht, und die CRC ermöglicht dem Verfolger festzustellen, ob der Text mit der CRC der bekannten vordefinierten Nachricht übereinstimmt.
Vordefinierte Nachrichten-CRCs werden unter Verwendung der gesamten vordefinierten Nachricht berechnet. Daher kann ein Verfolger feststellen, ob die ID einer neuen Nachricht neu zugewiesen worden ist. Wenn dies zutrifft oder wenn eine vorgegebene vordefinierte Nachricht unbekannt ist, kann der Verfolger die gesamte vordefinierte Nachricht unter Verwendung eines „Paketes zur Anforderung einer vordefinierten Nachricht" anfordern. Bei Empfang eines solchen Anforderungspaketes stellt der NDC-Server dem anfordernden Verfolger die vordefinierte Nachricht in einem „Paket zur Definition einer vordefinierten Nachricht" zur Verfügung. Die Verfolgeradressierung erfolgt ähnlich wie die für Textnachrichten. Die Struktur des „Paketes für die ID einer vordefinierten Nachricht" für einen einzelnen Verfolger oder eine gesamt Flotte wird in Tabelle 9 und für eine Verfolgergruppe in Tabelle 10 des Anhangs B dargestellt.
DGPS-Korrekturdatenpakete (Tabelle 11) werden durch den NTCC erzeugt und in den Basisnachrichtenblock ungefähr in Intervallen von 10 Sekunden eingefügt. Die Abstands- /Abstandsänderungskorrekturen werden durch den GPS-Empfänger (z. B. 54, 6) in dem NTCC-Dachmodul 55 berechnet. Die können im RTCM- oder einem anderen gewünschten Format erfolgen. Die Skalierung der Korrekturen ist die gleiche wie bei RTCM-104. Der NTCC sendet Korrekturdaten in einem Format mit vollständigen Korrekturen im Stil von „Typ 1" und „Typ 2". Andere RTCM-Nachrichtentypen können auf Wunsch alternativ unterstützt werden. Die RTCM-Nachrichtentypen 1 und 2 weisen das gleiche Format auf, wobei sich nur die Rahmen-IDs unterscheiden. Die Länge des Paketes ist variabel und hängt von der Zahl der Korrekturen darin ab. Die Zahl der Bytes beträgt 5 + 5N_SV.
Ein Benutzerdaten-Nachrichtenpaket unterstützt generische, benutzerspezifische Daten, die von den CCSs an die Verfolger gesendet werden. Das Format der Nachricht ist ähnlich wie das des Textnachrichtenpaketes, wobei 80 Datenbytes für Kundenzwecke verfügbar sind. Es muss kundenspezifische Software in den Verfolger, das MDE und die CCS einprogrammiert werden, damit der Kunde diese Nachricht nutzen kann. Benutzerdaten-Paketadressierung und -Quittungen stimmen mit denen von Textpaketen überein. Die Struktur des „Benutzerdaten-Nachrichtenpaketes" für einen einzelnen Verfolger oder eine gesamte Flotte wird in Tabelle 12 und für eine Verfolgergruppe in Tabelle 13 dargestellt.
Ein „Gitter-Identifizierungspaket" (Tabelle 14) stellt den Verfolgern den Mittelpunkt von örtlichen und angrenzenden PROTRAK-Navigationsgittern zur Verfügung (siehe z. B. 11, in Kürze hier zu erörtern). Bei einer beispielhaften Ausführungsform ist das Navigationsgitter ein quadratischer Bereich von ungefähr 262 km Seitenlänge, der grob auf den Mittelpunkt jedes PROTRAK-Abdeckungsgebietes ausgerichtet ist. Jedes Navigationsgitter (Abdeckungsgebiet) verfügt über eine eindeutige ID-Nummer von 15 Bit. Das „Gitter-ID-Paket" wird in Intervallen von ungefähr 20 Sekunden gesendet und wechselt zwischen dem lokalen Gitter und angrenzenden Gittern ab. Informationen über angrenzende Gitter werden bereitgestellt, um Verfolgern, die ihren Standort verändern, zu ermöglichen, das PROTRAK-System in neuen Abdeckungsgebieten schnell zu orten, während sie sich durch das Abdeckungsgebiet bewegen. Die Verfolger speichern Gitterinformationen bevorzugt in einem nicht flüchtigen Speicher.
Der Mittelpunkt des Navigationsgitters wird in skalierten ganzen Zahlen von 24 Bit mit einem LSB (least significant bit – niedrigstwertiges Bit) von ungefähr 2,4 m Breite bereitgestellt, was für die meisten Verfolger-Navigationsanwendungen ausreichend sein sollte. Es wird angenommen, dass das nominale Navigationsgitter quadratisch ist und aus 1.024 Quadraten von 64 km² besteht. Falls erforderlich, können zusätzliche Daten zu dieser Nachricht hinzugefügt werden, um rechteckige oder unregelmäßig geformte Navigationsgitter zu definieren.
Ein „FM-Identifikationspaket" (Tabelle 15) stellt den Verfolgern die FM-Basisübertragungsfrequenz und die Senderstandorte für die örtlichen und angrenzenden PROTRAK-Navigationsgitter zur Verfügung. Der Senderstandort wird für Berechnungen der Übertragungsverzbgerungszeit verwendet. Es wird darüber hinaus die Frequenz des Unterträgers bereitgestellt. Die Verfolger speichern bevorzugt außerdem Senderinformationen in einem nicht flüchtigen Speicher. Der Senderstandort wird in 24-Bit-skalierten ganzen Zahlen mit einem LSB von ungefähr 2,4 m Breite bereitgestellt, was für Übertragungsverzögerungs-Berechnungen völlig ausreichend ist. Jedes Navigationsgitter kann über mehrere FM-Sender verfügen. Das Paket unterstützt bis zu vier Sender durch eine Sender-ID-Nummer. Falls erforderlich, können aus Gründen der Kapazität oder der Abdeckung zusätzliche Daten in dieser Nachricht oder in einer weiteren Nachricht verwendet werden, um Gitterbereiche zu definieren, die von jedem Sender bedient werden.
Ein „UHF-Identifizierungspaket" (Tabelle 16) stellt den Verfolgern die UHF-Frequenz zur Verfügung, auf der sie ihre Zustandsdaten senden sollen. Frequenzen werden für die örtlichen und angrenzenden PROTRAK-Navigationsgitter bereitgestellt. Die Verfolger sollten auch hier die UHF-Frequenzinformationen in einem nicht flüchtigen Speicher speichern. Jedes Navigationsgitter kann über mehrere Verfolger-Sendefrequenzen verfügen, und das „UHF-Identifizierungspaket" unterstützt bis zu vier Frequenzen durch eine Frequenz-ID-Nummer. Falls erforderlich, können aus Gründen der Kapazität und der Abdeckung zusätzliche Daten in dieser Nachricht oder in einer weiteren Nachricht verwendet werden, um Gitterbereiche zu definieren, in denen die UHF-Frequenz jeweils verwendet werden soll.
Das NDC 10 sendet ein Paket, das die aktuelle GPS-Zeit enthält, in Intervallen von 10-20 Sekunden, um die Initialisierung der in die Fahrzeuge eingebauten GPS-Empfänger, die mit den Verfolgern verknüpft sind, zu unterstützen. Das „GPS-Zeitpaket" (Tabelle 17) wird berechnet und durch den NTCC in den Basisnachrichtenblock eingefügt. Das Zeitzonen-Offset und die UTC-Schaltsekunden werden zu der aktuellen GPS-Zeit addiert, um die Ortszeit zu bestimmen.
Ein „Paket zum Festlegen einer Definition für einen Wiederholungsintervall-Schlitz" (Tabelle 18) weist einem Verfolger ein kontinuierliches Wiederholungsintervall und eine Netzwerk-/Schnittstellen-ID zu. Verfolger, die dieses Paket empfangen, senden eine Verfolgungsaktualisierung an den NDC-Server 42, wenn (Rahmen-ID) mod (Intervalllänge) gleich dem in dem Paket angegebenen Wiederholungsintervallindex ist. Wenn ein Verfolger bereits über ein zugewiesenes Hauptwiederholungsintervall verfügt, wird es durch das Intervall in diesem Paket ersetzt. Verfolger können feststellen, ob dieses Paket an sie adressiert ist, indem sie überprüfen, ob das Verfolger-ID-Feld der Verfolger-ID des Empfängers gleichkommt. Falls dies so ist, setzt der Verfolger das zugewiesene Wiederholungsintervall und die Netzwerk-/Schnittstellen-ID ein. Anderenfalls stellt der Verfolger sicher, dass keines seiner Wiederholungsintervalle mit dem beschriebenen Intervall übereinstimmt. Falls das beschriebene Intervall mit dem aktuellen Hauptintervall übereinstimmt, beendet der Verfolger die Verwendung dieses Intervalls (und der Netzwerk-/Schnittstellen-ID) und versucht, einen Netzwerkeintritt auszuführen. Oder, wenn das beschriebene Intervall mit einem der aktuellen Hilfsintervalle des Verfolgers übereinstimmt, entfernt der Verfolger dieses Intervall aus seiner Liste.
Die mit dem Hauptwiederholungsintervall zugewiesene Netzwerk-/Schnittstellen-ID ist gültig, während das Hauptwiederholungsintervall gültig ist. Als Folge antworten die Verfolger auf Nachrichten mit ihrer Verfolger-ID oder ihrer temporären Netzwerk-/Schnittstellen-ID, während sie sich in dem HF-Netzwerk befinden. Sobald ein Verfolger das HF-Netzwerk verlässt (oder sein Hauptwiederholungsintervall gelöscht wurde), ist die verknüpfte Netzwerk-/Schnittstellen-ID nicht mehr für diesen Verfolger gültig. Verfolger, die eine Zuweisung des Hauptwiederholungsintervalls empfangen, können das zugewiesene Intervall einsetzen, bis sie beantragen, das Netzwerk zu verlassen, ein Paket zum Löschen des Wiederholungsintervalls quittieren oder die Selbstlöschungs-Aktualisierungsanzahl überschreiten.
Ein „Paket zum Hinzufügen eines Hilfswiederholungsintervall-Schlitzes" weist einem Verfolger ein Wiederholungsintervall für ein einzelnes Intervall zu (Tabelle 19). Verfolger, die dieses Paket empfangen, senden eine Verfolgungsaktualisierung an den NDC-Server 42, wenn (Rahmen-ID) mod (Intervalllänge) gleich dem in dem Paket angegebenen Wiederholungsintervallindex ist. Als Folge des Empfangens dieses Paketes sendet der Verfolger eine einzelne Aktualisierung. Verfolger können unter Verwendung der Verfolger-ID oder der Netzwerk-/Schnittstellen-ID feststellen, ob dieses Paket an sie adressiert ist. Wenn das Verfolger-ID-Feld den Empfänger identifiziert, setzt der Verfolger das zugewiesene Wiederholungsintervall ein, um seine Verfolgungsinformationen an den NDC-Server zu berichten. Anderenfalls stellt der Verfolger sicher, dass er seine Verfolgungsinformationen nicht unter Verwendung des beschriebenen Intervalls berichtet. Es sollte beachtet werden, dass, obwohl ein Verfolger mehrere Hilfswiederholungsintervalle aufweisen kann, jeder Verfolger nur über ein Hauptverfolgungsintervall verfügt. Tabelle 20 (Anhang B) stellt die Struktur des „Paketes zum Hinzufügen der Definition eines Hilfswiederholungsintervall-Schlitzes" für ein einzelnes Intervall durch eine Netzwerk-/Schnittstellen-ID dar.
Das Paket zum „Hinzufügen der Definition eines Hilfswiederholungsintervall-Schlitzes" für eine begrenzte Anzahl von Intervallen weist einem Verfolger für eine vorgegebene Anzahl von Intervallen ein Wiederholungsintervall zu. Verfolger, die dieses Paket empfangen, senden eine Verfolgungsaktualisierung an den NDC-Server 42, wenn (Rahmen-ID) mod (Intervalllänge) gleich dem in dieser Nachricht angegebenen Wiederholungsintervallindex ist, und diese Aktualisierungen werden durch die Verfolger so viele Male gesendet, wie Intervalle vorhanden sind. Auch hier können die Verfolger unter Verwendung des Verfolger-ID- oder des Netzwerk-/Schnittstellen-ID-Feldes feststellen, ob dieses Paket an sie adressiert ist, und ihre jeweiligen Verfolgungsinformationen in der gleichen Weise, wie oben angegeben, an den NDC-Server berichten oder nicht berichten. Die Tabellen 21 und 22 stellen die Struktur des Paketes zum „Hinzufügen der Definition eines Hilfswiederholungsintervall-Schlitzes" für eine begrenzte Anzahl von Intervallen jeweils durch die Verfolger-ID und durch die Netzwerk-/Schnittstellen-ID dar.
Ein „Paket der verfügbaren Netzwerkeintrittsschlitze" (Tabelle 23) enthält eine Schlitzanzahl, die die Anzahl der Schlitze innerhalb eines Rahmens von einer Sekunde angibt, und eine Bitmaske, die die Schlitze angibt, die gegenwärtig für den Netzwerkeintritt verfügbar sind. Das Bit 0 von Byte 2 gibt an, ob der Schlitz 0 verfügbar ist, Bit 1 von Byte 2 gibt an, ob Schlitz 1 verfügbar ist, Bit 0 von Byte 3 gibt an, ob Schlitz 8 verfügbar ist etc. Bevor einem Verfolger ermöglicht wird, ein „Netzeintrittsanforderungs"-Paket zu senden, muss er ein Paket der „verfügbaren Netzwerkeintrittsschlitze" empfangen, und er muss vor dem Senden seiner „Netzeintrittsanforderung" erfolgreich jede Basispaketnachricht empfangen. Das Paket ist nur gültig, bis das nächste empfangen wird, so dass der Verfolger keine Netzwerkeintrittsanforderungen in einem Schlitz sendet, der nicht mehr verfügbar ist. Der NDC-Server 42 überträgt dieses Paket, wenn sich die verfügbaren Netzwerkeintrittsschlitze ändern, und sendet es außerdem zumindest alle 10 Sekunden.
Ein Paket mit „Informationen zur Wiederholungsintervall-Schlitzkonfiguration" (Tabelle 24), das alle 30 Sekunden durch den NDC-Server gesendet wird, gibt die Rahmenzykluslänge, die Selbstlöschungs-Intervallanzahl und den Verfolger-ID-Anforderungsmodus an. Jeder dieser Werte wird benötigt, damit ein Verfolger den Sendetakt und/oder das Format seiner Pakete zur periodischen Verfolgungsaktualisierung bestimmen kann. Die Rahmenzykluslänge gibt die Anzahl der Rahmen von einer Sekunde an, die in einem Rahmenzyklus enthalten sind. Da diese Anzahl immer ein Divisor der Anzahl der Sekunden in einer GPS-Woche ist, kann eine Rahmen-ID unter Verwendung der GPS-Zeit bestimmt werden. Die Rahmen-ID wird unter Verwendung der GPS-Sekunden wie folgt berechnet: Rahmen-ID = (GPS-Sekunde) mod (Rahmenzykluslänge)
Die Selbstlöschungs-Aktualisierungsanzahl gibt die Anzahl der periodischen Aktualisierungen an, die ein Verfolger in einem zugewiesenen Wiederholungsintervallschlitz bereitstellen kann, ohne das Wiedereintreten in das Netzwerk zu beantragen. Verfolger mit einem zugewiesenen Wiederholungsintervallschlitz müssen beantragen, dass ihnen ihr Wiederholungsintervallschlitz neu zugewiesen wird, indem sie eine „Anforderung zum Neuzuweisen des Hauptwiederholungsintervall-Schlitzes" oder eine „Anforderung zum Neuzuweisen des Hilfswiederholungsintervall-Schlitzes" für ihren Netzwerkstatuscode anzeigen. Verfolger, die nicht erreichen, dass ihnen ihr Wiederholungsintervallschlitz neu zugewiesen wird, bevor sie die Selbstlöschungs-Aktualisierungsanzahl erreichen, löschen ihren zugewiesenen Wiederholungsintervallschlitz.
Der „Verfolger-ID-Anforderungsmodus" gibt an, ob Verfolger ihre Verfolger-ID-Nummer innerhalb von Verfolgerdatenpaketen zur Verfügung stellen müssen. Dieser Anforderungsmodus kann angeben, dass Verfolger ihre Verfolger-ID-Nummer nicht zur Verfügung stellen müssen, dass Verfolger ihre Verfolger-ID nur für die nächste Aktualisierung zur Verfügung stellen müssen oder dass Verfolger ihre Verfolger-ID für alle Aktualisierungen zur Verfügung stellen müssen.
Verfolgermodule sammeln Selbsttestinformationen (Selbsttest – built-in test – BIT), die daraufhin für den NDC-Server mit einer Rate (in Sekunden) zur Verfügung gestellt wird, die in dem „Wiederholungsintervallschlitz-Konfigurationsinfo"-Paket festgelegt ist. Wenn die Rate Null ist, braucht der Verfolger das BIT-Paket nicht zur Verfügung zu stellen. Wenn die Rate größer als Null ist, stellt der Verfolger sein BIT-Paket mit der angegebenen Rate zur Verfügung. Um eine BIT-Paketaktualisierung zur Verfügung zu stellen, fordern die Verfolger einen Hilfsschlitz an, wenn (Verfolger-ID) mod (BIT-Paketrate) der aktuellen Rahmen-ID gleichkommt. Als Folge werden Verfolgeranforderungen nach Hilfsschlitzen gleichmäßig verteilt. Wenn eine Anforderung nach einem Hilfsschlitz eine terminierte Aktualisierung eines Verfolgers behindern würde, stellt der Verfolger die Anforderung bis zu einem späteren Zeitpunkt zurück.
Der NDC-Server setzt ein „Netzwerkeintrittsantwort"-Paket (Tabelle 25) ein, um auf eine Netzwerkeintrittsanforderung eines Verfolgers zu antworten, wenn der Diensttyp des Verfolgers auf anderem Wege den Netzwerkeintritt nicht zulässt. Der in diesem Paket enthaltene zugewiesene Verfolgerzustandscode ermöglicht es einem Verfolger, seinen Typ und seine Anforderungen zu bestimmen, die einem Wiederholungsintervallschlitz zugewiesen werden sollen. Verfolger für manuelle Verfolgung müssen auf ein „Wiederholungsintervallschlitz-Definitionspaket" (Einzelintervall) warten, und Verfolger für reine Anmeldungsverfolgung und unbekannte Verfolger müssen auf eine „Netzwerkeintritts-Anforderungsgenehmigungs"-Nachricht warten. Der NDC-Server 42 kann eine „Netzwerkeintritts-Anforderungsgenehmigungs"-Nachricht als eine Folge davon senden, dass sich eine CCS (z. B. 14, 3) mit dem DMCS 27 verbindet oder weil der Diensttyp eines einzelnen Verfolgers sich geändert hat.
Der NDC-Server sendet ein „Netzwerkeintritts-Anforderungsgenehmigungs"-Paket (Tabelle 26) an die gesamte Flotte von LOT-Verfolgern eines Teilnehmers, an eine Gruppe von Verfolgern eines Teilnehmers oder einen einzelnen Verfolger, damit ein oder mehrere Verfolger den Eintritt in das Netzwerk anfordern können. Wenn ein Teilnehmer nicht verbunden ist, um seine Gruppe von LOT-Verfolgern anzeigen zu können, wird den Verfolgern nicht gestattet, in das HF-Netzwerk einzutreten, sondern sie werden stattdessen benachrichtigt, dass sie auf eine Netzwerkeintritts-Anforderungsgenehmigung warten müssen. Wenn ein Teilnehmer sich mit dem DMCS unter Verwendung der CCS-Software verbindet, überprüft der DMCS, ob bereits ein Teilnehmer mit dieser ID verbunden ist, und sendet, wenn dies nicht der Fall ist, eine Nachricht an den NDC-Server, die alle Verfolger in der Gruppe der CCS-Benutzer identifiziert. Der NDC-Server antwortet auf diese Nachricht durch Senden eines „Netzwerkeintritts-Anforderungsgenehmigungspaketes", um den Verfolgern in der Gruppe der CCS-Benutzer zu ermöglichen, den Netzwerkeintritt anzufordern. Abhängig von der Teilnehmergruppengröße oder der Teilnehmerflottengröße kann dieses Paket durch den Server an die gesamte Flotte oder nur an eine Gruppe von Verfolgern mit dem Ziel gesendet werden, die erforderliche HF-Bandbreite so weit wie möglich zu reduzieren. Das „Netzwerkeintritts-Anforderungsgenehmigungspaket" kann darüber hinaus gesendet werden, wenn der Diensttyp eines Verfolgers verändert wird, wie zum Beispiel wenn ein Verfolger für manuelle Verfolgung in einen Verfolger für kontinuierliche Verfolgung umgewandelt wird.
Eine „Nachricht zum Löschen zugewiesener Wiederholungsintervalle" (Tabelle 27) wird durch den NDC-Server durch ein Verfolger-ID-, Kunden-ID- oder Verfolger-ID-Listenpaket gesendet, um anzuzeigen, dass ein Verfolger oder eine Gruppe von Verfolgern einige oder alle ihre zugewiesenen Wiederholungsintervalle löschen sollte. Dies würde zum Beispiel erfolgen, wenn der einzige Teilnehmer in einer Gruppe von LOT-Verfolgern die Verbindung mit dem DMCS trennt, da Informationen von diesen Verfolgern nicht mehr berichtet werden, wenn ihre Anzeige durch den getrennten Teilnehmer beendet wird. Der DMCS stellt für den NDC-Server eine Liste von Verfolgern bereit, die aus dem HF-Netzwerk entfernt werden sollen. Die „Nachricht zum Löschen zugewiesener Wiederholungsintervalle" kann darüber hinaus an einzelne Verfolger gesendet werden, wie zum Beispiel wenn der Dienst eines Verfolgers für kontinuierliche Verfolgung in manuelle Verfolgung umgewandelt wird, in welchem Fall der betreffende Verfolger über seinen neuen Dienst informiert wird und aufgefordert wird, auf einen Wiederholungsintervallschlitz zu warten. Wenn sowohl der Diensttyp als auch die Aktualisierungsrate eines einzelnen Verfolgers verändert werden (z. B. von kontinuierlich mit einer Aktualisierungsrate von 30 Sekunden zu LOT mit einer Aktualisierungsrate von 60 Sekunden), wird diese Nachricht in ähnlicher Weise gesendet, wenn sein Teilnehmer nicht mit dem NDC-Server verbunden ist. Und wenn einem Verfolger ein Hilfsintervall für einen Notfall zugewiesen worden ist, um zum Beispiel über einen kurzen Zeitraum Daten mit einer hohen Aktualisierungsrate zusätzlich zu seinem Hauptwiederholungsintervall zu berichten, wird durch den NDC-Server die Nachricht an diesen Verfolger gesendet, sein Hilfswiederholungsintervall zu löschen, wenn die Notsituation beendet ist.
Verfolger quittieren den Empfang der „Nachricht zum Löschen zugewiesener Wiederholungsintervalle" durch Setzen des geeigneten Statusbits bei ihrer nächsten periodischen Aktualisierung oder, falls erforderlich, durch Anfordern eines einmaligen Schlitzes, um eine Quittung bereitzustellen. Ein Verfolger, dessen Hauptwiederholungsintervall-Schlitz gelöscht wird, kann diesen Schlitz ein letztes Mal nutzen, um die Quittung in einem Zustands- und Status-Verfolgerpaket bereitzustellen. Wenn der NDC-Server eine Löschquittung empfängt, kann er den Wiederholungsintervall-Schlitz zu diesem Zeitpunkt neu zuweisen oder warten, bis eine Selbstlöschungs-Aktualisierungsanzahl erreicht worden ist, um ihn erneut zuzuweisen.
Wenn eine Textnachricht oder eine vordefinierte Textnachricht an einen Verfolger gesendet wird, kann ein vordefinierter oder ein benutzerdefinierter Antwortsatz identifiziert werden, der die mit den Softkeys (den frei belegbaren Funktionstasten) des mobilen Datenendgerätes verknüpften Textbeschriftungen angibt, wenn die Nachricht angezeigt wird. Wenn ein Softkey in Reaktion auf eine Nachricht gedrückt wird, wird die Softkeynummer in einer „Nachrichtenantwort zu Zustand und Status" oder einer „Nachrichtenantwort zum bereinigten Zustand und Status" an den NDC-Server zurückgegeben. Eine „Nachrichtenantwortquittungs"-Basisnachricht (Tabelle 28) quittiert den erfolgreichen Empfang eines Antwortpaketes durch den NDC-Server. Eine Nachrichtenantwort wird nur dann durch das Verfolgermodul verworfen, wenn es innerhalb von zwei Minuten erfolgreich eine Quittierung empfangen hat; anderenfalls wird die Antwort erneut gesendet.
Eine „Einsatzortsabfertigungs"-Nachricht (Tabelle 29) unterstützt durch Bereitstellen eines Paares von Längen-/Breitenwerten, die den nächsten Einsatzort des Verfolgers definieren, und einer Textbeschreibung des Einsatzortes (der Zieladresse) beim Automatisieren der Fähigkeit des Flottenbetreibers festzustellen, wann ein bestimmter Verfolger an einem Einsatzort angekommen bzw. von einem Einsatzort abgefahren ist. Nach Empfang quittiert das Verfolgermodul die Nachricht unter Verwendung eines Paketes für eine „Nachrichtenantwort zu Zustand und Status" oder eines „Nachrichtenantwort- und Benutzerdaten"-Paketes.
Verfolger senden „Einsatzortsstatus"-Pakete, wenn sie zu einem ihrer bekannten Einsatzorte kommen oder ihn verlassen. Ein „Einsatzortslöschungs"-Nachrichtenpaket (Tabelle 30) von dem NDC fordert einen Verfolger auf, einen seiner bekannten Einsatzorte zu entfernen. Nach Empfangen dieses Paketes stellt der Verfolger keine „Einsatzortsstatus"-Nachricht mehr für den mit der in der „ Einsatzortslöschungs"-Nachricht angegebenen „Einsatzort-ID" verknüpften Einsatzort bereit.
Ein „Benutzerdatenquittungs"-Paket (Tabelle 31) dient zum Quittieren des Empfangs einer zuverlässigen Benutzerdatennachricht von einem Verfolger eines Fahrzeugs durch das NDC. Der Verfolger bewahrt eine Kopie aller zuverlässigen Benutzerdatenpakete, bis er diese Quittierungsnachricht von dem NDC-Server empfängt. Wenn die Quittierung nicht innerhalb von zwei Minuten empfangen wird, sendet der Verfolger das zuverlässige Benutzerdatenpaket erneut.
Es kann eine „NDC-Server-Bootsequenz-ID" durch den Verfolger eingesetzt werden, um festzustellen, ob der NDC-Server eines Navigationsgitters (siehe den obigen Verweis auf das „Gitteridentifizierungs"-Paket und die Erörterung dazu) neu gebootet hat. Wenn ein Verfolgermodul feststellt, dass diese ID sich geändert hat, löscht es alle HF-Zustandsinformationen (einschließlich der RI-Schlitzzuweisungen), die mit einer vorherigen Bootsequenz-ID empfangen worden sind. Empfangene neue HF-Zustandsinformationen werden dann mit der neuen „NDC-Server-Bootsequenz-ID" verknüpft. Die „NDC-Server-Bootsequenz-ID" ermöglicht es Verfolgern im Niedrigenergie-Modus oder Verfolgern, die sich außerhalb des FM-Unterträgerbereichs befunden haben, festzustellen, ob ihr RI-Schlitz und andere Informationen noch gültig sind. Verfolger, die sich über einen längeren Zeitraum in diesem Zustand befunden haben, müssen sicherstellen, dass sich die NDC-Server-Bootanzahl nicht verändert hat, bevor sie eine Verfolgungsaktualisierung bereitstellen. Ein „Gitter-Identifizierungspaket2" (Tabelle 32) stellt die „NDC-Server-Bootsequenz-ID" bereit.
Ein „Einsatzortsstatus-Quittungs"-Paket (Tabelle 33) wird zum Quittieren einer zuverlässigen „Einsatzortsstatus"-Nachricht von einem Verfolger durch den NDC eingesetzt. Der Verfolger bewahrt eine Kopie aller zuverlässigen Einsatzort-Statusnachrichtenpakete, bis er diese Quittierungsnachricht von dem NDC-Server empfängt. Wenn die Quittierung nicht innerhalb von zwei Minuten empfangen wird, sendet der Verfolger das zuverlässige „Einsatzortsstatus"-Paket erneut.
B. Verfolgernachrichten
Verfolgernachrichten werden von den Verfolgern über das TDMA-UHF-Funknetz an das NDC gesendet. Verfolgerdaten bestehen aus Navigations-Zustandsinformationen, Antworten auf netzwerkbezogene Befehle von dem NDC, Funkruf-/Messaging-Antworten und benutzerspezifische Daten. Jeder Verfolger verfügt über einen oder mehrere eindeutigen) Wiederholungsintervall-Schlitz(e) zum Senden seiner Daten. Die Daten werden durch die Netzwerk-Hubs empfangen und an die NDC gesendet, wenn jeder Rahmen vollständig ist. Da ein Verfolgerdatenpaket durch mehr als einen Hub empfangen werden kann, wird das NDC nach einem Aspekt der Erfindung mit einer Fähigkeit zum Ausführen von Diversity-Verarbeitung ausgestattet, um das Wiederherstellen korrumpierter Daten zu unterstützen.
Obwohl Verfolger nach der Erfindung im Allgemeinen über einen zugewiesenen kontinuierlichen Wiederholungsintervall-Zeitschlitz in dem TDMA-Netzwerk verfügen, werden Vorkehrungen getroffen, damit Verfolger mit geringen Anforderungen an die Aktualisierungsrate in einem Abfragemodus arbeiten, in dem das NDC 10 einen solchen in einem Fahrzeug 17 eingebauten Verfolger mit geringem Aktualisierungsbedarf auffordern muss, einen einzelnen Wiederholungsintervall-Zeitschlitz zu senden. Kurz vor der zugewiesenen Sendezeit des Verfolgers muss der Verfolger ein Paket von Daten für die Übertragung zusammenstellen. Auf Basis des übertragenen FM-Bit-Sync, das an dem FM-Empfänger 58 des NTCC-Dachmoduls 55 empfangen wird, und der geschätzten Entfernung zu der Rundfunkantenne 53 (6) muss der entsprechende Verfolger seine Übertragung zu der zugewiesenen Sendezeit innerhalb seines zugewiesenen Wiederholungsintervall-Schlitzes mit einer Genauigkeit von ungefähr einer Mikrosekunde beginnen.
Jeder Netzwerk-Hub 11-1 etc. versucht bei jedem Rahmen, Daten von Trackern in jedem Zeitschlitz zu empfangen. Am Ende des Rahmens werden von den Hubs empfangene Pakete in eine einzelne Nachricht gepackt und über ein Modem an das NDC 10 gesendet. Der NDC-Server 42 führt eine Fehlerkorrektur und eine Diversity-Verarbeitung an den Verfolgerpaketen von allen Hubs aus. Verfolgerzustandsdaten werden protokolliert und/oder über die TCP/IP- oder andere Verbindungsmöglichkeiten an die entsprechende CCS und/oder die entsprechenden NDC-Bedienstationen gesendet. Zusammenfassend sind die Verarbeitungsschritte wie folgt:

1. An dem Rahmen vor seinem zugewiesenen Wiederholungsinterball-Schlitz führt der Verfolger die folgenden Schritte aus: a) Bilden eines zu sendenden Datenpaketes; b) Ausführen von Verschlüsselung der Nachricht; c) Ausführen einer Fehlerüberwachungs-Codierung der Nachricht (bevorzugt unter Verwenddung eines (12,8)-Codes, obwohl ein anderer Code eingesetzt werden kann, falls erwünscht); d) Ausführen von Bitverschachtelung (es ist ein kompliziertes Verschachtelungsmuster erforderlich, um Bitfehler zu reduzieren, wenn die Daten um 1 Bit von der Wahrheit verschoben werden, um die Hub-Basisbandverarbeitung zu ermöglichen. Das Verschachtelungsschema stellt eine Tiefe von 11 Bit zur Verfügung, wodurch die Bündelfehler-Korrekturfähigkeit verbessert wird).
2. Ein hochauflösender Zeitgeber, der mit der ganzzahligen GPS-Sekunde unter Verwendung des FM-Bit-Sync und der Verfolgerposition synchronisiert wird, wird so eingestellt, dass er die Verfolgerübertragung zum geeigneten Zeitpunkt mit einer Genauigkeit von ungefähr einer Mikrosekunde auslöst.
3. Jeder Hub versucht, zum geeigneten Zeitpunkt Daten für jeden Schlitz einzutakten.
4. Am Ende eines Rahmens senden die Hubs alle empfangenen Verfolgerdaten über den Rahmen an das NDC.

Der Verfolgernachrichtentakt und das Format des Verfolgerdatenblocks müssen berücksichtigt werden. Das Verfolger-Übertragungs-TDMA-Netzwerk besteht aus 168 Rahmenzyklen in einer Woche, wobei jeder Rahmenzyklus über 3.600 Rahmen mit einer Länge von einer Sekunde verfügt. Jeder Rahmen wird in verschiedene Verfolger-Sendezeitschlitze unterteilt. Die Anzahl der Schlitze hängt von der Länge der Verfolgernachricht, der Sendebitrate und der erforderlichen Lücke zwischen den Schlitzen zum Ein-/Ausschalten des Senders und der Nachrichtenverzögerungszeit ab. Die Senderate beträgt 7.812,5 bps (15.625 bps Miller-codiert). Die Länge einer Verfolgernachricht beträgt 144 Bit, 8 Miller-Präambelbits (10101010). Die Sendedaten benötigen 18,944 Millisekunden. Es wird daher eine Gesamtschlitzzeit von 20 Millisekunden zugewiesen, um Lichtgeschwindigkeitsverzögerungen und Sender-Betriebs-/Nebenzeit zu ermöglichen; dementsprechend sind 50 Verfolgersendeschlitze für jeden Rahmen verfügbar. Ein Beispiel für einen Verfolgersenderahmen wird in 8 dargestellt, in der Fahrzeug-(Verfolger-)Nachrichtenpakete 76 sequentiell in ihren jeweiligen zugewiesenen Schlitzen (in den Schlitzen der Verfolger) vom Beginn 77 einer ganzzahligen Sekunde an gesendet werden, gefolgt von einem Intervall an Totzeit 78 (falls erforderlich), was ausreichend ist, um den Rest des Rahmens bis zum Beginn 79 der nächsten ganzzahligen Sekunde zu belegen.
Aufgrund von Beschränkungen der Hardware und von CPU-Ladezeiten, die erforderlich sind, um Sendezeitgeber und -taktgeber einzurichten, kann ein Verfolger nicht in zwei angrenzenden Zeitschlitze senden. Die Lücke zwischen den Verfolger-Übertragungsschlitzen muss groß genug sein, um die Verzögerungszeit des Funksignals durch die Luft und die Zeit, die für das Ein- und Ausschalten des Senders erforderlich ist, zu berücksichtigen. Im schlimmsten Fall beträgt die Verzögerungszeit 1,2 ms. Dies ist der Zeitraum, der benötigt wird, um zwei Mal die Länge der Diagonale des Navigationsgitters zurückzulegen. Eine Lückenzeit von dieser Länge verhindert, dass die Übertragung von einem Verfolger, der sich 181 km von dem FM-Sender entfernt befindet und nur das FM-Bit-Sync als Sendetakt einsetzt, sich mit der Übertragung von einem Verfolger überschneidet, der sich in der Nähe des FM-Senders befindet und GPS einsetzt, um den Sendetakt zu unterstützen. Angesichts der Sendeleistung der Verfolger und der Antennenhöhen beträgt eine vertretbare Entfernung, in der ein Hub eine Verfolgerübertragung hören kann, ungefähr 30 km. Daher muss die Lückenzeit ungefähr 211 km oder 0,7 ms unterstützen. Die Funkeinschalt-/-ausschaltzeit muss weniger als 0,1 ms betragen. Infolgedessen muss die Gesamtlückenzeit zwischen den Verfolgerübertragungen zumindest 0,8 ms betragen.
Das normale Verfolgerdatenpaket erfordert 90 Datenbits (einschließlich 24 Benutzerdatenbits). Die anderen Verfolgerdatenpakete erfordern 90 oder 96 Datenbits. Diese Anforderungen an die Größe der Nachrichtenpakete haben direkten Einfluss auf die Fehlerüberwachungs-Codierungsanforderungen für die Pakete. Der vorliegende beispielhafte Typ der Verfolgerpaket-Fehlercodierung verwendet einen (12,8)-Code für alle Verfolgerpakete, die eine Gesamtpaketlänge von 144 Bits mit 96 Datenbits für alle Zeitschlitze bereitstellt.
Die Verfolger setzen das Bit-Sync von einer Sekunde in der FM-Übertragung für ihre Sendeabstimmung ein. Die Übertragungszeit ist bis auf eine Mikrosekunde genau. Bei dem vorliegenden Ansatz schätzt der Verfolger die Zeit der ganzzahligen Sekunde anhand der empfangenen FM-Übertragungs-Bit-Sync-Ereigniszeit. Der Zeitgeberwert einer TPU (d. h. einer Zeitverarbeitungseinheit [time processing unit] des in den Verfolgern, CCSs und Netzwerk-Hubs eingesetzten Mikroprozessors 68332) für jede ganzzahlige Sekunde ist dann bekannt. Daraus kann der TPU-Zeitgeberwert für den Beginn der Sendezeit des Verfolgers berechnet werden. Die TPU wird programmiert, um dem Sendeschlüssel zu bestätigen, den Ausgabedatentakt exakt zu Beginn der Sendeschlitzzeit zu starten, und um die Bestätigung für den Schlüssel zurückzunehmen, damit der Datentakt gestoppt wird, wenn die Nachricht vollendet ist.
Für die Datentaktung an dem Netzwerk-Hub (z. B. 11-1, der in der nachfolgenden Beschreibung von 31 genauer beschrieben wird, wobei aber für die vorliegenden Zwecke nun kurz Bezug auf Letztere genommen wird) wird ein digitaler Signalprozessor (ein DSP-Mikroprozessor) 80 an dem Hub eingesetzt, um die von den Fahrzeugverfolgern empfangenen Nachrichtendaten durch den UHF-Empfänger 81 des Hubs zu demodulieren und sie für die Hub-CPU 82 bereitzustellen. Die CPU 82 stellt die TPU-Zeit (des Mikroprozessors 83 Motorola 68332) für die ganzzahlige Sekunde auf Basis des an dem FM-Empfänger 85 empfangenen FM-Übertragungs-Bit-Sync fest. Die beiden Empfänger 81 und 85 und der DSP 80 befinden sich auf einer HF-Karte 86 des Hubs. Die CPU 82 signalisiert dem DSP 80, mit dem Abfragen der UHF-Daten zu Beginn jeder Sendeschlitzzeit zu beginnen. Der DSP sammelt dann Daten, stellt den Bittakt wieder her und fragt die Bits ab. Er führt eine Miller-Decodierung, eine Entschachtelung und eine (12,8)-Fehlererkennung für bis zu 13 verschiedene Bitverzögerungen aus, um die unbekannte Lichtgeschwindigkeitsverzögerung von dem Verfolger zu dem Hub zu unterstützen. Die Bitverzögerung mit der niedrigsten Anzahl an Codewörtern mit Fehlern wird ausgewählt, und diese Daten werden an die CPU 82 für die Übertragung über ein Modem 87 oder eine andere Verbindungsmöglichkeit durch den Netz-Hub an den NDC-Server 42 (3) in dem NDC 10 getaktet. Der DSP 80 muss alle seine Verarbeitungsschritte in dem Fenster von 20 Millisekunden vollenden, das für jede Verfolgerübertragung zur Verfügung steht.
Wie zuvor hier erläutert, ist jeder Rahmen von einer Sekunde in Verfolgerpaket-Sendeschlitze von festgelegter Länge unterteilt. Da die Anzahl der Schlitze innerhalb eines Rahmens ebenfalls festgelegt ist, müssen die Verfolger in dem System der Erfindung diese Sendeschlitze gemeinsam nutzen. Die meisten Verfolger senden regelmäßig Informationen über ihren Zustand, ihre Position und/oder Benutzerdaten. Dementsprechend wird ein periodisches Schlitzzuweisungs-Schema ausgewählt, durch dessen Einsatz einzelne Schlitze innerhalb eines Rahmens über ein Zeitintervall gemeinsam genutzt werden.
Bei diesem periodischen Schlitzzuweisungs-Schema werden einzelne Schlitze mit Wiederholungsintervallen verknüpft. Dies ermöglicht Verfolgern mit einer gemeinsamen periodischen Aktualisierungsrate, einen bestimmten Schlitz während eines Zeitintervalls (entsprechend der gemeinsamen periodischen Aktualisierungsrate), das verschiedene Rahmen enthält und ein Divisor von 3.600 ist, gemeinsam zu nutzen. 9 stellt ein Wiederholungsintervall für verschiedene einzelne Sendeschlitze für Verfolgernachrichtenpakete dar und zeigt die Beziehung des Wiederholungsintervalls zu Schlitzen, Rahmen und Rahmenzyklen. Der Rahmenzyklus 90 besteht, wie oben erwähnt, aus einer Vielzahl von Rahmen (z. B. 90-1, ..., 90-i, ..., 90-n). Jeder Rahmen enthält eine Vielzahl von Schlitzen 91, die dem Schema entsprechend Verfolgernachrichtenübertragungen zugewiesen sind. Der Intervallindex für das Wiederholungsintervall 92, das mit Schlitz 0 verknüpft ist, unterscheidet sich von dem Intervallindex für das Wiederholungsintervall 93 für Schlitz 1 und so weiter für die Schlitze 2, ..., n-2, n-1, n. Der dargestellte Intervallindex kann unter Verwendung der folgenden Gleichung berechnet werden: Wiederholungsintervallindex = (Rahmen-ID) mod (Intervalllänge)
Den Verfolgern wird ein Hauptwiederholungsintervall und/oder mehrere Hilfswiederholungsintervalle zum Senden ihrer Verfolgungsdaten zugewiesen. Verfolgungsdaten werden durch die Verfolger während ihres Hauptwiederholungsintervalls gesendet, bis sie durch den NDC-Server aufgefordert werden, das Senden einzustellen, oder bis sich der Zustand des Verfolgers ändert (z. B. in den Niedrigenergie-Modus umschaltet). Hauptintervalle werden nur Verfolgern mit kontinuierlichem oder LOT-Verfolgungsdienst zugewiesen. Verfolger senden ihre Verfolgungsdaten während Hilfsintervallen eine festgelegte Anzahl von Malen, sofern ihr Zustand sich nicht ändert oder der NDC-Server ihnen keine andere Aufforderung zukommen lässt. Es können Verfolgern aller Diensttypen ein oder mehrere Hilfswiederholungsintervalle zugewiesen werden.
Wie in 9 gezeigt, wird jedes Wiederholungsintervall durch einen Schlitz, einen Wiederholungsintervallindex und eine Intervalllänge definiert. Darüber hinaus verfügen Hilfswiederholungsintervalle über eine Intervallanzahl. Da ein Verfolger die Rahmen-ID unter Verwendung der GPS-Sekunde berechnen kann, kann der Wiederholungsintervallindex ebenfalls unter Verwendung der Wiederholungsintervalllänge und der Rahmen-ID berechnet werden. Die Verfolger senden ihre Verfolgungsinformationen in ihren zugewiesenen Schlitzen während des Rahmens, wenn die (Rahmen-ID) mod (Intervalllänge) ihrem zugewiesenen Intervallindex gleichkommt. Hilfswiederholungsintervall-Aktualisierungen werden durch die Verfolger so viele Male bereitgestellt, wie Intervalle vorhanden sind. Verfolger, denen ein Hilfswiederholungsintervall mit einer Intervallanzahl von –1 zugewiesen wird, stellen während ihres zugewiesenen Wiederholungsintervalls Verfolgungsaktualisierungen unendlich bereit.
Wie oben bemerkt, können sehr lange Aktualisierungsintervalle – z. B. länger als 3.600 Sekunden – durch einen Sendeaufruf verarbeitet werden. Verfolgern, die so lange Aktualisierungsintervalle benötigen, wird kein kontinuierliches Wiederholungsintervall zugewiesen, sondern sie senden nur auf Anweisung durch den NDC-Server. Wiederholungsintervallraten für Verfolgeraktualisierungen werden in Tabelle 34 (Anhang B) zusammengefasst.
Da Schlitze innerhalb eines Rahmens dynamisch mit einem Wiederholungsintervall verknüpft werden, so dass Verfolger mit einer gemeinsamen Verfolgungsaktualisierungsrate einen Schlitz während eines Zeitintervalls gemeinsam nutzen, setzt der NDC-Server einen Satz von Algorithmen für die Zuweisung von Wiederholungsintervall-Schlitzen wie folgt ein, um Schlitze dynamisch mit Wiederholungsintervallen zu verknüpfen.
Initialisierung:
Alle Schlitze zu Netzwerkeintrittsschlitzen machen.
Einen Verfolger zu einem gewünschten Wiederholungsintervall für eine gewünschte Intervallanzahl hinzufügen:

1) Einen Verfolger zu dem am besten verfügbaren Wiederholungsintervall hinzufügen: • Nach einem Schlitz suchen, der mit dem gewünschten Wiederholungsintervall mit dem geringsten verfügbaren Platz verknüpft ist, • wenn ein verfügbares Wiederholungsintervall gefunden wird, den Verfolger zu dem Wiederholungsintervall für die gewünschte Intervallanzahl hinzufügen und den Intervallstatus auf „zugewiesen" setzen, • wenn der Verfolger nicht zu einem Wiederholungsintervall hinzugefügt wurde, zu Schritt 2 übergehen, • anderenfalls Anforderung gestatten.
2) Gewünschtes Wiederholungsintervall mit einem verfügbaren Netzwerkeintrittsschlitz verknüpfen. • Nach einem verfügbaren Netzwerkeintrittsschlitz suchen, • wenn ein verfügbarer Netzwerkeintrittsschlitz gefunden wird, den Schlitz mit dem gewünschten Wiederholungsintervall verknüpfen, • anderenfalls, wenn das Wiederholungsintervall ≠ der Rahmenzykluslänge ist, das gewünschte Wiederholungsintervall in das nächste verfügbare Wiederholungsintervall ändern. Zu Schritt 1 übergehen.
3) Einen Verfolger zu dem mit einem Schlitz in Schritt 2 verknüpften Intervall hinzufügen. • Einen Verfolger zu dem Intervall für die gewünschte Intervallanzahl hinzufügen, • Anforderung gestatten.

Die Tracker-ID für ein empfangenes Paket suchen (und die Intervallanzahl dekrementieren, falls erforderlich):

1) Die Schlitznummer verwenden, um festzustellen, ob der Schlitz mit einem Wiederholungsintervall verknüpft ist.
2) Wenn der Schlitz mit einem Wiederholungsintervall verknüpft ist, die Verfolger-ID unter Verwendung des Intervallindex feststellen, die Anzahl ausgelassener Aktualisierungen, falls erforderlich, zurücksetzen, die Intervallanzahl dekrementieren, den Intervallstatus auf „aktiv" setzen und den Schlitz freigeben, falls erforderlich. • Intervallindex berechnen: (Paketrahmen-ID) mod (Intervalllänge) • Den Intervallindex zum Feststellen der Verfolger-ID einsetzen. • Die Anzahl ausgelassener Aktualisierungen auf 0 setzen. • Wenn die Intervallanzahl ≠ –1 ist, die Intervallanzahl dekrementieren. • Wenn die Intervallanzahl = 0 ist, den Verfolger aus dem Wiederholungsintervall entfernen. Wenn keine weiteren Verfolger mit dem Wiederholungsintervall dieses Schlitzes verknüpft sind, diesen Schlitz in einen Netzwerkeintrittsschlitz umwandeln.
3) Anderenfalls ist der Schlitz ein Netzwerkeintrittsschlitz. Die Verfolger-ID sollte in dem Verfolgerpaket enthalten sein.

Einen leeren Schlitz verarbeiten:

1) Die Schlitznummer von ausgelassenen Paketaktualisierungen zum Feststellen des Schlitztyps einsetzen.
2) Wenn der Schlitz mit einem Wiederholungsintervall verknüpft ist, die Anzahl der ausgelassenen Aktualisierungen des Verfolgers erhöhen.
3) Wenn der Intervallstatus = „zugewiesen" oder der Intervallstatus = „aktiv" ist, den Verfolger zum Senden aufrufen.
4) Wenn der Intervallstatus = „zugewiesen" ist, Wiederholungsintervall-Schlitzzuweisung erneut übertragen.

Den Verfolger aus dem Wiederholungsintervall entfernen:

1) Einen mit dem Wiederholungsintervall des Verfolgers verknüpften Schlitz suchen.
2) Den Verfolger aus dem Wiederholungsintervall entfernen. • Intervallstatus = leer setzen. • Ein Basispaket an den Verfolger senden, um das zugewiesene Wiederholungsintervall zu löschen.
3) Wenn keine weiteren Verfolger mit dem Wiederholungsintervall dieses Schlitzes verknüpft sind, den Schlitz in einen Netzwerkeintrittsschlitz umwandeln.

Der NDC-Server 42 behält Informationen bezüglich der Beziehung zwischen den Verfolgern, Schlitzen und Wiederholungsintervallen als eine Form von Speicherung der Wiederholungsintervall-Schlitzzuweisung im Speicher. 10 stellt ein Schaubild dar, das die Entitätsbeziehung des Wiederholungsintervall-Schlitzes mit den folgenden Diagrammnotationen erläutert:
Feld = Objekt
Feld mit Doppelstrich = schwache Entität
Raute = Beziehung
Raute mit Doppelstrich = schwache
Oval = Attribut
Unterstrichen = Schlüssel
Gestrichelt unterstrichen = Teilschlüssel
Gestricheltes Oval = abgeleitetes Attribut
Beziehung

(x, y) = (Minimum, Maximum)

Darüber hinaus sind die nicht erfassten Einschränkungen wie folgt:
1 <= Intervalllänge <= Rahmenzykluslänge
Die Intervalllänge ist ein Divisor der Rahmenzykluslänge
Intervallindex = (Rahmen-ID) mod (Intervalllänge)
Wenn die Intervallanzahl = –1 ist, stellen die Verfolger unendlich Aktualisierungen bereit.
Intervallstatus = {leer, zugewiesen, aktiv, inaktiv}
Intervalltyp = {Haupt-, Hilfs-, kein}
Dementsprechend gibt zum Beispiel die Beziehung „Fordert Netzwerkeintritt an zu" (Raute 100) in 10 an, dass Verfolger den Netzwerkeintritt in Schlitzen (Feld 101 mit Doppelstrich) anfordern können, die keinem Wiederholungsintervall (Feld 102 mit Doppelstrich) zugewiesen sind. Folglich müssen die Verfolger über gültige Netzwerkeintrittsschlitze informiert werden, bevor sie versuchen, den Netzwerkeintritt anzufordern. Und die Beziehung „Stellt Aktualisierungen bereit in" (Raute 103) gibt an, dass die Verfolger Verfolgungsaktualisierungen in Wiederholungsintervallen (Feld 102 mit Doppelstrich) bereitstellen. Darüber hinaus sind Attribute, wie zum Beispiel Intervalltyp (Oval 104), Intervallanzahl (Oval 105), Intervallstatus (Oval 106) und Anzahl ausgelassener Aktualisierungen (Oval 107) mit dieser Beziehung verknüpft. Die Intervallanzahl gibt die Anzahl von Wiederholungsintervallen an, in denen ein Verfolger seine Verfolgungsinformationen senden sollte. Die Anzahl ausgelassener Aktualisierungen gibt die Anzahl von aufeinander folgenden Malen an, in denen der Verfolger das Bereitstellen seiner Verfolgungsaktualisierung während seines zugewiesenen Wiederholungsintervalls ausgelassen hat. Bei dem Intervallstatus handelt es sich um einen Aufzählungstyp, der angibt, ob ein Intervall leer, zugewiesen, aktiv oder inaktiv ist. Bei dem Intervalltyp handelt es sich um einen Aufzählungstyp, der angibt, ob ein Wiederholungsintervall mit einem Status „nicht leer" ein Haupt- oder ein Hilfsintervall ist oder ob kein Intervall zugewiesen ist.
Das Verfolgernachrichten-Blockformat der durch die Verfolger gesendeten Daten besteht aus einem fehlercodierten und bitverschachtelten Datenblock. Da der UHF-Sender/-Empfänger erfordert, dass die Daten häufige Zustandsänderungen enthalten, so dass der Phasenregelkreis (phase-locked-loop – PLL) die Daten nicht verfolgt, werden die Sendedaten Miller-codiert, um einen solchen Gehalt an Zustandsänderungen sicherzustellen.
Die grundlegenden Anforderungen bezüglich der Datengröße an durch die Verfolger gesendete Informationen und der minimale Platzbedarf für den Verfolgerzustand, den Netzwerkstatus und die Netzwerkbefehlsantworten sind wie folgt definiert. Der Verfolgerzustand besteht aus der Position, der Geschwindigkeit und der Richtung. Wie zuvor angegeben, beträgt die Seitenlänge des Navigationsgitters des PROTRAK-Systems für die derzeit bevorzugte Ausführungsform ungefähr 262 km. Das Gitter ist in 1.024 Gitterfelder von 8,192 km mal 8,192 km gegliedert. Die von dem Verfolger zur Verfügung gestellte Position besteht aus einem Gitterfeld und einem Offset in das Feld von der südwestlichen Ecke aus. Das nominale Navigationsgitter ist quadratisch, es können aber andere Formen, wie zum Beispiel unregelmäßig geformte Gitter eingesetzt werden, falls es gewünscht wird oder sie bei einer bestimmten System-/Netzwerkkonfiguration besser geeignet sind. Die unregelmäßige Formgebung kann durch Anordnen der Felder in spezifische Muster erreicht werden.
11 ist ein Schaubild eines nominalen Navigationsgitters für eine Breite von 45 Grad im Mittelpunkt. Es ist zu beachten, dass in der Praxis (aber nicht in der idealisierten Abbildung dargestellt) die Erdkrümmung dazu führt, dass das Gitter im Norden größer in der Breite als im Süden ist. Die Meridiane, die das Gitter umgrenzen, liegen am Nordende des Gitters ungefähr 3 km näher zusammen als am Südende.
Für ein gegebenes Gitter werden die Breite und die Länge des Gittermittelpunktes (Φ₀, λ₀) den Verfolgern durch das NDC in dem Gitter-Identifizierungspaket zur Verfügung gestellt. Der Verfolger berechnet seine Breite und Länge, (Φ, λ), und berechnet dann das Offset von dem Gittermittelpunkt: ΔΦ = Φ – Φ₀ und Φλ = λ – λ₀. Die nördlichen und östlichen Deltapositionen von dem Gittermittelpunkt aus sind: ΔN = v0Δλcos(Φ) ΔE = ρ0ΔΦwobei ρ₀ und v₀ die Erdradien der Krümmung sind: v0 = α/sqrt(1 – e2sin2(Φ)) ρ0 = v0(1 – e2)/(1 – e2sin2(Φ))wobei α die große Halbachse der Erde und e die Erdexzentrizität sind.
Die untere linke Ecke des Quadrates von 8,192 km, das die Position enthält, ist zum Beispiel: ΔN8K = floor(ΔN/8192) ΔE8K = floor(ΔE/8192)
Das Offset in das Quadrat hinein ist: ΔNoff = ΔN – 8192(ΔN8K) ΔEoff = ΔE – 8192(ΔE8K)
Für das nominale quadratische Navigationsgitter wird die Koordinate des Feldes von 8 Km berechnet als Z = (16 + ΔE8K) + 32(15 – ΔN8K)
Das NDC berechnet die ursprüngliche Breite und Länge durch Addieren der nördlichen und östlichen Offsets zu den nördlichen und östlichen Koordinaten der südwestlichen Ecke des durch den Verfolger angegebenen Feldes unter Verwendung der folgenden Gleichungen: ΔN8K = 15 – (Z/32) ΔE8K = (Zmod(32)) – 16 ΔN = 8192(ΔN8K) + ΔNoff ΔE = 8192(ΔE8K) + ΔEoff
Dann berechnet es die Breite als: Φ = Φ0 + ΔN/ρ0
Daraufhin kann die Länge berechnet werden als: λ = λ0 + ΔE/(v0cos(Φ))
Die vollständige Breite und Länge werden der entsprechenden CCS über Nachrichtendaten von dem Verfolger an den/die Netzwerk-Hub(s) zur Verfügung gestellt, die an das NDC und dann an den Kundenstandort weitergeleitet werden.
Die Datenmenge, die zum Beschreiben des Verfolgerzustands erforderlich ist, beträgt 48 Bits. Die Feld-ID-Nummer erfordert 10 Bits. Die nördlichen und östlichen Offsets innerhalb des Feldes erfordern jeweils 11 Bits für eine Auflösung von 4 Metern. Die Geschwindigkeit erfordert 7 Bits für eine Auflösung von 0,5 m/s (ungefähr 1,1 mph) und einen Maximalwert von ungefähr 230 km/h (143 mph). Der Kurs erfordert 7 Bits für eine Auflösung von 0,015625 Halbkreisen (ungefähr 2,8 Grad). Es werden zwei Zustandsdaten-Gültigkeitsbits definiert. Zwei weitere Zusatzbits können bereitgestellt werden, damit die Zustandsdaten einfach in einen „Zustandsdatenblock" von 48 Bits (dessen Byte-/Bit-Definitionen in Tabelle 35 zusammengefasst werden) passen.
Ein „Bereinigter Zustandsdatenblock" (Byte-/Bit-Definitionen sind in Tabelle 36 zusammengefasst) ist erforderlich, damit die Verfolger ihre vollständige Verfolger-ID-Nummer bereitstellen, auf Benutzernachrichten und/oder NDC-Befehle antworten und Benutzerdaten bereitstellen können. Dieser Datenblock enthält nur eine Position mit geringer Auflösung (8 Meter) und erfordert 34 Bits.
Ein „Netzwerkstatuscode" (Definitionen in Tabelle 37) wird von den Verfolgern eingesetzt, um in das HF-Netzwerk einzutreten oder es zu verlassen. Weitere Codes können zum Automatisieren der Verfolgung von Dienständerungen bereitgestellt werden. Bei der vorliegenden beispielhaften Ausführungsform sind neun Netzwerkstatuscodes von einer verfügbaren Gesamtzahl von 32 definiert worden.
Die meisten Datenpakete stellen Platz dafür bereit, dass benutzerdefinierte Daten für die CCSs zur Verfügung gestellt werden. Das NDC leitet einfach die Daten an den Kunden weiter, wobei der Inhalt der Daten auf die Anforderungen der jeweiligen Kunden ausgerichtet ist. Die Benutzerdaten bestehen aus mindestens 1 Byte und können so lang wie ein vollständiges Verfolgersendepaket sein. Dies alles wird durch den Benutzer definiert, und die Benutzerdaten werden hier als der „Benutzerdatenblock" bezeichnet.
Textnachrichten, vordefinierte Nachrichten, Benutzerdaten und Einsatzortsabfertigungs-Nachrichten werden durch die Verfolger quittiert, um ihren Empfang anzuzeigen. Darüber hinaus können Textnachrichten, vordefinierte Nachrichten und Einsatzortsabfertigungs-Nachrichten zwei Antworten erfordern, wobei es sich bei der einen um eine Bestätigung handelt, die anzeigt, wann die Nachricht gelesen wurde, und die andere die Softkeyantwort des Empfängers anzeigt. Quittierungen/Antworten werden in einem „Nachrichtenquittierungs-/Antwort"-Block (Tabelle 38) an den NDC-Server gesendet.
Es wird eine Paket-ID-Nummer eingesetzt, um jedes Paket zu identifizieren. Die Paket-ID erfordert 4 Bits für eine Gesamtzahl von 16 verschiedenen Pakettypen. Die ersten 4 Bits jedes Paketes sind für den ID-Block reserviert.
Die Verfolgerdatenpaketformate umfassen die folgenden Formate: Der Verfolgersendedatenblock besteht aus einem einzelnen Datenpaket, das für einen (12,8)-fehlercodierten Block 96 Bits lang ist. Zu Anfang müssen alle Verfolger ein „Netzeintrittsanforderungs"-Paket senden, um in das HF-Netzwerk einzutreten. Letzteres Paket ermöglicht den Verfolgern, ihren Hauptwiederholungsintervall-Schlitz oder ein einzelnes Hilfswiederholungsintervall anzufordern.
Sobald sie in das HF-Netzwerk eingetreten sind, können die Verfolger abhängig von dem Verfolgerzustand eine Vielzahl unterschiedlicher Pakettypen senden. Das von periodischen Verfolgern eingesetzte normale Paket ist ein Zustands- und Statuspaket.
Ein kurzes Zustands- und Statuspaket wird ebenfalls von den Verfolgern eingesetzt, wenn der NDC-Server die Verfolger auffordert, ihre Verfolger-ID-Nummer bereitzustellen. Verfolger, die eine große Menge an Benutzerdaten senden müssen, können das „Benutzerdatenpaket" und/oder das „Kurze Benutzerdatenpaket" während ihres Wiederholungsintervalls einsetzen. Wenn Verfolger ihre Verfolger-ID-Nummer, Positionsinformationen und Benutzerdaten senden müssen, kann ein Paket für „bereinigte Zustandsbenutzerdaten und Statusdaten" eingesetzt werden. Verfolger, die Benutzerdaten quittieren oder Text- bzw. vordefinierte Nachrichten quittieren/beantworten müssen, können die „Nachrichtenantwort-" und „Benutzerdaten"-Pakete einsetzen.
Verfolgerpakettypen werden durch eine Paket-ID identifiziert, wobei Platz für 16 verschiedene Pakettypen bereitgestellt wird (zusammengefasst in Tabelle 39). Unbelegte oder Zusatzdatenbits und -bytes in den Paketen werden auf null gesetzt. Die Pakete bestehen aus bitkomprimierten Datenblöcken, die alle hier zuvor definiert worden sind.
Ein „Netzeintrittsanforderungs"-Paket (die Bitdefinitionen werden in Tabelle 40 dargestellt) wird durch die Verfolgermodule eingesetzt, um in das HF-Netzwerk einzutreten. Die Verfolger können ihren Hauptwiederholungsintervall-Schlitz oder einen einmaligen Hilfswiederholungsintervall-Schlitz anfordern. Bevor einem Verfolger gestattet wird, eine solche Anforderung zu senden, muss er ein Basispaket der „Verfügbaren Netzwerkeintrittsschlitze" empfangen und weiterhin erfolgreich die FM-Basisübertragung empfangen, bis er ein „Netzwerkeintrittsanforderungs"-Paket sendet. Die Verfolger erzeugen eine willkürliche Nummer, um aus den verfügbaren Netzwerkeintrittsschlitzen den nächsten Rahmen auszuwählen, um die Anforderung zu senden, und sie erzeugen eine zweite willkürliche Nummer, um einen verfügbaren Schlitz auszuwählen. Die Verfolger können ihre Verfolger-ID für das Erzeugen jeder willkürlichen Nummer einsetzen. Wenn ein Verfolger nicht innerhalb von 60 Sekunden nach dem Senden einer Netzwerkeintrittsanforderung eine Zuweisung eines Wiederholungsintervall-Schlitzes (Wiederholungsintervall – repeating interval – RI) empfängt, sendet er die Anforderung erneut.
Da es möglich ist, dass mehrere Verfolger innerhalb desselben Schlitzes kommunizieren, zeigt das „Netzeintrittsanforderungs"-Paket den RI-Schlitztyp und die Verfolger-ID mehrmals an, um dem NDC-Server zu ermöglichen festzustellen, ob das Paket gültig ist. Verfolger müssen ihren Haupt-RI-Schlitz vor dem Senden eines „Netzeintrittsanforderungs"-Paketes löschen. Ein Verfolger, der sich im „Niedrigenergie"-Modus befunden hat, löscht zum Beispiel seinen Niedrigenergie-Schlitz vor dem Senden der Netzeintrittsanforderung. Diese Regel ermöglicht es dem NDC-Server, neu zugewiesene RI-Schlitze freizugeben, die mit einem Verfolger verknüpft sind, der einen Netzeintritt anfordert.
Ein „Zustands- und Statuspaket" ist das normale von periodischen Verfolgern gesendete Paket. Dieses Paket enthält Informationen zur voll aufgelösten Verfolgerposition, der Geschwindigkeit und dem Netzwerkstatus sowie fünf Benutzerdatenbytes. Die „Zustands- und Status"-Paketbitdefinitionen werden in Tabelle 41 dargestellt.
Ein Paket für „Zuverlässige Benutzerdaten" (Bitdefinitionen in Tabelle 42) stellt mehrere Bytes an Benutzerdaten bereit. Statt während seines zugewiesenen Wiederholungsintervalls Positionsinformationen bereitzustellen, kann ein Verfolger dieses Benutzerdatenpaket verwenden, um zehn Benutzerdatenbytes gleichzeitig zu senden. Falls erforderlich, kann ein einmaliger Wiederholungsintervall-Schlitz angefordert werden, um dieses Paket zu senden bzw. erneut zu senden.
Nach dem Empfang eines Paketes für „Zuverlässige Benutzerdaten" überträgt der NDC-Server eine „Nachrichtenantwortquittungs"-Nachricht mit derselben ID der Benutzerdatenfolge. Die Verfolger müssen eine Kopie jedes „Zuverlässigen Benutzerdatenpaketes" bewahren, bis der NDC-Server es erfolgreich quittiert. Wenn eine Quittierung nicht innerhalb von 2 Minuten empfangen wird, sendet der Verfolger das Benutzerdatenpaket erneut.
Ein „Kurzes Zustands- und Statuspaket" (die Bitdefinitionen werden in Tabelle 43 dargestellt) wird durch die Verfolger während ihres normalen Übertragungsschlitzes übertragen, wenn der NDC-Server die Verfolger auffordert, ihren Status zu senden. Es enthält die voll aufgelöste Verfolgerposition, die Geschwindigkeit, ein Benutzerdatenbyte und Netzwerkstatus-Informationen.
Ein Paket für „Zuverlässige kurze Benutzerdaten" (Tabelle 44 stellt seine Bitdefinitionen dar) wird gesendet, um mehrere Bytes an Benutzerdaten bereitzustellen. Statt während seines zugewiesenen Wiederholungsintervalls Positionsinformationen bereitzustellen, kann ein Verfolger dieses Benutzerdatenpaket verwenden, um sechs Benutzerdatenbytes gleichzeitig zu senden. Nach dem Empfang eines Paketes für „Zuverlässige Benutzerdaten" überträgt der NDC-Server eine „Nachrichtenantwortquittungs"-Nachricht mit derselben ID der Benutzerdatenfolge. Die Verfolger müssen eine Kopie jedes Paketes für „Zuverlässige Benutzerdaten" bewahren, bis der NDC-Server es erfolgreich quittiert. Wenn eine Quittierung nicht innerhalb von 2 Minuten empfangen wird, sendet der Verfolger das Paket erneut.
Ein Paket für „Bereinigte Zustandsbenutzerdaten und bereinigten Status" (die Bitdefinitionen werden in Tabelle 45 dargestellt) wird durch die Verfolger eingesetzt, um einen bereinigten Zustand und Status mit Benutzerdaten bereitzustellen. Das Paket enthält den Netzwerkstatus, die vollständige Verfolger-ID-Nummer, bereinigte Zustandsdaten und Benutzerdaten.
Ein „Nachrichtenantwort- und Benutzerdaten"-Paket (die Bitdefinitionen werden in Tabelle 46 dargestellt) wird während des normalen Übertragungsschlitzes eines Verfolgers übertragen. Dieses Paket stellt sowohl Quittierungs-/Antwort- als auch Benutzerdaten bereit. Falls erforderlich, können die Verfolgermodule entscheiden, einen einzelnen Schlitz anzufordern, um diese Antwort für den NDC-Server schnell bereitzustellen, statt auf ihren normalen Übertragungsschlitz zu warten, um das Paket zu senden. Einzelne Schlitze können einem Verfolger unter Verwendung eines „Netzeintrittsanforderungs"-Paketes zugewiesen werden.
Ein Paket für „Kurze Nachrichtenantwort- und Benutzerdaten" (Tabelle 47) wird während des normalen Übertragungsschlitzes eines Verfolgers übertragen, wenn der NDC-Server die Verfolger zum Senden ihrer Verfolger-ID auffordert. Dieses Paket enthält die vollständige Verfolger-ID von 30 Bits, eine Quittierung/Antwort und Benutzerdaten. Wie bei dem oben erörterten normalen „Nachrichtenantwort- und Benutzerdaten"-Paket können die Verfolger, falls erforderlich, entscheiden, einen einzelnen Schlitz anzufordern, um diese Antwort für den NDC-Server schneller bereitzustellen statt unter Verwendung ihres normalen Übertragungsschlitzes. Einzelne Schlitze können einem Verfolger unter Verwendung eines „Netzeintrittsanforderungs"-Paketes zugewiesen werden.
Eine „Einsatzortsabfertigungs"-Nachricht von dem Abfertigungsbüro des Kunden (durch eine CCS) zeigt dem Verfolger das Gebiet des Einsatzortes an. Infolgedessen ist der Verfolger in der Lage festzustellen, wann der Verfolger am Einsatzort angekommen ist oder ihn verlassen hat. Ein „Einsatzortsstatus"-Paket (Tabelle 48) wird durch einen Verfolger eingesetzt, um die Ankunft/Abfahrt am bzw. vom Einsatzort anzuzeigen. Dieses Paket gibt die Verfolger-ID, die Nachrichtenfolge-ID (ursprünglich mit der Einsatzortsabfertigungs-Nachricht verknüpft), den Ankunfts-/Abfahrts-Status, die Ankunfts-/Abfahrtszeit, die Quelle des Ankunfts-/Abfahrts-Status und Benutzerdaten an.
Geocodierung mit Kartierungsdaten ist möglicherweise nicht immer genau. Daher ist es unter Verwendung der erwarteten Breite/Länge als Adresse nicht immer möglich festzustellen, ob ein Verfolger den Einsatzort erreicht hat. Der Verfolger sendet ein „Einsatzortsstatus"-Paket auf Basis von Breite/Länge, wenn eine Ankunft/Abfahrt stattfindet (unter Verwendung der Breiten-/Längenwerte in der „Einsatzortsabfertigungs"-Nachricht), um dem Benutzer zu ermöglichen, die Ankunft/Abfahrt manuelle anzuzeigen. Das Einsatzorts-Quellenbit in diesem Paket zeigt an, wie die Ankunft/Abfahrt festgestellt wurde. Zunächst kann das „Einsatzortsstatus"-Paket unter Verwendung der beiden Statusquellen zwei Mal für die Ankunft und zwei Mal für die Abfahrt gesendet werden. Falls erforderlich können die Verfolger hier auch entscheiden, einen einzelnen Schlitz anzufordern, um diese Antwort für den NDC-Server schneller bereitzustellen, als es unter Verwendung ihres normalen Übertragungsschlitzes geschehen würde. Einzelne Schlitze können einem Verfolger unter Verwendung eines „Netzeintrittsanforderungs"-Paketes zugewiesen werden.
Ein „Selbsttest"-Verfolgerpaket (Selbsttest – Built-in Test – BIT) wird gesendet, um dem NDC Informationen über die Verfolger zur Verfügung zu stellen, um einen Systemtest zu unterstützen und festzustellen, ob die Verfolger ordnungsgemäß arbeiten. Die Verfolger stellen mit einer in dem „RI-Schlitz-Konfigurations"-Basispaket festgelegten Rate eines der gültigen „BIT"-Pakete in einem von jedem Verfolger angeforderten Hilfsschlitz bereit. Jeder „BIT"-Pakettyp sollte nacheinander gesendet werden. Falls erforderlich kann der Turnus der „BIT"-Pakettypen geändert werden, um dringende Selbsttest-Informationen zur Verfügung zu stellen. Die Bitdefinitionen für das „BIT"-Paket werden in Tabelle 49 dargestellt, und die verschiedenen Typen von „BIT"-Paket-Datenblöcken werden in den Tabellen 50 (Netzwerk und HF-System, Typ = 0), 51 (Fahrzeug und Umgebung, Typ = 1), 52 (Navigation, Typ = 2), 53 (Version, Typ = 3) und 54 (Transportbeton, Typ = 4) dargestellt. Alle in einem „BIT"-Paket-Datenblock zur Verfügung gestellten Werte geben die Werte an, die aufgezeichnet wurden, seit das letzte „BIT"-Paket desselben Pakettyps für den NDC-Server zur Verfügung gestellt worden war.
Wenn ein Verfolger eine vordefinierte Nachricht erhält, wie hier zuvor erörtert, zeigt er die bekannte Nachricht an, die mit der festgelegten vordefinierten Nachrichten-ID/CRC von 16 Bits verknüpft ist. Wenn dem Verfolger jedoch die mit dieser ID verknüpfte Nachricht nicht bekannt ist, oder wenn er feststellt, das die CRC der bekannten Nachricht nicht mit der CRC in dem empfangenen Paket übereinstimmt, kann er die Nachrichtendefinition durch Senden eines Pakets zur „Anforderung der Definition einer vordefinierten Nachricht" anfordern. Um einen effizienteren Einsatz der Bandbreite zu erreichen, kann dieses Paket durch den Verfolger in einem Netzwerkeintrittsschlitz gesendet werden.
Wenn der NDC-Server dieses Anforderungspaket empfängt, überträgt er ein Paket für die „Definition einer vordefinierten Nachricht" (Tabelle 55), das dem Verfolger ein vordefiniertes Nachrichten-ID/Nachrichten-Paar zur Verfügung stellt. Da vordefinierte Nachrichten auf einer Kunde-für-Kunde-Basis definiert werden, profitieren alle mit demselben Kunden verknüpften Verfolger von diesem Nachrichtendefinitionspaket. Folglich müssen die Verfolger das Nachrichtendefinitionspaket nicht immer von dem NDC-Server anfordern, selbst wenn sie zum ersten Mal eine vordefinierte Nachrichten-ID empfangen.
V. Netzwerktakt nach dem Zeitmultiplexverfahren (Time Division Multiple Access – TDMA)
Wie hier oben stehend erörtert worden ist, besteht ein Merkmal des TDMA-Netzwerks darin, dass es durch Zuweisen bestimmter Zeitschlitze zu jedem Benutzer, die ausschließlich für die Übertragung von Daten eingesetzt werden, mehrere Benutzer in einem einzelnen Kanal oder auf einer einzelnen Frequenz ermöglicht. Ein effizienter Einsatz der Bandbreite in einem solchen Netzwerk erfordert, dass die Lückenzeiten zwischen den Übertragungen jedes Benutzers, die vergeudete Zeit bedeuten, minimiert werden. Die Lückenzeit muss ausreichend sein, um Unsicherheiten in Benutzertakten, Verzögerungszeiten und Sender-Einschalt- und Ausschaltzeiten zu berücksichtigen. Die Minimierung der Taktunsicherheit ist ein Hauptziel dieses Aspektes der Erfindung.
Senderbetriebs-/Nebenzeiten sind eine Funktion der Elektronikhardware. In dem Gesamtsystem ist die Hardware der Fahrzeugcomputer-Netzwerkschnittstelle so optimiert, dass sie in weniger als 128 Mikrosekunden ein- und ausgeschaltet werden kann. Eine Minimierung von Verzögerungszeiten wird durch Lichtgeschwindigkeitsverzögerungen zwischen Fahrzeugen und Hub-Empfangsstellen begrenzt. Ungefähr 800 Mikrosekunden werden in dem Netzwerk für schlechtestmögliche Fahrzeug-Fern-/Nahortung von 240 Kilometern zugeordnet. Nachdem diese Parameter festgelegt sind, wird das Augenmerk auf das Minimieren der Taktunsicherheit gerichtet. Das vereinfachte Blockschaltbild von 1, das hier zuvor beschrieben worden ist, auf das aber zum Zwecke der vorliegenden Erörterung erneut Bezug genommen wird, stellt das gesamte drahtlose TDMA-Netzwerk dar, das in der beispielhaften Ausführungsform der Erfindung eingesetzt wird. Das NDC 10 erhält eine genaue Synchronisation der Bordverfolger der Fahrzeuge 17-1, 17-2, ..., 17-n und der Netzwerk-Hubs 11-1, 11-2, ..., 11-i aufrecht, um den Betrieb des TDMA-Netzwerks zu ermöglichen. Die Synchronisation des Taktes der Verfolger miteinander und mit den Netzwerk-Hubs, die die durch die Verfolger gesendeten Daten empfangen, wird durch den Empfang eines Synchronisationsmuster in den Daten erreicht, die über die modulierte Unterträger-Übertragung von der FM-Funkstation 12 gesendet werden. Empfänger in dem NDC, die Verfolger und die Hubs empfangen die FM-Unterträgerdaten, und diese Einheiten richten ihren Systemtakt an den in den Daten enthaltenen Synchronisationsimpulsen aus.
Das Fehlerbudget für die Taktsynchronisation zwischen jedem Fahrzeug (oder genauer gesagt, dessen Verfolger), z. B. 17-1, und den Netz-Hub-Orten, z. B. 11-1, beträgt 10 Mikrosekunden. Es ist unverzichtbar, dass die Verfolger innerhalb dieses Fensters über die korrekte Zeit verfügen, da sie anderenfalls Gefahr laufen, gleichzeitig mit einem anderen Verfolger zu senden, wodurch die Wahrscheinlichkeit verringert wird, dass beide Übertragungen korrekt empfangen werden. Wenn Hub-Empfänger (z. B. 81, 31) nicht über die korrekte Zeit innerhalb des Fensters von 10 Mikrosekunden verfügen, können sie unter Umständen in ähnlicher Weise die korrekte Zeit zum Empfangen von Verfolgerübertragungen nicht aktivieren.
Die Systemtaktreferenz für jede Netzwerkkomponente, die SCC, den Verfolger, den Hub-Empfänger und den NDC-Empfänger in der beispielhaften Ausführungsform ist ein temperaturkompensierter Quarzoszillator (temperature compensated crystal oscillator – TCXO) mit einer Frequenzstabilität von 1,5 ppm. Dies bedeutet, dass der Takt weniger als 1,5 Mikrosekunden an Fehlern pro Sekunden erzeugt; es würde jedoch das Fehlerbudget von 10 Mikrosekunden innerhalb von sieben Sekunden im frei schwingenden Betrieb überschritten. Takte in allen Fahrzeugen und an allen Empfangsstellen weichen mit unterschiedlichen Geschwindigkeiten und in unterschiedliche Richtungen ab. Es wird eine stabile Taktreferenz benötigt, um alle Takte miteinander synchron zu halten. Ein GPS-Empfänger, der sich im Gegensatz zu dem Senderort bei dem NDC befindet, ist die stabile Zeitreferenz für das TDMA-Netzwerk.
12 stellt ein vereinfachtes Schaubild des Taktregelkreises 110 – eines entfernten Taktphasenregelkreises (phase locked loop – PLL) – für das TDMA-Netzwerk dar. Der Taktregelkreis 110 umfasst eine Zeitreferenz in Form des GPS-Empfängers 111, einen FM-Unterträger-Empfänger 112 und den NTCC 47, die sich alle bei dem NDC 10 (das hier und bisweilen an anderer Stelle hierin als die Netzleitstelle bezeichnet wird) befinden. Der PLL 110 umfasst darüber hinaus eine SCC 48 bei der FM-Funkstation 12 zum Steuern des Taktes der gesendeten Daten und einen Unterträger-Modulator 68 zum Bereitstellen der Daten für die Mischeinrichtung in einem Sender 113 in der Funkstation für das Übertragen auf dem FM-Unterträger-Signal 114 über den Sendemast 53.
Quarzoszillatoren (einschließlich TCXOs) sind relativ genaue Zeitquellen, weichen aber ohne regelmäßige Korrektur mit der Zeit ab. Der GPS-Empfänger 111 fungiert als eine stabile, exakte Zeitreferenz für die Taktsynchronisation des TDMA-Netzwerks, die einen Impuls pro Sekunde (Pulse Per Second – PPS) auf eine diskrete Ausgabeschnittstelle bereitstellt. Der PPS findet zu einer GPS-Zeit statt, die durch eine Nachricht in der seriellen Ausgabeschnittstelle des Empfängers 111 angegeben wird, üblicherweise auf den Grenzen ganzzahliger Sekunden, und ist üblicherweise bis auf 300 Nanosekunden genau, wenn er der durch die GPS-Satellitensignale 115 eingebrachten selektiven Verfügbarkeit unterliegt.
Der FM-Unterträger-Empfänger 112 bei dem NDC 10, der mit den durch die Verfolger und die Netzwerk-Hubs eingesetzten FM-Unterträger-Empfängern übereinstimmt, empfängt die Synchronisationsimpulse von der SCC 48 in dem FM-Unterträger-Signal 114. Die gleiche Hardware stellt sicher, dass Schwankungen in der Verzögerung durch die Empfänger minimiert werden. Der Unterträger-Empfänger 112 stellt die Empfangszeit der Synchronisationsimpulse relativ zu dem Empfang des PSS von dem GPS-Empfänger 111 fest. Differenz dt zwischen der Durchschnittszeit des Synchronisationsimpulses und der Zeit des PPS wird durch eine serielle Schnittstelle 116 für den NTCC 47 bereitgestellt. Die NTCC-Software verarbeitet die Zeitdifferenz und berechnet abhängig von ihrem Betriebsmodus auf unterschiedliche Weise einen an die SCC 48 zu sendenden Zeitkorrekturbefehl. In ihrem normalen kontinuierlichen Modus werden Zeitkorrekturen unter Verwendung eines Regelkreises mit niedriger Bandbreite berechnet.
In jeder Sekunde sendet die SCC 48 einen neuen Datenblock, der etwas weniger als eine Sekunde lang ist, und lässt dabei von einer Sekunde zur nächsten eine sehr kleine Lücke in den Daten. Zu Beginn der Daten ist eine Folge von drei Synchronisationsimpulsen vorhanden. Die SCC 48 wendet die empfangenen Zeitkorrekturbefehle auf die Zeit an, zu der sie beginnt, den nächsten Datenblock zu senden. Die Lücke zwischen den Datenblöcken ermöglicht das Anpassen der Startzeit der Daten auf eine frühere oder spätere Zeit als das Intervall, das durch die SCC 48 zu dem Zeitpunkt eingesetzt wurde, als der Befehl ausgegeben wurde.
13 stellt die drei Zeitsynchronisationsimpulse 120, 121, 122 mit der zeitlich genau festgelegten Länge von 964,8 Mikrosekunden mit einem exakten Intervall von 750,4 Mikrosekunden dar, die zum Beginn 125 der Daten jeder Sekunde durch die SCC 48 (12) gesendet werden. Die Sendedaten 126 folgen unmittelbar auf diese Synchronisationsfolge und dauern 986.240 Mikrosekunden an. Die resultierende Lücke 127 – ungefähr 8.600 Mikrosekunden lang; aber in der Länge variierend, während Zeitkorrekturen angewendet werden, die von dem NTCC 47 an die SCC 48 (12) gesendet werden – belegt den Rest des Intervalls von einer Sekunde bis zum Start 128 des nächsten Intervalls von einer Sekunde.
Die NTCC-Software führt eine Synchronisation des Netzwerks mit der GPS-Zeit aus, die in den Flussdiagrammen von 14A-D dargestellt wird. Der NTCC durchläuft vier Betriebsmodi einer Zeitausrichtung, und zwar: Initialisierung (14A), Grobes Offset (14B), Grobe Rate (14C) und Genaue Rate (14D). Im Initialisierungsmodus (14A) stellt der NTCC 47 (12) sicher, dass das durch die SCC 48 berichtete Taktintervall sich innerhalb von 10 ppm der nominalen Zählung von einer Sekunde befindet. Unter normalen Bedingungen sollte sich das SCC-Taktintervall innerhalb von 2,2 ppm befinden, wobei es sich um die Summenquadratwurzel (root sum square – RSS) der Genauigkeit der SCC und der Unterträger-Empfängertakte von 1,5 ppm handelt. Falls es sich außerhalb des Fensters von 10 ppm befindet, weist der NTCC 47 die SCC 48 an, ihr Taktintervall an dem Sollwert auszurichten. Die SCC wartet bei jedem Befehl darauf, dass er wirksam wird, und setzt, wenn er sich im Toleranzbereich befindet, den Zeitausrichtungsmodus auf „Grobes Offset".
In dem Groben Offsetmodus (14B) nimmt der NTCC 47 drei Abtastwerte der Zeitdifferenz dt zwischen dem PPS von dem GPS-Empfänger 111 und dem von dem FM-Unterträger an dem FM-Empfänger 112 empfangenen Synchronisationsmuster. Es wird ein durchschnittliches Offset von der GPS-Zeit aus den drei Werten berechnet (Σdt/3). Wenn die Größe des Offsets größer als oder gleich 100 μs beträgt, wird ein Befehl an die SCC 48 gesendet, die Startzeit der Synchronisationsimpulsfolge um den Offset-Betrag zu verschieben. Der NTCC 47 wartet dann drei Sekunden, wiederholt den Prozess, bis die Toleranz von 100 Mikrosekunden erreicht ist, und setzt den Zeitausrichtungsmodus auf „Grobe Rate".
Der Modus „Grobe Rate" (14C) wird eingesetzt, um das SCC-Zeitoffset und das Taktintervall in annähernde Ausrichtung in Vorbereitung des Regelkreisbetriebs des Modus „Genaue Rate" zu bringen. Die Zeitdifferenz dt, die durch den Unterträger-Empfänger 116 berichtet wird, wird 20 Sekunden lang jede Sekunde abgetastet, und es wird eine lineare Anpassung an die 20 Abtastwerte mit der Methode der kleinsten Quadrate ausgeführt. Das Ergebnis der Anpassung ist eine Kurve mit einer Flanke m und einem Offset b: dt = mt + bwobei dt eine Funktion der Zeit, t, ist. Es wird ein Geschwindigkeitsbefehl an die SCC 48 gesendet, um m auf Null zu korrigieren. Anschließend wird ein Offset-Befehl an die SCC gesendet, der die Zeit ausgleicht, die erforderlich ist, um die Anpassung zu berechnen, und der die Zeit ausgleicht, die erforderlich ist, bis der Befehl wirksam wird – insgesamt 23 Sekunden: m(20 + 3) + b. Sobald das durchschnittliche Offset der letzten drei Abtastwerte unter 20 Mikrosekunden liegt, wird der Zeitausrichtungsmodus zu „Genaue Rate" geändert.
Im Modus „Genaue Rate" (14D) führt der NTCC einen PLL mit niedriger Bandbreite aus, um den Netzwerktakt kontinuierlich zu steuern, und überwacht den Regelkreis auf Fehlerzustände. Die Werte von dt, Offset und Rate des SCC-Taktes werden stetig durch den NTCC 47 überwacht. Wenn der Wert von dt für drei aufeinander folgende Abtastwerte um mehr als 40 Mikrosekunden fehlerhaft ist und das durchschnittliche Offset um mehr als 16 Mikrosekunden fehlerhaft ist, wird der Zeitausrichtungsmodus zurück auf „Grobes Offset" gesetzt, und das Synchronisations-Flag wird gelöscht. Es wird kontinuierlich eine Anpassung mit der Methode der kleinsten Quadrate an dem Taktfehlersignal ausgeführt. Wenn der Durchschnittswert um mehr als 8 Mikrosekunden fehlerhaft ist oder die Rate für 5 Abtastwerte in Folge um mehr als 1 ppm fehlerhaft ist, wird der Modus auf „Grobe Rate" zurückgesetzt, und das Synchronisations-Flag wird gelöscht. Wenn diese beiden Bedingungen erfüllt sind, wenn die Schleife nicht synchronisiert ist, wird das Synchronisations-Flag gesetzt.
Ein Blockschaltbild des Taktphasenregelkreises 110 in 15 stellt die Funktionen des Unterträger-Empfängers 112, des NTCC 47 und der SCC 48 für die Ausführung der Taktsteuerung mathematisch dar. Die Regelkreisbandbreite des PLL beträgt ungefähr 0,014 Hz (ungefähr eine Periode von 70 Sekunden). Der NTCC 47 tastet fortlaufend die dt-Ausgabe des Unterträger-Empfängers 112 ab und führt die PLL-Steuerung 130 aus, um Geschwindigkeitsbefehle zu erzeugen, die an die SCC 48 gesendet werden sollen. Die Geschwindigkeitsbefehle dienen dazu, kleine Taktfehler 131, 132 in den TCXOs der SCC 48 und des Unterträger-Empfängers 112 zu korrigieren.
Jeder Computer, der bei der vorliegenden beispielhaften Ausführungsform empfangend oder sendend mit dem TDMA-Netzwerk verbunden ist, setzt einen Mikrocontroller Motorola 68332 ein – einen 32-Bit-Prozessor mit einem 68020 Kern mit Serverperipherie auf dem Chip. Eines der Peripheriegeräte ist eine Zeitverarbeitungseinheit (Time Processing Unit – TPU, z. B. zusammen mit dem Prozessor 83 in dem Hub-Blockschaltbild in 30 dargestellt), die über 16 Kanäle an Spezialhardware zum Messen von Impulsbreiten und zum Erzeugen von Takten verfügt. Bei einem Takt von 20 MHz kann sie Messungen mit einer Auflösung von 0,2 Mikrosekunden vornehmen. Die TPU wird eingesetzt, um die FM-Unterträger-Synchronisationsimpulse zu erfassen und die genauen Takte für gesendete Daten zu erzeugen, sowohl auf dem Unterträger als auch durch die Fahrzeugortungscomputer in dem TDMA-Netzwerk.
Dabei erfasst und regelt die TPU das über den FM-Unterträger gesendete Synchronisationsimpulsmuster. Die in diesem Zusammenhang ausgeführte Verarbeitung durch den NDC-Unterträger-Empfänger, den Verfolger und die Netzwerk-Hub-Empfänger ist so gut wie identisch. Die CPU führt zwei Zeitgeber aus, und zwar einen Taktgeber mit 2.048 Hz für die Aufgabenplanung und den internen TPU-Taktgeber mit 5 MHz (Systemuhr dividiert durch vier). Für Taktzwecke wird der Taktgeber mit 2.048 Hz verwendet, um die Mehrdeutigkeit im TPU-Takt aufgrund der überlappenden Eingabe seines 16-Bit-Zählers alle 13 Millisekunden zu berücksichtigen. Die TPU-Kanalfunktionszuweisungen werden in Tabelle 56 (Anhang B) dargestellt.
Es wird nun Bezug auf diese Tabelle genommen, wobei beim Betrieb der TPU für die Synchronisation und die Takterzeugung die Synchronisationsimpulsfolge durch Ausführen einer Perioden-/Impulsbreitenakkumulationsfunktion (Period/Pulse Width Accumulation – PPWA) in dem TPU-Kanal 4 erfasst wird. Die TPU unterbricht den Prozessor bei jeder fallenden Flanke, die in den Eingabedaten erfasst wird, und stellt für den Prozessor die Zeit der fallenden Flanke und die vorhergehende Impulsbreite zur Verfügung. Wenn der Prozessor innerhalb eines Toleranzfensters drei Impulse von geeigneter Breite und geeignetem Abstand erfasst, legt er die Startzeit der Synchronisation in TPU-Zählungen auf Basis der Zeit der fallenden Flanke der empfangenen Impulse fest. Der Verfolger verfügt über zwei Empfänger für FM-Daten. Abhängig von der an einer der Antennen verfügbaren Signalqualität kann er versuchen, unter Verwendung des direkt oben beschriebenen Verfahrens anhand des TPU-Kanals 11 die Synchronisationsfolge in dem zweiten Kanal zu erfassen.
Der Start des Synchronisationsmusters wird von allen Empfängern als Referenz zum Erzeugen des Datentaktes eingesetzt, der erforderlich ist, um die FM-Daten in Schieberegister und in den Prozessorspeicher für das Decodieren einzulesen. Ein identischer Synchronisationsalgorithmus wird von allen Netzwerkelementen eingesetzt, um sicherzustellen, dass die Schwankungen in der Zeitschätzung minimiert werden. Eine Schätzung der Synchronisationsstartzeit wird durch die CPU unter Verwendung eines PLL mit niedriger Bandbreite verwaltet, der demjenigen, der durch den NTCC zum Steuern der Synchronisation relativ zu der GPS-Zeit eingesetzt wird, ähnlich ist. Die CPUs in dem Verfolger, dem Netzwerk-Hub und dem NDC-Unterträger-Empfänger führen sämtlich einen PLL zweiter Ordnung mit einer Bandbreite von 0,05 Hz aus, um eine Schätzung der Synchronisationsstartzeit zu erzeugen, so dass Störgeräusche in den Empfangsdaten keinen wesentlichen Synchronisationsfehler in der Synchronisationszeit verursachen. Dies ermöglicht darüber hinaus dem Prozessor, eine Zeitschätzung zu führen, die nur langsam an Genauigkeit abnimmt (TCXO-Fehler), wenn Synchronisationsimpulse verpasst werden, und so die Fähigkeit zu erhalten, Daten unter schlechten HF-Empfangsbedingungen zu empfangen und zu senden. Die Zeitschätzung wird verwendet, um die Datentakte unter Verwendung von vier TPU-Kanälen zu starten.
Der TPU-Kanal 5 führt eine Ausgabevergleichsfunktion (Ausgabevergleich – Output Compare – OC) aus, die darauf ausgelegt ist, einzelne Ausgabeübergänge oder kontinuierliche Takte zu erzeugen. Unter Verwendung der Synchronisationszeitschätzung codiert die CPU den Kanal so, dass er einen Impuls mit einer exakten Verzögerung nach dieser Zeit ausgibt. Der TPU-Kanal 6 führt die Funktion der Eingangsänderungs-Aufzeichnung/-Zählung (Input Transition Capture/Count – ITC) aus, die so eingerichtet ist, dass sie Änderungen in einer Eingangsleitung erfasst und den Prozessor unterbricht und/oder die Verarbeitung in anderen TPU-Kanälen auslöst. In diesem Fall erfasst sie den Impuls von Kanal 5 und startet die OC-Funktionen in den Kanälen 7 und 8, die einen Bittakt und einen Bytetakt erzeugen. Der Bittakt schaltet für jedes empfange Bit um und bewirkt, dass jedes Bit in ein Schieberegister verschoben wird. Der Bytetakt läuft mit einem Achtel der Rate des Bittaktes ab und übernimmt das Byte in den Prozessor. Sobald alle Datenbits eingetaktet sind, schaltet der Prozessor die Takte in der Lückenzeit vor den Daten der nächsten Sekunde ab.
Wie zuvor hier beschrieben, vergleicht der NDC-Unterträger-Empfänger 112 (12) die empfangene Synchronisationszeit mit der PPS-Zeit von dem GPS-Empfänger 111, um die dt-Messung für die Software des NTCC 47 bereitzustellen. Die genaue Messung von dt wird durch Anlegen des PPS-Ausgabesignals von dem GPS-Empfänger 111 mit dem TPU-Kanal 11 an der CPU des Unterträger-Empfängers durchgeführt. Der Kanal 11 führt eine ITC-Funktion aus, die den Impuls erfasst und den Prozessor unterbricht. Der Prozessor zeichnet die PPS-Zeit auf. Unter normalen Bedingungen werden daraufhin die drei Synchronisationsimpulse an Kanal 4 erfasst, und es wird die Synchronisationszeit berechnet. Diese Zeiten weisen eine Exaktheit von 0,2 Mikrosekunden und eine Genauigkeit des TCXO von 1,5 ppm auf, wobei der Wert dt einfach die Differenz zwischen den Zeiten darstellt.
Die Verfolger setzen die Schätzung der Synchronisationszeit als eine Referenz zum Starten der Sendedatenfolge ein. Ungefähr eine Sekunde bevor der einem Verfolger zugewiesene Zeitschlitz auftritt, richtet die CPU Verarbeitungsaufgaben ein, um zu sendende Daten zu formatieren, lädt Ausgabepuffer und initialisiert die TPU-Kanäle. Der TPU-Kanal 0 führt eine OC-Funktion aus, die ungefähr 6 Millisekunden, bevor die Sendefolge beginnen soll, initialisiert wird. Dieser Kanal bestätigt die Sendeschlüsselleitung der HF-Karte und löst darüber hinaus die Folge weiterer TPU-Ereignisse aus, die erforderlich sind, um Daten in dem TDMA-Netzwerk zu senden. Die OC-Funktion erzeugt eine einzelne Änderung zu Beginn des Zeitschlitzes von ungefähr 20 Millisekunden, indem sie den Sender einschaltet. Dieses Signal wird außerdem in den Kanal 1 der TPU eingegeben, der die ITC-Funktion ausführt. Die Erfassung der Änderung an Kanal 0 startet einen Sendedatenblock an Kanal 2, der um 96 Mikrosekunden verzögert ist, um der Senderleistung zu ermöglichen, sich zu stabilisieren. Der Taktgeber sendet Daten von einem Verschieberegister in der TPU, einer seriellen Peripherieschnittstelle mit Warteschlange (queued serial peripheral interface – QSPI; siehe z. B. Prozessor 83, 30). Der Takt wird außerdem in den TPU-Kanal 3 eingegeben, der eine ITC-Funktion ausführt, um die Anzahl der gesendeten Bits zu zählen. Die Sendebitanzahl wird durch den Prozessor eingesetzt, um das QSPI-Ausgaberegister auf Basis eines Interrupts von der ITC aufzufüllen, wenn die gewünschte Ausgabeanzahl erreicht ist. Die CPU schaltet darüber hinaus den CC-Sendeschlüssel an Kanal 0 aus, indem sie einen entgegengesetzten Übergang 19.200 Mikrosekunden, nachdem das Schlüsselsignal bestätigt worden ist, terminiert.
Die CPU der Netz-Hub-Empfangsstelle setzt die TPU ein, um die Synchronisationsinformationen zum Kennzeichnen des Beginns jedes TDMA-Zeitschlitzes von 20 Millisekunden zu erzeugen. Auf Basis der geschätzten Synchronisationsstartzeit richtet die CPU eine OC-Funktion an einem TPU-Kanal ein, um in Intervallen von exakt 20 Millisekunden umzuschalten. Dieses Signal steuert die Verarbeitungsstartzeiten für einen digitalen Signalprozessor (DSP), um Takt- und Datenrückgewinnung an allen in jedem Schlitz empfangenen Daten auszuführen. In diesem Fall kann die TPU nicht eingesetzt werden, um den Datentakt zu erzeugen, da die Lichtgeschwindigkeitsverzögerungen von den in die Fahrzeuge eingebauten Verfolgern zu dem Hub-Empfänger schwankend und schwer einschätzbar sind. Der DSP-Prozessor (z. B. 80, 30) führt eine Stapelverarbeitung an den aufgezeichneten Daten des vorhergehenden Schlitzes aus, während Daten für den aktuellen Schlitz in einer Speicherbank gespeichert werden. Bei der nächsten Schlitzintervall-Umschaltung schaltet der DSP zwischen Speicherbänken um, und die neuen Daten werden in der eben verarbeiteten Bank gespeichert.
Die SCC ist der Erzeuger des Synchronisationsmusters in den FM-Übertragungsdaten, die durch die anderen Elemente in dem System als exakte Zeitreferenz für das Arbeiten in dem TDMA-Netzwerk eingesetzt werden. Die SCC setzt dieselbe Folge von TPU-Funktionen an den Kanälen zum Senden ihrer Daten an den FM-Unterträger-Modulator ein, wie sie der Verfolger einsetzt, um Daten in dem TDMA-Netzwerk zu senden. Die Unterschiede bestehen darin, dass die SCC nahezu eine Sekunde lang sendet und die Startzeit der Übertragung durch einen Befehl von dem NTCC über eine Modemverbindung gesteuert wird. Die SCC läuft auf einem TCXO mit 10 MHz anstelle eines Taktes von 20 MHz, so dass ihre Zeitauflösung 0,4 Mikrosekunden statt 0,2 Mikrosekunden beträgt.
Nahe dem Beginn jeder ganzzahligen Sekunde empfängt die SCC einen Taktkorrekturbefehl von dem NTCC und die in der nächsten Sekunde zu sendenden Daten. Während sie diese Daten empfängt, sendet die SCC die Daten der aktuellen Sekunde. Die SCC formatiert einen Bitstrom, der die Synchronisationsimpulsfolge am Anfang, gefolgt von den Daten, enthält. Am Ende des aktuellen Datenübertragungszyklus richtet die CPU die TPU-Funktionen ein und lädt den Ausgabepuffer (ebenso wie die QSPI) mit den zu sendenden Daten. Es wird eine OC-Funktion initialisiert, um mit der aktuellen Intervallzählung der TPU von einer Sekunde, wie durch den NTCC-Befehl modifiziert, umzuschalten.
Der NTCC-Befehl kann entweder ein einmaliges Offset während der anfänglichen Zeitausrichtung der SCC oder ein Geschwindigkeitsanpassungsbefehl während des normalen Zeitausrichtungsmodus „Genaue Rate" sein. Die nominale TPU-Anzahl für eine Intervall von einer Sekunde auf der SCC beträgt zum Beispiel 2.500.000. Wenn der NTCC feststellt, dass der SCC-Takt um 0,4 ppm zu schnell ist, schickt er einen Geschwindigkeitsanpassungsbefehl an die SCC, damit sie ihre Anzahl um eins auf 2.500.001 erhöht, so dass der zu schnelle SCC-Taktgeber eine zusätzliche Einheit von 0,4 Mikrosekunden zählen muss, um ein korrektes Intervall von einer Sekunde zu erzielen. Die SCC setzt dieses Intervall ein, bis es erneut durch den NTCC korrigiert wird.
Wie bei dem Verfolgungscomputer wird eine ITC-Funktion in einem anderen Kanal eingesetzt, um die OC-Änderung zu erfassen und einen kontinuierlichen OC-Bitblock in einem dritten Kanal zu veranlassen. Ein vierter Kanal zählt die gesendeten Bits und füllt die QSPI-Puffer nach Bedarf auf. Sobald alle Bits gesendet worden sind, schaltet die CPU den Ausgabetakt ab und beginnt eine Wiederholung des Prozesses.
VI. Bandbreiteneffizientes drahtloses Sende-/Empfangssystem
Wie in dem oben stehen Abschnitt über das TDMA-Netzwerk festgestellt, ist die effiziente Nutzung von Bandbreite unverzichtbar für drahtlose digitale TDMA-Datennetze. Die nach einem weiteren Aspekt der Erfindung angewandten Verfahren, die in diesem Abschnitt der Patentschrift erläutert werden, maximieren die Effizienz durch Filtern der Basisbanddaten, um die belegte Bandbreite des Kanal zu verringern, und durch Unterdrücken der Übertragung von Synchronisationsinformationen, um den Overhead an nicht informationstragenden Daten zu minimieren. Der Basisbandfilter wird durch einen digitalen Mikrocontroller umgesetzt und ersetzt den ursprünglichen Datenstrom des Rechtecksignals durch deterministische Übergänge, die unabhängig von der Dateneingabefrequenz den Oberschwingungsanteil verringern und die Bitbreite beibehalten. Die Entfernung von Synchronisationsdaten wird durch Hinzufügen von prozessorintensiven Takt- und Datenrückgewinnungs-Algorithmen an der Empfangsstelle ermöglicht. Das Netzwerk setzt darüber hinaus nach weiteren Aspekten der Erfindung Vorwärtsfehlerkorrektur und Raum-Diversity-Verarbeitung ein, um die Zuverlässigkeit von empfangenen Daten zu erhöhen, wodurch die für die erneute Übertragung von korrumpierten Daten verwendete Bandbreite verringert wird.
Das TDMA-Netzwerk der beispielhaften Ausführungsform wird in 50 Fahrzeug-Sendezeitschlitze pro Sekunde aufgeteilt. Durch im vorhergehenden Abschnitt dieser Patentschrift beschriebene Einrichtungen werden sämtliche Verfolger und Netz-Hub-Empfängercomputer mit einer Taktgenauigkeit von wenigen Mikrosekunden synchronisiert, so dass die Lückenzeiten zwischen den 50 Zeitschlitzen auf ein Minimum reduziert werden. Die Verfolger erhalten eine genaue Taktzählung aufrecht, um den Zeitpunkt festzustellen, zu dem ein Datenpaket gesendet werden soll. Die durch die Verfolger ausgeführte Verarbeitung zum Senden der Datenpakete umfasst Vorwärtsfehlerkorrekturcodierung (Vorwärtsfehlerkorrektur – Forward Error Correction – FEC), Bitverschachtelung, Codierung der Verzögerungsleitung, Filtern vor der Modulation und binäre Frequenzumtastung (Binary Frequency Shift Keying – BFSK). Bei Empfang des Paketes führt der Hub-Computer FSK-Demodulation an einer Zwischenfrequenz (Intermediate Frequency – IF), digitales Abtasten des IF-Signals, Bittaktrückgewinnung, Bitsynchronisation unter Verwendung eines Iterationsverfahrens und Datencodierung aus. In jeder Sekunde werden bis zu 50 Fahrzeugdatenpakete an den NDC-Netzwerkserver gesendet, der Daten von anderen Netz-Hub-Empfängern in einem Diversity-Verarbeitungsalgorithmus verknüpft und eine FEC-Decodierung an dem resultierenden Datenpaket ausführt.
16 ist ein Blockschaltbild der TDMA-Sendedatenpaketverarbeitung, die durch den Verfolger (Verfolgungscomputer) 135 in jedem Fahrzeug ausgeführt wird. Ein Datenpaket 137 besteht aus 12 gesamtinformationentragenden Datenbytes oder 96 Bits. Die zu übertragenden Daten sind in den meisten Fällen dicht an dicht gepackt, so dass wenige verschwendete Bits zwischen Datenelementfeldern vorhanden sind. Der Inhalt der durch die Verfolger gesendeten Datenpakete variiert abhängig vom Typ der Daten, die der Verfolger berichten muss; die Pakete enthalten üblicherweise Navigationsdaten in periodischen Berichtsschlitzen und besondere Daten, wie zum Beispiel Ereignisberichte (z. B. was das Fahrzeug macht oder was ihm begegnet), Netzwerksteuerungsinformationen oder Codes ausgehender Nachrichten in Hilfsberichtsschlitzen.
Der Verfolger führt zunächst eine Vorwärtsfehlerkorrekturcodierung 138 (Vorwärtsfehlerkorrektur – forward error correction – FEC) der Daten aus. Es wird ein (12,8)-Code eingesetzt, der Codewörter verwendet, die 12 Bit lang sind, um jedes Datenbyte zu codieren. Es handelt sich dabei um einen BCH-Fehlerkorrekturcode, der es dem Server ermöglicht, ein Bit in jedem Codewort von 12 Bit zu korrigieren. Der (12,8)-Code wird darüber hinaus durch den Netz-Hub-Empfängerprozessor in seinem Bitsynchronisations-Algorithmus eingesetzt, um den wahrscheinlichen Beginn des Datenpaketes durch Auswählen des Takt-Offsets, das die Anzahl der Codewortfehler minimiert, zu lokalisieren. Das Ergebnis des FEC-Codierschrittes 138 ist eine Gesamtmenge von 144 zu sendenden Datenbits.
Als Nächstes werden die 144 Datenbits in 139 verschachtelt, ohne welchen Schritt jedes Codewort der Reihe nach gesendet würde. Funkdaten in mobilen Umgebungen können durch Bündelfehler korrumpiert werden, die dazu führen, dass mehrere aufeinander folgende Bits fehlerhaft empfangen werden. Da der FEC-Algorithmus nur ein Bit in jedem Codewort korrigieren kann, würde ein Bündel von Bitfehlern ein Wort unkorrigierbar machen. Die Bitverschachtelung stellt sicher, dass das erste Bit jedes Wortes zuerst gesendet wird, gefolgt von sämtlichen zweiten Bits und so weiter, um eine gewisse Unanfälligkeit gegenüber Bündelfehlern zur Verfügung zu stellen. Dies ermöglicht es dem FEC-Algorithmus, ein Bündel zu korrigieren, das zum Beispiel sämtliche ersten Bits zerstört, da er nur ein Bit in sämtlichen Codewörtern statt alle Bits in einem einzelnen Codewort beeinträchtigt. In jedem Paket müssen alle Codewörter erfolgreich decodiert werden, damit das Paket sinnvoll ist.
Es wird ein eindeutiges Verschachtelungsschema für die durch den Fahrzeugverfolger gesendeten Daten eingesetzt, damit der durch den Hub-Empfänger eingesetzte Bitsynchronisations-Algorithmus funktionieren kann. Anstelle des einfachen Anordnens aller ersten Bits, aller zweiten Bits bis zu allen zwölften Bits, wird die verwendete Anordnung in 17 dargestellt. Diese stellt eine Verschachtelungstiefe von 11 anstelle der mit einfacher Verschachtelung möglichen 12 bereit, stellt aber eine Randomisierung der Datenbits zur Verfügung, um sicherzustellen, dass einzelne Bitverschiebungen in empfangenen Daten Fehler in sämtlichen Codewörtern verursachen. In 17 wird die verschachtelte Bitanordnung in Tabellenform dargestellt: Die Zeilen sind verschachtelte 12-Bit-Wörter, und die Spalten sind die Bits innerhalb der Wörter. Die Bits werden von links nach rechts und von oben nach unten gesendet. Die Bits der ursprünglichen FEC-Codewörter werden durch das W/B-Format auf jeder verschachtelten Bitposition identifiziert. Dies sind die Bits, B, des Codewortes, W.
Wir kehren zu 16 zurück, wo die CPU nach der Verschachtelung die Daten unter Verwendung eines Verzögerungs-, oder Miller-, Linien-Codierungsalgorithmus 140 codiert. Die Verzögerungscodierung ist insofern ähnlich wie die Manchestercodierung, als sie Übergänge in den codierten digitalen Daten gewährleistet. Sie unterscheidet sich darin, dass sie die maximale Baudrate der uncodierten Daten nicht erhöht. Ein Nachteil des Verzögerungscodes besteht darin, dass er etwas komplizierter zu codieren ist als der Manchestercode. Der Verzögerungscode ersetzt jede ,1' in dem ursprünglichen Datenstrom durch einen Übergang an der Stelle des Mittelbits; der Übergang beginnt an dem Ausgangspegel des vorhergehenden Bits. Eine ,0' in den ursprünglichen Daten wird durch keine Zustandsänderung wiedergegeben, sofern nicht das vorhergehende uncodierte Bit eine ,0' war. In diesem Fall wird die zweite ,0' als eine Zustandsänderung zwischen Bitgrenzen codiert. Der Algorithmus stellt sicher, dass es drei verschiedene Bitbreiten gibt: 1-mal, 1,5-mal und 2-mal so breit wie das ursprüngliche Bit. Die 18A-C, die in Kürze weiter erörtert werden, stellen einen Vergleich einer ursprünglichen Datenfolge mit der verzögerungscodierten Version dieser Folge und eine Erläuterung des Filterns der verzögerungscodierten Folge bereit.
Wir kehren nun erneut zu 16 zurück, wo die digitalen Daten eines Rechtecksignals, wie bei der ursprünglichen Datenfolge und der verzögerungscodierten Version davon, gefiltert werden müssen, um die Flanken so abzurunden, dass Oberschwingungen, die dazu führen, dass die belegte Bandbreite der gesendeten Daten breit ist, minimiert werden. In der vorliegenden beispielhaften Ausführungsform ist ein Vormodulationsfilter 141 für die verzögerungscodierte Version unter Verwendung eines Mikrocontrollers PIC^TM 16F84-10I/SO (PIC ist ein Markenzeichen von Microchip Technology Inc. in Chandler, Arizona, dem Hersteller der Vorrichtung) implementiert, gefolgt von einem Digital-/Analog-Wandler (digital to analog converter – DAC) 142, der unter Verwendung eines genauen Widerstandnetzwerks erstellt worden ist. Die gefilterte analoge Darstellung des ursprünglichen digitalen Datenstroms wird unter Verwendung von Frequenzumtastung in Schritt 143 moduliert und durch den Verfolger von dessen Antenne 145 nach einer Verstärkung in 144 gesendet.
Der Filteralgorithmus, der in dem Vormodulationsfilter 141 eingesetzt wird, um sicherzustellen, dass drei verschiedene Bitbreiten vorhanden sind: 1-mal, 1,5-mal und 2-mal so breit wie das ursprüngliche Bit, wird in Form eines Ablaufdiagramms in 19 dargestellt. Der Mikrocontroller PIC^TM tastet kontinuierlich die digitalen Eingabedaten auf der Suche nach einem Übergang ab. Wenn ein Übergang stattfindet, führt der Mikrocontroller in Schritt 147 In-line-Code aus, um schnell Bytewerte an den DAC 142 auszugeben, die den Übergang in Form einer Sinuswelle darstellen. Wenn die Ausgabe des Übergangsbogens abgeschlossen ist, kehrt die Software des Mikrocontrollers zum Suchen nach dem nächsten Eingabedatenübergang zurück.
Der PIC^TM-Mikrocontroller ersetzt jeden Datenübergang nach Bedarf durch eine steigende oder fallende halbe Sinuswelle. Die maximale Baudrate der verzögerungscodierten Daten beträgt 7.812,5 bps. Dies entspricht einer maximalen Datenfrequenz von 3.906,25 Hz. Bei dieser Anwendung läuft der Mikrocontroller mit einem Takt von 10 MHz und verfügt über einen Befehlszyklus von 4 Systemtaktzyklen. Das Verfahren der schnellsten Ausgabe von Daten an den DAC erfordert zwei Befehle pro Punkt oder 0,8 Mikrosekunden. Die Periode der Daten mit der höchsten Frequenz beträgt 256 Mikrosekunden. Im Idealfall würde jeder Übergang durch eine halbe Sinuswelle mit 160 Punkten (128 Mikrosekunden dividiert durch 0,8 Mikrosekunden pro Punkt) ersetzt, so dass die vorhandenen Daten mit der höchsten Frequenz dem Modulator als eine reine Sinuswelle erscheinen würde.
Es können nicht alle 128 Mikrosekunden eingesetzt werden, um die gefilterte Übergangsausgabe zu erzeugen, da Zeit für den Overhead der Übergangserfassung und andere Funktionen übrig bleiben muss. Daher wird ein Übergangsbogen mit 150 Punkten eingesetzt. Die 18B und 18C stellen jeweils die verzögerungscodierten Daten und die gefilterte Ausgabe dar, die durch den digitalen Vormodulationsfilter erzeugt wird. Jede Flanke in den Daten der verzögerungscodierten Version in 18B wird um ungefähr 64 Mikrosekunden verzögert. Da diese Filterverzögerung konstant ist, wird sie in der durch die CPU bereitgestellten Sendedatentaktung berücksichtigt. 20 stellt einen schematischen Vergleich des angenäherten Leistungsspektrums der uncodierten 137, der verzögerungscodierten 140 und der gefilterten Daten in 18A-C dar. Die Verzögerungscodierung bündelt mehr Energie mit einem Durchschnitt von ungefähr ¾ der maximalen Frequenz. Die Spektren für zwei Filterversionen werden in dem Schaubild in 20 gezeigt, wobei die eine ein idealer Übergangsfilter 148 mit 160 Punkten ist, der für Bezugszwecke dargestellt wird, und die andere eine praktische Umsetzung 141 mit 150 Punkten ist. Letztere verfügt über eine etwas höhere Leistung von ungefähr dem ein- bis dreifachen der Grundfrequenz. Aus den oben vermerkten Gründen beschneidet der Filter im Wesentlichen die für das Senden der TDMA-FSK-Daten erforderliche Kanalbandbreite.
Ein Digitalfilter dieses Typs bietet den erheblichen Vorteil, dass sein Ausgang unabhängig von der Eingangsfrequenz über eine konstante Verzögerung verfügt, die der linearen Phasenverzögerung mit steigender Frequenz entspricht. Dies ist eine Eigenschaft von digitalen Filtern mit endlicher Impulsantwort. Herkömmliche digitale oder analoge Filterverfahren mit unendlicher Impulsantwort verfügen über eine nicht lineare Phase, die Bitbreiten verzerren kann, wenn die Eingangsfrequenz schwankt. Abhängig von der Filtergrenzfrequenz kann dies Intersymbolinterferenz verursachen. Die konstante Verzögerung ermöglicht das Senden exakter Bitbreiten ohne Verzerrung. Wenn Daten mit deterministischen und wiederholbaren Bitbreiten empfangen werden, können die Bits und die Bitwerte zuverlässig getaktet und decodiert werden.
In dem in der vorliegenden beispielhaften Verfolgerdatenverarbeitung in 16 eingesetzten UHF-Sendermodulatorabschnitt übernimmt der Mikrocontroller 141 die Sendedateneingabe (Sendedaten – transmit data – TXD) und stellt als Ausgabe einen Bytewert zur Verfügung. Diese Ausgabe wird in eine Widerstandsreihenschaltung 2QP16TF6235 von Bourns eingegeben, die als der DAC 142 fungiert. Der Mikrocontroller 141 führt darüber hinaus die Aufgabe aus, den Verfolgersender auf Basis von exakt getakteten Signalen von der CPU-Karte 149 zu synchronisieren.
Nach dem Filtern werden die Daten auf einem UHF-Träger in dem gemeinsam genutzten Business Band von 450-470 MHz in einem Offsetkanal von 12,5 kHz moduliert. Die durch den Vormodulationsfilter bereitgestellte Bandbreitensteuerung ist ein Schlüsselelement beim Ermöglichen einer Datenrate von 7.812,5 bps in einem so schmalen Kanal, während ein sehr einfaches FSK-Modulationsverfahren eingesetzt wird. Die Modulation setzt eine Abweichung von ungefähr 2 kHz ein. Der Verfolgersender verfügt über eine Ausgabe von zwei Watt.
Die Netzwerk-Hub-Empfänger sind rundherum im Stadtgebiet positioniert, um die TDMA-Übertragungen von den Fahrzeugverfolgern zu empfangen. 21 stellt ein Blockschaltbild der durch jeden Netzwerk-Hub 11 an den empfangenen RF-Signalen ausgeführten Verarbeitung dar. Die Front-End-Hardware des UHF-TDMA-Empfängers (die HF-Karte 151) ist zu jeder Zeit eingeschaltet. An der Antenne 152 empfangene Signale werden in 153 zu einem Zwischenfrequenzsignal (Zwischenfrequenz – intermediate frequency – IF) von 455 kHz demoduliert, das in 154 digitalisiert wird. Die IF-Frequenz wird weiter durch einen anwendungsspezifischen integrierten Schaltkreis (application-specific integrated circuit – ASIC) 155 verarbeitet, der eine digitale Filterung und Demodulation an einem Basisbandsignal ausführt. In exakten Intervallen von 20 Millisekunden, die den Grenzen zwischen Fahrzeugübertragungen entsprechen, wird jeder Abschnitt des Basisbandsignals von 20 Millisekunden mit einer hohen Rate abgetastet (156) und in einem Speicher gespeichert.
Ein digitaler Signalprozessor (DSP) (z. B. 80, 29) in dem CPU-Abschnitt 158 des Netz-Hubs wird eingesetzt, um die Daten aus dem abgetasteten Basisbandsignal zu extrahieren. Die Verarbeitung wird in einem Stapelmodus an dem gesamten Datenpaket ausgeführt, nachdem es empfangen worden ist. Währenddessen werden Daten, die empfangen werden, in einer alternativen Speicherbank für die Verarbeitung in dem nächsten Zyklus von 20 Millisekunden gespeichert. Die Stapelverarbeitung ermöglicht den Einsatz leistungsfähigerer Algorithmen, da so ein Datensatz als Ganzes analysiert werden kann. Echtzeitverarbeitung erfordert, dass der Algorithmus Daten spontan ohne den Vorteil nachfolgender Eingabedaten zurückgewinnt. Der DSP führt eine Taktrückgewinnung aus und ortet dann die Daten innerhalb des Fensters von 20 Millisekunden. Die zurückgewonnenen Daten werden entschachtelt, und die Daten für alle 50 Zeitschlitze werden schließlich zur weiteren Verarbeitung an den NDC-Netzwerkserver gesendet.
Die Rückgewinnung der Daten erfolgt durch einen prozessorintensiven Algorithmus. Um die Anzahl der durch die Fahrzeuge gesendeten Bits zu verringern und daher die Anzahl der Fahrzeuge zu erhöhen, die in jeder Sekunde berichten können, werden keine besonderen Bitmuster mit dem Datenpaket gesendet, die der Empfänger erfassen muss. Durch das Erfordernis, dass Bitsynchronisationsmuster die Daten erfassen müssen, wird darüber hinaus die Zuverlässigkeit in einer mobilen HF-Umgebung verringert, denn falls das Bitmuster korrumpiert ist, kann das Nachrichtenpaket nicht wiederhergestellt werden, selbst wenn es fehlerfrei empfangen wird. Jede Fahrzeugübertragung findet zu einem sehr exakten Zeitpunkt statt, aber ihr Empfang wird durch die Lichtgeschwindigkeit über die Distanz zwischen dem Fahrzeug und dem Hub-Empfänger um bis zu 800 Mikrosekunden verzögert. Der Hub muss den Start der Nachricht innerhalb des Fensters von 20 Millisekunden ohne Unterstützung von besonderen Bitsynchronisationsmustern lokalisieren. Zu diesem Zweck setzt er eine iterative Suche ein, die die Daten nacheinander mit immer größeren Verzögerungen von der nominalen Nachrichtenstartzeit eintaktet, bis ein gültiges Datenpaket lokalisiert worden ist.
Zunächst gewinnt der DSP-Algorithmus durch Differenzieren der empfangenen Daten den Bittakt (160, 21) für die empfangenen Daten zurück. Die differenzierten Daten weisen hohe Größenwerte an den Bitflanken auf. Bei der Verzögerungscodierung sind Bitflanken häufig, da Übergänge in den Daten gewährleistet sind. Die Zeitverzögerung vom Start des Datensatzes zu jeder ersichtlichen Bitflanke wird gemessen, modulo 64 Mikrosekunden. Die Moduloverzögerung wird gemittelt, um eine durchschnittliche Datentakt-Flankenzeit zu bestimmen, die auf den gesamten Datensatz angewendet werden kann. Eine Mittelbitzeit wird als ein Offset von 32 Mikrosekunden von der durchschnittlichen Verzögerung berechnet.
Mit diesem Offset werden die Daten in dem Zwischenspeicher mit 15.625 Bit pro Sekunde (in Intervallen von 64 Mikrosekunden) abgetastet. Diese Taktrate wird eingesetzt, um den Verzögerungscode zurückzugewinnen, da er Übergänge an der Stelle des Mittelbits für Einsen in den ursprünglichen, uncodierten Daten aufweist. Es wird eine Gesamtzahl von 288 verzögerungscodierten Bits eingetaktet.
Eine Verzögerungscodierung (161) wird an den abgetasteten 288 Bits ausgeführt, um 144 ursprüngliche Datenbits zu erzeugen. Nur bestimmte zulässige Bitmuster sind in dem Verzögerungscode vorhanden. Wenn ein Bitfehler ein ungültiges Muster verursacht, wird das Muster in eines der durch das Muster dargestellten möglichen Bits decodiert. Wenn eine anschließende Fehlererkennungsverarbeitung an den decodierten Daten einen Fehler anzeigt, wird, wenn nur ein mehrdeutiges Datenmuster in diesem bestimmten Codewort während des Verzögerungscodierungsprozesses aufgetreten ist, der andere Bitwert eingesetzt und die Fehlererkennung wiederholt. Wenn sie erfolgreich verläuft, wird der zweite Bitwert gehalten. Wenn mehr als ein Bit mehrdeutig ist oder das zweite Bit ebenfalls nicht zu gültigen Daten führt, wird der ursprüngliche Wert gehalten, und der Verarbeitung wird ermöglicht fortzufahren. Der Bitfehler kann möglicherweise in einem späteren Abschnitt in der Datenverarbeitungskette korrigiert werden.
Die Bits werden dann entschachtelt (162), und die FEC-Codewörter werden auf Fehler überprüft (163), aber nicht korrigiert. Die Verschachtelungsfolge spielt in diesem Prozess eine wichtige Rolle. Die Standardverschachtelung aller ersten Bits, gefolgt von der aller zweiten Bits etc., wird nur dann dazu führen, dass das erste oder das letzte Codewort fehlerhaft ist, wenn der Bittakt um bis zu 12 Bits fehlerhaft ist. Dadurch wird der Einsatz von Fehlererkennung zum Ausrichten des Bittaktes zum Lokalisieren der korrekten Daten nutzlos. Das in diesem Fall eingesetzte Verschachtelungsschema vermischt die Daten in ausreichender Weise, und einzelne Bitverschiebungen führen dazu, dass alle Codewörter fehlerhaft sind.
Die Anzahl der korrekten Codewörter wird gezählt und gespeichert. Der Bittakt wird daraufhin um 64 Mikrosekunden verschoben (verzögert), und der Prozess der Verzögerungscodierung 161, der Entschachtelung 162 und der Fehlererkennung 163 wird wiederholt (164). Bei der vorliegenden beispielhaften Ausführungsform erfolgt dies 12-mal, um den gesamten Bereich von 800 Mikrosekunden an möglichen Verzögerungen abzudecken. Die decodierten Daten 165 an dem Taktoffset, das über die meisten korrekten Codewörter verfügt, wie durch diese Verarbeitung durch den Netzwerk-Hub 11 der Verfolgerdaten des Fahrzeugs 17 in den empfangenen RF-Signalen festgestellt, werden für die Übertragung an den NDC-Server 42 gebündelt (3).
Der Server 42 empfängt in jeder Sekunde Daten für alle 50 Zeitschlitze von allen Netzwerk-Hub-Empfängern. Das Netzwerk ist so ausgelegt, dass mehrere Hubs jede einzelne Verfolgerdatenübertragung empfangen. Diese redundanten Daten werden durch den Server unter Verwendung eines Raum-Diversity-Wählalgorithmus verknüpft, der die Zuverlässigkeit der empfangenen Daten erhöht. Ein Ablaufdiagramm des Raum-Diversity-Algorithmus des NDC-Servers 42 wird in 22 dargestellt, wobei dieser Algorithmus für jeden der 50 Zeitschlitze in jeder Periode von einer Sekunde ausgeführt wird.
Jedes Verfolgerpaket verfügt über 12 Codewörter. Der Server setzt den FEC-Code ein, um Fehler in den durch jeden Hub bereitgestellten Codewörtern zu erfassen. Wenn zumindest 6 der 12 Codewörter fehlerfrei sind (170), wird das Paket zur weiteren Verarbeitung zurückbehalten (171). Es wird angenommen, dass, wenn die meisten Codewörter Fehler aufweisen, die Wahrscheinlichkeit einer erfolgreichen Rückgewinnung von gültigen Daten aus dem gesamten Paket gering ist. Sobald alle wahrscheinlich gültigen Pakete für den Zeitschlitz erfasst worden sind (172), wird einer von zwei Verarbeitungswegen gewählt.

Wenn der Zeitschlitz für das periodische Berichten definiert ist (173), wird der Diversity-Wählalgorithmus angewandt, wie in dem Verarbeitungswerg 174 angezeigt. Die in der ersten Phase erfassten Pakete werden bitweise unter Verwendung der durch den Hub berichteten, empfangenen Signalstärke als ein Gewichtungsfaktor (175) summiert. Die Signalstärke wird als ein Zeichen der Wahrscheinlichkeit verwendet, dass die Nachricht erfolgreich empfangen worden ist. Gesetzte Bits in dem Nachrichtenpaket werden unter Verwendung der positiven Signalstärke zu der Summe addiert; gelöschte Bits werden unter Verwendung der negativen Signalstärke zu der Summe addiert (176). Als einfaches Beispiel betrachten wir die drei unten stehenden Bitfolgen mit ihren entsprechenden Signalstärken. Nach dem Addieren werden Bits mit positiven Summen als gesetzte Bits decodiert, und Bits mit negativen Summen werden als gelöschte Bits decodiert. Wenn ein Paket ein Bit mit einer Summe von Null (einer Ergebnisgleichheit) enthält, wird das Paket verworfen.

Bit	01234567
Paket A:	11001010	Signalstärke: 100
Paket B:	11011110	Signalstärke: 30
Paket C:	11001110	Signalstärke: 80

Wählergebnisse:

Bit 0:	+100 + 30 + 80 = +210 > 0 => 1
Bit 1:	+100 + 30 + 80 = +210 > 0 => 1
Bit 2:	–100 – 30 – 80 = –210 < 0 => 0
Bit 3:	–100 + 30 – 80 = –150 < 0 => 0
Bit 4:	+100 + 30 + 80 = +210 > 0 => 1
Bit 5:	–100 + 30 + 80 = +010 > 0 => 1
Bit 6:	+100 + 30 + 80 = +210 > 0 => 1
Bit 7:	–100 – 30 – 80 = –210 < 0 => 0
Gewähltes Paket: 11001110

Nach dem Wählen wird eine Vorwärtsfehlerkorrektur auf das Ergebnis angewandt, um die verbleibenden Fehler in den Codewörtern zu korrigieren (177). Der (12,8)-Code ermöglicht das Korrigieren eines Fehlers in jedem Codewort. Jedes Paket enthält einen CRC-Code (CRC – cyclic redundancy check – zyklische Redundanzprüfung) von 8 Bit oder von 16 Bit, um zu überprüfen, dass das Paket wahrscheinlich keine Fehler aufweist (178); es ist jedoch immer noch möglich, dass das Paket Bitfehler enthält. Die abschließende Prüfung der Daten besteht in dem Überprüfen der Plausibilität der in dem Paket enthaltenen Daten, und wenn dies der Fall ist, wird das Paket gespeichert (179). Wenn ein Zeitschlitz nicht zum periodischen Berichten definiert ist, steht er jedem Verfolger zum Senden eines „Netzwerkeintrittsanforderungs"-Paketes zur Verfügung, um einen Haupt- oder Hilfsberichts-Intervallschlitz zu erhalten. Fahrzeuge 17 (3), die sich nahe beieinander befinden und gleichzeitig senden, werden nahezu sicher gegenseitig ihre Übertragungen korrumpieren. Wenn sie weit von einander entfernt sind, können ihre Verfolgerdatenpakete zuverlässig von den Hubs 11-1, 11-2, ..., 11-i, in der Nähe eines jeden Fahrzeugs empfangen werden. Der Server 42 verarbeitet Pakete in diesen Schlitzen einzeln. Anstatt den Diversity-Wählalgorithmus einzusetzen, verfährt die Verarbeitung gemäß dem Weg 180 (22). Netzwerkeintrittspakete enthalten redundante Daten zusätzlich zu der CRC, wodurch dem Server ermöglicht wird festzustellen, ob das Paket mit einem hohen Maß an Sicherheit gültig ist. Hier wird keine Wahl ausgeführt, sondern es werden Vorwärtsfehlerkorrektur- (181) und CRC-Prüfungen (182) ausgeführt, gefolgt von einer Bestimmung der Datenpaketgültigkeit aus den redundanten Daten in dem jeweiligen „Netzwerkeintrittsanforderungs"-Paket (183). Wenn durch dieses Verarbeitungsschema festgestellt wird, dass das Datenpaket gültig ist, wird es im Speicher (184) gespeichert.
VII. Verfolger und Verfolgersoftware
Die Hauptfunktionen des jeweils in allen Fahrzeugen eingebauten Verfolgers sind Navigation und Funkkommunikation. Seine untergeordneten Aufgaben sind das Unterstützen der Benutzerschnittstelle des mobilen Datenendgerätes (MDE), diskrete und analoge Datenerfassung und die Leistungssteuerung seiner selbst und der Peripheriegeräte. 23 ist eine kennzeichnende Abbildung einer beispielhaften Anordnung des Verfolgers 135, des MDE 190 und von Antennen (einschließlich einer FM-Empfangsantenne 191, einer UHF-/FM-Antenne 192 und einer GPS-Antenne 193) in einem typischen Flottenfahrzeug 195 (dargestellt zum Beispiel als Betonmischmaschine). Wie dargestellt wird, ist das Fahrzeug 195 des Weiteren so ausgestattet, dass es verschiedene Sensoren für das Berichten von Ereignissen aufnimmt, die unten stehend in einem weiteren Abschnitt dieser Patentschrift beschrieben werden.
Es wird ein flexibles, aber effizientes Echtzeit-Ausführungssteuerprogramm eingesetzt, um die Hauptfunktionen des Verfolgers zu unterstützen. Vor der Beschreibung des Echtzeit-Ausführungssteuerprogramms wird jedoch Bezug auf ein vereinfachtes Blockschaltbild des in 24 dargestellten Verfolgers (des Verfolgungscomputers) 135 genommen. Er besteht aus zwei Hauptleiterkarten oder -abschnitten, einem CPU-Abschnitt 200 und einem drahtlosen Netzwerkschnittstellenabschnitt oder HF-Abschnitt 201. Der CPU-Abschnitt 200 enthält die Stromversorgungseinheiten für den Verfolger, den Hauptmikroprozessor (die Zentraleinheit oder CPU) 203 zum Ausführen jeglicher Datenverarbeitung, einen GPS-Chipsatz (einschließlich einer HF-Front-End-Komponente, GP2010, und einer Korrelationskomponente, GP2021, eines beispielhaften Plessey-Chipsatzes), der mit einem Prozessor für den Empfang und das Decodieren von GPS-Satellitensignalen integriert ist, und Sensorelektronik und -schnittstellen. Der CPU-Abschnitt 200 führt die Navigation aus (teilweise durch den GPS-Navigationsabschnitt 204, aber auch durch Sensoren für Koppelnavigation und/oder Positionsbestimmung durch Kartenvergleich oder andere Navigationssensoren über Eingaben in die CPU 203) sowie Datenverarbeitung und Sensorverarbeitung durch die CPU 203.
Koppelnavigation in einer Landfahrzeugumgebung erhält eine stabile Navigationslösung aufrecht, wenn GPS-Daten möglicherweise als Folge von Satellitenmaskierung in Tunneln oder durch hohe Gebäude während der Fahrt des Fahrzeugs oder an einem Einsatzort nicht verfügbar sind. Ein Kreisel (ohne Abbildung) ist in das Verfolgergehäuse eingebaut, um die Winkelgeschwindigkeit in der Hochachse zu erfassen. Der Verfolgungscomputer, der die Winkelgeschwindigkeit zum Beurteilen des Kurses des Fahrzeugs einsetzt, ist darüber hinaus mit einem Fahrzeuggeschwindigkeits-Sensorausgang und mit dem Rücklicht gekoppelt, um anzuzeigen, ob die erfasste Geschwindigkeit nach vorwärts oder nach rückwärts gerichtet ist. Der Geschwindigkeitssensor ist ein wesentlicher Bestandteil anderer Sensormessfunktionen, die auf der Ausgabe der zurückgelegten Entfernung oder der Überprüfung, ob das Fahrzeug steht oder sich mit geringer Geschwindigkeit bewegt, beruht.
Wie des Weiteren im Zusammenhang mit einer nachfolgenden Abbildung erörtert wird, werden drei Netzteile (im Allgemeinen bezeichnet durch Block 205) auf der CPU-Karte 200 bereitgestellt, darunter ein Netzteil mit 12 VDC, das die HF-Karte mit Leistung versorgt, ein zweites Netzteil mit 12 VDC, das das MDE und andere Peripheriegeräte der Einheit einschließlich Sensoren mit Leistung versorgt, und ein drittes Netzteil mit 5 VDC für die Verarbeitungsfunktionen der CPU 203.
Der HF-Abschnitt bzw. die HF-Karte 201 enthält die Hochfrequenzschaltungen (einschließlich der Empfänger 207 und 208, die jeweils Eingaben von den in ein Fahrzeug eingebauten Antennen 191 und 192 empfangen), die für den Empfang und die Demodulation von über den FM-Unterträger von der Funkstation 12 empfangenen Hochfrequenzdaten erforderlich sind. Der HF-Abschnitt 201 enthält darüber hinaus Schaltungen (in dem Sender 210), die für die Modulation und Verstärkung zum Senden von Daten in dem UHF-Band unter Verwendung des TDMA-Netzwerkprotokolls erforderlich sind. Die HF-Karte führt jedoch keine eigene Datenverarbeitung aus. Vielmehr ist die Haupt-CPU 203 für jegliche Basisband-Datenverarbeitung für Nachrichtendecodierung und -codierung, Vorwärtsfehlerkorrektur und Datentaktung in dem Verfolger 135 zuständig.
Im Hinblick auf Verfolgersoftware ist es mit Bezug auf das Echtzeit-Ausführungssteuerprogramm, das zum Unterstützen der Hauptfunktionen des Verfolgers eingesetzt wird, nützlich, noch einmal festzustellen, dass die in jedem Verfolger und Netz-Hub eingesetzten CPUs im Wesentlichen übereinstimmen. Die Netz-Hub-CPU 82, die in dem vereinfachten Blockschaltbild in 29 erläutert wird, stellt zum Beispiel einen Mikroprozessor 68332 von Motorola mit zugehörigen Peripheriegeräten auf dem Chip, wie zum Beispiel eine TPU, eine QSPI und eine SCI, und ein damit verbundenes Schieberegister dar, wie sie bevorzugt die CPU bilden. Die Verfolger-CPU 203 stimmt damit überein. Sie verfügt über zwei periodische Interruptquellen für die Aufgabenplanung und Abfertigung, und zwar einen Akkumulator-Interrupt (ACCUMINT) von der GP2021 und einen von dem CPU-Takt abgeleiteten Zeitgeberbaustein (periodic interrupt timer – PIT). Der ACCUMINT wird zum Betreiben eines einfachen Echtzeit-Fahrzeugabfertigers mit hoher Priorität eingesetzt, während der PIT eingesetzt wird, um ein langsameres, prioritätsorientiertes Steuerprogramm für Langzeitnavigation und -Kommunikationsaufgaben zu betreiben.
Die Interruptpriorität ist wie folgt:

1. TPU Ebene 6

2. SCI Ebene 4

3. ACCUMINT Ebene 3

4. PIT Ebene 2
Der ACCUMINT-Interrupt betreibt einen periodischen Verteiler mit hoher Priorität für Aufgaben von kurzer (< 1 ms) Dauer. Die TPU-Interrupts treten durch TPU-Ereignisse auf, die mit der Netzwerkkommunikation und dem Netzwerktakt verbunden sind. Der PIT betreibt einen untergeordneten Interrupt mit geringem Datenfluss und notwendigerweise der niedrigsten Priorität, da er nur aktiviert werden kann, wenn der ACCUMINT-Interrupthandler (interrupt service routine – ISR) beendet ist. Die SCI erzeugt UART-Interrupts aus der seriellen Kommunikation mit dem Kompass oder anderen Peripheriegeräten. Die QSPI wird für Fahrzeugsendedaten eingesetzt, muss zwei Mal während einer Fahrzeugübertragung bedient werden und erzeugt keine Interrupts. Die TPU- und SCI-Interrupthandler sollten so schnell wie möglich sein.
Der ACCUMINT wird durch den GP2021 bereitgestellt und wird von dem TCXO mit 10 MHz abgeleitet, der darüber hinaus den Prozessortakt von 20 MHz (ebenfalls von dem GP2021) antreibt. Die ACCUMINT-Rate ist nominal für eine ungefähre Rate von 2.048,131 Hz programmiert (die Periode beträgt 488,25 μs). Dies ist eine Abweichung um 64 ppm von einer genauen Rate von 2.048 Hz. Der ACCUMINT kann durch Schreiben in ein GP2021-Register deaktiviert und reaktiviert werden. Das Zeitgeber-Tick-Flag (TIC) des GP2021, das für eine Rate von 8 Hz programmiert ist, steuert, wann GPS-Messdaten verfügbar sind, und wird eingesetzt, um Koppelnavigations-Verarbeitung zu terminieren.
Die Struktur des ACCUMINT-Handlers/Echtzeit-Verteilers wird wie folgt dargestellt:
Bei der Verfolgungsschleifenimplementierung der vorliegenden beispielhaften Ausführungsform erfordern die Aufgaben des Lesens der Akkumulatordaten und des Aktualisierens der Verfolgungsschleifen im Durchschnitt ungefähr 160 μs für 8 Kanäle. Dies schließt die Datenerfassung und -demodulierung für alle Kanäle und den Verfolgungsschleifenschluss für einen Kanal ein. Jeder Kanal erzeugt Akkumulationsdaten in Intervallen von 1 ms (ungefähr jeden zweiten ACCUMINT). Es ist wichtig, dass die Verfolgungsschleifen-Aktualisierungsverarbeitung für jeden Kanal abgeschlossen ist, bevor neue Akkumulationsdaten für diesen Kanal zur Verfügung stehen.
Das Steuerprogramm startet auf die Netzwerk-Zeitkontrolle und -Kommunikation bezogene Aufgaben, wie das Lesen und Speichern von GPS-Messdaten, periodische Aufgaben, die A/D- und diskrete E/A-Verarbeitung, Synthesizerprogrammierung und andere Aufgaben mit hoher Priorität und kurzer Dauer (weniger als 500 μs).
Ein TIC-Flag wird durch den GP2021 erzeugt und zeigt an, wann GPS-Messdaten übernommen worden sind. Die Standard-TIC-Rate beträgt ungefähr 10 Hz. Für den Verfolger wird die Rate auf ungefähr 8 Hz (eine Periode von 0,125000050 s) programmiert, und sie wird eingesetzt, um Kilometerzähler-/Raddrehzahlsensor-Daten zusätzlich zu den GPS-Messdaten zu übernehmen. Die Rate von 8 Hz ermöglicht einfache Zweierpotenz-Arithmetik für Zeitintervalle und verringert die Messverarbeitung um 20%. GPS-Verarbeitungsfunktionen müssen die TIC-Rate periodisch mit der GPS-Zeit halten, es ist jedoch (bei dem Verfolger) nicht erforderlich, den TIC an der ganzzahligen GPS-Sekunde auszurichten. Als Teil der Navigationsverarbeitung wird die TIC-Periode für einzelne TICs so angepasst, wie es für das Aufrechterhalten einer durchschnittlichen TIC-Rate von 0,125 Sekunden mit Bezug auf die GPS-Zeit erforderlich ist. Der ACCUMINT-Verteiler aktualisiert das TIC-Intervall so, wie es für die Navigationsverarbeitung erforderlich ist.
Der GP2021-Chip verfügt über zwei UARTs, die keine Interrupts erzeugen, so dass sie abgefragt werden müssen. Jeder UART verfügt über einen FIFO (first in, first out – zuerst hinein, zuerst hinaus) von 8 Byte. Wenn die Datenrate an den UARTs auf 38,4 kbps begrenzt wird, kann der FIFO ungefähr alle 2 ms gefüllt werden. Die CPU kann jeden UART während jedes zweiten ACCUMINT bedienen, ohne Daten zu verlieren. Einer der UARTs wird zum Kommunizieren mit dem MDE eingesetzt; und der andere kann für ein geeignetes Peripheriegerät eingesetzt werden.
Zeitkritische HF-Kommunikationsaufgaben werden nach Bedarf ausgeführt, was das Einrichten der TPU-Kanäle wie folgt umfasst:

• Datentakte starten und stoppen
• die QSPI starten und stoppen
• den Sender ein- und ausschalten
• die TPU so programmieren, dass sie das nächste Bit-Sync erfasst

Die Terminierung dieser Aufgaben erfordert in einigen Fällen einige Millisekunden Auflösung.
Der Verfolger setzt die QSPI für die Nachrichtenübertragung ein. Die Sendedaten werden im Miller-Format liniencodiert, was das Senden von 288 Codebits bei 15.625 bps für ein Äquivalent von 144 Datenbits bei 7.812,5 bps erfordert. Der QSPI-Ausgabepuffer kann 256 Bits halten, so dass die QSPI mit 256 Bits vorgeladen und dann einige Millisekunden später mit dem Rest der Nachricht neu gefüllt werden kann. Ein zusätzliches Datenwort (für insgesamt 304 Bits) muss an die HF-Karte ausgetaktet werden. Eine Präambel von 8 Bits geht den Daten voraus, und 8 Bits folgen auf die Daten, nachdem der Sender abgeschaltet worden ist, um sicherzustellen, dass das letzte gesendete Datenbit niedrig ist.
Der Verfolger setzt die TPU ein, um die Daten in externe Verschieberegister für Empfangsdaten einzutakten. Zwei FM-Datenströme werden von räumlich getrennten Antennen empfangen. Die Daten werden im Miller-Format liniencodiert, was erfordert, dass 9.200 Codebits mit ungefähr 9.328,36 bps für ein Äquivalent von 4.600 Datenbits mit ungefähr 4.664,18 bps gesendet werden. Eine Präambel und ein Synchronisationsmuster von 64 Bits gehen den Daten voraus. Die beiden Datenströme werden synchron getaktet, aber unabhängig verarbeitet. Die Bytes werden aus dem Schieberegister auf der fallenden Flanke des Latchtaktes gelesen, wobei 428,8 μs zum Lesen der Daten verbleiben.
Mit Bezug auf Datenerfassungsaufgaben melden TIC-Ereignisse, dass GPS-Messdaten von dem GP2021-Korrelator verfügbar sind. Wenn diese auftreten, muss der Prozessor die Daten vor dem nächsten TIC (ungefähr 125 ms) lesen. Der Prozessor liest darüber hinaus Rad-/Kilometerzählerdaten. In dem ISR werden Daten nur gespeichert – die Datenverarbeitung findet unter Steuerung des PIT-Steuerprogramms statt.
Die Verfolgersoftware hat darüber hinaus eine Reihe von periodischen Aufgaben von kurzer Dauer, die durch den ACCUMINT-Verteiler ausgeführt werden können. Diese umfassen A/D-Funktionen zum Lesen von Daten von dem Kreisel und anderen Datenquellen; ebenso wie Bitumschaltung zum Implementieren von einfachen seriellen Schnittstellen zum Programmieren von HF-Kartensynthesizern und des für die Leistungssteuerung des Verfolgermoduls eingesetzten PIC.
Die TPU wird für die Abstimmung von HF-Kommunikation, für das Takten des HF-Dateneingangs und -ausgangs und für die Eingänge von Fahrzeug-Raddrehzahl- oder Geschwindigkeitssensoren. Wie zuvor hier beschrieben, werden die TPU-Kanäle (16) und -Funktionen in Tabelle 56 (Anhang B) zusammengefasst.
Bei der Verarbeitung von Raddrehzahl- und Geschwindigkeitssensor-Eingaben aus der Koppelnavigation des PROTRAK-Systems zählt die TPU Impulse von diesen Sensoren zum Messen der Fahrzeuggeschwindigkeit. In der TPU werden die Kanäle 13 und 14 für Quadratureingaben von den Raddrehzahlsensoren reserviert, die Kanäle 12 und 15 werden für die Eingaben des Fahrzeugfahrtrichtungssensors und des Geschwindigkeitssensors der Geschwindigkeitssteuerung reserviert, Kanal 15 führt eine ITC-Funktion aus, und Kanal 12 führt eine diskrete Eingabefunktion aus. Bei den meisten Systemen wird ein Geschwindigkeitssensor für die Geschwindigkeitssteuerung eingesetzt.
Der SCI-UART des Prozessors 68332 von Motorola wird für eine Magnetkompassschnittstelle oder eine andere Einrichtung mit relativ geringer Datenrate (4.800-9.600 bps) eingesetzt. Während des Betriebs erzeugt die SCI Sende- oder Empfangsinterrupts in Intervallen von ungefähr 1 ms (bei 4.800 bps). Diese Interrupts müssen innerhalb 1 ms bedient werden.
Der PIT des Prozessors läuft mit 32 Hz, und in diesem Modus führt der PIT-ISR ein priorisierendes Ausführungssteuerprogramm aus, das die folgenden Aufgaben in der folgenden Rangfolge ausführt:

1. Kommunikations- und HF-Takt-/Terminierungsaufgaben
2. FM-Datenfehlerdecodierung
3. Koppelnavigation (Dead reckoning – DR; Lösungsausbreitung mit 8 Hz)
4. FM-Datenanalyse
5. GPS-Messverarbeitung (Pseudobereichs-/Abstandsänderungs-Messungen, Satellitenerfassung)
6. Verknüpfte GPS-/Koppelfilterung (Kalman-Filteraktualisierung der Koppelnavigationslösung)
7. GPS-Satellitensichtbarkeits-/Kanalzuweisung

Für das Ausführungssteuerprogramm werden die Aufgaben periodisch oder auf Anforderung nach Priorität terminiert. Aufgaben mit hoher Priorität wird ermöglicht, Aufgaben mit niedrigerer Priorität zu unterbrechen.
Die Netzteilarchitektur für den Verfolger 135 umfasst vier unabhängige Netzteile, die mit Eingangsbatterieleistung (6-28 V) betrieben werden. Mit Bezug auf die 25 und 26, bei denen es sich um Blockschaltbilder der internen Leistungsverteilung zu dem Verteiler bzw. eine Übersicht über die Leistungsverteilung handelt, ist eines dieser Netzteile ein lineares Netzteil 215 mit 5 V, das den Mikrochip-Mikrocontroller PIC^TM (μC) 216 mit Leistung versorgt, der für die Hauptleistungssteuerung des Verfolgers eingesetzt wird. Sie hält darüber hinaus die Versorgung des SRAM (ohne Abbildung) mit Leistung aufrecht, so dass der Gerätezustand erhalten bleibt, während der Prozessor ausgeschaltet ist.
Der Mikrocontroller 216 wird mit sehr schwachem Strom betrieben und ist stets eingeschaltet, wobei er ein CPU-Netzteil 217 mit 5 V und ein Funknetzteil 218 mit 12 V steuert. Das Netzteil 217 mit 5 V ist ein Schaltnetzteil, das die CPU 203, die digitale Elektronik und den GPS-Empfänger 204 des CPU-Abschnitts 200 mit Leistung versorgt. Das Funknetzteil 218 mit 12 V versorgt die HF-Karte 201 mit Leistung und versorgt darüber hinaus den rauscharmen Verstärker (low noise amplifier – LNA) 219 der GPS-Antenne durch einen linearen Regler 220 mit 5 V. Da der TCXO, der letztlich den CPU-Takt steuert, sich auf der HF-Karte 201 befindet, ist es für die CPU 203 erforderlich, dass sowohl dieses Netzteil (218) als auch das CPU-Netzteil 217 mit 5 V eingeschaltet sind. Das letzte der vier unabhängigen Netzteile ist ein Hilfsnetzteil 222 mit 12 V, das eine geregelte Leistung mit einer Spannung von 12 V an alle externen Peripheriegeräte (z. B. das MDE 190, den Kompass 230 und andere 232, 26), wie durch 223 (in 25) bezeichnet, und das Leistung an einen Bordkreisel 224 durch einen linearen Regler 225 von 5 V liefert. Die CPU 203 steuert dieses Hilfsnetzteil 222 mit 12 V. Der Verfolger empfängt darüber hinaus eine diskrete Eingabe 226 von 12 Volt in die CPU 203 und den Mikrocontroller 216, wodurch angezeigt wird, dass der Zündschalter 233 sich in der Position RUN/ACC befindet.
Der Mikrocontroller 216 steuert die Leistung für den Verfolger 135 und bleibt, zusammen mit dem SRAM der CPU, stets eingeschaltet. Diese beiden nehmen weniger als 5 mA Strom auf. Wenn die diskrete Eingabe anzeigt, dass der Zündschalter auf der Position RUN oder ACC steht, schaltet der Mikrocontroller 216 die CPU 203 und die Netzteile 217 und 218 ein. Wenn die Zündung ausgeschaltet ist, kann die CPU 203 den Mikrocontroller 216 anweisen, die Leistung während Zeitintervallen zwischen 5 und 630 Minuten oder bis die Zündung eingeschaltet wird, auszuschalten, je nachdem, was zuerst auftritt.
Der Verfolger 135 unterstützt Energiesparmodi, so dass die Leistungsaufnahme der Fahrzeugbatterie minimiert wird, wenn die Fahrzeugzündung ausgeschaltet wird, und die darüber hinaus Auswirkungen auf die Funknetzsteuerung und den Datenerhalt haben. Die Energiesparmodi des Verfolgers sind wie folgt:

• Alles ein: Der Verfolger 135 und die externen Peripheriegeräte sind eingeschaltet und arbeiten normal.
• Peripheriegeräte aus: Der Verfolger 135 ist eingeschaltet und arbeitet normal, das periphere Hilfsnetzteil 222 mit 12 V ist jedoch ausgeschaltet. Die Peripheriegeräte werden unverzüglich ausgeschaltet oder, falls gewünscht, innerhalb einer vorgegebenen Zeit T1, z. B. 1-2 Minuten nach dem Ausschalten der Zündung, was die DR-Navigation verhindert, da sowohl der interne Kreisel 224 als auch der externe Kompass 230 ausgeschaltet sind.
• Schlaf: Die CPU 203 wird bei ausgeschalteter Zündung während einer vorher festgelegten Zeitdauer T2 (z. B. ungefähr 40 Minuten) ausgeschaltet. Wenn die CPU wieder eingeschaltet wird (Modus „Peripheriegeräte aus"), kann sie nach neuen Nachrichten oder anderen Daten horchen, antworten und sich dann wieder ausschalten. Der Schlafmodus ermöglicht reinen Anmeldungs- und kontinuierlichen Verfolgungssystemen, Daten von der Bedienstation zu empfangen, während die Zündung ausgeschaltet ist. Reine Abfragefahrzeuge bleiben im Schlafmodus und wachen erst auf, wenn die Zündung eingeschaltet ist. Das System bleibt auch dann im Schlafmodus, wenn die Batteriespannung unter eine vorgegebene untere Grenze fällt.
• Aus: In diesem Modus wird keine Leistung an den Verfolger angelegt.

Abhängig von spezifischen Benutzeranforderungen kann die Steuerung des Energiesparmodus des Verfolgers variieren, z. B.:

• Bediener von Notfahrzeugen ziehen es möglicherweise vor, dass das System sich stets im Modus „Alles ein" befindet, um zu ermöglichen, dass die CCS jederzeit (über das TDMA-Netzwerk) mit dem Fahrzeug kommunizieren kann.
• Einige Benutzer ziehen möglicherweise einen abgestuften Energiesparansatz vor, bei dem die Fahrzeuge, die periodisch ein- und ausgeschaltet werden, wie zum Beispiel Lieferwagen, in dem Netzwerk verbleiben, während sie ausgeschaltet sind.

27 ist ein Schaubild, das die Logik für den Energiemoduszustands-Übergang des Verfolgers 135 darstellt. Die Zeitdauer T1 und die Zeitdauer T2 werden wie gewünscht eingestellt. Die Schlafzeit ist die durch die CPU angewiesene Nebenzeit für den Schlafmodus 240. Die Modusübergänge und der netzwerkbezogene Betrieb in allen Modi sind wie folgt:
Der Aus-Zustand 241 wird erreicht, wenn eine externe Batterieleistung von dem Verfolger entfernt wird. Wenn Batterieleistung an den Verfolger angelegt wird, wird der Leistungssteuerung-Prozessor (der Mikrocontroller 216) zurückgesetzt, und er schaltet das CPU-Netzteil (CPU 203) und das Funknetzteil 218 ein, wodurch der Verfolger eingeschaltet wird, lässt aber die Peripheriegeräte 223 ausgeschaltet (Modus 242).
Im Modus „Alles ein" (243) werden die HF- und CPU-Abschnitte 201 und 200 eingeschaltet. Das System navigiert und arbeitet normal in dem HF-Netzwerk. Verfolgern für kontinuierliche Verfolgung (Continuous Track – CT) werden periodische Sendeschlitze zugewiesen. Verfolgern für reine Anmeldungsverfolgung (Login-Only Track – LOT) werden periodische Sendeschlitze zugewiesen, wenn der jeweilige Kunde angemeldet ist. Wenn kein Kunde (d. h. ein Flottenteilnehmer oder -besitzer) angemeldet ist, versuchen diese Einheiten bisweilen, in das Netzwerk einzutreten, oder sie bleiben ruhig, bis sie durch das NDC informiert werden, dass ihr Kunde sich angemeldet hat. Reine Abfrageverfolger versuchen einen Netzwerkeintritt und bleiben dann ruhig, bis sie aufgefordert werden zu senden.
Wenn die Zündung ausgeschaltet wird, werden durch den Verfolger angetriebene Peripheriegeräte (z. B. das MDE 190, der Magnetkompass 230, falls angeschlossen, etc., und der interne Kreisel 224 (optional)) unverzüglich oder nach Ablauf der Zeitdauer T1 ausgeschaltet (Modus 242). Der Kompass- und der Kreiselnavigationssensor werden auf Basis der Annahme ausgeschaltet, dass sich das Fahrzeug nicht bewegt, wenn die Zündung ausgeschaltet ist. Der Verfolger kehr zu dem Modus 243 „Alles ein" zurück, wenn die Zündung wieder eingeschaltet wird.
Aus dem Modus 242 „Peripheriegeräte aus" können die LOT- und CT-Verfolger nach einer Zeitdauer von T2, seitdem die Zündung ausgeschaltet worden ist, in den Schlafmodus 240 eintreten. Um den Schlafmodus zu erreichen, fordert der Verfolger einen periodischen Niedrigenergie-Netzwerkschlitz von dem NDC an, der über ein langes Sendeintervall verfügt. Wenn ein Schlitz gewährt wird, speichert der Verfolger die erforderlichen Daten in einem Bereich in dem SRAM, speichert alle Daten nach Bedarf in einem Flash-Speicher und fordert den Mikrocontroller 216 auf, die CPU 203 für eine Schlafperiode auszuschalten, die einige Minuten kürzer ist als das Niedrigenergie-Sendeintervall. Reine Abfrageverfolger fordern eine Niedrigenergie-Abschaltung von dem NDC an. Wenn die Abschaltanforderung quittiert oder unterbrochen wird, speichert der Verfolger Daten in dem SRAM und dem Flash-Speicher, falls erforderlich, und befiehlt dem Mikrocontroller 216, die CPU 203 auszuschalten, bis die Zündung wieder eingeschaltet wird.
Wenn der Mikrocontroller 216 den Verfolger (eigentlich die CPU 203) aus dem Schlafmodus 240 aufweckt, überprüft die CPU die Batteriespannung und den in dem SRAM gespeicherten vorherigen Systemzustand. Wenn sich der Verfolger in einem Niedrigenergie-Schlitz befindet, hört er die FM-Unterträger-Daten während eines Fensters von 3-4 Minuten um die Schlitzzeit herum ab, um festzustellen, ob das NDC für ihn bestimmte Informationen sendet. Zu diesem Zeitpunkt hat das NDC die Gelegenheit, die Verfolgernachricht oder andere Daten zu senden. Sobald alle Netzwerktransaktionen abgeschlossen sind, befiehlt der Verfolger dem Mikrocontroller erneut, die CPU auszuschalten.
Wenn die Zündung während einer vorgegebenen Zeitdauer ausgeschaltet bleibt oder die Batteriespannung unter die Mindestschwelle V_MIN fällt, fordert der Verfolger bei seiner nächsten Sendegelegenheit eine Niedrigenergie-Abschaltung von dem NDC an. Wenn die Abschaltanforderung quittiert oder unterbrochen wird, bekommt der Mikrocontroller 216 den Befehl, die CPU 203 nicht aufzuwecken, bis die Zündung wieder eingeschaltet wird.
Die Rückgewinnung des SRAM-Zustands wird wie folgt erreicht. Da der gesamte Inhalt der globalen Variablen und des globalen Stapels während des Schlafmodus 240 beibehalten wird, kann die CPU 203 einen bestimmten Punkt im Code neu starten, wobei alle Daten in intaktem Zustand sind. Dies kann erfolgen, wenn die Register, der Programmzähler und der Stapelzeiger auf dem Stapel abgelegt werden und der Stapelzeiger an einem bekannten Ort gespeichert wird. Eine CRC muss an angemessenen Teilen des SRAM ausgeführt werden, um die Datenintegrität beim Neustart sicherzustellen, wonach der CPU ermöglicht wird, einen Ausschaltbefehl an den Mikrocontroller zu senden. Nach dem Rücksetzen überprüft die CPU die CRC auf dem SRAM, um festzustellen, ob er neu gestartet ist. Wenn dies der Fall ist, setzt die Software geeignete Flags und fragt daraufhin den Stapelzeiger und die Register von dem Stapel ab. Sie ist dann in der Lage, an den Punkt zu springen, an dem sie sich vor dem Ausschalten befand. Wenn die CRC auf dem SRAM fehlschlägt, führt die CPU einen normalen Startvorgang aus.
Wenn der Verfolger eingeschaltet wird, muss der die SCC-Übertragung auf dem empfangenen FM-Unterträger suchen. Unter normalen Bedingungen verfügt der Verfolger über in einem Flash-Speicher gespeicherte Kanalinformationen, die der Haupt-FM-Kanal einsetzen soll, und durchsucht zunächst Kanäle und Unterträger, die er in dem Speicher gespeichert hat. Wenn keine SCC-Synchronisationsmuster gefunden werden, muss er systematisch alle FM-Kanäle und Unterträger durchsuchen. Zu diesem Zweck wird eine Bit-Sync-Suche durch Suchen nach einem vorgegebenen eindeutigen Synchronisationsmuster ausgeführt. Wenn das Bit-Sync-Ereignis verpasst wird (d. h., wenn nicht alle drei Impulse innerhalb des erwarteten Zeitfensters auftreten), wird keine neue Korrektur angewandt, und dem Takt wird ermöglicht, frei zu schwingen. Die Zeitschätzung wird weiterhin auf Basis der sich verändernden Entfernung zu dem Sender aktualisiert, wenn die Navigationsdaten gültig sind. Wenn das Bit-Sync fortdauernd über mehr als 20 Sekunden verpasst wird, kann der Fehler in der Zeitschätzung der ganzzahligen Sekunde nach außerhalb der zulässigen Grenzen abweichen. Wenn dies auftritt, muss die CPU die Bit-Sync-Suche in dem aktuellen und anderen verfügbaren FM-Kanälen fortsetzen.
Die Zeitgebung und die Taktgebung für den Empfang von FM-Daten durch den Verfolger (und den Netz-Hub) werden so verarbeitet, wie es durch das Zeitgebungs- und Taktgebungs-Schaubild in 28 angezeigt wird. Die Taktgebung der empfangenen FM-Daten 246 wird durch die CPU 203 so terminiert, dass es bei einem bestimmten TPU-Zeitgeberwert beginnt, der nicht direkt auf das FM-Daten-Synchronisationsmuster 247 bezogen ist, der aber auf die geschätzte Zeit der ganzzahligen Sekunde zuzüglich der geschätzten Lichtgeschwindigkeitsverzögerung 248 bezogen ist. Die Zeitgebung in der Abbildung wird in Einheiten von TPU-TICs von 5 MHz angezeigt. Die steigende Flanke der Taktverschiebung 250 hat zur Folge, dass Bits in ein externes Schieberegisters verschoben werden. Die steigende Flanke des Latchtaktes 252 übernimmt das empfangene Byte in der Ausgabe des Schieberegisters. Die CPU 203 empfängt einen Interrupt auf der fallenden Flanke des Latchtaktes zum Einlesen der Daten mit 428,8 μs zum Lesen des Byte.
Die Differenz 253 zwischen der Zeit des empfangenen Synchronisationsmusters und der Zeit, zu der es von der CPU erwartet wurde, wird in 28 in übertriebenem Maßstab dargestellt. Die Differenz 253 beträgt gewöhnlich weniger als 20 μs und wird verursacht durch die Fahrzeugbewegung, Taktfehler zwischen der SCC und dem Verfolger/Hub sowie durch Synchronisationsfehler und andere durch den FM-Empfänger verursachte Fehler. Die CPU 203 setzt die durchschnittliche Differenz für die drei Impulse ein, um ihre aktuelle Zeitschätzung der ganzzahligen Sekunde für die nächste Sekunde zu korrigieren.
Die Verfolger-UHF-Datenübertragung, Zeitgebung und Taktgebung werden so verarbeitet, wie es in dem Zeitgebungs- und Taktgebungs-Schaubild in 29 dargestellt wird. In dem Rahmen unmittelbar vor dem oder während des Rahmens, den der Verfolger senden soll, muss das Echtzeit-Ausführungssteuerprogramm die Aufgaben der Datenübertragung terminieren. Die Aufgaben werden so terminiert, dass sie mit einer angemessenen Vorlaufzeit (von bis zu 6,5 ms) ablaufen, um TPU-Aufgaben zu starten, um Ausgabezustands-Änderungen an den gewünschten TPU-Zeitgeberwerten zu erzeugen. Der Senderschlüssel und der serielle Datentakt sollten exakt gestartet und gestoppt werden. Die ersten 16 Bytes der Ausgabedaten werden in das QSPI-Schieberegister geladen, bevor die Übertragung beginnt, und der letzte Teil der Daten wird geladen, bevor die QSPI geleert wird. Die in 29 angegebenen Zeiten werden ebenfalls in Einheiten von TPU-Zeitgeber-Ticks von 5 MHz angegeben. Es kann erforderlich sein, dass der TPU-Kanal 3 Ausgabebits zählt, so dass der Datentakt und die QSPI allmählich gestoppt werden können.
Natürlich umfassen durch den Verfolger gesendete Daten Informationen zum Identifizieren des exakten Standortes oder der exakten Position des Fahrzeugs, in dem der Verfolger eingebaut ist. Wie zuvor hier vermerkt, setzt der Verfolger Hochleistungs-Koppelnavigation (dead reckoning – DR) ein, um Daten zur Fahrzeugposition und Geschwindigkeit in Straßenschluchten bereitzustellen, wo GPS-Messungen nur in Abständen verfügbar sind. Die DR-Sensoren umfassen eine Geschwindigkeitsmessung, die bei der vorliegenden beispielhaften Ausführungsform bevorzugt auf dem Geschwindigkeitssensor der Geschwindigkeitssteuerung basiert, falls verfügbar, sowie einen Azimutkreisel und möglicherweise einen Magnetkompass, die für die Feststellung des Kurses eingesetzt werden. Es kann ein Sensor für die Rückwärtsrichtung mit den Rücklichtern verbunden werden. Diese Sensoren werden durch den Einsatz eines Kalman-Filters auf Basis von DGPS-korrigierten rohen Messeingaben kalibriert. Das Genauigkeitsziel für den DR-Navigator beträgt 0,2% der zurückgelegten Entfernung (mit 95% Wahrscheinlichkeit) nach 4 Minuten DGPS-Messverfügbarkeit über einen „typischen" Bewegungsablauf eines Fahrzeugs.
Die DR-Algorithmus-Anforderungen berücksichtigen Folgendes: Bei der derzeit bevorzugten Ausführungsform beträgt die Aktualisierungsrate des DR-Navigationssystems ungefähr 8 Hz. Azimutkreiseldaten werden mit einer hohen Rate (ungefähr 100 Hz) abgetastet und integriert, um eine Schätzung des Kurses zu verbreiten. Daten des Geschwindigkeitssensors oder der Radimpulszahl werden mit hoher Priorität abgetastet, um regelmäßige Zeitbestimmungsintervalle bei 8 Hz sicherzustellen, und werden durch den Kurs umgewandelt und integriert, um eine Positionsschätzung zu verbreiten.
Die GPS-Messanforderungen umfassen von dem GPS-Abschnitt der Software verfügbare Pseudobereichmessungen bei 8 Hz. Diese Messungen werden abgetastet und nach Bedarf aufbereitet. Die GPS-Messungen werden durch einen Kalman-Filter eingesetzt, der in Intervallen von zwei Sekunden betrieben wird. Es wird entweder die letzte verfügbare Messung oder ein Mittelwert von bis zu der Aktualisierungszeit verfügbaren Messdaten eingesetzt. Die Kalmanfilteranforderungen erkennen, dass der zum Mischen der DGPS- und der Koppelnavigationsdaten einsetzte Kalman-Filter Sensorfehlerzustände mit ausreichender Genauigkeit unterstützen und schätzen muss, um die gewünschte Koppelnavigationsgenauigkeit zu erzielen. Darüber hinaus unterstützt der Kalman-Filter eine grobe Ausrichtung (die Kursfehlerunsicherheit ist größer als ein kleiner Winkel) und arbeitet, wenn einige unterstützende Sensoren (wie zum Beispiel ein Kompass) nicht angeschlossen sind.
Ein Rohmessfilter muss über dreidimensionale Positions- und Geschwindigkeits-Fehlerzustände und ein gutes Taktfehlermodell verfügen. Die Filterfehlerzustände umfassen:

• 3 Positionsfehler (NED)
• 3 Geschwindigkeitsfehler (NED)
• 1 Kurs- oder Abweichungswinkel-Fehlerzustand
• 2 oder 3 Taktfehlerzustände
• 2 Kreiselfehlerzustände (Fehler durch Signalverfälschung oder Skalenfaktorfehler)
• 2 Kilometerzähler-Fehlerzustände (Skalenfaktor und Skalenfaktor-Nichtlinearität)
• 1 Kompassausrichtungs-Fehlerzustand

Magnetkompasse weisen üblicherweise Fehlereigenschaften auf, die sinusförmig mit dem Kurs schwanken, so dass es wichtig ist, ein effizientes Verfahren zur Verarbeitung des variablen Kompassausrichtungsfehlers einzusetzen. Kompassfehler können außerhalb des Gefüges des Kalman-Filters verarbeitet werden. Der Prozessor verfügt über einen Temperatursensor, der für einen Temperaturausgleich des Kreisels eingesetzt werden kann.
Wenn das Navigationssystem eingeschaltet ist, kann es von der Position und dem Kurs aus initialisiert werden, die beim Ausschalten gespeichert wurden. Da diese Daten jedoch nicht völlig zuverlässig sind, müssen die anfänglichen Kovarianzen groß sein. Wenn das System über einen Magnetkompass verfügt, können Anfangsmessung davon durch nahe gelegene Magnetfelder korrumpiert werden. Der Filter muss in der Lage sein, einen „Grobausrichtungs"-Modus zu unterstützen, der üblicherweise den Einsatz von Fehlerzuständen mit sich bringt, die der Sinus und der Cosinus des Kurs-/Abweichungswinkelfehlers sind, da die Fehlerfortpflanzung linear zu diesen Begriffen ist. Sobald die Sinus- und Cosinusfehler klein sind, kann das System zu einem einzelnen Kursfehlerzustand umschalten.
Der Kalman-Filter verbreitet das Fehlermodell für den Koppelnavigationsprozess auf Basis der Kreisel- und Geschwindigkeits-Sensordaten. Es verbreitet darüber hinaus unterstützende Sensorfehlermodelle einschließlich GPS-Taktfehlern und Kompassausrichtungsfehlern. Zu den für den Filter verfügbaren Messungen gehören:

1) GPS-Pseudobereich
2) Missweisender Kompasskurs
3) Kreiselbias bei Geschwindigkeit Null

Messungen der Nullgeschwindigkeit (Winkelgeschwindigkeit Null) sind nur verfügbar, wenn das Fahrzeug angehalten wird.
Das Abschließen der Fehlerfortpflanzung und des Aktualisierungszyklus des Kalman-Filters erfordert mehr als eine Sekunde. Wenn die Filterverarbeitung beginnt, müssen Messdaten und Fehlermodellinformationen in Software übernommen werden, so dass die Ausbreitung der Koppelnavigationslösung mit 8 Hz in Echtzeit fortgesetzt werden kann, während der Filter die Daten des vorherigen Zyklus bearbeitet.
Die Zeitbestimmung der Koppelnavigations- und GPS-Messdaten ist entscheidend für eine erfolgreiche Navigation. Es werden Geschwindigkeitssensor-Impulszahlen und Kreiseldaten der Koppelnavigation abgetastet, so dass sie bei GPS-TIC-Ereignissen gültig sind. Die GPS-Rohmessungen sind bei den TIC-Ereignissen ebenfalls gültig, so dass die Zeitausrichtung auf einfache Weise durchgeführt werden kann.
Ein Teil der Kalman-Filterschätzung besteht in einem systematischen Fehler und einem Geschwindigkeitsfehler des Empfängertaktgebers (des Haupt-TCXO mit 10 MHz). Aufgrund dieses Fehlers und der Unfähigkeit, das TIC-Intervall exakt einzustellen, weicht das TIC-Intervall in Bezug auf die GPS-Zeit leicht von einer genauen Rate von 8 Hz ab. Es ist wünschenswert, diesen Fehler zu berücksichtigen und das TIC-Intervall regelmäßig anzupassen, um die Abweichung zu korrigieren.
Der Verfolger verfügt über mehrere analoge Eingänge, die durch einen Multiplex-A/D gemeinsam genutzt werden müssen. Der Analogeingang mit der höchsten Priorität ist der des Kreisels, der mit zwischen 50 Hz und 100 Hz abgetastet werden muss, wenn das Fahrzeug möglicherweise in Bewegung ist (d. h. zu jeder Zeit, wenn die Zündung eingeschaltet ist). Die Batteriespannung wird hauptsächlich überwacht, wenn die Zündung ausgeschaltet ist, um sicherzustellen, dass die Einheit die Batterie nicht leert. Mehrere externe analoge Sensoren können an den Verfolger angeschlossen werden, um kundenspezifische Informationen über Fahrzeugparameter bereitzustellen. Die Anforderungen für das Überwachen dieser Sensoren sind kundenspezifisch.
Die HF-Karte verfügt über einen Empfangssignalstärke-Indikator, der periodisch abgetastet wird, um die Stärke der FM-Unterträger-Übertragung festzustellen. Der Temperatursensor auf der CPU-Platine stellt noch ein weiteres analoges Signal dar, das für die Kreiselkalibrierung eingesetzt wird.
Die Verarbeitung der Parameterspeicherung stellt einen bedeutenden Aspekt dar. Die CPU-Karte des Verfolgers setzt einen Flash-Speicher für die Langzeitspeicherung der Parameter ein, wenn die Einheit ausgeschaltet oder vom Bordnetz getrennt wird. Der SRAM wird durch das Bordnetz gesichert, so dass die kurzfristige Speicherung des Gerätezustands im Schlafmodus intakt bleibt. Daten werden in dem Flash-Speicher täglich oder wöchentlich gespeichert, so dass ein Leistungsabfall nur zum Verlust der neuesten Daten führt.
Die CPU-Karte verfügt zum Beispiel über einen banklöschbaren Flash-Speicher von 512 Kbyte. Das Programm und die konstanten Daten belegen bevorzugt die untere Hälfte des Speichers, während die oberen 256 K für die Speicherung der Parameter reserviert sind. Ein Nachteil des Flash-Speichers besteht darin, dass die gesamte Vorrichtung nicht verfügbar ist, wenn Daten auf eine beliebige Bank geschrieben oder von ihr gelöscht werden, bis der Vorgang abgeschlossen ist. Da sich der Code in dem Flash-Speicher befindet, muss das Schreiben auf die Vorrichtung sorgfältig erfolgen. Der Code, der in den Flash-Speicher geschrieben wird, muss im RAM bei deaktivierten Interrupts ablaufen. Der Löschvorgang muss das Löschaufschiebe-Feature der Vorrichtung einsetzen. Dieses wird mit einer Interruptverarbeitung implementiert, während der Löschvorgang ausgeführt wird. In den meisten Fällen erfolgt das Beschreiben und Löschen des Flash-Speichers, wenn die CPU den Mikrocontroller anweist, ihn auszuschalten. Daher ist es unproblematisch, alle Interrupts zu deaktivieren, da keine Navigations- oder Funkkommunikation stattfindet.
Die Flash-Speichervorrichtung ist wortadressierbar (16-bit). Daten müssen wortweise an geraden Bytegrenzen in den Flash geschrieben werden. Bytes können jedoch an ungeraden Bytegrenzen gelesen werden.
Als Speicherverfahren wird bevorzugt ein lineares Dateispeichersystem (linearer Dateispeicher – Linear File Store – LFS) zum Speichern von Parameterdaten eingesetzt. Dieses Verfahren erzeugt eine verknüpfte Liste von Datensätzen, die erweitert wird, um einen Speicherblock zu füllen. Wenn der Block gefüllt ist, werden die Datensätze, die nicht für die Rückgewinnung gekennzeichnet sind, in einen neuen Block kopiert, und der alte Block wird gelöscht. Das Dateisystem muss Blöcke wiederherstellen, die durch einen Leistungsabfall während des Schreibens und der Rückgewinnung verloren gehen. Der LFS-Ansatz unterstützt die stabile Verarbeitung von auftretendem Leistungsverlust. In einem Flash-Speicher gespeicherte Datensätze sollten über eine CRC oder eine Prüfsumme verfügen, um sicherzustellen, dass die Daten gültig sind.
Parameterdaten werden in zumindest einer Flash-Speicherbank gespeichert und periodisch aktualisiert, wenn neue Informationen verfügbar werden. Der Flash-Speicher speichert die folgenden Datentypen:

1. GPS-Satellitenalmanachdaten für die Satellitenerfassung: Neue Almanachdaten werden wöchentlich gespeichert. Sie werden gelesen, wenn die CPU eingeschaltet wird, und geschrieben, wenn neue Daten von den Satelliten zumindest um eine Woche neuer sind als die gespeicherten Daten. Ein vollständiger Almanachsatz erfordert 2 K Speicher.
2. Informationen des PROTRAK-Systems über das Abdeckungsgebiet: Daten über den Standort und die Frequenzen der FM-Unterträger-Sender, die in allen Abdeckungsgebieten eingesetzt werden, werden gespeichert, wenn die Daten von dem NDC gesendet werden. Das Speichern dieser Informationen ermöglicht den Verfolgern, bekannte PROTRAK-Frequenzen für die von dem NDC übertragenen Daten zu suchen und dadurch die Initialisierung des Systems zu beschleunigen. Die Mittelpunkte der Navigationsgitter und die UHF-Übertragungsfrequenzen für jedes Abdeckungsgebiet werden ebenfalls gespeichert. Es sollte so viel Platz für diese Daten reserviert werden, dass 5-10 Datensätze gespeichert werden können.
3. Seriennummer des Verfolgers: Die Seriennummer der Einheit wird in einem Flash-Speicher gespeichert und, außer im Werk, niemals gelöscht oder verändert. Die Seriennummer und kunden-/gerätespezifische Konfigurationsdaten werden getrennt von den Parameterdaten in dem Flash-Speicher gespeichert.

Andere Parameter werden nach Bedarf definiert.
Der Verfolger unterstützt Protokolldaten, z. B. das Protokollieren der Position und anderer Sensorinformationen im Flash-Speicher zum späteren Herunterladen. Dies ist nützlich für das Feststellen der Position eines Fahrzeugs, wenn es sich außerhalb des Sendebereichs bewegt; und bei der Rückkehr in den Sendebereich können die Daten über die MDE-Schnittstelle oder über Funk heruntergeladen werden.
VIII. Mobiles Datenendgerät
Das MDE 190 dient, in erster Linie zum Nutzen des Fahrzeugbedieners, als eine Steuer- und Anzeigeeinheit (control and display unit – CDU) für den Verfolger 135 (23, 26). Das MDE ist ein kleiner, herkömmlicher programmierbarer Computer, ähnlich wie, aber im Allgemeinen kleiner als ein Notebook-PC (mit kundenspezifischer Software), und ein Anzeige-Endgerät mit einer Flüssigkristallanzeige (liquid crystal display – LCD), einer kleinen Tastatur, einem Assoziativspeicher und interner (integrierter) Schalttechnik, um das Anzeigen von Text und anderen Daten zu ermöglichen und um den Fahrzeugbediener in die Lage zu versetzen, auf Text-Funkrufnachrichten zu antworten und weitere an den Fahrzeugabfertiger zu sendende Daten einzugeben. Das MDE 190 und der Verfolger 135 kommunizieren über eine symmetrische, differentielle, asynchrone, serielle Schnittstelle, die bei der beispielhaften Ausführungsform eine duale differentielle Sender-/Empfänger Schnittstellenschaltung SN65C1167NS von Texas Instruments (TI) einsetzt. Der Verfolger 135 unterstützt „Standard"-Baudraten von bis zu 38.400 bps, und das MDE 190 sollte eine Baudrate von zumindest 4.800 bps unterstützen. Das Programmieren des MDE wird ebenfalls durch die serielle Schnittstelle gesteuert. Die Protokoll- und Nachrichtenformate, ebenso wie die Leistungs- und Programmierschnittstellen, werden unten ausführlicher beschrieben.
Das bevorzugte Protokoll der seriellen Schnittstelle für die Kommunikation zwischen dem Verfolger und dem MDE, das darüber hinaus in anderen seriellen Schnittstellen des PROTRAK-Systems eingesetzt wird, basiert auf der GPS-Maschinenschnittstelle Rockwell NavCore V, die im „NavCore Designer's Guide", Überarbeitung H, 14. Dezember 1993 von Rockwell International (hier im Folgenden als das NavCore-Schnittstellenprotokoll bezeichnet) beschrieben ist. Die MDE-Schnittstelle setzt unterschiedliche Baudraten und Nachrichtentakte ein.
In Übereinstimmung mit NavCore und anderen Konventionen zur Nachrichtennummerierung wird jede Schnittstelle durch eine unterschiedliche Tausenderstelle in der ID-Nummer der Nachricht identifiziert. Die MDE-Verfolgerschnittstelle verwendet 7.000 als Schnittstellenkennung. Durch den Verfolger 135 gesendete Nachrichten setzen bei 7.100 beginnende ID-Nummern ein, und durch den Verfolger 135 empfangene Nachrichten setzen bei 7.200 beginnende ID-Nummern ein. Bei der beispielhaften Ausführungsform sind die Nachrichten-IDs wie folgt:
Für den Verfolger zum MDE:
7101 Navigationsdaten
7102 Empfangene Nachrichtendaten
7103 Empfangene Benutzerdaten
7104 Verfügbare Nachrichtendaten
7106 Benutzerdaten-Nachrichtenliste
Für das MDE zum Verfolger:
7201 Datenanforderung
7202 Textnachrichtenantwort
7203 Benutzerdatenausgabe
7204 Anfordern verfügbarer Nachrichtendaten
7205 Anforderungsnachricht
7206 Anfordern der Benutzerdaten-Nachrichtenliste
Auf Anforderung durch das MDE 190 (ausgelöst durch den Fahrzeugbediener) sendet der Verfolger 135 Navigationsdaten (Nachricht 7201, Tabelle 57, Anhang B) einschließlich der aktuellen Position, Geschwindigkeit und Zeit mit ungefähr 1 Hz an das MDE. Wenn der Verfolger eine „Anforderungsnachricht" (7205, Tabelle 66) von dem MDE empfängt, sendet er Daten für die angeforderte Textnachricht unter Verwendung eines Paketes für „Empfangene Nachrichtendaten" (7102, Tabelle 58) an das MDE. Letzteres enthält entweder den Volltext der empfangenen Nachricht oder eine ID-Nummer, die angibt, dass ein „vorgefertigter" Text angezeigt werden kann. Es wird eine Antwort zusammen mit der Textnachricht gesendet, die einen eindeutigen Satz an Textelementen enthält, die durch den Fahrzeugbediener in Reaktion auf die empfangene Nachricht ausgewählt werden können.
Jede Nachricht verfügt über eine Kennung oder eine Ausgabe der Daten (issue of data – IOD), einen Durchgangszähler, um Nachrichten innerhalb des Systems zu unterscheiden und um Nachrichten mit ihren Antworten zu verknüpfen. Wenn der Bediener eine Antwort auf eine Nachricht auswählt (z. B. eine Anfrage von dem Fahrzeugabfertiger), wird die IOD dieser Nachricht mit der Antwort in der Nachricht 7202 an den Verfolger zurückgesendet. Die Antwort wird unter Verwendung von Pfeiltasten auf der Vorderseite (der kleinen Tastatur) des MDE ausgewählt. Das MDE speichert den Text einer einzelnen Nachricht, der bis zu 80 Zeichen umfassen kann, während er dem Bediener angezeigt wird. Der Text jeder Antwort kann aufgrund der Bildschirmgröße begrenzt sein (z. B. auf ungefähr 10 Zeichen).
In den „Empfangenen Nachrichtendaten" (Tabelle 58) gibt der Nachrichtentyp an, ob die Nachricht eine vorgefertigte oder eine Volltextnachricht enthält. Wenn die Nachricht vorgefertigt ist, enthält das nächste Byte die ID-Nummer der Nachricht; anderenfalls enthält es die Länge des empfangenen Nachrichtentextes in Byte. Die nächsten zwei Bytes enthalten die IOD-Nummer der empfangenen Textnachricht und die Benutzerantwort, wenn eine Nachricht bereits gesendet worden ist. Die nächsten drei Wörter geben das Datum und die Zeit an, zu denen die Nachricht empfangen wurde. Das nächste Wort enthält die Anzahl der gültigen Antworten in der Antwortliste. Als Nächstes folgt die Liste der vier Textantworten, die oberhalb der Softkeys des MDE angezeigt werden sollen. Unbelegte Antwortstrings werden mit Null aufgefüllt. Wenn es sich bei der Nachricht um Volltext handelt, folgen die Zeichen der Nachricht der Reihe nach. Bei einer ungeraden Anzahl von Bytes wird das letzte Nachrichtenbyte auf 0 gesetzt. Die Datenprüfsumme folgt dem Antwortsatz im Fall einer vorgefertigten Nachricht oder den Textdaten im Fall einer Volltextnachricht.
Der Verfolger empfängt benutzerdefinierte Daten von dem NDC in einem Paket, das aus einer Datenkennung (1 Byte) und 20 Bytes Daten besteht. Abhängig von den Benutzeranforderungen und dem Type der empfangenen Daten bearbeitet der Verfolger die Daten entweder selbst oder gibt sie an das MDE weiter, indem er eine „Empfangene Benutzerdaten"-Nachricht (7103, Tabelle 59) an den Fahrzeugbediener sendet. In dem MDE verarbeitet kundenspezifische Software die empfangenen Daten.
Der Verfolger ist in der Lage, zahlreiche Textnachrichten von dem NDC zu empfangen und zu speichern. Wenn der Verfolger eine neue Nachricht empfängt (ebenso wie in periodischen Intervallen), sendet er eine „Verfügbare Nachrichtendaten"-Nachricht (7104, Tabelle 60) an das MDE und zeigt die Anzahl der ungelesenen Nachrichten und die Anzahl der gespeicherten Nachrichten wie auch eine eindeutige ID für jede Nachricht an, die dazu bestimmt ist, eine bestimmte Nachricht von dem Verfolger abzurufen. Beim Empfang dieser Nachricht 7104, gibt das MDE periodisch einen Impuls an einen Lautsprecher oder eine andere Alarmvorrichtung (z. B. eine Lampe, LED oder die LCD-Anzeige selbst) innerhalb des MDE, wenn die Anzahl der ungelesenen Nachrichten nicht Null ist, um den Fahrzeugbediener über ungelesene Nachrichten zu informieren, die eine Antwort erfordern. Einzelne ungelesene Nachrichten können von dem Verfolger abgerufen werden, indem der Fahrer eine Anforderungsnachricht (7205, Tabelle 66) von dem MDE sendet.
Der Verfolger 135 wird ein Satz vorgefertigter „Benutzerdaten"-Nachrichten einprogrammiert, von denen eine Liste (Nachricht 7106, Tabelle 61) zum Anzeigen auf dem MDE angefordert werden kann, indem der Fahrer eine Nachricht zum „Anfordern der Benutzerdaten-Nachrichtenliste" (7206, Tabelle 67) sendet. Beim nachfolgenden Empfang einer „Anforderungsnachricht" für eine bestimmte „Benutzerdaten"-Nachricht stellt der Verfolger den Text dieser angeforderten Nachricht für das MDE bereit. Jede Nachricht besteht aus einer festgelegten Länge von 30 Zeichen, wobei unbelegte Positionen auf 0x00 gesetzt werden.
Es ist eine Anzahl von Status- und Fehlerbeseitigungsnachrichten von dem Verfolger zur periodischen Ausgabe verfügbar, und das MDE kann anweisen, dass diese Nachrichten – oder bestimmte von ihnen durch Benennung einer Nachrichten-ID – ein- oder ausgeschaltet werden, indem es eine „Datenanforderungs"-Nachricht (7201, Tabelle 62) sendet. Standardmäßig sind alle verfügbaren dieser periodischen Nachrichten ausgeschaltet. Sobald jedoch eine Nachricht eingeschaltet wird, fährt der Verfolger fort, sie periodisch auszugeben, bis die Nachricht ausgeschaltet wird oder dem Verfolger die Nennleistung entzogen wird.
Wenn der Fahrzeugbediener eine Antwort auf eine empfangene Textnachricht auswählt, sendet das MDE diese Antwort unter Verwendung einer „Textnachrichtenantwort"-Nachricht (7202, Tabelle 63) an den Verfolger, die die IOD der Nachricht, die beantwortet wird, und den numerischen Antwortwert enthält.
Der Verfolger wird eingesetzt, um unter Verwendung eines Ausgabepaketes, das aus einer Datenkennung (1 Byte) und entweder 1 oder 9 Bytes an Daten besteht, benutzerdefinierte Daten an das NDC und an den Fahrzeugabfertiger oder Teilnehmer über den/die Hub(s) über kundenspezifische MDE-Schnittstellen zu senden, die den Dateneintritt gestatten. Die Daten können aus Notfallanforderungen oder einem einfachen Status des Fahrzeuges, wie „Arbeit abgeschlossen" oder komplexeren Informationen bestehen. Nach der Dateneingabe werden sie in jedem Fall von dem MDE unter Verwendung einer „Benutzerdatenausgabe"-Nachricht (7203, Tabelle 64) für die Übertragung durch den Verfolger an das NDC an den Verfolger gesendet. Die Nachricht hat eine festgelegte Länge mit tatsächlichem Platz für 10 Datenbytes, und nur 1 oder 9 ist auf Basis des LSB von Wort 6 bedeutungstragend. Für die verbleibenden Datenbytes werden die Werte auf Null gesetzt.
Wenn der Fahrzeugbediener gespeicherte Nachrichten anzeigen möchte, gibt er oder sie in das MDE 190 ein, dass eine Nachricht zum „Anfordern verfügbarer Nachrichtendaten" (7204, Tabelle 65) an den Verfolger gesendet wird, um die Liste der verfügbaren Textnachrichten abzurufen, und der Verfolger antwortet mit einer Liste der „Verfügbaren Nachrichtendaten" (7104, Tabelle 60). Danach wird eine „Anforderungsnachricht" (7205, Tabelle 66) durch den Fahrzeugbediener von dem MDE gesendet, um von dem Verfolger eine bestimmte der verfügbaren Textnachrichten aus denen, die in der Liste enthalten sind, abzurufen. Wie oben vermerkt, wird eine Nachricht „Anfordern der Benutzerdaten-Nachrichtenliste" (7206, Tabelle 67) durch den Fahrzeugbediener von dem MDE gesendet, um eine Liste der durch den Verfolger gespeicherten vorgefertigten „Benutzerdaten"-Nachrichten abzurufen.
Wir kehren zu der Betrachtung der Leistung zurück, wobei der Verfolger 135 eine Leistung von 12 VDC an das MDE 190 bereitstellt, wie zuvor in 26 angegeben, während der durch das MDE aufgenommene Maximalstrom, der das Einschalten und das Einschalten der Rücklichter einschließt, bevorzugt auf 0,5 A begrenzt ist. Das MDE verfügt über einen einzelnen Schnittstellen-Verbindungsstecker, bei dem es sich bei der vorliegenden beispielhaften Ausführungsform um einen auf eine Leiterplatte montierten 9-Stifte-D-Typ handelt. Die Verbindungssteckersignale von dem Verfolger an das MDE sind wie folgt:

1. Laststeuerung hochfahren (nicht angeschlossen)
2. + Empfangsdaten
3. – Empfangsdaten
4. + Sendedaten
5. – Sendedaten
6. Erde
7. +12V
8. +12V
9. Erde

Der Festwertspeicher (read-only memory – ROM) des MDE kann über die serielle Schnittstelle programmiert werden. Das MDE wird durch Bestätigen (pulling low) eines Signals für das Hochfahren der Laststeuerung in den Programmiermodus versetzt und wird dann durch Senden von Datenblöcken durch die serielle Anschussstelle programmiert.
IX. Netzwerk-Hubs
Es wird nun auf das vereinfachte Blockschaltbild eines beispielhaften Netzwerk-Hubs in 30 Bezug genommen, wobei der Hub 11 Fahrzeugdaten-Übertragungen empfängt, die Binärdaten zurückgewinnt und die Daten über eine Telefonleitung an das NDC sendet. Der Netzwerk-Hub umfasst einen FM-Funkempfänger 85 (der mit dem FM-Funkempfänger in jedem Fahrzeugverfolger übereinstimmt), um übertragene Nachrichten für Taktzwecke zu empfangen, einen UHF-Funkempfänger 81, um Fahrzeugübertragungen zu empfangen, und ein Modem 87 für die Kommunikation mit dem NDC.
Die Netzwerk-Hubs sind an strategischen Punkten montiert – üblicherweise auf gemietetem Platz auf vorhandenen Funktürmen in oder in der Nähe des bedienten Stadtgebietes – um Fahrzeugdaten-Übertragungen zu empfangen. Die Hubs erfordern zum Arbeiten nur eine Leistung von 110 V AC und eine Telefonleitung in Geschäftsqualität. Bei einem typischen Abdeckungsgebiet werden 10 bis 30 Hubs benötigt, um die verschiedenen Flottenbetriebe zu bedienen, die Fahrzeugverfolgung fordern. Durch diese relativ kleine Anzahl von Einheiten und den Bedarf an hoher HF-Leistung werden die Kosten zu einem weniger wichtigen Faktor für die Hubs als für die Verfolger in den Fahrzeugen. Die FM- und UHF-Empfängerempfindlichkeit und die Systemzuverlässigkeit sind von großer Bedeutung.
Jeder Netzwerk-Hub ist in vier wesentliche Funktionsbereiche aufgeteilt, und zwar: 1) die CPU 82, 2) das Netzteil 84, 3) das Modem 87 und 4) die HF-Karte 86. Die CPU 82 stimmt weitgehend mit der Verfolger-CPU überein und setzt einen Mikrocontroller 68332 von Motorola ein, der mit 20 MHz betrieben wird. Der 68332 ist wegen der SCI-, QSPI- und TPU-Peripheriegeräte hervorragend für diese Anwendung geeignet. Die Hub-CPU 82 setzt einen Prozessor, einen SRAM und einen Flash-Speicher wie in dem Verfolger ein, benötigt aber nicht den GPS-Abschnitt des Verfolgers. Andere Ähnlichkeiten/Unterschiede der Hub-CPU mit/zu der Verfolger-CPU sind, dass in der Hub-CPU ein TCXO und eine Pegelumsetzung für die Modemschnittstelle hinzugefügt werden und ein Austausch der UHF-Senderschnittstelle durch eine UHF-Empfängerschnittstelle erfolgt, aber die gleiche FM-Empfängerschnittstelle beibehalten wird. Der CPU-Flash-Speicher ist über einen Kopfteil oder einen Verbindungsstecker unter Verwendung der BDM-Modusschnittstelle des Prozessors schaltungsintern programmierbar.
Der Hub setzt den FM-Datenstrom, der eine Rate von ungefähr 4.664 bps von dem FM-Empfänger 85 aufweist, für die Systemtakt-Synchronisation ein, genau wie die Verfolger. Die FM-Daten sollten durch die Verfolger eingesetzt werden, müssen aber dennoch an dem Hub in dem Maße decodiert werden, dass die Taktdaten abgeleitet werden können. Die TPU in dem 68332, an die der FM-Datenstrom gesendet wird, und auf der CPU ablaufende Software setzen Bit-Synchronisationsinformationen in dem FM-Datenstrom ein, um der TPU zu ermöglichen, die Bit- und Bytedatentakte zu erzeugen, die zum Steuern eines Verschieberegisters 88 auf der CPU-Karte eingesetzt werden, der ebenfalls den FM-Datenstrom empfängt und die Daten in den Prozessor 83 eintaktet. Wie auch bei der Verfolger-CPU ist die Hub-CPU zuständig für das Programmieren der FM-Frequenz und des Unterträger-Offsets der HF-Karte über eine serielle Schnittstelle.
Der UHF-Empfänger 81 setzt für die UHF-Empfängerschnittstelle einen DSP-Mikroprozessor 80 ein, um die Bit- und Bytetakte aus dem empfangenen UHF-Datenstrom zu extrahieren. Dem Prozessor auf der UHF-Karte werden Taktinformationen von der CPU zur Verfügung gestellt, durch die er die Zeitfenster zum Suchen der empfangenen Fahrzeugdaten ermitteln kann.
Der Mikrocontroller 83 68332 setzt den peripheren SCI-UART zum Kommunizieren mit dem externen Modem 87 von USRobotics ein, das über eine RS-232-Schnittstelle verfügt. Es wird eine Umwandlung zwischen 5-V- und RS-232-Pegelsignalen ausgeführt. Die SCI unterstützt eine Bitrate von 19.200 bps und erzeugt bis zu ungefähr 2.800 Empfangs- und Sendeinterrupts pro Sekunde, wobei das Modem mit 14.400 bps angeschlossen wird. Wenn eine Unterstützung höherer Bitraten wünschenswert ist, kann sie unter Verwendung eines externen UART mit einem FIFO oder unter Einbeziehung von GP2010- und GP2021-Komponenten des GPS-Chipsatzes erzielt werden, um zwischengespeicherte, gepolte UARTs bereitzustellen.
Das Netzteil 84 wandelt 110 V Wechselstrom (AC) in 12 V Gleichstrom (DC) für die CPU- und HF-Abschnitte des Hubs um, die getrennt die Leistung auf 5 V Gleichstrom regulieren, um die beiden Abschnitte zu trennen. Die Umwandlung von AC zu DC wird durch ein handelsübliches Netzteil und einen handelsüblichen Transformator ausgeführt.
Die Modemleistung wird über einen Stecktransformator bereitgestellt, und die CPU stellt die Signale der seriellen Schnittstelle bereit, um Hardware-Flusssteuerung mit dem Modem zu unterstützen. Die CPU-Software steuert das Modem so, dass es das NDC anwählt, sich anmeldet und überprüft, ob die Verbindung einsatzbereit ist. Wenn die Verbindung unterbrochen wird, hängt der Hub auf und wählt erneut, um die Verbindung erneut aufzubauen, wobei er wiederholt neu wählt, bis eine Verbindung hergestellt wird, wenn das NDC-Modem anfänglich nicht antwortet. Die Telefonnummer des NDC und die Hub-Benutzer-ID und das Passwort werden in dem CPU-Flash-Speicher gespeichert. Es wird eine Verbindungsgeschwindigkeit von 14.400 bps eingesetzt, um die Zuverlässigkeit der Verbindung zu maximieren. Möglicherweise wird in einigen Situationen ein vor elektromagnetischen Störungen abgeschirmtes Modem benötigt, da das System in der Nähe von HF-Sendern arbeitet.
Der HF-Abschnitt 86 des Hubs empfängt die NDC-Übertragung auf dem FM-Unterträger an dem FM-Empfänger 85 und empfängt die TDMA-Fahrzeugübertragungen auf einem UHF-Kanal an dem UHF-Empfänger 81. Die Daten werden der CPU als serieller Strom zur Verfügung gestellt. Die CPU erzeugt die Datentakte für die NDC-Übertragungsdaten und programmiert darüber hinaus die Empfangsfrequenzen der HF-Karte, und die HF-Karte erzeugt die Takte für die Fahrzeugdaten.
Die FM-Unterträger-Daten weisen ein Offset von 67 kHz oder 92 kHz von normalen FM-Kanälen auf, und die FM-Empfangsfrequenz und das Offset können vollständig durch die CPU programmiert werden. Die Unterträger-Daten werden durch das SCA-300B 68 (6) moduliert, das ein einfaches BFSK-Modulationsverfahren einsetzt.
Die Fahrzeugverfolger übertragen Datenpakete zu zugewiesenen Zeiten auf einer Frequenz in dem UHF-Business-Band, wobei die UHF-Empfangsfrequenz ebenfalls durch die CPU mit Offsets von 12,5 kHz zwischen 450 MHz und 470 MHz programmiert werden kann. Um die verfügbare Bandbreite effizient einsetzen zu können, beträgt die Fahrzeugdatenrate 7.812,5 bps.
Die CPU-Software ermöglicht ihr, ihre Hauptaufgaben auszuführen einschließlich der Zeitsynchronisation mit dem TDMA-Netzwerk, der Kommunikation mit dem NDC über ein Modem, der Programmierung und Steuerung der HF-Karte, des Empfangs und Decodierens von FM-Unterträger-Daten und des Empfangs von Fahrzeug-UHF-Daten und des Weiterleitens der Daten an das NDC. Verschiedene Softwarefunktionen sind so geschrieben worden, dass sie mit denselben Funktionen in anderen Teilen des Systems übereinstimmen. Es sind zum Beispiel zahlreiche auf die Modemkommunikation mit dem NDC bezogene Funktionen identisch mit denen, die in dem SCC eingesetzt werden, obwohl die seriellen Datennachrichten sich unterscheiden und der Hub wählen und sich anmelden muss, während dies für den SCC nicht erforderlich ist. Die HF-Synthesizerprogrammierung, der FM-Datenempfang und der FM-Datenstrom-Synchronisationscode stimmen mit denen des Verfolgers überein.
X. Unterträger-Steuerungsrechner (Subcarrier Control Computer – SCC)
Die Hardware des Unterträger-Steuerungsrechners 48 (6) einer beispielhaften Ausführungsform wird in dem vereinfachten Blockschaltbild in 31 dargestellt. Der SCC steuert die Übertragung der NDC-Basisübertragungsnachricht. Die Nachricht wird an den Unterträger-Modulator 68 SCA-300B mit exakten Nachrichtenstartzeiten und einer exakten Datenrate ausgetaktet. Der SCC ist bevorzugt zusammen mit dem Unterträger-Modulator in der FM-Funkstation 12 in ein Gehäuse eingebaut. Der NTCC 47 an dem NDC 10 wählt das SCC-Modem 57 an, um den SCC 48 mit dem NDC zu verbinden. Der NTCC 47 stellt die Übertragungsnachrichtendaten bereit, die durch den SCC an den Modulator 68 gesendet werden sollen, und der NTCC steuert darüber hinaus die Zeit, zu der jede Übertragung beginnt.
Die CPU 260 des SCC (wie in den Beispielen der CPUs, die für den Netz-Hub und den Verfolger eingesetzt werden, bevorzugt ein 16-MHz-Prozessor 68332 von Motorola) setzt einen peripheren SCI-UART (siehe z. B. die CPU 83 des Netz-Hubs in 30) als Schnittstelle für die Kommunikation mit dem externen Modem 57 (bevorzugt von USRobotics) über eine Eingabe-/Ausgabe-Karte (E/A-Karte) 262 ein. Es wird eine Umwandlung zwischen 5-V- und RS-232-Pegelsignalen vorgenommen. Das Modem ist so eingestellt, dass es mit der CPU 260 mit 19.200 bps kommuniziert, und darf eine Verbindung mit dem NTCC 47 bei Raten von zwischen 14.400 bps und 19.200 bps herstellen. Bei dieser Kommunikationsrate kann die SCI bis zu ungefähr 2.800 Empfangs- und Sendeinterrupts pro Sekunde erzeugen.
Die CPU 260 setzt die periphere QSPI der 68332-Vorrichtung (siehe wiederum z. B. die CPU 83 des Netz-Hubs in 30) für die Unterträger-Modulatorschnittstelle ein, um die seriellen Sendedaten an den Unterträger-Modulator 68 zu senden. Auch hier erfolgt eine Umwandlung zwischen 5-V- und RS-232-Pegel-Signalen. Die QSPI wird durch die TPU des Prozessors 68332 für exakt gesteuerte Taktphasensteuerung getaktet. Die Ausgabedatenraten beträgt ungefähr 4.664,18 bps (2,5 MHz/536). Die Sendedaten werden jedoch Miller-codiert, so dass 2 Miller-Codebits für jedes Datenbit für einen Divisor von 268 (9.328,36 Code-Bps) gesendet werden. Die Ausgabevergleichs-TPU-Funktion (Ausgabevergleich – Output compare – OC) setzt eine Halbzykluszahl von 134 ein. Ein vorhandener serieller HF-Takt von der TPU zu der QSPI wird für den Ausgabedatentakt eingesetzt.
Der Sendezeitgebung und -taktgebung erfordern drei TPU-Kanäle, da das Starten des Datentaktes zur korrekten Zeit den Einsatz von zwei zusätzlichen TPU-Kanälen erfordert. Der erste TPU-Kanal ist über ein Kabel mit dem zweiten Kanal verbunden. In dem ersten Kanal löst die CPU einen einzelnen Übergangs-OC zu einem gewünschten Zeitpunkt aus und programmiert einen dritten Kanal für einen OC mit einem kontinuierlichen Impulsmodus mit einer exakten Taktsteuerregister-Startzeit (Taktsteuerregister – timing control register – TCR), die der tatsächlichen gewünschten Startzeit entspricht. Der zweite Kanal wird so eingerichtet, dass eine ITC (input transition count/capture – Eingangsänderungs-Aufzeichnung/-Zählung) mit einer Verknüpfung zu dem dritten Kanals ausgeführt wird. Wenn der Prozessor den Übergang in dem ersten Kanal auslöst, startet die TPU über die ITC-Verknüpfung den Datentakt in dem dritten Kanal zu der exakten Startzeit.
In Übereinstimmung mit dem exakten Takt, der von dem PROTRAK-System erfordert wird, wird der SCC 48 direkt von einem TCXO-Quarzoszillator mit 1,5 ppm ausgeführt. Um gemeinsame Bitraten zwischen dem SCC, den Netzwerk-Hubs und den Verfolgern aufrecht zu erhalten, die mit 20 MHz laufen, wird die TPU der CPU 260 mit 10 MHz betrieben. Das Echtzeit-Ausführungssteuerprogramm wird mit einer Rate von 1 kHz ausgeführt, was die erforderliche Programmierauflösung der TPU-Funktionen ermöglicht. Das Ausführungssteuerprogramm benötigt einen Wert des TPU-TCR-Zählers bei jedem Zeitgeber-Tick des Ausführungssteuerprogramms, so dass der Takt des Ausführungssteuerprogramms mit dem TPU-Taktgeber zum Programmieren von Datenübertragungsfunktionen synchronisiert werden kann. Zu diesem Zweck ist es günstig, die ITC-TPU-Funktion einzusetzen, um Interrupts für das Ausführungssteuerprogramm zu erzeugen. Interrupts werden erzeugt, indem Übergänge von einem zweiten TPU-Kanal erfasst werden, der eine Impulsbreitenmodulationsfunktion (Impulsbreitenmodulation – pulse-width modulation – PWM) mit der gewünschten Ausführungssteuerprogramm-Rate ausführt.
Die CPU 260 löst ein Rechtecksignal mit einem Arbeitszyklus von 50% in dem ersten Kanal der TPU aus. Die PWM-Frequenz sollte ein bequemer Teiler von 2,5 MHz sein; eine Halbperiodenbreite von 2.500 (Ausführungssteuerprogramm-Rate von 1 kHz) wird als angemessen erachtet. Die Ausgabe aus diesem Kanal wird in die Eingabe des zweiten Kanals eingegeben, der die ITC ausführt. Die ITC tastet das TCR1 ab und unterbricht den Prozessor bei jedem Übergang des PWM-Signals. Das Ausführungssteuerprogramm kann daraufhin das TPU-Register lesen, um den TCR1-Wert an diesem Interrupt-TIC festzustellen.
Die Hauptfunktion des SCC 48 ist das Senden der durch den NTCC 47 bereitgestellten Basisübertragungsnachricht mit einer exakten Rate von 1 Hz, die mit der ganzzahligen GPS-Sekunde synchronisiert ist. Der NTCC 47 hört die von dem SCC ausgelöste Übertragung ab und steuert den Takt durch Vergleichen des Starts jeder empfangenen Übertragungsnachricht mit der GPS-Zeit, wobei er eine Taktkorrektur auf Basis der Differenz zwischen der Empfangszeit und der GPS-Zeit berechnet und eine Korrektur zurück an den SCC sendet. Der SCC 48 passt daraufhin die Übertragungszeit der nachfolgenden Nachrichten auf Basis dieser Korrektur an. Dieser Taktprozess ist oben stehend ausführlicher beschrieben worden.
Die Modemschnittstelle des NTCC 47 wird so implementiert, dass der SCC 48 den durch den NTCC durchgeführten Ruf an sein Modem beantwortet. Der SCC empfängt übertragene Nachrichtendaten und Taktsteuerbefehle über die serielle Schnittstelle, wobei die Übertragungsnachricht von dem NTCC 47 üblicherweise in fünf Paketen gesendet wird. Der SCC stellt daraufhin die Pakete der Reihe nach zusammen und sendet die Nachrichtendaten bei der nächsten ganzzahligen Sekunde an den Unterträger-Modulator 68. Es wird LCD-Bildschirm 263 an dem SCC 48 eingesetzt, um Status- und Fehlerbeseitigungsinformationen anzuzeigen.
Eine Anzahl von Softwarefunktionen ist so geschrieben, dass diese mit Funktionen in anderen Teilen des Systems übereinstimmen. Viele auf die Modemkommunikation durch den SCC mit dem NTCC bezogene Funktionen sind zum Beispiel identisch mit denjenigen, die in dem Netzwerk-Hub verwendet werden. Die seriellen Datennachrichten unterscheiden sich jedoch, und anders als der SCC muss der Hub wählen und sich anmelden. Teile des Zeitsynchronisationscodes und des Ausführungssteuerprogramms stimmen mit denen der Netzwerk-Hubs und der Verfolger überein.
Während des normalen Betriebs empfängt der SCC 48 5 Blöcke von 155 Datenbytes von dem NTCC 47, die in jeder Sekunde in der FM-Unterträger-Übertragung durch die Funkstation 12 übertragen werden sollen. Der SCC Miller-codiert die Daten, fügt eine Präambel und das Synchronisationsmuster am Anfang hinzu und platziert die resultierenden 9.264 Bits in einem Ausgabepuffer. Vor der nächsten Sendezeit wird der Ausgabedatentakt gestoppt und so eingestellt, dass er zu der nächsten gewünschten Startzeit erneut startet, wie durch den NTCC angewiesen. Der QSPI-Ausgabepuffer wird vorbereitet, und die CPU 260 schaltet einen TPU-Ausgangskanal um, um den Sende-Synchronisationsprozess zu starten.
Für die NTCC-SCC-Synchronisation koordiniert der NTCC 47 den Takt des Sendens der Übertagungsdaten an den SCC 48, indem er ihn auf die Empfangszeit einer SCC-Statusnachricht gründet (siehe Tabelle 72 in Anhang B, worauf in der unten stehenden Erörterung des NTCC-Abschnitts verwiesen wird). Der SCC sendet diese Nachricht jedes Mal, wenn er eine Datenübertragung auslöst. Zu diesem Zeitpunkt sendet der NTCC 47 eine neue Übertragungsdatennachricht (1102, siehe Tabelle 71 in Anhang B, worauf ebenfalls in der unten stehenden Erörterung verwiesen wird). Dieses Taktverfahren stellt eine minimale Wartezeit der Übertragungsdaten sicher und beseitigt Taktmehrdeutigkeiten zwischen dem NTCC und dem SCC aufgrund des Fehlens einer absoluten Zeitreferenz bei dem SCC.
Die durch den NTCC 47 übertragenen vollständigen 5 Blöcke (575 Bytes) erfordern bei 14.400 bps ungefähr 500 ms, um an den SCC 48 gesendet zu werden. Der SCC gestattet insgesamt 900 ms für den Empfang von neuen Daten, bevor die Verarbeitung für die Übertragung der Daten in der nächsten Sekunde abgeschlossen sein muss. Diese zusätzliche Zeit ermöglicht eine Wiederholung von einem oder zwei Nachrichtenblöcken, die möglicherweise korrumpiert worden sind. Eine höhere Verbindungsbitrate ermöglicht zusätzliche Wiederholungen, aber mit der Möglichkeit einer geringeren Zuverlässigkeit. Ungültige Übertragungsdaten aus einer NTCC-Nachricht mit einem gültigen Kopf sollten gesendet werden, selbst wenn eine fehlerfreie Wiederholung von dem NTCC nicht verfügbar ist, da die Golay-codierten Daten möglicherweise durch die Fahrzeugverfolger selbst korrigiert werden können.
Für die Nachrichtendatenverarbeitung bildet der SCC 48 den vollständigen Sendepufferspeicher durch Einfügen der Präambel und des Bit-Sync-Musters in den Puffer und darauf folgendes Anhängen der Daten. Die Sendedaten werden durch den NTCC an den SCC mit einer Leitungscodierung ohne Rückkehr nach Null (non-return to zero – NRZ) gesendet. Der SCC muss die Daten Miller-codieren, wodurch die 4.600 NRZ-Datenbits in 9.200 Miller-Bits umgewandelt werden. Der Codierprozess dauert ungefähr 12-15 ms. Der Miller-Code setzt den Speicher des zuvor codierten Bit ein, so dass er nur an einem Datenblock ausgeführt werden kann, wenn der vorherige Block empfangen worden ist. Die Präambel ist ein abwechselndes Eins-Null-Miller-Bitmuster, das vor dem Bit-Sync-Muster eingefügt wird: 11 00 11 00 11 00 11 00, wobei das Bit ganz links zuerst gesendet wird. Das Bit-Sync-Muster hat eine Länge von 48 Miller-Bits und besteht aus 9 hohen Bits gefolgt von 7 niedrigen Bits, was drei Mal wiederholt wird.
Die QSPI des Prozessors 68332 der CPU 260 wird als das Ausgabe-Schieberegister eingesetzt. Der interne QSPI-Puffer hält 16 Bytes, wenn er für Übertragungen von 8 Bits konfiguriert worden ist. Bei Übertragungen von 8 Bits entleert er sich alle 13,72 ms, so dass eine Aufgabe in dem Echtzeit-Ausführungssteuerprogramm terminiert werden muss, um die QSPI-Warteschlange zu bedienen. Die QSPI sendet Daten mit dem höchstwertigen Bit zuerst, was bei der Bildung der Präambel und der Bit-Sync-Muster sowie beim Laden der QSPI berücksichtigt wird.
Der NTCC-/SCC-Datenfluss wird in dem Taktdiagramm in 32 dargestellt. Der SCC 48 sendet gleichzeitig Übertragungsdaten 265 für den aktuellen Rahmen und Empfangsdaten 266 von dem NTCC für den nächsten Rahmen. Nach ungefähr 900 ms in dem aktuellen Rahmen (bei 267) muss der SCC den Empfang von Daten von dem NTCC 47 abbrechen und die Verarbeitung der verfügbaren Blöcke beginnen. Wenn Datenblöcke vollständig fehlen, nimmt der SCC an, dass alle NRZ-Daten Nullen sind, und beginnt die Miller-Codierung entsprechend. Der SCC 48 muss darüber hinaus eine neue Sendezeit auf Basis der empfangenen Befehle von dem NTCC berechnen. Die TPU wird mit der neuen Sendezeit während der Lückenzeit 269 zwischen den Übertragungsdaten-Übertragungen programmiert.
Jegliche Sendetaktung und Synchronisation erfolgt in der Lückenzeit 269 von ungefähr 6,9 ms zwischen den Übertragungen. Während dieser Zeit führt der SCC 48 die folgenden Schritte aus, um das Senden der Daten für die nächste Zeit zu beginnen:

1. Die QSPI stoppen.
2. Den OC-Datentakt in dem TPU-Kanal 3 ausschalten.
3. Den Ausgabedatenpuffer auf die neu empfangenen Daten umschalten.
4. Den TPU-Kanal 3 so programmieren, dass der kontinuierliche Impulsmodus mit der nächsten Sendezeit startet.
5. Die QSPI mit den neuen Daten laden und die QSPI aktivieren.
6. Die SCC-Statusnachricht an den NTCC senden.
7. Den OC-Status des TPU-Kanals 1 umschalten, um den Synchronisationsprozess zu starten.

Die Sendedaten-Zeitgebung und -Taktgebung erfordern 3 TPU-Kanäle: Kanal 1 wird auf eine einzelne OC-Übergangs-Funktion programmiert, die so eingerichtet wird, dass sie während der Lückenzeit durch die CPU umschaltet. Der Ausgang von Kanal 1 ist über ein Kabel mit dem Eingang von Kanal 2 verbunden.

Die Kanalparameter sind wie folgt:

PSC = 11	keinen Status erzwingen
PAC = 010	bei Übereinstimmung umschalten
TBS = 0100	Kanal ausgeben, TCR 1 anpassen
OFFSET = 0
(REF_ADDR 1) = TCR1-Zeit für den Übergang
(REF_ADDR2)= egal
(REF_ADDR3)= egal

Kanal 2 wird mit der ITC-Funktion so programmiert, dass kontinuierlich Verknüpfungen zu Kanal 3 erzeugt werden. Die ITC ist so eingerichtet, dass sie bei jedem Übergang auslöst.

Die Kanalparameter sind wie folgt:

PSC = 11
PAC = 011	beide Flanken erfassen
TBS = 0000	Kanal eingeben, TCR 1 aufzeichnen
MAX_COUNT = 1
START_LINK_CHANNEL = 3
LINK_CHANNEL_COUNT = 1
BANK_ADDRESS = unbelegte TPU-Parameter-RAM-Position

Kanal 3 wird mit einer kontinuierlichen OC-Impuls-Funktion programmiert. Dies ist der Ausgang für den Datentakt, und er ist über ein Kabel mit dem Takteingang der QSPI verbunden. Während der Lückenzeit wird er mit einer aktualisierten REF_TIME, bei der es sich um die Sendestartzeit handelt, neu programmiert.

Die Kanalparameter sind wie folgt:

PSC = 10	bei Initialisierung niedrigen Zustand erzwingen
PAC = 010	bei Übereinstimmung niedrigen Zustand erzwingen
TBS = 0100	Kanal ausgeben, TCR 1 anpassen
RATIO = IFF
(REF_ADDR1) = egal
(REF_ADDR2) = 134
(REF_ADDR3) = TCR1-Zeit senden

Die Bezugsadresszeiger zeigen auf Positionen in dem TPU-Parameter-RAM (random access memory – Speicher mit wahlfreiem Zugriff). Daher muss der Parameterraum von unbelegten Kanälen zum Speichern der Daten für diesen Kanal eingesetzt werden. Interrupts dieser Kanäle können deaktiviert werden.
Der SCC 48 verfügt über drei Betriebsmodi: Initialisierung, Ruhe und Lauf. Wenn der SCC eingeschaltet wird, tritt er in den Initialisierungsmodus ein. In diesem Modus initialisiert die Software Systemvariablen, schaltet das LCD 263 und das Rücklicht ein, initialisiert das Modem 57 und richtet die TPU so ein, dass sie das Echtzeit-Ausführungssteuerprogramm startet. Nachdem die Initialisierung abgeschlossen ist, geht der SCC in den Ruhezustand über.
Im Ruhezustand wartet der SCC 48 auf einen von dem NTCC 47 zu empfangenden Ruf. Während des Wartens sendet der SCC keine Daten an den Unterträger-Modulator 68, und der Ausgang bleibt hoch oder niedrig. Das Modem 57 wird auf ein Verbindungsereignis überwacht. Wenn das Modem eine Verbindung herstellt, geht der SCC in den Laufmodus über und empfängt Befehle von dem NTCC.
Im Laufmodus weist der NTCC 47 den SCC 48 an, in einen von zwei Datenübertragungsmodi einzutreten, und zwar: Synchronisation oder Übertragung. Der NTCC setzt zunächst den Synchronisationsmodus ein, um das Übertragungs-Synchronisationsmuster an der GPS-Zeit auszurichten. In diesem Modus wählt der SCC eine willkürliche Startzeit und sendet eine Präambel und ein Bit-Sync-Muster ohne jegliche Daten in Intervallen von einer Sekunde. Der NTCC weist den SCC an, die Sendestartzeit zu verschieben, bis die Synchronisation mit der GPS-Zeit erreicht ist. Zu diesem Zeitpunkt weist der NTCC den SCC an, in den Übertragungsmodus überzugehen. In diesem Modus stellt der NTCC jede Sekunde fünf zu sendende Datenblöcke bereit. Während des Betriebs im Laufmodus sendet der SCC vor dem Start jeder Übertragung seine Statusnachricht an den NTCC, wie oben beschrieben.
Wenn über einen vorgegebenen Zeitraum gültige Nachrichtendatenstopps von dem NTCC empfangen werden, lässt der SCC das Modem aufhängen, initialisiert das Modem erneut und kehrt in den Ruhemodus zurück, um einen weiteren Ruf von dem NTCC zu erwarten.
XI. Netzwerktakt-Steuerunqsrechner (NTCC)
Wie hier oben stehend beschrieben worden ist (und mit kurzer erneuter Bezugnahme auf 6), kommuniziert der NTCC 47 mit einer Reihe weiterer Anwendungen, einschließlich des NDC-Servers 42, des NTCC-Dachmoduls 55 und, über ein Modem, des SCC 48. Der NTCC dient als eine Echtzeit-Steuerschnittstelle für das NDC zu dem Funknetz, und er empfängt darüber hinaus Taktdaten und DGPS-Korrekturen von einem GPS-Empfänger 54 NavSymm XR5M in dem Dachmodul. Die Schnittstellen zwischen den Computern sind seriell. Es werden die diskreten Schnittstellen PPS und Reset zwischen dem NTCC 47 und dem Dachmodul 55 unterstützt.
Der NDC-Server 42, das Dachmodul 55 und der SCC 48 setzen alle dieselben Protokoll- und Nachrichtenformate auf Basis des zuvor genannten NavCore-Schnittstellenprotokolls ein, um mit dem NTCC 47 zu kommunizieren. Das NavCore-Schnittstellenprotokoll ist insofern für die Zwecke der vorliegenden beispielhaften Ausführungsform des PROTRAK-Systems modifiziert worden, als das niedrigere Byte des Statusflagwortes in dem Kopf für einen frei schwingenden Nachrichtenzähler eingesetzt wird. Der Nachrichtenzähler identifiziert die Nachricht eindeutig und wird in einer ACK/NACK-Antwort eingesetzt, wenn eine Quittung für die Nachricht erforderlich ist. Dadurch wird es möglich, dass mehrere Nachrichten desselben Typs gleichzeitig ausstehend (in Erwartung von Quittungen) sind. Der Nachrichtenzähler im ACK/NACK identifiziert die spezifische Nachricht, die quittiert wird.
In Übereinstimmung mit NavCore und bestimmten anderen Konventionen zur Nachrichtennummerierung wird jede Schnittstelle durch eine unterschiedliche Tausenderstelle in der ID-Nummer der Nachricht identifiziert. Durch den NTCC 47 gesendete Nachrichten setzen ID-Nummern ein, die bei x100 beginnen, und durch den NTCC empfangene Nachrichten setzen ID-Nummern ein, die bei x200 beginnen, wobei x die Tausenderstellen-Schnittstellenkennung ist. Die Nachrichten-IDs für jede serielle Schnittstelle werden unten in Tabelle 68 dargestellt. Tabelle 68: Nachrichten-ID-Nummern der seriellen Schnittstellen

Schnittstelle Nachrichten-ID-Bereich

SCC 1100/1200

NDC-Server 2100/2200

Dachmodul 3100/3200
Die seriellen NTCC-Schnittstellen werden unter Verwendung einer seriellen COM-8SF-2-E/A-Platine mit mehreren Anschlussstellen von Contec ausgeführt, die in der Lage ist, mit bis zu 115.200 bps zu kommunizieren. Es werden die diskreten Schnittstellen PPS und Reset durch eine P10-48W-Platine von Contec unterstützt.
Der NTCC kommuniziert mit dem SCC, dem NDC-Server und dem Dachmodul durch serielle Datennachrichten. Es wird erneut auf 6 Bezug genommen, wo der NTCC 47 eine Verbindung zu dem SCC 48 herstellt, indem er über das Modem 57 einen Ruf an den SCC richtet. Wenn das Modem verbunden ist, beginnt der NTCC Taktsteuernachrichten zu senden, und der SCC beginnt, Statusnachrichten zu senden. Nachdem die Zeitsynchronisation erreicht worden ist, beginnt der NTCC, vollständige Sendedatensätze zu senden, die aus DGPS-Daten und durch das NDC erzeugte Nachrichten bestehen, die aus 5 Rahmen von 115 Bit Länge bestehen. Der SCC ist zuständig für die Erzeugung des Bit-Sync und für den Start der FM-Übertragung. Die für die Kommunikation zwischen dem NTCC und dem SCC eingesetzten Nachrichten werden in Tabelle 69 (Anhang B) und ausführlicher unten und in weiteren Tabellen im Anhang B zusammengefasst, wie unten angegeben.
Der NTCC 47 steuert den Takt der FM-Unterträger-Übertragung unter Verwendung einer „Taktsteuerungs"-Nachricht (1101, Tabelle 70). Der SCC 48 setzt die Daten in dieser Nachricht ein, um seinen Sendetakt so auszurichten, dass das Übertragungsdaten-Bit-Sync mit der GPS-Zeit synchronisiert wird. Die Taktsteuerungsnachricht wird durch den NTCC kurz vor Beginn eines Intervalls von einer Sekunde gesendet. Der SCC-Zeitgeber der ganzzahligen Sekunde wird unter Verwendung der in der Taktsteuerungsnachricht enthaltenen Taktgebersteuerung programmiert, bevor der aktuelle Zeitgeber abläuft.
Kurz gesagt und mit Bezug auf Tabelle 70 (Anhang B), ist der Taktsteuerungsmodus das niedrigstwertige Byte von Wort 6 in der Taktsteuerungsnachricht und verfügt über drei Werte: 0 = aus, 1 = grob, und 2 = genau. Der Steuerungstyp ist das höchstwertige Byte von Wort 6 und zeigt an, wie die Taktgebersteuerung in den Wörtern 7 und 8 der Nachricht anzuwenden ist. Der Steuerungstyp verfügt über drei Werte: 0 = nicht einsetzen, 1 = zum Nominalwert addieren, und 2 = ein Versuch. Wenn der Steuerungstyp gleich 0 ist, wird er nicht berücksichtigt; wenn er gleich 1 ist, wird der Wert der Taktgebersteuerung zu dem nominalen Taktgeberwert addiert, und der Taktgeber wird neu programmiert; und wenn er gleich 2 ist, wird der Taktgeber einmal mit dem Wert der Taktgebersteuerung programmiert und kehrt dann zu dem nominalen Wert zurück.
Eine Nachricht zum „Senden des Datenrahmens" (1102, Tabelle 71) enthält einen Abschnitt der vollständigen SCC-Übertragungsnachricht, die in jeder Sekunde übertragen wird. Die Übertragungsnachricht wird in kleinere Rahmen aufgeteilt, so dass, wenn ein Teil der Nachricht verpasst wird, er schneller wiederholt werden kann als die gesamte Übertragungsnachricht.
Die nominale Übertragungsnachricht besteht üblicherweise aus fünf Rahmen von 115 Bytes (23-Bit-Verschachtelung des (23,12)-Golay-Codes), wodurch die gesamte Übertragungsnachricht eine Länge von 4.600 Datenbits bekommt. Datenrahmennachrichten, die Daten enthalten, die in dem nächsten Übertragungsrahmen gesendet werden sollen, werden von dem NTCC in dem aktuellen Rahmen an den SCC gesendet. Der SCC sendet die verfügbaren Übertragungsdaten zu Beginn jeder Sekunde. Wenn Datenrahmen fehlen, werden die fehlenden Rahmen in dem Sendedatenstrom durch Nullen ersetzt.
Kurz vor Beginn jeder Sekunde legt der NTCC die in der nächsten Sekunde zu sendenden Daten fest, und diese Daten werden in Rahmen aufgeteilt. Mehrere Nachrichten mit der ID 1102, eine für jeden Rahmen, werden gleichzeitig in die Warteschlange eingestellt.
Die Übertragungsrahmen-ID in Wort 6 der Nachricht zum „Senden des Datenrahmens" gibt den Übertragungsrahmen an, für den die Sendedaten bestimmt sind. Der SCC setzt diesen Wert ein, um eine Vermischung von für unterschiedliche Übertragungsrahmen bestimmten Daten auszuschließen. Die Rahmennummer und die Gesamtzahl der Rahmen sind in den niedrigstwertigen und höchstwertigen Bytes von Wort 7 enthalten, um die Art der Zusammenstellung der Datenrahmen anzugeben, falls die Nachrichten nicht der Reihe nach empfangen werden. Die Anzahl von Bytes in dem Rahmen, / (in Wort 8), gibt die Anzahl von nachfolgenden Datenbytes an. Wenn / ungerade ist, wird das höchstwertige Byte des letzten Datenwortes mit 0x00 aufgefüllt. Die Datenbytes werden so angeordnet, dass sie in derselben Reihenfolge an den SCC gesendet werden, wie sie durch den SCC zurückgesendet werden sollen.
Der SCC 48 sendet in Intervallen von einer Sekunde Statusinformationen an den NTCC 47 in „SCC-Status"-Nachrichten (1201, Tabelle 72). Ein aktueller nominaler Zeitgeber in der Nachricht enthält den vorliegenden Nominalwert des Sendezeitgeber-Countdowns. Der SCC-Status in Wort 8 ist bitcodiert.
Der NTCC 47 kommuniziert mit dem NDC-Server 42 über eine serielle Schnittstelle mit 115.200 bps oder direkt über TCP/IP oder über eine Wählverbindung. Der Server unterstützt zwei parallel laufende NTCC-Systeme für eine FM-Stations-/NTCC-Redundanz, wobei er dieselben Verfolgerdaten an beide NTCC-Systeme sendet, jedoch die Verfolger und die Netzwerk-Hubs nur einer nach dem anderen arbeiten. Dies ist das Hauptsystem, und falls dieses System ausfällt, weist der NDC-Server 42 die Netz-Hubs an, zu der untergeordneten FM-Station umzuschalten, und die Verfolger schalten bald danach ebenfalls zu der untergeordneten Station um.
Während des normalen Betriebs sendet der Server 42 Pakete, die an die Fahrzeuge (d. h. an die darin eingebauten Verfolger) zu sendende Daten enthalten, an den NTCC 47. Der NTCC formatiert die Daten in Sendedatenrahmen und sendet sie an den SCC. Der NTCC stellt für den Server 42 eine Statusnachricht bereit, die zu Beginn jeder ganzzahligen Sekunde gesendet werden soll, um dem Server zu ermöglichen, Verarbeitungsaufgaben zu terminieren. Die Statusnachricht zeigt dem Server den Status des NTCC und des SCC an und informiert den Server über verfügbaren Platz in der Ausgabewarteschlange für Daten, die an die Fahrzeuge gesendet werden sollen.
Für die Kommunikation zwischen dem NTCC 47 (wie auch einem zusätzlichen NTCC, falls vorhanden) und dem NDC-Server 42 eingesetzte Nachrichten werden in Tabelle 73 zusammengefasst. NTCCs mit Wählverbindung müssen sich zwei Mal anmelden, und zwar über eine Modembank von 3Com/U.S.Robotics und einem Radius-Server für die erste Anmeldung unter Verwendung der Standard-Eingabeaufforderungen „Anmeldename:" und „Passwort:" zum Authentifizieren von Benutzername und Passwort. Wenn ein NTCC mit Wählverbindung erfolgreich bei dem Netzwerk angemeldet ist, wird er mit einer TCP-Anschlussstelle an dem NDC-Server verbunden, die für Netzwerk-Hub- Verbindungen reserviert ist. Sobald er verbunden ist, sendet der NDC-Server eine „Anmeldungs-Infoanforderungs"-Nachricht (2104, Tabelle 74) an den Netzwerk-Hub, der die Verbindung herstellt, um sich gegenüber dem NDC-Server zu authentifizieren. Dasselbe Paar aus Benutzer-ID und Passwort, das für die Anmeldung bei der Modembank eingesetzt worden ist, wird als Antwort in einer „Anmeldungs-Infoantwort"-Nachricht (2304, Tabelle 75) gesendet. Die NTCCs mit TCP/IP-Verbindungsfähigkeit mit dem NDC-Server brauchen sich jedoch nicht bei der Modembank anzumelden, sondern können stattdessen einfach eine Verbindung mit einer TCP-Anschlussstelle an dem NDC-Server herstellen und auf die „Anmeldungs-Infoanforderungs"-Nachricht antworten.
Nachdem der NTCC authentifiziert worden ist, fordert der NDC-Server durch Senden einer „NTCC-Profilanforderungs"-Nachricht (4105, Tabelle 76) ein NTCC-Profil an. Obwohl der NTCC sein Profil verändern darf, erhält der NDC-Server ein genaues Profil durch Verwendung der in einer „NTCC-Profilantwort"-Nachricht (4305, Tabelle 77) enthaltenen Informationen aufrecht, die durch den NTCC in Reaktion auf die Anforderungsnachricht gesendet wird.
Der NTCC steuert den Echtzeit-Anteil des Funknetzes für den NDC-Server. Zu Beginn jeder Sekunde wird durch den NTCC eine „Statusnachricht 2" (2103, Tabelle 78) an den Server gesendet, die durch den Server als grobe Zeitmarkierung für das Terminieren von periodischen Aufgaben eingesetzt werden soll. Die Genauigkeit der Zeitmarkierung hängt von der Rate ab, mit der der NTCC und der Server ihre seriellen Sende- und Empfangsdaten-Warteschlangen jeweils bedienen. Wenn zwei NTCCs mit dem Server verbunden sind, setzt der Server die Zeitmarkierungs-Informationen für den Haupt-NTCC ein.
Wenn der NTCC eine Verbindung mit dem NDC-Server anfordert, sendet der Server Daten, die die FM-Funkstation beschreiben, mit der der NTCC eine Verbindung herzustellen versuchen wird, in einer „FM-Daten"-Nachricht (2201, Tabelle 79), die die Frequenz der FM-Station und die Unterträger-Frequenz angibt, auf der das PROTRAK-System arbeitet. In der Nachricht wird die Position des FM-Senders in Breite, Länge und Höhe bereitgestellt, um dem NTCC zu ermöglichen, die Verzögerungszeit der Übertragung zu berechnen. Die Telefonnummer in der Nachricht ist ein nullterminierter ASCII-String, den der NTCC wählen muss, um eine Verbindung mit dem SCC herzustellen.
Für jedes durch den NDC-Server erzeugte Basisstations-Sendepaket, z. B. „FM-Identifikation", „Schlitzzuweisung" etc., sendet der Server eine „Fahrzeugpaket"-Nachricht (2202, Tabelle 80), die das Sendepaket an den NTCC enthält, das schließlich über den FM-Unterträger durch den SCC an die Fahrzeuge gesendet werden soll. Der NTCC platziert dieses Paket in der Ausgabewarteschlange und in der Basisstations-Übertragungsnachricht, wenn der Platz es erlaubt. „Fahrzeugpaket"-Nachrichten werden durch den NTCC nicht quittiert einfach wegen des Volumens der durch den Server zu koordinierenden Nachrichten.
Wenn der NTCC eine Verbindung zu dem NDC-Server herstellt, sendet Letzterer an den NTCC eine „Ortszeitzonen-Offset"-Nachricht (2203, Tabelle 81), die das Offset anzeigt und die der NTCC mit dem „GPS-Zeit"-Basispaket an die Verfolger (über den SCC und die FM-Unterträger-Funkübertragung) überträgt. Der NDC-Server sendet diese Offset-Nachricht 2203 nicht nur in Reaktion auf das Empfangen einer gültigen NTCC-Profil-Antwortnachricht, sondern zu Beginn jeder Stunde an den NTCC. Auf diese Weise erhält der NTCC die neuesten Zeitzoneninformationen in allen Ortszeitzonen, die sich zu jeder vollen Stunde ändern.
Der NTCC 47 kommuniziert mit dem Dachmodul 55 über eine serielle Schnittstelle mit 38.400 bps, dessen CPU 56 die FM-Übertragung über den Empfänger 58 von dem SCC 48 an der Funkstation 12 empfängt. Wie zuvor hier beschrieben, wird die Ankunftszeit der FM-Daten mit der ganzzahligen GPS-Sekunde verglichen, und die Differenz zwischen dem Beginn der ganzzahligen Sekunde und dem Zeitpunkt, zu dem die Nachrichtendaten empfangen werden, wird dem NTCC 47 zur Verfügung gestellt, um eine Korrektur für eine Taktsteuerungs-Rückkopplung für den SCC 48 zu entwickeln. Der NTCC vergleicht die empfangenen Daten mit den durch den SCC bereitgestellten Daten, um zu überprüfen, ob die korrekten Daten gesendet wurden. Der NTCC 47 stellt HF-Informationen für das Dachmodul 55 bereit, um Letzteres in die Lage zu versetzen, den FM-Empfänger 58 auf den richtigen Kanal und Unterträger einzustellen.
Für die Kommunikation zwischen dem NTCC 47 und dem Dachmodul 55 eingesetzte Nachrichten werden in Tabelle 82 zusammengefasst. Der NTCC sendet während der Initialisierung eine „Frequenzsteuerungs"-Nachricht (3101, Tabelle 83) an das Dachmodul, wodurch er Letzteres anweist, sich auf die korrekte FM-Funkfrequenz einzustellen.
Der NTCC stellt durch Senden einer „Zeit-/Status"-Nachricht (3102, Tabelle 84) Zeit- und Statusinformationen in Intervallen von einer Sekunde für das Dachmodul bereit. Obwohl das Dachmodul in der beispielhaften Ausführungsform die GPS-Zeit für die Synchronisation mit dem PPS von dem GPS-Empfänger einsetzt, kann als Alternative eine Dachmodul-CPU 56 eingesetzt werden, die keine periodischen Zeitinformationen, sondern einfach Initialisierungsinformationen für den GPS-Empfänger 54 erfordert. Die „Zeit-/Status"-Nachricht, die kurz nach dem PSS gesendet wird, enthält den Zeitpunkt des PPS. Weitere Modus- und Statusinformationen werden ebenfalls für die Dachmodul-CPU bereitgestellt.
In einer „Status"-Nachricht (3201, Tabelle 85) stellt das Dachmodul seinen Status einschließlich der aktuell eingesetzten Frequenz für den NTCC bereit. Ein Taktstatuswort in der Nachricht gibt den GPS-Zeit-Synchronisationsstatus durch Bit 0 = „empfangene Zeit gültig" und Bit 1 = „Zeit synchronisiert" an. Das FM-Statuswort wird mit Bit 0 = „Synthesizer blockiert", Bit 1 = „Bit-Sync-Suchmodus", Bit 2 = „Sync erfasst" codiert.
Das Dachmodul berichtet empfangene FM-Daten in einer Nachricht (3202, Tabelle 86) an den NTCC, die der NTCC mit den für die Rahmenzeit-Synchronisation und das Überwachen des Senders und des Dachmodulempfängers gesendeten Daten vergleicht. Während des normalen Betriebs werden die FM-Daten, beginnend in der Nähe des Starts der ganzzahligen Sekunde und endend kurz vor deren Ende, empfangen, so dass die FM-Daten für ein Intervall von einer Sekunde zu Beginn des nächsten Intervalls an den NTCC berichtet werden.
Das Dachmodul gibt die Zeitdifferenz (Verzögerung) zwischen der ganzzahligen Sekunde und dem empfangenen FM-Bit-Sync für den NTCC in einer „Takt"-Nachricht (3203, Tabelle 87) für den Taktregelkreis an. Die ganzzahlige Sekunde wird durch den GPS-PPS definiert, und die „Takt"-Nachricht muss gesendet werden, unmittelbar nachdem die Verzögerung berechnet worden ist, um dem NTCC zu ermöglichen, eine Taktkorrektur zu berechnen und sie vor dem Start der nächsten ganzzahligen Sekunde an den SCC zu senden. Im normalen Laufmodus wird das Sync ungefähr 15 ms nach der ganzzahligen Sekunde erfasst. Die GPS-Woche und -Zeit werden in der „Takt"-Nachricht für den Start der ganzzahligen Sekunde bereitgestellt, für die die Verzögerung berechnet wird. Die vorgegebene Verzögerung ist die Zeit vom Start der ganzzahligen Sekunde bis zur Erfassung des Sync. Die mit 5 MHz laufende TPU hat eine Auflösung von 0,2 μs.
Der GPS-Empfänger 54 des Dachmoduls 55 ist ein GPS-Empfänger NavSymm XR5M für die DGPS-Korrekturerzeugung. Der NTCC verfügt über zwei serielle Schnittstellen zu dem XR5M-Empfänger – eine CDU-Anschlussstelle und die DGPS-Ausgabeanschlussstelle – wobei die CDU-Anschlussstelle zum Steuern des Empfängerbetriebs eingesetzt wird und die DGPS-Anschlussstelle DGPS-Korrekturen im RTCM-104-Format bereitstellt. Alternativ kann das Dachmodul 55 so implementiert werden, dass die Schnittstelle mit ihrer CPU 56 die GPS-Funktionen unterstützt.
Diskrete Schnittstellen umfassen PPS (Impuls pro Sekunde) und Reset, wobei der NTCC einen PPS zum Synchronisieren seines Ausführungssteuerprogramms mit der GPS-Zeit benötigt. Das Dachmodul setzt ebenfalls einen PPS für das Takten der Unterträger-Übertragung ein, und bei der aktuellen Ausführungsform stellt der GPS-Empfänger Navstar XR5M den PPS bereit, und der NTCC setzt ein Rücksetzsignal zum Steuern der Initialisierung dieses Empfängers ein.
XII. Datenbankverwaltungs- und CCS-Server (Database Management and CCS Server – DMCS)
Der DMCS (z. B. 27, 3) an einem Kundenstandort 13 wird der Einfachheit halber zusammen mit der Steuerung der Schnittstelle zwischen dem NDC-Server 42 und Komponenten, die mit dem Server kommunizieren, einschließlich der CCSs (z. B. 14, 15), den NDC-Bedienstationen (z. B. 43, 45, 4), der Netzwerk-Hubs (z. B. 11-1, 11-2, 3) und des NTCC 47, sowie für diese Kommunikation eingesetzten Nachrichten beschrieben.
Das Standard-Nachrichtenformat, das für das Kommunizieren zwischen dem NDC-Server und allen weiteren Systemen eingesetzt wird, basiert auf dem Nachrichtenformat, das in dem zuvor erwähnten NavCore-Schnittstellenprotokoll definiert wird, mit einem festgelegten Kopfabschnitt von fünf Wörtern und einem optionalen Datenabschnitt, wie in Tabelle 88 dargestellt. Das Standardformat des Nachrichtenkopfes wird in Tabelle 89 dargestellt.
Das Nachrichten-Startwort ist immer 0x8IFF, wodurch der Start einer gültigen Nachricht angezeigt wird. Die Standardnachrichtentyp-ID (IDNN) zeigt die Schnittstelle (interface – I) an, an der eine Nachricht eingesetzt wird, die Nachrichtenrichtung (direction – D) und -nummer (NN). Der gültige Bereich für die Nachrichtentyp-ID für Softwarekomponenten, die mit dem NDC-Server kommunizieren, wird in Tabelle 90 dargestellt, und der Bereich für diejenigen Softwarekomponenten, die mit dem DMCS kommunizieren, wird in Tabelle 91 dargestellt. Das Datenwort-Anzahlfeld zeigt die Anzahl der 16-Bit-Wörter an, die in dem Datenabschnitt einer Nachricht enthalten sind (wobei dieses Feld auf 0 gesetzt ist, wenn die Nachricht über keinen Datenabschnitt verfügt), ausgenommen das Datenprüfsummenfeld.
In dem Flags-/Nachrichten-ID-Feld identifiziert das niedrigstwertige Byte (Bits 7-0) die Nachricht, wenn eine Quittierung oder eine negative Quittierung erforderlich ist, und die Bits 12, 11 und 10 sind Flags, die jeweils eine erforderliche Quittierung, eine Quittierung und eine negative Quittierung anzeigen. Wenn eine Nachricht mit gesetztem Bit (12) für die erforderliche Quittierung gesendet wird, muss der Empfänger unter Verwendung derselben Nachrichten-ID mit gesetztem Quittierungsbit (11) oder gesetztem negativen Quittierungsbit (10) antworten. Wenn eine erforderliche Quittierung nicht innerhalb einer vorgegebenen Zeitspanne empfangen wird oder eine negative Quittierung empfangen wird, muss der Sender die Nachricht erneut senden.
Die Kopfprüfsumme wird durch Addieren aller in dem Kopf enthaltenen Wörter und durch Ausführen eines Zweierkomplementes an der Summe berechnet, mathematisch ausgedrückt als (von dem NavCore-Schnittstellenprotokoll):
Kopfprüfsumme = –SUMME falls SUMME ≠ –32768 Kopfprüfsumme = SUMME falls SUMME = –32768
Wobei gilt:

1. Die unäre Negation wird wie das Zweierkomplement eines 16-Bit-Datenwortes berechnet.
2. Mod 2¹⁶ gibt die niedrigsten 16 Bits eines Rechenprozesses an (nur die unteren 16 Bits werden erhalten).
3. Die Summierung ist die algebraische Binärsumme der durch das Subskript (I) angegebenen Wörter.
4. Der Summenwert –32768 muss als Sonderfall behandelt werden, da er nicht negiert werden kann.

Die meisten Standardnachrichten, die zum Kommunizieren mit dem NDC-Server eingesetzt werden, verfügen über einen Datenabschnitt, wie in Tabelle 92 dargestellt. Die Datenwortanzahl in dem Nachrichtenkopf gibt die Anzahl von Datenwörtern in dem Datenabschnitt an, wobei es sich um 16-Bit-Datenwörter handelt, die eine Nachricht in dem durch die Standardnachrichtentyp-ID angegebenen Format bilden. Nachrichten ohne Datenabschnitt haben keine Datenprüfsumme. Nachricht mit einem Datenabschnitt verfügen dagegen über eine Datenprüfsumme, die auf dieselbe Weise wie die Kopfprüfsumme berechnet wird. Der einzige Unterschied zwischen den beiden Berechnungen besteht darin, dass die Kopfprüfsumme unter Verwendung der ersten vier Wörter des Kopfes berechnet wird, während die Datenprüfsumme unter Verwendung aller Datenwörter vor dem Datenprüfsummenfeld berechnet wird.
Jedes Byte der Standardnachricht wird mit den Bits in der Reihenfolge von dem niedrigstwertigen zu dem höchstwertigen Bit übertragen, d. h. das niedrigstwertige Bit wird als erstes gesendet/empfangen. Bei jedem Wort wird das niedrigstwertige Bit zuerst gesendet.
Die für die NDC-Server-/DMCS-Schnittstelle eingesetzten Nachrichtenformate sind wie folgt. Mit Bezug auf Befehls-/Antwortnachrichten und Nachrichtenanforderungs-/-antwortfolgen, die möglicherweise durch den NDC-Server 42 ausgelöst werden, gilt, dass sobald ein DMCS 27 eine Verbindung zu dem NDC-Server hergestellt hat, er bereit sein muss, falls erforderlich durch den Server gesendete Nachrichten zu empfangen und auf sie zu antworten. Die Nachrichtentyp-ID 71XX kennzeichnet Nachrichten, die durch den NDC-Server ausgelöst werden, während erforderliche Antworten auf diese Nachrichten durch die Nachrichtentyp-ID 73XX gekennzeichnet werden (wie in Tabelle 90 dargestellt).
DMCS-Anwendungen mit Wählverbindung müssen sich zwei Mal anmelden. Eine Modembank von U.S. Robotics und ein Radius-Server führen die erste Anmeldung unter Verwendung von PPP-Anmelde-Eingabeaufforderungen aus, um eine Authentifizierung der Benutzer-ID und des -Passwortes anzufordern. Wenn ein DMCS mit Wählverbindung erfolgreich bei dem Netzwerk angemeldet ist, kann es eine Verbindung zu einer TCP-Anschlussstelle auf dem NDC-Server herstellen, zu welchem Zeitpunkt der Server eine „Anmeldungsinfo-Anforderungs"-Nachricht (7101, Tabelle 93) an den DMCS, der die Verbindung herstellt, für die Authentifizierung gegenüber dem Server sendet. Dasselbe Paar aus Benutzer-ID/-Passwort, das für das Anmelden bei der Modembank eingesetzt worden ist, wird als Antwort in einer „Anmeldungsinfo-Antwort"-Nachricht (7301, Tabelle 94) gesendet. Eine „Anmeldungsinfo-Antwortergebnis"-Nachricht (7107, Tabelle 95) wird durch den NDC-Server zurückgegeben, um das Ergebnis des Anmeldungsversuchs anzuzeigen. Die zweifache Anmeldung ist erforderlich, um den Zugriff sowohl auf das NDC-Servernetzwerk als auch den NDC-Server selbst zu steuern, und wird vor den Benutzern des DMCS mit Wählverbindung verborgen. DMCS-Anwendungen mit TCP/IP-Verbindungsfähigkeit mit dem NDC-Server müssen sich nicht bei der Modembank anmelden, sondern stellen einfach eine Verbindung mit einer TCP-Anschlussstelle auf dem NDC-Server her und antworten auf die „Anmeldungsinfo-Anforderungs"-Nachricht.
Wenn Nachrichten (Text-, vordefinierte oder Einsatzortsabfertigungs-Nachrichten) an die Verfolger gesendet werden, kann ein Timeout-Wert angegeben werden. Wenn eine Nachricht nicht vor ihrem angegebenen Timeout-Wert quittiert wird, sendet der NDC-Server eine „Nachrichten-Timeout"-Nachricht (7107, Tabelle 96), um anzuzeigen, dass die Nachricht nicht quittiert wurde und dass kein weiterer Versuch gemacht wird, die Nachricht zu senden, sofern nicht eine Anforderung zum erneuten Senden gestellt wird. An mehrere Verfolger gesendete Nachrichten können durch eine Teilmenge der ursprünglichen Empfängerliste quittiert werden. Die in dem „Nachrichten-Timeout" aufgeführten Verfolger-IDs sind für diejenigen Verfolger bestimmt, die die Nachricht nicht vor dem Timeout quittiert haben.
Die NDC-Bedienstationen haben die Option, eine „NDC-Befehls"-Nachricht (7102, Tabelle 97) an die CCSs zu senden, die mit dem DMCS verbunden sind, um die CCS-Benutzer über wichtige Ereignisse zu informieren (z. B. eine Systemabschaltwarnung während des Testens). Ein DMCS, der eine „NDC-Befehls"-Nachricht empfängt, antwortet unter Verwendung einer „NDC-Befehlsantwort"-Nachricht (7302, Tabelle 98) und leitet sie an alle CCSs weiter.
Während der DMCS mit dem NDC-Server verbunden ist, empfängt er Echtzeit-Verfolgungsdaten von dem Server in einer „Echtzeit-Verfolgungsdaten"-Nachricht (7103, Tabelle 99) für zu dem jeweiligen Kunden gehörige Verfolger. Solche Nachrichten, die Nachrichten mehrerer verschiedener Typen enthalten können, z. B. Verfolgerstandort, Verfolgergeschwindigkeit, Verfolgerkurs, von einem Verfolger empfangene Benutzerdaten, Nachrichtenquittierungen/-antworten und Einsatzortsstatus-Informationen, werden an den DMCS gesendet, sobald sie durch den Server empfangen werden. Verfolgungsdaten-Nachrichten für Verfolger mit kontinuierlichem Verfolgungsdienst oder reinem Anmeldungsverfolgungsdienst (reine Anmeldungsverfolgung – Jogin only tracking – LOT) werden mit einer Rate empfangen, die durch die zugehörige aktive Aktualisierungsrate des Verfolgers angegeben wird. Und für Verfolger mit manuellem Verfolgungsdienst werden Verfolgungsdaten-Nachrichten als Folge einer Anforderung empfangen, die durch den DMCS mit einer Nachricht zum Senden einer Verfolgungsanforderung gestellt wurde. Das Format einer Echtzeit-Verfolgungsdatennachricht wird in Tabelle 100 dargestellt.
Wie zuvor hier beschrieben, verfügen die Verfolger über eine Fähigkeit zu erfassen, wann die Zündung der zugehörigen Fahrzeuge ein- oder ausgeschaltet worden ist. Wenn ein Verfolger sich in dem HF-Netzwerk befindet und die Zündung eines Fahrzeugs für eine vorgegebene Zeitspanne ausgeschaltet wird, fordert der Verfolger einen Niedrigenergie-Schlitz von dem NDC-Server an. Nach dem Empfangen seines Niedrigenergie-Schlitzes fährt der Verfolger bis unmittelbar vor seiner nächsten Aktualisierung herunter. Die Verfolger stellen weiterhin Aktualisierungen in diesem Schlitz bereit, während die Zündung ausgeschaltet bleibt oder die Batteriespannung des Fahrzeugs unter einem Mindestwert liegt. Eine „Verfolger-Energiemodus"-Nachricht (7107, Tabelle 101) wird jedes Mal, wenn ein Verfolger, für den er verantwortlich ist, den Energiemodus ein- oder ausschaltet, an den anwendbaren DMCS gesendet, Wenn der DMCS oder die NDC-Bedienstation ein Verfolgerprofil aktualisieren, werden die aktualisierten Profilinformationen in Form einer „Verfolgerprofil-Aktualisierungs"-Nachricht (7104, Tabelle 102) mit dem in Tabelle 103 dargestellten Verfolgerprofilformat an alle angeschlossenen DMCS-Anwendungen weitergeleitet, die mit dem Profil verknüpft sind.
Der NDC-Server 42 verwaltet nicht die Einbauhistorie für die Verfolger, kann aber den DMCS (z. B. 27) abfragen, um festzustellen, wann Verfolger in Fahrzeuge eingebaut oder aus ihnen ausgebaut worden sind. Eine Nachricht zum „Abrufen der Verfolger-Einbauhistorie" (7105, Tabelle 104) ermöglicht dem NDC-Server, einen Einbaudatumsbereich anzugeben. Durch den DMCS wird eine Nachricht mit der „Antwort auf das Abrufen der Verfolger-Einbauhistorie" (7305, Tabelle 105) eingesetzt, um Informationen für den NDC-Server für alle Verfolger bereitzustellen, die während des angegebenen Zeitraums eingebaut worden sind. Da die Antwortnachricht recht groß sein kann, wird eine einzelne Antwortnachricht für jeden eingebauten Verfolger zurückgegeben. Ein beispielhafter Verfolgereinbau-Datensatz wird in Tabelle 106 dargestellt.
Der DMCS 27, der für die Verwaltung von Fahrzeugprofil-Informationen (z. B. die Fahrgestellnummer (vehicle identification number – VIN), Bundesstaat, Zulassung, Marke, Modell, Jahr) zuständig ist, stellt diese Informationen für den NDC-Server 42 in Form einer Nachricht zum „Abrufen der Fahrzeugprofilliste" (7106, Tabelle 107) auf Anforderung bereit. Der NDC-Server stellt diese Anforderung üblicherweise, wenn ihm eine VIN (von der er durch die Nachricht zum „Abrufen der Antwort zur Verfolgereinbauhistorie" erfahren hat) bekannt ist und er zusätzliche Informationen über das Fahrzeug benötigt. Wenn die VIN nicht bekannt ist, kann das „Abrufen des Fahrzeugprofils durch eingebauten Verfolger" eingesetzt werden. Eine Nachricht zum Abrufen der Fahrzeugprofillisten-Antwort und das Fahrzeugprofilformat werden jeweils in den Tabellen 108 und 109 dargestellt.
Sobald ein DMCS sich erfolgreich bei dem NDC-Server angemeldet hat, kann es Befehlsnachrichten mit einer Nachrichtentyp-ID von 72XX an den Server senden. Alle Antworten von dem Server auf diese Befehlsnachrichten werden durch die Nachrichtentyp-ID 74XX identifiziert. Befehls-/Antwortnachrichten und Nachrichtenanforderungs-/-antwortfolgen, die durch einen angemeldeten DMCS initiiert werden, werden unten erörtert.
Wenn Nachrichten (Text-, vordefinierte oder Fahrzeugabfertigungs-Nachrichten) an die Verfolger gesendet werden, wird eine Nachrichtenfolgen-ID mit der Nachricht verknüpft. Nachrichten mit ausstehender Quittierung können durch Senden einer Nachricht zum „Abbrechen" (7215, Tabelle 110) mit der verknüpften Nachrichtenfolgen-ID, gefolgt von einer Nachricht zum „Abbrechen der Nachrichtenantwort" (7415, Tabelle 111), abgebrochen werden.
Es ist eine Verknüpfung aus Benutzer-ID und -Passwort für einen Zugriff über eine Wählverbindung oder einen TCP-Zugriff auf den NDC-Server erforderlich. Benutzer, die sich bei dem NDC-Servernetzwerk und der -anwendung anmelden, verwenden dieselbe Benutzer-ID und dasselbe Benutzerpasswort für beides. Sobald sich ein Benutzer bei dem NDC-Server angemeldet hat, kann eine Nachricht zum „Ändern des Kontopasswortes" (7201, Tabelle 112) eingesetzt werden, um das Passwort zu ändern, worauf durch eine Nachricht für die „Antwort auf das Ändern des Kontopasswortes" (7401, Tabelle 113) geantwortet wird.
Wenn ein Verfolgerprofil in die NDC-Server-Datenbank eingegeben wird, wird ein Verfolgungsdienst als Teil des Profils eingegeben. Jeder Verfolger verfügt über einen Verfolgungsdienst, wobei gültige Verfolgungsdienste die kontinuierliche Verfolgung, LOT und die manuelle Verfolgung sind. Verfolger mit kontinuierlichem Verfolgungsdienst senden ihre Verfolgungsinformationen periodisch, selbst wenn kein DMCS mit dem NDC-Server verbunden ist, um diese Informationen zu empfangen. Verfolger mit LOT-Dienst senden ihre Informationen periodisch, wenn ein DMCS mit dem NDC-Server verbunden ist, um diese Verfolgungsinformationen zu empfangen. Verfolger mit manuellem Verfolgungsdienst senden ihre Verfolgungsinformationen auf Anforderung. Für den kontinuierlichen und den LOT-Dienst wird darüber hinaus eine Aktualisierungsrate (in Sekunden) als Teil des Profils eingegeben, um die periodische Rate anzugeben, mit der der Verfolger seine Verfolgungsinformationen sendet, wobei die Rate eingesetzt wird, um anfänglich die aktive Aktualisierungsrate eines Verfolgers einzurichten, wenn ein Verfolger erstmals berechtigt ist, in das Funknetz einzutreten. Es kann eine Nachricht zum „Ändern des Verfolgungsdienstes" (7202, Tabelle 114) gesendet werden, um den Verfolgungsdienst und die zugehörige Aktualisierungsrate zu ändern, auf die eine Nachricht für die „Antwort auf das Ändern des Verfolgungsdienstes" (7402, Tabelle 115) folgt.
DMCS-Anwendungen können eine „fing-Anforderungs"-Nachricht (7203, Tabelle 116) senden, um ihre Verbindung mit dem NDC-Server zu überprüfen. Wenn eine „Ping-Antwort"-Nachricht (7403, Tabelle 117) empfangen wird, ist die Verbindung aktiv, und der NDC-Server ist einsatzbereit.
Es wird auf die oben beschriebene, durch den NDC-Server gesendete „Nachrichten-Timeout"-Nachricht zurückverwiesen, wobei eine Nachricht zum „erneuten Senden" (7216, Tabelle 118) an den Server gesendet wird, um anzuzeigen, dass eine Nachricht erneut an Verfolger aus der ursprünglichen Liste von Empfängern gesendet werden sollte, denen es nicht gelungen ist, die Nachricht vor der Timeout-Periode zu quittieren, gefolgt von einer Nachricht zum „erneuten Senden einer Antwortnachricht" (7416, Tabelle 119).
Wie bei der oben beschriebenen Zuständigkeit des DMCS für die Verwaltung und Pflege der Fahrzeugprofil-Informationen und dem Einsatz einer Liste zum Abrufen des Fahrzeugprofils pflegt der NDC-Server ein Informationsprofil für jeden Verfolger, das Informationen zum Identifizieren des Verfolgers enthält. Die Informationen umfassen die Aktualisierungsrate, den Diensttyp und die Dienstflags des Verfolgers. Es wird eine Nachricht zum „Abrufen der Verfolgerprofilliste" (7204, Tabelle 120) zum Abrufen einer Liste von mit einem Kundenkonto verknüpften Verfolgerprofilen gesendet. Die zurückzugebende Liste kann durch Angeben der Verfolger-IDs beschränkt werden. Die geeignete Antwortnachricht (7404) wird in Tabelle 121 dargestellt. Textnachrichten können an Fahrzeuge gesendet werden, die mit einem Verfolger und einem MDE ausgestattet sind. Eine „Senden"-Nachricht (7205, Tabelle 122) weist den NDC-Server an, eine Textnachricht an alle Verfolger, die mit dem anfordernden Benutzer verknüpft sind, oder an eine Liste einzelner Verfolger, die durch eine Verfolger-ID identifiziert werden, zu senden. In Tabelle 123 werden vordefinierte beispielhafte Nachrichten-Antwort-Sätze dargestellt. Wenn der NDC-Server erfolgreich eine zu sendende Nachricht in eine Warteschlange einstellt, wird eine Nachricht zum „Senden einer Antwortnachricht" (7405, Tabelle 124) eingesetzt, um eine Nachrichtenfolgen-ID anzugeben, die mit der Nachricht verknüpft ist, die gesendet wird. Wenn eine Nachricht erfolgreich durch einen Verfolger quittiert wird und/oder eine Antwort erhält, empfängt der DMCS ein „Nachrichtenantwort- und Benutzerdaten"- oder ein „Kurznachrichtenantwort- und Benutzerdaten"-Paket innerhalb einer „Echtzeit-Verfolgungsdaten"-Nachricht (oben erörtert), die dieselbe Nachrichtenfolgen-ID enthält.
Es können darüber hinaus vordefinierte Textnachrichten an Fahrzeuge mit einem Verfolger und einem MDE gesendet werden. Eine Nachricht zum „Senden der ID einer vordefinierten Nachricht" (7206, Tabelle 125) weist den NDC-Server an, eine ID einer vordefinierten Nachricht an alle Verfolger zu senden, die mit dem anfordernden Benutzer verknüpft sind, oder an eine Liste einzelner Verfolger, die durch eine Verfolger-ID identifiziert werden. Wenn der NDC-Server erfolgreich eine zu sendende Nachricht in eine Warteschlange einstellt, wird eine Nachricht mit der „Antwort auf das Senden einer ID einer vordefinierten Nachricht" (7406, Tabelle 126) eingesetzt, um eine Nachrichtenfolgen-ID anzugeben, die mit der Nachricht verknüpft ist, die gesendet wird. Wenn eine Nachricht erfolgreich durch einen Verfolger quittiert und/oder eine Antwort erhält, empfängt der DMCS ein „Nachrichtenantwort- und Benutzerdaten"- oder ein „Kurznachrichtenantwort- und Benutzerdaten"-Paket innerhalb einer „Echtzeit-Verfolgungsdaten"-Nachricht, die dieselbe Nachrichtenfolgen-ID enthält.
Eine Nachricht zum „Senden einer Einsatzortsabfertigung" (7207, Tabelle 127) wird eingesetzt, um das Abfertigen und Automatisieren des Aufzeichnens der Ankunft/Abfahrt am bzw. vom Einsatzort zu erleichtern. Sie wird durch den DMCS an einen Verfolger gesendet, um einen Einsatzortsbereich und eine Nachricht (z. B. die Straßenanschrift eines Einsatzortes) anzugeben, die dem Fahrzeugbediener angezeigt werden sollen. Es kann ein vordefinierter oder ein kundenspezifischer Antwortsatz definiert werden, um eine manuelle Antwort zu ermöglichen. Bei der Ankunft/Abfahrt an/von dem durch die Nachricht definierten Einsatzort sendet der Verfolger ein „Einsatzortsstatus"-Paket innerhalb einer „Echtzeit-Verfolgungsdaten"-Nachricht, um die Ankunft/Abfahrt am/vom Einsatzort anzuzeigen, entweder aufgrund der Bestimmung des Verfolgers auf Basis seiner Breite/Länge relativ zu dem Einsatzortsbereich oder des Fahrzeugbedieners, der das MDE einsetzt, um die Ankunft/Abfahrt des Verfolgers an/von dem Einsatzort anzuzeigen, und eine nachfolgende Nachricht für die „Antwort auf das Senden der Einsatzortsabfertigung" (7407, Tabelle 128).
Eine Nachricht zum „Senden von Benutzerdaten" (7208, Tabelle 129) weist den NDC-Server an, eine Textnachricht an alle Verfolger, die mit dem anfordernden Benutzer (Kunden) verknüpft sind, oder an eine Liste einzelner Verfolger, die durch eine Verfolger-ID identifiziert werden, zu senden. Wenn der NDC-Server erfolgreich eine zu sendende Nachricht in eine Warteschlange einstellt, wird eine Nachricht mit einer Antwort auf das „Senden von Benutzerdaten" (7408, Tabelle 130) eingesetzt, um eine Nachrichtenfolgen-ID anzugeben, die mit der Nachricht verknüpft ist, die gesendet wird. Wenn eine Nachricht erfolgreich durch einen Verfolger quittiert wird, empfängt der DMCS ein „Nachrichtenantwort- und Benutzerdaten"- oder ein „Kurznachrichtenantwort- und Benutzerdaten"-Paket innerhalb einer „Echtzeit-Verfolgungsdaten"-Nachricht, die dieselbe Nachrichtenfolgen-ID enthält.
Verfolger, die über einen manuellen Verfolgungsdienst verfügen, senden ihre Verfolgungsinformationen nur auf Anforderung. Eine Nachricht zum „Senden einer Verfolgungsanforderung" (7209, Tabelle 131) ermöglicht dem DMCS, Verfolgungsinformationen von einem bestimmten Verfolger anzufordern. Wenn ein Verfolger erfolgreich eine Verfolgungsinformations-Anforderung empfängt, sendet er seine Verfolgungsinformationen während des nächsten verfügbaren Zeitschlitzes, der für eine solche Übertragung reserviert ist, und der anfordernde DMCS empfängt eine „Echtzeitdaten"-Nachricht mit den angeforderten Verfolgungsinformationen. Eine Nachricht mit einer „Antwort auf das Senden einer Verfolgungsanforderung" (7409) wird in Tabelle 132 dargestellt.
Wenn der DMCS einen Verfolgerinstallations-Datensatz erstellt/aktualisiert/ändert, wird der Datensatz an den NDC-Server als eine Aktualisierung weitergeleitet, die in Form einer „Verfolgerinstallations-Datensatzaktualisierungs"-Nachricht (7210, Tabelle 133) gesendet wird. Wenn der DMCS ein Fahrzeugprofil aktualisiert, werden die aktualisierten Profilinformationen an den NDC-Server in Form einer „Fahrzeugprofil-Aktualisierungs"-Nachricht (7212, Tabelle 134) weitergeleitet.
XIII. Ereignisgesteuerte Statusberichterstattung
Dieser Aspekt der Erfindung stellt ein Verfahren und eine Vorrichtung zum automatischen Bestimmen und Berichten von Ereignissen von einem Fahrzeug an einen Besitzer oder Abfertiger des Fahrzeugs an einem Standort bereit, der entfernt von dem Fahrzeug liegt. Zu berichtende Ereignisse umfassen Änderungen im Status des Fahrzeugbetriebs, des Standortes oder von Messwerten von Fahrzeugsystemen oder Fracht. Der Verfolgungscomputer (Verfolger) in dem Fahrzeug ist an verschiedene Sensoren angeschlossen, die Parameter messen, die für den Fahrzeugabfertiger oder Besitzer relevant sind, und berichtet kritische Änderungen in den Parametern über das TDMA-Netzwerk. CCS-/DMCS-Computer an dem Standort des Kunden zeigen Statusänderungen für den Einsatz durch den Fahrzeugabfertiger an oder speichern die Daten für eine spätere Analyse. Software in dem Verfolger und eine Vielzahl von Sensoren ermöglichen das Bestimmen und Berichten von mehrfachen, komplizierten und abstrakten Statusereignisse, die für bestimmte Fahrzeug- oder Branchenanwendungen relevant sind, durch den Verfolger. Automatisch erzeugte Berichte von den Fahrzeugen ermöglichen das Bereitstellen von erheblich genaueren und zeitgerechteren Daten für den Standort des Kunden, als von den menschlichen Bedienern der Fahrzeuge verfügbar sind.
33 ist ein Schaubild von verschiedenen Typen von Sensoren und/oder Messquellen, die leicht entweder einzeln oder zusammen an den Verfolgungscomputer (Verfolger) 135 angeschlossen werden können bzw. für ihn bereitgestellt werden können, einschließlich bestimmter „grundlegender" Sensoren, analoger Eingänge, diskreter Eingänge, TPU-Eingänge und serieller Schnittstellen zu dem Verfolger, die für nahezu jeden Mess- und Steuerzweck konfiguriert werden können. Eine erweiterte Liste von Sensoreingaben wird unten dargelegt. Diese fallen in die beiden breiten Kategorien von (1) grundlegenden Fahrzeugfunktionen und (2) Betriebsfunktionen des Fahrzeugs, die für die Branche spezifisch sind, in der es eingesetzt wird. Betriebsfunktionen erfordern das Hinzufügen von Sensoren zu einem Standardfahrzeug. Der Leser wird darüber hinaus auf 23 zurückverwiesen, die bestimmte besonders bedeutende Sensoren von Betriebsfunktionen für Transportbeton-Lastwagen darstellt, wie zum Beispiel für Lastwagen 195 – einen Trommeldrehungssensor 281 und einen Spülwasserdurchfluss-Erfassungssensor 281 – wie auch einen verallgemeinerten Satz von Eingaben 280 in den Verfolger 135 von Sensoren/Messquellen der Typen, auf die in diesem Abschnitt der Patentschrift hingewiesen wird.
Grundlegende Fahrzeugfunktionen oder -parameter, die direkt durch den Verfolger gemessen werden, können von Fahrzeug zu Fahrzeug variieren, umfassen aber üblicherweise Folgendes:

• Fahrzeugzündung und Laufzeit
• Scheinwerfer
• Rückwärtsgang
• Radgeschwindigkeit (von dem Getriebe)
• Beifahrer-/Fahrertür offen
• Allradantrieb eingeschaltet
• Krankenwagen-Einsatzbeleuchtung/Sirenen
• Kraftstofffüllstand
• Kühlflüssigkeitstemperatur
• Öldruck
• Batteriespannung
• Motorwarnungen

Andere Fahrzeugfunktionen erfordern möglicherweise das Hinzufügen von Sensoren für die Messung oder können direkt an Einrichtungen gemessen werden, die zu dem Fahrzeug hinzugefügt werden, um eine Funktion auszuführen, die für das Unternehmen, in dem das Fahrzeug eingesetzt wird, spezifisch ist. Einige typische Parameter oder Funktionen, die in diese Kategorie fallen, sind wie folgt:

• Diebstahl- oder Manipulations-Alarm
• Frachttür offen
• Frachttemperatur
• Fahrzeuggewicht
• Zuschalten des Nebenabtriebs: Nebenabtriebe (Power TakeOffs – PTOs) können eine breite Palette von Geräten antreiben einschließlich: – Pumpen – Winden – Kräne – Einzugsschnecken
• Parameter und Toleranzprüfung des Motordatenbusses
• Kippbox oben oder Luke offen
• Betonmischtrommeldrehgeschwindigkeit und -richtung
• Betonmischwaschwasserverwendung
• Betonmischfüllwasservolumen

Fahrzeugfunktionen werden mit Standort- und Geschwindigkeitsinformationen von dem Navigationssystem verknüpft. Eine Wechselbeziehung von Messungen mit der Fahrzeugbewegung ermöglicht, dass Ereignisse auf Basis des Fahrzeugstandortes ausgelöst werden oder dass gemessene Daten als zulässiger Betriebsvorgang eines Fahrzeugs gekennzeichnet werden – oder als Ausnahme von normalen Betriebsabläufen, wie zum Beispiel das Öffnen einer Frachttür außerhalb der normalen Lade-/Entladebereiche des Kunden oder des Unternehmens.
In dieser Hinsicht ermöglicht das System dem Besitzer oder Abfertiger des Fahrzeugs, rechteckige Bereiche auf einer gespeicherten Karte des relevanten Stadtgebietes zu definieren, zum Beispiel einen Bereich 300, wie in 34 dargestellt. Die Ecken, die die Bereiche definieren (z. B. 301, 302, 303, 304 für Bereich 300), werden an die Fahrzeuge gesendet, so dass der Verfolger auf Basis seiner Navigationslösung feststellen kann, ob er sich innerhalb oder außerhalb eines bestimmten Bereichs befindet. Diese Bereiche werden üblicherweise so eingerichtet, dass sie Heimat- oder Fabrikstandorte, an denen Fahrzeuge gewöhnlich stationiert sind oder Fracht aufnehmen, oder Einsatzorte, an denen Fahrzeuge gewöhnlich abgefertigt werden, um Fracht zu liefern oder einen Dienst auszuführen, identifizieren.
Die Bereiche können darüber hinaus Kartenregionen für andere Zwecke definieren, wie zum Beispiel Geschwindigkeitsbeschränkungen, Gewichtsbeschränkungen oder Grenzen, die das Fahrzeug nicht überfahren darf. Unter Verwendung ausschließlich der Navigation kann der Verfolger Folgendes berichten:

• Zwischen den Bereichen zurückgelegte Entfernung
• Motor an und aus
• Fahren jenseits einer festgelegten Geschwindigkeit
• Fahren zu ungeeigneten Zeiten
• Unerlaubte Stopps
• Ankunfts- und Abfahrtszeit an und von festgelegten Standorten

Das Verknüpfen von Standortinformationen mit anderen gemessenen Parametern in dem Fahrzeug kann andere Statusereignisse erzeugen, wie zum Beispiel das Einsetzen des Fahrzeugstandortes zum Bestätigen des korrekten Fahrzeugstatus, wobei der Abfertiger benachrichtigt wird, wenn eine Frachttür zu einer ungeeigneten Zeit oder an einem ungeeigneten Ort geöffnet wird, oder das Korrelieren eines Motorproblems mit einem bestimmten Standort, um die zugrundeliegende Situation zu verstehen.
Wenn ein Fahrzeugverfolger Ereignisdaten senden muss, fordert er spezielle Zeitschlitze unter Verwendung eines dieser Zeitschlitze an. Ihm werden daraufhin ausreichende Hilfsberichtszeiten in Intervallen von zwölf Sekunden bewilligt, um seine Daten zu senden. Die gesamte Wartezeit zwischen dem Erfassen eines Ereignisses und der Übertragung von Daten bleibt bevorzugt unter dreißig Sekunden.
Alle durch das Netzwerk geleiteten Daten und anderen Statusinformationen werden auf großen Datenbankservern für späteren Abruf für Berichte über die Fahrzeugaktivität oder -analyse gespeichert. Der Verfolger berichtet, abhängig von dem Ereignis, Ereignisse unter Verwendung verschiedener Typen von Datenpaketen. Ereignisse, die einfach durch direkte Messung einer Eingabe angezeigt werden, werden in einem gemeinsamen Ereignispaketformat berichtet, das die gemessene Eingabe (diskret oder analog) und den neuen Wert angibt. Dabei handelt es sich um Ereignisse wie zum Beispiel „Frachttür offen", „Allradantrieb eingeschaltet" oder „PTO-angetriebene Pumpe eingeschaltet". Diese Daten werden in der Datenbank gespeichert und an die Kundenanwendungen weitergeleitet. Da ein Flottenbesitzer (ein Betreiber oder Teilnehmer) möglicherweise über viele Typen von Fahrzeugen in der Flotte verfügt, und jeder möglicherweise unterschiedliche relevante Ereignisdaten an denselben Eingängen in den Verfolger aufweist, müssen die Daten von Fahrzeug zu Fahrzeug eindeutig identifiziert werden.
Das Identifizieren der Ereignisberichte durch den Verfolger wird durch eine Verfolger-Konfigurationsanwendung erreicht, die in dem NDC abläuft. Wenn ein Verfolger in einem Fahrzeug eingebaut wird und Sensoren an seine Eingänge angeschlossen werden, aktiviert die Konfigurationsanwendung den Verfolger, indem sie ihm einen Befehl für die zugehörigen Eingänge sendet, der Schwellen und Hysterese beim Auslösen eines Ereignisses an dem Eingang identifiziert. Die Konfigurationsanwendung speichert darüber hinaus die Verknüpfung jedes Eingangs des Verfolgers mit einem bestimmten Ereignistyp wie zum Beispiel „Frachttür offen". In komplizierteren Situationen, in denen ein Fahrzeug über einen ausführlichen Satz an Logik verfügt, um festzustellen, wann Ereignisse auftreten und welchen Typ sie haben, zum Beispiel bei einem Transportbeton-Lastwagen oder einem Krankenwagen, sendet die Konfigurationsanwendung einen Befehl an den Verfolger des Fahrzeugs, um den gesamten Abschnitt der Software zum Verarbeiten von Eingaben zu aktivieren. In diesen Fällen werden branchenspezifische Datenpakete durch die Verfolger gesendet, um ausführliche Ereignisstati und -daten dem Ereignis entsprechend zu identifizieren.
Eine Reihe von bestimmten Anwendungen für das ereignisgesteuerte Berichten von Fahrzeugstati wird unten beschrieben. Beispiele für Anwendungen auf bestimmte Branchen, als Erläuterung und nicht als Beschränkung, sind wie folgt: Transportbeton, Transport von pulverisiertem Schüttgut, Transport von Schüttgestein und Ambulanzbetrieb. Es ließen sich zahlreiche weitere Beispiele für Anwendungen aufzählen, die eine automatisierte Ereignisberichterstattung erfordern. Die Kombinationsmöglichkeiten und Anwendungen von Parametern, die gemessen und berichtet werden können, sind nahezu unbegrenzt.
A. Transportbeton
Während der effiziente Einsatz von Sachanlagen für jedes Unternehmen wichtig ist, ist er besonders wichtig für die Transportbetonbranche. Es handelt sich dabei vorwiegend um eine Lieferbranche, da das gelieferte Produkt im Wesentlichen eine Massenware ist und sich die Rohmaterialkosten der einzelnen Zulieferer nicht nennenswert unterscheiden. Der Unterschied zwischen Gewinn und Verlust in dieser Branche entsteht daher durch den effizienten Einsatz von sehr teuren Transport-Anlagegütern.
Der Betonmisch-LKW verfügt über eine eindeutig definierte Folge von Ereignissen, die er während des Prozesses des Auslieferns von Beton durchläuft und die im Allgemeinen die folgenden Schritte umfassen:

1) Ladung
2) Abfahrt von Fabrik
3) Ankunft am Einsatzort
4) Beginn des Ausschüttens
5) Ende des Ausschüttens
6) Waschen
7) Verlassen des Einsatzortes
8) Ankunft an der Fabrik

Es ist bekannt, dass die Transportbetonbranche ein Verfahren gesucht hat, um diese Ereignisse dem Fahrzeugabfertiger in einer kostengünstigen, zeitgerechten und genauen Weise anzuzeigen. Eine zuverlässige Anzeige dieser Ereignisse für den Fahrzeugabfertiger führt zu dem effizientesten Einsatz des Fuhrparks. Wenn dem Fahrzeugabfertiger die Arbeitsstufe jedes LKW bekannt ist, kann er für die nächsten Ladungen die LKWs auswählen, die am besten verfügbar sind. Dies trifft insbesondere zu, wenn vorgesehene Zeitpläne durch Kundenanforderungen oder Lieferverzögerungen geändert werden. Transportbeton-Unternehmen haben für diese Ereignisse üblicherweise Sprachmeldungen der Fahrer oder fahrerbediente Statusboxen eingesetzt.
Der Einsatz von Sprach- und Statusboxen erfährt eine grundlegende Begrenzung dadurch, dass der Fahrer aktiv werden muss, um den Fahrzeugabfertiger über seine aktuelle Arbeitsstufe zu informieren. Selbst kooperative Fahrer vergessen zu häufig, den Fahrzeugabfertiger zu informieren. Die Branche schätzt, dass weniger als 10% der auf diese Weise bereitgestellten Daten korrekt sind. Statusboxen sind Steuerköpfe, die an den Sprechfunk angeschlossen sind, wobei die Statusboxen über mehrere Tasten verfügen, wobei üblicherweise eine Taste bedient wird, um jede der oben erwähnten Lieferphasen anzuzeigen. Ein Vorteil der Statusbox ist, dass Daten von ihr herkömmlichen Abfertigungsanwendungen, die in der Branche eingesetzt werden, zur Verfügung gestellt werden können, um der Abfertigungssoftware zu ermöglichen, den LKW durch die Phasen hindurch ohne manuelles Eingreifen durch den Fahrzeugabfertiger zu verfolgen. Dieser Vorteil wird jedoch aufgrund der Unzuverlässigkeit der Daten von dem Fahrer und der daraus resultierenden Unfähigkeit des Fahrzeugabfertigers, korrekte Entscheidungen für den effizientesten Einsatz der Anlagegüter zu treffen, selten umgesetzt.
Mit den passenden Sensoren in dem Betonmisch-LKW und der passenden Software in dem drahtlosen Datenrechner können die Lieferphasen des Transportbetons automatisch und zuverlässig bestimmt werden. Eine zuverlässige automatisierte Ablaufplanung wird nach diesem Aspekt der vorliegenden Erfindung durch Implementierung von drei Basissensoren in dem LKW wie auch durch zuverlässige Navigation und beteiligte Zustandslogik erzielt. Bei einer bevorzugten Ausführungsform umfassen die Sensoren einen Trommeldrehungssensor 280 (23), der sowohl die Geschwindigkeit als auch die Richtung einer Mischtrommel misst, einen Wasserdurchflusssensor 281, der das Wasser misst, das zum Abwaschen des LKW eingesetzt wird, und einen Türschalter (z. B. verknüpft mit dem Schalter, der eine offene Tür erfasst, um die Innenbeleuchtung in dem Führerhaus des LKW einzuschalten), der anzeigt, wenn die Tür des Fahrers offen steht. Es sind Informationen bezüglich des Standortes und der Geschwindigkeit des Fahrzeugs erforderlich, um festzustellen, wann der LKW sich an einer Fabrik oder an einem Einsatzort (oder unterwegs zu dem Einsatzort) befindet. Die Zustandslogik verknüpft alle diese Informationen, um dem Verfolger zu ermöglichen, jede Phase des Lieferprozesses zurück an den Standort des Teilnehmers zu berichten.
Der Trommeldrehungssensor 280 misst die Geschwindigkeit und die Richtung der Trommel 287 des LKW 195. Bei einer bevorzugten Ausführungsform unterscheidet sich der Sensor 280 von üblichen in Mischlastwagen eingebauten Trommelumdrehungszählern, die Begrenzungsschalter oder Hall-Effekt-Magnet- oder -Näherungsschalter zum Zählen der Trommelumdrehungen einsetzen, indem er stattdessen sowohl die Geschwindigkeit als auch die Richtung genau bereitstellt – Parameter, die zum Unterstützen der Feststellung benötigt werden, wann der LKW beladen wird, wann das Ausschütten des nassen Betoninhalts der Trommel begonnen wird und wann es abgeschlossen ist. Das Laden wird üblicherweise durch Drehen der Trommel in „Füll"-Richtung bei hoher Geschwindigkeit ausgeführt, während das normale Mischen bei viel langsamerer Füllgeschwindigkeit und, während der LKW unterwegs ist, ausgeführt wird. Das Ausschütten wird üblicherweise mit einer sehr langsamen Entleerungsgeschwindigkeit ausgeführt, um die Trommelgeschwindigkeit wird häufig im Laufe des Entleerens der Trommel erhöht. Mit Bezug auf das Blockschaltbild des Trommeldrehungssensors 280 in 35 werden zwei Hall-Effekt-Sensoren 288, 289 Nummer 3240 von Allegro eingesetzt, die ungefähr 5 cm (2 in) voneinander entfernt auf einer Halterung 290 angebracht sind, die oben auf dem Getriebe 291 montiert wird, das die Betonmischtrommel 287 antreibt. Der Sensor 280 wird durch sechs Magnete aktiviert, die um die Trommeldrehachse herum auf der Trägerplatte zwischen dem Getriebe und der Trommel platziert sind. Magnetanordnungen 292, die zum Betätigen des Hall-Effekt-Sensors 288, 289 eingesetzt werden, sind an dem Trommel-Getriebe-Verbindungsflansch 293 angebracht.
Die Schnittstelle zwischen Getriebe und Trommel ist die ideale Position für den Drehungssensor 280, wenn er einem Mischer nach dem Bau hinzugefügt wird. Die direkte Messung von Getriebeumdrehungen pro Minute wird bevorzeugt, ist aber nur durchführbar, wenn das Getriebe im Werk so modifiziert werden kann, dass ein Drehgeschwindigkeits-/Drehrichtungsausgang bereitgestellt wird. Die Getriebeschnittstelle weist gut kontrollierte Abmessungen auf und ist relativ frei von Schadstoffen und von Eingriffen durch den Fahrer. Sie ist darüber hinaus bei Mischern mit Vorder- und Rückentleerung verbreitet. Andere mögliche Positionen für die Sensorplatzierung, wie zum Beispiel die Zwischenräder an der Trommelöffnung oder zwischen dem Mittelpunkt der Trommel und dem LKW-Chassis, weisen Nachteile auf, zu denen die Maßabweichungen von Hersteller zu Hersteller und von Fahrzeugmodell zu Fahrzeugmodell gehören. Diese Positionen sind darüber hinaus in höherem Maße Fett, Schmutz, Beschädigung und unterschiedlichen Spaltabständen aufgrund von Biegungen des LKW-Fahrgestells und des Herausspringens der Trommel aus ihren Zwischenrädern ausgesetzt.
Die Oberseite der Standard-Getriebeschnittstelle weist Montagelöcher auf, die für Ölkühler und Wasserbehälter vorhanden sind und die für die Montage von Sensoren eingesetzt werden können. Trotz der erheblichen Größe eines Betonmisch-LKW 195 (23) sind die Abstände um die Getriebeschnittstelle sehr gering. Darüber hinaus besteht nur ein Abstand von ungefähr 2,54 cm (1 inch) zwischen den Bolzen, die die Trommel an der Trägerplatte befestigen, und dem Sockel, auf dem das Getriebe montiert ist. Die Möglichkeiten zum Montieren von Magneten sind begrenzt, wenn werksseitig eingebaute Umdrehungszähler aufgenommen werden müssen. Diese Sensoren liegen in verschiedenen Ausführungen vor einschließlich als Reedschalter unter Verwendung einer ähnlichen Magnetbolzen-Ausführung, als Begrenzungsschalter, die durch einen an einem der Trommelbolzen befestigten Flansch betätigt werden, oder als Näherungssensoren, die durch einen Flansch unmittelbar außerhalb des Trägerplattenradius betätigt werden.
Um Magnete in dem Trommelbolzenradius der Trägerplatte der Mischlastwagen aller Hersteller zu montieren, wird eine Magnethalteklammer eingesetzt. Bei heutigen Mischlastwagenmodellen werden die folgenden Gestaltungen unterstützt: (1) keine Klammer, (2) eine einzelne Klammer, die eingesetzt wird, um einen Umdrehungszähler-Aktivierungsmagneten zu versetzen oder (3) sechs Klammern, um Magneten im Radius zu halten, wenn keine Bolzenlöcher verfügbar sind. Mischer von den meisten Herstellern, die ZF-Getriebe einsetzen, benötigen die Klammer nicht. In diesen Fällen sind sechs Gewindebohrungen in der Trägerplatte zum Bestücken mit Magnetbolzen verfügbar. Von McNeilus hergestellte Mischer mit ZF-Getrieben verfügen über einen Reedschalter-Umdrehungszähler, der durch einen werksseitig eingebauten Magnetbolzen in der Trägerplatte in Betrieb gesetzt wird, der durch eine Magnetniete ersetzt wird, die durch die Klammer von dem normalen Bolzenradius versetzt wird. Der Reedschalter wird von seiner Werksklammer zu einem Loch in der neu montierten Geschwindigkeits- und Richtungssensorklammer umgesetzt. EIP-Getriebe bestücken bis auf zwei alle Löcher in der Trägerplatte mit Bolzen, um die Trommel am Getriebe festzuhalten. Für dieses Getriebe wird die Klammer um 90 Grad gedreht und gewendet, so dass die Magnetniete zwischen den Bolzen gehalten wird, die die Trommel mit der Platte verbinden. Es werden entweder sechs Klammer-Nieten-Anordnungen oder eine Kombination aus zwei Magnetbolzen und vier Klammer-Nieten-Anordnungen eingesetzt.
Der Sensor 280 bei dieser beispielhaften Ausführungsform verfügt über eine Vierdrahtschnittstelle 294 zu dem Verfolger 135: Leistung, Erde und eine Signalleitung von jedem Hall-Effekt-Sensor. Die Signale stellen Eingaben in die TPU des Mikrocontrollers (CPU) 68332 von Motorola für den Verfolger dar. Die TPU verfügt über dedizierte Hardware zum Messen vom Impulsen mit sehr exaktem Takt. Wenn ein Magnet an der Trommel an einem Sensor vorbeigeführt wird, gibt der Sensor einen abfallenden Impuls aus. Es wird nun auf 36 Bezug genommen, die ein Taktdiagramm der aus der Wechselwirkung der Sensoren und des Magneten bei der Trommelumdrehung resultierenden Impulse darstellt, wobei die beiden Sensoren 288, 289 jeweils als A bzw. als B gekennzeichnet sind, und eine einfache Feststellung der Geschwindigkeit und Richtung der Trommel 287 vorgenommen wird. Die Geschwindigkeit wird durch zwei aufeinander folgende Impulse 295, 296 von dem Sensor A festgestellt. Die Zeit zwischen den Impulsen (T_A/A) in Sekunden dividiert durch 6 Magnete (Impulse) pro Umdrehung multipliziert mit 60 Sekunden in einer Minute ergibt die Getriebeumdrehungen pro Minute. Die Höchstgeschwindigkeit einer Betonmischtrommel liegt bei ungefähr 16 1/min. Die Richtung wird durch den relativen Takt der durch beide Sensoren erfassten Impulse festgestellt. Wenn die Zeit zwischen einem Impuls 295 an Sensor A und einem Impuls 297 an Sensor B (T_A/B) kürzer ist als die Zeit bis zum nächsten Impuls 296 an Sensor A (T_A/A), dreht sich die Trommel in Richtung von A nach B, wobei es sich um die Füllrichtung handelt. Umgekehrt gilt, wenn die Zeit zwischen einem Impuls an Sensor A und einem Impuls an Sensor B länger ist als die Zeit bis zum nächsten Impuls an Sensor A, dreht sich die Trommel in Richtung von B nach A, wobei es sich um die Entleerungsrichtung handelt.
Der Abstand 298 (35) zwischen den Vorderflächen der Magnete und dem Sensor ist ein wichtiger Faktor. Während des Ladens und unterwegs ist der LKW erheblichen Stoß- und Erschütterungsbelastungen ausgesetzt. Diese Belastungen können dazu führen, dass die Trommel aus ihren Zwischenrädern herausspringt und sich das LKW-Fahrgestell biegt. Mit dem Alterungsprozess der LKWs und Getriebe wächst das Problem. Es wird bevorzugt ein Abstand 298 von zumindest ungefähr 1,905 cm (0,75 in) bereitgestellt, um Schäden an den Sensoren oder Magneten zu vermeiden.
Betonmisch-LKWs verfügen üblicherweise über einen Wasserbehälter, der Wasser unter Druck speichert. Das Wasser wird zum Hinzufügen von Wasser zu der Betonmischung und darüber hinaus zum Abwaschen des LKWs eingesetzt, wenn ein Ausschüttvorgang abgeschlossen ist. Um festzustellen, wann ein Waschvorgang stattfindet, wird das durch den Schlauch fließende Wasser unter Verwendung eines Durchflussschalters gemessen. Der Strömungsschalter löst bei einer vorgegebenen Durchflussvolumenschwelle aus. Es kann eine Reihe von Verfahren für den Durchflussschalter eingesetzt werden, um den Durchfluss zu erfassen, und zwar: der Luftdruck des Wasserbehälters, Wirbelstrom, Differenzdruck durch eine Öffnung und Federspielschieber oder -klappen. Ein Durchflussschalter ist ein bevorzugter Sensor 281 (23) für diese Anwendung, da das Durchflussvolumen nicht von Bedeutung ist, sondern nur die für das Waschen des LKW aufgewendete Zeit. Eine Schlüsselüberlegung bei der Gestaltung eines Durchflussschalters oder -sensors besteht darin, dass er mit Wasser arbeiten muss, das mit Schmutz und Ablagerungen, wie zum Beispiel Steinen und großen Rostteilen verunreinigt ist.
Bei Mischern mit Rückentleerung muss der Fahrer aus dem LKW aussteigen, um vor dem Ausschütten die Schüttrinnen einzurichten. Es wird ein Türschalter eingesetzt, um festzustellen, wann die Tür des Fahrers geöffnet wird. Das Öffnen der Fahrertür wird zum Bestätigen der Ankunft am Einsatzort eingesetzt, ist aber nicht entscheidend für den korrekten Betrieb des Systems.
Ein Zustandsübergangsdiagramm, das die durch den Verfolger eingesetzte Logik definiert, um Sensor- und Navigationsdaten zu verknüpfen, um den Mischestatus automatisch abzuleiten, wird in 37 dargestellt. Die Logik ist zwangsläufig komplex, um alle Abweichungen von dem normalen Betonlieferablauf, die auftreten können, zu berücksichtigen. Es werden Schwellen und Timeouts gesetzt, um um den Preis einer kleinen Verzögerung beim Anzeigen des Ereignisses das falsche Auslösen von logischen Zuständen zu verhindern. Die oben aufgeführten Hauptzustände werden in der Abbildung fett gedruckt dargestellt.
Der Lieferprozess beginnt mit dem Einschalten (310) der LKW-Zündung an der Fabrik (311). Sobald das Navigationssystem initialisiert ist, stellt der in dem LKW eingebaute Verfolger fest, dass er sich an der Fabrik befindet. Mischer werden beladen, indem sie unter der Mischanlage abgestellt werden und die Trommel sehr schnell in Füllrichtung gedreht wird. Dies wird durch den Verfolger festgestellt, wenn über 60 Sekunden hinweg der LKW eine Geschwindigkeit von weniger als 3,22 km/h (2 mph) aufweist, sich der LKW an der Fabrik befindet und sich die Trommelgeschwindigkeit und -richtung in der Nähe der Schnellladeschwelle befinden. Wenn dies festgestellt wird (312), sendet der Verfolger den Ladestatus (313).
Nach dem Laden fährt der LKW üblicherweise zur Waschgrube, wo Wasser zu der Mischung hinzugefügt, Staub von dem LKW abgewaschen und der Wasserbehälter des LKW aufgefüllt wird. Ein Zustand, der erfasst werden kann, aber gewöhnlich nicht von einem Transportbeton-Unternehmen benötigt wird, ist das Feststellen, ob sich der LKW an der Waschgrube (314) befindet. Dies kann durch eine kleine Positionsänderung des LKW und durch Parken nach dem Laden ohne Verlassen der Fabrik festgestellt werden. Als Nächstes verlässt der LKW die Fabrik. Dies wird dadurch festgestellt, dass eine Position außerhalb des vorgegebenen rechteckigen Bereichs (siehe z. B. 34), der die Fabrik definiert, und eine Geschwindigkeit von mehr als ca. 24 km/h (15 mph) vorliegen. Wenn dies festgestellt wird (315), sendet der Verfolger den Status „Abfahrt von Fabrik" (316). Es wird eine Hysterese auf die Überquerung der Bereichsgrenze angewendet, so dass ein LKW, der entlang der Grenze des Bereichs fährt, nicht mehrere „Ankunft an/Abfahrt von Fabrik"-Folgen verursacht.
Ein optimaler Einsatz des Systems erfordert, dass der Fahrzeugabfertiger eine Abfertigungsnachricht an den LKW sendet, die dem Verfolger den rechteckigen Bereich anzeigt, der die Grenzen des Einsatzortes definiert, aber es ist nicht erforderlich, dass der Verfolger einen automatischen Status bereitstellt. Informationen über den Einsatzort ermöglichen es dem Verfolger, die Ankunft am Einsatzort getrennt vom Beginn des Ausschüttens festzustellen, ermöglichen es dem Verfolger, Informationen über Ausnahmen bei Ausschüttvorgängen festzustellen, die abseits von Einsatzorten stattfinden, und ermöglichen es Software zur Routenoptimierung, über zuverlässige Informationen zu Fahrtzeiten zu verfügen.
Die Ankunft am Einsatzort wird dadurch festgestellt, dass der LKW in einen definierten Einsatzbereich einfährt und daraufhin mindesten eine Minute lang mit weniger als ca. 8 km/h (5 mph) fährt oder sich die Tür des Fahrers öffnet, je nachdem welcher dieser Vorgänge zuerst stattfindet (317). Wenn kein Einsatzbereich definiert ist, wird die Ankunft am Einsatzort dadurch festgestellt, dass die Trommel länger als 10 Sekunden in der Entleerungsrichtung läuft (318). Alternativ kann eine Teilumdrehung der Trommel in die Entleerungsrichtung verwendet werden. Wenn diese Voraussetzungen festgestellt werden, sendet der Verfolger den Status „Ankunft am Einsatzort" (319).
Der Beginn der Ausschütt-Bedingung wird festgestellt, wenn die Trommel 20 Sekunden lang oder alternativ während einer oder zwei Umdrehungen in die Entleerungsrichtung läuft. Sobald dies festgestellt wird (320), wird der Beginn des Ausschüttens durch den Verfolger gesendet (321). Dies versetzt die Verfolgersoftware in den Ausschütt-Zustand (322), und sie sucht daraufhin nach einer Bedingung für das „Ende des Ausschüttens".
Das Ende des Ausschüttens kann auf mehrere Arten festgestellt werden. Manche Ausschüttvorgänge werden mit langsamer Entleerungsgeschwindigkeit ausgeführt. Wenn die Trommel beinahe leer ist, wird die Trommel beschleunigt, um den letzten verbleibenden Beton zu entleeren. Wenn die Trommel 10 Sekunden lang mit schneller Entleerungsgeschwindigkeit läuft, nachdem sie mit langsamer Entleerungsgeschwindigkeit gelaufen ist (323), löst dies das Ende des Ausschüttens (324) aus. Wenn zwei Minuten lang Waschwasser verwendet wird (325), wird ebenfalls das Ende des Ausschüttens ausgelöst (326), da die Verwendung solcher Wassermengen beinahe sicher anzeigt, dass der LKW gewaschen wird. Das Ende des Ausschüttens (327) kann darüber hinaus ausgelöst werden, wenn die Geschwindigkeit des LKW mehr als ca. 48 km/h (30 mph) beträgt (328). LKWs können an einem Einsatzort selten so schnell fahren, insbesondere wenn der Ausschüttvorgang noch andauert, da die Ausschüttrinnen üblicherweise an dem LKW befestigt bleiben, bis das Ausschütten abgeschlossen ist. Es kann ein alternatives Verfahren aktiviert werden, wenn Informationen über die Menge des in den LKW geladenen Betons von dem Fahrzeugabfertiger (von einer CSS am Standort des Teilnehmers über den DMCS, den NDC-Server, den NTCC, die SCC, den Unterträger-Modulator und eine FM-Übertragung) für den Verfolger zur Verfügung gestellt werden. In diesem Fall kann das Ende des Ausschüttens besser durch die Anzahl der Umdrehungen geschätzt werden, die erforderlich sind, um die Trommel angesichts eines vorgegebenen, ursprünglich geladenen Volumens zu entleeren. Eine zweite Alternative ist der Einsatz eines Bord-Gewichtsmesssystems, wie zum Beispiel des AW4600 oder des AW5600 von Air-Weigh. Das Leergewicht des LKW kann mit dem Gewicht während des Ausschüttens verglichen werden, und eine Ende des Ausschüttens kann erfasst werden, wenn sich das Gewicht dem Leergewicht nähert.
Der Beginn des Waschens wird durch die Verwendung von Wasser zum Waschen des LKW über einen vorgegebenen Zeitraum festgestellt. Wenn ein Ende des Ausschüttens (324) durch ein Schnellentladungs-Ereignis (323) festgestellt wurde, muss eine Minute lang Wasser verwendet werden (329), um den Waschstatus (330) anzuzeigen. Wenn ein Ende des Ausschüttens (326) durch die Verwendung von Wasser über zwei Minuten hinweg (325) festgestellt worden ist, wird der Waschstatus (331) zusammen mit dem Status „Ende des Ausschüttens" (326) gesendet.
Ein Ereignis „Verlassen des Einsatzortes" wird gesendet, wenn das Fahrzeug den definierten Einsatzort verlässt. Wie in 37 dargestellt, wird eine Absicherung bereitgestellt, um das Senden des Status „Verlassen des Einsatzortes" zu ermöglichen, falls kein Einsatzbereich definiert wurde. Das Verlassen des Einsatzortes (332, 333) wird in jedem Fall festgestellt, wenn die Fahrzeuggeschwindigkeit ca. 48 km/h (30 mph) überschreitet (334). Es ist zu beachten, dass der Zustand des Systems in einigen Fällen zum Ausschütten (322) zurückkehren kann, nachdem das Waschen (331) oder das Verlassen des Einsatzortes (333) erfasst worden sind, wenn die Trommel erneut in Entleerungsrichtung läuft, bevor der LKW zu einem Einsatzort zurückkehrt (335). Dies ermöglicht es dem System, Unregelmäßigkeiten im Betrieb zu unterstützen, wie das Ausschütten von Beton von einem LKW an zwei verschiedenen Standorten an einem Gesamteinsatzort.
Wenn Einsatzorte für den Verfolger definiert sind, können sie eingesetzt werden, um das Verhalten des Fahrzeugs oder des Fahrers zu überwachen, das den Richtlinien des Flottenbetreibers (des Teilnehmers) zuwiderläuft. Wenn zum Beispiel ein Ausschüttvorgang außerhalb des Rechtecks des definierten Einsatzortes erfasst wird, kann der Fahrzeugcomputer eine Ausnahme erzeugen und sie senden. Dies warnt den Fahrzeugabfertiger, dass der Fahrer möglicherweise Beton an einem nicht autorisierten Standort ausschüttet, verringert den Materialverlust und erhöht das Leistungspotential. Die Ankunft an der Fabrik (311) wird schließlich erfasst, wenn der LKW in ein Rechteck einfährt, das einen Fabrikstandort definiert, und die Geschwindigkeit weniger als ca. 24 km/h (15 mph) beträgt (337).
Über die normale Transportbeton-Lieferfolge hinaus möchte der Unternehmenseigner die Wassermenge feststellen, die am Einsatzort in die Mischtrommel gefüllt wird. Fahrer sind wiederum eine unzuverlässige Quelle für diese Informationen, da sie die tatsächlich hinzugefügte Menge selten aufzeichnen. Es ist entscheidend, dass die korrekte Menge hinzugefügt wird und bekannt ist, da eine fehlerhafte Mischung möglicherweise nicht richtig aushärtet.
Das Feststellen der hinzugefügten Wassermenge kann erreicht werden, indem ein Wasserdurchflussmesser an das Rohr angebracht wird, das die Trommel füllt. Ein Beispiel für eine dieser Einheiten ist EMCO/Fluidyne mit der Teilenummer 1200-1-1. Diese Art von Messgeräten stellt üblicherweise eine Impulsausgabe oder eine analoge Ausgabe bereit. Jede Art dieser Messgeräte kann leicht in die Standardeingänge des Verfolgungscomputers integriert werden. Die hinzugefügte Wassermenge wird in der Zeit von der Ankunft des LKW am Einsatzort bis zur Beendigung des Ausschüttens gemessen. Die hinzugefügte Menge wird als ein Ereignis zusammen mit dem Ereignis der Beendigung des Ausschüttens ausgesendet.
B. Transport von pulverisiertem Schüttgut
Transport-LKWs für Schüttgut transportieren pulverisiertes Material wie zum Beispiel Kalk, Zement und Flugasche. Die Sammelbunker werden von oben mit freiem Gefälle beladen. Sie werden entladen, indem Luft durch ein Netzwerk von Rohren unter den Bunkern gepresst wird, wodurch zusammen mit dem Gefälle das Material aus den Bunkern gezogen und in Lagersilos hinaufgepumpt wird. Schüttguttransportunternehmen müssen wissen, wann der LKW am Standort des Kunden eintrifft, wann er mit dem Entladen beginnt, wann das Entladen abgeschlossen ist und wann er den Einsatzort verlässt. Die Grundanforderungen sind den oben für die Transportbetonbranche beschriebenen sehr ähnlich.
Das Entladen wird durch Pumpen von Luft durch Rohre unter den Sammelbunkern ausgeführt. Luftdruck wird im Allgemeinen durch den LKW selbst erzeugt. Dies geschieht entweder durch eine PTO-angetriebene Pumpe oder durch eine abgasangetriebene Turbopumpe. Bei den meisten Unternehmen wird die abgasangetriebene Pumpe vorgezogen, da sie ein deutlich geringeres Gewicht als die PTO-Pumpe aufweist. Mit einer dieser Pumpen wird der Motor des LKW mit einer hohen Drehzahl laufen gelassen, um den erforderlichen Luftdruck zu erzeugen.
Zu bestimmen, wann die PTO-Pumpe eingeschaltet ist, ist recht unkompliziert. Einer der diskreten Eingänge wird mit dem Eingang für die Lampe an der Pumpe verbunden, die anzeigt, dass die Pumpe eingeschaltet worden ist. Die Eingangsbeschaltung ist so gestaltet, dass sichergestellt wird, dass der Eingang ausgelöst wird, selbst wenn die Lampe durchgebrannt ist. Jedes Mal, wenn die PTO-Pumpe ein- oder ausgeschaltet wird, wird eine entsprechende Statusnachricht durch den Verfolger gesendet, um das Statusänderungs-Ereignis anzuzeigen.
Bei LKWs mit abgasangetriebenen Turbopumpen ist das direkte Messen, ob die Pumpe eingeschaltet worden ist, sehr schwierig. Da die Pumpe durch die Fahrzeugabgase angetrieben wird, ist das Gehäuse sehr heiß. In dieser Umgebung kann integrierte Schaltelektronik nicht zuverlässig eingesetzt werden, so dass der Einsatz von elektronischen Durchflussschaltern und Druckschaltern schwierig wäre. Der Auslösehebel an der Pumpe ist mechanisch ungenau und schwierig zu verwenden. Darüber hinaus unterliegen Sensoren außerhalb des LKW in der Nähe der Pumpe der Manipulation.
Angesichts dieser Schwierigkeiten wird ein Tachometersensor eingesetzt, um festzustellen, ob der LKW Material pumpt. Die Sensorschaltung ist so gestaltet, dass sie ein analoges Kleinsignal erfasst, es zu einem digitalen Signalpegel umwandelt und die Frequenz in einen niedrigeren Wert teilt. Das Signal mit der niedrigeren Frequenz wird durch die TPU-Schnittstelle für einen diskreten Eingang an den Verfolger angelegt. Software in der Verfolger-CPU zählt die empfangenen Impulse und wandelt sie in eine Drehzahl um.
Die Motordrehzahl wird zusammen mit dem Umstand, dass der LKW steht, eingesetzt, um den Entladestatus festzustellen. Wenn der LKW steht und die Motordrehzahl die geeignete Drehzahlschwelle so lange überschreitet, dass der Fahrer den LKW vorbereiten und die Druckleitung anschließen kann, wird der Entladestatus gesendet. Wenn der Fahrzeugabfertiger Standortinformationen für den Verfolger bereitgestellt hat, wird diese eingesetzt, um sicherzustellen, dass der Entladevorgang an dem Einsatzort stattfindet. Wenn er außerhalb des Einsatzortes stattfindet, sendet der Verfolger eine Ausnahme, um den Fahrzeugabfertiger zu warnen.
C. Transport von Schüttgestein
Transport-LKWs für Schüttgestein sind Kipplaster, die Kies, Gestein und Sand im Allgemeinen für den Einsatz durch Transportbetonunternehmen, für den Bau oder den Landschaftsbau transportieren. Diese Branche hat ähnliche Anforderungen an die Berichterstattung von LKW-Stati wie Schlepper für pulverisiertes Schüttgutmaterial. Die Fahrzeugbesitzer müssen wissen, wann und wie oft ein Kipplaster seine Ladung entleert. Fahrzeuge in dieser Branche werden häufig von Transportbeton- oder anderen Unternehmen gemietet, die keine eigenen Gesteins-Schlepplaster besitzen. Der Fahrzeugbesitzer benötigt zur Rechnungserstellung Berichte über Laufzeitstunden, den Stand des Kilometerzählers und die Anzahl der transportierten Ladungen; und der Mieter benötigt dieselben Informationen, um sicherzustellen, dass der LKW mit der gewünschten Effizienz eingesetzt wird.
Um festzustellen, ob die Kippfläche hochgestellt ist, muss ein zuverlässiger Sensor eingesetzt werden, der unempfindlich gegenüber Erschütterung, Stößen und der extremen Ladeumgebung ist. Es wird ein Näherungssensor bevorzugt, der das Vorhandensein von Metall über eine Entfernung von mehr als ca. 1,3 cm (0,5 inch) erfassen kann, und ein solcher Sensor ist bei einer Reihe von Sensorenmodellen von dem Sensorenhersteller Turck erhältlich. Der Sensor wird an einen der diskreten Eingänge an dem Verfolger angeschlossen. Wenn der Verfolger über ein Sicherheitszeitintervall hinaus, um Geräusche zu beseitigen, feststellt, dass die Kippfläche die Nähe des Sensors verlassen hat, sendet er den Kippstatus.
Besitzer von Kipplastern möchten darüber hinaus den Verlust von Fracht verhindern. Falls anwendbar, werden wie bei dem Transportbeton Definitionen für geografische Bereiche und Grenzen durch Kartierungsdaten oder auf andere Weise für den Verfolger zur Verfügung gestellt, woraufhin er feststellen kann, ob die Kippfläche außerhalb der Bereiche angehoben wurde, in denen das Produkt angeliefert werden sollte.
D. Krankenwagen
Krankenwagenbetreiber müssen der Regierung nachweisen, dass sie den geforderten Reaktionszeiten für Notrufe und andere Rufe gerecht werden. Dies geschieht durch Bereitstellen von Berichten über jeden Einsatz mit Bezug auf Aufnahmeorte, das Krankenhaus, in das eingeliefert wurde, die Uhrzeiten der Rufe und andere Faktoren. Die Berichte werden häufig manuell auf Basis von aufgezeichneten Rufprotokollen zusammengestellt. Rettungsdienstunternehmen müssen darüber hinaus besondere örtliche Vorschriften, Richtlinien und Bestimmungen erfüllen, die für das Betreiben von Notfahrzeugen gelten, wie zum Beispiel das Unterlassen des Einsatzes der Einsatzbeleuchtung oder der Sirenen auf Autobahnen oder außerhalb von Notfallsituationen.
Diese Funktionen können durch Erfassen des Ein- und Ausschaltens der Beleuchtung und der Sirenen und unter Verwendung von Abfertigungsbereichen zu einem erheblichen Grad automatisiert werden. Wenn Ruforte und Standorte von Hospitälern und Kliniken von Bereichen umschlossen werden und dem Fahrzeugverfolger zur Verfügung gestellt werden, und wenn Sensoren an der Einsatzbeleuchtung angebracht werden, kann der Verfolger die Reaktionszeiten und die Einlieferorte automatisch feststellen.
Wenn der Verfolger erfasst, dass die Einsatzbeleuchtung eingeschaltet wird, sendet er das Ereignis und den Zeitpunkt, zu dem die Beleuchtung eingeschaltet wird. Er beginnt daraufhin außerdem, die Zeit und die Entfernung zu messen, bis das Fahrzeug am Rufort eintrifft. Die Ankunft am Rufort kann automatisch festgestellt werden, wenn für den Verfolger ein Bereich bereitgestellt wird, oder sie kann manuell festgestellt werden, indem der Fahrer eine Statustaste auf dem Anzeige-Endgerät betätigt. Sobald die Ankunft am Ort festgestellt worden ist, sendet der Verfolger die Ankunftszeit und die zurückgelegte Entfernung. Die Abfolge des Verlassens des Ortes und der Ankunft am Krankenhaus wird in ähnlicher Weise durch Bereichserfassung und Sensoren sichergestellt.
Für die Berichterstellung werden alle durch den Verfolger berichteten Daten für eine spätere Verarbeitung am Standort des Krankenwagenbesitzers gespeichert. Der Bericht enthält dann jeweils den Rufort, die zurückgelegte Entfernung und die Reaktionszeit zusammen mit dem Notfall für jede Teilstrecke der Fahrt.
XIV. Verfolger-FM-Diversity-Verarbeitung
Ein zuverlässiger Empfang von Daten in einer Mobilfunkumgebung ist schwer zu erreichen. Die Signalqualität ist schnell zeitabhängig, während das Fahrzeug sich durch das Durcheinander von Blockierungen, Reflexion und Funkstörquellen bewegt. Das durch den Fahrzeugverfolger empfangene FM-Unterträger-Datensignal kann aufgrund von Signaltrübung und Mehrwegereflexion schnell ein- oder ausgeblendet werden. Um Daten auf die zuverlässigste Weise zurückzugewinnen, die möglich ist, setzt der Netzwerktyp eine Verknüpfung aus FED-Codierung, Bitverschachtelung, CRCs an Nachrichtenpaketen und Raum-Diversity in dem Fahrzeugantennensystem ein. Obwohl die ersten drei von diesen hier zuvor erörtert worden sind, werden sie hier zum Nutzen des Lesers kurz erneut aufgegriffen.
Bei der Vorwärtsfehlerkorrektur handelt es sich um einen (23,12)-Golay-Code. Dieser Algorithmus codiert alle 12-Bit-Einheiten von Nachrichteninformationen in 23 Codebits. Nach dem Empfang ist der Decodieralgorithmus in der Lage, Fehler in bis zu 2 der 23 Codebits zu korrigieren. Der FM-Sender sendet in jeder Sekunde 300 Nachrichtenbytes (2.400 Bits) an auf diese Weise codierten Daten in 4.600 Codebits.
Um die Unanfälligkeit der Leitung gegenüber durch Mehrwege- oder Sperreffekte verursachten Fehlerbündeln zu verbessern, werden die gesendeten Bits verschachtelt. Die 200 Codewörter, die in jeder Sekunde in dem FM-Unterträger gesendet werden, werden in fünf Blöcke von 40 Wörtern geteilt. Innerhalb jedes Blocks von 40 Wörtern wird die Bitanordnung umgeordnet, so dass die 40 ersten Bits eines jeden Wortes zuerst gesendet werden, gefolgt von den 40 zweiten Bits und so weiter. Diese Verschachtelung ermöglicht es dem Golay-Algorithmus, bis zu 120 aufeinander folgende Bitfehler zu korrigieren.
Einige Fehlerbedingungen sind so schwerwiegend, dass sie nicht zuverlässig durch den FEC-Code korrigiert werden können. Zum Schutz dagegen enthält jedes Nachrichtenpaket in den FM-Daten eine Standard-CRC von 16 Bit, die zur Fehlererkennung eingesetzt wird. Wenn die CRC für ein Paket nicht korrekt ist, wird das Paket zurückgewiesen. Die CRC kann alle ungeraden Bitfehler, alle Doppelbitfehler und viele andere Kombinationen erfassen. Für die Längen kurzer Nachrichtenpakete, die üblicherweise in dem System gesendet werden, ist der 16-Bit-CRC-Algorithmus ausreichend, wenn er mit Vorwärtsfehlerkorrektur und Verschachtelung verknüpft wird.
Raum-Diversity in dem Empfangssystem des Fahrzeugs wird eingesetzt, um Fehler zu reduzieren, die durch länger andauernden Mehrwegeschwund oder länger andauernde Trübungen verursacht werden, die nicht ausschließlich durch Verschachtelung korrigiert werden können. Es werden zwei unabhängige Empfänger (207, 208, 24) und Antennen (191, 192, siehe auch 23) eingesetzt, um das FM-Unterträger-Signal für den Verfolger 135 zu empfangen. Die Empfangsantennen werden auf dem Dach des Fahrzeugs so weit voneinander getrennt, wie es praktisch möglich ist. Bei FM-Frequenzen von 100 MHz sollte die Entfernung zwischen den Antennen des Fahrzeugs für eine optimale Diversity-Verarbeitung ungefähr 1,2 m (4 ft) betragen. Diese Entfernung kann gewöhnlich bei den meisten Fahrzeugen erreicht werden. Signale von den beiden Antennen werden unter Verwendung von zwei Empfängerketten unabhängig zu Basisband-Daten demoduliert. Die Verfolger-CPU 203 setzt daraufhin einen Diversity-Verarbeitungsalgorithmus ein, um die Daten zurückzugewinnen.
Die Verfolger-CPU 203 decodiert die empfangenen Daten unter Verwendung einer Algorithmusfolge: (1) Bitentschachtelung, (2) Golay-FEC-Decodierung, (3) Nachrichtenpaket-Analyse und Diversity-Verarbeitung. Bei der Entschachtelung und der Golay-Decodierung handelt es sich um relativ unkomplizierte Algorithmen. Die Analyse- und Diversity-Algorithmen werden unten beschrieben.
In 38 wird ein Ablaufdiagramm des Diversity-Algorithmus dargestellt. In jeder Sekunde beginnt der Verfolger, über den FM-Unterträger empfangene Daten zu verarbeiten. Die beiden empfangenen Datenströme sind als Strom A und Strom B gekennzeichnet. Die Diversity-Decodierung startet am Beginn des Nachrichtenblocks entweder mit Strom A oder B. Die Nachrichtensynchronisation findet am Anfang statt, da das erste in den Daten jeder Sekunde zu verarbeitende Byte den Start eines Nachrichtenpaketes darstellt. Es wird darüber hinaus ein Flag gesetzt, um das Umschalten zu dem alternativen Strom (350) zu ermöglichen, wenn eine Nachricht nicht korrekt decodiert werden kann.
Wenn es sich bei dem nächsten zu verarbeitenden Byte um eine gültige Nachrichten-ID (351) handelt, wird der aktuelle Strom daraufhin auf das Nachrichtenpaket (352) hin analysiert. Wenn die CRC für das Paket bestanden wird (353), wird die Nachrichtensynchronisation angehalten (354) und der Zeiger wird um die Nachrichtenlänge inkrementiert (355). Daraufhin wird das nächste Byte auf eine gültige Nachrichten-ID hin überprüft (351). Dies ist der normale Ablauf der Verarbeitung, bis das Ende der Pufferkennzeichnung erfasst wird (358) oder in dem Puffer kein Platz mehr für Nachrichten vorhanden ist (359).
Wenn keine gültige Nachrichten-ID erfasst wird und der andere Strom nicht überprüft worden ist, wird das entsprechende Byte in dem anderen Strom (360) auf eine gültige Nachrichten-ID überprüft (351). Wenn sie gültig ist, wird die Nachricht, wie oben beschrieben, analysiert. Alternativ wird in beiden oben stehenden Fällen das Nachrichtenpaket korrumpiert, wenn die CRC nicht gültig ist (362). Wenn eine Nachrichtensynchronisation stattgefunden hat (363), wird eine Fehlerzahl inkrementiert (364); anderenfalls zeigt dies an, dass die Nachrichten-ID nicht der Beginn einer tatsächlichen Nachricht war. Wenn der andere Strom nicht für die Nachricht analysiert worden ist, wird er getestet.
Wenn an einem beliebigen Punkt beide Ströme daran scheitern, eine gültige Nachrichten-ID oder ein korrekt analysiertes Nachrichtenpaket zu erzeugen, kehrt der Algorithmus zum byteweisen Überprüfen beider Ströme zurück, um das nächste gültige Nachrichtenpaket zu lokalisieren.
Aus der vorangehenden ausführlichen Beschreibung ist zu erkennen, dass bestimmte Ziele, Merkmale und Aspekte der vorliegenden Erfindung besonders beachtenswert sind. Zum einen wird ein Fahrzeugflottenverwaltungs-Informationssystem für Flottenanlagenverwaltung bereitgestellt, das die Identifizierung des Standortes und der Bewegungsrichtung jedes Fahrzeugs in der Flotte in Echtzeit und die automatische Kommunikation direkt mit den Verwaltungsbüros zum Berichten von Fahrzeugstandort und -richtung ermöglicht, und das darüber hinaus die Identifizierung des Status von vorgegebenen Ereignissen ermöglicht, an denen ein Fahrzeug möglicherweise teilnimmt, wobei eine Vorrichtung in einer Netzleitstelle oder einem Netzwerk-Verteilungszentrum jedem Fahrzeug in der Flotte einen eindeutigen Zeitschlitz zum Senden seiner Berichtsinformationen über ein Kommunikationsnetzwerk ohne wesentliches Stören von Übertragungen von anderen Fahrzeugen in ihren jeweils eigenen Zeitschlitzen zuweist. Zum anderen wird eine exakte Zeitsynchronisation für alle Elemente des Netzwerks bereitgestellt, bei dem es sich zumindest teilweise um ein drahtloses TDMA-Netzwerk handelt, mit Hilfe eines Taktphasenregelkreises für das Verteilen einer einzelnen, auf entfernten globalen Positionssatelliten-GPS basierenden Zeitreferenz überall in dem Netzwerk. Das Netzwerk umfasst eine Dualband-Vollduplex-Schnittstelle mit TDMA an der einen Hälfte der Schnittstelle und Übertragung an der anderen Hälfte. Darüber hinaus verfügen die Mikroprozessoren in Bestandteilen im gesamten Netzwerk jeweils über eine Zeitverarbeitungseinheit zum Ausführen einer exakten Taktsynchronisation innerhalb von 10 Mikrosekunden für den TDMA-Anteil des Netzwerks.
Noch ein weiterer Aspekt besteht in der Bereitstellung einer Vorrichtung zum Erstellen eine Protokolls für den Eintritt von Fahrzeugsendern in das Netzwerk in zugewiesenen Zeitschlitzen für periodische Übertragungen von Nachrichten und einer Vorrichtung zum Bereitstellen von Raum-Diversity der von den Fahrzeugsendern empfangenen Nachrichten zum Vermeiden von Datenkorruption. Darüber hinaus werden periodische Übertragungsintervalle für unterschiedliche Fahrzeuge in dem Netzwerk durch dynamisches Zuweisen der Schlitze für verschiedene Aktualisierungsraten bereitgestellt. Zusätzlich werden Hilfsberichtsschlitze bereitgestellt, um umgehendes Berichten von wichtigen Daten durch die jeweiligen Fahrzeugsender unabhängig von langsameren periodischen Übertragungsintervallen zu ermöglichen. Und die Vorrichtung in dem System unterstützt sowohl die garantierte als auch die nicht garantierte Lieferung von Nachrichtendaten. Des Weiteren sind zugewiesene Schlitze für die jeweiligen Fahrzeuge eindeutig, um den Gebrauch von Bandbreite zu minimieren, indem die Identität des sendenden Fahrzeugs aus dem Zeitschlitz, in dem die Übertragung empfangen wird, abgeleitet wird. Jeder Fahrzeugsender verfügt über einen Filter für Basisbanddaten, um die belegte Bandbreite des Kanals, in dem Daten gesendet werden, zu reduzieren, einschließlich der Entfernung von Synchronisationsdaten, um den Overhead an nicht informationstragenden Daten zu minimieren. Der Basisbandfilter wird durch einen digitalen Mikrocontroller implementiert, der einen ursprünglichen Datenstrom eines Rechtecksignals der Basisbanddaten durch deterministische Übergänge ersetzt, die unabhängig von der Dateneingabefrequenz den Oberschwingungsanteil reduzieren und die Bitbreiten beibehalten. Jeder Empfänger in dem Netzwerk verfügt über die Fähigkeit, die gesendeten Daten ohne gesendete Synchronisationsinformationen durch Lokalisieren des Beginns jeder Datennachricht innerhalb eines vorgegebenen engen Zeitfensters ohne Hilfe von Bit-Synchronisationsmustern zurückzugewinnen. Zu diesem Zweck wird eine iterative Suche ausgeführt, die die Daten nacheinander mit immer größeren Verzögerungen von der nominalen Nachrichtenstartzeit eintaktet, bis ein gültiges Datenpaket lokalisiert worden ist.
Ein noch weiterer Aspekt sieht das Ermitteln, Erfassen oder Messen bestimmter wiederholter Ereignisse, an denen das Fahrzeug entsprechend der ganz grundlegenden Art seines Einsatzes und entsprechend der Branche, in der es eingesetzt wird, beteiligt ist, und das automatische Berichten der erfassten Ereignisse an das Flottenverwaltungsbüro vor. Diese sind besonders bedeutende Aspekte für Fahrzeuge, die ein Programm verfolgen müssen, das wegen der Effizienz durch das Flottenverwaltungsbüro vorgeschrieben wird, wie zum Beispiel für Transportbetonlastwagen, Schlepper für den Transport von pulverisiertem Material und Gesteinsmaterial, Krankenwagen usw.
Anhang A: Glossar der abgekürzten Begriffe

ACCUMINT

(accumulator interrupt – Akkumulator-Interrupt)

BFSK

(binary frequency shift keying – Binäre Frequenzumtastung)

CCS

(Customer Command Station – Kundenbedienstation)

CDU

(control and display Unit – Steuer- und Anzeigeeinheit)

CPU

(central processing unit – Hauptprozessor)

CRC

(cyclic redundancy check – Zyklische Redundanzprüfung)

DGPS

(differential global positioning system – Globales Positionsbestimmungssystem mit Differentialsignal)

DMCS

(Database Management and CCS Server – Datenbankverwaltungs- und CCS-Server)

DR

(dead reckoning navigation – Koppelnavigation)

DSP

(digital signal processor – Digitale Signalverarbeitung)

FEC

(forward error correction – Vorwärtsfehlerkorrektur)

FM

(frequency modulation – Frequenzmodulation)

FSK

(frequency shift keying – Frequenzumtastung)

GP2010

(HF-Front-End-Komponente eines GPS-Chipsatzes von Plessey)

GP2021

(Korrelationskomponente eines GPS-Chipsatzes von Plessey)

GPS

(global positioning system – Globales Positionsbestimmungssystem)

IF

(intermediate frequency – Zwischenfrequenz)

IOD

(issue of data – Ausgabe der Daten)

ISP

(Internet service provider – Internetdienstanbieter)

ISR

(interrupt service routine – Interrupthandler)

ITC

(input transition capture/count – Eingangsänderungs-Aufzeichnung/-Zählung)

LFS

(linear file store – Linearer Dateispeicher)

LNA

(low noise amplifier – Rauscharmer Verstärker)

LOT

(login only tracking – Reine Anmeldungsverfolgung)

MDE

(Mobiles Daten-/Anzeige-Endgerät)

NDC

(Network Distribution Center – Netzwerk-Verteilungszentrum)

NTCC

(Network Timing Control Computer – Netzwerktakt-Steuerungsrechner)

OC

(output compare – Ausgabevergleich)

PCS

(personal communications services – Persönliche Kommunikationsdienste)

PDC

(PROTRAK^TM Data Center – PROTRAK^TM-Rechenzentrum)

PIT

(periodic interrupt timer – Periodischer Interrupttimer, Zeitgeberbaustein)

PPM

(parts per million – Teile pro Million)

PPP

(point-to-point protocol – Punkt-zu-Punkt-Protokoll)

PPWA

(periodic pulse width accumulation – Perioden-/Impulsbreitenakkumulation)

PSTN

(public switched telephone network – Öffentliches Fernsprechnetz)

PWM

(pulse-width modulation – Im pulsbreitenmodulation)

QSPI

(queued serial peripheral interface, a Motorola 68332 processor peripheral – Serielle Peripherieschnittstelle mit Warteschlange, ein Peripheriegerät mit 68332-Prozessor von Motorola)

RF

(radio frequency – Hochfrequenz)

RI

(repeating interval – Wiederholungsintervall)

RSS

(root sum square – Summenquadratwurzel)

RXD

(receive data – Empfangsdaten)

SCA

(subsidiary communications authorization – ein Unterträgersystem)

SCC

(Subcarrier Control Computer – Unterträger-Steuerungsrechner)

SCI

(serial communications interface – serielle Kommunikationsschnittstelle)

SMR

(specialized mobile radio – spezialisierter Mobilfunk)

SQL

(structured query language – strukturierte Abfragesprache)

SRAM

(static random access memory – statischer Speicher mit wahlfreiem Zugriff)

TCR

(timing control register – Taktsteuerregister)

TCXO

(temperature compensated crystal oscillator – Temperaturkompensierter Quarzoszillator)

TIC

(Zeitmarkierung (Zeitgeber-Ticks) von dem GPS-Chipsatz)

TDMA

(time division multiple access – Zeitmultiplexverfahren)

TPU

(time processing unit – Zeitverarbeitungseinheit)

TXD

(transmit data – Sendedaten)

UART

(universal asynchronous receiver/transmitter – Universeller asynchroner Empfänger/Sender)

UHF

(ultra high frequency – Ultrahochfrequenz)

Anhang B: Tabellen Tabelle 2: Basispaket-Zusammenfassung

Beschreibung	ID-Nummer	Länge (Bytes)	Bemerkungen
Textnachrichtenpaket – Einzelner Verfolger oder gesamte Flotte	0x01	Variabel	Zeigt Nachrichten- und Antwortsatz für eine Verfolger-/Flottennachricht an.
Textnachrichtenpaket – Verfolgergruppe	0x02	Variabel	Zeigt Nachrichten- und Antwortsatz für eine Gruppennachricht an.
Verfolgergruppen-Nachrichtenschnittstelle n-ID-Listenpaket	0x03	Variabel	Zeigt eine Gruppe von Empfänger-IDs für Text- und Benutzerdaten-Nachrichten an.
Definition von vordefinierten Nachrichten	0x1D	Variabel	Stellt von Kunde zu Kunde eine Definition von vordefinierten Nachrichten an Verfolgermodule bereit.
Paket für die ID einer vordefinierten Nachricht – Einzelner Verfolger oder gesamte Flotte	0x04	Variabel	Benutzerspezifisch
Paket für die ID einer vordefinierten Nachricht – Verfolgergruppe	0x05		Zeigt Benutzerdaten für eine Gruppennachricht an.
DGPS-Paket	0x06	Variabel	Durch NTCC berechnet
Benutzerdaten-Nachrichtenpaket – Einzelner Verfolger	0x07	Variabel	Benutzerspezifisch
Benutzerdaten-Nachrichtenpaket – Verfolgergruppe	0x08	Variabel	Benutzerspezifisch
Gitter-ID-Paket	0x09	11
FM-Identifikationspaket	0x0a	13
UHF-Identifizierungspaket	0x0b	5

GPS-Zeitpaket	0x0c	7	Durch NTCC berechnet
Paket zum Festlegen einer Definition für einen Wiederholungsintervall-Schlitz	0x0d	12	Weist Hauptwiederholungsinterall und Netzwerk-/Schnittstellen-ID zu.
Hinzufügen eines Hilfswiederholungsintervall-Schlitzes – Einzelnes Intervall durch Verfolger-ID-Paket	0x0e	10	Weist Hilfswiederholungsintervalle zu.
Hinzufügen eines Hilfswiederholungsintervall-Schlitzes – Einzelnes Intervall durch Netzwerk-/Schnittstellen-ID-Paket	0x0f	8
Hinzufügen eines Hilfswiederholungsintervall-Schlitzes – Begrenzte Anzahl von Intervallen durch Verfolger-ID-Paket	0x10	11	Weist Hilfswiederholungsintervalle zu.
Hinzufügen eines Hilfswiederholungsintervall-Schlitzes – Begrenzte Anzahl von Intervallen durch Netzwerk-/Schnittstellen-ID-Paket	0x11	9
Paket der verfügbaren Netzwerkeintrittsschlitze	0x12	8	Wird einmal pro Minute gesendet.

Wiederholungsintervallschlitz-Konfigurationsinfopaket	0x13	3	Wird einmal pro Minute gesendet. Wird zum Festlegen von Sendetakt/-formst von Paketen für Verfolger mit periodischer Aktualisierung verwendet.
	0x14
Netzwerkeintrittsantwort -Paket	0x15	6
Netzwerkeintritts-Anforderungsgenehmigungs-Paket	0x16	5
Löschen zugewiesener Wiederholungsintervalle – Durch Verfolger-ID-, Kunden-ID, oder Verfolger-ID-Listenpaket	0x17	6
Nachrichtenantwortquittung	0x18	Variabel	Quittiert Text- und vordefinierte Nachrichtenantworten
Einsatzortsabfertigungs-Nachricht	0x19	Variabel	Stellt dem Verfolger Einsatzort und Nachricht für den Benutzer zur Verfügung.
Benutzerdatenquittung	0x1a	Variabel	Quittiert zuverlässige Benutzerdatenpakete.
Gitter-Identifizierung 2	0x1b	13	Definiert HF-Navigationsgitter und zeigt NDC-Server-Bootsequenz-ID an.
Einsatzorts-Löschnachricht	0x1c	Variabel	Löscht einen bekannten Einsatzort aus dem Verfolger.
Einsatzorts-Statusquittung	0x1e

Tabelle 3: Textnachrichtenpaket – Einzelner Verfolger oder gesamte Flotte

# der Bytes	Beschreibung
1	Paket-ID: 0x01
1	Bits 0-2: Antwortsatz¹ (vordefinierter Satz von Antwortmöglichkeiten) Bits 3-4: Adressiermodus 0 = Verfolger-ID, 1 = Netzwerk-/Schnittstellen-ID, 2 = Kunden-ID Bits 5-7: Frei
3	Nachrichtenfolgen-ID (eindeutig für jeden Kunden)
Variabel	Verfolger-ID (4 Bytes), Netzwerk-/Schnittstellen-ID (2 Bytes), Kunden-ID (3 Bytes)
3	Sendezeit² (GPS-Sekunde)²
1	Nachrichtenlänge (L₁)
L₁	Nachricht

¹Die unten stehende Tabelle zeigt die vordefinierten Antwortsätze an.
²Zeigt die Zeit an, zu der die Nachricht ursprünglich gesendet wurde. Bemerkung: Da nur die GPS-Sekunde bereitgestellt wird, nehmen Verfolgermodule möglicherweise an, dass die Nachricht weniger als eine GPS-Woche alt ist.

Antwortsatz-ID	MDE-Softkey 1	MDE-Softkey 2	MDE-Softkey 3	MDE-Softkey 4
0¹	{LEER}	{LEER}	{LEER}	{LEER}
1	Ja	Nein	Rufen	{LEER}
2	OK	{LEER}	{LEER}	{LEER}
3	OK	Abbrechen	Rufen	{LEER}
4	Annehmen	Ablehnen	Rufen	{LEER}
5	{LEER}	{LEER}	{LEER}	{LEER}
6	{LEER}	{LEER}	{LEER}	{LEER}
7	{LEER}	{LEER}	{LEER}	{LEER}

¹Die Antwortsatz-ID zeigt an, dass keine vordefinierte Antwort erforderlich ist. Es kann jedoch trotzdem ein benutzerdefinierter Antwortsatz innerhalb der Nachricht definiert werden. Benutzerdefinierte Antwortsätze können durch Anhängen von Antwortsatzwerten an die Nachricht definiert werden. Antwortsatzwerte werden durch das Zeichen "|" (einen senkrechten Balken) abgegrenzt.

# der Bytes	Beschreibung
1	Paket-ID: 0x02
1	Bits 0-2: Antwortsatz (vordefinierter Satz von Antwortmöglichkeiten) Bits 3-7: frei
3	Kunden-ID
3	Nachrichtenfolgen-ID (eindeutig für jeden Kunden)
3	Sendezeit (GPS-Sekunde)²
1	Nachrichtenlänge (L₁)
L₁	Nachricht

¹Siehe vordefinierte Nachrichtenantwortsätze zu weiteren Informationen über Antwortsätze. Bemerkung: Textnachrichten, die an eine Gruppe von Verfolgern gesendet werden, werden in zwei Paketen gesendet. Ein Paket enthält die Textnachricht, die Kunden-ID und die Nachrichtenfolgen-ID, während das andere Paket die Verfolger-IDs, die Kunden-ID und die Nachrichtenfolgen-ID enthält.
²Zeigt die Zeit an, zu der die Nachricht ursprünglich gesendet wurde. Bemerkung: Da nur die GPS-Sekunde bereitgestellt wird, nehmen Verfolgermodule möglicherweise an, dass die Nachricht weniger als eine GPS-Woche alt ist.

# der Bytes	Beschreibung
1	Paket-ID: 0x03
2	Nachrichtenlänge¹
1	Verfolger-ID-Listenblock-Anzahl (TILBC₁)
Variabel	Verfolger-ID-Listenblock #1
...
Variabel	Verfolger-ID-Listenblock #TILBC₁
3	Nachrichtenfolgen-ID (eindeutig für jeden Kunden)
3	Kunden-ID

¹Zeigt die Gesamtlänge dieser Nachricht ausschließlich der Paket-ID und des Nachrichtenlängenwertes an.

# der Bytes	Beschreibung
1	Verfolger-ID-Blocktyp/-Größe Bits 0-3: ID-Typ ( 0 – Netzwerk-ID-Liste¹, 1 – Schnittstellen-ID-Liste innerhalb einesNetzwerks¹, 2 – Schnittstellen-ID-Bereichspaare innerhalb eines Netzwerks¹. 3 – Netzwerk-/Schnittstellen-ID, 4 – Verfolger-ID) Bit 4: ID der Netzwerkgröße¹ (0 = 256 Verfolger, 1 = 16 Verfolger) 5-7: Frei
1	Netzwerk-ID-Anzahl (NC)/ID-Anzahl (IC)
Variabel	ID-Typ	Netzwerkgröße	# der Bytes	Beschreibung
	0	0	1	Netzwerk-ID #1
			...
			1	Netzwerk-ID #NC
		1	3	Bits 0-11: Netzwerk-ID #1 Bits 12-23: Netzwerk-ID #2
			...
			3	Bits 0-11: Netzwerk-ID # NC-1 Bits 12-23: Netzwerk-ID # NC
	1	0	1	Netzwerk-ID #1
			1	Schnittstellen-ID-Anzahl (IIC₁)
			1	Schnittstellen-ID #1

		...
		1	Schnittstellers-ID #IIC₁
		...
		1	Netzwerk-ID #NC
		1	Schnittstellen-ID-Anzahl (IIC_NC)
		1	Schnittstellen-ID #1
		...
		1	Schnittstellen-ID #IIC_NC
	1	2	Netzwerk-ID #1
		1	Schnittstellen-ID-Anzahl (IIC₁)
		1	Bits 0-3: Schnittstellen-ID #1 Bits 4-7: Schnittstellen-ID #2
		...
		1	Bits 0-3: Schnittstellen-ID # IIC-1 Bits 4-7: Schnittstellen-ID # IIC
		...
		2	Netzwerk-ID #NC
		1	Schnittstellen-ID-Anzahl (IIC_NC)
		1	Bits 0-3: Schnittstellen-ID #1 Bits 4-7: Schnittstellen-ID #2
		...
		1	Bits 0-3: Schnittstellen-ID #IIC_NC-1 Bits 4-7: Schnittstellen-ID # IIC_NC
2	0	1	Netzwerk-ID #1
		1	Schnittstellen-ID-Paaranzahl (IIPC₁)
		1	Schnittstellen-ID-Paar #1 Start
		1	Schnittstellen-ID-Paar #1 Ende
		...
		1	Schnittstellen-ID-Paar #IIPC₁ Start

	1	Schnittstellen-ID-Paar #IIPC₁ Ende
	...
	1	Netzwerk-ID #NC
	1	Schnittstellen-ID-Paaranzahl (IIPC_NC)
	1	Schnittstellen-ID-Paar #1 Start
	1	Schnittstellen-ID-Paar #1 Ende
	...
	1	Schnittstellen-ID-Paar # IIPC_NC Start
	1	Schnittstellen-ID-Paar # IIPC_NC Ende
1	2	Netzwerk-ID #1
	1	Schnittstellen-ID-Paaranzahl (IIPC₁)
	1	Bits 0-3: Schnittstellen-ID-Paar #1 Start Bits 4-7: Schnittstellen-ID-Paar #1 Ende
	...
	1	Bits 0-3: Schnittstellen-ID # IIPC₁ Start Bits 4-7: Schnittstellen-ID # IIPC₁ Ende
	...
	2	Netzwerk-ID #NC
	1	Schnittstellen-ID-Paaranzahl (IIPC_NC)
	1	Bits 0-3: Schnittstellen-ID #1 Start
	1	Bits 4-7: Schnittstellen-ID #1 Ende
	...

		1	Bits 0-3: Schnittstellen-ID # IIPC_NCStart
		1	Bits 4-7: Schnittstellen-ID # IIPC_NCEnde
3	N/A	2	Bits 0-15: Netzwerk-Schnittstellen-ID #1
		...
		2	Bits 0-15: Netzwerk-Schnittstellen-ID #IC₁
4	N/A	4	Verfolger-ID #1
		...
		4	Verfolger-ID #IC₁

# der Bytes	Beschreibung
1	Paket-ID: 0xID
3	Kunden-ID
1	Vordefinierte Nachrichten-ID
1	Nachrichtenlänge (L₁)
L₁	Nachricht

# der Bytes	Beschreibung
1	Paket-ID: 0x04
1	Bits 0-2: Antwortsatz¹ (vordefinierter Satz von Antwortmöglichkeiten) Bits 3-4: Adressiermodus 0 = Verfolger-ID, 1 = Netzwerk-/Schnittstellen-ID, 2 = Kunden-ID Bits 5-7: Frei
3	Nachrichtenfolgen-ID (eindeutig für jeden Kunden)
Variabel²	Verfolger-ID (4 Bytes), Netzwerk-/Schnittstellen-ID (2 Bytes), Kunden-ID (3 Bytes)
3	Sendezeit (GPS-Sekunde)³
1	Vordefinierte Nachrichten-ID
2	Vordefinierte Nachricht 16-Bit-CRC
1	Länge des benutzerdefinierten Antwortsatzes (L₁)
L₁	Benutzerdefinierter Antwortsatz³

¹Siehe vordefinierte Nachrichtenantwortsätze zu weiteren Informationen über Antwortsätze.
²Zeigt die Zeit an, zu der die Nachricht ursprünglich gesendet wurde. Bemerkung: Da nur die GPS-Sekunde bereitgestellt wird, nehmen Verfolgermodule möglicherweise an, dass die Nachricht weniger als eine GPS-Woche alt ist.
³Wenn der vordefinierte Antwortsatz 0 ist, kann dieses vordefinierte Nachrichtenpaket einen benutzerdefinierten Satz an vordefinierten Antwortsätzen enthalten. Benutzerdefinierte Antwortsatzwerte werden durch das Zeichen "|" (einen senkrechten Balken) abgegrenzt.

# der Bytes	Beschreibung
1	Paket-ID: 0x05
2	Nachrichtenlänge¹
1	Bits 0-2: Antwortsatz² (vordefinierter Satz von Antwortmöglichkeiten) Bits 3-7: Frei
1	Verfolger-ID-Listenblock-Anzahl (TILBC₁)
Variabel	Verfolger-ID-Listenblock #1
...
Variabel	Verfolger-ID-Listenblock #TILBC₁
3	Sendezeit (GPS-Sekunde)³
1	Vordefinierte Nachrichten-ID
2	Vordefinierte Nachricht 16-Bit-CRC
1	Länge des benutzerdefinierten Antwortsatzes (L₁)
L₁	Benutzerdefinierter Antwortsatz⁴

¹Zeigt die Gesamtlänge dieser Nachricht ausschließlich der Paket-ID und des Nachrichtenlängenwertes an.
²Siehe vordefinierte Nachrichtenantwortsätze zu weiteren Informationen über Antwortsätze.
³Zeigt die Zeit an, zu der die Nachricht ursprünglich gesendet wurde. Bemerkung: Da nur die GPS-Sekunde bereitgestellt wird, nehmen Verfolgermodule möglicherweise an, dass die Nachricht weniger als eine GPS-Woche alt ist.
⁴Wenn der vordefinierte Antwortsatz 0 ist, kann dieses vordefinierte Nachrichtenpaket einen benutzerdefinierten Satz an vordefinierten Antwortsätzen enthalten. Benutzerdefinierte Antwortsatzwerte werden durch "|" (einen senkrechten Balken) abgegrenzt.

Bytenummer	Beschreibung
0	Paket-ID: 0x06
1	Bits 0-5: RTCM-Rahmen-ID (0-63) Bits 6-7: Frei
2	Bits 0-4: Anzahl an SVs in der Nachricht (0 ⇒ 32 SVs = N_SV) Bits 5-7: Frei
3-4	Bits 0-12: RTCM-104 Geänderter Z-Zähler Bits 13-15: Stationszustand
(i = 0 – N_SV – 1)	Korrekturdaten für jeden SV folgen (jeweils 5 Bytes)
5 + 5i	Bits 0-4: SV-PRN-ID dieser Korrektur (0 ⇒ PRN 32) Bits 5-6: Benutzer-Differentialentfernungsfehler Bit 7: Skalenfaktor
6 + 5i	IODE
7 + 5i – 8 + 5i	Pseudoentfernungskorrektur
9 + 5i	Pseudoentfernungs-Änderungskorrektur

# der Bytes	Beschreibung
1	Paket-ID: 0x07
1	Bits 0-2: Frei² Bits 3-4: Adressiermodus 0 = Verfolger-ID, 1 = Netzwerk-/Schnittstellen-ID, 2 = Kunden-ID Bits 5-7: Frei²
3	Nachrichtenfolgen-ID
Variabel	Verfolger-ID (4 Bytes), Netzwerk-/Schnittstellen-ID (2 Bytes), Kunden-ID (3 Bytes)
3	Sendezeit (GPS-Sekunde)¹
1	Nachrichtenlänge (L₁)
L₁	Nachricht

¹Zeigt die Zeit an, zu der die Nachricht ursprünglich gesendet wurde. Bemerkung: Da nur die GPS-Sekunde bereitgestellt wird, nehmen Verfolgermodule möglicherweise an, dass die Nachricht weniger als eine GPS-Woche alt ist.
²Freie Werte sind geteilt worden, damit der Adressiermodus sich bei allen Nachrichten an derselben Position befinden kann.

# der Bytes	Beschreibung
1	Paket-ID: 0x08
3	Kunden-ID
3	Nachrichtenfolgen-ID
3	Sendezeit (GPS-Sekunde)¹
1	Benutzerdatenlänge (L₁)
L₁	Benutzerdaten

Bemerkung: Benutzerdaten, die an eine Gruppe von Verfolgern gesendet werden, werden in zwei Paketen gesendet. Ein Paket enthält die Benutzerdaten, die Kunden-ID und die Nachrichtenfolgen-ID, während das andere Paket die Verfolger-IDs, die Kunden-ID und die Nachrichtenfolgen-ID enthält. Siehe das Verfolgergruppen-Nachrichtenschnittstellen-ID-Listenpaket zum Identifizieren der Verfolger, die dieses Benutzerdatenpaket empfangen.

¹Zeigt die Zeit an, zu der die Nachricht ursprünglich gesendet wurde. Bemerkung: Da nur die GPS-Sekunde bereitgestellt wird, nehmen Verfolgermodule möglicherweise an, dass die Nachricht weniger als eine GPS-Woche alt ist.

Bytenummer	Beschreibung
0	Paket-ID: 0x09
1-2	Bits 0-14: Gitter-ID-Nummer Bit 15: lokales Gitter = 1; angrenzendes Gitter = 0
3-5	Gitternull-Breite: LSB = 2^-23 Halbkreise
6-8	Gitternull-Länge: LSB = 2^-23 Halbkreise
9-10	Gitternull-Höhe (HAE): LSB = 1 m

Bytenummer	Beschreibung
0	Paket-ID: 0x0a
1-2	Bits 0-14: Gitter-ID-Nummer Bit 15: lokales Gitter = 1; angrenzendes Gitter = 0
3	Bits 0-1: Sender-ID Bits 2-3: Anzahl der Sender (0 ⇒ 4 Sender) Bits 4-7: Frei
4-6	FM-Senderbreite: LSB = 2^-23 Halbkreise
7-9	FM-Senderlänge: LSB = 2^-23 Halbkreise
10-11	FM-Senderhöhe (HAE): LSB = 1 m
12	Bits 0-6: Frequenz 0 ⇒ 87,5 MHz, 1 ⇒ 87,7 MHz, 102 ⇒ 107,9 MHz Bit 7: Unterträger: 0 ⇒ 67 kHz, 1 ⇒ 92 kHz

Bytenummer	Beschreibung
0	Paket-ID: 0x0b
1-2	Bits 0-14: Gitter-ID-Nummer Bit 15: lokales Gitter = 1; angrenzendes Gitter = 0
3	Bits 0-1: UHF-Frequenz-ID Bits 2-3: Anzahl der Frequenzen (0 ⇒ 4 Frequenzen) Bits 4-7: Frei
4-5	Bits 0-11: Frequenz ⇒ 450 MHz, 1 ⇒ 450,0125 MHz, 1600 ⇒ 470 MHz Bits 12-15: Frei

Bytenummer	Beschreibung
0	Paket-ID: 0x0c
1-2	Bits 10-15: Schaltsekunden Bits 0-9: GPS-Woche 0-1023
3-5	Bits 0-19: GPS-Sekunde 0-604799 Bits 20-23: Durchgangszähler
6	Bits 0-6: Zeitzonen-Offset von GPS/UTC, LSB = 15 min Bit 7: Frei

Bytenummer	Beschreibung
0	Paket-ID: 0x0d
1-4	Bits 0-29: Verfolger-ID Bit 30: Eingabeart-Flag (0 = normal, 1 = Niedrigenergie)¹ Bit 31: frei
5-6	Netzwerk-/Schnittstellen-ID
7	Schlitz
8-9	Wiederholungsintervall-Index
10-11	Intervalllänge

¹Verfolgermodule können durch Anfordern des Netzwerkeintritts oder durch Anfordern eines Niedrigenergie-Schlitzes mit ihrer Zustands- und Status-Verfolgungsaktualisierung in das Netzwerk eintreten. Wenn ein Verfolger den Netzeintritt unter Verwendung eines Netzeintrittsanforderungs-Paketes angefordert hat, ist dieses Flag auf 0 gesetzt. Wenn ein Verfolger einen Niedrigenergie-RI-Schlitz angefordert hat, ist dieses Flag auf 1 gesetzt.

Bytenummer	Beschreibung
0	Paket-ID: 0x0e
1-4	Verfolger-ID
5	Schlitz
6-7	Wiederholungsintervall-Index
8-9	Intervalllänge

Bytenummer	Beschreibung
0	Paket-ID: 0x0f
1-2	Netzwerk-/Schnittstellen-ID
3	Schlitz
4-5	Wiederholungsintervall-Index
6-7	Intervalllänge

Bytenummer	Beschreibung
0	Paket-ID: 0x10
1-4	Verfolger-ID
5	Schlitz
6-7	Wiederholungsintervall-Index
8-9	Intervalllänge
10	Intervallanzahl

Bytenummer	Beschreibung
0	Paket-ID: x011
1-2	Netzwerk-/Schnittstellen-ID
3	Schlitz
4-5	Wiederholungsintervall-Index
6-7	Intervalllänge
8	Intervallanzahl

# der Bytes	Beschreibung
1	Paket-ID: 0x12
1	Schlitzanzahl
(Schlitzanzahl + 7)/8	Bitmap der verfügbaren Schlitze Flag (0 = nicht verfügbar, 1 = verfügbar) Schlitz-0-Flag = Bit 0, Byte 2, Schlitz1-Flag = Bit 1, Byte 2, ... Schlitz8-Flag = Bit 0, Byte 3, Schlitz9-Flag = Bit 0, Byte 2, ...

Bytenummer	Beschreibung
0	Paket-ID: 0x13
1-2	Rahmenzykluslänge
3	Selbstlöschungs-Aktualisierungsanzahl
4	Verfolger-ID-Anforderungsmodus 0 = Verfolger-ID nicht erforderlich, 1 = Verfolger-ID nur für nächste Aktualisierung erforderlich, 2 = Verfolger-ID für alle Aktualisierungen erforderlich,
5-6	BIT-Paketrate (in Sekunden)

Bytenummer	Beschreibung
0	Paket-ID: 0x15
1-4	Verfolger-ID1
5	Bits 0-1: Statuscode des zugewiesenen Verfolgers 0 = auf Hilfswiederholungsintervall-Schlitz warten, 1 = auf Netzeintrittserlaubnis warten 2 = auf Registrierung warten¹

¹Zeigt an, dass der Verfolger nicht bei dem NDC-Server registriert worden ist. Unregistrierte Verfolger können weiterhin jede Stunde den Netzwerkeintritt anfordern.

# der Bytes	Beschreibung
1	Paket-ID: 0x16
4 oder 1¹	Bits 0-1: Adressiermodus 0 = durch Verfolger-ID, 1 = durch Kunden-ID, 3 = durch Verfolger-ID-Liste Bits 2-31: Adresse (durch Verfolger-ID) Bits 2-25: Kunden-ID (durch Kunden-ID)
2 oder Variabel¹	2 Bytes: Netzwerk-/Schnittstellen-ID (durch Netzwerk-/Schnittstellen-ID)
2 oder Variabel¹	Variabel: Verfolger-ID-Listenblock (durch Verfolger-ID-Liste)

¹Wenn der Adresstyp "durch Verfolger-ID" oder "durch Kunden-ID" anzeigt, folgt die ID unmittelbar im Anschluss. Wenn „durch Netzwerk-/Schnittstellen-ID" oder „durch Verfolger-ID-Liste" angezeigt wird, beginnt die ID im nächsten Byte.

# der Bytes	Beschreibung
1	Paket-ID: 0x17
4 oder 1¹	Bits 0-1: Adressiermodus 0 = durch Verfolger-ID, 1 = durch Kunden-ID, 2 = durch Netzwerk-/Schnittstellen-ID, 3 = durch Verfolger-ID-Liste Bits 2-31: Adresse (durch Verfolger-ID)³ Bits 2-25: Kunden-ID (durch Kunden-ID)
2 oder Variabel¹	2 Bytes: Netzwerk-/Schnittstellen-ID (durch Netzwerk-/Schnittstellen-ID) oder
2 oder Variabel¹	Variabel: Verfolger-ID-Listenblock (durch Verfolger-ID-Liste) oder
1	Bits 0-3: 0 = Alle Wiederholungsintervalle löschen, 1 = Alle Hilfswiederholungsintervalle löschen, 2 = Hauptwiederholungsintervall löschen² 3 = Angegebenes Wiederholungsintervall löschen⁴ Bit 4: 0 = auf Netzeintritts-Anforderungserlaubnis warten 1 = Netzwerkeintritt anfordern
1 (optional)⁴	Angegebenes Wiederholungsintervall: Schlitz⁴
2 (optional)⁴	Angegebenes Wiederholungsintervall: Index⁴
2 (optional)⁴	Angegebenes Wiederholungsintervall: Länge⁴

¹Wenn der Adresstyp "durch Verfolger-ID" oder "durch Kunden-ID" anzeigt, folgt die ID unmittelbar im Anschluss. Wenn „durch Netzwerk-/Schnittstellen-ID" oder „durch Verfolger-ID-Liste" angezeigt wird, beginnt die ID im nächsten Byte.
²Die Verfolger sollten ihre Netzwerk-/Schnittstellen-ID löschen, wenn ihr Hauptwiederholungsintervall gelöscht wird.
³0x0000 = Broadcast-Verfolger-ID. Wenn ein zum Löschen bestimmtes Wiederholungsintervall an 0x0000 gesendet wird, sollten alle Verfolgermodule die/das angezeigte(n) Wiederholungsintervall(e) löschen.
⁴Optionaler Abschnitt der Nachricht, der nur vorhanden ist, wenn "Angegebenes Wiederholungsintervall löschen" angezeigt wird.

# der Bytes	Beschreibung
1	Paket-ID: 0x18
1	Bits 0-2: Antwortschlüssel-ID 1 = Softkey #1, 2 = Softkey #2, 3 = Softkey #3, 4 = Softkey #4 Bits 3-4: Adressiermodus 0 = Verfolger-ID, 1 = Netzwerk-/Schnittstellen-ID Bits 5-7: Frei
3	Nachrichtenfolgen-ID¹ (eindeutig für jeden Kunden)
Variabel	Verfolger-ID (4 Bytes), Netzwerk-/Schnittstellen-ID (2 Bytes)

¹Die Nachrichtenfolgen-ID ist dieselbe ID, die mit der ursprünglichen Text-/Einsatzortsabfertigungs-Nachricht verknüpft, die die Antwort erforderte.

# der Bytes	Beschreibung
1	Paket-ID: 0x19
1	Bits 0-2: Antwortsatz¹ (vordefinierter Satz von Antwortmöglichkeiten) Bits 3-4: Adressiermodus 0 = Verfolger-ID, 1 = Netzwerk-/Schnittstellen-ID, 2 = Kunden-ID Bits 5-6: Typ des Ortes³ (0 = Einsatzort, 1 = Heimatstandort, 2 = kundendefiniert, 3 = kundendefiniert) Bit 7: Frei
3	Nachrichtenfolgen-ID (eindeutig für jeden Kunden)
Variabel	Verfolger-ID (4 Bytes), Netzwerk-/Schnittstellen-ID (2 Bytes), Kunden-ID (3 Bytes)
3	Sendezeit (GPS-Sekunde)
3	Orts-ID (eindeutig je Typ je Kunde)⁴
3	Nordöstliche Breite –90° to +90° (LSB = 180°·2^–23)
3	Nordöstliche Länge –180° to +180° (LSB = 180°·2^–23)
3	Südwestliche Breite –90° to +90° (LSB = 180°·2^–23)
3	Südwestliche Länge –180° to +180° (LSB = 180°·2^–23)
1	Nachrichtenlänge (L₁) (Max = 128 Bytes einschließlich Antwort)
L₁	Nachrichte

¹Siehe die Tabelle für vordefinierte Nachrichten-Antwortsätze zu weiteren Informationen.

# der Bytes	Beschreibung
1	Paket-ID: 0x1c
1	Bits 0-2: Antwortsatz¹ (vordefinierter Satz von Antwortmöglichkeiten) Bits 3-4: Adressiermodus 0 = Verfolger-ID, 1 = Netzwerk-/Schnittstellen-ID, 2 = Kunden-ID Bits 5-6: Typ des Ortes³ (0 = Einsatzort, 1 = Heimatstandort, 2 = kundendefiniert, 3 = kundendefiniert) Bit 7: frei
3	Nachrichtenfolgen-ID (eindeutig für jeden Kunden)
Variabel	Verfolger-ID (4 Bytes), Netzwerk-/Schnittstellen-ID (2 Bytes), Kunden-ID (3 Bytes)
3	Sendezeit (GPS-Sekunde)
3	Orts-ID (eindeutig je Typ je Kunde)²

¹Siehe die Tabelle für Vordefinierte Nachrichten-Antwortsätze zu weiteren Informationen.
²Die Werte der Orts-IDs sind pro Kunde pro Ortstyp eindeutig, außer für die Massenlöschungs-Orts-ID 0x1FFFFF. Die Orts-ID 0x1FFFFF weist den Verfolger an, alle Nachrichten des in dem Ortstyp-Feld angezeigten Typs zu löschen.
³Das Verfolgermodul kann den Ortstyp einsetzen, um die Zeitdauer festzustellen, über die ein Ort erhalten bleiben soll, und um den Algorithmus festzustellen, der zum Feststellen des Ankunfts-/Abfahrts-Status eingesetzt werden soll. Einsatzorte sollte durch den Verfolger erhalten bleiben, bis der Verfolger in den Ort eintritt oder ihn verlässt. Heimatstandorte sollten erhalten bleiben, bis sie gelöscht werden. Und die Typen 2 & 3 sollten auf Basis von kundendefinierten Regeln erhalten bleiben.

# der Bytes	Beschreibung
1	Paket-ID: 0x1a
1	Bit 0: Adressiermodus 0 = Verfolger-ID, 1 = Netzwerk-/Schnittstellen-ID Bits 1-7: frei
1	ID der Benutzerdatenfolge¹
Variabel	Verfolger-ID (4 Bytes), Netzwerk-/Schnittstellen-ID (2 Bytes)

¹Folgen-ID, die durch den Verfolger zugewiesen wurde, wenn ein zuverlässiges Benutzerdatenpaket gesendet wurde. Siehe Zuverlässige Benutzerdaten und Zuverlässige kurze Benutzerdaten zu weiteren Informationen.

# der Bytes	Beschreibung
1	Paket-ID: 0x1b
2	Bits 0-14: Gitter-ID-Nummer Bit 15: lokales Gitter = 1; angrenzendes Gitter = 0
3	Gitternull-Breite: LSB = 2^-23 Halbkreise
3	Gitternull-Länge: LSB = 2^-23 Halbkreise
2	Gitternull-Höhe (HAE): LSB = 1 m
2	NDC-Server-Bootsequenz-ID

# der Bytes	Beschreibung
1	Paket-ID: 0x1d
1	Bit 0: Adressiermodus 0 = Verfolger-ID, 1 = Netzwerk-/Schnittstellen-ID Bits 1-2: Typ des Ortes³ (0 = Einsatzort, 1 = Heimatstandort, 2 = kundendefiniert, 3 = kundendefiniert) Bit 3-7: frei
Variabel	Verfolger-ID (4 Bytes), Netzwerk-/Schnittstellen-ID (2 Bytes)
3	Orts-ID
1	Einsatzorts-Folgen-ID¹

¹Folgen-ID, die durch den Verfolger zugewiesen wurde, wenn ein zuverlässiges Einsatzorts-Statuspaket gesendet wurde. Siehe Einsatzortsstatus zu weiteren Informationen.

Sendeintervall (s)	Sendeintervall (min)	Bemerkungen
3600	60	Niedrigenergie-Wiederholungsintervall
1800	30
1200	20
900	15	12 h/Tag, 1000 Aktualisierungen/Monat
600	10	8 h/Tag, 1000 Aktualisierungen/Monat
300	5
225	3,75	12 h/Tag, 4000 Aktualisierungen/Monat
144	2,4	8 h/Tag, 4000 Aktualisierungen/Monat
60	1
30	0,5
10	0,166667
5	0,083333	Notfahrzeuge

Byte/Bit, Bitlänge	Beschreibung
0/0, 10	Gitterfeld-ID
1/2, 24	Bits 0-10: ΔN_off Bits 11-21: ΔE_off Bit 22: Zustandsdaten-Gültigkeit 1 = gültig Bit 23: GPS-Gültigkeit 1 = DGPS aktuell
4/2, 7	Bits 0-6: Geschwindigkeit
5/1, 7	Bits 0-6: Kurs

Byte/Bit, Bitlänge	Beschreibung
0/0, 10	Gitterfeld-ID
1/2, 24	Bits 0-10: ΔN_off Bits 11-21: ΔE_off Bit 22: Zustandsdaten-Gültigkeit 1 = gültig Bit 23: GPS-Gültigkeit 1 = DGPS aktuell

Code	Beschreibung
0	Kein Status
1	Netzwerkaustrittsanforderung
2	Niedrigenergie-Wiederholungsintervall-Anforderung
3	Niedrigenergie-Austrittsanforderung
4	Alle Wiederholungsintervall-Schlitze gelöscht
5	Hauptwiederholungsintervall-Schlitz gelöscht
6	Hilfswiederholungsintervall-Schlitz gelöscht
7	Anforderung zum Neuzuweisen des Hauptwiederholungsintervalls
8	Anforderung zum Neuzuweisen des Hilfswiederholungsintervalls
9-31

Byte/Bit, Bitlänge	Beschreibung
0/0, 1	Quittungs-/Antwort-Flag (0 = nur Quittung, 1 = Antwort)
0/1, 3	Antwortschlüssel-ID (0 = Bestätigung², 1 = Softkey #1, 2 = Softkey #2, 3 = Softkey #3, 4 = Softkey #4)
0/4, 1	Frei
0/5, 21	Nachrichten-/Einsatzorts-Folgen-ID
3/2, 20	GPS-Sekundenbestätigungs-/Antwortzeit¹

¹Zeigt die GPS-Sekunde an, wann die Nachricht zur Quittierung empfangen wurde, oder die GPS-Sekunde, wann der Softkey betätigt wurde, um eine Antwort zu erhalten.
²Zeigt an, dass die Nachricht vom Fahrer gelesen wurde.

Beschreibung	ID-Nummer	Bemerkungen	Zusatzbits
Netzeintritts-Anforderung	0	Zum Anfordern eines Haupt-RI-Schlitzes oder eines einmaligen Hilfs-RI-Schlitzes verwendet.	14
Zustand und Status	1	Normale periodische Übertragung	1
Zuverlässige Benutzerdaten	2	Benutzerspezifisch	4
Kurzer Zustand und Status	3	Enthält Verfolger-ID	3
Zuverlässige kurze Benutzerdaten	4	Benutzerspezifisch mit Verfolger-ID	6
Bereinigte Zustands-Benutzerdaten und Status	5	Zustand, Verfolger-ID und Benutzerdaten	3
Nachrichtenantwort und Benutzerdaten	6	Nachrichtenantwort mit Benutzerdaten.	6
Kurze Nachrichtenantwort und Benutzerdaten	7	Nachrichtenantwort mit vollständiger Verfolger-ID und vollständigen Benutzerdaten.	0
Einsatzortsstatus	8	Zum Anzeigen von Ankunft/Abfahrt am/vom Einsatzort verwendet.	2
Selbsttest (BIT)	9	Paket zum Bereitstellen von Info über den Verfolger, seine Umgebung und das HF-Netzwerk.	Je nach Typ unterschiedlich.
Vordefinierte Nachrichtendefinition und -anforderung	0x0a	Durch den Verfolger zum Anfordern einer Definition von vordefinierten Nachrichten verwendet.	0
Vordefinierte Nachrichtendefinition und -anforderung	0x0a	Bemerkung: Dieses Paket kann in einem Netzwerkeintritts-Schlitz gesendet werden.	0

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x00)
0/4, 1	4-4	0 = Haupt-RI-Schlitz, 1 = Einzelner Hilfs-RI-Schlitz
0/5, 1	5-5	0 = Haupt-RI-Schlitz, 1 = Einzelner Hilfs-RI-Schlitz
0/6, 30	6-35	Bits 0-29: Verfolger-ID-Nummer
4/4, 30	36-65	Bits 0-29: Verfolger-ID-Nummer
8/2, 5	66-70	Hilfsintervallanzahl
8/7, 5	71-75	Hilfsintervallanzahl
9/4, 4	76-79	Frei
10/0, 16	80-95	CRC 16

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x01)
0/4, 5	4-8	Netzwerkstatuscode
1/1, 48	9-56	Verfolgerzustands-Datenblock
7/1, 24	57-80	Benutzerdatenblock
10/1, 7	81-87	Frei
11/0, 8	88-95	CRC 8

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x02)
0/4, 8	4-11	ID der Benutzerdatenfolge
1/4, 72	12-83	Benutzerdatenblock
10/4, 4	84-87	Frei
11/0, 8	88-95	CRC 8

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x03)
0/4, 30	4-33	Bits 0-29: Verfolger-ID-Nummer
4/2, 5	34-38	Netzwerkstatuscode
4/7, 48	39-86	Verfolgerzustandsdaten-Block
10/5, 1	87-87	Frei
11/0, 8	88-95	CRC 8

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x04)
0/4, 30	4-33	Bits 0-29: Verfolger-ID-Nummer
4/2, 8	34-41	ID der Benutzerdatenfolge
5/2, 40	42-81	Benutzerdaten
10/2, 6	82-87	Frei
11/0, 8	88-95	CRC 8

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x05)
0/4, 30	4-33	Bits 0-29: Verfolger-ID-Nummer
4/2, 5	34-38	Netzwerkstatuscode
4/7, 34	39-72	Bereinigter Zustandsdaten-Block
8/7, 8	73-80	Benutzerdaten
10/7, 7	81-87	Frei
11/0, 8	88-95	CRC 8

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x06)
0/4, 46	4-49	Nachrichtenquittierungs-/-antwortblock
6/2, 32	50-81	Benutzerdatenblock
10/2, 6	82-87	Frei
11/0, 8	88-95	CRC 8

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x07)
0/4, 30	4-33	Bits 0-29: Verfolger-ID-Nummer
4/2, 46	34-79	Nachrichtenquittierungs-/-antwortblock
10/0, 8	80-87	Benutzerdatenblock
11/0, 8	88-95	CRC 8

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x08)
0/4, 30	4-33	Bits 0-29: Verfolger-ID-Nummer
4/2, 2	34-35	Typ des Ortes (0 = Einsatzort, 1 = Heimatstandort, 2 = kundendefininiert, 3 = kundendefininiert)
4/2, 21	36-56	Orts-ID
7/0, 1	56-56	Status (0 = Ankunft, 1 = Abfahrt)
7/1, 1	57-57	Automatisches Quellen-Flag²
7/2, 1	58-58	Benutzerquellen-Flag³
7/2, 20	59-79	GPS-Sekunden-Ankunfts-/-Abfahrtszeit¹
9/6, 8	80-87	Einsatzorts-Statusfolgen-ID
11/0, 8	88-95	CRC 8

¹Zeigt den Wert der GPS-Sekunde bei Ankunft/Abfahrt an.
²Auf durch „Ereignissteuerung" initiiertes Ereignis gesetzt.
³Auf benutzerinitiiertes Ereignis gesetzt.

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x09)
0/4, 4	4-7	BIT-Paket-Typ
1/0, 80		BIT-Paket-Datenblock¹
11/0, 8	88-95	CRC 8

¹Siehe die folgenden Tabellen zu BIT-Paketdatenblöcken.

# der Bytes	Beschreibung
2	Anzahl verpasster Bit-Syncs
2	CRC-Fehleranzahl A
2	CRC-Fehleranzahl B
1	Häufigkeit des Sync-Verlustes
1	Max. Dauer des Sync-Verlustes
1	Anzahl der Netzwerkeintritts-Versuche
1	Anzahl der Wiederholungen des zuverlässigen Paketes

# der Bytes	Beschreibung
1	Höchste Batteriespannung
1	Niedrigste Batteriespannung
1	Häufigkeit des Abschaltens der Zündung
1	Kürzeste Aus-Zeit (min)
1	Längste Aus-Zeit (min)
1	Höchste Temperatur (°C)
1	Niedrigste Temperatur (°C)
3	Frei (0x000000)

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 8	0-7	Häufigkeit ungültiger Nav
1/0, 8	8-15	Längste Dauer, in der Nav ungültig war (min)
2/0, 8	16-23	Häufigkeit ohne DGPS
3/0, 8	24-31	Längste Dauer ohne DGPS (min)
4/0, 4	32-35	Anzahl verfolgter SVs
4/4, 5	36-40	SNR für Kanal 0
5/1, 5	41-45	SNR für Kanal 1
5/6, 5	46-50	SNR für Kanal 2
6/3, 5	51-55	SNR für Kanal 3
7/0, 5	56-60	SNR für Kanal 4
7/5, 5	61-65	SNR für Kanal 5
8/2, 5	66-70	SNR für Kanal 6
8/7, 5	71-75	SNR für Kanal 7
9/4, 4	76-79	Frei

# der Bytes	Beschreibung
1	Größere Verfolger-Softwarefreigabe
1	Kleinere Verfolger-Softwarefreigabe
1	Verfolger-Software-Build
1	Größere Verfolger-Hardwarefreigabe
1	Kleinere Verfolger-Hardwarefreigabe
1	Größere MDT-Softwarefreigabe
1	Kleinere MDT-Softwarefreigabe
1	MDT-Software-Build
1	Größere MDT-Hardwarefreigabe
1	Kleinere MDT-Hardwarefreigabe

# der Bytes	Beschreibung
2	Häufigkeit, mit der der Auswaschschlauch über 15 Minuten hinweg dauerhaft eingeschaltet war
2	Häufigkeit, mit der Wasser eingeschaltet wurde
2	Häufigkeit, mit der Tür geöffnet wurde
2	Häufigkeit, mit der Trommel gefüllt wurde
2	Häufigkeit, mit der Trommel entleert wurde

Byte/Bit, Bitlänge	Bitnummer	Beschreibung
0/0, 4	0-3	Paket-ID-Block (0x0A)
0/4, 30	4-33	Bits 0-29: Verfolger-ID-Nummer
4/2, 30	34-63	Bits 0-29: Verfolger-ID-Nummer
8/0, 8	64-71	Vordefinierte Nachrichten-ID
9/0, 8	72-79	Vordefinierte Nachrichten-ID
10/0, 16	80-95	CRC 16

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6	Status
7-8	Breite	Lang	2^–31 Halbkreise	±0,5
9-10	Länge	Lang	2^–31 Halbkreise	±1,0
11	Höhe	Kurz	0,125 m
12	Nordgeschwindigkeit	Kurz	2^–8 m/s
13	Ostgeschwindigkeit	Kurz	2^–8 m/s
14	Vertikalgeschwindigkeit	Kurz	2^–8 m/s
15	Jahr	Ushort
16 (lsb)	Monat	Uchar		1-12
16 (msb)	Tag	Uchar		1-31
17 (lsb)	Stunde	Uchar		0-23
17 (msb)	Minute	Uchar		0-59
18	Sekunde	Ushort	2^–7 s	0-7679
19	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6 (lsb)	Nachrichten-Typ 1 = vorgefertigt, 2 = Volltext	uchar
6 (msb)	Länge (L) d. vorgefertigten ID/Textes	uchar
7 (lsb)	IOD	uchar		0-255
7 (msb)	Benutzerantwort	uchar		0-4
8	Jahr	ushort
9 (lsb)	Monat	uchar		1-12
9 (msb)	Tag	uchar		1-31
10 (lsb)	Stunde	uchar		0-23
10 (msb)	Minute	uchar		0-59
11 (lsb)	Anzahl gültiger Antworten	uchar		0-4
11 (msb)	Frei	uchar
12-16	Text Antwort 1	char
17-21	Text Antwort 2	char
22-26	Text Antwort 3	char
27-31	Text Antwort 4	char
nächstes L/2	Wenn Typ = 2, Text aufgefüllt mit 0 im letzten Byte, wenn L ungerade	char

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6	Datentyp-Kennung	ushort		0-255
7-16	20 Datenbytes	uchar

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6	Anzahl ungelesener Nachrichten (X)	ushort		0-255
7	ID der neuesten ungelesenen Nachricht	ushort		0-255
...	...	...	...	...
7 + X – 1	ID der ältesten ungelesenen Nachricht	ushort		0-255
7 + X	Anzahl gespeicherter Nachrichten (Y)	ushort		0-255
7 + X + 1	ID der neuesten gespeicherten Nachricht	ushort		0-255
...	...	...	...	...
7 + X + Y – 1	ID der ältesten gespeicherten Nachricht	ushort		0-255
7 + X + Y	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6	Anzahl der Nachrichten in der Liste (N)	ushort		0-255
7-21	Nachricht 1	char		0-255
...	...	...	...	...
(7+N·15) – (21 + N·15)	Nachricht N	char		0-255
7 + N·15	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6	Nachrichten-ID	ushort
7	Ein/Aus	ushort
8	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6 (lsb)	IOD	uchar		0-255
6 (msb)	Antwort	ushort		0-7
7	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6 (lsb)	Anzahl der Bytes	uchar		1 oder 9
6 (msb)	Datentyp-Kennung	uchar		0-255
7-11	10 Datenbytes (1 oder 9 werden verwendet)	uchar
12	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6	Nachrichten-Kennung	ushort		0-255
7	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf

Nachrichten-ID	Quelle	Beschreibung	Rate
1101	NTCC	Taktsteuerung	1 Hz
1102	NTCC	Sendedatenrahmen (1 von N)	N Rahmen bei 1 Hz
1201	SCC	SCC-Status	1 Hz

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6 (lsb)	Taktsteuerungs-Modus	uchar		0-2
6 (msb)	Steuerungstyp	uchar		0-2
7-8	Zeitgeber-Steuerung	lang	0,1 μs	±0,5 s
9	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6	Broadcast-Rahmen-ID	kurz		0-188
7 (lsb)	Rahmennummer (n)	uchar		0-?
7 (msb)	Gesamtzahl der Rahmen (N)	uchar		0-?
8	Anzahl der Bytes pro Rahmen (/)	kurz
9 – 8 + (/+1)/2	Rahmen-Datenbytes	uchar
9 + (/+1)/2	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten/LSB	Bereich
1-5	Kopf
6-7	Aktueller nominaler	lang	0,1 ms	0-0,1 + s
	Zeitgeber
8	SCC-Status	codiert
9	Datenprüfsumme

Nachrichten-ID	Quelle	Beschreibung	Rate
2104	Server	Anmelde-Info-Anforderung	Bei Initialisierung
2304	NTCC	Anmelde-Info-Antwort	Bei Initialisierung
2105	Server	NTCC-Profil-Anforderung	Bei Initialisierung
2305	NTCC	NTCC-Profil-Antwort	Bei Initialisierung
2103	NTCC	Status 2	1 Hz
2201	Server	FM-Daten	Bei Verbindung
2202	Server	Fahrzeugpaket	Hohe Rate
2203	Server	Ortszeitzonen-Offset	Bei Initialisierung und einmal pro Stunde

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Länge der Benutzer-ID	0x0000-0x0020
L₁	Benutzer-ID
2	Länge des Passwortes	0x0000-0x0020
12	Passwort
Auffüllen¹
1	Datenprüfsumme

¹0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
4	Seriennummer des NTCC
4	Seriennummer des Dachmoduls
2	Datenprüfsumme

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Taktstatus	0 = nicht synchron 1 = synchron
2	Wochen-Durchgangszähler
2	Schaltsekunden
2	GPS-Woche
4	GPS-Sekunde
2	Aktuelle Netzwerk-Rahmennummer
1	Systemstatus-Modus	1 = Initialisierung, 2 = Synchronisierung, 3 = Ausführung
1	Bits 0-3: Taktmodus Bits 4-7: Takt-Untermodus	Bits 0-3: 0 = Initialisierung, 1 = Grobes Offset, 2 = Grobe Rate, 3 = Genaue Rate Bits 4-7: 0 = Abtasten, 1 = Warten, 2 = Befehlen, 3 = Prüfen

1	Bits 0-3: GPS-Status Bits 4-7: Systemzeit-Status	Bits 0-3: 0 = Auf GPS warten, 1 = GPS initialisiert Bits 4-7: 0 = Ungültig, 1 = Gültig
2	SCC-Taktrate	LSB = 0,1 PPM
1	Bits 0-3: Status der SCC-Anschlussstelle Bits 4-7: Verbindungsstatus der SCC-Anschlussstelle	Bits 0-3: 0 = Inaktiv, 1 = Aktiv Bits 4-7: 0 = Nicht verbunden, 1 = Verbunden
4	Sync-Verlust-Ereignis
4	Gesamtdauer des Sync-Verlustes
1	NDC-Anschlussstelle	0 = Inaktiv, 1 = Aktiv
1	Bit 0: Dachmodul-Status Bits 1-2: Dachmodulkanal-Status Bit 3: FM-Sync Bit 4: FM-Sync-Nachricht Bits 5-7: frei	Bit 0: 0 = Inaktiv, 1 = Aktiv Bits 1-2: 0 = Kein Frequenzdatum, 1 = Nicht gesperrt, 2 = Gesperrt Bit 3: 0 = Unzuverlässig, 1 = Zuverlässig Bit 4: 0 = Unzuverlässig, 1 = Zuverlässig Bits 5-7:0
1	FM-Bit-Sync-Zuverlässigkeit	LSB = 1%
1	Sync-Daten-Status	0 = Unzuverlässig, 1 = Zuverlässig, 2 = abgelaufen
1	Sync-Daten-Zuverlässigkeit	LSB = 1%
1	Bits 0-3: GPS-CDU-Anschlussstelle Bits 4-7: PPS	Bits 0-3: 0 = Inaktiv, 1 = Aktiv Bits 4-7: 0 = Ungültig, 1 = Gültig
1	GPS-SVID-Anzahl (C₁)	0-12
1	GPS-SVID #0

...
1	GPS-SVID #(C₁-1)
1	GPS-CN0-Anzahl (C₂)	0-12
1	GPS-CN0 #0
...
1	GPS-CN0 #(C₂-1)
1	Bits 0-3: RTCM-Anschlussstelle Bits 4-7: Daten	Bits 0-3: 0 = Inaktiv, 1 = Aktiv Bits 4-7: 0 = Nicht verfügbar, 1 = Verfügbar
1	RTCM-T1-SVID-Anzahl (C₃)	0-12
2 (wenn C₃ >	RTCM-T1-Rahmennummer	0-3599 Bemerkung: T1-Rahmennummer wird nicht bereitgestellt, wenn C₃ = 0.
0)
1	RTCM-T1-SVID #0
...
1	RTCM-T1-SVID # (C₃-1)
1	RTCM-T2-SVID-Anzahl (C₄)	0-12
2 (wenn C₄ > 0)	RTCM-T2-Rahmennummer	0-3599
2 (wenn C₄ > 0)	RTCM-T2-Rahmennummer	Bemerkung: T2-Rahmennummer wird nicht bereitgestellt, wenn C₄ = 0.
1	RTCM-T2-SVID #0
...
1	RTCM-T2-SVID # (C₄-1)

2	FM-Fehler-Rahmen
2	FM-Fehlerzahl
2	FM-Bitzahl
4	FM-Gesamtfehlerzahl
4	FM-Gesamtbitzahl
4	Bitfehlerratenprüfung PPM	LSB = ,001 PPM

2	Gesamtzahl der im letzten Rahmen gesendeten Bytes	kurz
2	Freie Bytes nach dem letzten Rahmen	kurz
2	Gesendete Pakete	kurz
2	Empfangene Paketbytes	kurz
2	Gesendete Pakete	kurz
2	Gesendete Paketbytes	kurz
2	Pakete in Warteschlange	kurz
2	Paketbytes in Warteschlange	kurz
Auffüllen¹
1	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten	Bereich
1-5	Kopf
6	Frequenz	kurz	0,1 MHz	875-1079
7	Unterträger	kurz	kHz	67 oder 92
8-9	Breite	lang	2^–31 Halbkreise	–1 bis 1
10-11	Länge	lang	2^–31 Halbkreise	–0,5 bis 0,5
12	Höhe	kurz	m
13-27	Zeichenkette der	char
	Telefonnummer
28	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten	Bereich
1-5	Kopf
6	Länge der Fahrzeugdaten (I)	kurz	Bytes
7 – 6 + (1 + 1)12	Paketinhalt
7 + (/+1)/2	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten	Bereich
1-5	Kopf
6	Zeitzonen-Offset	kurz	LSB = 15 min	–48 bis 48
7	Datenprüfsumme

Nachrichten-ID	Quelle	Beschreibung	Rate
3101	NTCC	Frequenzsteuerung	Bei Initialisierung
3102	NTCC	Zeit/Status	1 Hz
3201	Dachmodul	Status	1 Hz
3202	Dachmodul	Empfangene FM-Daten	1 Hz
3203	Dachmodul	Takt	1 Hz

Wortnummer	Beschreibung	Typ	Einheiten	Bereich
1-5	Kopf
6	Frequenz	kurz	0,1 MHz	875-1079
7	Unterträger	kurz	kHz	67 oder 92
8	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten	Bereich
1-5	Kopf
6	Taktstatus	codiert
7	GPS-Woche	kurz		0-1023
8-9	GPS-Sekunde	lang		0-604799
10	Aktuelle Netzwerk-Rahmennummer	kurz		0-188
11	Modus	codiert
12	System-Status	codiert
13	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten	Bereich
1-5	Kopf
6	Frequenz	kurz	0,1 MHz	875-1079
7	Unterträger	kurz	kHz	67 oder 92
8	Taktstatus	codiert
9	System-Status	codiert
10	FM-Status	codiert
11	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten	Bereich
1-5	Kopf
6	Rahmennummer	kurz		0-188
7	Anzahl der Bytes (/)	kurz
8 – 7 + (/+1)/2	Datenbytes	uchar
8 + (/+1)/2	Datenprüfsumme

Wortnummer	Beschreibung	Typ	Einheiten	Bereich
1-5	Kopf
6	GPS-Woche	kurz		0-1023
7-8	GPS-Sekunde	lang		0-604799
9-10	Verzögerung gegenüber Sync	lang	0,1 μs	0-1 s
11	Datenprüfsumme

Nachrichten-Abschnitt	# der Wörter	Beschreibung	Wert oder Bereich
Kopf	1	Nachrichten-Startwort	0x81FF
	1	Standard-Nachrichtentyp-ID
	1	Datenwortanzahl (N)
	1	Flags	0xXX00
	1	Kopfprüfsumme
Daten (Optional)	1	Datenwort #1
	...
	1	Datenwort #N
	1	Datenprüfsumme

Nachrichten-Abschnitt	# der Wörter	Beschreibung	Wert oder Bereich
Kopf	1	Nachrichten-Startwort	0x81FF
	1	Standard-Nachrichtentyp-ID
	1	Datenwortanzahl (N)
	1	Flags/Nachrichten-ID	0xXX00
	1	Kopfprüfsumme

Software-Komponente mit einer Schnittstelle zum NDC-Server	Richtung/Zweck	Reservierter Nachrichten-ID-Bereich
NTCC	Vom N DC-Server	2100-2199
	Zum NDC-Server	2200-2299
	Antwort auf vom NDC-Server initiierte Nachricht	2300-2399
	Antwort auf vom NTCC initiierte Nachricht	2400-2499
Netzwerk-Hub	Vom NDC-Server	4100-4199
	Zum NDC-Server	4200-4299
	Antwort auf vom NDC-Server initiierte Nachricht	4300-4399
	Antwort auf vom Netzwerk-Hub initiierte Nachricht	4400-4499
NDC-Bedienstation	Vom NDC-Server	5100-5199
	Zum NDC-Server	5200-5299
	Antwort auf vom NDC-Server initiierte Nachricht	5300-5399
	Antwort auf von NDC-Bedienstation initiierte Nachricht	5400-5499
DMCS	Vom NDC-Server	7100-7199
	Zum NDC-Server	7200-7299
	Antwort auf vom NDC-Server initiierte Nachricht	7300-7399
	Antwort auf vom DMCS initiierte Nachricht	7400-7499

Software-Komponente mit einer Schnittstelle zum DMCS	Richtung/Zweck	Reservierter Nachrichten-ID-Bereich
CCS	Vom DMCS	6100-6199
	Zum CCS	6200-6299
	Antwort auf vom DMCS initiierte Nachricht	6300-6399
	Antwort auf vom CCS initiierte Nachricht	5400-6499

Nachrichten-Abschnitt	# der Wörter	Beschreibung	Wert oder Bereich
Optionaler Datenabschnitt	1	Datenwort #1
	...
	1	Datenwort #N
	1	Datenprüfsumme

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Länge der Benutzer-ID (L₁)	0x0000-0x0010
L₁	Benutzer-ID
2	Länge des Passwortes (L₂)	0x000-0x0010
L₂	Passwort
Auffüllen¹
2	Datenprüfsumme

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
		0x0000 = ERFOLG, 0x0001 = Benutzemame/Passwort ungültig, 0x002 = Verbindung hinzufügen gescheitert, 0x003 = Datenbankzugriffs-Fehler

2	Ergebnis

2	Datenprüfsumme

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
3	Nachrichtenfolgen-ID
2	Anzahl der Verfolger N₁ ¹	0x0000-0x0800⁵
4	Verfolger-ID #1	0x00000000-0x03FFFFFF
...
4	Verfolger-ID #N₁	0x00000000-0x03FFFFFF
1	Auffüllen	0x00
2	Datenprüfsumme

¹Die Zahl der Verfolgermodule, die daran scheiterten, die Nachricht vor dem Timeout zu quittieren. Wenn die Nachricht an alle mit dem Kunden verknüpften Verfolger gesendet worden war, zeigt diese Zahl die Verfolger an, die noch nicht auf die Nachricht geantwortet haben.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Länge des Benutzemamens der NDC-Bedienstation (L₁)	0x0000-0x0020
L₁	Benutzername der NDC-Bedienstation
2	Nachrichtenlänge (L₂)	0x0000-0x0100
12	Nachricht
2	ID der NDCS-Befehlsfolge¹	0x0000-0xFFFF
Auffüllen²
2	Datenprüfsumme

¹Die Antwort sollte diesen ID-Wert verwenden.
²0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	ID der NDCS-Befehlsfolge¹	0x0000 – 0xFFFF
2	Status	0x0000 = Erfolg/weitergeleitet an Kundenbedienstationen, 0x0001 = Keine Kundenbedienstationen verbunden.
2	Datenprüfsumme

¹Die Antwort sollte dieselbe ID verwenden, die mit der Anforderungsnachricht gesendet wurde.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Jahr²
1	Monat²	1-12
1	Tag²	1-31
1	Stunde²	0-23
1	Minute²	0-59
1	Sekunde²	0-59
2	Wert der Verfolgungsfolge³	0x0000-0xFFFF
2	Typ-ID1	0x0000-0x0004
1	Flag für Niedrigenergie-Modus des Verfolgers⁵	0 = nicht Niedrigenergie, 1 = Niedrigenergie
4	Verfolger-ID	0x00000000-0x3FFFFFFF
Variabel	Verfolgungsdatennachricht¹
Auffüllen⁴
2	Datenprüfsumme

¹Siehe Tabelle für das Format der Echtzeit-Verfolgungsdatennachricht.
²Daten-/Zeit-Werte zeigen an, wann der NDC-Server die Nachricht empfangen hat, und werden unter Verwendung der Greenwich Mean Time (GMT) angegeben.
³Der NDC-Server verwaltet einen Verfolgungsfolgenzähler für jedes Fahrzeug. Dieser Zähler wird eingesetzt, um Nachrichten, die von einem Fahrzeug an den NDC-Server gesendet werden, Verfolgungsfolgenwerte zuzuweisen. Die Nachrichtenfolgenwerte können durch CCS-Anwendungen eingesetzt werden, um festzustellen, ob Nachrichten in einem Satz von Fahrzeugverfolgungs-Nachrichten fehlen. Bemerkung: Verfolgungsfolgenwerte für jeden Verfolger überlappen alle 65536 Aktualisierungen.
⁴0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.
⁵Dieses Flag zeigt an, ob sich ein Verfolger derzeit im Niedrigenergie-Modus befindet.
Wenn Verfolger in den Niedrigenergie-Modus übergehen, fordern sie einen Niedrigenergie-Aktualisierungsschlitz in dem HF-Netzwerk an. Die Niedrigenergie-Aktualisierung ist geringer (1 Stunde) als die meisten Verfolgeraktualisierungsraten. Als Folge können die Verfolger zwischen den Aktualisierungen herunterfahren, um die Batterie ihres Fahrzeugs zu schonen. Verfolger im Niedrigenergie-Modus können Quittungen auf Nachrichten nicht unverzüglich bereitstellen. Nachrichten, die an Verfolger in diesem Modus gesendet werden, werden durch den NDC-Server in eine Warteschlange eingestellt, bis die Nachricht quittiert wird oder die Nachricht ihr Timeout erreicht.

Typ-ID	Name	# der Bytes	Beschreibung	Wert oder Bereich
0x0001	Zustand	4	Breite¹	–90° bis +90° (LSB = 180°·2^–31)
0x0001	Zustand	4	Länge¹	–180° bis +180° (LSB = 180°·2^–31)

		1	Geschwindigkeit	0x00-0x7F
		1	Geschwindigkeit	(LSB = 0,5 m/s 1,1 mph)
		1	Kurs	–180° bis +180° (LSB = 360°·2^–7 = 2,8125°)
		3	Benutzerdatenblock
		1	Frei	7 Zusatzbits sind verfügbar
0x0002	Zuverlässige Benutzerdaten	9	Benutzerdatenblock
0x0002	Zuverlässige Benutzerdaten	1	Frei
0x0003	Kurzer Zustand	4	Breite¹	–90° bis + 90° (LSB = 180°·2^–31)
		4	Länge¹	–180° bis +180° (LSB = 180°·2^–31)
		1	Geschwindigkeit	0x00-0x7F
		1	Geschwindigkeit	(LSB = 0,5m/s ≈ 1,1 mph)
		1	Kurs	–180° to +180°
		1	Kurs	(LSB = 360°·2^–7 = 2,8125°)
		1	Frei	1 Zusatzbit ist verfügbar
0x0004	Zuverlässige kurze Benutzerdaten	5	Benutzerdaten
0x0004	Zuverlässige kurze Benutzerdaten	1	Frei
0x0005	Bereinigte Zustands- und Benutzerdaten	4	Breite¹	–90° bis + 90° (LSB = 180°·2^–31)
		4	Länge¹	–180° bis +180° (LSB = 180°·2^–31)
		1	Benutzerdaten
		1	Frei	7 Zusatzbits sind verfügbar

0x0006	Nachrichtenantwort und Benutzerdaten	1	Quittungs-/Antwort-Flag	0 = nur Quittierung, 1 = Antwort⁶
		1	Antwortschlüssel-ID	0 = nur Quittierung/Bestätigung 1 = Softkey #1, 2 = Softkey #2, 3 = Softkey #3, 4 = Softkey #4
		3	Nachrichtenfolgen-/Orts-ID⁵
		2	GMT-Jahr³
		1	GMT-Monat³	1-12
		1	GMT-Tag³	1-31
		1	GMT-Stunde³	0-23
		1	GMT-Minute³	0-59
		1	GMT-Sekunde³	0-59
		4	Benutzerdaten
		1	Frei	6 Zusatzbits sind verfügbar
0x0007	Kurze Nachrichtenantwort und Benutzerdaten	1	Quittungs-/Antwort-Flag	0 = nur Quittierung, 1 = Antwort⁶
		1	Antwortschlüssel-ID	0 = nur Quittierung/Bestätigung 1 = Softkey #1, 2 = Softkey #2, 3 = Softkey #3, 4 = Softkey #4
		3	Nachrichtenfolgen-/Orts-ID⁵
		2	GMT-Jahr³
		1	GMT-Monat³
		1	GMT-Tag³
		1	GMT-Stunde³
		1	GMT-Minute³
		1	GMT-Sekunde³

		1	Benutzerdaten
0x008	Einsatzortssta	3	Einsatzorts-ID⁴
	tus	1	Status	0 = Ankunft, 1 = Abfahrt
		1	Statusquelle	1 = GPS, 2 = Benutzer, 3 = GPS und Benutzer
		2	GMT-Jahr³
		1	GMT-Monat³	1-12
		1	GMT-Tag³	1-31
		1	GMT-Stunde³	0-23
		1	GMT-Minute³	0-59
		1	GMT-Sekunde³	0-59
		1	Benutzerdaten
		1	Frei

¹Auflösung von ±4 m
²Auflösung von ±8 m
³Die Zeit des Empfangs von Quittierungen und die Zeit, zu der der Softkey betätigt wurde, um eine Antwort zu erhalten.
⁴ Diese Einsatzorts-ID ist dieselbe wie die mit der Einsatzortsabfertigungs-Nachricht verknüpfte ID. Siehe Einsatzortsabfertigung zu weiteren Informationen.
⁵Nachrichtenfolgen-ID verknüpft mit einer Textnachricht oder einer vordefinierten Nachricht. Oder Einsatzorts-ID verknüpft mit einer Einsatzortsabfertigungs-Nachricht. Siehe „Nachricht zum Senden einer Antwortnachricht", „Nachricht für die Antwort auf das Senden einer ID einer vordefinierten Nachricht" oder „Nachricht zum Senden einer Einsatzortsabfertigung" zu weiteren Informationen.
⁶Wenn Quittungs-/Antwort-Flag auf 0 gesetzt ist, zeigt 0 nur Quittierung an. Wenn Quittungs-/Antwort-Flag auf 1 gesetzt ist, zeigt 0 an, dass der Benutzer die Nachricht gelesen hat.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Flag für Niedrigenergie-Modus des Verfolgers¹	0 = nicht Niedrigenergie, 1 = Niedrigenergie
4	Verfolger-ID	0x00000000-0x3FFFFFFF
1	Auffüllen (= 0x00)
2	Datenprüfsumme

¹Dieses Flag zeigt an, ob sich ein Verfolger derzeit im Niedrigenergie-Modus befindet. Wenn Verfolger in den Niedrigenergie-Modus übergehen, fordern sie einen Niedrigenergie-Aktualisierungsschlitz in dem HF-Netzwerk an. Die Niedrigenergie-Aktualisierung ist geringer (1 Stunde) als die meisten Verfolgeraktualisierungsraten. Als Folge können die Verfolger zwischen den Aktualisierungen herunterfahren, um die Batterie ihres Fahrzeugs zu schonen. Verfolger im Niedrigenergie-Modus können Quittungen auf Nachrichten nicht unverzüglich bereitstellen. Nachrichten, die an Verfolger in diesem Modus gesendet werden, werden durch den NDC-Server in eine Warteschlange eingestellt, bis die Nachricht quittiert wird oder die Nachricht ihr Timeout erreicht.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
8	Verfolgerformat¹
Auffüllen⁴
2	Datenprüfsumme

# der Bytes	Beschreibung	Wert oder Bereich
4	Verfolger-ID	0x00000000-0x3FFFFFFF
1	Verfolgungsdienst	0 = LOT,
		1 = Kontinuierlich,
		2 = Manuell
2	Standard-Aktualisierungsrate (in Sekunden)	0x0000 (0), 0x0005 (5), 0x000a (10), 0x001e (30), 0x003c (60), 0x0090 (144), 0x00e1 (225), 0x012c (300), 0x0258 (600), 0x0384 (900), 0x04b0 (1200), 0x0708 (1800), 0x0e10 (3600) (0x0000 für Verfolger mit manueller Verfolgung)
1	Bit 0: Verfolgungsverlaufsdienst-Flag Bit 1: Nachrichtendienst-Flag Bit 2: Flag des Dienstes zum Ändern der Aktualisierungsrate Bit 3: Flag des Dienstes zum Ändern des Verfolgungsverlaufs Bits 4-7: frei	Bit 0: 0 = Nicht verfügbar, 1 = Verfügbar Bit 1: 0 = Nicht verfügbar, 1 = Verfügbar Bit 2: 0 = Nicht verfügbar, 1 = Verfügbar Bit 3: 0 = Nicht verfügbar, 1 = Verfügbar

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Startjahre installieren (0x0000 = Alle)
1	Startmonat² installieren	1-12
1	Starttag² installieren	1-31
1	Startstunde² installieren	0-23
1	Startminute² installieren	0-59

1	Startsekunde² installieren	0-59
2	Endejahr² installieren (0x0000 = Alle)
1	Endemonat² installieren	1-12
1	Endetag² installieren	1-31
1	Endestunde² installieren	0-23
1	Endeminute² installieren	0-59
1	Endesekunde² installieren	0-59
2	ID der NDCS-Befehlsfolge¹	0x0000-0xFFFF
2	Datenprüfsumme

¹Die Antwort sollte diesen ID-Wert verwenden.
²Der Datumsbereich wird eingesetzt, um gewünschtes) Zeit/Datum für Verfolgerinstallation anzuzeigen. Wenn Start- und/oder Endejahr auf 0x000 gesetzt sind, wird das entsprechende Start- und/oder Enddatum NICHT zum Begrenzen des Ergebnisses verwendet.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	ID der NDCS-Befehlsfolge¹	0x0000-0xFFFF
2	Status	0x0000 = Erfolg, 0x0001 = Datenbankzugriffs-Fehler
2	Gesamtzahl der Antworten²
2	Nummer der Antwort²
4	Verfolger-ID	0x00000000-0x3FFFFFFF
2	Verfolgerinstallations-Datensatz-Anzahl (C₁)
Variabel	Verfolgerinstallations-Datensatz #1
...
Variabel	Verfolgerinstallations-Datensatz #C₁
2	Datenprüfsumme

¹Die Antwort sollte dieselbe ID verwenden, die mit der Anforderungsnachricht gesendet wurde.
²Für jeden Verfolger in dem Anforderungsdatumsbereich wird eine eigene Antwortnachricht an den NDC-Server gesendet. Die Gesamtzahl der Antworten zeigt die Gesamtzahl der Antwortnachrichten, während die Nummer der Antwort die auf Null basierende Antwortnummer anzeigt.

# der Bytes	Beschreibung	Wert oder Bereich
2	Länge der VIN (L₁)	0x0000-0x0020
L₁	VIN
2	Jahr installieren
1	Monat installieren	1-12
1	Tag installieren	1-31
1	Stunde installieren	0-23
1	Minute installieren	0-59
1	Sekunde installieren	0-59
2	Jahr deinstallieren¹
1	Monat deinstallieren¹	1-12
1	Tag deinstallieren¹	1-31
1	Stunde deinstallieren¹	0-23
1	Minute deinstallieren¹	0-59
1	Sekunde deinstallieren¹	0-59

¹Wenn das Deinstallationsdatum nicht gesetzt worden ist und/oder der Verfolger noch in dem Fahrzeug installiert ist, sollten alle Werte für das Deinstallationsdatum auf NULL gesetzt werden.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Anzahl der VIN¹ (C1)
2	Länge der VIN #1 (L₁)
L₁	VIN #1
...
2	Länge der VIN #C1 (L_C1)
L_C1	VIN # C1
2	ID der NDCS-Befehlsfolge²	0x0000-0xFFFF
2	Datenprüfsumme

¹Wenn die Anzahl der VIN 0x0000 ist, werden alle Kundenprofile zurückgegeben.
²Die Antwort sollte diesen ID-Wert verwenden.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	ID der NDCS-Befehlsfolge¹	0x0000-0xFFFF
2	Status	0x0000 = Erfolg,
		0x0001 = Datenbankzugriffs-Fehler
2	Gesamtzahl der Profile in der Antwort
2	Fahizeugprofilnummer² (N)
Variabel	Fahrzeugprofilformat³ #1
...
Variabel	Fahrzeugprofilformat³ #N
2	Datenprüfsumme

¹Die Antwort sollte dieselbe ID verwenden, die mit der Anforderungsnachricht gesendet wurde.
²Aus der Gesamtzahl der Profile in der Profilliste wird das Profil mit der Nummer N zurückgegeben.
³Siehe Fahrzeugprofilformat unten.

2	Länge der VIN (L₁)
L₁	VIN
2	Länge des Alias (L₂)
L₂	Alias
2	Länge des Bundesstaats (L₃)
L₃	Bundesstaat
2	Länge der Zulassung (L₄)
L₄	Zulassung
2	Länge der Marke (L₅)
L₅	Marke
2	Länge des Modells (L₆)
L₆	Modell
2	Jahr
2	Datenprüfsumme

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
3	Nachrichtenfolgen-ID
1	Auffüllen	0x00
2	Datenprüfsumme

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID³	0x00-0xFF
2	Status	0x0000 = Erfolg¹, 0x0001 = ungültige Nachrichtenfolgen-ID, 0x0002 = Nachrichtenquittung bereits empfangen


2	Datenprüfsumme

¹Erfolg zeigt an, dass kein weiterer Versuch zum Senden der Nachricht unternommen wird. Es ist jedoch immer noch denkbar, dass die Nachricht gesendet wurde.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Länge des aktuellen Passworts (L₁)	0x0000-0x0020
L₁	Aktuelles Passwort
2	Länge des neuen Passworts (L₂)	0x0000-0x0020
L₂	Neues Passwort
1	Client-Anforderungs-ID¹	0x00-0xFF
Auffüllen¹
2	Datenprüfsumme

¹0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.
²Die Client-Anforderungs-ID wird durch den DMCS zugewiesen und durch den NDC-Server in der Antwortnachricht zurückgegeben.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID¹	0x00 – 0xFF
2	Status	0x0000 = Erfolg, 0x0001 = Erfolg – Nur NDC-Server-Passwort, 0x002 = Falsches aktuelles Passwort, 0x003 = Ungültiges neues Passwort, 0x004 = Datenbankzugriffs-Fehler
1	Auffüllen	0x00
2	Datenprüfsumme

¹Die ID, die mit der durch den DMCS gesendeten Anforderung verknüpft ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
4	Verfolger-ID	0x00000000-0x3FFFFFFF
2	Verfolgungsdienst	0x0000 = LOT,
		0x0001 = Kontinuierlich,
		0x0002 = Manuell
2	Aktualisierungsrate in Sekunden	0x0005 (5), 0x000a (10), 0x001e (30), 0x003c (60), 0x0090 (144), 0x00e1 (225), 0x012c (300), 0x0258 (600), 0x0384 (900), 0x04b0 (1200), 0x0708 (1800), 0x0e10 (3600)
1	Client-Anforderungs-ID²	0x00-0xFF
1	Auffüllen	0x00
2	Datenprüfsumme

¹Die Client-Anforderungs-ID wird durch den DMCS zugewiesen und durch den NDC-Server in der Antwortnachricht zurückgegeben.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID²	0x00-0xFF
2	Status	0x0000 = Erfolg,
		0x0001 = Dienst nicht verfügbar¹,
		0x002 = Ungültige Aktualisierungsrate,
		0x003 = Ungültiger Verfolgungsdienst,
		0x004 = Ungültige Verfolger-ID,
		0x005 = Angeforderte Rate derzeit nicht verfügbar
1	Auffüllen	0x00
2	Datenprüfsumme

¹Die Fähigkeit, den Verfolgungsdienst zu ändern, ist ein optionaler Dienst, der von Verfolger zu Verfolger gepflegt wird. Verfolger ohne diesen Dienst empfangen diese Fehlermeldung.
²Die ID, die mit der durch den DMCS gesendeten Anforderung verknüpft ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
3	Nachrichtenfolgen-ID
1	Timeout¹ (in Minuten)	0x00 = Kein Timeout, 0x01-0xF0 = Timeout-Wert in Minuten
2	Datenprüfsumme

¹Zeigt den Maximalwert für das Wiederholungs-Timeout an. Eine Nachrichten-Timeout-Nachricht wird an die/den CCS/DMCS gesendet, wenn die Nachricht nicht durch den Timeout-Wert quittiert wird. Wenn 0x00 für den Timeout festgelegt worden ist, wird die Nachricht gesendet, bis das maximale Timeout des PROTRAK-Systems erreicht worden ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Anzahl der Verfolger-IDs (N₁)¹
4	Verfolger-ID #1	0x00000000-0x3FFFFFFF
...
4	Verfolger-ID #N₁	0x00000000-0x3FFFFFFF
1	Client-Anforderungs-ID³	0x00-0xFF
Auffüllen²
2	Datenprüfsumme

¹Das Angeben von 0x0000 für die Nummer der Verfolger-IDs gibt alle Verfolgerprofile zurück, die mit dem Anmeldekontenprofil des Kunden verknüpft sind.
²0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.
³Die Client-Anforderungs-ID wird durch den DMCS zugewiesen und durch den NDC-Server in der Antwortnachricht zurückgegeben.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID⁵	0x00-0xFF
2	Status	0x0000 = Erfolg, 0x0001 = Datenbankzugriffs-Fehler, 0x0002 = Ungültige Verfolger-ID²
2	Gesamtzahl der Profile in der Antwortliste
2	Verfolgerprofil-Nummer (N)¹
Variabel	Verfolgerprofil #N³
Auffüllen⁴
2	Datenprüfsumme

¹Aus der Gesamtzahl der Profile in der Profilliste wird das Profil mit der Nummer N zurückgegeben.
²Ungültig bezieht sich nur auf IDs, die sich nicht im gültigen Bereich und/oder Format befinden. In der Datenbank fehlende (oder mit anderen Kunden-IDs verknüpfte) IDs führen dazu, dass das Profil nicht ohne Fehlercode zurückgegeben wird.
³Siehe die Tabelle für das Verfolgerprofilformat.
⁴0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.
⁵ Die ID, die mit der durch den DMCS gesendeten Anforderung verknüpft ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Anzahl der Verfolger N₁ ¹	0x0000-0x0800⁵
4	Verfolger-ID #1	0x00000000-0x3FFFFFFF
...	Verfolger-ID #N₁
4	Verfolger-ID #N₁	0x00000000-0x3FFFFFFF
2	Nachrichtenlänge (L₁)	0x0000-0x0050
L₁	Message
1	Antwortsatz-ID²	0x0000-0x0007
1	Timeout⁶ (in Minuten)	0x00 = Kein Timeout, 0x01-0xF0 = Timeout-Wert in Minuten
1	Client-Anforderungs-ID⁴	0x00-0xFF
Auffüllen³
2	Datenprüfsumme

¹Wenn die Anzahl der Verfolger 0x0000 ist, wird die Kunden-ID verwendet, die mit dem Anmeldekontenprofil des Kunden verknüpft ist.
²Es kann ein vordefinierter Antwortsatz (siehe Vordefinierte Nachrichten-Antwort-Sätze) ausgewählt werden. Verfolger antworten unter Verwendung einer Antwort-ID, die die aus dem vordefinierten Satz ausgewählte Antwort anzeigt. Diese Antwort-ID wird in einem Paket für „Nachrichtenantwort und Zustand" oder in einem Paket für „Nachrichtenantwort und bereinigten Zustand" innerhalb einer „Echtzeit-Verfolgungsdaten-Nachricht", die dieselbe Nachrichtenfolgen-ID enthält, zurückgegeben.
³0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.
⁴Die Client-Anforderungs-ID wird durch den DMCS zugewiesen und durch den NDC-Server in der Antwortnachricht zurückgegeben.
⁵Aufgrund von Beschränkungen der FM-Unterträger-Bandbreite kann es mehrere Sekunden (oder Minuten) dauern, Nachrichten an eine große Zahl von Verfolgern zu senden. Es wird erwartet, dass Gruppen klein sind (etwa 20-60 Verfolger). Der NDC-Server setzt jedoch ein ID-Zuweisungsverfahren ein, das ihm ermöglicht, mit einer großen Zahl von Verfolgern in seinem HF-Netzwerk zu kommunizieren, wenn Verfolgergruppen-Verknüpfungen im Voraus bekannt sind. Der DMCS ist dafür zuständig, diese Verfolgergruppen-Verknüpfungen bereitzustellen.
⁶Zeigt den Maximalwert für das Wiederholungs-Timeout an. Eine Nachrichten-Timeout-Nachricht wird an die/den CCS/DMCS gesendet, wenn die Nachricht nicht durch den Timeout-Wert quittiert wird. Wenn 0x00 für den Timeout festgelegt worden ist, wird die Nachricht gesendet, bis das maximale Timeout des PROTRAK-Systems erreicht worden ist.

Antwortsatz-ID	MDE-Softkey 1	MDE-Softkey 1	MDE-Softkey 1	MDE-Softkey 1
0¹	{LEER}	{LEER}	{LEER}	{LEER}
1	Ja	Nein	Rufen	{LEER}
2	OK	{LEER}	{LEER}	{LEER}
3	OK	Abbrechen	Rufen	{LEER}
4	Annehmen	Ablehnen	Rufen	{LEER}
5	{LEER}	{LEER}	{LEER}	{LEER}
6	{LEER}	{LEER}	{LEER}	{LEER}
7	{LEER}	{LEER}	{LEER}	{LEER}

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID³	0x00-0xFF
2	Status	0x0000 = Erfolg¹, 0x0001 = Dienst nicht verfügbar⁴, 0x0002 = Ungültiges Nachrichtenformat, 0x0003 = Nachricht zu lang, 0x0004 = Ungültige Verfolger-ID, 0x0005 = Ungültiger Antwortsatz, 0x0006 = Datenbankzugriffs-Fehler, 0x0007 = Dienst vorübergehend nicht verfügbar, 0x0008 = Nullnachrichten-Fehler, 0x0009 = Niedrigenergie-Modus, 0x0010 = Außerhalb des Netzwerks
3	Nachrichtenfolgen-ID²	0x000000-0xFFFFFF
2	Datenprüfsumme

¹Erfolg zeigt an, dass die Nachricht erfolgreich in eine Warteschlange eingestellt worden ist, so dass sie an den/die angegebenen Verfolger gesendet werden kann.
²ID, die mit der Nachricht verknüpft ist, die gesendet wird. Wenn der Verfolger diese Nachricht erfolgreich quittiert und/oder auf sie antwortet, empfängt der DMCS ein Paket für „Nachrichtenantwort und Zustand" oder ein Paket für „Nachrichtenantwort und bereinigten Zustand" innerhalb einer „Echtzeit-Verfolgungsdaten-Nachricht", die dieselbe Nachrichtenfolgen-ID enthält.
³Die ID, die mit der durch den DMCS gesendeten Anforderung verknüpft ist.
⁴Wenn die Nachricht an eine Liste von Verfolgern gesendet wurde, muss für alle Verfolger in der Liste der Nachrichtendienst verfügbar sein, oder es wird dieser Fehlercode zurückgegeben.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Anzahl der Verfolger N₁ ²	0x0000-0x0800⁴
4	Verfolger-ID #1	0x00000000-0x3FFFFFFF
...
4	Verfolger-ID #N₁	0x00000000-0x3FFFFFFF
1	Vordefinierte Nachrichten-ID	0x00-0xFF
1	Antwortsatz-ID²	0x0000-0x07
1	Timeout⁵ (in Minuten)	0x00 = Kein Timeout, 0x01-0xF0 = Timeout-Wert in Minuten
1	Client-Anforderungs-ID³	0x00-0xFF
2	Datenprüfsumme

¹Wenn die Anzahl der Verfolger 0x0000 ist, wird die Kunden-ID verwendet, die mit dem Anmeldekontenprofil des Kunden verknüpft ist.
²Es kann ein vordefinierter Antwortsatz (siehe Vordefinierte Nachrichten-Antwort-Sätze) ausgewählt werden. Verfolger antworten unter Verwendung einer Antwort-ID, die die aus dem vordefinierten Satz ausgewählte Antwort anzeigt. Diese Antwort-ID wird in einem Paket für „Nachrichtenantwort und Zustand" oder in einem Paket für „Nachrichtenantwort und bereinigten Zustand" innerhalb einer „Echtzeit-Verfolgungsdaten-Nachricht", die dieselbe Nachrichtenfolgen-ID enthält, zurückgegeben.
³Die Client-Anforderungs-ID wird durch den DMCS zugewiesen und durch den NDC-Server in der Antwortnachricht zurückgegeben.
⁴Aufgrund von Beschränkungen der FM-Unterträger-Bandbreite kann es mehrere Sekunden (oder Minuten) dauern, Nachrichten an eine große Zahl von Verfolgern zu senden. Es wird erwartet, dass Gruppen klein sind (etwa 20-60 Verfolger). Der NDC-Server setzt jedoch ein ID-Zuweisungsverfahren ein, das ihm ermöglicht, mit einer großen Zahl von Verfolgern in seinem HF-Netzwerk zu kommunizieren, wenn Verfolgergruppen-Verknüpfungen im Voraus bekannt sind. Der DMCS ist dafür zuständig, diese Verfolgergruppen-Verknüpfungen bereitzustellen.
⁵Zeigt den Maximalwert für das Wiederholungs-Timeout an. Eine Nachrichten-Timeout-Nachricht wird an die/den CCS/DMCS gesendet, wenn die Nachricht nicht durch den Timeout-Wert quittiert wird. Wenn 0x00 für den Timeout festgelegt worden ist, wird die Nachricht gesendet, bis das maximale Timeout des PROTRAK-Systems erreicht worden ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID³	0x00-0xFF
2	Status	0x0000 = Erfolg¹, 0x0001 = Dienst nicht verfügbar⁴, 0x0002 = Ungültiges Nachrichtenformat, 0x0003 = Nachricht zu lang, 0x0004 = ungültige Verfolger-ID, 0x0005 = Ungültiger Antwortsatz, 0x0006 = Datenbankzugriffs-Fehler, 0x0007 = Dienst vorübergehend nicht verfügbar, 0x0009 = Niedrigenergie-Modus, 0x0010 = Außerhalb des Netzwerks
3	Nachrichtenfolgen-ID²	0x000000-0xFFFFFF
2	Datenprüfsumme

¹Erfolg zeigt an, dass die Nachrichten-ID erfolgreich in eine Warteschlange eingestellt worden ist, so dass sie an den/die angegebenen Verfolger gesendet werden kann.
²ID, die mit der Nachricht verknüpft ist, die gesendet wird. Wenn der Verfolger diese Nachricht erfolgreich quittiert und/oder auf sie antwortet, empfängt der DMCS ein Paket für „Nachrichtenantwort und Zustand" oder ein Paket für „Nachrichtenantwort und bereinigten Zustand" innerhalb einer „Echtzeit-Verfolgungsdaten-Nachricht", die dieselbe Nachrichtenfolgen-ID enthält.
³Die ID, die mit der durch den DMCS gesendeten Anforderung verknüpft ist.
⁴Wenn eine vordefinierte Nachricht an eine Liste von Verfolgern gesendet wurde, muss für alle Verfolger in der Liste der Nachrichtendienst verfügbar sein, oder es wird dieser Fehlercode zurückgegeben.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Anzahl der Verfolger N₁ ¹	0x0000-0x0800
4	Verfolger-ID #1	0x00000000-0x03FFFFFF
...
4	Verfolger-ID #N₁	0x00000000-0x03FFFFFF
1	Ablaufen des Einsatzortes⁷	0x00 (alle Fahrten), 0x01-0xff
1	Antwortsatz-ID²	0x0000-0x07
4	Nordöstliche Breite
4	Nordöstliche Länge
4	Südwestliche Breite
4	Südwestliche Länge
1	Nachrichtenlänge (L₁)	0x00-0x64
1¹	Message⁷
1	Timeout⁵ (in Minuten)	0x00 = Kein Timeout, 0x01-0xF0 = Timeout-Wert in Minuten
1	Client-Anforderungs-ID³	0x00-0xFF
Auffüllen⁴
2	Datenprüfsumme

¹Wenn die Anzahl der Verfolger 0x0000 ist, wird die Kunden-ID verwendet, die mit dem Anmeldekontenprofil des Kunden verknüpft ist.
²Es kann ein vordefinierter Antwortsatz (siehe Vordefinierte Nachrichten-Antwort-Sätze) ausgewählt werden. Verfolger antworten unter Verwendung einer Antwort-ID, die die aus dem vordefinierten Satz ausgewählte Antwort anzeigt. Diese Antwort-ID wird in einem Paket für „Nachrichtenantwort und Zustand" oder in einem Paket für „Nachrichtenantwort und bereinigten Zustand" innerhalb einer „Echtzeit-Verfolgungsdaten-Nachricht", die dieselbe Nachrichtenfolgen-ID enthält, zurückgegeben.
³Die Client-Anforderungs-ID wird durch den DMCS zugewiesen und durch den NDC-Server in der Antwortnachricht zurückgegeben.
⁴0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.
⁵Zeigt den Maximalwert für das Wiederholungs-Timeout an. Eine Nachrichten-Timeout-Nachricht wird an die/den CCS/DMCS gesendet, wenn die Nachricht nicht durch den Timeout-Wert quittiert wird. Wenn 0x00 für den Timeout festgelegt worden ist, wird die Nachricht gesendet, bis das maximale Timeout des PROTRAK-Systems erreicht worden ist.
⁶Einsatzortdauer zeigt an, wie lange ein angegebener Einsatzort eingesetzt werden sollte. Einzelfahrt zeigt an, dass der Verfolger die Einsatzortsinformationen beibehalten sollte, bis der Verfolger in den angegebenen Einsatzort eintritt oder ihn verlässt. Jede Fahrt zeigt an, dass der Verfolger jedes Mal anzeigen soll, wenn der Verfolger in den angegebenen Einsatzort eintritt oder ihn verlässt.
⁷Zeigt die Anzahl der Stunden an, über die der Einsatzort gültig ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID³	0x00 – 0xFF
2	Status	0x0000 = Erfolg¹, 0x0001 = Dienst nicht verfügbar, 0x0002 = Ungültiges Nachrichtenformat, 0x0003 = Nachricht zu lang, 0x0004 = Ungültige Verfolger-ID, 0x0005 = Ungültiger Antwortsatz, 0x0006 = Datenbankzugriffs-Fehler, 0x0007 = Dienst vorübergehend nicht verfügbar, 0x0009 = Niedrigenergie-Modus, 0x0010 = Außerhalb des Netzwerks
1	Orts-ID^2,4	0x000000-0xFFFFFF
2	Datenprüfsumme

¹Erfolg zeigt an, dass die Nachrichten-ID erfolgreich in eine Warteschlange eingestellt worden ist, so dass sie an den/die angegebenen Verfolger gesendet werden kann.
²ID, die mit der Nachricht verknüpft ist, die gesendet wird. Wenn der Verfolger diese Nachricht erfolgreich quittiert und/oder auf sie antwortet, empfängt der DMCS ein Paket für „Nachrichtenantwort und Zustand" oder ein Paket für „Nachrichtenantwort und bereinigten Zustand" innerhalb einer „Echtzeit-Verfolgungsdaten-Nachricht", die dieselbe Einsatzorts-ID enthält.
³Die ID, die mit der durch den DMCS gesendeten Anforderung verknüpft ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
2	Anzahl der Verfolger N₁ ¹	0x0000-0x0800⁴
4	Verfolger-ID #1	0x00000000-0x03FFFFFF
...
4	Verfolger-ID #N₁	0x00000000-0x03FFFFFF
1	Benutzerdatentyp	0x00-0xFF
2	Benutzerdatenlänge (L₁)	0x0000-0x0050
L₁	Benutzerdaten
1	Timeout⁵ (in Minuten)	0x00 = Kein Timeout, 0x01-0xF0 = Timeout-Wert in Minuten
1	Client-Anforderungs-ID³	0x00-0xFF
Auffüllen²
2	Datenprüfsumme

¹Wenn die Anzahl der Verfolger 0x0000 ist, wird die Kunden-ID verwendet, die mit dem Anmeldekontenprofil des Kunden verknüpft ist.
²0x00 wird zum Auffüllen eingesetzt, falls erforderlich, um das komplette Gesamtwort auszurichten.
³Die Client-Anforderungs-ID wird durch den DMCS zugewiesen und durch den NDC-Server in der Antwortnachricht zurückgegeben.
⁴Aufgrund von Beschränkungen der FM-Unterträger-Bandbreite kann es mehrere Sekunden (oder Minuten) dauern, Nachrichten an eine große Zahl von Verfolgern zu senden. Es wird erwartet, dass Gruppen klein sind (etwa 20-60 Verfolger). Der NDC-Server setzt jedoch ein ID-Zuweisungsverfahren ein, das ihm ermöglicht, mit einer großen Zahl von Verfolgern in seinem HF-Netzwerk zu kommunizieren, wenn Verfolgergruppen-Verknüpfungen im Voraus bekannt sind. Der DMCS ist dafür zuständig, diese Verfolgergruppen-Verknüpfungen bereitzustellen.
⁵Zeigt den Maximalwert für das Wiederholungs-Timeout an. Eine Nachrichten-Timeout- Nachricht wird an die/den CCS/DMCS gesendet, wenn die Nachricht nicht durch den Timeout-Wert quittiert wird. Wenn 0x00 für den Timeout festgelegt worden ist, wird die Nachricht gesendet, bis das maximale Timeout des PROTRAK-Systems erreicht worden ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID³	0x00-0xFF
2	Status	0x0000 = Erfolg¹, 0x0001 = Dienst nicht verfügbar⁴, 0x0002 = Ungültiges Nachrichtenformat, 0x0003 = Nachricht zu lang, 0x0004 = Ungültige Verfolger-ID, 0x0005 = Ungültiger Antwortsatz, 0x0006 = Datenbankzugriffs-Fehler, 0x0007 = Dienst vorübergehend nicht verfügbar, 0x0009 = Niedrigenergie-Modus, 0x0010 = Außerhalb des Netzwerks
1	Nachrichtenfolgen-ID²	0x000000-0xFFFFFF
2	Datenprüfsumme

¹Erfolg zeigt an, dass die Nachrichten-ID erfolgreich in eine Warteschlange eingestellt worden ist, so dass sie an den/die angegebenen Verfolger gesendet werden kann.
²ID, die mit der Nachricht verknüpft ist, die gesendet wird. Wenn der Verfolger diese Nachricht erfolgreich quittiert und/oder auf sie antwortet, empfängt der DMCS ein Paket für „Nachrichtenantwort und Zustand" oder ein Paket für „Nachrichtenantwort und bereinigten Zustand" innerhalb einer „Echtzeit-Verfolgungsdaten-Nachricht", die dieselbe Nachrichtenfolgen-ID enthält.
³Die ID, die mit der durch den DMCS gesendeten Anforderung verknüpft ist.
⁴Wenn Benutzerdaten an eine Liste von Verfolgern gesendet wurde, muss für alle Verfolger in der Liste der Nachrichtendienst verfügbar sein, oder es wird dieser Fehlercode zurückgegeben.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
4	Verfolger-ID	0x00000000-0x03FFFFFF
1	Client-Anforderungs-ID¹	0x00-0xFF
1	Auffüllen	0x00
2	Datenprüfsumme

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
1	Client-Anforderungs-ID²	0x00-0xFF
2	Status	0x0000 = Erfolg¹, 0x0001 = Dienst nicht verfügbar, 0x0002 = Ungültige Verfolger-ID, 0x0003 = Datenbankzugriffs-Fehler, 0x0004 = Dienst vorübergehend nicht verfügbar,
1	Auffüllen	0x00
2	Datenprüfsumme

¹Erfolg zeigt an, dass die Nachricht erfolgreich in eine Warteschlange eingestellt worden ist, so dass sie an den angegebenen Verfolger gesendet werden kann.
²Die ID, die mit der durch den DMCS gesendeten Anforderung verknüpft ist.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
4	Verfolger-ID
8	Verfolgerinstallations-Datensatz¹
Auffüllen⁴
2	Datenprüfsumme

¹Siehe Verfolgerinstallations-Datensatz.

# der Bytes	Beschreibung	Wert oder Bereich
10	Kopf
8	Fahrzeugprofilformat¹
Auffüllen⁴
2	Datenprüfsumme

¹siehe Fahrzeugprofilformat.

Claims

Ein Flottenverwaltungssystem zum Verfolgen der Standorte von Fahrzeugen (17) in der Flotte und zum Bestimmen des Status von Ereignissen, die mit der Verwendung oder Funktion der Fahrzeuge (17) in Beziehung stehen, wobei jedes dieser Fahrzeuge (17) ein Positionsortungssystem (193, 203, 204) zur Bestimmung des Standortes des besagten Fahrzeugs (17) besitzt, und wenigstens einen Sensor besitzt zur Detektierung von Fahrzeugereignisinformation und zum Erzeugen von Ausgaben der betriebsbereiten Funktionen des Fahrzeugs, und einen Verfolgungscomputer (135) besitzt zur Übertragung von Standortinformation und Statusinformation an ein Flottenverwaltungsbüro; dadurch gekennzeichnet, dass es weiterhin Mittel enthält, das die Fahrzeugereignisinformation von dem wenigstens einen Sensor empfängt und mehrere Statusereignisse bestimmt, die auf Auslieferungszustände (311, 316, 319, 321, 322, 324, 330, 332) in einer Sequenz von Auslieferungsereignissen, die das besagte Fahrzeug bei einer Auslieferung vornimmt, hinweisen, auf der Basis der Fahrzeugereignisinformation, die durch den wenigstens einen Sensor detektiert wird, und wobei dieser Verfolgungscomputer (135) automatisch Fahrzeugereignisinformation, die auf den Auslieferungszustand des Fahrzeugs hinweist, an das Flottenverwaltungsbüro überträgt.
Das Flottenverwaltungssystem von Anspruch 1, wobei diese Flottenfahrzeuge und dieses Flottenverwaltungsbüro für eine Kommunikation durch ein drahtloses Netzwerk (57) verbunden sind.
Das Flottenverwaltungssystem von Anspruch 2, wobei jedes Fahrzeug eine Vielzahl von Sensoren besitzt zur Detektierung oder Messung von vielen dieser Ereignisse und zum Liefern von darauf hinweisenden Eingaben über dieses drahtlose Netzwerk an den besagten Verfolgungscomputer (135) für ein umgehendes Berichten von Ereignisdaten, wie sie sich gerade ereignen.
Das Flottenverwaltungssystem von Anspruch 3, wobei wenigstens einige von dieser Vielzahl von Sensoren aus einer Gruppe ausgewählt werden, die besteht aus Detektoren für Fahrzeugzündung, Fahrzeuglaufzeit, Scheinwerfer an, Getriebe in Vorwärts- und Rückwärts-Richtungen, Radgeschwindigkeit, Beifahrer- oder Fahrer tür offen, Einschalten des Allradantriebs, Betrieb der Fahrzeugnotbeleuchtung oder -sirenen, Kraftstoffstand, Kühlmitteltemperatur, Öldruck, Batteriespannung, Motorwarnungsanzeigen, Diebstahls- oder Manipulationsalarme, Frachttür offen, Frachttemperatur, Fahrzeuggewicht, Einschalten des Nebenabtriebs für Geräte inklusive Pumpen, Winden, Kräne oder Einzugsschnecken, Parameter und Toleranzprüfung des Motordatenbusses, Kippbox oben oder Luke offen, Betonmischtrommeldrehgeschwindigkeit und -richtung, Betonmischwaschwasserverwendung, Betonmischfüllwasservolumen, Entfernung die zwischen vorgegebenen Zonen durchfahren wird, Motor an und aus, überhöhte Fahrzeuggeschwindigkeit, Fahren bei unangemessenen Zeiten, unautorisierte Stopps des Fahrzeugs und Ankunfts-/Abfahrtszeiten bei bestimmten Standorten.
Das Flottenverwaltungssystem von Anspruch 1, inklusive einem Gerät bei diesem Flottenverwaltungsbüro zum Zuordnen eines detektierten Ereignisses zu einem Fahrzeugstandort oder einer Fahrzeuggeschwindigkeit.
Das Flottenverwaltungssystem von Anspruch 5, wobei dieses Fahrzeugstandortzuordnungsgerät Mittel enthält zum Vergleichen des Fahrzeugstandortes, der durch dieses Positionsortungssystem detektiert wird, mit vorbestimmten geografisch abgebildeten Zonen.
Das Flottenverwaltungssystem von Anspruch 2, inklusive einem Gerät bei diesem Flottenverwaltungsbüro zum Definieren von Kartenregionen, die Zonen in Gebieten bilden von denen erwartet wird, dass sie durch die besagten Flottenfahrzeuge durchquert werden, und wobei dieser Verfolgungscomputer ein Gerät enthält zum automatischen Berichten, inklusive der Benutzung dieses Positionsortungssystem des dazugehörigen Flottenfahrzeugs, um eines oder mehrere der Folgenden zu berichten: Entfernung die zwischen Zonen von dem Fahrzeug durchfahren wird, Fahrzeugmotor an und aus, Fahrzeug wird mit überhöhter Geschwindigkeit gefahren, Fahrzeug wird bei unangemessenen Zeiten gefahren, Fahrzeug macht unautorisierte Stopps, und Zeiten der Ankunft und Abfahrt bei vorausgewählten Standorten.
Das Flottenverwaltungssystem von Anspruch 2, wobei diese Flottenfahrzeuge Krankenwagen sind und dieses automatische Berichten, an dieses Flottenverwaltungsbüro, über Ausflüge, Anrufzeiten, Mitnahmeorte, und Krankenhäuser berichtet, zu welchen Beförderungen gemacht werden.
Das Flottenverwaltungssystem von Anspruch 1, wobei dieser Verfolgungscomputer ein Gerät enthält zum automatischen Berichten der detektierten Ereignisse, das Ausnahmen von Routineoperationen des Fahrzeugs an dieses Flottenverwaltungsbüro berichtet.
Das Flottenverwaltungssystem von Anspruch 3, wobei diese Flottenfahrzeuge Mischlastwagen (195) für Transportbeton oder anderes Schlammmaterial sind, und diese Vielzahl von Sensoren wenigstens einige der folgenden Ereignisse detektieren oder messen: Lastwagen ist bei Fabrikgrundstück voll beladen, Lastwagenabfahrt vom Fabrikgrundstück, Lastwagenankunft bei Einsatzort, Lastwagen beginnt das Ausschütten, das Ausschütten des Lastwagens ist beendet, Lastwagen wird einer Wäsche unterzogen, Lastwagenabfahrt vom Einsatzort, Lastwagenankunft bei Fabrikgrundstück, und Abweichungen von einer Routinesequenz der besagten Ereignisse; und wobei wenigstens einige der besagten Ereignisse basierend auf der Lastwagengeschwindigkeit oder dem Zeitintervall detektiert werden, über welches ein Ereignis stattfindet.
Das Flottenverwaltungssystem von Anspruch 10, wobei wenigstens einige der besagten Mischlastwagen der besagten Flottenfahrzeuge mit Halleffektsensoren (288, 289) ausgestattet sind.
Das Flottenverwaltungssystem von Anspruch 1, wobei diese Flottenfahrzeuge Transportlastwagen (195) für pulverisiertes Schuttgutmaterial sind, in die durch Rohre unterhalb des Sammelbunkersdes Lastwagens Luft gepumpt wird, um davon das pulverisierte Material abzuladen, und wobei jeder dieser Transportlastwagen einen Tachometersensor enthält zur An-/Ausdetektierung des Pumpens, um auf ein Ausladen und eine Beendigung des Ausladens des pulverisierten Materials von dem entsprechenden Transportlastwagen hinzuweisen, um selbiges an dieses Flottenverwaltungsbüro zu berichten.
Das Flottenverwaltungssystem von Anspruch 1, wobei diese Flottenfahrzeuge Transportlastwagen (195) für Schüttgesteinmaterial sind, wobei jeder einen Kipper besitzt, um das Gesteinmaterial davon abzuladen, und wobei jeder dieser Transportlastwagen einen Sensor zur Detektierung des Kipperbetriebs enthält, um auf ein Ausladen und eine Beendigung des Ausladens des Gesteinmaterials von dem entsprechenden Transportlastwagen hinzuweisen, um selbiges an dieses Flottenverwaltungsbüro zu berichten.